Ochrona firmware IoT: podpisywanie, szyfrowanie i secure boot

Twój firmware zawiera Twoją własność intelektualną. Jeśli konkurent zdoła go wyodrębnić i zdezasemblować, tracisz przewagę konkurencyjną. Jeśli atakujący zdoła go zmodyfikować i ponownie wgrać, Twoje urządzenie jest skompromitowane.

Szyfrowanie pamięci flash (ESP32)

CONFIG_FLASH_ENCRYPTION_ENABLED=y
CONFIG_FLASH_ENCRYPTION_MODE_RELEASE=y

Podpisywanie firmware

espsecure.py generate_signing_key --keyfile signing_key.pem
espsecure.py sign_data --keyfile signing_key.pem   --version 2 firmware.bin --output firmware_signed.bin

Bezpieczny potok OTA

1. Download via HTTPS with cert pinning
2. Verify SHA-256: computed_hash == twin.desired.ota.sha256
3. Verify signature: esp_secure_boot_verify_signature()
4. Only then: esp_ota_set_boot_partition()
// If any step fails: abort, report failure to cloud

Integracja elementu bezpieczeństwa dla kluczy podpisujących firmware

Klucz prywatny do podpisywania firmware jest prawdopodobnie najbardziej wrażliwym kluczem w całej architekturze bezpieczeństwa Twojego produktu IoT. Jeśli atakujący go zdobędzie, może podpisać złośliwy firmware, który przejdzie weryfikację secure boot na każdym urządzeniu w Twojej flocie. Ten klucz nigdy nie powinien istnieć jako plik na laptopie programisty ani w systemie plików serwera CI/CD.

Przechowuj klucze podpisujące firmware w dedykowanych modułach HSM (Hardware Security Modules) dla produkcyjnych potoków podpisywania. Na potrzeby rozwoju praktycznym kompromisem jest YubiKey lub podobny klucz bezpieczeństwa FIDO2 z obsługą PIV — operacje podpisywania odbywają się wewnątrz klucza sprzętowego, którego nie da się wyeksportować. Zintegruj podpisywanie HSM ze swoim potokiem CI/CD (GitHub Actions, Azure DevOps) za pomocą bibliotek dostawcy PKCS#11 — Twój potok kompilacji żąda podpisów od HSM, nigdy nie mając dostępu do surowego materiału klucza.

Ochrona przed przywracaniem starszych wersji (anti-rollback)

Secure boot zapobiega uruchamianiu niepodpisanego firmware, ale sam w sobie nie powstrzymuje atakującego przed cofnięciem urządzenia do starszej, podatnej wersji firmware (jeśli dysponuje on ważnym, podpisanym obrazem starego firmware). Ochrona anti-rollback wykorzystuje licznik monotoniczny w eFuse: każda nowa wersja firmware inkrementuje licznik, a bootloader odmawia uruchomienia jakiegokolwiek firmware podpisanego dla numeru wersji niższego niż bieżąca wartość licznika.

CONFIG_BOOTLOADER_APP_ANTI_ROLLBACK=y
CONFIG_BOOTLOADER_APP_SEC_VER=1  # increment with each release

Anti-rollback jest z założenia nieodwracalny — gdy urządzenie uruchomi już firmware w wersji N, nie da się go cofnąć do N-1. Oznacza to, że Twój potok OTA nigdy nie może dystrybuować starszego firmware do urządzeń, które już się zaktualizowały. Zbuduj swój system zarządzania OTA tak, by śledził wersję firmware każdego urządzenia i wymuszał kolejność wersji.

Debugowanie w bezpiecznym środowisku

Debugowanie JTAG jest wyłączane przez secure boot w trybie RELEASE, co utrudnia diagnozowanie problemów firmware po wprowadzeniu do produkcji. Obejściem jest kompleksowe logowanie do bezpiecznego, odpornego na manipulacje magazynu logów — zarówno lokalnego bufora cyklicznego w NVS, jak i logowania w chmurze przez MQTT. Gdy urządzenie produkcyjne zachowuje się w nieoczekiwany sposób, logi są Twoim jedynym oknem diagnostycznym. Zaprojektuj system logowania tak, by przechwytywał wystarczający kontekst do zdalnego diagnozowania problemów, nie logując przy tym danych wrażliwych (materiału kryptograficznego, danych osobowych ani poświadczeń).