Встраиваемые системы
Bootloader и OTA
В 2022 году Hermetic Wiper malware атаковал Украину за несколько часов до вторжения. Среди целей были промышленные контроллеры с устаревшим firmware без Secure Boot. Обновление прошивки по воздуху - не просто удобство, это линия обороны. Tesla раскатывает critical security patch на 1.5 миллиона автомобилей за 48 часов. Как работает механизм, не допускающий 'окирпичивания' при обновлении?
- **Tesla** использует dual-bank OTA с криптографической подписью: каждое обновление проверяется Ed25519, anti-rollback счётчик в OTP предотвращает откат на версии с уязвимостями.
- **медицинские кардиостимуляторы** (Medtronic) требуют OTA-обновлений: замена батареи/устройства ради обновления ПО неприемлема. FDA требует Secure Boot для всех имплантируемых устройств с 2023 года.
- **IoT-счётчики** (миллиарды устройств Itron, Landis+Gyr) получают OTA через DLMS/COSEM протокол - иначе смена tariff plan требовала бы физического выезда к каждому счётчику.
Bootloader: первый код, который видит процессор
Когда микроконтроллер получает питание, счётчик команд устанавливается на фиксированный адрес (reset vector) - и там должен быть bootloader. Загрузчик выполняет три задачи: инициализация аппаратуры (тактирование, RAM), проверка целостности основного приложения (CRC или подпись), передача управления. Без bootloader невозможно обновить прошивку в поле - придётся физически перепрошивать через JTAG/SWD. Знаменитый U-Boot (Das U-Boot) используется в Linux-embedded от Raspberry Pi до роутеров Linksys - его история начинается с 2000 года. На bare-metal MCU (STM32, nRF52) пишут custom bootloader под конкретную задачу: меньше размер (2-8 KB), быстрее запуск (5-50 мс), контроль над каждым байтом.
Linker script определяет flash-карту: BOOTLOADER_START=0x08000000, APP_START=0x08008000. Bootloader занимает первые 32 KB, приложение - остальное. Jump to application: установить MSP (Main Stack Pointer) из заголовка приложения, перейти по Reset_Handler.
Почему bootloader помещают в начало flash-памяти (адрес reset vector), а не в конец?
OTA: обновление прошивки по воздуху
Over-The-Air (OTA) обновление - это способность устройства обновить собственную прошивку без физического контакта. Без OTA отзыв прошивки с дефектом в 10 миллионах устройств стоит сотни миллионов долларов. В 2015 году Tesla OTA-обновлением исправила потенциально опасный баг в Model S за одну ночь - без единого визита на сервис. Классическая схема dual-bank: flash разбита на два слота (A/B). Активный слот работает, второй - принимает новую прошивку. После загрузки и верификации bootloader переключает активный слот - атомарная операция. Если новая прошивка не прошла watchdog-тест, bootloader откатывается на предыдущий слот. ESP32, nRF52 и STM32 имеют встроенную поддержку этой схемы.
MCUboot - открытый bootloader с поддержкой dual-bank OTA, используется в Zephyr RTOS, MyNewt, nRF SDK. Поддерживает ed25519 подпись образов, SHA-256, AES-шифрование прошивки в хранилище.
Зачем в OTA dual-bank схеме новая прошивка должна 'подтвердить себя' после первой загрузки?
Secure Boot: криптографическая цепочка доверия
Secure Boot - это механизм, гарантирующий что устройство запускает только авторизованный код. Цепочка доверия начинается с ROM-кода (несменяемый, производитель кристалла) -> bootloader (верифицирован ROM по публичному ключу) -> приложение (верифицировано bootloader). Ключ верификации прошит в OTP (One-Time Programmable) памяти - записать можно один раз. Если атакующий подменит прошивку - подпись не пройдёт, устройство не загрузится. ESP32 реализует Secure Boot V2 на RSA-PSS 3072: ROM проверяет bootloader, bootloader проверяет приложение. STM32 поддерживает SBSFU (Secure Boot & Secure Firmware Update) с ecc256. Цена безопасности: невозможно откатиться на непоодписанную прошивку, нужно хранить приватный ключ за пределами устройств.
Anti-rollback: счётчик в OTP увеличивается при каждом обновлении. Прошивка с меньшим счётчиком не запустится - защита от downgrade attack (откат к версии с уже известной уязвимостью). Используется в ESP32, nRF9160, STM32.
Почему публичный ключ Secure Boot хранят в OTP-памяти, а не в обычной flash?
Верификация прошивки: CRC, SHA и подписи
Верификация прошивки - это многоуровневая проверка целостности и подлинности кода. CRC32 обнаруживает случайные ошибки памяти (bit-flip от радиации, aging). SHA-256 обнаруживает злонамеренные модификации - коллизия практически невозможна. Цифровая подпись (RSA, ECDSA, Ed25519) гарантирует авторство. Стандарт IETF SUIT (Software Updates for Internet of Things, RFC 9019) определяет формат манифеста обновления: JSON/CBOR-документ с описанием компонентов, зависимостей, условий применения, подписанный производителем. AWS IoT Jobs, Azure IoT Hub, Mender - все реализуют SUIT-совместимые OTA-пайплайны.
Атака downgrade: если не проверять версию, можно откатить устройство на старую прошивку с уязвимостью. Anti-rollback счётчик в OTP (monotonic counter) решает эту проблему: текущий счётчик хранится в OTP, новая прошивка должна иметь счётчик >= текущего.
Чем SHA-256 хеш прошивки принципиально отличается от CRC32 по защитным свойствам?
Ключевые идеи
- **Bootloader** - первый код после сброса; проверяет образ (CRC/подпись) и передаёт управление приложению или запускает DFU-режим.
- **Dual-bank OTA** позволяет атомарно переключаться между прошивками с автоматическим откатом, если новая не прошла self-test.
- **Secure Boot** строит криптографическую цепочку доверия: ROM -> bootloader -> приложение; публичный ключ в OTP неизменяем.
- **Anti-rollback** (monotonic counter в OTP) предотвращает downgrade-атаки; SHA-256 + цифровая подпись гарантируют авторство прошивки.
Связанные темы
Bootloader и OTA опираются на управление памятью и периферией из предыдущих уроков:
- Управление памятью MCU — Dual-bank OTA требует понимания flash-карты, секторов и адресации; linker script определяет где bootloader, где приложение
- RTOS и задачи — OTA-загрузка обычно выполняется в фоновой RTOS-задаче с низким приоритетом, пока система продолжает работу
Вопросы для размышления
- Если приватный ключ подписи прошивки утечёт (скомпрометирован), какие шаги нужно предпринять для продуктов с уже задеплоенными устройствами?
- Устройство с 64 KB flash не помещает dual-bank: нет места для двух образов. Какие альтернативные схемы OTA существуют для constrained devices?
- Как проверить, что Secure Boot действительно включён на конкретном устройстве, если нет физического доступа к OTP?