We have spent ten thousand words breaking things. The defender's question is: how to design so that breaking is uneconomic.
11.1 Threat modeling
STRIDE (Spoofing, Tampering, Repudiation, Information disclosure, Denial of service, Elevation of privilege) was originally a Microsoft software-security framework. Adapted to hardware:
For each STRIDE row, ask: which attack class applies, what's the cost to mount, what's our cost to defend, what's our risk tolerance.
11.2 Cost vs. assurance
There is no "secure" without "secure against whom". A bicycle lock keeps out opportunistic thieves; it does not stop a workshop with bolt cutters. Pick the assurance level that matches the asset value and the adversary's likely budget. A consumer IoT bulb does not need FIPS Level 4. A smart meter needs side-channel resistance. A bank HSM needs everything.
The Common Criteria framework provides one quantification through Evaluation Assurance Levels (EAL):
- EAL1. Functionally tested. Minimal.
- EAL2. Structurally tested.
- EAL3. Methodically tested and checked.
- EAL4. Methodically designed, tested, reviewed. Common ceiling for commercial products.
- EAL5. Semiformally designed and tested.
- EAL6. Semiformally verified.
- EAL7. Formally verified design and tested. Defense / national-security grade.
The point of the levels is to communicate the depth of evaluation, not the strength of the result. A poorly designed product evaluated at EAL7 is still poor; a well-designed product evaluated at EAL2 may still be excellent. Assurance levels measure process, not outcome.
11.3 Open versus closed
The open-versus-closed debate runs through hardware security. Closed designs (proprietary, NDA-protected, security-by-obscurity-leaning) are easier to ship quickly but tend to harbor flaws that emerge years later (Mifare Classic). Open designs (OpenTitan, RISC-V cores, open ASIC bitstreams) accept that the design is public and rely on cryptographic strength, transparent review, and reproducible builds. The open approach has been winning intellectually for a decade and is starting to win practically with OpenTitan in production at Google and elsewhere.
11.4 Defense in depth
No single countermeasure is sufficient. The right architecture stacks countermeasures so that defeating any one of them only buys the attacker a small amount of progress:
Application layer: constant-time crypto, MAC verification
OS layer: secure boot, KASLR, control flow integrity
Hypervisor: VM isolation, encrypted memory
CPU: hardware crypto, side-channel-hardened ISA, TEE
Boot: ROM root-of-trust, anti-rollback fuses, signed BL
Hardware: dual-rail, masking, sensors, mesh, PUF-derived keys
Package: tamper-evident, conformal coat
System: physical security, supply-chain assuranceA break at any one layer should cost the attacker time and noise, and the layer above should detect and respond. This is the architectural lesson of the entire chapter.