Secure boot is a key management decision

Verification is the easy half

Implementing signature verification in a bootloader is a well-understood task. The algorithm is standard, reference implementations exist, silicon vendors supply the primitives, and a competent firmware engineer can have a verified boot chain working in a few weeks.

Then the product ships, and the questions start. The release engineer who held the signing credential leaves. A contract manufacturer asks to sign test images. A security advisory requires revoking a build that is already in the field. Legal asks how long the key must remain available. A new hardware revision uses a different secure element. Someone discovers that the development key was accepted by two hundred production units.

None of these are verification problems. They are key management problems, and they are much harder to fix afterwards, because the verification root in most designs is written once and never again.

Decide what is immutable before production

The defining constraint of secure boot is that the trust anchor is usually not changeable. A hash of the root public key is burned into one-time-programmable fuses or stored in immutable ROM, and from that moment the set of keys the device will ever trust is fixed.

Designs differ in how much flexibility they leave, and the difference is worth understanding before the silicon is chosen:

The third arrangement is the most common good answer for a long-lived product: the immutable root is used rarely, kept offline, and signs an intermediate that signs firmware. Day-to-day signing risk then attaches to the intermediate, which can be replaced.

NIST SP 800-193 treats this as part of protection: the root of trust for update must itself be protected against unauthorised modification, and the recovery path must not depend on the component being recovered. The same reasoning applies to keys—a rotation mechanism that requires a working firmware to perform the rotation cannot recover from a bad firmware.

Custody: no individual should be able to sign

The requirement is straightforward to state and frequently not met: producing a firmware image that devices will trust should not be possible for any single person or any single credential.

A workable arrangement has four properties. The key material lives in a hardware security module or equivalent validated module, so it cannot be copied; FIPS 140-3 validation is the usual assurance reference for this. Signing happens through an automated release process rather than a person with a tool, so the signed input is an artefact the pipeline produced from a reviewed revision. Authorisation requires a quorum for production releases, so one compromised account is insufficient. And every use of the key is logged with the artefact digest, so the set of images that were ever signed is knowable.

The last property is the one that makes incident response possible. When you need to determine whether an unexpected image could have come from your pipeline, the answer should be a query rather than an investigation.

Development and production must use different keys, and the device lifecycle state must determine which is accepted. The failure where a development key is trusted by production units is common enough to be worth an explicit test in manufacturing: attempt to boot a development-signed image on a production unit and require it to fail.

Plan rotation while rotation is still possible

Signing keys need to change for unremarkable reasons: a scheduled cryptoperiod, a personnel change, a move to a new module, an acquisition, an algorithm deprecation. NIST SP 800-57 frames this as assigning each key a defined cryptoperiod, which implies a mechanism for what happens at the end of it.

For firmware signing, rotation is a fleet operation and needs to be designed as one:

• devices must accept images signed by the new key before the old key stops being used, which means a period where both are valid;
• the update that introduces the new trust must itself be signed by the old key, so the order of operations is fixed;
• devices that miss the transition window must still have a route back, which usually means the recovery image trusts a longer-lived anchor;
• the anti-rollback counter must not prevent the transitional image from installing.

Rehearse this on real hardware, including a unit that skips the transitional release. The common discovery is that the rotation works on a device that takes every update and strands the fraction that does not.

Revocation needs somewhere to write

Revoking a compromised signing key or a specific bad image requires the device to remember the revocation across reboots and to refuse to be told otherwise. That means protected, monotonic storage—fuses for a counter, or an authenticated store that the bootloader trusts.

Two distinct needs are often conflated. Revoking a key is coarse and permanent: the device will never again accept images signed by it, which is what a compromise demands. Revoking a version is finer: the device refuses to install or execute builds below a threshold, which is what a vulnerable release demands. A monotonic version counter handles the second; the first needs either a spare root slot or a revocable intermediate.

Neither works without a plan for devices that are offline when the revocation is issued. A device that has not connected since before the compromise will still accept the bad key, and no protocol fixes that. The answer is usually to shorten the window—shorter certificate validity for intermediates, and update checks that are mandatory rather than optional at first connection.

Algorithm choice outlives the product team

A device shipping now with a ten to fifteen year service life will be verifying signatures well into the 2040s. The algorithm and key size chosen today are therefore commitments across a period in which cryptographic guidance will change at least once.

Two consequences follow. The first is to provision more algorithm flexibility than current needs require—space for a larger key, a signature field sized generously, and a version field in the image header that lets a future bootloader dispatch on scheme. The second is to consider whether a quantum-resistant signature belongs in the design now. The UK’s migration timelines guidance asks organisations to complete high-priority migration by 2031 and the remainder by 2035, which for a product shipping today falls inside the support window.

Firmware signing is unusually well served here, because hash-based signatures such as the Leighton-Micali scheme are standardised, conservative and a natural fit: verification is cheap, the state management burden falls on the signing side where an HSM can handle it, and the number of signatures a firmware key needs to produce is small and predictable.

The questions worth settling on paper

Before the boot chain is implemented, a short document should answer: which anchor design the silicon supports and which one you are using; who can authorise a production signature and how many of them are required; where each key lives and under which validation; what the cryptoperiod is for each key and what the rotation sequence is; what the device does when verification fails; how a revocation is delivered and stored; and what the recovery image trusts.

Seven answers, most of them a sentence. The reason to write them down is that six of the seven become expensive or impossible to change once the first production run is complete, and the team that made the decisions will not be the team that lives with them.