Explain the secure boot chain from ROM to application

A secure boot chain establishes a root of trust anchored in immutable hardware and extends that trust through each stage of the boot process using cryptographic signature verification. The chain begins in ROM (Read-Only Memory) — code burned into the silicon during manufacturing that cannot be modified. This Boot ROM contains the first-stage bootloader and, critically, the public key hash (or the public key itself) used to verify the next boot stage. Because the ROM is immutable, an attacker cannot replace the root of trust without physically replacing the chip. The Boot ROM loads the second-stage bootloader (often called SPL, U-Boot, or a manufacturer-specific bootloader) from flash, computes a cryptographic hash (SHA-256) of the binary, verifies the hash against a digital signature using the root public key (RSA-2048/4096 or ECDSA-P256), and only transfers execution if verification passes.

The second-stage bootloader repeats this process for the next stage — typically the application firmware or an operating system kernel. It loads the image from flash, verifies its signature against a key that was itself authenticated in the previous step (this key may be embedded in the signed bootloader image or stored in a protected key store), and jumps to the application only on success. This creates a chain of trust: ROM verifies bootloader, bootloader verifies firmware, and optionally firmware verifies application-level components. If any stage fails verification, the boot process halts or enters a recovery mode. On more complex systems (embedded Linux), the chain might be: ROM, SPL, U-Boot, kernel, and root filesystem, with each stage verifying the next.

The security of the entire chain depends on several implementation details that interviewers probe: (1) Key storage — the root public key hash must be stored in OTP (One-Time Programmable) fuses, not in writable flash, otherwise an attacker can replace the key and sign their own malicious firmware. (2) Rollback protection — without an anti-rollback counter (also in OTP fuses), an attacker can flash an older, signed firmware version that has known vulnerabilities. (3) JTAG/debug port lockdown — if the debug port is open, an attacker can bypass secure boot entirely by loading code directly into RAM. (4) Fault injection resistance — glitching the power supply or clock during signature verification can cause the check to pass incorrectly; hardened implementations verify the signature twice or use constant-time comparison. Platforms like ARM TrustZone, NXP HAB (High Assurance Boot), STM32 SBSFU, and TI TIFS implement these concepts with varying levels of sophistication.