Electronics Guide

Articles in This Category

Architecture and Internal Components

A TPM is a self-contained microcontroller with a fixed command interface and no general-purpose programming model. Host software sends byte-encoded commands and receives byte-encoded responses; it cannot load arbitrary code into the module. That narrow interface is the primary security boundary, and it is what allows a physically small, inexpensive part to make meaningful guarantees.

Inside, a cryptographic engine performs RSA, elliptic curve, SHA, and HMAC operations in hardware. A hardware random number generator, seeded from a physical entropy source, supplies the randomness for key generation and nonces. Platform Configuration Registers hold integrity measurements of the boot sequence. Shielded non-volatile memory stores primary seeds, authorization values, monotonic counters, persistent key handles, and vendor-provisioned certificates across power cycles. A volatile object store holds the handful of keys and sessions that are loaded at any moment.

The TPM does not initiate anything. It has no direct memory access, no bus mastering, and no ability to interrupt or halt the host. It cannot detect that the platform has been modified; it can only record what the platform tells it and refuse to release secrets when those records do not match a policy. Every guarantee therefore depends on the measuring code being trustworthy at the moment it takes each measurement.

Authorization is enforced per object. A key or non-volatile index may be protected by a plain password, by an HMAC session that proves knowledge of an authorization value without transmitting it, or by an enhanced authorization policy that composes conditions such as required PCR values, a signed authorization from a named authority, a time or counter threshold, or possession of a specific secret. Failed authorization attempts feed a dictionary attack counter that locks the module for a configured recovery interval once the failure threshold is reached.

Specifications and Versions

TPM 1.2, widely deployed from the mid-2000s, established the core ideas of platform measurement, sealed storage, and attestation. It also hard-coded its cryptography: RSA 2048 for asymmetric operations and SHA-1 for measurement. On personal computers it provided twenty-four 20-byte PCRs holding SHA-1 digests, and it offered no mechanism to migrate to a stronger hash. As practical collision attacks against SHA-1 matured, that rigidity became the specification's defining weakness.

TPM 2.0 is an architectural rewrite rather than an increment. The TCG published the library specification in 2014, and it was adopted as the international standard ISO/IEC 11889:2015; the TCG has continued to revise the document since, so the current TCG text is ahead of the ISO edition. Revision 1.83 was published in 2024, and revision 1.85 followed in March 2026. The central change is cryptographic agility: algorithms are identified through an extensible algorithm registry rather than fixed in the command definitions, and a TPM may implement several at once.

That agility shows up most clearly in PCR banks. A TPM 2.0 device maintains a separate bank of registers for each supported hash algorithm, so the same boot event can be extended into a SHA-1 bank for legacy verifiers and a SHA-256 bank for current ones. The PC Client Platform TPM Profile, which defines what a TPM in a personal computer or server must provide, requires a SHA-256 bank, RSA 2048, and elliptic curve operations over the NIST P-256 curve, and it requires at least twenty-four PCRs per bank.

TPM 2.0 also replaced ad hoc authorization with the unified enhanced authorization framework, introduced the four-hierarchy key model described below, and defined behavior for form factors that TPM 1.2 never anticipated, including firmware implementations and per-virtual-machine instances. Version 1.85 added the first post-quantum algorithms to the specification, discussed under future directions.

Measured Boot and Secure Boot

Measured boot and secure boot are complementary but distinct, and only the first requires a TPM. Secure boot, as specified for UEFI firmware, verifies a digital signature on each executable before running it and refuses to execute anything that does not chain to an authorized key. It is an enforcement mechanism, it operates entirely within the firmware, and it works on a platform with no TPM at all.

Measured boot records rather than blocks. Each stage of the boot chain hashes the next component and extends that digest into a PCR before transferring control. The extend operation is deliberately one-way: the register's new value is the hash of its old value concatenated with the new measurement, so measurements accumulate into a chain that cannot be rewound or reordered by later code. Only a TPM reset returns a PCR to its default value. Software can therefore add measurements but can never remove the record of its own predecessor.

Alongside the PCRs, the firmware maintains a TCG event log in ordinary memory that records each measured event in the clear. The log itself is unprotected, but a verifier can replay it, recompute the expected PCR values, and compare them with the TPM's signed report. If the recomputation matches, the log is authentic; if it does not, the log has been altered. This design keeps the TPM small, since it needs to store only the folded digests, while still allowing a verifier to see exactly which components were loaded.

On personal computers the TCG profile assigns PCRs to roles: PCRs 0 through 7 cover firmware code, configuration, option ROMs, and the secure boot policy; PCRs 8 through 15 are available to the boot loader and operating system; and PCRs 17 through 22 are reserved for a dynamic root of trust established after boot by an instruction such as Intel TXT's SENTER or AMD's SKINIT. A dynamic root of trust is valuable because it resets a defined range of PCRs at runtime and measures a small, tightly scoped block of code, which shortens the trust chain from the whole firmware stack to a single measured launch environment.

Used together, secure boot enforces a policy while measured boot produces the evidence, and the two answer different questions. Secure boot answers whether the platform would run unauthorized code. Measured boot answers what the platform actually ran.

Remote Attestation

Remote attestation lets a platform prove its measured state to a party that cannot inspect it physically. The verifier sends a random nonce; the platform calls the TPM's quote command, which signs the selected PCR values together with that nonce using a restricted signing key; and the platform returns the signed quote alongside its event log. The nonce prevents replay of an old quote, and the restriction on the signing key prevents software from asking the TPM to sign an arbitrary structure that merely resembles a quote.

The key used for quoting is called an attestation key in TPM 2.0, a renaming of TPM 1.2's attestation identity key. It is distinct from the endorsement key by design. The endorsement key is unique to the module and typically accompanied by a manufacturer certificate, which makes it strong evidence that a genuine TPM is present but also makes it a permanent hardware identifier. Using it to sign every attestation would let every verifier correlate a machine's activity across unrelated services.

Two approaches break that correlation. A privacy certificate authority receives the endorsement credential once, confirms that it belongs to a real TPM, and issues certificates for attestation keys that carry no permanent identifier; verifiers then see only the attestation key, while the privacy CA holds the link. Direct Anonymous Attestation removes the trusted third party from the transaction entirely by using a group signature scheme, so a platform proves it holds a valid credential from an issuer without revealing which member of the group it is. TPM 2.0 specifies an elliptic curve variant of the scheme, and the same construction underpins the attestation used by FIDO authenticators.

A quote by itself proves very little. The verifier must also hold reference values, sometimes called golden measurements, for the firmware and boot components it considers acceptable. Assembling and maintaining those reference values across a fleet of machines from different vendors, with firmware that updates on the vendors' schedules, is the hard operational problem in attestation deployments, and it is the reason many organizations attest a narrow set of registers rather than the full boot chain.

Key Hierarchies and Key Management

TPM 2.0 organizes keys into four hierarchies, each rooted in a primary seed held in shielded storage and each under separate administrative control. The endorsement hierarchy derives from the endorsement primary seed and produces the endorsement key that identifies the module; the platform manufacturer provisions it and its certificate. The storage hierarchy, sometimes called the owner hierarchy, derives from the storage primary seed and serves the platform owner and ordinary applications. The platform hierarchy derives from the platform primary seed and is reserved for firmware. A fourth, the null hierarchy, uses a seed regenerated at every reset, so keys created under it are ephemeral by construction and become unusable after a reboot.

Separating the hierarchies separates the parties. An enterprise that takes ownership of a machine clears and reprovisions the storage hierarchy without disturbing the manufacturer's endorsement credential or the firmware's platform keys. Clearing the storage hierarchy regenerates its seed, which cryptographically destroys every key derived from it in a single operation.

Because the module's internal memory is small, most keys live outside it. A parent key wraps each child key into an encrypted blob that the host stores on disk and loads back into the TPM on demand. The wrapping key never leaves the module, so an unlimited number of keys can be protected by a device that holds only a few at a time. Primary keys are not stored at all in the usual sense: the TPM regenerates them deterministically from the hierarchy seed and a template whenever they are needed, which is why the storage primary key, conventionally called the storage root key, can be recreated after a power cycle without having been saved.

TPM 2.0 replaced TPM 1.2's migratable and non-migratable labels with explicit object attributes. A key marked fixedTPM can never be duplicated to another module; a key marked fixedParent cannot be moved to a different parent within the same module. Clearing both attributes allows the duplication command to export the key under a new parent's protection, which is how a key is backed up or replicated to a second device under controlled conditions. Attestation and endorsement keys are marked fixedTPM precisely so that their signatures remain proof of a specific piece of silicon.

Authorization policies attach to individual objects and are evaluated as a digest accumulated over a session. A policy can require that PCRs hold specific values, that a particular authorization value be presented, that a named authority sign the request, or any combination of these. Policies compose with logical AND by chaining assertions in one session and with logical OR by listing acceptable policy digests, which makes it possible to express rules such as "release this key only during measured boot, or on presentation of a recovery credential."

Form Factors

Discrete TPMs are separate packaged chips attached to the host over the LPC, SPI, or I2C bus. They offer the strongest isolation, since the security boundary is a distinct die with its own power and reset domain, and high-assurance parts add shielding, active sensors, and zeroization on tamper detection. They are also the form factor most exposed to bus probing, because the wires between the chip and the host are physically accessible.

Integrated TPMs place the same functionality on a die that serves other purposes, such as a chipset or a system-on-chip. Cost and board area fall, and the interconnect is no longer exposed on the board, but the module now shares a package with logic that has other responsibilities.

Firmware TPMs implement the specification as software running inside an isolated execution environment on the main processor, such as Arm TrustZone, the AMD Secure Processor, or the Intel Converged Security and Management Engine that hosts Intel Platform Trust Technology. They add no bill-of-materials cost and can be patched in the field, which matters when a specification errata or a vulnerability requires a fix. In exchange, they inherit the host's threat surface: a flaw in the isolation mechanism, in the surrounding firmware, or in the processor's side-channel behavior can undermine the module, and the fTPM depends on the host's power management for correct operation.

Virtual TPMs give each virtual machine its own instance, implemented by the hypervisor. They make measured boot and sealed storage available to guests and to cloud workloads, but the guest's root of trust is only as strong as the hypervisor and the host platform beneath it. A serious deployment therefore anchors the vTPM implementation to a physical TPM or an equivalent hardware root on the host, so that the host itself can be attested before its guests' attestations are believed.

The trade-off is consistent across the range. Moving the module closer to the host lowers cost and improves manageability while widening the set of failures that can compromise it. The right choice depends on whether the expected adversary has physical access to the board.

Sealed Storage

Sealing binds a secret to a platform state. The application creates a small data object whose authorization policy requires specified PCRs to hold specified values, and the TPM will unseal it only when that condition holds at the time of the request. The sealed blob can be stored anywhere, including on an unencrypted partition, because it is useless without the module that wrapped it and the boot state that satisfies its policy.

Full disk encryption is the canonical application. BitLocker seals the volume master key to the TPM so that the disk decrypts automatically on an unmodified machine and fails to decrypt if the firmware, the secure boot policy, or the boot loader has been replaced. On UEFI systems with secure boot enabled, the default validation profile relies on PCR 7, which records the secure boot policy and the keys in use, together with PCR 11, which the boot manager uses to signal that the volume has been unlocked. Basing the policy on the secure boot state rather than on hashes of individual binaries keeps the seal intact across ordinary firmware and boot loader updates. Linux implementations expose the same capability through the LUKS key slots managed by systemd-cryptenroll or Clevis.

Brittleness is the practical difficulty. Any legitimate change that alters a measured value, including a firmware update, a settings change in the setup menu, or the addition of an option ROM, will change a PCR and break the seal. Every deployment therefore needs an independent recovery path, such as a printed or escrowed recovery key, and an update procedure that reseals the secret to the new expected values before the change takes effect. TPM 2.0 softens the problem with policy authorization, in which the object's policy names a signing authority rather than a fixed PCR digest; the vendor or administrator can then issue a signed policy that admits the new measurements without rewrapping the sealed object.

Applications

Full disk encryption is the most widespread use, covering BitLocker on Windows and LUKS-based schemes on Linux. Credential protection is close behind: Windows Hello for Business holds its authentication keys in the TPM so that they cannot be exported, and Credential Guard, which isolates secrets in a virtualization-based enclave, binds that enclave's keys to the TPM so that its protected data does not survive a move to another machine. Platform device identity follows the same pattern, with a TPM-resident key backing a client certificate for network access control under 802.1X or for enrollment into a device management service.

Code signing and release engineering use TPMs to keep signing keys non-exportable on build and release hosts, so that compromise of the host produces unauthorized signatures during the compromise window rather than a stolen key that remains valid indefinitely. TLS clients and SSH clients can hold their private keys in the TPM through a PKCS #11 module or a provider engine, binding the credential to the machine.

Industrial controllers, medical devices, and network infrastructure use TPMs to verify firmware integrity, to hold the keys that authenticate signed updates, and to give a field device a manufacturer-provisioned identity that survives reprovisioning. Cloud providers use attestation to confirm that a host runs approved firmware before releasing tenant key material to it, and confidential computing services extend the pattern to individual workloads. Across all of these, the common thread is the same: the TPM converts "trust this software" into "trust this hardware, and let it vouch for the software."

Limitations and Known Attacks

A TPM is a passive recorder, not a monitor. It cannot observe the platform, cannot detect that measured code was malicious, and cannot act on its own. If a compromise occurs after the measurements are taken, the TPM will happily attest to the boot state that preceded it. Runtime integrity is outside its scope.

Bus interception is the best-documented physical attack. A discrete TPM communicates over a low-speed serial bus, and unless the host software encrypts the session parameters, the payloads on that bus are plaintext. Researchers have repeatedly shown that a volume master key can be captured on the LPC or SPI lines of a locked laptop with inexpensive equipment in a short period of unattended access. TPM 2.0 provides the countermeasure in the form of encrypted and HMAC-protected sessions that establish a shared secret with the module using a salted or bound session, but software must opt into it. The operational mitigation is to add pre-boot authentication, a PIN or a startup key, so that nothing sensitive crosses the bus until the user has authenticated.

Implementation flaws in the module itself are less common but consequential, because a single reference codebase propagates widely. In 2023, researchers reported an out-of-bounds write and an out-of-bounds read in the parameter-decryption routine of the TCG reference implementation, tracked as CVE-2023-1017 and CVE-2023-1018, which reached a wide range of discrete TPMs, firmware TPMs, and virtual TPM implementations derived from that code. Earlier work found timing side channels in the elliptic curve signature implementations of some commercial modules that allowed private key recovery. Discrete TPMs generally require a vendor firmware update delivered through the platform manufacturer, which makes patching slow.

Finally, the endorsement key raises a privacy question that no amount of engineering removes. A permanent, certified, unique hardware identifier is exactly what attestation needs and exactly what a tracking system would want. Privacy CA and Direct Anonymous Attestation protocols exist to keep that identifier from reaching relying parties, and consumer platforms are expected to use them rather than expose the endorsement key directly.

Design Considerations

Design the trust chain before choosing a module. Every link from the first instruction the processor executes to the code that consumes a sealed secret must be measured, and any mutable firmware or configuration that is not measured is a gap through which the platform state can be altered without changing a PCR. An immutable boot ROM or equivalent hardware-anchored first stage is what makes the rest of the chain meaningful.

Choose PCRs deliberately. Sealing to a broad set of registers maximizes sensitivity to tampering and also maximizes false alarms from routine updates. Sealing to a narrow set, such as the secure boot policy alone, survives updates but accepts any signed component the policy permits. State the threat being addressed and select the registers that detect it.

Budget for performance. TPM operations run on a small microcontroller across a slow bus, and an RSA key generation can take seconds. Provision keys ahead of time rather than on the critical path, prefer elliptic curve keys where the protocol allows, and keep the number of measurements in the boot path bounded.

Handle failure explicitly. Software must cope with a TPM that is disabled in setup, not yet owned, in dictionary attack lockout, or absent entirely, and it must degrade to a defined state rather than an undefined one. Provision recovery credentials before deployment, store them separately from the machines they recover, and rehearse the recovery procedure. Plan the ownership lifecycle as well: define who clears the module at decommissioning, and remember that clearing a hierarchy destroys every key beneath it irreversibly.

Standards and Certification

The Trusted Computing Group maintains the TPM library specification along with the algorithm registry, the platform-specific profiles that state what a TPM in a given class of system must implement, interface specifications for the physical buses, and the PC Client platform firmware profile that defines how firmware measures the boot sequence. Conformance testing against these documents is what makes a TPM from one vendor a drop-in replacement for another.

Common Criteria evaluation under ISO/IEC 15408 provides independent assurance, guided by a TCG-authored protection profile for PC client TPMs that fixes the security problem, objectives, and requirements so that evaluations of competing products are comparable. Commercial discrete TPMs are commonly certified at Evaluation Assurance Level 4 augmented, with the augmentation typically covering resistance to attackers of moderate or high attack potential.

FIPS 140-3 validation, administered by NIST through the Cryptographic Module Validation Program, is the requirement that governs use in United States federal systems and in many regulated industries. It supersedes FIPS 140-2, whose remaining certificates the program moves to its historical list on September 21, 2026; historical status does not revoke a certificate, but federal agencies are directed not to select such modules for new procurements. Because validation is scoped to a specific module and firmware version, a firmware update can invalidate the certificate until the revised module is validated again, which procurement schedules must accommodate.

The TPM 2.0 library is also published as the international standard ISO/IEC 11889, which supports adoption in jurisdictions and procurement regimes that require formal standardization rather than an industry consortium document.

Future Directions

Post-quantum migration is the most consequential change in progress. A TPM's endorsement and attestation keys rest on RSA and elliptic curve cryptography, both of which fall to a sufficiently large quantum computer, and platform keys have service lifetimes measured in years. NIST standardized ML-KEM, ML-DSA, and SLH-DSA in August 2024 as FIPS 203, 204, and 205. The TCG followed with TPM 2.0 library revision 1.85 in March 2026, which introduces ML-KEM and ML-DSA into the specification, including their use for endorsement and attestation keys, and extends the algorithm registry with identifiers for the parameter sets. Deployment will be slow, because the affected keys are burned into hardware at manufacture and the installed base turns over on a hardware refresh cycle.

Confidential computing is reshaping how attestation is used. Technologies such as Intel TDX and AMD SEV-SNP protect a workload from the hypervisor and produce their own attestation reports signed by the processor, so a full trust statement now combines a platform-level TPM quote with a workload-level report from the confidential computing hardware. Standardization efforts, notably the IETF Remote Attestation Procedures architecture, are working toward evidence and appraisal formats that let a verifier reason about both in one framework.

Supply chain assurance is a related growth area. A TPM provisioned at manufacture with a certified identity gives an owner a way to confirm that the device received is the device shipped, and it anchors the signed firmware manifests that increasingly accompany hardware. At the other end of the range, resource-constrained devices are driving interest in lighter-weight roots of trust, including the TCG's Device Identifier Composition Engine, which derives layered device identities from an immutable boot stage rather than requiring a full TPM.

Conclusion

The Trusted Platform Module earns its place by doing a small number of things that software cannot do for itself: it holds keys that cannot be copied out, it records an unforgeable chain of what the platform executed, and it signs that record for someone else to judge. Those three properties are enough to support full disk encryption that resists offline attack, device identities that survive operating system compromise, and attestation that governs access to enterprise and cloud resources.

Its limits deserve equal attention. A TPM measures rather than enforces, it says nothing about what happened after boot, and a discrete part is only as private as the bus that connects it. Deployments that acknowledge these boundaries, seal to well-chosen registers, use encrypted sessions, and maintain a tested recovery path get real security from the technology. The four topics above examine the pieces in detail: the architecture of the coprocessor, the configuration registers that record integrity, the key hierarchies that protect cryptographic material, and the attestation systems that carry the evidence across a network.

Related Topics