3

Inside the security chip: how a PCR works

goal: run a chip and verify a signed report at the bit level
objective Operate a Trusted Platform Module (real or simulated), produce a signed report of its registers, and check that report yourself. This is the technical spine of everything.
the Attestation Key is itself vouched for by the chip's Endorsement Key Checker sends a challenge Security chip holds the registers nonce — a fresh random number signs The Quote • the chosen register values • the checker's nonce signed by the Attestation Key the signed answer the checker then tests two things: 1 · the signature verifies against the Attestation Key 2 · the nonce is the one it just sent accepted live, and from real hardware
A Quote is the register values and the checker's own nonce, signed inside the chip. The nonce is what makes the answer live — an old recording carries the wrong one — and the signature is what ties it to hardware, because the Attestation Key never leaves. Change the nonce and the check fails; that is freshness, felt rather than argued.
The three roots of trust — trusted by definition; only STORING and REPORTING live in the TPM Root for MEASURING takes the first fingerprint CRTM Code Root of Trust for Measurement — platform firmware, outside the TPM Root for STORING locks secrets to a specific set of fingerprints ("sealing") Root for REPORTING signs the register values so a remote checker can trust them
Three roots, two homes. The TPM provides the roots for storing and reporting; the root for measuring starts outside the chip — the CRTM is the platform's own first instructions, which is exactly why a firmware update changes PCR0. (Naming precision: TCG's glossary gives "Code Root of Trust for Measurement" and marks it the preferred expansion; NIST's glossary lists "Core". You will see both — "Code" is what the defining body prefers.)
SRTM — Static trust starts at power-on firmware loader kernel weakness: the huge firmware is all trusted a firmware update changes PCR0 DRTM — Dynamic a CPU instruction re-starts trust mid-run firmware(now excluded) small trusted coremeasured fresh strength: tiny trusted base → less brittle survives firmware updates
SRTM = Static Root of Trust for Measurement (trust from the moment of power-on). DRTM = Dynamic Root of Trust for Measurement (a special processor instruction re-establishes trust at runtime, so the messy firmware no longer has to be trusted). More on the dynamic path in Phase 4.

The register mechanics, precisely

an attacker putting back a clean value there is no command that does this new measurement a fingerprint new = Hash(old ‖ measurement) extend PCR one shielded slot the old value folds into the new one the slot only ever accumulates — nothing removes a value once it is in
Extend is the only way in, and it can only add. The slot's old value is folded together with the new measurement — new = Hash(old ‖ measurement) — and the result lands back in the same shielded slot. No command sets a register to a value you choose, which is exactly why a hacker cannot put a clean fingerprint back after the fact.
one event, measured once — one digest per bank one event measured SHA-1 digest SHA-256 digest SHA-1 bank PCR0 · PCR1 · PCR2 · … SHA-256 bank PCR0 · PCR1 · PCR2 · … another bank, only if it is configured a digest extends only the bank of its own algorithm
A bank is a full set of registers, one bank per hash algorithm. The same event is measured into each bank with a digest of that bank's algorithm — a SHA-256 digest cannot extend a SHA-1 bank, so the caller supplies a matching digest per algorithm. Which banks are active is configurable, so read them before you predict a value.
  • A PCR is a shielded slot; software can only extend it (add a fingerprint), never overwrite it.
  • Counts & sizes: TPM version 1.2 had one set of 24 registers on PC platforms (160-bit fingerprints). TPM version 2.0 supports multiple banks — one full set of registers per hash algorithm. PC-class machines commonly ship SHA-1 and SHA-256 banks, and which banks are active is configurable, not guaranteed.
  • Extend: new = Hash(old ‖ measurement). An extend call carries one digest per bank it means to update — a SHA-256 digest cannot extend a SHA-1 bank, so the caller supplies a matching digest per algorithm. Firmware extending every active bank is recommended practice, not automatic fan-out.
  • Reset rules: registers 0–15 reset only when the platform itself resets — a reset attribute, and the reason a boot-time fingerprint can be trusted for the whole session. The dynamic registers (17–22) play by a different rule: locality — which hardware context is speaking — gates who may reset them at runtime.
  • The report ("Quote"): the chip signs {chosen register values + the checker's nonce} with an Attestation Key — a signing key that never leaves the chip, itself vouched for by the chip's built-in Endorsement Key (the maker's proof that this is a genuine chip).
lab 3 · run a chip end to end
  • Install a TPM 2.0 simulator (swtpm) + the tpm2-tools toolkit (the standard command-line tools for talking to the chip).
  • tpm2_pcrread sha256 to read the registers. Extend one and watch it change.
  • Make an Attestation Key, take a signed report over some registers with a nonce, then verify it yourself: tpm2_checkquote …. Change the nonce and watch it fail — feel freshness.
  • Dump the boot event log and replay it to confirm it reproduces the firmware registers.
mastery gate 3

Verify a report without the helper tool: check the signature against the Attestation Key, confirm the nonce, and recompute the combined register fingerprint by hand. If you can do that, you understand attestation at the bit level.

sources
TPM 2.0 Library Specification — TCG · TCG Glossary — PDF · tpm2-tools — docs · RFC 9683 (TPM attestation, freshness & log replay) — link