TPM 2.0, Secure Boot and measured boot
What a TPM actually does, how PCRs record the boot chain, why Secure Boot and measured boot solve different problems, and why TPM-only disk encryption keeps getting broken.
01What a TPM is and what it is not
- Explain what a TPM holds and why its keys cannot simply be copied out
- Describe how PCRs are extended and why they cannot be set to a chosen value
- Tell the EK, AK and SRK apart and what each one is for
- Contrast UEFI Secure Boot (enforce) with measured boot (record)
- Explain how sealing binds a disk key to PCRs and the attacks that still work
A Trusted Platform Module (TPM) is a small, slow cryptographic chip (or firmware equivalent) with three jobs: generate and hold keys that never leave it in plaintext, keep a tamper-evident record of what booted, and release secrets only when that record matches a policy. It is not a crypto accelerator, not an HSM for your web traffic, and it does not stop anything from running. It remembers and it refuses.
| Form factor | Where it lives | Main weakness |
|---|---|---|
| Discrete TPM (dTPM) | Separate chip on the LPC or SPI bus | Bus traffic can be sniffed unless sessions are encrypted |
| Firmware TPM (fTPM) | Runs in the CPU's secure environment (Intel PTT, AMD fTPM) | Shares fate with CPU firmware and its side channels |
| Integrated / Pluton | Security processor inside the SoC | Vendor-controlled firmware; less independent review |
| Virtual TPM (vTPM) | Emulated by the hypervisor for a VM | Only as trustworthy as the host, unless the vTPM runs inside a confidential VM |
PCRs: a hash chain you can only append to
A Platform Configuration Register (PCR) is a register inside the TPM that starts at zero on reset and can only be changed by extend: PCR_new = H(PCR_old || H(measurement)). You cannot write a value, only fold another hash in. To reach a given final value you would have to replay exactly the same measurements in exactly the same order, which is the point. A TPM 2.0 has at least 24 PCRs per hash bank, usually with SHA-1 and SHA-256 banks active.
| PCR | Measured by convention (TCG PC Client spec) | Changes when |
|---|---|---|
| 0 | Core firmware code (SRTM, BIOS/UEFI) | Firmware update |
| 1 | Firmware configuration | BIOS setting change, sometimes hardware swap |
| 2 / 3 | Option ROMs and UEFI driver code / their config | New GPU, NIC or storage controller firmware |
| 4 | Boot manager code (bootmgfw.efi, shim, GRUB) | Boot loader update |
| 5 | Boot manager config, GPT partition table | Repartitioning |
| 7 | Secure Boot state and the db/dbx/KEK/PK contents plus certs used | Secure Boot toggled, dbx update, booting via a different signing authority |
| 8 / 9 | GRUB: commands and kernel command line / loaded files | Kernel or initrd update, edited command line |
| 11 | Windows: BitLocker access control. systemd-stub: unified kernel image sections | Every kernel update (Linux UKI) |
| 17-22 | Dynamic root of trust (Intel TXT, AMD SKINIT) | Late launch of a measured environment |
A strong signal is knowing that a PCR is a hash chain, not a stored hash. Interviewers like asking "can malware just write the expected value into PCR 7?" The answer is no: it can only extend, and an extend from a known-good state with a bad measurement produces a value nobody will ever match.
This is an advanced module
Hardware roots of trust & confidential computing is part of the Pro pass. 3 more sections — the deep dives, the final design, follow-ups and the test — unlock with it.
Already a cyart.io or studio.cyart.io member? Your pass code is in your Studio account.