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 запускает отслеживание контактов.

В этот момент на уровне системы происходит следующая цепочка:

1. Генерируется случайный приватный ключ Tracing Key.
2. Из этого приватного ключа каждый день генерируется дневной ключ Daily Tracing Key как HKDF от Tracing Key ключа с номером дня.
3. Из этого дневного ключа каждые 10 минут генерируется временный Rolling Proximity ID как HMAC от Daily Tracing Key с номером временного интервала.
4. Этот временный ключ транслируется через Bluetooth Low Energy. Другие устройства, считавшие его, запоминают этот ключ локально.
5. Когда кто-то заражается, он публикует свои последние 14 дневных ключей и все другие устройства, скачав эти 14 ключей, генерируют Rolling Proximity ID’s за все эти 14 дней и ищут их у себя локально.
6. Если ключ нашелся, то у вас был контакт с зараженным.

Подробное описание вы можете увидеть в нашей прошлой статье.

Схема работы нового протокола

1. Каждый день генерируется новый случайный 16-ти байтный дневной ключ Exposure Key.
   Из него генерируется ключ шифрования временных идентификаторов Rolling Proximity Key (RPIKey) и ключ шифрования метаданных Associated Encrypted Metadata Key (AEMKey):
   

   
   

   RPIKey = HKDF(ExpKey, NULL, UTF8("EN-RPIK"),16)

   
   

   AEMKey = HKDF(ExpKey, NULL, UTF8("EN-AEMK"),16)

   
   

   где:

   
   
   • HKDF – обозначает крипто-функцию генерации ключа HKDF(Key, Salt, Info, OutputLength) описанную в RFC 5869, использующую в качестве хеша SHA-256
   • NULL – это соль, которая не используется
     UTF8("EN-RPIK") – массив байт, соответствующий строке EN-RPIK в кодировке UTF8
     
   
   

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

   
   

   RPID = AES128(RPIKey, UTF8("EN-RPI") || 0x000000000000 || Ti)

   
   

   где:

   
   
   • AES128(Key, Data) – обозначает крипто-функцию AES с 128-битным ключом. Длина укладывается ровно в один 128-битный блок
   • RPIKey – Rolling Proximity Key сгенерированный на первом шаге
   • || – символ, обозначающий конкатенацию следующих данных:
     
     • UTF8("EN-RPI") – массив из 6 байт, соответствующий строке EN-RPI в кодировке UTF8
     • 0x000000000000 – 6 нулевых байт (чтобы в сумме получить 128-ми битный блок)
     • Ti – 4-х байтный номер 10-ти минутного временного интервала, вычисляемый как unix_timestamp div (60 * 10), где div – операция целочисленного деления
   
   

   Далее шифруется 4 байта метаинформации Associated Encrypted Metadata (AEM). Спецификация не объясняет, из чего формируется метаинформация. Вероятно, это сделано для расширения протокола.
   
   Более подробно о метаинформации мы поговорим далее в статье.
   

   
   

   AEM = AES128?CTR(AEMKey, RPID,  Metadata)
   

   
   

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

   
   

   Далее временный идентификатор Rolling Proximity ID и зашифрованная метаинформация Associated Encrypted Metadata объединяются, и вот как выглядит BLE Payload:

   
   
   
   
   

   Такой пакет транслируется через Bluetooth Low Energy. Другие устройства, считавшие его, запоминают его локально.

2. Когда кто-то заражается, он публикует свои последние 14 дневных ключей. Все другие устройства, скачав эти 14 ключей, генерируют Rolling Proximity ID’s за все эти 14 дней и ищут их у себя локально.
   

Что изменилось и почему

Название

Репутация “Большого Брата” давно преследует компании Apple и Google.

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

Отсутствует основной ключ

Основной приватный ключ Tracing Key, который ранее использовался для генерации дневных ключей Daily Tracing Key’s, теперь отсутствует.

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

Такой подход также используется в протоколе DP-3T, разработанном европейским научным сообществом. Подробнее о нем вы можете прочитать в нашей предыдущей статье.

Apple / Google таким образом отреагировали на критику, защитив протокол от 2-х типов атак:

• Если злоумышленник сможет найти старый бэкап телефона, то он может извлечь Tracing Key. Этого будет достаточно, чтобы начать генерировать свежие дневные ключи и транслировать якобы ваши новые контакты.
• Если после заражения и публикации Daily Tracing Key атакующий сможет определить связанные ключи или даже подобрать Tracing Key, обладая большими вычислительными ресурсами и временем, тогда он также сможет при наличии заранее расставленных BLE маячков понять перемещения зараженных или подделать новые контакты (в случае вычисления Tracing Key).

AES вместо HMAC-SHA-256

Переход к шифрованию AES вместо HMAC-SHA-256 сделан для оптимизации производительности.

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

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

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

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

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

Синхронизация смены MAC и RPI

Исправлена ошибка в выборе времени генерации временного ключа.

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

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

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

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

Цитата:

The key schedule is fixed and defined by operating system components, preventing applications from including static or predictable information that could be used for tracking.

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

Поэтому в протоколе DP-3T и OpenCovidTrace временные идентификаторы генерируются в момент обращения к Bluetooth LE сервису и недоступны для сканирования.

Associated Metadata

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

• Во-первых, она генерируется и шифруется на нашем девайсе раз в 15-20 минут, ее размер всего 4 байта.
  
  Это может быть: 1) информация о нашем девайсе, 2) времени, 3) местоположении (неточном, т.к. всего 4 байта), 4) таймзоне, 5) выпустившей приложение организации, 6) возможно, ID, который присвоен вам организацией, выпустившей приложение.
  
• Во-вторых, она передается всем устройствам поблизости (в зашифрованном виде) и больше никто этой информацией не владеет, а при заражении эта информация на сервер не передается.
  
  Таким образом, информацией владеют только устройства, с которыми у вас были контакты. Логично предположить, что эта информация, которой ваш контакт не обладает, т.е. вряд ли это время или местоположение (хотя эти данные не используются протоколом, и разработчик может использовать их как расширение). Это, скорее всего, дополнительная информация о вас.
  
• В третьих, эта информация может быть расшифрована только в момент, когда один из участников заразился и опубликовал свой дневной ключ, из которого можно сгенерировать ключ и инициализационный вектор для расшифровки этой информации.
  
  Следовательно, эта информация имеет значение только при заражении.
  

• Код модели телефона или мощность Bluetooth передатчика, необходимые для оценки расстояния.
• Код приложения или организации/страны, выпустившей приложение, чтобы понять, кто подтверждал диагноз.
• Или же, что хуже всего, это может быть внутренний ID, который позволит разработчикам приложений делать их не анонимными вопреки тому, как это изначально было задекларировано протоколом. Разработчик в своей базе данных может связывать записи о конкретном пользователе приложения с анонимными идентификаторами, использующимися протоколом, через ID в метаданных.
  
  При получении сообщения о заражении можно будет узнать ID заразившего вас пользователя и запросить информацию о нем.
  

Выводы

Компании показали, что могут оперативно реагировать на критику и прислушиваться к ней.

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

Но главная проблема – недоверие IT гигантам со стороны пользователей в части приватности информации об их контактах и передвижениях – вряд ли решится только переименованием протокола.

Мы в OpenCovidTrace уверены в том, что такие социально значимые проекты должны быть реализованы как open-source, а защита приватности данных пользователей требует проверки профессиональным сообществом.

Поэтому мы работаем над open-source платформой OpenCovidTrace, которая поддерживает протокол DP-3T и имплементирует протокол Apple/Google с некоторыми изменениями, обусловленными ограничениям iOS.

Присоединяйтесь к нам на Github!

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

Также вы можете помочь OpenCovidTrace, если поделитесь ссылкой на проект в социальных сетях.

Спасибо за внимание, не болейте.

Ссылки

• Документация протокола Apple & Google
• Cайт нашего open-source проектта
• Cайт нашего репозитория на Github
• Github репозиторий протокола DP-3T, разработанного европейским научным сообществом