Decentralized Privacy-Preserving Proximity Tracing (DP-3T) — еще один протокол отслеживания цепочек контактов с помощью Bluetooth для предотвращения распространения коронавируса SARS-CoV-2.

Протокол разработан международным научным сообществом и анонсирован в начале апреля, на две недели раньше протокола Apple & Google, но детальная спецификация и исходный код появились только недавно. Правительства Швейцарии, Австрии и Эстонии объявили, что будут использовать SDK DP-3T для отслеживания контактов в своих приложениях.

Изначально проект вступил в инициативу PEPP-PT (Pan-European Privacy-Preserving Proximity Tracing).

Впоследствии у DP-3T возникли разногласия с подходом PEPP-PT из-за централизованного подхода и они вышли из этой инициативы.

Если вы еще не знакомы с протоколом Apple & Google, то можете посмотреть нашу статью об этом протоколе. В целом принцип отслеживания контактов через Bluetooth такой:

На телефонах с операционной системой iOS или Android запускается BLE-сервис со специальными service UUID и characteristic UUID.

Работает это так же, как с вашими Bluetooth наушниками или гарнитурой, которые используют Bluetooth-сервис со стандартным задающим класс гарнитур кодом (characteristic UUID), только в данном случае это особый код, определяющий протокол отслеживания контактов Apple & Google. Потребление энергии в таком режиме небольшое.

Телефоны периодически ищут по Bluetooth другие устройства с фиксированными service UUID и characteristic UUID, и если находят, то понимают, что произошел контакт.

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

Итак, какие различия между Apple & Google и DP-3T?

Описание протокола DP-3T

Сам протокол DP-3T очень похож на протокол Apple & Google:

• Приложение генерирует секретный 32-х байтный ключ, который всегда остается на девайсе
• Каждый день приложение генерирует новый дневной ключ как SHA256 хэш от предыдущего дневного ключа (или от секретного ключа для первого дня).
  Эти ключи в дальнейшем передаются на сервер, если пользователь заразился.
  

• Вместе с дневным ключом приложение генерирует временные ID EphID’s (ephemeral ID, в терминологии Apple & Google — Rolling Proximity ID). Это 24*60 временных ID на каждую минуту дня, которые используются для обмена контактами.
  
  

  
  
  
  

  То есть если вы находитесь рядом с телефоном с таким BLE сервисом, то он видит один из 1440 ваших EphID’s, которые меняются каждую минуту, чтобы вас было невозможно по ним отследить.
  
  Эти идентификаторы генерируются с помощью дневного ключа. Таким образом, получив дневной ключ, вы можете сгенерировать все EphID’s аналогично протоколу Apple & Google.
  

  
  

  Для генерации EphID’s протокол использует массив 16*24*60 нулевых байт, и шифрует его AES CTR с ключем HMAC (“broadcast key” || Daily Key)
  Где “broadcast key” — это соль, Daily Key — дневной ключ для текущего дня, а символом || обозначена конкатенация. После генерации ключи перемешиваются.
  

  
  
• При контакте устройства запоминают EphID’s друг друга и значение RSSI, по которому вычисляется расстояние между устройствами.
  
• При заражении пользователь загружает последние 14 дневных ключей на сервер, откуда другие устройства периодически скачивают новые ключи.
  Скачав новый ключ, телефон генерирует все 24*60 соответствующих ему EphID’s и сверяет их со своими локально сохраненными контактами.
  Если находится соответствие, то пользователь получает уведомление о контакте с зараженным.
  

Различия между протоколами

Как видно из описания выше, протоколы похожи, давайте сравним их на каждом шаге:

• В обоих протоколах есть секретный ключ, который не передается на сервер, размером 32 байта, чего достаточно, чтобы исключить случайное совпадение или подбор.
  
• В обоих протоколах есть дневные ключи, которые являются производной секретного ключа и используются для передачи на сервер в случае заражения, то есть узнать заранее дневные ключи другого устройства невозможно.
  
  В отличие от Apple & Google, где дневной ключ имеет размер 16 байт и
  генерируется функцией HKDF из секретного ключа дополненного номером дня, в DP-3T используется 32 байтный ключ, SHA-256 хэш от предыдущего дневного ключа (или от секретного ключа для первого дня).
  
  Данное различие, на наш взгляд, не принципиально, Apple & Google вероятно сознательно уменьшили размер ключа, чтобы сократить трафик при загрузке зараженных ключей.
• Есть временные идентификаторы размером 16 байт (из-за ограничений BLE), которые являются производными от дневных ключей и используются для обмена при контактах. В обоих протоколах они меняются достаточно часто, чтобы исключить отслеживание пользователя, но есть различие в принципе их генерации и ротации.
  
  В протоколе Apple & Google идентификаторы меняются раз в 10 минут, а у DP-3T раз в минуту, но следуют не по порядку и без привязки к временному интервалу, в отличие от Apple & Google, что потенциально позволяет злоумышленнику использовать идентификаторы для ретрансляции ложных контактов в течение всего дня.
  
• Обмен контактами, описанный в протоколе Apple & Google, происходит пассивно. Временные идентификаторы записаны в характеристике BLE сервиса, для чего размер идентификаторов уменьшен до 16 байт.
  
  Два находящиеся рядом устройства видят BLE сервисы друг друга и считывают из их характеристики идентификатор.
  
  Но ограничения Core Bluetooth в iOS не дают возможности приложениям, работающим в бэкграунде, получить характеристики BLE сервисов при сканировании, поэтому в протоколе DP-3T iOS устройства подключаются к сервису для получения идентификатора.
  
  Apple объявил, что протокол обмена контактами Apple & Google будет работать в следующем обновлении iOS, и это может означать, что Apple собирается убрать данное ограничение Core Bluetooth для поддержки протокола.
  
  В противном случае, если ограничение будет снято только для реализации протокола Apple & Google и останется на уровне приложения, Apple поставит других разработчиков в неравное положение. Это может быть расценено как недобросовестная конкуренция.
  

К моменту публикации статьи компании Apple и Google анонсировали новую версию спецификации Contact Tracing Protocol.

В новом протоколе они стали использовать AES для оптимизации вычислений при генерации временных ключей, так же как и в DP-3T.

Подробный разбор отличий мы сделаем в следующей статье.

Различие в реализации

Главное различие, конечно же, в том, что DP-3T реализовано как open-source решение.
В данный момент в репозитории DP-3T на Github доступно SDK для iOS и Android, а также демонстрационное приложение и open-source backend.

Различие в бэкенде

DP-3T предлагает также open-source реализацию сервера, который используется для загрузки зараженных дневных ключей.
Архитектура протокола DP-3T подразумевает децентрализацию, т.е. может существовать много различных приложений, работающих на протоколе DP-3T, использующих различные бэкенды.

Контакты между различными приложениями DP-3T будут работать, но чтобы своевременно узнавать о новых зараженных, требуется обмениваться такими зараженными ключами между серверами, в то время как все приложения, использующие Apple & Google протокол, будут связаны с единой базой зараженных ключей.

Сравнение безопасности

Атака на систему через дневные ключи

Наиболее вероятный вектор атаки на систему через дневной ключ возможен как трансляция временных ID, соответствующих уже зараженным дневным ключам.

Злоумышленник скачивает зараженный дневной ключ, генерирует по нему EphID’s и рассылает их по Bluetooth.

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

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

В этом плане решение Apple & Google может быть надежнее, так как их имплементация будет на уровне системы, где прямой доступ к дневным ключам зараженных пользователей не предполагается.

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

Возможный вектор атаки на систему через временный ключ

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

В этом плане Apple & Google решение может быть надежнее, так как их временный ключ привязан к конкретном временному интервалу (10 минут).

При заражении временный ключ сверяется вместе с проверкой временного интервала, а в случае с DP-3T все временные ключи действуют в течение суток.

Выводы

DP-3T — хорошая и нужная альтернатива решению Apple & Google благодаря open-source имплементации и децентрализованной структуре.

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

Но все ли государственные организации готовы доверять Apple и Google? Кажется, что нет.
Например в России хранение дневных ключей зараженных пользователей должно осуществляться на российских серверах, что вряд ли будет возможно в решении Apple & Google.

Также не ясно, насколько анонимными будут контакты, ведь секретный ключ пользователя может быть ассоциирован с id устройства.

В то же время любая организация может создать свой сервер и приложение на базе протокола DP-3T безопасно и быстро, но какое будет покрытие у такого решения?

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

Поэтому мы работаем над open-source платформой OpenCovidTrace, объединяющей протоколы отслеживания контактов.

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

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

В следующей статье мы разберем изменения спецификации Apple/Google v1.1

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