How Does Secure Boot Work on Embedded Linux? A Technical Deep Dive

What is Secure Boot in Embedded Linux? A Guide to Secure Boot Embedded Linux

Secure boot on embedded Linux is a mechanism that cryptographically verifies every software component in the boot sequence — from the ROM bootloader through the SoC bootloader, U-Boot, the Linux kernel, and optionally the root filesystem — before executing it. Each stage verifies the signature of the next stage using a chain of trust rooted in hardware. If any stage fails verification, boot halts, preventing execution of tampered or unauthorised firmware on your embedded Linux product. Implementing secure boot embedded Linux is now mandatory for automotive (ISO 21434), industrial (IEC 62443), and medical device products.

The Chain of Trust in Embedded Systems: How Secure Boot Embedded Linux Works

The chain of trust in embedded systems is the sequence of cryptographic verifications that constitutes the backbone of secure boot embedded Linux that links hardware-immutable root keys to the application layer:

1. Hardware Root of Trust: The SoC contains an immutable ROM bootloader that runs first. This ROM code is manufactured into silicon and cannot be modified. It contains (or verifies against) the public keys burned into One-Time Programmable (OTP) fuses on the device — the root of the chain of trust.
2. Stage 1 Bootloader (SPL/BL1/BL2): The ROM bootloader verifies the first loaded software stage (SPL in U-Boot terms, or BL1/BL2 in ARM Trusted Firmware-A) using the hardware root public key.
3. U-Boot Verified Boot: Once running, U-Boot uses its own FIT (Flattened Image Tree) image signing to verify the Linux kernel, DTB, and initramfs before loading them. The public keys for this verification are embedded in U-Boot itself, which was already verified.
4. Kernel to Rootfs: The Linux kernel can verify the root filesystem using dm-verity (a device-mapper target that provides transparent integrity checking of block devices) — completing the chain of trust from silicon to application.

U-Boot Verified Boot: Implementation Details

U-Boot verified boot is the most commonly implemented secure boot layer in embedded Linux products:

• FIT Image: The bootable image is packaged as a Flattened Image Tree (FIT), an ITB binary that contains the kernel, DTB, and initramfs as separate nodes with their cryptographic hashes.
• Signing: FIT images are signed offline using RSA-2048 or RSA-4096 private keys with SHA-256 hash. The signing tool (mkimage) produces a signed .itb image.
• Key embedding: The corresponding public key is embedded in the U-Boot device tree, which is verified by the previous boot stage. U-Boot uses this embedded public key to verify the FIT image at boot time.
• Verification at boot: At runtime, U-Boot reads the FIT image, extracts each component, recomputes the hash, and verifies the signature against the embedded public key. A mismatch halts boot.

SoC-Specific Secure Boot Implementations

NXP HAB (High Assurance Boot)

NXP i.MX processors (i.MX6, i.MX7, i.MX8) implement secure boot via HAB (High Assurance Boot). The HAB framework uses Super Root Keys (SRKs) burned into OTP fuses to verify the initial bootloader image. HAB fusing is a one-time, irreversible operation that permanently binds the device to the key set used for signing. Once HAB is enabled, unsigned or incorrectly signed images are rejected.

ARM Trusted Firmware-A (TF-A)

For ARM Cortex-A SoCs, TF-A implements a secure boot flow following the ARM Trusted Board Boot Requirements (TBBR) specification. BL1 (in ROM) verifies BL2; BL2 verifies BL31 (secure firmware), BL32 (optional TEE), and BL33 (U-Boot or other non-secure bootloader). Each stage is verified using RSA or ECDSA signatures against certificates in a chain rooted at the Trusted Root Key (ROTPK).

Completing Secure Boot: dm-verity for Root Filesystem Integrity

U-Boot verified boot protects the kernel but not the root filesystem. dm-verity adds root filesystem integrity to the chain of trust in embedded systems:

• The root filesystem partition is made read-only.
• A hash tree covering every 4KB block of the filesystem is pre-computed and stored in a separate hash partition.
• A root hash of the entire hash tree is signed and embedded in the kernel command line or initramfs.
• At runtime, dm-verity verifies each block as it is read — a tampered block causes an I/O error rather than being silently served to the application.

Secure Boot Implementation Checklist

• Select hardware with HAB, TF-A, or equivalent ROM-level secure boot support.
• Generate and securely manage RSA/ECDSA key pairs — private keys never touch production hardware.
• Integrate signing into your build pipeline (CI/CD).
• Test the complete chain: verify that a tampered image is rejected at each stage.
• Implement OTA update signing — new firmware must be signed before deployment to maintain the chain of trust.
• Plan for key rotation before fusing — if a key is compromised before fusing, you can change it; after fusing, the device is permanently bound.

Embien's Secure Boot Embedded Linux and Chain of Trust in Embedded Systems Services

Embien Technologies implements secure boot embedded Linux solutions across NXP i.MX (HAB-based), Renesas RZ (TF-A), Qualcomm, and Xilinx/AMD Zynq platforms. Our security engineering team covers the complete implementation: SRK key generation and management, HAB fusing procedures, U-Boot verified boot with FIT image signing, dm-verity root filesystem protection, and secure OTA update pipelines.

We also support ISO 21434 automotive cybersecurity requirements and IEC 62443 industrial security standards for clients in automotive and industrial IoT sectors, where chain of trust in embedded systems is mandated by regulation.