The defender's question: how does a system know it is running legitimate firmware? The answer is a chain of trust.
4.1 The chain
Each stage cryptographically verifies the next before handing control. Verification is a public-key signature check (RSA-2048, ECDSA, or Ed25519): the OEM signs each firmware blob with their private key, the verifier holds the public key (or a hash of it), the verifier computes a hash of the candidate firmware, then checks that the signature is valid for that hash under the OEM public key.
The chain is only as strong as the root. The root is the boot ROM, which is mask-programmed at fab time and contains the OEM root public-key hash. If the boot ROM is compromised, the entire chain is compromised, and you cannot fix it in the field. The Apple checkm8 exploit (2019) targeted a USB stack bug inside the boot ROM of A5 through A11 chips, an unfixable hole in hundreds of millions of devices.
4.2 Anti-rollback
A naive chain trusts "any signed version" of the firmware. Attackers exploit this by downgrading to a known-vulnerable version that the OEM signed once and now wishes they hadn't. Defense: a monotonic counter stored in OTP fuses (one-time-programmable poly-fuses, blown irreversibly during firmware update). Every firmware version is tagged with a minimum-version field, and the ROM refuses to load firmware whose minimum-version is below the fuse counter's current value. Once a counter is incremented, the chip cannot run old versions even if signed.
4.3 Hardware roots: TPM, SE, TrustZone, SGX, SEV
-
TPM 2.0 (Trusted Platform Module). Standardized chip with a small set of capabilities: PCRs (Platform Configuration Registers, hash chains of measurements), sealed storage (data only released if PCRs match a policy), key generation, attestation. PCs include a TPM either as a discrete chip or as fTPM running inside a CPU's secure mode.
-
Apple Secure Enclave Processor (SEP). A separate ARM core inside Apple's A-series and M-series chips. Has its own boot ROM, runs sepOS, holds the Touch ID/Face ID and key-store secrets. The application processor cannot read SEP memory; it can only ask SEP to perform operations. The iPhone 5c vs 5s case (FBI vs. Apple, 2016) hinged on this: the 5c had no SEP, the FBI brute-forced the PIN; the 5s had SEP, brute-force was rate-limited at the silicon level.
-
ARM TrustZone. Splits the CPU into "normal world" and "secure world" with bus-level isolation: the secure world has its own memory, peripherals, and interrupt handlers, and the MMU enforces that normal-world code cannot see secure-world memory. Used in essentially every modern Android phone for DRM, key storage, and biometric processing. Repeatedly compromised by side channels and fault injection over the past decade, because the hardware boundary, while real, is not as deep as a separate die.
-
Intel SGX (Software Guard Extensions). Enclaves: pages of memory encrypted to a specific code identity, accessible only to that code. Originally pitched as enabling cloud customers to run sensitive code on untrusted servers. The model has been progressively broken by Foreshadow (L1TF, 2018), Plundervolt, SGAxe, ÆPIC Leak, and a series of MDS variants. Intel deprecated client-side SGX in 11th-gen Core CPUs. The case study of SGX is sobering: a featureful, well-engineered HW-isolation primitive was repeatedly defeated by side channels in the very microarchitecture it ran on.
-
AMD SEV (Secure Encrypted Virtualization). Encrypts each VM's memory with a per-VM key managed by a security processor on the AMD CPU. SEV-ES adds register-state encryption; SEV-SNP adds integrity. Targeted at confidential computing in clouds. Has its own history of attacks (CipherLeaks, undeSErVed, SEV-Step) but the primitives keep evolving.
-
Google Titan / Pixel Titan M. Discrete secure-element chip in Pixel phones and Cloud servers, with its own ROM, runs Trusty OS, holds the device-binding keys.
-
OpenTitan. Open-source secure element specification and reference implementation. RISC-V based, transparent supply chain, growing adoption. The first serious open root-of-trust that aspires to rival closed offerings.
The pattern across all of these: a small, hardened, mask-programmed root performs a few critical operations and refuses to expose its secrets even to its host CPU. The cost of breaking this root is what defines the security of the system above it.