Контроль доступа на основе BLE: как обеспечивается безопасность системы?

В основе облачного контроля доступа на основе BLE лежит обмен данными между мобильным приложением и контроллером. Смартфон выступает в роли цифрового ключа (токена): приложение передает контроллеру данные, подтверждающие право пользователя на доступ, после чего система принимает решение об открытии двери или шлагбаума.

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

В AIVP обмен между приложением и BLE-контроллером защищен криптографическими алгоритмами банковского уровня:

Такой подход позволяет совместить удобное управление доступом и защиту от попыток открыть объект с помощью перехваченных или подделанных данных.

Схема авторизации между мобильным приложением и контроллером основана на протоколе v3. Она построена на криптографических алгоритмах AES-128, SHA-256 и HMAC-SHA256 и их правильном сочетании: они используются для шифрования токена доступа, формирования ключа клиента и проверки ответа приложения.

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

Модель угроз показывает, от каких сценариев атаки должна защищать система. Рассмотрим схему, где предполагается достаточно сильный нарушитель. Злоумышленник может:

В то же время злоумышленник имеет вычислительные ресурсы, реализуемые на практике — условно до 2⁸⁰ операций. Мастер-ключа и физического доступа к внутренним компонентам контроллера у атакующего нет.

В такой модели рассматриваются следующие цели атаки:

Вывод анализа. Злоумышленник не может открыть контроллер без действительной для конкретного контроллера и конкретного момента времени пары «зашифрованный токен — ключ клиента» с вероятностью выше n · 2⁻⁶⁴, где n — количество совершенных попыток.

Восстановление мастер-ключа, ключа клиента или содержимого токена по данным радиообмена потребовало бы нарушения стойкости AES-128, SHA-256 или HMAC-SHA256.

Защита системы бесконтактного доступа (по BLE) строится не на одном механизме, а на применении нескольких криптографических принципов. Каждый из них закрывает отдельный сценарий атаки: от попытки изменить права доступа до повторного использования перехваченного ответа или применения ключа на другом контроллере.

Клиентский ключ вычисляется как имитовставка (HMAC) от содержимого токена на мастер-ключе. Поэтому одновременно выполняет две функции: подтверждает целостность токена и доказывает наличие действительного права доступа. Целостность токена проверяется бесплатно.

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

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

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

Вероятность успешной подделки составляет 2⁻⁶⁴ на одну попытку. Получить более высокую вероятность успеха можно было бы только за счет эффективной атаки на HMAC-SHA256 или SHA-256. Для этих алгоритмов неизвестны методы, позволяющие выполнить такую атаку быстрее перебора ключа.

При этом клиентский ключ представляет собой полный 256-битный результат HMAC-SHA256, а не пароль или значение из ограниченного набора. Поэтому словарные и структурные атаки здесь неприменимы по строению.

Каждый запрос контроллера содержит новое случайное 64-битное значение. Подпись рассчитывается с учетом этого значения, поэтому ранее записанный ответ действителен только для конкретного запроса, на который он был сформирован.

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

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

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

Таким образом, из одного вычисления HMAC схема получает два результата по назначению и безопасности: подпись используется как публичное подтверждение владения ключом, а полный 256-битный результат остается сеансовым секретом.

Предположим, что злоумышленник все же извлек из телефона пару «зашифрованный токен — клиентский ключ». В таком случае возможности ограничены: он может открывать тот же контроллер BLE, с теми же правами и в тех же временных рамках, что и владелец ключа.

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

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

Каждый ответ раскрывает только 64 бита значения функции для выбранного входа. Восстановление 256-битного клиентского ключа в такой ситуации сводится к стандартной задаче поиска ключа для псевдослучайной функции при выбранных входных данных.

Для HMAC-SHA256 не известен способ решить эту задачу эффективнее полного перебора: число возможных ключей остается равным 2²⁵⁶.

В схеме используются только примитивы AES-128, SHA-256, HMAC-SHA256. Они стандартизированы в FIPS 197, FIPS 180-4 и RFC 2104, имеют многолетнюю публичную криптоаналитическую историю и протестированы в реализации.

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

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

В AIVP проверка цифрового ключа выполняется непосредственно BLE-контроллером. Постоянное соединение с сервером для принятия решения об открытии не требуется. Права доступа и срок действия ключа нельзя изменить из приложения, а компрометация одного ключа не дает доступа к другим контроллерам.

Это позволяет оператору подключать контроль доступа по Bluetooth как отдельную VAS-услугу: выдавать абонентам цифровые ключи, управлять их правами и сроками действия, использовать один подход для дверей, ворот, шлагбаумов и других точек доступа.

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