Шифрование и защита данных с низким энергопотреблением Bluetooth

Мне нужно отправить некоторые конфиденциальные данные через соединение Bluetooth с низким энергопотреблением (BLE) между смартфоном (iOS и Android) и встроенным устройством (чип CC2540).

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

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

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

  • Мне нужно, чтобы каждое устройство было сопряжено с несколькими телефонами (но только для связи по одному за раз). Какое максимальное количество спаев pr. устройство? - К сожалению, мне нужно подключить довольно большое количество телефонов к моим устройствам.

  • Могу ли я получить данные о спаривании (долгосрочные ключи и т.д.) с устройства и сохранить его в некоторой внешней памяти, чтобы увеличить этот предел.

  • Можно ли безопасно подключить данные к устройству без сопряжения или, может быть, путем повторного спаривания, когда мне это нужно? - Насколько безопасна эта процедура в отношении атак MITM?

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

ОТВЕТЫ

Ответ 1

здесь мои два цента:

  • Процесс AFAIK, BLE/шифрование не является ошибочным. Существуют три уровня защиты MITM, доступных с шифрованием:

    • Нет, это использует известный ключ == 0, поэтому, если eavesdropper ловит все ваши пакеты в процессе сопряжения, он может следить за вашим зашифрованным соединением.
    • Низкая защита MITM, это когда вы используете ключ доступа пользователя для сопряжения с ключом < 1.000.000. Здесь подслушивателю нужно было всего лишь попробовать миллион ключей.
    • Высокая защита MITM, используя внеполосный ключ. Это обеспечило бы полную 128-битную силу для вашего шифрования, и подслушивающее устройство должно было бы знать ключ, чтобы следить за разговором, даже если поймать весь процесс сопряжения. Поскольку в BLE нет метода обмена ключами (хотя бы, по крайней мере), самой слабой точкой здесь будет распределение ключей, но это будет та же проблема, что и при наличии дополнительного уровня шифрования на уровне приложения.

  • Это зависит от реализации. Ваше устройство не должно связываться, т.е. Устанавливать постоянные отношения с хостом. Если устройства не связаны, то не сообщается о более ранних соединениях (кроме обменных данных, но это домен приложения, а не стек BLE). Если устройства не связаны, они должны будут снова соединиться при следующем подключении к обмену защищенными данными. Если устройства связаны, зашифрованное соединение может быть продолжено без взаимодействия с пользователем/пользователем с тем же уровнем безопасности, что и ранее. Для устройств с одним подключением связь не имеет смысла, поэтому вы можете иметь безгосударственную реализацию без ограничений на количество подключенных устройств. Для многократного подключения вы также можете иметь реализацию без состояния, в зависимости от того, как вы распространяете/сохраняете ключ (ы), который затем не зависит от BLE. Доступность различных опций здесь зависит от используемой вами реализации стека устройства /BLE, но спецификация позволяет все это.

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

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

Ответ 2

Я возьму удар по этому.

1) Мое понимание процесса сопряжения одно и то же. Если бы данные были достаточно чувствительными, я бы добавил независимый уровень собственного шифрования в своем приложении...

2) Для соединений протокол BLE ограничен одним хостом на устройство одновременно, даже если соединение не связано/сопряжено. Единственный способ для одного устройства установить соединение с несколькими хостами одновременно - это то, что устройство каким-то образом "претендует" на несколько устройств. Независимо от того, может ли это быть сделано, это зависит от оборудования, и это определенно не является одним из стандартных способов использования устройства. Даже если вы можете обмануть аппаратное обеспечение в этом, вы можете столкнуться с неизбежными проблемами, такими как появление (почти) перекрывающихся интервалов подключения, что может привести к потере данных и, в конечном итоге, даже к установленным соединениям.

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

См. также раздел 4.1.2 в томе 1, часть A спецификации bluetooth "Core_V4.0" (например, здесь https://www.bluetooth.org/docman/handlers/downloaddoc.ashx?doc_id=229737)

3) Скорее всего, да, детали будут отличаться от поставщика, но с ограничениями, упомянутыми выше.

4) Вы можете установить соединение без склеивания/спаривания. Это соединение позволит общаться, но он будет открытым текстом без какой-либо безопасности. AFAICS, единственный способ сделать это правильно - использовать собственную защиту данных на уровне приложений.

Ответ 3

Я предполагаю, что устройство CC2450 использует стек TI. Хорошая документация по поведению стека CC2540 находится в CC2540 Development Kit User Guide. Вероятно, это лучшая документация после спецификаций 4.0 из bluetooth.org

  • 6-значный PIN-код, используемый в процессах обработки парирования, против MITM - есть 30-секундное окно для ввода PIN-кода.

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

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

  • У вас не будет зашифрованной характеристики чтения/записи без склеивания. Обратитесь к 4.6.1 руководства пользователя TI - в соответствии со спецификациями Bluetooth 4.0.