Secure Boot Is a Chain. The Weak Link Is Key Management, Not Code.

Secure boot is one of those features that sounds finished the moment it is described. Each stage of the boot process cryptographically verifies the next before handing over control; the first stage is immutable and trusted by construction; therefore only authentic firmware runs. Written on a slide, the property is airtight. The trouble is that the slide describes the cryptography, and the cryptography is almost never where secure boot fails.

What fails is everything around the signature: where the keys are generated, who can reach them, how many devices share one, whether an old image can be replayed, and whether a leaked key can ever be retired. Those are not cryptographic questions. They are operational ones, and they are the questions a serious review spends its time on.

The chain, stated precisely

A verified boot chain is a sequence of hand-offs. Immutable Boot ROM — code fixed in silicon at manufacture — is the root of trust. It verifies a signature over the first writable stage, typically a bootloader, against a public key whose authenticity is anchored by a hash or key fingerprint burned into one-time-programmable (OTP) fuses. If the signature checks out, the bootloader runs, and it in turn verifies the next image: a second-stage loader, then an OS or RTOS kernel, then the application payload. Each link refuses to execute the next unless the signature holds.

It is worth separating two ideas that get blurred. Verified boot enforces: a bad signature halts the boot. Measured boot records: each stage hashes the next into a tamper-evident register — a TPM PCR or equivalent — so the boot can later be proven to a remote verifier. They solve different problems. Verified boot keeps a device from running attacker firmware on its own; measured boot lets something else decide whether to trust the device afterward. Many designs implement one and quietly assume they have the benefits of both.

The failure is upstream of the device

Put the cryptography aside — assume the signature verification is correct and the algorithm is sound. The device is still only as trustworthy as the private key that signs its firmware, and that key does not live on the device. It lives in your build pipeline. This is where most of the real risk sits, and it rarely shows up in a datasheet.

• Keys on a build machine — If the signing key sits on an engineer's laptop or unprotected in CI, then the security of every device in the field is the security of that one host. A compromised developer account signs malicious firmware the whole fleet will accept as genuine.
• One key for everything — A single key shared across an entire product line means a single compromise is a fleet-wide event. There is no containment, because the trust anchor does not distinguish one device, model, or generation from another.
• No hierarchy — Development and production share a key; there is no per-model or per-stage separation. A key leaked from a lab bench signs production firmware, and nothing in the design treats those two worlds differently.
• No rollback protection — Even with perfect keys, an attacker who can reflash takes a genuinely signed older image with a known vulnerability and installs it. The signature is valid; the firmware is exploitable. The chain happily verifies its own undoing.
• No revocation path — When a key does leak, can you retire it? For many shipped devices the honest answer is no: there is no provisioned successor and no mechanism to tell the field that the old anchor is dead.

The cryptography almost never breaks. The key that the cryptography depends on breaks all the time — because it was treated as a build artifact rather than as the most sensitive asset the product has.

Rollback protection and the recovery tension

Rollback protection usually means a monotonic counter — a fuse-backed or secure-storage value that only ever increases. Firmware carries a security version; the device refuses to boot an image whose version is below the stored counter; successful updates advance it. This is what stops the replay of old signed images.

It also introduces a real design tension. A counter you can never decrease means a botched update or a bad batch can brick devices with no field path back. A counter you can bypass "for recovery" is a counter an attacker will use for exactly that. Resolving this honestly — a recovery mode that itself requires authentication, staged rollout so a bad version never reaches the whole fleet, a version policy that distinguishes a functional downgrade from a security-relevant one — is design work that has to happen before the product ships. Retrofitting it into fielded hardware is often impossible, because the fuses are already the shape they are.

Revocation is the part everyone skips

Key revocation is where secure-boot designs most often reveal they were never finished. Generating a root key is easy. Planning for the day it leaks is not, and it has to be planned at silicon-provisioning time, because OTP space for additional key hashes and the logic to prefer a newer anchor over a revoked one both have to exist before the device leaves the factory. A design with exactly one root key and no provisioned successor has made an implicit bet that the key will never be compromised across the entire service life of the hardware. For a device that lives ten or fifteen years in the field, that is not a bet worth making silently.

What a defensible root of trust looks like

None of this requires exotic technology. It requires treating the signing key as the crown jewel it is, and designing the lifecycle around the assumption that things go wrong.

• Keys are born in hardware and never leave it — generated inside an HSM or equivalent, used for signing by reference, never exported to a filesystem. The build pipeline asks the HSM to sign; it never holds the key.
• There is a documented key hierarchy — separate anchors for development and production, and separation by product or stage so that one compromise is contained rather than fleet-wide.
• Rollback counters are wired to a real version policy — not a field someone remembers to bump, but a policy tied to the release process, with an authenticated recovery path that an attacker cannot invoke.
• At least one successor root is provisioned — OTP space and anchor-selection logic that make revocation a procedure you have rehearsed, not a redesign you cannot perform.
• Boot state is measured and actually attested — measurements that a remote verifier checks before granting the device access to anything sensitive, so that a measured boot is a control rather than a decoration.
• The whole scheme is threat-modeled against a physical attacker — someone with the device on a bench, a logic analyzer, and patience, because for most embedded products that is the realistic adversary.

Secure boot earns its name at the seams — key custody, rollback policy, revocation, attestation — not in the signature check that every vendor implements. When 6QURE reviews an embedded secure-boot design, that is where the hours go: following the private key from the moment it is generated to the moment a device in the field decides to trust it, and asking at each hand-off what an attacker who reached that point could do. It is unglamorous work, and it is the work that decides whether the chain holds.