Secure boot answers one question: why should the ROM trust the image it is about to jump to. The answer is a chain: immutable ROM trusts fused keys, the keys authenticate the next image, and each image authenticates the next before handing over control. No step trusts what it has not verified, and the chain starts in hardware that software cannot change. This topic teaches the chain at a conceptual level with no cryptographic parameters: what must be immutable, what must be fused, and what happens when verification fails. For the bring-up view see Secure Boot Enablement and Fuse Bring-up.
Lesson | After it you can... |
|---|---|
Draw the NanoSoC trust chain and say what is immutable at each link. | |
Explain verification of an image without naming any crypto parameters. | |
Define what the ROM does when authentication fails, and how the device recovers. |
Suggested order: top to bottom. Establish the chain and its anchor first, because authentication is meaningless without a root; then verify images against it; then handle failure, which is where insecure shortcuts hide. The security-architecture topic turns this chain into enforced partitions.
Because software can be replaced by an attacker, so trust placed in rewritable code is circular: the verifier itself could be the thing that was changed. Immutability breaks the circle by giving trust somewhere it cannot be edited from.