Hitchhiker's Guide — Measuring, Attesting, and Hardening Real Platforms

The operator's manual for Phase 13 WARMUP. The WARMUP derives the mechanisms; this is how you actually inspect a TPM, read PCRs and the event log, drive an attestation, verify a firmware image, and harden a platform's root of trust — with concrete commands and expected output. Authorized-lab / owned-hardware only.

Table of Contents

Inspecting the Root of Trust and Boot State

# Is a TPM present, which version, which manufacturer?
sudo tpm2_getcap properties-fixed | grep -E 'TPM2_PT_(MANUFACTURER|FAMILY|REVISION)'
# Secure Boot state (UEFI)
mokutil --sb-state            # "SecureBoot enabled"
bootctl status | grep -i secure
# Android Verified Boot state on a device
adb shell getprop ro.boot.verifiedbootstate   # "green" = locked + verified

What "good" looks like: a genuine manufacturer TPM, Secure Boot enabled, verified-boot state green/locked. A yellow/orange AVB state or disabled Secure Boot means the boot chain's enforcement is off — measured evidence may still exist, but a key control is missing.

Reading PCRs and the Event Log

sudo tpm2_pcrread sha256:0,4,7        # firmware(0), bootloader/kernel(4), secure-boot config(7)
sudo tpm2_eventlog /sys/kernel/security/tpm0/binary_bios_measurements   # the measurement log

The discipline (Lab 01): replay the event log and confirm it reproduces the PCRs. If the log's extends don't compute to the live PCR values, the log is dishonest — treat the platform as untrusted. PCR usage is standardized by the TCG PC Client Firmware Profile (e.g. PCR0 = firmware code, PCR7 = Secure Boot policy), so you know which register should change when which component changes.

Driving a Remote Attestation

The verifier-side flow (what the relying party does — exactly attest() in Lab 01):

1. issue a fresh random NONCE
2. ask the device for a quote over a PCR selection + the nonce, signed by its AK
   (device: sudo tpm2_quote -c ak.ctx -l sha256:0,4,7 -q <nonce> -m msg -s sig -o pcrs)
3. verify: AK cert chains to a trusted manufacturer EK; signature valid (tpm2_checkquote);
           nonce matches; PCRs == golden; supplied event log replays to those PCRs
4. only then: release the disk key / issue the fleet credential / admit to the network

Gate access on the attestation result, not on network location. This is the operational core of a zero-trust device fleet: a device proves freshly that it booted approved software on genuine hardware before it gets secrets or connectivity.

Golden-Value Management

Attestation is only as good as the golden values. Operate them like a security-critical dataset:

  • Derive goldens from your approved build, not from "whatever the first device measured" — compute the expected PCRs from the signed firmware/kernel you ship.
  • Version goldens with the firmware; a legitimate update changes PCRs, so the attestation policy must know which goldens are valid for which firmware version (and during a fleet rollout, accept the set {old, new}).
  • Treat an unexpected PCR as a finding, then triage: is it an un-rolled-out update, a new hardware revision, or an implant? The event log tells you which component diverged.

Verifying a Firmware Image and Anti-Rollback

verify_update(image, device):                    # Lab 02
  signer ∈ device.trusted_keys ?                  authenticity (root of trust)
  signature over (model:version:payload_hash) ?   manifest authenticity
  sha256(payload) == payload_hash ?               integrity
  image.model == device.model ?                   no cross-model flash
  image.version > device.rollback_index ?         anti-rollback (monotonic, hardware-backed)
apply_update: advance the counter ONLY on success; A/B swap; keep a recovery slot

Operationally: store the rollback index in eFuses/RPMB (not normal flash), use A/B slots so a bad update falls back to the known-good slot, and never ship an update path that can be coerced into accepting version <= stored.

Hardening the Platform

  • Enable and lock Secure Boot / Verified Boot; remove debug/unlock paths from production builds.
  • Write-protect SPI flash in hardware (the OS must not be able to rewrite firmware).
  • Measure firmware into PCRs so an implant breaks attestation (NIST 800-193 protect/detect/recover).
  • Disable unused management surfaces (or segment the BMC/ME network) — out-of-band processors are a ring-(-2) attack surface.
  • Provision device identity on-device (key born in the Enclave/TPM, never exported); treat the factory provisioning HSM as crown-jewel infrastructure.

Confidential Computing in Practice

# AMD SEV-SNP / Intel TDX: fetch and verify a hardware attestation report before key release
# (conceptually): guest produces a signed report (measurement + chip identity);
# a key-release service verifies it against the CPU vendor's roots + your golden measurement,
# THEN unwraps the data key for the attested guest only.

The rule: release secrets to a workload only after verifying its hardware attestation — the same nonce→quote→verify-against-golden pattern as platform attestation, at VM/enclave granularity. This is how you make "the operator cannot read customer data" a verifiable property.

Failure Drills

  • Tampered firmware → PCR0 diverges from golden → attestation fails → device denied fleet access.
  • Replayed quote → nonce mismatch → rejected (proves freshness matters).
  • Downgrade attempt → version <= rollback_index → update refused.
  • Cross-model flash → model mismatch → refused.
  • Disabled Secure Boot → enforcement gap detected by policy even if measurement still flows.

Evidence Packet

Boot-chain diagram with verified/measured links; live PCR + event-log capture that replays correctly; an attestation transcript (nonce, quote, verification result); golden-value provenance; a firmware-update verification log including a blocked downgrade; firmware write-protection proof; and an honest physical/ side-channel resistance statement.

References

  • tpm2-tools documentation (tpm2_pcrread, tpm2_quote, tpm2_checkquote, tpm2_eventlog).
  • TCG PC Client Platform Firmware Profile (PCR assignments); NIST SP 800-155 / 800-193.
  • Keylime (open-source remote-attestation framework); go-attestation; AMD SEV-SNP / Intel TDX guest attestation docs; fwupd/LVFS (firmware update); chipsec (platform/firmware assessment).
  • Phase 04 (Android Verified Boot/Keystore), Phase 14 (firmware supply chain).