TPM Integration: Practical Measured Boot Flow

TPM in embedded: what it does and what it does not do

TPM is useful, but teams misuse it when they expect it to replace secure boot.

TPM does

• Stores keys with tamper-resistant boundaries.
• Records boot measurements in PCRs (measured boot).
• Enables attestation: proving measured state to a verifier.
• Seals secrets so they unseal only under expected PCR values.

TPM does not

• Automatically verify all boot images for you.
• Replace ROM/fuse key anchors.
• Fix unsigned recovery/update paths.

Measured boot vs verified boot

• Verified boot: block execution of untrusted images.
• Measured boot: record what actually executed.

Production systems often need both:

• Verified boot enforces.
• Measured boot provides visibility/attestation.

TPM integration flow (practical)

1. U-Boot verifies signed artifacts.
2. Hashes of boot stages/artifacts extend TPM PCRs.
3. Kernel/service reads PCRs and compares against allowed reference set.
4. Remote backend can request attestation quote before granting sensitive access.
5. Device secrets are sealed to approved PCR states.

Practical component comparison

• TPM: standard measured boot + attestation + sealed secrets
• Secure element: small isolated key store, limited compute/standardization
• TrustZone/TEE: isolated execution environment in SoC
• OTP/fuse: immutable anchor, not dynamic measurement engine
• HSM: server-side key protection for signing infrastructure

Practical takeaway

Use TPM when you need measured-state evidence and secret sealing tied to boot integrity, not just signature enforcement.

Misconception to correct

"If I add TPM, I automatically have secure boot."
No. TPM complements secure boot; it does not replace boot verification architecture.