TPM

What It Is

A TPM (Trusted Platform Module) is a dedicated security chip (or firmware implementation) that provides tamper-resistant cryptographic operations and small secret storage. It's soldered to the motherboard on most modern PCs, servers, and laptops. Windows 11 requires a TPM 2.0.

Think of it as a tiny, paranoid safe that can do math. You can put secrets in it, ask it to sign things or encrypt things, but you cannot extract the private keys. The TPM performs operations internally and only returns results.

TPMs come in three forms:

Discrete: A separate physical chip on the motherboard. Highest security -- isolated hardware, hardest to attack.
Firmware (fTPM): Code running in the CPU's trusted execution environment (AMD PSP on AMD, Intel ME on Intel). Most common on consumer hardware. No extra chip needed but depends on the security of the CPU's secure enclave.
Virtual (vTPM): Emulated by a hypervisor for VMs. No hardware root of trust -- only as secure as the hypervisor.

How It Works

TPM 1.2 vs 2.0

TPM 2.0 replaced TPM 1.2 with major improvements:

Feature	TPM 1.2	TPM 2.0
Algorithms	SHA-1, RSA-2048 only	SHA-256, SHA-384, ECC P-256, RSA, extensible
Key hierarchies	One fixed	Multiple (endorsement, platform, storage, null)
Authorization	Simple HMAC	Enhanced Authorization (EA) -- complex policies
Required by	Older enterprise	Windows 11, modern systems

TPM 1.2 is obsolete. All discussion below refers to TPM 2.0.

Key Hierarchy

The TPM organizes keys in a hierarchy:

Endorsement Key (EK): A permanent key burned in at manufacturing (or generated once, never changed). The EK uniquely identifies the physical TPM. Its certificate is signed by the manufacturer (Infineon, STMicro, etc.) and proves the key lives in a genuine TPM. The EK can only decrypt or perform key agreement -- it is never used for signing directly. This is a privacy measure: the EK is a permanent hardware ID, so using it for signing would make every signature traceable to a specific physical chip.

Storage Root Key (SRK): The root of the hierarchy used to protect (wrap) other keys. When you create a key "in the TPM," it's actually encrypted with the SRK and stored externally (on disk). The TPM can load it back, decrypt it internally, and use it -- but the raw key bits never leave the TPM boundary. This means the TPM can manage far more keys than its small internal storage would allow.

Attestation Key (AK): A signing key used specifically for attestation (proving your boot state to a remote verifier). The AK exists so you can sign attestation quotes without revealing your EK. A Privacy CA protocol links the AK back to a genuine EK without exposing the EK to the verifier.

PCRs (Platform Configuration Registers)

PCRs are the TPM's boot measurement mechanism. A TPM 2.0 has 24 PCRs (numbered 0-23), each holding a SHA-256 hash. They have one critical property: PCRs can only be extended, never directly written.

Extending a PCR means:

new_value = SHA-256(current_value || new_measurement)

Each boot component measures (hashes) the next component and extends the result into the appropriate PCR before executing it. This creates a chain:

PCR	What's measured
0	UEFI firmware code
1	UEFI firmware configuration
2	Option ROMs (add-in card firmware)
3	Option ROM configuration
4	Bootloader (MBR/GPT/UEFI app)
5	GPT partition table
7	Secure Boot policy (PK, KEK, db, dbx)
8-9	OS kernel, initrd (varies by bootloader)
11	UKI sections (measured by ruki-stub)
14+	Application-specific

Because extend is one-way, no component can retroactively change its PCR. The final PCR values form an unforgeable record of exactly what software ran during boot.

Sealing

Sealing binds a secret to specific PCR values. You tell the TPM: "Store this secret, but only release it if PCRs 0, 4, 7, and 11 have these exact values." If anything in the boot chain changes (firmware update, different bootloader, tampered kernel), the PCRs won't match and the TPM refuses to release the secret.

This is how disk encryption keys are tied to a known-good boot chain:

At setup: seal the LUKS key to the current PCR values
At boot: ask the TPM to unseal the key -- succeeds only if the boot chain matches
After tampering: PCRs are different, TPM refuses, disk stays locked

NV (Non-Volatile) Storage

TPM NV storage is a small area of persistent, tamper-resistant memory inside the TPM. Typically 6-8 KB total (the spec requires at least 1,280 bytes). NV indices are like named slots -- you define an index with access policies (who can read, who can write) and store small values.

FortrOS stores two values in TPM NV:

Index 0x01500001: preboot_secret (32 bytes)
Index 0x01500002: Ed25519 keypair (64 bytes)

These persist across reboots. The access policy allows reading only during the preboot (before the main OS takes over), adding a timing-based security boundary.

Remote Attestation

The TPM can sign its current PCR values with the Attestation Key, producing a TPM Quote. A remote verifier (like the org's provisioner) can:

Send a challenge (nonce) to prevent replay
Receive the signed PCR quote
Verify the signature chains to a genuine TPM (via EK certificate)
Compare PCR values against a known-good baseline

This proves to the verifier that the machine booted genuine, untampered software. FortrOS uses this for future attestation-based enrollment (the org can verify that a joining node booted a genuine FortrOS image before granting membership).

Security Considerations

fTPM vs discrete: Firmware TPMs run on the AMD PSP or Intel ME, which means a PSP/ME compromise is also a TPM compromise. Discrete TPMs are physically isolated from the CPU. For high-security deployments, discrete TPMs are preferred.

Physical attacks: Discrete TPMs communicate with the CPU over a bus (SPI or I2C). An attacker with physical access can sniff this bus and extract secrets as they transit from TPM to CPU. This is a known attack vector that requires hardware skill but is not theoretical.

TPM reset attacks: Some older TPMs could be reset by hardware manipulation, clearing PCR values. Modern TPMs (2.0) are more resistant but physical attacks remain a concern for high-value targets.

How FortrOS Uses It

Preboot identity storage: preboot_secret and Ed25519 keypair in NV indices. These are the preboot's persistent credentials.
LUKS key derivation: preboot_secret is an input to HKDF, which derives the LUKS encryption key for /persist. See Key Derivation.
Measured boot (future): Seal the LUKS key to PCR values so the TPM only releases it if the boot chain is unmodified.
Remote attestation (future): Prove to the org that a node booted genuine FortrOS before granting membership.
No-TPM degraded mode: Without a TPM, preboot_secret is lost on reboot. /persist is reformatted each boot. Single-boot-cycle operation.

Ownership Contract

The bootstrapper takes positive ownership of the TPM NV slots it uses. Running the bootstrapper (any PXE boot that reaches /bootstrap) is, by design, a full reprovision: it tpm2_nvundefines slots 0x01500001 (preboot_secret) and 0x01500002 (preboot signing key) before writing a fresh preboot.efi to a fresh ESP. The preboot that boots next sees empty NV and runs the first-boot enrollment path against the current admin's org.

The doctrine: "whoever is running the installer takes ownership." Stock Windows follows the same contract in reverse -- the Windows installer re-owns the TPM slots it needs as part of its normal install flow. A machine can move between FortrOS and Windows with a clean handoff in either direction; neither side inherits cruft from the other.

Preserving identity across a disk swap (same TPM, new disk, keep the existing preboot_secret) is therefore not bootstrapper's job -- it's a separate admin tool. Running bootstrapper wipes that identity. This is deliberate: a bootstrapper invocation that doesn't reset state is indistinguishable from one that does, and silent identity carry-over has been the source of "unknown returning node" auth failures across workstation migrations.

Alternatives

Software keystores (files on disk): Simpler but no tamper resistance. If the disk is compromised, so are the keys. Suitable for development, not production.

HSMs (Hardware Security Modules): Enterprise-grade key management. Much more capable than TPMs (faster crypto, more storage, network-attached) but expensive ($500-$10,000+) and not built into consumer hardware.

TEEs (Trusted Execution Environments): CPU features like Intel SGX, AMD SEV-SNP, and ARM TrustZone that create isolated execution environments. More flexible than TPMs but different threat model -- TEEs protect running code, TPMs protect stored secrets and boot integrity. FortrOS uses SEV-SNP for confidential VMs alongside TPM for boot trust.

TPM