Шифрование файлов обновлений ПО OTA для встраиваемых устройств

Содержание

Вопрос или проблема
Ответ или решение
Шифрование файлов OTA обновлений для встроенных устройств
Архитектура процесса обновления
Выбор алгоритмов шифрования
Рекомендации
Заключение

Вопрос или проблема

Мне нужно зашифровать и отправить файлы обновлений порядка 100K с сервера через мобильное приложение на маломощные беспроводные встроенные устройства (32 бита). Передача файлов будет редкой. Связь от мобильного приложения к устройству медленная (BLE) и может передавать 16 байтов данных за сообщение. У устройства ограниченная дополнительная память, помимо 100K, поэтому расшифровка должна выполняться на месте. Кодовое пространство тоже довольно ограничено на устройстве.

Сервер и устройства могут иметь общие секреты, и устройство может создать последовательность незанятых значений (nonces), которая не повторяется после перезапуска питания. Файлы уже содержат CRC32 для проверки целостности данных.

Является ли следующий подход действительным?

Каждое устройство имеет свой собственный ключ, сервер имеет таблицу ключей устройств. Устройство отправляет свой идентификатор и незанятое значение на сервер. Файл шифруется с аутентификацией в целом на сервере. Зашифрованный файл отправляется в мобильное приложение, разбивается на фрагменты по 16 байтов и отправляется на устройство. Устройство восстанавливает зашифрованный файл, расшифровывает и проверяет подлинность.

Является ли salsa20 + umac хорошим выбором для шифрования/аутентификации?

Каждое устройство имеет свой собственный ключ, сервер имеет таблицу ключей устройств. Устройство отправляет свой идентификатор и незанятое значение на сервер. Файл шифруется с аутентификацией в целом на сервере. Зашифрованный файл отправляется в мобильное приложение, разбивается на фрагменты по 16 байтов и отправляется на устройство. Устройство восстанавливает зашифрованный файл, расшифровывает и проверяет подлинность.

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

Является ли salsa20 + umac хорошим выбором для шифрования/аутентификации?

Этот вопрос устаревает, и через 6 лет мои конкретные рекомендации также устареют.

Salsa20 + umac вероятно был хорош в то время. Chacha-Poly является рекомендованной парой для аутентифицированного шифрования из этой семейства на момент написания. В зависимости от поддержки процессорных ускорителей, AES-GCM в настоящее время является рекомендованным аутентифицированным потоковым шифром из семейства AES.

Ответ или решение

Шифрование файлов OTA обновлений для встроенных устройств

Вопрос шифрования файлов обновлений OTA (over-the-air) для встроенных устройств требует комплексного подхода. За основу мы принимаем описанные вами условия: передача 100К файлов с сервера через мобильное приложение на устройства с низким энергопотреблением, мощностью 32 бита. Общая проблема заключается в ограниченной памяти и низкой скорости передачи данных через Bluetooth Low Energy (BLE), что требует внимательного проектирования и использования соответствующих методов шифрования.

Архитектура процесса обновления

Система ключей: Каждый устройство имеет уникальный ключ, который хранится на сервере в виде таблицы. Это позволяет гарантировать, что только авторизованные устройства могут принимать обновления.
Идентификация устройства: Устройство отправляет свой идентификатор и уникальный nonce (число, которое не должно повторяться) на сервер перед началом процесса обновления. Это дополнительный уровень безопасности помогает предотвратить атаки повторного воспроизведения.
Шифрование файла: Файл обновлений шифруется на сервере с использованием общего ключа и включает в себя контрольные суммы для проверки целостности данных. Шифрование производится за один раз для всего файла, чтобы упростить процесс передачи данных.
Передача через мобильное приложение: Зашифрованный файл разбивается на фрагменты по 16 байт, что соответствует ограничениям BLE, и отправляется на устройство.
Десятчение и проверка подлинности: Устройство собирает зашифрованный файл обратно, производит его расшифровку с использованием своего уникального ключа и проверяет подлинность. Использование системы контроля целостности (CRC32) дополнительно защищает данные от повреждений.

Выбор алгоритмов шифрования

По поводу оптимальности использования Salsa20 + UMAC:

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

Тем не менее, важно отметить, что на текущий момент более предпочтительным является использование комбинации ChaCha20-Poly1305. Этот метод обеспечивает аутентифицированное шифрование и доказал свою эффективность в мобильных и встроенных применениях.

Дополнительным альтернативным выбором является AES-GCM, если оборудование поддерживает аппаратное ускорение для AES.

Заключение

Процесс шифрования OTA обновлений файлов для встроенных устройств представляет собой сложную задачу, требующую баланса между безопасностью и эффективностью. Реализация предложенной архитектуры и использование современных алгоритмов шифрования, таких как ChaCha20-Poly1305 или AES-GCM, обеспечат надежную защиту обновлений. Настоятельно рекомендуется активно следить за новыми разработками в области безопасности, чтобы гарантировать защиту устройств от потенциальных угроз.