Trusted Platform Module (TPM)

A Trusted Platform Module (TPM) is a secure cryptoprocessor, standardized as ISO/IEC 11889, that provides hardware-based cryptographic functions and tamper-resistant key storage. Usually a discrete chip soldered to a motherboard, or an equivalent implemented in CPU firmware, a TPM generates and holds keys so that private material never leaves the device in cleartext. It also includes physical defenses that make extracting secrets by probing the silicon difficult and expensive — the same design philosophy, at commodity scale, as the secure chips inside hardware wallets.

Platform Configuration Registers and measured boot

The TPM's defining feature is its set of Platform Configuration Registers (PCRs). PCRs are reset at power-on and can only be extended — each new value is a hash combining the old value with a fresh measurement — never set arbitrarily. During boot, each component (firmware, bootloader, kernel) is hashed into a PCR before it runs, producing a tamper-evident record of exactly what the system loaded. This is called measured boot, and it differs from Secure Boot in a way worth internalizing: Secure Boot blocks unsigned code from running at all, while measured boot records what ran so the result can be verified afterward. One is a bouncer; the other is a notary. Mature systems use both.

Attestation and sealing

Because PCR values reflect the real boot state, a TPM can produce a signed "quote" for remote attestation, cryptographically proving to another party that the platform booted into an expected configuration. More immediately useful to a self-hoster is sealing: the TPM can encrypt data such that it only decrypts when the PCRs match a known-good state. The classic application is full-disk encryption where the disk key is released only if the boot chain is unaltered — modify the bootloader to capture the passphrase, and the PCR measurements change, so the TPM refuses to unseal the key. For a sovereign Bitcoiner this turns a vague "my machine is probably fine" into a verifiable claim about the box running your node, your Lightning daemon, or your self-hosted AI stack.

Limits — and where Bitcoin keys should actually live

A TPM protects the boot chain and keys at rest; it does not protect a running operating system from itself. Malware executing on a successfully booted, healthy-looking system can still use TPM-held keys through the normal interfaces — the TPM verifies what booted, not what the software does next. Discrete TPMs communicating over a motherboard bus have also been demonstrated vulnerable to physical interposer attacks that sniff secrets in transit, which is why high-assurance setups combine TPM sealing with a user-supplied PIN or passphrase. For Bitcoin specifically, the right conclusion is layered: use the TPM to harden the node and the workstation, but keep signing keys in a dedicated hardware wallet built around a purpose-designed secure element, with long-term funds in cold storage. A general-purpose platform chip and a dedicated signing device solve different problems, and the sovereign stack wants both.

Practical setup notes

Most desktop and server hardware from the last decade includes either a discrete TPM 2.0 or a firmware TPM built into the CPU — check your UEFI settings before assuming you lack one. On Linux, standard disk-encryption tooling can enroll a TPM-sealed key so the machine boots unattended while remaining protected against offline tampering; pair it with a PIN for higher assurance. Two disciplines save grief: always keep a recovery passphrase that works without the TPM (firmware updates and hardware swaps legitimately change PCR values and will lock you out), and test that recovery path before you need it, not after.

See also the cold boot attack that targets keys held in RAM outside such protected hardware — the class of attack that disk-encryption sealing is designed to blunt — and private key for what, ultimately, all of this machinery exists to protect.