TPM 2.0 is cool, actually Like a lot of developers and computer users, my first real encounter with TPM 2.0 was: This PC doesn't meet the minimum system requirements for Windows 11. I didn't know what it was, just that it was annoying me. Over the years, I overheard that it was some kind of DRM-ish Microsoft requirement to force hardware upgrades without ever getting the chance to actually dive into what it is. But now, I actually have the need for it and I completely changed my opinion on it. The problem For CodSpeed , part of the infrastructure is a fleet of bare-metal runners that execute performance benchmarks. The results need to be trustworthy since we're making claims about performance changes, so if a runner is compromised, the whole system's integrity collapses. So a big issue to solve was: How do you authenticate that a machine is actually the hardware you enrolled? Not just that the software on it is correct but that the hardware itself hasn't been swapped, tampered with, or impersonated. The runners live in a data center. We don't physically control them 24/7. The workloads they receive are sensitive. The threat model includes someone with physical access: either an attacker, or someone inside the hosting provider. The naive approach My first instinct: generate a private key on each machine at enrollment, store the corresponding public key fingerprint in the control plane, sign a challenge at registration time. It's simple, works. Until someone reads the filesystem. A private key on disk is extractable by anyone with physical access or enough privilege escalation. You can tighten permissions, put it in a secret manager, rotate it all of which add complexity without solving the fundamental problem: the key is still a blob of bytes somewhere accessible. What I actually needed: a secret that cannot leave the hardware. Not hard to extract. Not guarded by access controls. Just physically impossible to extract. I started thinking about mobile, remembered Secure Enclave on iOS. Keys that live in dedicated hardware, never exposed to the OS. I needed the same thing essentially, but for a server. That's when I started properly reading about TPM. And realized it's been sitting on every modern motherboard all along. What TPM actually is TPM stands for Trusted Platform Module . It's a dedicated security microcontroller, soldered on the motherboard, with its own isolated execution environment. Its core promise: it can sign messages with a private key that never leaves the chip . You can ask it to sign things, to generate keys but you cannot ask it to export raw key material, because that operation purposefully doesn't exist in the command interface. It communicates with the host over SPI or PCIe, through a standardized API called TSS (Trusted computing group Software Stack). The Windows 11 drama gave TPM a reputation as a bureaucratic gatekeeper. The actual technology is the opposite of that, solving a genuinely hard problem. EK, AK, and the credential activation protocol Two keys matter for hardware attestation. Their design is more thoughtful than it first appears. Endorsement Key (EK) It's called "endorsement" because it's literally the manufacturer's endorsement of the chip. When Infineon, STMicro, or NXP produces a TPM, they burn a unique asymmetric key pair into it and issue an Endorsement Certificate , a signed document that says "this key lives inside genuine hardware that we manufactured." The certificate chains back to the manufacturer's root CA. You verify it the same way you'd verify a TLS certificate. The private half of the EK never leaves the chip. But here's the subtle part: the EK is a decryption-only key, not a signing key. This is deliberate. If the EK could sign arbitrary data, it would be a perfect tracking device. Every signature would fingerprint the physical chip. So the spec restricts the EK to decryption only. You can encrypt something to a specific TPM, but that TPM can't use its EK to sign a message back. This constraint is what makes the AK necessary. Attestation Key (AK) A key you generate yourself, inside the TPM, under the EK's hierarchy. Unlike the EK, the AK is a signing key — this is what actually signs challenges, quotes, and attestation evidence. Why not just use the EK for everything? Privacy. The EK uniquely identifies the physical chip. If every service you attest to sees the same key, they can collude and track the hardware across contexts. The AK breaks that link. You can create multiple AKs — one per service, one per use case — each unlinkable to each other and to the EK from the outside. The only way to prove an AK belongs to a specific EK is through the credential activation protocol, which requires cooperation from the TPM itself. So now the interesting question: how do you prove to a remote control plane that a given AK actually lives on a genuine TPM, and specifically the same chip as an enrolled EK? Credential Activation This is the credential activation protoc...