24 апреля 2020 года Apple и Google анонсировали обновление совместно разработанного протокола отслеживания контактов (Apple & Google Contact Tracing Protocol), который они теперь называют исключительно технологией «уведомления о возможном заражении» (Exposure Notification Technology), поскольку указанное название лучше описывает суть протокола.
 29 апреля вышла iOS 13.5 beta с первой реализацией данного протокола. Бета нацелена на тестирование разработчиками нового API и получение обратной связи. Доступ к API планируется выдавать только приложениям, официально связанным с государственными медицинскими учереждениями.
  Эта статья расскажет о том, чем вызваны изменения в протоколе, остались ли уязвимости после обновления, а также удалось ли компаниям Apple и Google ответить на критику (часто необоснованную).
 Как отмечают компании, отслеживание контактов – это хоть и необходимая, но всего лишь часть протокола.

Задача разрабатываемого решения – заранее уведомить людей, которые потенциально могут быть зараженными COVID-19, чтобы уменьшить распространение заболевания.
 Как показано на изображении, если один человек заразил несколько других, то к моменту, когда у него подтвердится COVID-19 (инкубационный период составляет до 14 дней), многие из них, скорее всего, еще не почувствуют на себе симптомы заболевания, но будут заражать других людей.

Если уведомить таких бессимптомных зараженных в момент подтверждения диагноза заразившего их человека, то мы не дадим заразиться следующему звену, значительно снизив распространение болезни.

Такой подход позволит частично отменять карантинные ограничения. Реализация этой простой идеи может быть спасением для экономик многих стран, недаром Apple и Google объединились для ее воплощения.
 Для описания остальных различий давайте сначала разберемся, как работал старый протокол и как работает новый.
 На устройство с операционной системой iOS или Android устанавливается приложение, которое через Apple & Google Contact Tracing API запускает отслеживание контактов.
 В этот момент на уровне системы происходит следующая цепочка: 
 Подробное описание вы можете увидеть в нашей прошлой статье.
 Каждый день генерируется новый случайный 16-ти байтный дневной ключ Exposure Key.
Из него генерируется ключ шифрования временных идентификаторов Rolling Proximity Key (RPIKey) и ключ шифрования метаданных Associated Encrypted Metadata Key (AEMKey):
 где: Bluetooth LE по спецификации предполагает смену MAC адреса каждые 15-20 минут, чтобы исключить возможность слежения за устройствами.

Каждый раз в момент смены MAC адреса генерируется новый временный ключ Rolling Proximity ID (RPID)
 где: Далее шифруется 4 байта метаинформации Associated Encrypted Metadata (AEM). Спецификация не объясняет, из чего формируется метаинформация. Вероятно, это сделано для расширения протокола.

Более подробно о метаинформации мы поговорим далее в статье.
 где:
AES128−CTR(Key, IV, Data) – крипто-функция AES-CTR, 128-битным ключом выступает AEMKey. Размер выходных данных соответствует размеру входных, ничем не дополняется до размера блока.

В качестве входного вектора IV используется Rolling Proximity Key.
 Далее временный идентификатор Rolling Proximity ID и зашифрованная метаинформация Associated Encrypted Metadata объединяются, и вот как выглядит BLE Payload: Такой пакет транслируется через Bluetooth Low Energy. Другие устройства, считавшие его, запоминают его локально. Репутация “Большого Брата” давно преследует компании Apple и Google. 

После анонса первой версии протокола заголовки новостей стали сообщать что Apple и Google разработали протокол отслеживания контактов. Большинство читателей, увидев только заголовок, делали вывод, что это очередная система слежения. И никакие аргументы (анонимность, локальное хранение контактов на устройстве и шифрование) уже не могли разубедить таких читателей.
 Основной приватный ключ Tracing Key, который ранее использовался для генерации дневных ключей Daily Tracing Key’s, теперь отсутствует.

В новой версии каждый Exposure Key (ранее Daily Tracing Key) генерируется случайно, т.е. между ключами даже теоретически не удастся восстановить связь. 

Такой подход также используется в протоколе DP-3T, разработанном европейским научным сообществом. Подробнее о нем вы можете прочитать в нашей предыдущей статье.
 Apple / Google таким образом отреагировали на критику, защитив протокол от 2-х типов атак: Переход к шифрованию AES вместо HMAC-SHA-256 сделан для оптимизации производительности. 

Нет проблемы генерировать раз в 10 минут свой временный ключ, но при загрузке зараженных ключей с сервера это может играть значительную роль. 

Представьте, что в какой-то день в большой стране о заражении сообщили 10K человек.

Это 140K дневных ключей или 140K*144 ~ 20М временных ключей (каждый день генерируется 144 временных ключей 24*60/10), которые нужно сгенерировать на девайсе.

Можно оптимизировать матчинг, если не генерировать все возможные временные ключи, а производить сравнение для каждого своего локально сохраненного контакта, перебирая все новые дневные ключи зараженных, соответствующие номеру дня этого контакта. Тогда, если у вас было в среднем 10 контактов в день, т.е. 140 контактов за 2 недели, то получится 140*10K=1,4M операций, что тоже очень много.

Для AES во многих современных телефонах есть аппаратное ускорение, что позволит быстрее и с меньшей энергопотерей производить матчинг контактов.
 Исправлена ошибка в выборе времени генерации временного ключа.

В первой версии спецификации говорилось о том, что временный идентификатор Rolling Proximity Identifier генерировался каждые 10 минут, в то время как MAC адрес Bluetooth LE меняется с разной периодичностью в интервале 15-20 минут. 

Таким образом, RPI и MAC менялись не синхронно, что позволяло ассоциировать по RPI новый MAC и наоборот по MAC новый RPI.

Такая ошибка позволила бы следить за перемещением пользователя, например в торговом центре, расставив Bluetooth маячки.

В новой версии смена MAC и RPI синхронизирована.

Цитата:
 Протоколы, работающие на уровне приложения, а не на уровне операционной системы, не могут синхронизировать MAC и RPI таким же образом.

Поэтому в протоколе DP-3T и OpenCovidTrace временные идентификаторы генерируются в момент обращения к Bluetooth LE сервису и недоступны для сканирования.
 Самое загадочное изменение – это появившаяся в зашифрованном виде метаинформация. В спецификации не поясняется, что может быть в этой метаинформации и кто ей владеет, давайте попробуем догадаться сами.
 Компании показали, что могут оперативно реагировать на критику и прислушиваться к ней.

Изменения в протоколе устранили ряд проблем безопасности, улучшили производительность при матчинге зараженных контактов, а также дали дополнительные возможности разработчикам приложений. Будем надеяться, что разработчики не будут злоупотреблять этими возможностями.
 Но главная проблема – недоверие IT гигантам со стороны пользователей в части приватности информации об их контактах и передвижениях – вряд ли решится только переименованием протокола.
 Мы в OpenCovidTrace уверены в том, что такие социально значимые проекты должны быть реализованы как open-source, а защита приватности данных пользователей требует проверки профессиональным сообществом.
 
Поэтому мы работаем над open-source платформой OpenCovidTrace, которая поддерживает протокол DP-3T и имплементирует протокол Apple/Google с некоторыми изменениями, обусловленными ограничениям iOS.
 Присоединяйтесь к нам на Github! 

Ваши идеи и замечания будут полезны для развития проекта, вместе мы поможем погасить новые вспышки заболевания после снятия карантина.
 Также вы можете помочь OpenCovidTrace, если поделитесь ссылкой на проект в социальных сетях. Спасибо за внимание, не болейте.