Platform Configuration Register (PCR)

What a PCR is

A Platform Configuration Register (PCR) is a fixed-size slot inside a Trusted Platform Module that can never be written to directly. The only operation permitted on it is TPM2_Extend, which folds a new measurement into the register using a cryptographic hash:

PCR[n] = SHA256( PCR[n] || measurement )

Every extend is one-way and cumulative. You cannot roll a PCR back, and you cannot set it to an arbitrary value. The only way to arrive at a specific PCR value is to have extended exactly the right measurements, in exactly the right order. That property is the entire foundation of measured boot and remote attestation.

A TPM 2.0 chip exposes multiple PCR banks — one per supported hash algorithm. A typical fTPM ships with SHA-1 and SHA-256 banks; higher-assurance chips add SHA-384 and SHA-512. Each bank has its own set of registers (usually 24). Referring to "PCR 7" without specifying the bank is technically ambiguous, though SHA-256 is the safe modern default.

The measured boot sequence

PCRs get populated during boot by a chain of measurements, each stage measuring the next before handing off control. The TCG PC Client specification assigns semantic meaning to each PCR:

The pattern that matters: BIOS measures itself and the bootloader before running it; bootloader measures the kernel and initrd before jumping to them; the kernel (via IMA) measures every binary before executing it. Any tampering anywhere in the chain changes some downstream PCR.

How verifiers use PCRs

The TPM will not let anything read a PCR value and forward it in a trustworthy way — the OS could lie. Instead the TPM signs a quote: a data structure containing the current PCR values, a caller-supplied nonce, and a signature by an Attestation Key. The signature covers the PCR digest, not each PCR individually:

PCRDigest = SHA256( PCR[a] || PCR[b] || PCR[c] || ... )

The verifier receives the quote and the claimed PCR values, hashes the values, and confirms the hash matches the PCRDigest inside the signed quote. Then it compares each PCR value to a golden reference — the expected values captured from a known-good device. TigerTrust's verifier records specific failure modes so operators can debug:

• quote_verify: pcr digest does not match claimed PCR values — the agent lied about PCR contents.
• pcr_missing:<n> — required PCR was not included in the quote.
• pcr_mismatch:<n> — PCR value differs from policy expectation.
• secure_boot_not_measured — PCR 7 is zero, meaning Secure Boot did not run.

What problem PCRs solve

Without PCRs, a device claiming to run trusted firmware has only its word. A rootkit that boots before the OS can present arbitrary responses to any software query about "what firmware are we running?" PCRs move the answer into hardware: the measurement happens before the code being measured has a chance to lie, and the register itself can only be extended, not overwritten. A verifier who trusts the chip can trust the PCR values by transitivity.

The specific attacks measured boot defeats:

• Firmware implants — modified UEFI changes PCR 0 or 1; quote fails golden-value check.
• Bootkits — modified MBR/bootloader changes PCR 4 or 8/9.
• Secure Boot bypass — bypass changes PCR 7 or leaves it zero; policy requires it non-zero.
• Runtime code injection into measured processes — with IMA enabled, changes PCR 10.

When to gate on which PCRs

Most fleets do not need to pin every register. For a UEFI + Secure Boot Linux device, a reasonable minimum gating set is:

• [0, 2, 4] to lock down firmware and bootloader code.
• [1, 3] to lock down firmware and Option ROM configuration.
• [7] to require Secure Boot ran and its state matches expectation.

Add PCRs 8 and 9 if you want to pin the exact kernel and initrd; add PCR 10 (with IMA policy on the device) to gate on userspace binary integrity too. Every added PCR increases the frequency of forced policy updates when the fleet gets patched, so choose what you actually care about.

Common misconceptions

"A signed PCR value is enough." The signed value is only meaningful if compared to a golden reference. A quote you cannot compare to anything is a signed record of arbitrary bytes.

"PCRs prevent modifications." They do not prevent — they detect. Enforcement happens on the verifier side. A modified device will happily boot; it just cannot obtain a valid attestation.

"PCRs are secret." They are not. Anyone with local access can read them via tpm2_pcrread or the equivalent Windows API. The security property is unforgeability, not confidentiality.

"Resettable PCRs give me flexibility." PCRs 16 and 23 are resettable specifically because they are not trustworthy. Never build a security decision on them.

"Every device in the fleet has the same PCR values." In practice, no. Even identical hardware with identical firmware can produce different PCR 1 values due to configuration data included in the measurement. Golden PCR management usually needs per-hardware-model tables.

How TigerTrust uses PCRs

TigerTrust's attestation policy model lets operators specify expectedPcrs as a nested map of bank → PCR index → hex digest, plus a requiredPcrs array of indices the agent must include in every quote (so agents cannot cherry-pick only the PCRs known to pass). Policies also support event-log replay against PCR values so operators can express "any kernel signed by a permitted vendor" rather than pinning exact hashes, and multi-bank verification (SHA-256 plus SHA-384) for CNSA 2.0 profiles. Full details in the TPM_ATTESTATION design doc.

Related reading

• TCG PC Client Platform Firmware Profile — the spec that defines which PCR measures what.
• Linux IMA documentation — how PCR 10 is populated.