4

PCR0 & measured boot, step by step

goal: own what each register measures and why PCR0 is the anchor
objective Explain exactly what registers 0–7 hold, why a firmware update breaks locked secrets, and how disk encryption ties its key to register values.
Boot stages (each measures the next before running it) Registers CRTMfirst immutable code core firmware (the BIOS/UEFI) UEFI drivers & applications boot manager / boot loader Secure Boot key policy operating system kernel PCR0core firmware — ANCHOR PCR1firmware settings PCR2UEFI drivers + apps (code) PCR3their config & data PCR4boot manager + boot attempts PCR5boot settings + disk map PCR6maker-specific PCR7Secure Boot policy filled — the register holds code hollow — it holds that code's settings dashed edge — vendor-defined, not fixed by the Profile
The pattern is learnable at a glance: even registers hold code, odd registers hold that code's settings, and PCR7 holds the Secure Boot policy. BIOS = Basic Input/Output System; UEFI = Unified Extensible Firmware Interface — both names for the core startup firmware. Wording here matches Table 1 (PCR Usage) of the PC Client Platform Firmware Profile v1.06 r52 — checked, and worth checking yourself.

Why PCR0 is special — and its one weakness

  • PCR0 is the anchor: the first immutable code measures the core firmware into it before running it. Everything downstream hangs off this link.
  • The brittleness (draw this): update the firmware → its fingerprint changes → PCR0 changes → two things break, shown below.
firmwareupdated PCR0 changesnew fingerprint locked secrets won't unlocke.g. disk encryption asks for recovery key attestation values shiftthe checker's "known-good" list must update
This is the real-world gotcha. It's exactly why disk encryption prefers to bind to PCR7 (the signing policy, which survives a signed update) instead of PCR0, and why the dynamic root of trust from Phase 3 was invented.

Where measured boot is used (spoken-language)

at seal time at unseal time the secret a key, say chosen registers PCR7, say seal sealed secret current values right now sealed-to values recorded at seal compare equal → released if the values differ, the secret stays locked
Sealing locks a secret to a set of register values. The registers chosen at seal time are recorded alongside the secret, and it comes back only when those registers hold the same values again. That is the whole story behind the recovery-key prompt: a secret sealed to PCR7 survives a signed firmware update, and one sealed to PCR0 does not.
  • Sealing = locking a secret so it only unlocks if the chosen registers match. BitLocker (Windows disk encryption) usually binds to PCR7 so signed updates don't lock you out; older setups bind to PCR0/2/4 and then a firmware update triggers the recovery-key prompt.
  • Linux: systemd-cryptenroll defaults to PCR7; register 11 can hold a pre-computable kernel fingerprint so you can plan an update in advance.
  • The dynamic path: Intel's TXT (Trusted Execution Technology) and AMD's SKINIT instruction re-root trust at runtime; Microsoft ships this as "System Guard Secure Launch." Payoff: a handful of valid fingerprints instead of thousands of firmware variants.
lab 4 · make PCR0 real
  • Dump the boot event log (tpm2_eventlog) and find the events that build PCR0.
  • Seal a secret to PCR7, then change the firmware in a virtual machine and watch the unseal fail; re-seal.
  • Before booting, predict which registers change after (a) a firmware update, (b) enabling an add-in network card, (c) a kernel upgrade. Then check.
mastery gate 4

Redraw the boot-chain-to-registers diagram from memory with the even/odd/policy pattern. Explain why binding to PCR7 survives a firmware update but PCR0 does not.

sources
TCG PC Client Platform Firmware Profile v1.06 r52 — PDF · Intel TXT guide — PDF · Microsoft System Guard — MS · systemd-cryptenroll — man