Trusted Platform Module 2.0

What a TPM 2.0 actually is

A Trusted Platform Module 2.0 (TPM 2.0) is a small cryptoprocessor that lives on a device and does three unglamorous but critical things: it generates and stores keys that cannot be exported, it records what code the device ran during boot, and it signs statements about both. It is specified by the Trusted Computing Group (TCG) in the TPM 2.0 Library Specification, and it replaces the older TPM 1.2 standard with a more flexible algorithm-agnostic design.

TPMs come in three shapes that all speak the same protocol:

From the software side you talk to all of them the same way — through a TPM Software Stack (TSS) or a lower-level library like github.com/google/go-tpm. The kernel exposes the chip as /dev/tpm0 (raw) or /dev/tpmrm0 (resource-managed). Applications never see the private keys.

How it works

Everything a TPM does traces back to two features: protected keys and measurement.

Protected keys. When code asks the TPM to generate a key (via TPM2_CreatePrimary or TPM2_Create), the private half stays inside the chip. Software receives a handle and a public area (TPM2B_PUBLIC). To use the key you send the TPM a command like TPM2_Sign or TPM2_Certify and it does the operation internally. Even a fully compromised operating system cannot extract the raw private bytes — that is the whole point of the design.

Measurement. During boot, each stage hashes the next stage's code and configuration and extends the hash into a Platform Configuration Register (PCR):

PCR[n] = SHA256( PCR[n] || measurement )

Because extend is cumulative and one-way, the final PCR value is a fingerprint of every measurement that fed into it, in order. Different firmware, different bootloader, different kernel — different PCR values.

The TPM will sign a report of its current PCR values with a special key called an Attestation Key (AK). That signed report is called a quote (TPM2_Quote). The quote includes a caller-supplied nonce so the recipient can verify freshness. This is the raw material of remote attestation.

What problem it solves

Traditional device authentication assumes "if you can present a certificate, you are trustworthy." That fails the moment credentials are stolen, cloned into a VM, or exfiltrated by malware. A TPM lets the device prove three additional things a stolen credential cannot:

1. The key material is bound to this specific silicon. Copy the certificate file all you like — the private key never left the chip.
2. The device booted the software you expect. The PCR values tell you whether firmware, bootloader, and (with IMA) userspace binaries match a golden reference.
3. The device is who it claims to be. Every TPM ships with a manufacturer-signed Endorsement Key (EK) certificate. Chain-verify it to Intel, Infineon, ST, Nuvoton, AMD, or whoever, and you have a hardware identity you did not have to bootstrap yourself.

That set of guarantees is exactly what regulators are starting to require for critical infrastructure and IoT — see NIST SP 800-193, the EU CRA, and the U.S. NCS/NCSIP.

When to use it

Reach for TPM 2.0 when:

• You are issuing certificates to devices you do not physically control (IoT gateways, edge servers, medical equipment, industrial controllers).
• The blast radius of a stolen private key is unacceptably large.
• You need audit-quality evidence of what firmware and software ran, not just what was installed.
• You are subject to compliance frameworks that reference hardware-backed keys — FIPS 140-3, Common Criteria, IEC 62443, HIPAA hardware controls, or PCI-DSS 4.0 requirement 3.6.

Skip it (or postpone it) when the device is short-lived, ephemeral (say a Kubernetes pod — use SPIFFE instead), or when there is no TPM in the hardware and you cannot enable an fTPM.

Common misconceptions

"TPM is just secure key storage." It is that, but the more interesting feature is attestation — the ability to sign statements about the device's state that a remote party can verify. A hardware security module (HSM) stores keys; a TPM stores keys and reports device state.

"fTPM is not real security." Firmware TPMs run inside the CPU's trusted execution environment (Intel TXT/PPT, AMD PSP). They are not as tamper-resistant as a discrete chip against physical attacks, but for remote-attacker threat models they provide the same cryptographic guarantees. Windows 11 requires TPM 2.0 for exactly this reason and accepts fTPMs.

"TPMs prevent malware." They do not. A TPM will happily measure malware into its PCRs and sign a quote saying "I am running malware." What it prevents is the malware lying about it. Enforcement happens on the verifier side — the server that receives the quote refuses to issue certificates when PCR values do not match a golden reference.

"TPMs are slow, so I cannot use them for TLS." True — a TPM's signing throughput is measured in single-digit signatures per second, not thousands. The right pattern is to use the TPM to bind a long-lived identity key whose certificate authorizes shorter-lived operational keys. Or to use the TPM to seal an in-memory ephemeral key that is unsealed only when PCR state matches.

How TigerTrust uses TPM 2.0

TigerTrust's PKI issues certificates only to devices that can prove — using their TPM — three things: they are running expected firmware (via a signed TPM2_Quote over the PCRs), the Attestation Key doing the signing actually belongs to that TPM (via TCG Credential Activation against the manufacturer EK certificate), and the CSR's public key was generated inside and cannot leave the chip (via TPM2_Certify). All three checks run in the PKI Core verifier before a CA ever sees the certificate signing request. This is documented in detail in the project's TPM_ATTESTATION design doc.

Related reading

• TCG TPM 2.0 Library Specification — the source of truth.
• github.com/google/go-tpm — the Go client library most modern verifiers use.
• IETF RFC 9334 (RATS Architecture) — how remote attestation fits together in general.