design-iot-secure-boot

name	design-iot-secure-boot
description	Use when designing firmware update mechanisms for IoT devices — implementing code signing, secure boot chains, and rollback protection to prevent malicious firmware from running on deployed hardware.
source	OWASP IoT Top 10 I4 (owasp.org/www-project-internet-of-things/); NIST SP 800-193 (Platform Firmware Resiliency); IETF SUIT manifest standard (RFC 9019); Arm TrustZone secure boot documentation
tags	["security","owasp","iot","firmware","secure-boot","code-signing","embedded","hardware"]

Design IoT Secure Boot

Implement cryptographic code signing for firmware, verified boot chain from ROM to application, and rollback prevention — ensuring only authorized firmware runs on IoT devices even after physical access.

Why This Is Best Practice

Adopted by: OWASP IoT Top 10 I4 (Lack of Secure Update Mechanism). NIST SP 800-193 (Platform Firmware Resiliency) is the US federal standard for firmware integrity. The IETF SUIT (Software Updates for Internet of Things) manifest standard (RFC 9019) defines the protocol. Arm TrustZone secure boot is implemented in the majority of modern IoT SoCs (STM32H5, NXP i.MX RT, Nordic nRF9161). AWS IoT Jobs, Azure Device Update, and Mbed TLS all implement SUIT-compatible update pipelines. Impact: Mirai botnet (2016, 600,000+ devices compromised) and its variants exploited devices with no firmware verification — malicious firmware was flashed over default credentials and telnet. VPNFilter (2018, 500,000 routers compromised) survived factory resets because it persisted in flash memory beyond the OS partition. NIST SP 800-193 states that "the ability to detect and recover from corrupt or maliciously modified firmware is a foundational security control" — without it, physical access equals full device compromise. Why best: OTA updates without signature verification allow any attacker who intercepts the update channel (or the update server itself) to push malicious firmware to the entire device fleet. Code signing ensures the device verifies the firmware author before executing it. Secure boot ties the trust chain to hardware (ROM key, OTP fuses) so no software-level attack can bypass it.

Sources: OWASP IoT Top 10 I4; NIST SP 800-193; IETF RFC 9019 (SUIT Manifest); Arm Platform Security Architecture (PSA) documentation

Steps

1. Sign firmware images before distribution:

   # Generate signing key (keep private key in HSM for production)
   openssl ecparam -name prime256v1 -genkey -noout -out firmware-signing-key.pem
   openssl ec -in firmware-signing-key.pem -pubout -out firmware-signing-key-pub.pem
   
   # Sign firmware binary
   openssl dgst -sha256 -sign firmware-signing-key.pem \
     -out firmware-v1.2.3.bin.sig firmware-v1.2.3.bin
   
   # Verify (device does this)
   openssl dgst -sha256 -verify firmware-signing-key-pub.pem \
     -signature firmware-v1.2.3.bin.sig firmware-v1.2.3.bin
   

2. Implement ECDSA signature verification in the bootloader:

   #include "mbedtls/ecdsa.h"
   #include "mbedtls/sha256.h"
   
   /* Public key burned into OTP fuses or stored in secure storage */
   static const uint8_t SIGNING_PUBLIC_KEY[] = {
       0x04, /* uncompressed point marker */
       /* 64-byte public key X and Y coordinates */
   };
   
   int verify_firmware(const uint8_t *firmware, size_t firmware_len,
                       const uint8_t *signature, size_t sig_len) {
       uint8_t hash[32];
       mbedtls_sha256(firmware, firmware_len, hash, 0);
   
       mbedtls_ecdsa_context ecdsa;
       mbedtls_ecdsa_init(&ecdsa);
   
       int ret = mbedtls_ecp_point_read_binary(
           &ecdsa.private_grp, &ecdsa.private_Q,
           SIGNING_PUBLIC_KEY, sizeof(SIGNING_PUBLIC_KEY)
       );
       if (ret != 0) return VERIFY_FAILED;
   
       ret = mbedtls_ecdsa_read_signature(&ecdsa, hash, (hash),
                                          signature, sig_len);
       mbedtls_ecdsa_free(&ecdsa);
   
        (ret == ) ? VERIFY_OK : VERIFY_FAILED;
   }
   

Rules

• The signing private key must never be stored on the device — it lives in an HSM or air-gapped signing server; the device only stores the public key.
• Never verify firmware signature in application code — the bootloader must verify before jumping to application; application-level verification is too late.
• Test rollback protection explicitly: flash an older firmware version and verify the device rejects it.
• Disable JTAG/SWD debug interfaces in production via OTP fuses — debuggers allow bypassing signature verification.

Common Mistakes

• Burning the same signing key into all devices — a single key compromise affects the entire fleet; use a key hierarchy with per-batch keys where feasible.
• Checking version number for rollback prevention — version numbers are in flash and changeable; use OTP hardware counters that can only increment.
• Downloading firmware over HTTP — even with a valid signature, HTTP OTA allows detection of update patterns and MITM size information leakage; use HTTPS.
• Not testing the revert path — A/B update that can't revert leaves devices bricked if new firmware has a boot failure; test the failure scenario.