Как добавить шифрование на уровне приложения к BLE-соединению Android?
Android Bluetooth Low Energy документация рекомендует добавлять шифрование на уровне приложения-верхней части BLE связи , если обмен данными чувствителен:
Внимание : когда пользователь связывает свое устройство с другим устройством с помощью BLE, данные, передаваемые между двумя устройствами, становятся доступными для всех приложений на устройстве пользователя.
По этой причине, если ваше приложение захватывает конфиденциальные данные, вам следует реализовать безопасность на уровне приложения, чтобы защитить конфиденциальность этих данных.
Поскольку я хотел бы избежать «накатывания собственного шифрования», я ищу готовый к работе способ шифрования пакетов.
У меня есть внеполосный канал для обмена одним сообщением (например, ключом) от одного участника к другому (QR-код). Оба участника являются устройствами Android, одно из которых работает в режиме сервера (периферийное устройство), а другое - как клиент (центральное устройство).
Я рассматривал Noise Protocol Framework как более легкую альтернативу TLS, но мне кажется, что это все еще требует большой ручной работы (?).
Есть простое решение? Похоже, это должна быть решенная проблема.
Ответы
Во-первых, небольшой совет: StackExchange не предназначен для рекомендации конкретных продуктов, поэтому я буду здесь в общих чертах. Тот, кто прочтет это в будущем, может оказаться в мире, где есть новые и гораздо лучшие альтернативы, или даже где старая гвардия, как выяснилось, сломалась.
Существует несколько высокоуровневых криптографических библиотек, которые - при наличии предварительного общего ключа - будут обрабатывать шифрование сообщений или, возможно, поток (и соответствующие требования безопасности, такие как целостность данных) с минимальными усилиями. Простой поиск по запросу «easy crypto library» найдет вам несколько кандидатов. Обратите внимание, что многие люди игнорируют советы против развертывания собственной криптовалюты, а некоторые из них публикуют ее, поэтому вы действительно хотите убедиться, что выбранная вами библиотека хорошо проверена экспертами, в идеале не связанными с ее разработкой.
Вы также захотите подумать о том, что именно вы хотите (и что вам нужно) от своей библиотеки. Нужно ли поддерживать зашифрованные потоки произвольной длины (или очень большие сообщения, которые не помещаются в память), или будет работать простой протокол на основе сообщений? Должна ли библиотека быть очень маленькой по размеру установки или использованию ОЗУ? Очень быстро на определенном процессоре? Совместим с какой-либо другой библиотекой? Использовать определенные шифры или другие примитивы из соображений соответствия (надеюсь, что нет)? Доступно на определенном языке?
В качестве нескольких хорошо известных примеров по состоянию на середину 2020 года рассмотрим LibSodium или Monocypher . Оба хорошо известны, проверены и ориентированы на простоту использования. Другие альтернативы - NaCl, LibHydrogen и так далее. Обратите внимание, что не все из них одинаково сосредоточены на безопасности, скорости или удобстве; например, TweetNaCl подчеркивает минимальный размер кода, жертвуя большой скоростью и потенциально некоторой безопасностью процесса по сравнению с исходным NaCl.