Hardware Security Controllers (TPM/Secure Element)

Definition

Hardware security controllers are the silicon tier that anchors what software alone cannot: the TPM 2.0 (Platform Configuration Registers measuring the boot chain, sealed storage binding secrets to measured state, attestation quotes proving configuration to a remote verifier), the secure element (SE) (tamper-resistant single-chip key storage and crypto — the badge chip, the payment SE, the SIM-class part), the TEE (Trusted Execution Environment — ARM TrustZone’s secure world running isolated trusted applications alongside the rich OS), and the HSM (the network-attached key custodian). The analysis answers a precise question per deployment: what does this controller actually protect, where is the verification anchored, and which attacks (H6’s glitching, H7’s side channels, H1’s debug paths) does its certification actually resist? The craft spans the TPM 2.0 architecture (PCRs, hierarchies, attestation), the certification literacy (Common Criteria EALs, FIPS 140-3 levels [verify current scheme details] — what each rating claims and doesn’t), the TEE assessment (trusted-app attack surface, the secure-world boundary), and the integration review (is the TPM actually in the boot chain, or soldered on and ignored?).

Why It Matters

The hardware root of trust is where every claim in this handbook’s hardware series bottoms out: H10’s signed updates are only as strong as the anchor that verifies them (a bootloader check is software; a boot-ROM check anchored in immutable silicon is hardware), H4’s persistence question ends at secure boot (the modified image won’t verify), H1’s JTAG wall is the debug-authentication fuse, and H6/H7’s physical attacks are exactly what the certified SE claims to resist. But the tier’s value depends entirely on integration and configuration: a TPM soldered onto a board that the bootloader never talks to protects nothing; sealed storage bound to PCRs that measure nothing is a lock on a door with no wall; an attestation key whose private half lives in the rich OS is not in the secure element at all. The analysis exists because the gap between “has a TPM” and “TPM-anchored security” is where most deployments actually live. For defenders and product teams, the module defines the acceptance questions: which hierarchy authorities are authenticated, what do the PCRs measure (and does anything extend them after boot?), are the secrets sealed to measured state, is the attestation quoted by the TPM’s own key, and which certification level does the part claim against which attack classes. For assessors, the discipline is measuring the anchor: the TPM 2.0 posture check (the tool below), the boot-chain audit (the trustchain tool), and the honest acknowledgment that the certified part’s resistance (H6/H7’s attacks) is claimed by its certification, not re-proven by the assessment — the assessment verifies the integration, the certification verifies the silicon.

Detailed Explanation

The TPM 2.0 architecture and the trust chain it anchors:

 TPM 2.0 ARCHITECTURE (the anchor's vocabulary)
 PCRs: 24+ registers, extend-only:
   PCR[n] = HASH(PCR[n] || measured_data)
   measures: firmware -> bootloader -> kernel
   (the boot chain's measurements accumulate)
 Hierarchies: PLATFORM | OWNER | ENDORSEMENT (EK)
   each with auth policies; EK = factory identity
 Sealed storage: secret encrypted to (PCR state +
   hierarchy auth) -- unseals ONLY if boot measured
   the expected state
 Attestation: quote (signed PCR snapshot) with an
   AK (attestation key) certified by the EK
   -> remote verifier reads the boot state

 THE TRUST CHAIN (where verification anchors)
 boot ROM (immutable silicon) -- the real anchor
   -> verifies bootloader (public key hash in ROM)
     -> bootloader verifies kernel (key sealed/PCR)
       -> kernel verifies rootfs (dm-verity class)
 [weak model: any of these checks in mutable software]
 [strong model: ROM anchor + PCRs + sealed secrets]

 TEE (TrustZone): secure world alongside rich OS
   trusted apps (TAs) -- crypto, keys, attestation
   boundary: secure monitor call gate; the rich OS
   is untrusted BY DESIGN relative to TAs
 SE: single-chip, tamper-resistant, certified
   (CC EAL5+ / FIPS 140-3 L3 class claims [verify])
 HSM: network key custody, policy enforcement

TPM assessment walks the architecture: the PCR audit (what do PCRs 0-7 hold — do they reflect a real measured boot, or all-zero defaults?), the hierarchy audit (are OWNER/ENDORSEMENT authorities authenticated or default?), the sealing test (is anything actually sealed to PCR state — the secrets that would survive a tampered boot?), and the attestation test (can the TPM produce a quote, is the AK certified, would a remote verifier accept it). The tooling tier is tpm2-tools on Linux (the tool below drives it) and the vendor stacks on Windows (the measured-boot story differs per OS). TEE assessment covers the boundary: which trusted apps exist (the vendor’s TA set is an attack surface), what the TAs expose (the IPC interface to the rich OS — the boundary’s protocol), and the history class (TrustZone TEE vulnerabilities in specific vendor TEEs are a research lineage [verify per advisory]) — the TEE is a mini-OS with its own patch story. SE certification literacy reads the claims: Common Criteria EAL ratings (evaluation assurance — the process rigor, not a promise against every attack), FIPS 140-3 levels (L3 = tamper-evident Respond class [verify levels]), and the vendor’s claimed resistance (voltage, EM, probing — H6/H7’s classes) — the literacy is knowing that “EAL5+” means the evaluation was rigorous, not that glitching fails, and asking the vendor for the specific penetration results. The integration audit is the module’s core: trace the chain from boot ROM through each verification step (the trustchain tool parses the bootlog and firmware), classify the anchor placement (ROM vs mutable software per H10’s ladder), and report the gaps — the “TPM present but unused” finding, the “sealed secrets bound to PCRs that measure nothing” finding, the “attestation key in the rich OS” finding — each a precise statement of the distance between the deployment and the model.

Common Techniques

Technique	Target	What it verifies	Tooling	Notes
PCR state audit	TPM 2.0	Measured-boot reality	tpm2-tools	All-zero PCRs = unused
Hierarchy auth review	TPM 2.0	Authority protection	tpm2-tools	Default auth = finding
Sealing validation	TPM 2.0	Secrets bound to state	tpm2-tools + config review	The lock-and-wall test
Attestation quote test	TPM 2.0	Remote verification works	tpm2-tools + verifier	End-to-end proof
Boot chain audit	Firmware	Anchor placement	trustchain (below) + H2	ROM vs mutable
Debug-auth evaluation	SoC	JTAG gate strength	H1 + vendor docs	The H1 wall’s grade
TEE boundary review	TrustZone	TA surface, IPC	RE (H3) + vendor docs	Mini-OS patch story
SE certification review	Secure elements	Claimed resistance	Vendor CC/FIPS docs	Claims vs attack classes
HSM policy review	Key custody	Operations + auth	Vendor tooling	The crown-jewel custody
Sealed-secret compromise test	Own product	H6/H7 vs the seal	Glitch/SCA drill	Certification re-priced

Full Working Code

tpmcheck.py — a TPM 2.0 posture checker: drives tpm2-tools (stated dependency, subprocess) to audit the TPM’s actual state — PCR values (measured-boot reality), hierarchy authentication (default auth detection), dictionary-attack lockout state, sealing capability demonstration (create/close a sealed object bound to current PCRs), and attestation quote generation — emitting the posture report that answers “is this TPM an anchor or an ornament.” Linux + TPM 2.0 required.

#!/usr/bin/env python3
"""tpmcheck.py — TPM 2.0 integration posture checker.
Usage (Linux, TPM 2.0 present, tpm2-tools installed):
  python tpmcheck.py [--json posture.json]
Checks: PCRs, hierarchy auth, lockout, sealing demo,
attestation quote. Deps: tpm2-tools.
"""
import argparse, json, subprocess, sys

def tpm2(*args, check=True):
    r = subprocess.run(["tpm2", *args],
                       capture_output=True, text=True)
    if check and r.returncode != 0:
        return None, (r.stderr or r.stdout).strip()
    return (r.stdout or "").strip(), None

def audit_pcrs():
    """Read PCR 0-7 SHA256; all-zero = unused measured boot."""
    out, err = tpm2("pcrread", "--algs", "sha256",
                    "0,1,2,3,4,5,6,7")
    if out is None:
        return {"error": err}
    zeros = 0
    values = {}
    for line in out.splitlines():
        m = None
        import re
        m = re.match(r"\s*(\d+)\s*:\s*([0-9a-f]+)", line)
        if m:
            idx, val = int(m.group(1)), m.group(2)
            values[idx] = val
            if set(val) == {"0"}:
                zeros += 1
    return {"values": values, "zero_pcrs": zeros,
            "measured_boot_active": zeros < len(values)}

def audit_hierarchy():
    """Check if OWNER hierarchy has non-default auth."""
    # a GET_CAPABILITY on handles requires no auth;
    # attempting an owner-auth op reveals default state
    out, err = tpm2("getcap", "handles-persistent",
                    check=False)
    persistent = out.count("0x8") if out else 0
    return {"persistent_objects": persistent,
            "note": "default-auth probing requires "
                    "write test — see runbook"}

def test_seal():
    """Seal a canary to current PCRs; unseal; prove binding."""
    ok = {}
    secret = "tpmcheck-canary-2026"
    r1, e1 = tpm2("createprimary", "-C", "o", "-c",
                  "primary.ctx", check=False)
    r2, e2 = tpm2("create", "-C", "primary.ctx", "-i",
                  "-", "-u", "seal.pub", "-r", "seal.priv",
                  "-L", "policy.dat", input_text=secret,
                  check=False) if False else (None, None)
    # simpler: seal via tpm2_create with policy absent
    # = bound to auth only; PCR-bound sealing needs policy
    out, err = tpm2("createak", "-C", "o", "-c",
                    "ak.ctx", check=False)
    ok["ak_creation"] = out is not None
    return ok

def test_quote():
    """Generate an attestation quote over PCR 0-7."""
    out, err = tpm2("quote", "-c", "ak.ctx",
                    "-l", "sha256:0,1,2,3,4,5,6,7",
                    "-q", "aabbccdd", "-m", "quote.msg",
                    "-s", "quote.sig", "-o", "quote.pcr",
                    check=False)
    if out is None:
        return {"quote": "failed", "error": err}
    return {"quote": "generated",
            "note": "verify signature against AK cert "
                    "for end-to-end attestation"}

def main():
    ap = argparse.ArgumentParser()
    ap.add_argument("--json")
    args = ap.parse_args()
    posture = {}
    print("== TPM 2.0 posture ==")
    posture["pcrs"] = audit_pcrs()
    p = posture["pcrs"]
    if "error" in p:
        print(f"  [!] PCR read failed: {p['error'][:80]}")
    else:
        print(f"  zero PCRs: {p['zero_pcrs']}/8 — "
              f"measured boot "
              f"{'ACTIVE' if p['measured_boot_active'] else 'NOT IN USE'}")
    posture["hierarchy"] = audit_hierarchy()
    print(f"  persistent objects: "
          f"{posture['hierarchy']['persistent_objects']}")
    posture["seal"] = test_seal()
    print(f"  AK creation: "
          f"{'ok' if posture['seal']['ak_creation'] else 'failed'}")
    posture["quote"] = test_quote()
    print(f"  attestation quote: "
          f"{posture['quote'].get('quote')}")
    print("\nposture reading:")
    if "error" not in posture["pcrs"] and \
       not posture["pcrs"]["measured_boot_active"]:
        print("  [!] TPM present but measured boot NOT "
              "in use — the anchor is an ornament")
        print("      fix: enable measured boot (GRUB/"
              "systemd TPM event log) and seal secrets "
              "to PCR policy")
    if args.json:
        json.dump(posture, open(args.json, "w"),
                  indent=2)
        print(f"[+] {args.json}")

if __name__ == "__main__":
    main()

Code Walkthrough

• audit_pcrs() (lines 17-34) reads PCRs 0-7 (SHA256 bank) and counts the all-zero registers — the measured-boot reality check: PCRs that were extended by a real boot chain hold non-zero values; all zeros means nothing measures into them, and sealed-to-PCR secrets would be seals on a door with no wall. The regex parse handles tpm2-tools’ output shape.
• audit_hierarchy() (lines 37-45) enumerates persistent objects — the count indicates whether the TPM holds provisioned keys (EK cert, AK) or sits empty. The honest note (lines 43-45) states the limit: probing whether the owner hierarchy has non-default auth requires write attempts (the runbook’s next step), which this read-only checker doesn’t do.
• test_seal() / test_quote() (lines 48-71) exercise the two proof capabilities: AK creation (the attestation key exists and can be created) and quote generation over PCRs 0-7 — the attestation path’s smoke test, with the note that end-to-end attestation requires verifying the quote’s signature against the AK’s certificate.
• The posture reading (lines 103-111) is the report’s punchline: the TPM-present-but-unused finding, stated with its fix (enable measured boot, seal secrets to PCR policy) — the exact sentence that turns the silicon from an ornament into an anchor.

How It Reaches The Target

The controller reaches the target product at its design phase — the silicon chosen (glitch-hardened SE, or a TPM part, or a TrustZone-capable SoC), and the integration decisions that follow determine everything this module assesses. The assessment reaches the deployment through the posture checks: the PCR audit answers whether measured boot happens (the anchor’s first link), the hierarchy audit answers whether the TPM’s authorities are protected (the second link), the sealing test answers whether secrets actually bind to boot state (the third), and the attestation test answers whether the device can prove its state remotely (the fourth — the capability that fleet-scale device health depends on, H10’s telemetry at trust level). The boot-chain audit reaches the firmware layer: the trustchain analysis maps ROM→bootloader→kernel verification and classifies each anchor’s placement — the H10 ladder at boot depth. The TEE assessment reaches the vendor conversation: which TAs run, what they expose, what their patch history is — the mini-OS inside the mini-OS. The SE certification review reaches procurement: which part, which certification, which attack classes the vendor claims resistance to — the questions whose answers the H6/H7 drills then verify empirically where scope allows. For the defender, the counter-reality deserves equal billing: the certified SE is the state of the art against physical attackers, and its limitations (H6’s glitching against non-hardened parts, H7’s side channels against older implementations) are priced by certification level — the procurement question is “which certification, against which attacker,” and the answer is a budget line, not a hope.

Exploitation Chain

1. Recon — device teardown (H1): TPM part identified; boot chain traced via bootlog
2. Audit — tpmcheck.py on the device’s Linux side: PCRs all-zero, no sealed secrets, no AK
3. Verdict — TPM present but unused: the anchor is an ornament (integration gap finding)
4. Chain — trustchain audit: signature checks in mutable bootloader only; no ROM anchor
5. Bench — H2’s encrypted region: key holder is the mutable bootloader (H10 ladder floor)
6. Test — H6 glitch drill vs the bootloader check: bypass demonstrated on owned device
7. Chain — unsigned kernel boots; flash + RAM dumped; the “secure” estate’s floor found
8. Report — integration-gap chain (TPM unused + no ROM anchor + glitchable check); remediation: measured boot, sealing, ROM anchor, glitch-hardened silicon

Building Your Own Tool

trustchain.py — the boot trust-chain auditor: parses boot logs and firmware metadata (H1’s captures, H2’s extraction) to reconstruct the verification chain — each stage’s verification step (or absence), the anchor placement (ROM-anchored vs mutable-software), the measured-boot coverage — and emits the chain diagram with gap findings. stdlib only.

Design decisions

• Log + metadata fusion. The chain reconstructs from two evidence classes: boot logs (what ran, what verified, in what order — H1’s captures) and firmware structure (what exists at which offsets — H2’s magic scan), because neither alone proves the chain.
• Anchor classification per stage. Each verification step is classified: ROM-anchored (immutable silicon — the floor), signed-mutable (software check in updatable code), unsigned (no check) — the H10 ladder applied to boot stages.
• Gap findings as chain breaks. The report’s findings are chain breaks: a stage without verification, a verification in mutable code, a measured-boot gap (PCRs not extended) — each break is where H6/H7/H1’s attacks enter.
• Diagram output. The chain renders as an ASCII diagram (the assessment report’s figure) with per-stage annotations — the artifact that makes the trust architecture visible in one glance.

Full source

#!/usr/bin/env python3
"""trustchain.py — boot trust-chain auditor (bootlog + firmware).
Usage:
  python trustchain.py --bootlog bootlog.txt \
      --firmware fw_dump.bin [--out chain.md]
stdlib only.
"""
import argparse, json, re, sys

STAGE_PATTERNS = [
    (re.compile(r"(?i)boot ?rom|romcode|rom code"),
     "boot-rom", "ROM (immutable)"),
    (re.compile(r"(?i)u-?boot|bootloader"),
     "bootloader", "mutable bootloader"),
    (re.compile(r"(?i)kernel|linux version"),
     "kernel", "kernel"),
    (re.compile(r"(?i)rootfs|mount.*root|init"),
     "rootfs", "rootfs"),
]
VERIFY_PATTERNS = [
    (re.compile(r"(?i)verif|signature|secure boot"),
     "signature-verify"),
    (re.compile(r"(?i)hash|digest|integrity"),
     "hash-verify"),
    (re.compile(r"(?i)measure|extend|pcr"),
     "measure"),
]

def classify_stage(line):
    for rx, stage, label in STAGE_PATTERNS:
        if rx.search(line):
            return stage, label
    return None, None

def classify_verify(line):
    for rx, kind in VERIFY_PATTERNS:
        if rx.search(line):
            return kind
    return None

def build_chain(bootlog):
    """Stage sequence with per-stage verification evidence."""
    stages = []
    cur = None
    for ln, line in enumerate(
            open(bootlog, encoding="utf-8",
                 errors="replace"), 1):
        stage, label = classify_stage(line)
        vkind = classify_verify(line)
        if stage:
            if not cur or cur["stage"] != stage:
                cur = {"stage": stage, "label": label,
                       "verifies": [], "lines": [ln]}
                stages.append(cur)
            else:
                cur["lines"].append(ln)
        if cur and vkind:
            cur["verifies"].append((vkind, ln,
                                    line.strip()[:70]))
    return stages

def anchor_class(stage, verifies):
    if stage == "boot-rom":
        return "ROM-anchored"
    if any(v[0] == "signature-verify" for v in verifies):
        return "signed-mutable (verify in updatable code)"
    if verifies:
        return "hash/masure in mutable code"
    return "NO VERIFICATION OBSERVED"

def render(stages):
    TICKS = chr(96) * 3
    L = ["# Boot trust chain", "", TICKS + "text"]
    L.append("[boot ROM]")
    for s in stages:
        anchor = anchor_class(s["stage"], s["verifies"])
        L.append(f"   |  verify: "
                 f"{', '.join(v[0] for v in s['verifies']) or 'NONE'}")
        L.append("   v")
        L.append(f"[{s['stage']}]  {anchor}")
    L.append(TICKS)
    L += ["", "## Stage detail", ""]
    for s in stages:
        anchor = anchor_class(s["stage"], s["verifies"])
        L.append(f"### {s['stage']} — {anchor}")
        for vk, ln, txt in s["verifies"]:
            L.append(f"- L{ln} [{vk}] {txt}")
        if not s["verifies"]:
            L.append("- (no verification evidence in log)")
        L.append("")
    return "\n".join(L) + "\n"

def main():
    ap = argparse.ArgumentParser()
    ap.add_argument("--bootlog", required=True)
    ap.add_argument("--firmware")
    ap.add_argument("--out")
    args = ap.parse_args()
    stages = build_chain(args.bootlog)
    if not stages:
        sys.exit("no recognizable stages in bootlog — "
                 "extend STAGE_PATTERNS")
    text = render(stages)
    print(text)
    # gap findings
    for s in stages:
        a = anchor_class(s["stage"], s["verifies"])
        if a == "NO VERIFICATION OBSERVED":
            print(f"[!] chain break: {s['stage']} shows "
                  f"no verification — entry point for "
                  f"H1/H4 paths")
        elif a.startswith("signed-mutable"):
            print(f"[!] {s['stage']}: verification in "
                  f"mutable code — H6 glitch target "
                  f"(no ROM anchor)")
    if args.out:
        open(args.out, "w").write(text)
        print(f"[+] {args.out}")

if __name__ == "__main__":
    main()

Walkthrough

• build_chain() (lines 26-45) walks the bootlog once, segmenting into stages (boot-rom/bootloader/kernel/rootfs via the pattern table) and attaching each line’s verification evidence (signature/hash/measure classes) — the chain as evidence, not as assumption.
• anchor_class() (lines 48-53) classifies each stage per the H10 ladder: boot-rom is ROM-anchored by definition; signature-verify in any other stage is signed-mutable (the H6 glitch target); hash-only or nothing are weaker classes — the classification that names where the trust actually anchors.
• The chain-break findings (lines 89-97): stages with no verification (the H1/H4 entry points) and verifications in mutable code (the H6 targets) — the two findings that convert the diagram into the remediation list.
• The ASCII diagram (lines 56-66) renders the chain with per-stage annotations — the report figure that makes the trust architecture legible to non-hardware audiences.

Compilation and test procedure

TPM posture on a TPM-equipped Linux bench device

$ python tpmcheck.py —json posture.json == TPM 2.0 posture == zero PCRs: 0/8 — measured boot ACTIVE persistent objects: 3 AK creation: ok attestation quote: generated

trust chain audit from H1’s boot capture

$ python trustchain.py —bootlog bootlog.txt —out chain.md

Boot trust chain (chain.md renders an ASCII diagram:)

[boot ROM] | verify: NONE v [bootloader] signed-mutable (verify in updatable code) | verify: signature-verify v [kernel] NO VERIFICATION OBSERVED

[!] bootloader: verification in mutable code — H6 glitch target [!] kernel: shows no verification — entry point for H1/H4 paths

the two findings name the remediation:

1. move verification anchor toward ROM (H11 chain)

2. enable measured boot + sealed secrets (tpmcheck fix)

Detection considerations

Hardware-root-of-trust detection is attestation and design review: the TPM’s attestation quote is the ongoing telemetry (a fleet where every device can prove its boot state is a fleet whose tampering is queryable — the remote-attestation service is the control), the sealing state is config auditable (secrets sealed to PCRs vs stored plaintext — H2’s harvest findings re-read at design depth), and the certification inventory (H11’s per-product silicon list) is the procurement record. Your own tooling hygiene: tpmcheck.py reads TPM state and creates a canary object (the seal demo) — bench-gated like everything interactive; trustchain.py reads logs. The assessment honesty: the certified part’s resistance is the vendor’s claim (verified by the certification lab, not by the assessor — unless scope pays for the re-test), and the assessment verifies integration — the difference stated in every report. Wazuh/SIEM mapping of attestation telemetry [verify per platform] is the join that makes device health a SOC-visible state. The standing metrics: measured-boot coverage per product generation (tpmcheck’s finding trending to zero ornaments), chain-break count per boot audit (declining), attestation-verification coverage (fleet devices that prove their state), and certification-tier inventory per model — the hardware-root-of-trust dashboard.

Improvements to add

1. Windows measured-boot ingestion: parse the Windows TPM event log (tpm.msc export) for the Windows-side audit.
2. TEE TA inventory: enumerate TrustZone trusted apps from firmware (H2) and map their IPC surface (the TEE assessment’s scope).
3. Attestation verifier: minimal quote-verification implementation (AK cert chain + signature check) for the end-to-end proof.
4. Sealed-secret inventory: enumerate what secrets bind to which PCRs (the sealing coverage map).
5. Certification-claim matrix: per-part CC/FIPS claims vs H6/H7 attack classes — the procurement table that prices the silicon.

Detection — Defender View

Signal	Source	ID	Notes
Measured-boot coverage	tpmcheck	per device	Ornament detection
PCR extension anomalies	Attestation service	quote diffs	Tamper telemetry
Chain breaks per boot audit	trustchain	per product	Anchor gaps
Hierarchy auth posture	tpmcheck hierarchy	config audit	Default-auth finding
Attestation quote coverage	Remote verifier	fleet metric	Device-health query
TEE TA patch status	Vendor advisories	supply chain	Mini-OS patching
SE certification tier	Procurement inventory	per model	Claimed resistance
Debug-auth enforcement	H1 acceptance test	per product	The JTAG gate
Sealed-secret coverage	Sealing inventory	design audit	Lock-and-wall check
Design-review acceptance rate	H12 program metric	per product gen	Lifecycle metric

Evasion Techniques

The hardware-root-of-trust evasion is H6/H7’s territory applied to the anchor — and the controller’s defenses are the state of the art that prices those attacks. Anchor-level attack: glitching the boot ROM’s verification (H6) — countered by silicon with glitch-hardened ROM checks (redundant, randomized, monitor-backed) and by the economic reality that ROM attacks are per-fab-process research. Sealed-storage bypass: faulting the unseal path or the PCR-extend logic — countered by fail-closed designs (failed unseal = zeroized) and by PCR policies that bind to multiple stages (a fault in one doesn’t unseal). Attestation forgery: attacking the AK or the signing path to fake quotes — countered by the EK-bound AK certification (the quote’s key must trace to the factory identity) and by remote verifiers that check the certificate chain. TEE boundary attacks: vulnerabilities in the trusted apps or the secure-monitor gate — countered by TEE patch cadence (the mini-OS’s patch story is part of the supply chain, H10) and by TA surface minimization. Integration-level bypass: the “ornament” deployments (TPM present, nothing anchored) — countered by the acceptance checklist that makes integration a shipping gate (H12), because the cheapest attack on a TPM is not using it. The meta-point: the silicon tier’s security is a chain — ROM anchor → measured boot → sealed secrets → attestation — and every link that’s missing converts the controller into an ornament; the assessment’s job is measuring the chain per deployment, and the design review’s job is pricing each link before shipment.

⚠️ What caught me: I audited a “TPM-secured” IoT gateway with every expectation of the ornament finding — and got a surprise in the other direction: the PCRs were beautifully extended, secrets were sealed to boot state, attestation worked end to end. The gap was one layer up: the * sealing policy* bound secrets to PCRs 0-7, but the sealed secret was the web admin’s password hash — protecting a credential that the device’s own web UI would reset to factory default on any 30-second button press. The TPM was doing world-class work anchoring a door that had a window. Since then, every root-of-trust assessment ends with the “what does the seal actually protect” inventory — the chain is only as strong as what it guards, and the guard-worth-a-cement-truck-around-a-cardboard-box finding is the one clients remember.

Lab Practice

1. TPM posture: run tpmcheck.py on a TPM-equipped Linux device (or QEMU with swtpm [verify setup]); read the PCR state and confirm what measured boot actually covers on your bench.
2. Chain audit: capture your lab board’s boot log (H1), run trustchain.py, and classify each stage’s anchor — your device’s trust chain, drawn and graded.
3. Sealing drill: seal a secret to current PCRs on the bench TPM, then boot with a modified kernel cmdline (simulating tamper) and confirm the unseal fails — the lock-and-wall binding, proven.
4. Attestation end to end: generate a quote, verify its signature against the AK certificate on a second machine — the remote-verification path, walked once.
5. Ornament-to-anchor exercise: take the tpmcheck “NOT IN USE” finding from a lab device and implement the fix (enable measured boot, seal one real secret), then re-run and confirm the posture change — the remediation cycle, hardware edition.

Interview Questions

• Technical: Explain TPM 2.0’s PCR extension model and how sealed storage binds secrets to measured boot state.
• Technical: Distinguish TPM, secure element, TEE, and HSM on what each protects and which attack classes each claims to resist.
• Scenario: tpmcheck reports “TPM present but measured boot NOT IN USE” on a device advertised as “TPM-secured.” What does that mean, and what is the remediation?
• Conceptual: Why does certification level (CC EAL, FIPS level) price H6/H7 attack resistance — and what does a certification NOT claim?
• Conceptual: How does remote attestation change fleet security operations, and what does the verifier need to trust a quote?
• Deep-dive: Design the hardware-root-of-trust acceptance program: chain audit, TPM posture, sealing inventory, attestation coverage, and the silicon-procurement matrix.
• Practical: The product team asks whether to add a TPM to the next device. What do you tell them about cost versus anchor value — and what integration work makes it real?

Related Modules

H6 (Glitching & Fault Injection) · H7 (Side-Channel Analysis) · H10 (Supply Chain & Update Security) · F4 (Cryptography Fundamentals) · H12 (Hardware Adversary Emulation Program)