Разработка Bluetooth приложений на модулях фирмы Silicon Labs. Часть 2.

Автор: Сергей Безруков (aka Ser60)
Опубликовано 08.01.2020
Создано при помощи КотоРед.

Эта часть статьи посвящена вопросам безопасности Bluetooth приложений. Помимо обсуждения некоторых теоретических аспектов, нашей целью будет создание безпроводного выключателя нагрузки, защищённого от несанкционированного использования. Также будет рассказано как сделать защищённое OTA обновление ПО по воздуху авторизированной прошивкой.

Немного теории

В технологии Bluetooth имеется несколько способов обеспечения конфиденциальности соединения и предотвращения как пассивного так и активного подслушивания. Последнее также известно как атака посредника (англ. акроним MITM – Man In The Middle). Эти способы включают спаривание устройств (paring), спаривание с сохранением ключей шифрования для последующих соединений (сопряжение - bonding), аутентификация устройств, шифрование передаваемых данных, электронные подписи и др. Технология Bluetooth использует алгоритм шифрования AES-128 и определяет следующие уровни безопасности: Уровень 1 – отсутствие каких—либо мер безопасности, Уровень 2 – аутентифицированное спаривание с шифрованием методoм Just Works, Уровень 3 – аутентифицированное спаривание с шифрованием методами LE Legacy (Bluetooth 4.0 и 4.1), и Уровень 4 – аутентифицированное спаривание с шифрованием методами Bluetooth 4.2. Помимо этого, каждая характеристика Bluetooth профиля может быть сконфигурирована на уровне протокола GATT на определённые виды доступа, включая аутентифицированное чтение и запись (authenticated_read/write).

Установки безопасности в Simplicity Studio IDE включают конфигурирование менеджера безопасности стека (SM - Security Manager), разрешение/запрет сопряжения, определение уровня безопасности, и обработку событий SM. Конфигурирование SM сводится к вызову API функции cmd_sm_configure(), первый параметер которой определяет флаги SM в соответствии со следующей таблицей:

Алгоритм аутентификации устройств находится в сильной зависимости от способностей устройств в отношении ввода/вывода для отображения и ввода ключей/паролей, что устанавливается вторым параметром функции. При этом при спаривании различают устройство-инициатор соединения (И) и устройство-ответчик (О). Аутентификация устройств по отношению друг к другу заключается в показе ключа/пароля для соединения одним устройством и ввод и передача его для проверки первому на другом. При этом предполагается, что посредник (MITM) не видит показываемого устройствами пароля на их средствах вывода и поэтому не сможет предоставить его для аутентификации себя ответчику. Алгоритмы определены в соответствии со следующей таблицей, где строки соответствуют средствам ввода/вывода ответчика, а столбцы – инициатора.

Далее мы продемонстритуем работу алгоримта аутентификации на паре примеров. Касательно флагов конфигурации SM, практически они означают следующее. Установка бита 0 (MITM) предотвращает сопряжение с устройствами лишёнными средств ввода/вывода. Бит 1 означает шифрование всей коммуникации между устройствами. В частности, коммуникация между сопряжёнными устройствами будет зашифрованной. Установленный бит 2 (Bluetooth LE средства зашиты) фактически предотвращает сопряжение с устройствами, использующими старые версии Bluetooth LE (ниже 4.1). Бит 3 устанавливают при необходимости подтверждения спаривания не только на уровне стека, но и на уровне приложения, которое будет оповещено производством сопряжение генерацией события sm_confirm_bonding. Сопряжение с новыми устройствами можно разрешить или запретить вызовом функции cmd_sm_set_boundable_mode с соответствующим бинарным параметром. Обратимся теперь к применению этой теории на практике.

Приложение защищённого сервера (Secure Server)

Здесь нашей целью будет создание Bluetooth приложения с проприетарным сервисом Switch Service с единственной характеристикой Switch, нулевое значение которой соответствует разомкнутому состоянию ключа, и которое, в свою очередь, индицируется светодиодом на плате. Разработку ПО будем производить на той-же демо-плате как и для сервера в первой части статьи.

Как и ранее, начнём с конфигурации профиля, изменив имя устройства на Secure Switch, и добавив в дефолтный проект SOC – Empty сервис Switch Service с соответствующей характеристикой. Настроим в конфигурации характеристики аутентифицированный доступ к ней на запись и чтение. Это автоматически подразумевает шифрование траффика и ограничивает доступ к характеристике только сопряжённым с нашим сервером устройств методами с защитой от MITM.

Файл Server_BGM_SM.isc с настройками профиля находится в приложенном архиве. По завершению конфигурирования профиля нажимаем на Generate. Все дальнейшие изменения проекта касаются только файла app.c. Как всегда, после завершения инициализации стека мы приступаем к конфигурированию приложения в обработчике события evt_system_boot. На этот раз добавим туда код для конфигурирования SM (Secure Manager):

В строке 61 мы вызываем функцию генерирования случайного ключа (passkey) – целого 6-значного числа для сопряжения. Эта функция, определённая в конце файла, использует аппаратный генератор случайных чисел (True Random Number Generator – TRNG) на борту МК. В данном приложении используются 2 кнопки на демо-плате. Спаривание с новыми устройствами возможно только при нажатии одной из них - BUTTON0 (строки 68 – 73). Если эта кнопка не нажата при инициализации стека, то строками 64/65 разрешается соединение только со спаренными ранее устройствами. Аналогичным образом предусмотрено стирание всех прежних спариваний при нажатой по выходу из ресета кнопке BUTTON1 (строки 75 – 78). Далее в коде производится конфигурирование периода посылки оповещений с периодом 100мс (строка 79) и в следующей строке - запрос на выдачу в окно терминала МАС адресов всех сопряжённых с сервером устройств для отладки. При выдаче стеком данных очередного спаренного устройства генерируется событие evt_sm_list_bonding_entry, при обработке которого МАС адрес доступен из соответствующей структуры (строки 150 – 155). По завершении выдачи всего списка формуруется событие evt_sm_list_all_bondings_complete, в котором мы разрешаем посылку оповещений (advertisements) для соединения с нашим сервером (строка 160).

Таким, образом, для спаривания нашего сервера со смартфоном пользователя следует при нажатой кнопке BUTTON0 нажать на кнопку сброса МК на плате. В этом случае на экране терминала появится следующее сообщение:

Теперь при попытке внешнего устройства соединиться с нашим сервером стеком генерируется событие evt_em_passkey_display для показа пароля, в результате обработки которого на экране терминала появится следующее сообщение:

Это наша защита от MITM в действии. Пароль доступа к соединению случайный и разовый. Если внешнее устройство - это смартфон с клавиатурой, на нём отобразится запрос на ввод случайного пароля, показанного в окне терминала (915959). При успешном вводе пароля стеком будет сгенерировано событие evt_sm_bonded. В противном случае генерируется событие evt_sm_bonding_failed. Мы просто отображаем факт наступления этих событий в окне терминала.

По установке защищённого соединения с сервером включается светодиод LED0 на плате и смартфон получит доступ к характеристике Switch, контролирующей состояние светодиода LED1. При записи клиентом значения в эту характеристику генерируется событие evt_gatt_server_attribute_value (такое-же, как и при работе с незащищённым сервером в первой части статьи), при обработке которого мы анализируем это значение и включаем либо выключаем светодиод.

Приложение защищённого клиента (Secure Client)

Помимо управления нашим сервером со смартфона, им можно управлять и с помощью другого Bluetooth модуля. Продемонстрируем как это сделать на практике с использованием той-же платы Thunderboard Sense 2, что и для киента в первой части статьи. В нашем приложении будут задействованы её светодиоды для индикации соединения с сервером (LED0) и для индикации состояния ключа на сервере (LED1). Также задействуем 2 кнопки – BUTTON0 для стирания данных сопряжений с сервером, и BUTTON1 – для изменения состояния ключа на плате сервера. Прежде всего следует научиться реагировать на прерывания, вызванные нажатием кнопок, и передачу их Bluetooth стеку. Сконфигурируем выводы на светодиоды и кнопку BUTTON1 для прерывания по спаду уровня как показано ниже:

Здесь Button_Event – это callback функция, определённая в конце файла app.c, вызываемая драйвером прерываний GPIO, в которой мы формируем биты внешних сигналов для передачи стеку. В свою очередь стек в нужный момент сформирует событие evt_system_external_signal, в котором мы изменяем состояние светодиода на плате клиента и передаём его серверу (строка 180):

Однако, прежде чем что-то передавать, следует установить соединение с нашим безопасным сервером. Здесь мы также, как и в первой части, распознаём сервер по его МАС адресу. Отличие состоит лишь в дополнительной конфигурации менеджера безопасности SM, представленной ниже:

В этой секции мы попутно продемонстрируем работу двух методов аутентификации устройств. При первом из них (ввод пароля когда О показывает, а И вводит) строке 63 мы сообщаем стеку о наличии у клиента дисплея и клавиатуры (посредством окна терминала). Таким образом, клиент наш будет работать также, как смартфон (диалог слева), обеспечивая ввод показываемого сервером в другом окне терминала пароля (см. диалог справа):

При этом в ответ на запрос пароля сервером в приложении клиента генерируется событие evt_sm_passkey_request, где мы вводим пароль с клавиатуры компьютера и отправляем его для проверки серверу (строка 144):

Если-же закомментировать строку 63 и раскомментировать 64-ю, то тем самым стек узнает о наличии у клиента дисплея и возможности ввода только бинарной величины да/нет, например, нажатием на кнопку, или как у нас – нажатием клавиш y/n (yes/no) на клавиатуре. Согласно таблице во введении, единственный способ аутентификации при этом – это сравнение чисел. В этом случае сервер сам генерирует случайный пароль и передаёт его для показа клиенту, в ответ на запрос последнего, вызванного командой cmd_sm_inscrease_security сразу после установки соединения. До этого момента способ спаривания, основанный на сравнении чисел (паролей) работает также, как и Just Works. Однако, при нашем способе спаривания необходим один дополнительный шаг. Именно, предполагается, что пользователь сможет сравнить пароли, показанные в окне сервера и клиента и подтвердить или не подтвердить их идентичность на каждом из устройств. При этом также предполагается, что только пользователь и никто иной имеет доступ к обоим устройствам, чем и обеспечивается защита от MITM. По подтверждении идентичности паролей на одном из устройств система автоматически ожидает подтверждения на другом. При использовании этого способа спаривания следует использовать строки 65 и 71 (вместо строк 64 и 70) в конфигурации SM сервера.

Суммируя сказанное, по команде клиента smd_sm_increase_security обоими устройствами генерируется событие evt_sm_confirm_passkey, в котором мы читаем символ, введённый пользователем в окне терминала, и посылаем подтверждение другому устройству (строка 155), либо опровержение (строка 159). Аналогичный обработчик этого события должен быть включён в программу сервера (строки 169 – 183).

Таким образом, мы продемонстрировали работу всех способов соединения, показанных в таблице в теоретической части. При любом из них нажатие кнопки BUTTON1 на плате клиента вызовет изменение соединения светодиода на плате сервера. Оба устройства аутентифицируют себя по отношению друг к другу с защитой от MITM и весь поток данных между ними шифруется алгoритмом AES-128.

Защищённое обновление прошивки по воздуху (Secure OTA DFU)

Описанный выше сервер поддерживает связь только с сопряжёнными устройствами и в этом слысле автоматически защищён от неауторизированного перепрограммирования по воздуху. Однако, можно сделать ещё один шаг в плане повышения безопасности – загружать только зашифрованные пользователем прошивки. Это несложная процедура и во многом аналогичная процессу OTA обновления, описанному в первой части статьи. Bootloader в модуле уже поддерживает защищённое обновление, но начать следует с генерации ключа шифрования и записи его в модуль. Для этого используем инструмент commander, входящий в состав Simplicity Studio и для упрощения его использования добавим Path на него:

C:SiliconLabsSimplicityStudiov4developeradapter_packscommander

Далее в Windows откроем командное окно (cmd.eve) и в нём введём команду

commander gbl keygen --type ecc-p256 --outfile app-sign-key.pem

В результате получим 3 файла с ключами для электронной подписи: app-sign-key.pem (закрытый ключ для асимметричного шифрования), app-sign-key.pem.pub, и app-sign-key.pem-token.txt (открытые ключи, которые следует загрузить в модуль). Далее генерируем ключ app-encrypt-key.txt для симметричного шифрования прошивки и бутлоадера (в случае обновления последнего) командой

commander gbl keygen --type aes-ccm --outfile app-encrypt-key.txt

Для загрузки ключей в модуль (он должен быть подсоединён к компьютеру) подаём команду

commander flash --tokengroup znet --tokenfile app-encrypt-key.txt --tokenfile app-sign-key.pem-tokens.txt

Следующий шаг – электронное подписывание приложения. Для этого нужно добавить сгенерированный выше файлы app-sign-key.pem и app-encrypt-key.txt в проект и кликнуть мышкой на файл create_bl_files.bat, который дефолтно находодится в дереве проекта в Studio. При этом в фолдер output_gbl проекта добавится несколько файлов, которые следует скопировать в смартфон для производства ОТА приложением Bluetooth Smart.

Если предполагается частичное обновление (только приложение без бутлоадера – Partial OTA Update), нам понадобится лишь файл application-signed-encrypted.gbl. Его следует загрузить в смартфон в фолдер Server, созданный в первой части статьи и далее следовать процедуре обновления, описанной там. Если желательно также обновить и бутлоадер (Full OTA Update), следует скопировать в смартфон также и файл apploader-signed-encrypted.gbl и выбрать его вместе с приложением сервера в Bluetooth Smart приложении на смартфоне.

Подробнее о работе с бутлоадером и его конфигурацией можно прочитать в [1] или статьях в списке [2], включая вопросы безопасности. Однако, распространённая беда многих производителей – это отставание документации от последних обновлений средств разработки, что делает некоторые руководства не совсем верными. Я постарался представить сегодняшнее состояние дел с разработкой приложений.

Литература

1. Using the Gecko Bootloader with the Silicon Labs Bluetooth® Applications
2. Bluetooth Training

Файлы:
Архив ZIP

Все вопросы в Форум.

Эти статьи вам тоже могут пригодиться:

О работе с BLE модулем BGM111 фирмы Silicon Labs

О работе с Bluetooth модулями AMS001/002 фирмы Zentri

Прием и передача данных по bluetooth (HC-05)

Разработка Bluetooth приложений на модулях фирмы Silicon Labs. Часть III.

Разработка Bluetooth приложений на модулях фирмы Silicon Labs. Часть I.

Bluetooth по-китайски: теория и практика

Радиоуправление моделью через Bluetooth LE

Универсальный генератор с Bluetooth из готовых модулей

О работе с Bluetooth модулями семейства BL65х фирмы Laird