Secure Boot and Firmware Signing: A Practical Guide for Industrial IoT Devices

A step-by-step walkthrough of implementing hardware-rooted secure boot and signed OTA updates on our NXP i.MX RT platform, with lessons applicable to any Cortex-M device.

1. Why Bother?

In industrial control, a compromised firmware image isn’t just a data breach — it’s a physical safety hazard. A tampered firmware could disable watchdog timers, override thermal shutdown thresholds, or silently exfiltrate proprietary motion-control parameters.

Yet most industrial IoT devices ship with JTAG left open and firmware images verified by nothing more than a CRC32 checksum. CRC32 catches bit flips; it does nothing against a motivated attacker.

In mid-2025, we audited Tainuo’s firmware supply chain and found multiple gaps: unsigned OTA payloads, no rollback protection, and debug interfaces that remained active in production. This post documents the fix.

2. The Chain of Trust

Our secure boot implementation follows a three-stage chain of trust:

$$ROM Boot Code (immutable, in mask ROM) ↓ verifies ECDSA signature of Stage 1: Bootloader (public key hash fused in OTP) ↓ verifies ECDSA signature of Stage 2: Application Firmware ↓ verifies ECDSA signature of Stage 3: FPGA Bitstream + Calibration Data$$

Each stage’s public key is embedded in the previous stage, with the root of trust anchored in one-time-programmable (OTP) eFuses on the i.MX RT1064. Once the public key hash is burned into OTP, it cannot be modified without physically replacing the chip.

We use ECDSA with NIST P-256 for all signatures. The choice of ECDSA over RSA was driven by two factors: significantly smaller signature sizes (64 bytes vs. 256+ bytes for equivalent security) and faster verification on Cortex-M cores (no hardware crypto accelerator needed for reasonable performance).

3. OTA Anti-Rollback

Signed firmware alone isn’t enough. An attacker who captures a valid-but-old OTA package could replay it to downgrade a device to a version with known vulnerabilities.

Our anti-rollback mechanism is simple and hardware-backed:

Each firmware image carries a monotonic security version number in its signed metadata.
The current security version is stored in a monotonic counter implemented in eFuse bits (burned, never cleared).
The bootloader rejects any image whose security version is less than the eFuse counter value.
An OTA update that increments the security version burns a new eFuse bit — a physically irreversible operation that survives full chip erase.

4. Key Management in CI/CD

Managing signing keys across a team is where most secure boot implementations fall apart. Keys that live on a developer’s laptop are keys that will leak.

Our approach:

Offline root CA: an air-gapped machine holding the root signing key. Used only once per year to sign intermediate certificates.
HSM-backed CI signing: day-to-day firmware signing keys live in a YubiHSM 2 attached to the CI server. Private keys never leave the HSM; the CI pipeline sends the firmware hash to be signed, and the HSM returns the signature.
Developer signing uses ephemeral keys signed by the CI intermediate CA, valid for 8 hours — no persistent developer keys on workstations.

5. What We Learned

Test the brick path first: before enabling secure boot in production, we deliberately flashed unsigned images and verified that the device correctly refuses to boot. The failure mode must be safe and recoverable.
OTP bits are forever: double-check every fuse value before burning. We keep a “fuse map” spreadsheet that’s reviewed by two engineers before any OTP programming.
Key ceremony matters: the root key generation ceremony is recorded on video, with two witnesses present. The root private key exists only on paper (as a QR-code-encoded mnemonic) stored in a physical safe.

Since deploying secure boot across our i.MX RT fleet, firmware integrity verification adds approximately 120ms to the boot sequence. That’s a small price for the guarantee that no unauthorized code will ever execute on a Tainuo controller.