Phase 13 — Hardware, Firmware, and Device Security
Track: Elite / Principal | Duration: 8 weeks | Prerequisites: Phases 01, 04, 05
Objective: anchor trust in silicon. Become able to reason about, assess, and build verifiers for the layers beneath the operating system — the hardware root of trust, the boot chain, measured boot and the TPM, remote attestation, TEEs and confidential computing, firmware security, and secure update with anti-rollback. This is the assurance foundation FAANG device/cloud-platform teams and critical open-source RoT projects (OpenTitan, coreboot, Verified Boot, Sigstore-adjacent attestation) are built on, and the basis of the hardware requirements in FedRAMP High / DoD IL5.
Deep guides: WARMUP.md derives the whole stack from first principles; HITCHHIKERS-GUIDE.md is the operator's manual for measuring, attesting, and hardening real platforms.
Why This Phase Exists
Every control in Phases 00–12 runs as software, and software is only trustworthy if the layers beneath it are. The most valuable, most persistent compromises — firmware implants, evil-maid bootkits, malicious microcode — live below the OS, where software defenses can't see them. A principal security engineer must be able to answer, with cryptography rooted in hardware: is this device the genuine, unmodified thing I think it is, and can it prove it to me remotely before I trust it with secrets or network access? That capability is what makes zero-trust device fleets, confidential computing, and hardware-backed key management possible — and it is what lets you offer customers provable ("we literally cannot read your data"), not merely promised, security.
Core Topics
- Hardware root of trust (boot ROM, fused keys, OTP/eFuses), RTV vs RTM, dedicated security processors (Secure Enclave, Titan/OpenTitan, Pluton, discrete TPM).
- Boot chain of trust: verified boot (UEFI Secure Boot, Android Verified Boot, ARM TF) vs measured boot.
- TPM 2.0: PCRs, the extend operation, the event log, key hierarchies, EK/AK.
- Remote attestation: nonce, quote, AK→EK chain, golden values, event-log replay; zero-trust device fleets and confidential-computing key release.
- TEEs and confidential computing: TrustZone, SGX, SEV-SNP/TDX/CCA; enclave attestation.
- Firmware security: UEFI/SMM (ring -2), ME/PSP/BMC, SPI flash write-protection, NIST 800-193 resilience.
- Secure firmware update / secure OTA: authenticity, integrity, model binding, anti-rollback (monotonic counters), A/B slots, TUF/Uptane.
- Key provisioning, DICE, the manufacturing trust boundary.
- Physical and side-channel threat model: timing/power/EM, fault injection/glitching, invasive attacks.
Labs
| Lab | Build | Core security idea |
|---|---|---|
| 01 Remote Attestation Verifier | TPM-style measured-boot + quote verifier | PCR extend, event-log replay, signed quote, nonce anti-replay, golden values |
| 02 Firmware Update Integrity | secure-OTA verifier with anti-rollback | authenticity, integrity, model binding, monotonic anti-rollback counter |
Both are pure-Python, offline, deterministic models faithful to the real mechanisms (the RSA/ECDSA/TPM signatures are deterministic stand-ins so the labs are reproducible). Run each:
LAB_MODULE=solution pytest -q
pytest -q
Capstone — Device Trust Assessment
Produce a device-trust assessment package for a fictional fleet (servers + IoT field devices):
- a root-of-trust and boot-chain diagram (RTV/RTM, where each link is verified/measured);
- a remote-attestation design (golden-value management, AK trust, nonce/freshness, fleet gating);
- a secure-update design (signing hierarchy, anti-rollback counter placement, A/B, recovery);
- a firmware-resilience plan (protect/detect/recover, NIST 800-193);
- a key-provisioning and DICE/identity design with the manufacturing threat model;
- a side-channel/physical-attack resistance statement (target level + honest limits);
- an executive memo: what "device trust" buys the business and customers, and residual risk.
Recommended Sources
TCG TPM 2.0 spec and PC Client Firmware Profile; NIST SP 800-147/155/164/193; UEFI Secure Boot; Android Verified Boot; Intel SGX/TDX and AMD SEV-SNP docs; Apple Platform Security Guide; OpenTitan and coreboot projects; Confidential Computing Consortium; Spectre/Meltdown and DPA/fault-injection literature.
Measurable Outcomes
- Verify a measured-boot attestation end to end and detect a tampered firmware measurement, a replayed quote, a forged quote, and an untrusted AK.
- Verify a firmware update and block an untrusted signer, a tampered payload, a cross-model flash, and a downgrade/rollback.
- Explain verified vs measured boot, enclave attestation, and the physical/side-channel threat model.
- Produce a defensible device-trust design with honest physical-attack-resistance limits.
Evaluation Checklist
- Explain why the root of trust must be immutable hardware.
- Trace the boot chain and label each link verified/measured.
- Explain the PCR extend and why it is un-rollback-able.
- Walk an attestation exchange and justify the nonce and the golden comparison.
- Explain anti-rollback and why a hardware monotonic counter is required.
- State a physical-attack-resistance target and its limits honestly.
Common Mistakes
- Treating signing as a root of trust (the root is the immutable verifier, not the signature).
- Believing measured boot prevents malware (it records; it does not enforce).
- Omitting the nonce from attestation (enabling replay of a captured good quote).
- Shipping signed updates with no anti-rollback (re-introducing patched bugs on demand).
- Trusting an enclave as a "magic safe" and ignoring side channels.
- Patching the OS and declaring a firmware-implanted box clean.
Interview Topics
Verified vs measured boot; the PCR extend; remote attestation and why the nonce; enclave/confidential-VM attestation and confidential computing; anti-rollback and monotonic counters; firmware/SMM/ME threat; side-channel and fault-injection defense; designing a zero-trust attested device fleet.