Validating TPM Measured Boot and Attestation

Legal Notice: Perform TPM operations only on systems you own or are authorized to assess. Some operations (clearing the TPM, taking ownership, defining NV indices) are destructive or can lock the device. This skill is for defensive integrity verification and authorized assessment.

Overview

A Trusted Platform Module (TPM 2.0) is a hardware root of trust that supports measured boot: each stage of the boot chain hashes ("measures") the next stage and extends that measurement into a Platform Configuration Register (PCR) before handing off control. PCRs cannot be set arbitrarily — they can only be extended (new = hash(old || measurement)), so the final PCR value is a tamper-evident summary of everything that executed. The TCG firmware profile assigns specific meanings: UEFI firmware code/config measure into PCR 0–7 (PCR 7 specifically captures Secure Boot policy), bootloaders measure the kernel into PCR 8–9, and Linux IMA measures executables into PCR 10.

Two complementary verifications matter. Local validation reads current PCRs (tpm2_pcrread) and replays the TPM event log (tpm2_eventlog on /sys/kernel/security/tpm0/binary_bios_measurements) to confirm the recorded measurements reproduce the live PCR values — proving the log is authentic and revealing exactly what changed if a value drifts from baseline. Remote attestation has the TPM produce a signed quote (tpm2_quote) over selected PCRs using an Attestation Key (AK), with a fresh nonce to prevent replay; a verifier then independently checks the signature and PCR digest (tpm2_checkquote) and compares against a golden/expected value. This lets a server cryptographically establish that a remote machine booted approved firmware and kernel before granting access, sealing secrets, or admitting it to a Zero Trust network.

This skill provides the full tpm2-tools workflow for enrolling an AK, capturing and verifying quotes, replaying event logs, sealing/unsealing data to a PCR policy, and building a golden-value baseline for fleet attestation.

When to Use

• Establishing that endpoints/servers booted a known-good firmware and kernel before granting access (Zero Trust device posture).
• Detecting boot-chain tampering (bootkits, unauthorized firmware/kernel changes) via PCR drift from a baseline.
• Verifying measured-boot integrity after a Secure Boot or firmware incident.
• Sealing secrets (disk keys, credentials) to a measured-boot state so they only release on a trusted boot.
• Building or auditing a remote-attestation service (e.g., Keylime, custom verifier).