How to Implement Secure Boot on ARM Cortex-M Devices

Secure boot is a critical security mechanism that ensures only authenticated and untampered firmware executes on a microcontroller, establishing a hardware root of trust from the moment the device powers on. On ARM Cortex-M devices, secure boot works by verifying the cryptographic signature of the firmware image against a public key stored in immutable memory (OTP fuses or ROM) before transferring execution control. The boot process forms a chain of trust: the ROM bootloader verifies the first-stage bootloader, which in turn verifies the application firmware. ARM's Platform Security Architecture (PSA) and Trusted Firmware-M (TF-M) provide standardized frameworks for implementing secure boot on Cortex-M23, M33, and M55 processors that support TrustZone-M. Without secure boot, attackers can flash malicious firmware, extract intellectual property, or compromise device integrity through physical or remote attacks on the update mechanism.

What Is the Chain of Trust in Secure Boot?

The chain of trust begins with an immutable root of trust, typically implemented in mask ROM or hardware security modules. When the device powers on, the ROM bootloader executes first and verifies the signature of the second-stage bootloader (often MCUboot or a vendor-specific bootloader). If verification succeeds, control passes to the second-stage bootloader, which then verifies the application firmware. Each stage in the chain must be verified before execution. If any verification fails, the device enters a safe state, preventing potentially compromised code from running. This hierarchical verification ensures that even if an attacker modifies the application firmware, the bootloader will detect the tampering and refuse to execute it.

How Do You Set Up MCUboot for Secure Boot?

# Generate signing keys for MCUboot
python3 scripts/imgtool.py keygen -k root-rsa-2048.pem -t rsa-2048

# Sign the application image
python3 scripts/imgtool.py sign \
  --key root-rsa-2048.pem \
  --header-size 0x200 \
  --align 8 \
  --version 1.0.0 \
  --slot-size 0x60000 \
  zephyr.bin signed-app.bin

# Flash MCUboot + signed application
pyocd flash -t nrf52840 mcuboot.hex
pyocd flash -t nrf52840 --base-address 0x10000 signed-app.bin

What Role Does ARM TrustZone-M Play in Secure Boot?

ARM TrustZone-M, available on Cortex-M23, M33, and M55 processors, provides hardware-enforced isolation between Secure and Non-Secure worlds. In a secure boot implementation, the Secure Processing Environment (SPE) handles cryptographic verification, key storage, and secure services, while the Non-Secure Processing Environment (NSPE) runs the application code. The Security Attribution Unit (SAU) and Implementation Defined Attribution Unit (IDAU) control which memory regions and peripherals are accessible from each world. TF-M (Trusted Firmware-M) provides a reference implementation of PSA-compliant secure services including secure storage, cryptography, and attestation that run in the secure world.

What Cryptographic Algorithms Should You Use?

What Are Common Pitfalls in Secure Boot Implementation?

Several common mistakes can undermine secure boot security. Storing private signing keys in version control or CI/CD systems without proper secrets management exposes the entire trust chain. Failing to protect debug interfaces (JTAG/SWD) allows attackers to bypass secure boot by directly reading or modifying flash memory. Not implementing rollback protection means attackers can downgrade to older firmware versions with known vulnerabilities. Leaving test or development keys in production devices creates a universal bypass. Always use hardware security modules (HSMs) for key management, disable debug access on production devices, implement monotonic version counters for anti-rollback, and rotate keys according to your security policy.

Key takeaway: Secure boot on ARM Cortex-M establishes a hardware root of trust by verifying cryptographic signatures of firmware images at each boot stage. Using MCUboot with ECDSA P-256 signatures and TrustZone-M isolation on Cortex-M33/M55, you can prevent unauthorized code execution while adding under 100 ms to boot time.

How Did We Implement Secure Boot for an Industrial IoT Product?

When we implemented secure boot for a client's industrial IoT gateway at EmbedCrest, we used an STM32L5 (Cortex-M33 with TrustZone) running MCUboot in the Secure Processing Environment. The boot chain consisted of three stages: the ROM bootloader (immutable, stored in factory-programmed OTP) verified MCUboot using a SHA-256 hash stored in OTP fuses, MCUboot verified the TF-M Secure image using ECDSA P-256 with a public key embedded in the MCUboot binary, and TF-M verified the Non-Secure application firmware before jumping to it. We stored the ECDSA signing private key in an AWS CloudHSM, with the CI/CD pipeline (GitHub Actions) requesting signatures through a limited-access IAM role. This prevented any single engineer from accessing the private key. Total boot time overhead was 65 ms for the two signature verifications, well within the 500 ms boot budget. We also implemented anti-rollback protection using a monotonic counter stored in STM32L5 OTP bits, preventing downgrade attacks to firmware versions with known CVEs.

What Best Practices Ensure Secure Boot Remains Effective?

Secure boot is only as strong as its weakest link. Follow these engineering practices to maintain the integrity of your boot chain. Store signing keys exclusively in Hardware Security Modules (HSMs) such as AWS CloudHSM, Azure Dedicated HSM, or YubiHSM 2. Never store private keys in version control, CI environment variables, or developer workstations. Implement key rotation procedures with a planned transition period where both old and new public keys are accepted. Disable all debug interfaces (JTAG/SWD) on production devices using permanent fuse settings, not software configuration. Enable flash readout protection (RDP Level 2 on STM32) to prevent firmware extraction via debug probes. Implement monotonic version counters in OTP or secure storage to prevent rollback attacks. Test your secure boot implementation against the OWASP Firmware Security Testing Methodology, including glitch injection resistance if your threat model includes physical attackers with moderate resources.

How Does Secure Boot Performance Scale Across MCU Families?

Signature verification time varies significantly across Cortex-M families and depends on whether hardware crypto acceleration is available. On a Cortex-M0+ at 48 MHz without crypto hardware, RSA-2048 verification takes 800-1200 ms and ECDSA P-256 takes 300-500 ms, making secure boot painfully slow. On a Cortex-M4 at 168 MHz (STM32F4) with no crypto accelerator, RSA-2048 drops to 150-250 ms and ECDSA P-256 to 60-120 ms. On a Cortex-M33 at 110 MHz with hardware PKA (STM32L5, STM32U5), ECDSA P-256 verification completes in 8-15 ms, making it nearly imperceptible. Ed25519 signatures offer faster software verification than ECDSA P-256 (approximately 30% faster on Cortex-M4 without hardware acceleration) while providing equivalent 128-bit security. For applications requiring the fastest boot possible, choose an MCU with hardware crypto acceleration and use ECDSA P-256 or Ed25519 rather than RSA.