security root of trust design
# Hardware Root of Trust
Every chain of trust has to start somewhere, and software alone can never be that starting point — any verification step implemented purely in software can, in principle, be subverted by software running underneath it. A hardware root of trust is the anchor that breaks that regress: a small, immutable block of silicon whose own correctness is established by the manufacturing process itself rather than by anything checked at runtime, providing the one link in the chain that doesn't need to trust anything below it.
The root's immutability comes from physically burning its contents in at manufacturing, not from any software protection layered on afterward. A root key or initial boot-verification code gets written into one-time-programmable fuses or a masked ROM during chip fabrication — structures that are physically incapable of being rewritten once set, unlike flash memory, which can always in principle be reprogrammed by someone with the right access or the right exploit. That physical immutability is the actual security property at stake: a root of trust implemented in rewritable memory isn't really a root of trust at all, because anything that can overwrite the root can also fake what the root is supposed to guarantee.
The root verifies the next stage before handing it control, and that handoff pattern repeats all the way up to the application layer — a secure boot chain is this root-of-trust property applied step by step. The immutable boot code's first and only job is to cryptographically verify the signature on the next stage (typically a bootloader) before executing a single instruction of it; a verified bootloader then does the same check on the OS kernel it loads; a verified kernel can extend the same pattern to application code or firmware updates. Each link only has to trust the signature check performed by the link below it, and the entire chain's integrity ultimately traces back to whether that very first, hardware-anchored check was itself unforgeable — which is precisely what makes the root of trust the single most security-critical few square microns on the whole die.
A hardware root of trust typically pairs its immutable boot anchor with a secure key-storage and cryptographic-acceleration block, since verifying signatures and managing keys both need to happen somewhere an attacker with OS-level access still can't reach. Dedicated secure elements — isolated processor cores with their own private memory, running independently of the main application processor — hold provisioned keys and perform signature verification and encryption operations without ever exposing the key material to the main OS, even if that OS is fully compromised. A PUF (id 12520) can supply exactly this kind of key material without ever storing it anywhere persistent, making PUF-derived keys a natural pairing with a hardware root of trust that needs a device-unique secret it can trust without having provisioned or recorded that secret anywhere.
Glitch attacks (572) target exactly this kind of security-critical verification logic, attempting to fault the signature check itself into reporting success on unsigned or malicious code — which is why root-of-trust silicon specifically layers in the voltage/clock sensing and redundant-computation countermeasures covered there, rather than assuming cryptographic correctness alone is enough once an attacker can physically disturb the chip performing the check.