10 апреля 2020 года компании Apple и Google анонсировали, что в следующих обновлениях их операционных систем iOS и Android появится поддержка совместно разработанного протокола отслеживания контактов.
Целью данного проекта является снижение распространения коронавируса с помощью отслеживания цепочек контактов и раннего обнаружения новых заразившихся с последующей быстрой изоляцией.
Для отслеживания контактов будет использоваться технология BLE (Bluetooth Low Energy).
Принцип работы данного протокола отслеживания контактов следующий:
На телефонах с операционной системой iOS или Android запускается BLE-сервис со специальными service UUID и characteristic UUID.
Работает это так же, как с вашими Bluetooth наушниками или гарнитурой, которые используют Bluetooth-сервис со стандартным задающим класс гарнитур кодом (characteristic UUID), только в данном случае это особый код, определяющий протокол отслеживания контактов Apple & Google. Потребление энергии в таком режиме небольшое.
Телефоны периодически ищут по Bluetooth другие устройства с фиксированными service UUID и characteristic UUID и если находят, то понимают, что произошел контакт.
Задача протокола — передать анонимные идентификаторы устройств друг другу при таком контакте, и если в дальнейшем кто-то заразится, сообщить всем контактам об этом.
Первый опыт тестирования в Сингапуре
Подобная технология отслеживания контактов через Bluetooth уже была запущена в Сингапуре.
Приложение Trace Together было запущено правительством Сингапура в марте 2020 года и быстро дало результат.
Всемирная организация здравоохранения и эксперты заявили, что широкие меры по отслеживанию, тестированию и изоляции помогли значительно сократить распространение вируса, снизив за две недели число новых заражений с 909 случаев, объявленных 29 февраля, до 74 случаев 16 марта.
Сейчас приложение установлено более чем на 1 миллион устройств, а технологию, на которой работает приложение BlueTrace, выложили в open-source.
Описание протокола Apple & Google
Протокол Apple & Google, в отличие от BlueTrace, разрабатывался с учетом повышенных требований безопасности и приватности.
Он не требует авторизации по номеру телефона или email, информация о зараженных пользователях передается анонимно.
Для исключения отслеживания устройств используются временные идентификаторы, период существования которых не превышает 10 минут.
Так как же работает протокол?
- Девайс случайным образом генерирует приватный 32-х байтный ключ Tracing Key, который всегда остается на девайсе
- Каждый день генерируется дневной 16-ти байтный ключ Daily Tracing Key.
Для его генерации используется функция HKDF:
dk = HKDF(tk , NULL, (UTF8("CT-DTK")||Di),16)
tk— это приватный ключ,
Di— номер дня, который вычисляется какunix_timestamp div (60*60*24), гдеdiv— операция целочисленного деления
а символ||обозначает конкатенацию
NULL в данном случае это соль, которая не используется, а 16 — количество байт на выходе.
Эти ключи в дальнейшем передаются на сервер, если пользователь заразился.
Каждые 10 минут * генерируется временный идентификатор Rolling Proximity ID.
Его длина также составляет 16 байт.
Эти идентификаторы используются для обмена между устройствами при контакте.
Для генерации используется функция HMAC (первые 16 байт), в качестве аргумента используется дневной ключ, объединенный с номером временного интервала:
RPI = Truncate(HMAC(dk, (UTF8("CT-RPI")||Ti)),16)
Гдеdk— это дневной ключ,
Ti— номер временного интервала, который вычисляется как
(unix_timestamp mod (60*60*24)) div (60*10), гдеdiv— операция целочисленного деления, аmod— остаток от деления
*Идентификатор меняется каждые 10 минут согласно криптографической спецификации протокола:
TimeIntervalNumber provides a number for each 10-minute window in a 24-hour window as defined by DayNumber)
Но в bluetooth спецификации указан 15-20 минутный интервал смены мак адреса, что потенциально может означать несинхронную смену.
- При контакте устройства локально запоминают RPI (Rolling Proximity ID) друг друга и время, в которое произошел контакт.
При заражении пользователь загружает последние 14 дневных ключей на сервер, откуда другие устройства периодически скачивают новые ключи.
Скачав новый ключ, телефон сверяет со своими локально сохраненными контактами, вычислив для каждого контакта RPI и сравнив его с сохраненным RPI.
Если находится соответствие, то пользователь получает уведомление о контакте с зараженным.
К моменту публикации статьи компании Apple и Google анонсировали новую версию спецификации Contact Tracing Protocol, где изменили принцип генерации ежедневных ключей и Rolling Proximity ID. Вероятно, это было сделано из-за того, что в данной версии протокола есть возможность отследить заразившегося пользователя в последние 14 дней перед публикацией его ключей.
Подробный разбор отличий мы сделаем в следующей статье.
Как планируется использовать протокол
Вместе с описанием протокола компании Apple и Google объявили, что протокол будет реализован на уровне операционных систем, а разработчики получат лишь доступ к API.
Приложение сможет запросить доступ у пользователя к Contact Tracing Framework.
Операционная система сама будет генерировать приватный и дневные ключи, а также временные идентификаторы. Bluetooth сервис также включится на уровне системы.
Приложение же получит доступ к статусу пользователя, и если у пользователя был контакт с зараженным, то статус поменяется на «exposed».
В таком случае приложение может запросить дополнительную информации о контакте: дату и продолжительность.
В API также есть возможность сообщить, что пользователь заразился COVID-19, но такое сообщение должно быть подписано медицинским центром, который должен быть авторизован Apple & Google для таких операций.
Приложение должно передать медицинскому центру свои дневные ключи за последние 14 дней, получить цифровую подпись и отправить ее в API.
Отсюда возникает ряд вопросов:
Какие медицинские учреждения смогут получить доступ подписи таких диагнозов?
Кто будет сертифицировать медицинские центры для таких операций?
Уже сейчас Apple App Store и Google Play Market ограничили публикацию приложений, имеющих отношение к COVID-19, пропускаются только приложения от медицинских и государственных учреждений. Возможно, планируется выдавать ключи для подписи диагнозов таким разработчикам при публикации приложений, использующих Contact Tracing Framework.
Выводы
Анонсированный Apple и Google протокол еще раз доказывает актуальность проблемы отслеживания контактов для борьбы с инфекционными заболеваниями, в частности с COVID-19.
Сложно вспомнить другую ситуацию, когда два конкурирующих IT-гиганта могли бы так быстро договориться о протоколе и выпустить совместный релиз.
Приложение Trace Together набрало более 1 миллиона пользователей за несколько месяцев, но это несравнимо меньше с потенциальным охватом Apple и Google в несколько миллиардов устройств.
Такой охват делает данный протокол потенциально очень интересным для медицинских и государственных организаций по всему миру.
Централизованная база данных заболевших пользователей и покрытие по всему миру решает проблему международного взаимодействия, что является как и огромным преимуществом так и недостатком этой технологии.
Не все государственные организации готовы доверять данные своих пользователей Apple и Google, не имея их в собственном распоряжении.
Кроме этого, реализация данного протокола на уровне операционной системы не может быть проверена сообществом, таким образом нельзя быть на 100% уверенными, что приватный ключ не передается 3-м лицам.
Open-source
В силу социальной значимости и защиты приватности данных пользователей требуется open-source имплементация протокола Apple & Google, которая будет проверена профессиональным сообществом и доступна всем желающим по open-source лицензии.
Поэтому мы работаем над open-source платформой OpenCovidTrace, в которой реализован протокол, описанный Apple & Google, с некоторыми улучшениями и изменениями, обусловленными ограничениями iOS.
Ограничения iOS
Обмен контактами, описанный в протоколе Apple & Google, происходит пассивно.
Временные идентификаторы записаны в пакеты объявления ( advertising packets) BLE сервиса, для чего размер этих идентификаторов уменьшен до 16 байт.
Два находящиеся рядом устройства видят BLE сервисы друг друга с соответствующим UUID и читают идентификаторы из advertising info (характеристики) BLE сервиса.
Ограничения фреймворка Core Bluetooth в iOS не дают возможности приложениям, работающим в бэкграунде, получить характеристики BLE сервисов.
Поэтому в нашей имплементации протокола устройства создают два BLE сервиса: один используется для поиска устройств, а другой для подключения и получения временного идентификатора устройства.
Мы рассчитываем, что в следующем обновлении iOS компания Apple уберет данное ограничение Core Bluetooth для своей реализации протокола обмена контактами.
В противном случае, если ограничение будет снято только для реализации протокола Apple & Google, но останется на уровне приложения, Apple поставит других разработчиков в неравное положение, что может быть расценено как недобросовестная конкуренция.
Улучшения протокола
Представьте, что вы находитесь в машине на парковке рядом с другим автомобилем или находитесь в соседнем кабинете с другим пользователем.
Ваши телефоны фиксируют контакт. Если кто-то из вас заболеет, то будет определен ложно-положительный контакт с зараженным.
Количество таких контактов потенциально большое в определенных местах, поэтому для оценки риска заражения важно знать координаты заражения.
По протоколу Apple & Google фиксируются только время и дистанция.
В нашей реализации, если контакт был на дороге, а вы передвигаетесь на машине, вы просто отмечаете этот контакт безопасным в отличие от опасного контакта в публичном месте.
Geo-позиция контактов за прошлые 14 дней и Rolling Proximity ID’s контактов хранятся локально, они доступны только вам, поэтому это никак не нарушает вашу приватность.
Заразившийся пользователь кроме Rolling Proximity ID’s контактов может загрузить и свои GPS треки за последние 14 дней.
Эти треки зараженных пользователей будут доступны другим пользователям на карте, анонимно без привязки к устройству или другим данным по контактам.
Дополнительно мы предлагаем фиксацию контактов между пользователями по QR-коду, если Bluetooth недоступен.
Объединение технологий
OpenCovidTrace также ставит задачу объединить различные протоколы отслеживания контактов, включая упомянутый ранее BlueTrace, Apple & Google, а также описанный европейским научным сообществом протокол DP-3T, о котором мы расскажем в следующих статьях.
Присоединяйтесь к нам на Github!
Ваши идеи и замечания будут полезны для развития проекта, вместе мы поможем погасить новые вспышки заболевания после снятия карантина.
Также вы можете помочь OpenCovidTrace, если поделитесь ссылкой на проект в социальных сетях.
Спасибо за внимание, не болейте.
Ссылки
https://www.apple.com/covid19/contacttracing — документация протокола Apple & Google
https://www.tracetogether.gov.sg/ — сайт запущенного в сингапуре приложения Trace Together
https://bluetrace.io/ — сайт технологии на которой базируется Trace Together
https://opencovidtrace.org — сайт нашего open-source проектта
https://github.com/OpenCovidTrace — сайт нашего репозитория на Github
https://github.com/DP-3T/ — еще один перспективный протокол обмена контактами
