Secure boot on ARM Linux devices: the chain from boot ROM to your application

“We have secure boot” is one of the least informative sentences in embedded engineering. It can mean a fused root key and a verified chain all the way to a read-only, integrity-checked root filesystem with anti-rollback counters. It can also mean that U-Boot checks a signature on the kernel while the U-Boot binary itself is replaceable from an SD card. Both teams will say the same sentence in the same tone.

Secure boot is a chain. Every link verifies the next before running it, starting from something that cannot be changed. This article walks the chain as it exists on most ARM Linux devices, then covers the parts that are not about cryptography at all: key handling, anti-rollback, and the debug ports everybody forgets.

The chain, link by link

Link 0: the boot ROM and the fuses

Every SoC starts in mask ROM that cannot be modified. When secure boot is enabled in one-time-programmable fuses, the ROM will only execute a first-stage image whose signature verifies against a public key (or a hash of a key table) that is also burned into fuses. This is the root of trust. Everything else can be updated; this cannot, and burning it is irreversible, which is why it is done at the end of manufacturing and not on the first prototype.

Vendors name this differently: NXP calls it HAB (High Assurance Boot) on older i.MX parts and AHAB on newer ones; TI’s K3 family uses “high security” device variants with a signed boot image; STMicroelectronics’ STM32MP1 verifies the first-stage loader against keys in OTP; Rockchip, Allwinner and others have their own. On Raspberry Pi 4 and Compute Module 4 the boot EEPROM can be configured to accept only a signed boot.img, with the key hash held in OTP. The mechanisms differ; the shape is identical.

Link 1: first-stage loader and Arm Trusted Firmware

The ROM loads a small first stage (U-Boot SPL, or TF-A’s BL2) which initialises DRAM and loads the next images. On modern ARM64 designs that next stage is Arm Trusted Firmware’s BL31, the secure monitor that stays resident and provides PSCI, plus optionally BL32, a trusted OS such as OP-TEE. TF-A’s Trusted Board Boot verifies each image against a certificate chain rooted in a key whose hash is in fuses or in the ROM-verified BL2. If you are not using Trusted Board Boot, everything from here on is verified only by U-Boot, and U-Boot itself is only as protected as Link 0 makes it.

Link 2: U-Boot and the FIT image

U-Boot (BL33) verifies the kernel, device tree and initramfs using its verified-boot support: the images are packaged in a Flattened Image Tree, signed with a private key, and U-Boot checks them against a public key compiled into its own device tree. Two details matter:

• Sign configurations, not just images. A FIT can contain several kernels and device trees and several configurations that combine them. If only the individual images are signed, an attacker can construct a configuration that pairs a signed kernel with a signed but wrong device tree. Signing the configuration node, with the key marked required = "conf", closes this.
• Make verification mandatory. With the key marked required, U-Boot refuses to boot an unsigned or badly signed FIT. Without that, verification is advisory and prints a warning nobody reads.

Link 3: kernel and root filesystem

The kernel is now trusted; the root filesystem is not. The two standard answers are a signed initramfs that contains the application (for small systems) or dm-verity over a read-only root filesystem. dm-verity computes a Merkle tree over the filesystem at build time; the root hash goes on the kernel command line inside the signed FIT, and every block is verified against the tree when it is read. Tampering with the filesystem produces an I/O error rather than silently running modified code. Because the filesystem must be read-only, writable state goes on a separate partition, usually encrypted with a key that only this device can unwrap.

On top of that, kernel lockdown mode prevents even root from loading unsigned modules or writing to /dev/mem, and module signing enforcement makes sure that out-of-tree drivers are part of the chain rather than a hole in it.

Link 4: updates

The chain is only complete if the update system respects it. New FIT images and root filesystems must be signed with the same keys the bootloader trusts, written to an inactive slot, and only then made bootable. We cover the update side in Designing over-the-air updates that survive power loss, bad networks and bad releases.

Verified boot is not measured boot

Verified boot refuses to run code that does not verify. Measured boot runs whatever is there but records a hash of each stage into a Trusted Platform Module’s platform configuration registers, so that later a remote party can ask the TPM to sign those registers and prove what booted. The two are complementary: verified boot for enforcement on the device, measured boot for evidence in the cloud. A discrete TPM or a firmware TPM implemented in OP-TEE provides the registers; the cloud side, which decides whether a device’s attestation is acceptable before it receives credentials or updates, is where the value appears.

Anti-rollback

A validly signed image with a known vulnerability is still validly signed. Without anti-rollback, an attacker with write access to storage can downgrade the device to it. Each stage that verifies the next should also check a version number against a monotonic counter the device cannot decrement: fuses (a small number of bits, so they are spent carefully, on security-relevant releases only), or a replay-protected memory block in eMMC accessed through the trusted OS. Design the counter policy with the update team before the first release; retrofitting it means an update that itself cannot be rolled back.

Keys: where most secure-boot designs actually fail

• Separate keys per stage and per purpose. The root key that is fused should sign only the next-stage key. Release signing, development signing and per-device identity keys are different keys with different holders.
• Private keys live in an HSM or a signing service, not in a repository, a CI variable or a laptop. Signing is an API call from the release pipeline with an audit log.
• Plan revocation on day one. Most fuse-based schemes let you burn a hash of a key table with several entries and revoke individual entries later. Use it: a key you cannot revoke is a key you cannot lose.
• Development devices use development keys. Never sign a debug build with the production key to save a day; the debug build is now a production-signed image with a shell in it.

The holes that are not cryptographic

• The U-Boot console. If a serial cable and a keypress at boot get you a U-Boot prompt, you can boot anything. Disable autoboot interruption in production builds (CONFIG_BOOTDELAY=-2 or the equivalent), and remove commands that load and execute arbitrary memory.
• Alternate boot sources. The fuses decide whether the ROM will boot from USB or SD when the primary storage fails. Recovery modes that skip verification are a bypass, not a feature.
• JTAG and SWD. Debug access on a production device is full access. Fuse it off, or gate it behind an authenticated debug mechanism if the SoC has one.
• The device tree. If the device tree is not covered by the signature, an attacker can change where the kernel thinks the console, the storage or the security hardware lives.
• The command line. init=/bin/sh is a classic. The kernel command line must be inside the signed image, and U-Boot must not append user-controlled variables to it.