A Trusted Platform Module is a small, dedicated chip (or a firmware mode of the main CPU) that performs a narrow set of cryptographic operations on behalf of the rest of the system. It has its own non-volatile storage, its own true random number generator, its own RSA/ECC/SHA implementations, and a small set of registers called Platform Configuration Registers (PCRs) whose values can only be modified by extending — appending and hashing — never by writing arbitrarily.
Architecturally, the TPM is a passive co-processor. The operating system sends it commands; it executes them and returns results. It cannot initiate anything on its own. It cannot read system memory. It is not a "hardware DRM enforcer" in the colloquial sense — it cannot prevent you from running unauthorized code. What it can do is refuse to release secrets unless certain conditions are met, and sign statements about what the system has loaded.
The Four Things a TPM Actually Does
1. Generate and store keys in tamper-resistant storage
The TPM contains a hardware random-number generator and the ability to generate RSA and ECC key pairs internally. A key generated inside a TPM cannot, by design, be extracted in plaintext. The private half exists only on the chip. Software can ask the TPM to sign or decrypt with that key, but cannot ever read the key material itself.
This is the property that makes TPM-backed keys useful: a stolen disk image does not yield the keys. Cloning the machine does not clone the keys. To get the keys, you need physical access to the specific chip, and even then extraction requires invasive attacks like decapping or fault injection that are well outside casual threat models.
2. Measure the boot chain
During boot, every component — UEFI firmware, bootloader, kernel — measures the next component before executing it. "Measure" here means hashing the binary and extending one of the TPM's PCRs with that hash. The PCR's new value is SHA256(old_value || new_measurement).
You cannot fake a PCR value forward. To make a PCR read a particular value, you must have arrived at that value through the actual sequence of measurements. A different bootloader produces a different PCR. A tampered kernel produces a different PCR. Whatever the system actually did is recorded in PCRs that no software running on the system can rewrite.
3. Seal secrets to PCR values
A TPM can be asked to encrypt a secret in such a way that only the same TPM, with the same PCR values, can decrypt it. This is called sealing. The classic use case: BitLocker on Windows seals the disk encryption key to the PCRs that measure UEFI, the bootloader, and the kernel. If any of those change, the seal fails and the disk does not auto-unlock.
An attacker who steals your laptop cannot boot a malicious kernel and have the TPM hand over the disk key. The boot chain measurement will not match, and the TPM refuses to unseal. They must either know your passphrase, recover the key through physical attack on the chip, or find a flaw in the boot chain itself.
4. Attest to a remote party
The TPM can produce a signed statement saying "my PCRs currently read these values" — signed with a TPM-resident key that was provisioned at manufacture and can be verified against the manufacturer's certificate chain. A remote server can use this attestation to decide whether to trust the device: did it boot the expected firmware, the expected kernel, the expected userspace measurement?
This is the basis for measured-launch enterprise deployments, Windows Device Health Attestation, Android's Play Integrity API, and the various forms of "this device is in a known-good state" checks that high-security environments depend on.
What TPM Does Not Do
Common misconceptions worth correcting:
- The TPM does not encrypt your disk. BitLocker does. The TPM holds and conditionally releases the key. The actual encryption work runs on the CPU.
- The TPM does not "lock you out of your computer." If sealing fails, you fall back to a recovery key. You can use the recovery key. The TPM does not have an opinion about that.
- The TPM does not enforce DRM in the strong sense. It can attest to what's running, but a remote service deciding whether to serve you content is the actual enforcer. The TPM tells the truth; the remote service decides what to do about it.
- The TPM does not prevent malware from running. It records what ran. Detection and prevention require software that consults those records.
Discrete TPM vs Firmware TPM
| Form factor | What it is | Trade-offs |
|---|---|---|
| dTPM (discrete) | Separate chip on the motherboard | Physically isolated from CPU. Stronger isolation. Susceptible to bus-sniffing attacks (see below). |
| fTPM (firmware) | Runs in CPU TrustZone / SGX / PSP | No separate chip needed. Shares fate with CPU. Subject to side-channel attacks like Spectre/Meltdown variants if firmware has bugs. |
| Apple Secure Enclave | Apple's TPM-equivalent, much more capable | Not TPM 2.0 standard, but performs the same role and more. Tightly integrated with iOS/macOS key management. |
| Google Titan / Pluton | Vendor-specific secure coprocessors | TPM-equivalent functionality with deeper OS integration. Pluton ships on newer Windows hardware as a TPM 2.0 implementation. |
Known Attacks
The TPM is not magic. Documented attacks include:
- Bus sniffing on dTPM. A discrete TPM communicates with the CPU over an SPI or LPC bus. When BitLocker uses TPM-only mode (no PIN), the disk key transits this bus in plaintext after unsealing. Demonstrated extractions take minutes of physical access with cheap logic analyzers — this is the Pulse Security / SecuraBit pre-boot attack. Mitigation: require a BitLocker PIN, so the key is also wrapped under the PIN, never traversing the bus by itself.
- TPM-Fail (2019). Side-channel attacks on Intel's fTPM and STMicroelectronics dTPMs allowed key extraction via timing analysis. Patched in microcode/firmware updates.
- fTPM glitches. Voltage and clock glitching attacks against AMD's fTPM have been demonstrated by researchers extracting keys. Requires physical access and specialized equipment.
- Cold boot. If the disk key has been unsealed and is sitting in RAM, a cold-boot attack can recover it from chilled DRAM after a forced reboot. The TPM is not involved at that point.
These attacks are real but require physical access and specialized capability. Against bulk attackers (stolen-laptop scenarios), TPM-based disk encryption is highly effective. Against a targeted adversary with hardware-attack expertise, it is one layer among several.
The Windows 11 Mandate
Microsoft made TPM 2.0 mandatory for Windows 11 in 2021, which produced widespread frustration because many recent machines either lacked a TPM or had it disabled in firmware by default. The technical rationale was reasonable: with TPM 2.0 guaranteed, Microsoft could ship features like BitLocker by default, Windows Hello with hardware-backed credentials, Device Health Attestation, and Pluton-based key isolation as baseline assumptions rather than optional add-ons.
The rollout was clumsier than the rationale. Many users discovered their machine "didn't have a TPM" only to find that the fTPM was disabled in the UEFI and a single firmware setting flip fixed it. Others were genuinely stuck on older hardware. The net effect was that TPM 2.0 went from "obscure security feature" to "thing most users know exists" in about six months.
What This Means for You
Practical implications:
- If you use BitLocker, FileVault, or LUKS+systemd-cryptenroll, your TPM is the reason your disk auto-unlocks. The seal-to-PCR mechanism is what makes the trade-off "no password at boot" vs "disk readable if stolen" actually work.
- Set a BitLocker PIN if you're on a Windows laptop you care about. Without a PIN, bus-sniffing attacks recover the disk key with minutes of physical access.
- Use Secure Boot. Without it, the boot chain measurements that the TPM relies on can be circumvented by booting a different OS off USB.
- Hardware-backed credentials (Windows Hello, FIDO2 keys, Android key attestation) ride on TPM/Secure Enclave. These are stronger than software-stored credentials because the private key never leaves the chip.
- Don't assume "TPM" means uniform security. A dTPM in a 2014 desktop with a 2014 UEFI is not the same security profile as Apple's Secure Enclave or Microsoft Pluton in 2024 hardware. The architecture matters.
The TPM is a small, narrow tool that does one thing well: anchor secrets to a specific boot configuration of a specific physical machine. Used correctly, it makes whole classes of attack (stolen laptops, tampered firmware, off-line disk attacks) substantially harder. Used by itself, it does not produce a secure system — but no single component does.
Where Haven Fits
Haven's key derivation runs entirely client-side, with passphrase-derived keys via PBKDF2. We do not currently bind keys to TPM/Secure Enclave by default — partly because cross-platform parity is hard, and partly because the passphrase model already protects against the threats that matter most for messenger data.
For users with TPM-backed full-disk encryption underneath Haven (BitLocker on Windows, FileVault on macOS, LUKS+TPM on Linux), the device itself is already protected against the cold-storage threats that motivate hardware-key binding. Different layer, different threat, both worth having. For more on the layered model, see our piece on disk encryption.