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).

Prerequisites

• A system with a TPM 2.0 device and the resource manager:

  sudo apt install tpm2-tools tpm2-abrmd        # Debian/Ubuntu
  sudo dnf install tpm2-tools tpm2-abrmd        # Fedora/RHEL
  

• Access to the TPM (/dev/tpm0 / /dev/tpmrm0) and the kernel measurement log at /sys/kernel/security/tpm0/binary_bios_measurements.
• Root for reading some sysfs entries and for NV/AK operations.
• For remote attestation: a verifier host and a transport for the quote/nonce exchange.

Objectives

• Read and interpret PCR banks and their TCG-assigned meanings.
• Verify the TPM event log reproduces live PCR values (event-log replay).
• Create an Attestation Key and produce a nonce-bound signed quote.
• Independently verify the quote signature and PCR digest on a verifier.
• Establish golden PCR baselines and detect drift across a fleet.
• Optionally seal/unseal a secret to a measured-boot PCR policy.

MITRE ATT&CK Mapping

Workflow

1. Confirm the TPM is present and read its properties

tpm2_getcap properties-fixed | grep -i manufacturer
tpm2_getcap pcrs                 # list supported PCR banks (sha1, sha256, ...)

2. Read current PCR values

…