Шифрование данных iBeacon (режим рекламы)

Question

Моя цель - зашифровать данные iBeacon (UUID + MajorID + MinorID: 20 байт), предпочтительно с включенной временной отметкой (зашифрованной и простой), суммируя ее примерно до 31/32 байт. Как вы уже выяснили, это превышает максимально допустимые данные iBeacon (31 байт, включая префикс iBeacon и tx power). Таким образом, шифрование работает только путем создания пользовательского формата маяка вместо формата iBeacon? Говоря о шифровании: я бы подумал об использовании симметричного шифра с использованием режима работы CBC (чтобы избежать расшифровки из-за повторения, и, самое главное, чтобы избежать коррекции текста шифрования, что привело к изменению UUID, Major-/MinorID). Это не проблема, чтобы сделать IV (Инициализационный вектор) общедоступным (незашифрованным), правильно? Помните, что iBeacons работают в режиме рекламы (только для передачи), без предварительной связи, поэтому я не могу обменять вектор инициализации (IV) до отправки каких-либо данных. Какие соображения должны быть сделаны с использованием наиболее подходящего алгоритма шифрования? Является ли AES-128 ОК? С или без прокладки-схемы? Я также подумал о созвездии AES-GCM, но я этого не делаю, это действительно необходимо/применимо из-за используемого режима рекламы. Как я могу обменять токены сеанса? Более того, в моем случае нет реальной сессии, iBeacons отправляют данные 24/7, открытый конец, без реальной инициализации соединения. Предположим, что система содержит 100 iBeacons, 20 устройств и 1 приложение. Каждый iBeacon периодически отправляет данные (то есть 500 мс), которые принимаются ближними устройствами через BLE, которые отправляют данные в приложение через udp. Таким образом, обзор системы соотношение:

п iBeacons - (BLE) - K устройства - (UDP) - 1 Применение

Допустимо использовать один и тот же ключ шифрования на каждом IBeacon? Если бы я работал с кортежем (ключ iBeacon Id/encryption key), мне дополнительно пришлось бы добавить идентификатор iBeacon в каждый пакет, тем самым имея возможность искать ключ в словаре. Должны ли данные быть дешифрованы на устройстве или только позже в приложении?

Answer 1

Вы можете посмотреть на Eddystone-EID spec, чтобы узнать, как Google попытался решить подобную проблему.

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

Ответы на них: у вас нет. Они решают эту проблему, обрезая зашифрованную полезную нагрузку, чтобы сделать хэш, а затем используя онлайн-сервис, чтобы «разрешить» этот хэш и посмотреть, соответствует ли он любому из ваших маяков. Онлайн-сервис просто выполняет один и тот же алгоритм хэширования против каждого зарегистрированного маяка и видит, имеет ли он такое же значение для периода времени. Если это так, он может преобразовать зашифрованный хэш-идентификатор в полезный.

Прежде, чем зайти слишком далеко с этим подходом, обязательно подумайте о точке @ Paulw11, что на устройствах iOS вы можете знать, что 16-байтовый iBeacon UUID спереди или операционная система блокирует вас от чтения остальной части пакета. По этой причине вам может потребоваться придерживаться платформы Android, если вы используете iBeacon, или переключитесь на аналогичный формат AltBeacon, который не имеет этого ограничения для iOS.

Answer 2

спасибо за отличный пост, я раньше не слышал о спецификации Eddystone, это действительно что-то, что нужно изучить, и оно имеет максимальную длину полезной нагрузки в 31 байт, как и iBeacon. В статье написано, что в общем случае это шифрование значения временной метки (с предопределенной эпохи). Правильно ли я выполнил этапы обработки?

1. Определите секретные ключи (EIK) для каждого маяка и передайте эти ключи другому распознавателю или серверу (если есть созвездие без онлайн-ресурса);
2. Создайте таблицы поиска на сервере с PRF (например, AES CTR);
3. Шифровать временную метку на маяке с PRF (то есть AES CTR?) И отправлять данные в формате Eddystone в resolver/server;
4. Сервер сравнивает полученный зашифрованный текст с записями в таблице поиска, таким образом, знает идентификатор маяка, поскольку каждый маяк имеет уникальный секретный ключ, что приводит к другому зашифрованному тексту
5. Будет ли он работать с AES-EAX? Все, что мне нужно включить в алгоритм, это значение IV (значение nonce), а также ключ и сообщение? Другой конец будет строить один и тот же кортеж для сравнения зашифрованного текста и тега '?

Вопрос: Как насчет IRK (ключ разрешения идентификации), что это такое? Какой nonce будет использоваться для ATR CTR? Будет ли каждый маяк использовать тот же самый nonce? Это должно быть известно и для преобразователя/сервера. Как насчет синхронизации времени? Между маяком и резольвером/сервером нет реальной связи, но предполагается ли, что оба конца синхронизированы с одним и тем же сервером времени? Или как beacon и resolver/server получат один и тот же шифротекст, если один конец работает в 2011 году, а резольвер - в 2017 году?