Внедрение безопасной загрузки во встроенные устройства для предотвращения тамперинга

Императив безопасной загрузки во встроенной безопасности IoT

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

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

Что такое безопасная загрузка? Криптографическая цепочка доверия

Основной принцип: проверяйте доверительные отношения

Безопасная загрузка - это аппаратно-принудительный или аппаратно-ассистированный процесс, который гарантирует, что каждый фрагмент кода, выполненный после сброса, является подлинным и неповрежденным. Он полагается на корень доверия (RoT) - неизменяемый компонент, обычно ROM для маски только для чтения или выделенный модуль безопасности - который хранит один или несколько открытых ключей. Во время запуска корень доверия начинает цепочку проверки: он проверяет цифровую подпись следующего этапа (загрузчик первой стадии или образ прошивки), и так далее, пока не загрузится операционная система и код приложения. Если какая-либо проверка подписи не удается на этапе, процесс загрузки останавливается, и устройство входит в состояние безопасности от сбоев (например, режим восстановления или постоянный кирпич).

Криптографические фонды

Безопасная загрузка использует асимметричную криптографию (инфраструктура открытого ключа или PKI). Частный ключ, надежно хранящийся в среде производителя устройства, подписывает каждое изображение прошивки. Соответствующий открытый ключ хранится в неизменной памяти устройства. Во время проверки загрузчик вычисляет хеш изображения прошивки и сравнивает его со значением расшифрованной подписи. Соответствие гарантирует, что изображение было подписано владельцем частного ключа и не было изменено при передаче или хранении. Общие алгоритмы включают RSA-2048/4096 и ECDSA (P-256/P-384). Функция хеширования обычно SHA-256 или SHA-384.

Отличие безопасной загрузки от других функций безопасности загрузки

Безопасную загрузку часто путают с измеренной загрузкой (используется в системах на основе TPM, таких как Trusted Boot в Windows или измеренный запуск в Linux).В то время как безопасная загрузка предотвращает выполнение ненадежного кода, измеренная загрузка записывает весь исполняемый код в PCR (Platform Configuration Registers) TPM без обязательного прекращения загрузки. Аутентификация загрузки иногда используется как синоним безопасной загрузки, но осторожные поставщики различают два: аутентификация загрузки выполняет проверки, но может позволить устройству продолжать работу в ограниченном режиме. В этой статье безопасная загрузка подразумевает обеспечение соблюдения — устройство не загружается, если проверка не удается.

Почему безопасная загрузка важна для встраиваемых устройств IoT

Физические и дистанционные риски атаки

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

Регулятивные и отраслевые мандаты

Правительства и отраслевые органы все чаще требуют безопасной загрузки для подключенных устройств. EU Cyber Resilience Act , Калифорнийский закон о безопасности SB-327 (закон о безопасности IoT), и NISTIR 8259 руководящие принципы подчеркивают целостность устройства от загрузки. Устройства здравоохранения с разрешением FDA часто требуют безопасной загрузки для удовлетворения уровней безопасности IEC 62304 и SWaP. Для производителей, стремящихся продавать на регулируемых рынках, безопасная загрузка больше не является опциональной.

Основные компоненты безопасной системы загрузки

Корень доверия (RoT)

RoT является якорем всей цепочки доверия. Он должен быть неизменяемым (не может быть изменен программным обеспечением) и должен обеспечивать безопасную среду для хранения криптографических ключей. Общие реализации включают:

Подписание ключей и иерархия сертификатов

Крупномасштабные развертывания IoT используют трехуровневый PKI: root CA (офлайн, редко используется), промежуточное подписание CA и пары ключей для конкретного устройства. Во многих реализациях устройство хранит только открытый ключ root CA (или его хеш) в качестве RoT. Все изображения прошивки подписаны промежуточным ключом, и устройство проверяет цепочку подписей промежуточного сертификата обратно в корень. Эта архитектура позволяет отменять скомпрометированные промежуточные ключи без замены неизменного RoT. Управление ключами является единственным наиболее важным операционным бременем: потеря закрытого ключа означает, что все обновления прошивки становятся невозможными.

Загрузчик и этапы проверки

Процесс загрузки разделен на несколько этапов, чтобы каждый этап был достаточно мал, чтобы вписаться в ПЗУ на чипе или защищенную память, а также обеспечить загрузку сложной операционной системы:

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

Пошаговое руководство по внедрению встроенного IoT

Шаг 1: Определите модель угрозы и границы доверия

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

Шаг 2: Выберите аппаратную платформу с безопасными возможностями загрузки

Не все микроконтроллеры поддерживают безопасную загрузку. Выберите чип с неизменяемым загрузчиком ROM, хранилищем ключей на чипе (например, eFuses или OTP NVRAM) и встроенным аппаратным крипто ускорителем. Ведущие поставщики, предлагающие надежные решения для безопасной загрузки, включают:

Если выбранный SoC не включает аппаратный RoT, вы можете добавить дискретный TPM (например, Infineon SLB9670) или безопасный элемент (Microchip ATECC608A), чтобы обеспечить его.

Шаг 3: Создайте и храните корень доверия

Во время производства устройств каждое устройство должно иметь свой уникальный или общий корневой открытый ключ, запрограммированный в неизменяемую память. Для производства большого объема большинство производителей используют подход flash-on-production , когда открытый ключ вдувается в электронные предохранители в качестве одноразовой операции. Частный ключ никогда не подвергается воздействию заводского пола; подписание выполняется в автономном режиме на сервере сборки внутри защищенного анклава. Не жестко кодируйте один и тот же ключ на всех устройствах — если этот ключ извлечен, все устройства становятся уязвимыми. Используйте уникальные ключи на устройство или, как минимум, на партию с возможностью отзыва.

Шаг 4: Подпишите изображения прошивки

Настройка конвейера CI/CD, который подписывает все выпущенные изображения прошивки соответствующим закрытым ключом. Для каждой версии прошивки скрипт сборки генерирует двоичный файл, вычисляет его хеш SHA-256/384 и добавляет подпись RSA-2048/4096 или ECDSA. Многие продавцы SDK предоставляют инструменты для подписи; для пользовательских загрузчиков вы можете использовать и форматировать подпись для целевого загрузчика.

Важно: подписать не только полезную нагрузку прошивки, но и ее метаданные (например, номер версии, идентификатор целевого оборудования, длина изображения). Это предотвращает атаки отката, когда злоумышленник возвращается к более старой, уязвимой версии прошивки. Защита от отката обычно реализуется путем хранения минимально допустимой версии в защищенном счетчике (например, монотонный счетчик в памяти TPM или OTP).

Шаг 5: Настройка загрузчика для проверки

Настройка U-Boot (системы на основе Linux)

Для систем, использующих U-Boot, включите CONFIG CHAIN OF TRUST и CONFIG VERIFICATION INSECURE и предоставьте блоб открытого ключа. Механизм U-Boot , проверенный загрузкой (VBOOT) , поддерживает верифицированные изображения с метаданными (обязательный для отката версии). Вы также можете настроить U-Boot для автоматической попытки восстановления режима, если подпись выходит из строя.

Использование MCUBoot (для RTOS или Zephyr)

MCUBoot является фактическим стандартом безопасной загрузки на ARM Cortex-M и аналогичных микроконтроллерах. Он поддерживает проверку подписи с помощью RSA, ECDSA и настраивается с шифрованием изображений. MCUBoot интегрируется с цепочкой загрузки Zephyr RTOS и работает с внешней вспышкой. Его архитектура поддерживает обмен двойным изображением (механизм обновления A/B) и слот с одним изображением с восстановлением ошибок.

Загрузчики, предназначенные для конкретных поставщиков

Для NXP i.MX настройте HAB (High Assurance Boot) через инструмент CST. Для STM32 используйте X-CUBE-SBSFU, который включает в себя как безопасное обновление загрузки, так и безопасное обновление прошивки в одном пакете. Для ESP32 включите CONFIG SECURE BOOT V2 в меню-конфигурации и запустите скрипт подписи .

Шаг 6: Внедрение безопасного обновления прошивки по воздуху (FOTA)

Безопасная загрузка настолько же сильна, как и механизм обновления. Если злоумышленник может вводить неподписанное прошивку через канал OTA, проверка безопасной загрузки при следующей загрузке поймает его, но может возникнуть условие отказа в обслуживании. Сам процесс обновления должен проверить подпись перед записью в раздел загрузки. Рекомендуемая архитектура - это обновление двух банков (A / B) [[FLT: 1]]:

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

Реальные мировые архитектуры внедрения

ARM TrustZone-M (Cortex-M23/M33) с TF-M

Trusted Firmware-M (TF-M) обеспечивает эталонную реализацию безопасной загрузки, безопасного менеджера разделов и безопасного обновления прошивки для систем ARMv8-M. Загрузчик TF-M (BL2) работает вместе с MCUBoot и поддерживает подписание изображений, проверку и анти-откат. Безопасный менеджер разделов (SPM) изолирует код приложения в «безопасные» и «небезопасные» миры даже после загрузки.

AMD/Ryzen Embedded + PSP + UEFI Secure Boot (Безопасная загрузка)

Высокопроизводительные встроенные системы используют x86 UEFI Secure Boot (как определено спецификацией Microsoft Secure Boot for Windows) в сочетании с аппаратным обеспечением Platform Secure Processor (PSP). UEFI Secure Boot проверяет загрузчик EFI с помощью клавиш платформы (PK, KEK), хранящихся в UEFI Non-Volatile RAM. Для развертывания IoT UEFI Secure Boot сложен, но необходим для устройств, которые запускают Windows IoT или определенные ароматы Linux с шимом.

NXP i.MX High Assurance Boot (HAB) (недоступная ссылка)

HAB NXP широко используется в автомобильных и промышленных устройствах. В нем используется хеш «Super Root Key» (SRK), хранящийся в защищенных предохранителях. Загрузочный ПЗУ проверяет CSF (Command Sequence File), который включает в себя цифровые подписи для каждого изображения. HAB версия 4 поддерживает зашифрованные изображения и несколько записей таблицы SRK для вращения ключа. Инструменты подписи (CST) находятся в свободном доступе, но требуют тщательного управления файлом хранения ключа (дерево PKI).

Общие проблемы и как их смягчить

Ключевая сложность управления

Самым большим препятствием является защита закрытого ключа на протяжении всего жизненного цикла продукта. Лучшие практики: использование HSM (Hardware Security Module) или облачного сервиса ключей (AWS CloudHSM, Azure Key Vault) для операций подписи. Регулярно вращайте промежуточные ключи. Реализуйте церемонию ключей, которая требует нескольких авторизованных подписчиков. Для отзыва полей включите список отзывов в составе подписанных метаданных и проверьте его во время загрузки.

Восстановление с помощью кирпичных устройств

Если вспышка повреждена или обновление установлено неправильно, устройство может отказаться от загрузки. Смягчения: включают вторичный минимальный загрузчик в защищенной от записи памяти, который может инициировать режим восстановления через физическую кнопку, последовательный интерфейс или USB DFU. Некоторые SoC имеют предохранитель «восстановления силы», который обходит безопасную загрузку для целей ремонта, но это открывает окно для физических атак, если не контролируется должным образом.

Производительность и время загрузки накладные расходы

Асимметричная проверка подписи может занять сотни миллисекунд, особенно на маломощных MCU без аппаратного крипто ускорителя. Используйте ECDSA по сравнению с RSA для меньших подписей и более быстрой проверки. Многие поставщики включают специализированные криптодвижки, которые выполняют операции проверки менее чем за 10 мс для 256-битной подписи ECDSA. Измеряйте и оптимизируйте проверку каждого этапа; перемещайте тяжелые операции (например, хеш-вычисления) после инициализации DRAM, если подписанные данные малы.

Отсутствие отраслевой однородности

Каждый поставщик SoC имеет собственную реализацию безопасной загрузки. Разработчики должны каждый раз изучать конкретную цепочку инструментов и скрипт. Использование загрузчика с открытым исходным кодом, такого как MCUBoot или U-Boot, абстрагирует некоторые из этих различий. Усилия по стандартизации через Trusted Computing Group (TCG) и GlobalPlatform постепенно унифицируют API безопасности загрузки (например, TAM - TCG Attestation Model, PSA Certified Level 2/3).

Усиление безопасной загрузки с помощью дополнительных технологий

Безопасная загрузка сама по себе не защищает от атак во время выполнения, утечки боковых каналов или скомпрометированных серверов обновлений.

Будущие направления: например, DICE, PSA Certified и Integrated Security

Архитектура Device Identifier Composition Engine (DICE) , определенная TCG, использует простой аппаратный секрет, называемый Unique Device Secret (UDS), который уникален для каждого чипа. При загрузке слой ROM выдает криптографический ключ, который связывается с идентификатором прошивки. Любое изменение прошивки изменяет производный ключ, позволяя автоматическую безопасную загрузку и аттестацию без предварительно предусмотренного открытого ключа. DICE идеально подходит для больших объемов, недорогих устройств, где управление PKI слишком дорого.

PSA Certified (Platform Security Architecture) предлагает основу для создания и сертификации IoT-устройств с уровнями безопасности от 1 (базовая защита) до 3 (изоляция оборудования). Уровень 2 требует безопасной загрузки, в то время как уровень 3 требует физического сопротивления взлому. Использование чипов PSA Certified и следование рекомендациям снижает риск проектирования и повышает доверие покупателей.

Все чаще безопасная загрузка интегрируется непосредственно в кремний в виде «безопасных анклавов» на уровне чипов, которые обрабатывают всю аутентификацию и хранение ключей.По мере снижения стоимости этих функций ожидается, что даже самые дешевые IoT-SoC будут поставляться с неизменным ПЗУ и хранилищем ключей на диске.

Заключение: Обезопасьте загрузку первой линии обороны

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

Для дальнейшего чтения, обратитесь к NIST SP 800-193: Platform Firmware Resiliency , спецификации TCG DICE , и PSA Certified руководящие принципы.