1. Тема дня

Защищенная цепочка загрузки и OTA:

text 
release build
→ подпись прошивки
→ provisioning
→ ROM bootloader
→ проверка bootloader
→ проверка app
→ OTA
→ self-test
→ confirm или rollback
→ optional anti-rollback floor

Механизмы:

МеханизмЧто делает
Secure BootЗапускает только авторизованный код
Flash EncryptionСкрывает содержимое внешней Flash
OTA rollbackВозвращает исправную версию при неудачном OTA
Anti-rollbackЗапрещает старую подписанную, но уязвимую версию

Главная мысль: это разные механизмы, включать их нужно в правильном порядке.

2. Зачем это нужно

Через EC25 устройство скачивает OTA. TLS помогает, но остаются риски:

text 
сервер скомпрометирован;
файл подменен;
подписанная старая уязвимая версия;
физическая замена SPI Flash;
UART/JTAG доступ.

Secure Boot проверяет код, Flash Encryption скрывает Flash, anti-rollback отзывает старые security floors.

3. Теория

Secure Boot

Цепочка ESP32:

text 
ROM -> signed second-stage bootloader -> signed app

Private signing key не хранится на устройстве. Устройство хранит verification material/digest. Для классического ESP32 Secure Boot v2 доступен только на revision 3.0+. Перед provisioning:

text 
esptool -p COM7 chip-id
espefuse -p COM7 summary --format json --file efuses-before.json

Flash Encryption

Шифрует внешнюю Flash. Production mode должен использовать уникальный flash-encryption key на устройство. Не путать:

text 
Secure Boot -> authenticity
Flash Encryption -> confidentiality

Порядок включения

При внешнем provisioning обычно:

text 
Flash Encryption first
Secure Boot second

Потому что read protection key blocks и digest должны быть защищены в правильном порядке. eFuse необратимы.

OTA rollback

Новая прошивка сначала PENDING_VERIFY. После локального self-test:

c 
esp_ota_mark_app_valid_cancel_rollback();

При провале:

c 
esp_ota_mark_app_invalid_rollback_and_reboot();

Anti-rollback

security_version - отдельное поле, не равное semantic version. Правило:

text 
Product version меняется часто.
security_version повышается только для отзыва уязвимых релизов.

Нельзя повышать security version в каждой nightly build.

Self-test

Подтверждать OTA можно только после локального self-test:

c 
config valid;
critical tasks started;
input service alive;
watchdog supervisor alive;
power stable;
heap budget OK;
hardware revision compatible.

Не делай MQTT broker обязательным условием подтверждения.

4. Типичные ошибки

  • Flash Encryption считается заменой Secure Boot.
  • Secure Boot считается заменой TLS.
  • Security включается на единственной отладочной плате.
  • Не проверяется revision ESP32.
  • Private signing key хранится в Git/CI.
  • Один Flash Encryption key на весь парк.
  • Secure Boot включается до записи read-protected keys.
  • security_version повышается в каждом release.
  • anti-rollback floor повышается до self-test.
  • MQTT включен как обязательный OTA self-test.
  • Неактивный OTA slot содержит старый запрещенный image.
  • eFuse команды повторяются без понимания, что они необратимы.

5. Практическое задание на 30-60 минут

Без eFuse и production security создай SECURITY_LIFECYCLE.md:

markdown 
# Firmware security lifecycle
## Development
- Hardware Secure Boot disabled.
- Flash Encryption disabled or development-only on sacrificial boards.
- Development signing keys only.
- JTAG and UART available.
## Pilot
- Signed OTA images required.
- OTA rollback enabled.
- Hardware security tested only on dedicated boards.
- Production key is not present on developer workstations.
## Production
- Secure Boot enabled.
- Flash Encryption release mode.
- Unique flash-encryption key per device.
- UART/JTAG policy explicitly configured.
- Anti-rollback enabled only after staged fleet validation.
- Provisioning and eFuse reports archived.

Создай test signing key:

text 
espsecure generate-signing-key --version 2 --scheme rsa3072 keys/dev_secure_boot.pem

Включи подписанные приложения без hardware Secure Boot:

text 
CONFIG_SECURE_SIGNED_APPS_NO_SECURE_BOOT=y
CONFIG_SECURE_SIGNED_ON_UPDATE_NO_SECURE_BOOT=y
CONFIG_BOOTLOADER_APP_ROLLBACK_ENABLE=y
CONFIG_BOOTLOADER_APP_ANTI_ROLLBACK=n

Проверь:

text 
idf.py secure-verify-signature --keyfile keys/dev_secure_boot.pem build/app.bin

Измени один байт binary и убедись, что verification падает.

6. Что почитать или попробовать дальше

  • ESP-IDF Secure Boot v2, Flash Encryption, OTA Rollback, Anti-rollback.
  • espefuse summary и production provisioning.
  • STM32Trust, X-CUBE-SBSFU, MCUboot/TrustZone для конкретной серии STM32.
Какой механизм запрещает старую уязвимую прошивку с корректной подписью?

Критерии: Соотнесите угрозу и механизм; не меняйте eFuse в этом упражнении.

Задание

Сравните OTA rollback и anti-rollback в design review. Объясните момент подтверждения нового приложения и почему внешний MQTT broker не должен быть обязательным условием self-test.

Критерии самопроверки: Разделите recovery и отзыв версий, сохраните требование локального self-test и не выполняйте необратимый provisioning.

Показать ответ автора

OTA rollback возвращает исправный image при неуспешном новом приложении; anti-rollback запрещает releases ниже security floor. Новое приложение подтверждается после локального self-test. Доступность broker — внешнее условие, поэтому его отсутствие не должно быть обязательным критерием локального подтверждения.