1. Purpose and scope
The security architecture decides what can be protected at all. Weak choices here cannot be fixed by careful design or testing later: a root of trust that shares memory with untrusted software, a debug port that a fuse cannot close, a key that has to be handled in clear on the test floor, or an algorithm the hardware cannot replace. This stage designs the security of the chip as a whole and allocates every requirement to an element that will meet it.
The architecture spans hardware, firmware and manufacturing. The boot chain starts in boot ROM code fixed at tape-out; the key hierarchy determines the provisioning flow at test; the lifecycle states determine how debug and failure analysis work for the life of the device; isolation decides what the operating system and applications must be trusted with. It must therefore be agreed with the chip, firmware, DFT and supply chain architects and baselined with the chip architecture.
In scope: the security architecture specification, the root of trust specification, the key management specification, the debug and lifecycle state specification, the cryptographic design and countermeasure specifications, the secure boot specification, the security verification plan and the first provisioning flow. Out of scope: implementation, which follows in Secure Design & Implementation.
14 more sections for registered members.