Hardware root of trust: why signed firmware alone is not enough

Firmware signing is necessary and insufficient. If an attacker reaches the layer that checks the signature, they control the answer. A root of trust breaks that circularity by anchoring the first check in hardware that cannot be rewritten.

The circular trust problem

Integrity checking is usually done by software running on the system being checked. A rootkit loading before the checker can present whatever the checker expects to see. The check returns green because the thing answering it is the thing you were trying to detect.

What a hardware anchor changes

A secure element or TPM holds verification keys in immutable storage. At power-on, hardware validates the bootloader before executing it; the bootloader validates the kernel; the kernel validates the application image. Each stage is verified by a stage that was itself verified, and the bottom of that chain is silicon rather than code.

The security property depends entirely on that anchor being genuinely immutable. A "secure boot" implementation whose keys live in rewritable flash provides considerably less than the datasheet implies.

Why routers and IoT specifically

These devices are long-lived, physically accessible, rarely monitored and sit at the point where compromise is most useful to an attacker. Firmware implants there persist across reboots and reimaging of everything above them, and endpoint tooling cannot see them at all.

What to require when specifying hardware

• An immutable hardware anchor — not keys in rewritable storage
• A documented, staged verification chain from power-on to application
• Anti-rollback protection, so a signed but vulnerable old image cannot be reinstalled
• A key rotation and revocation process that works on deployed field devices
• Remote attestation, so the device can prove its state to something other than itself

If a vendor cannot answer the rotation question, assume the keys are permanent for the life of the device and price the risk accordingly.