Безопасность прошивки для инженеров встраиваемых систем

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

Моделирование угроз безопасности для целей прошивки

Уникальные векторы атак на прошивку: физические угрозы, угрозы цепочки поставок и каналов обновления

Прошивка сталкивается с тремя окнами угроз, которые стандартные модели CVE и OWASP плохо учитывают: физический доступ, подмена в цепочке поставок и злоупотребление каналом обновления OTA.

Атаки через физический доступ являются прямыми и часто недооцениваются. Злоумышленник, имеющий доступ к плате, может подключить JTAG или SWD зонд и за минуты прочитать содержимое флэш-памяти, если отладочные интерфейсы остаются разблокированными. Оставленные включенными в производственных сборках оболочки UART открывают доступ к интерфейсам команд. Микросхемы флэш-памяти в некоторых конструкциях могут быть отпаяны и прочитаны внешними стандартными программаторами. Это не теоретические риски — это стандартные методы, используемые при анализе разборки продуктов и конкурентном реверс-инжиниринге.

Подмена в цепочке поставок нацелена на окно производства и дистрибуции. Образы прошивки, поставляемые контрактным производителям без проверки целостности, могут быть заменены или изменены до сборки устройства. Угроза не ограничивается злоумышленниками. Неправильно сконфигурированные программаторы могут прошивать неверные образы, и у устройства нет способа обнаружить подмену при загрузке.

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

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

Специфичные для прошивок границы доверия и классификация активов

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

Картографирование границ доверия во встраиваемых системах отличается от серверной архитектуры одним критическим аспектом: границы являются как физическими, так и логическими. Загрузчик доверяет только тому, что было проверено аппаратным корнем доверия. Прикладная прошивка доверяет только тому, что было передано ей загрузчиком. Облачный бэкэнд доверяет только тому, что устройство аутентифицировало. Разрыв любого звена в этой цепи означает полный крах всей модели.

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

Архитектура безопасной прошивки: цепочка загрузки и схема защиты памяти

Проектирование безопасной цепочки загрузки и интеграция аппаратного корня доверия

Безопасная цепочка загрузки закрепляет доверие в коде, расположенном в ПЗУ (ROM), который производитель записывает один раз и который не может быть изменен после производства. Этот неизменяемый этап загрузки проверяет подпись загрузчика перед передачей выполнения. Затем загрузчик проверяет образ приложения. Каждый этап доверяет только тому, что было проверено предыдущим этапом.

Хранение ключей — наиболее важное проектное решение в этой цепочке. Основные варианты имеют реальные компромиссы:

• OTP фьюзы: низкая стоимость, однократная запись, отсутствие внешних зависимостей — но без смены ключей после инициализации
• Безопасные анклавы (например, TrustZone на Cortex-A, TF-M на Cortex-M): Программно-изолированное хранилище ключей с большей гибкостью, но все еще зависящее от правильной конфигурации
• Выделенные безопасные элементы или TPM: аппаратно-изолированные, устойчивые к несанкционированному доступу, максимальная устойчивость к атакам — добавляет стоимость компонента и место на плате

Конфигурация блока защиты памяти (MPU) при загрузке обеспечивает области, запрещающие выполнение (execute-never) для разделов данных, и области только для чтения (read-only) для проверенного образа. Без принудительного применения MPU переполнение буфера в приложении может привести к перезаписи и выполнению произвольного кода даже после чистой проверки при загрузке.

Предотвращение отката часто упускается из виду. Хранение монотонного счетчика версий в OTP или безопасной NVM и отклонение любого образа с более низким номером версии блокирует атаки понижения версии, которые могли бы повторно раскрыть исправленные уязвимости.

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

Реализация элементов безопасности прошивки в конвейере разработки

Реализация подписи, шифрования и безопасного обновления прошивки по воздуху (OTA)

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

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

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

Управление ключами заслуживает отдельного инженерного плана. Генерация ключей должна происходить в HSM. Политика ротации должна учитывать ожидаемый срок службы устройства. Отзыв на встраиваемых устройствах сложнее, чем на серверах — в большинстве конструкций он обрабатывается через истечение срока действия сертификата и обязательное обновление, а не через проверки отзыва в реальном времени. Для Паттерны обновления прошивки и подключения IoT-устройствграницы доверия облачного бэкэнда добавляет еще один уровень к этому конвейеру, который заслуживает отдельного рассмотрения.

В производстве регулярно встречается одна закономерность отказов: инженеры подписывают бинарный файл с предварительной очисткой (pre-strip) во время сборки, а затем поставляют образ с пост-очисткой (post-strip). Подписи не совпадают. Решение — это CI-триггер, который обеспечивает подписание именно того артефакта, который прошивается, с проверкой по хешу перед завершением сборки.

Средства контроля безопасности во время выполнения: сторожевые таймеры, защита стека и безопасное соединение

Канарейки стека обнаруживают переполнение буфера до перенаправления выполнения. В сочетании с границами стека, налагаемыми MPU, они ограничивают радиус поражения успешного переполнения задачей, вызвавшей сбой, вместо того чтобы позволить ей повредить всю систему. На большинстве целевых плат Cortex-M области защиты стека MPU добавляют незначительные накладные расходы во время выполнения.

Сторожевые таймеры — это средства контроля доступности. Атака, приводящая к зависанию прошивки (firmware lockup), — преднамеренная или случайная — которая мешает обслуживанию сторожевого таймера, приведет к сбросу. Инженерный компромисс — это выбор времени ожидания сторожевого таймера. Слишком короткое время, и легитимные задержки обработки вызывают ложные сбросы. Слишком длинное время, и устройство остается в заблокированном состоянии достаточно долго, чтобы нанести операционный ущерб. Типичный диапазон для промышленных HMI-приложений составляет от 500 мс до нескольких секунд, настроенный на окно максимальной допустимой длительности легитимной обработки.

Безопасное соединение на уровне прошивки означает взаимную аутентификацию TLS для соединений MQTT и HTTPS, а не только проверку сертификата сервера. Привязка сертификатов (certificate pinning) обеспечивает защиту от скомпрометированных центров сертификации (CA), но усложняет ротацию сертификатов. На ограниченных устройствах привязка сертификата CA, а не конечного сертификата, обеспечивает баланс между безопасностью и операционной гибкостью.

Блокировка отладочного интерфейса — это проблема обеспечения соблюдения правил в CI (CI enforcement) в той же мере, что и проблема конфигурации. Биты блокировки JTAG и отключение оболочки UART должны быть проверены в конфигурации производственной сборки и не должны быть отправлены в состоянии с включенной отладкой. CI-триггер, который проверяет конфигурацию отладочных плавких предохранителей бинарного файла перед подписанием, предотвращает попадание этого в производство.

Контрмеры против атак внедрением ошибок (fault injection) применяются там, где физический доступ представляет собой реальную угрозу. Схемы обнаружения скачков напряжения (voltage glitch detection) и избыточные критические проверки — выполнение одной и той же операции принятия решения дважды и сравнение результатов — повышают стоимость успешных атак внедрением скачков напряжения на безопасную загрузку или операции вывода ключей.

Проверка безопасности: статическое тестирование, фаззинг и тестирование на проникновение для прошивки

Статический анализ для прошивки нацелен на другие уязвимости, чем сканирование на прикладном уровне. Приоритетные проблемы включают небезопасные операции с памятью без проверки границ, жестко закодированные учетные данные во флэш-памяти, слабые источники энтропии для генерации ключей и непроверенный внешний ввод в обработчиках связи. Такие инструменты, как PC-lint, Polyspace или Coverity, выявляют многие из этих проблем до того, как код попадет на аппаратное обеспечение.

Фаззинг прошивки делится на два подхода. Фаззинг на основе эмуляции запускает образ прошивки в программном эмуляторе, что позволяет генерировать входные данные с высокой скоростью и измерять покрытие без использования аппаратного обеспечения. Фаззинг «аппаратное обеспечение в контуре» (Hardware-in-the-loop) выполняется на реальном целевом устройстве, выявляя аппаратные особенности, которые упускают эмуляторы. Компромисс заключается в скорости по сравнению с точностью. Большинство команд используют эмуляцию для широкого покрытия на ранних этапах разработки и «аппаратное обеспечение в контуре» для целенаправленного тестирования интерфейсов связи перед выпуском.

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

Проверки безопасности в CI должны включать сканирование двоичных файлов на наличие известных уязвимых версий библиотек, генерацию SBOM для отслеживания всех зависимостей прошивки и автоматическую проверку подписи для каждого артефакта сборки. Фреймворки соответствия — IEC 62443 для промышленных систем, NIST SP 800-193 для устойчивости прошивки платформы и PSA Certified для устройств на базе Arm — предоставляют структурированные критерии валидации, которые хорошо соотносятся с этими элементами конвейера.

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

Безопасность прошивки — это набор проектных обязательств, принятых на ранней стадии и постоянно применяемых через конвейер сборки. Команды, которые встраивают моделирование угроз и инфраструктуру подписи в начале проекта, несут существенно меньшие затраты на исправление, чем те, кто добавляет средства контроля безопасности при выпуске. STONE HMI разрабатывает промышленные прошивки производственного класса для систем HMI. Такая дисциплина процесса — средства контроля безопасности, интегрированные в конвейер сборки, а не добавленные к нему — напрямую снижает риск дорогостоящей переделки на поздних этапах и уязвимостей в полевых условиях, которые дороги в исправлении на развернутых устройствах.