What Is Attestation?
Attestation is the process of providing cryptographic proof that a piece of hardware is genuine and that cryptographic keys are actually protected by that hardware. It answers a fundamental question in security: How do I know this key is really inside a TPM or a YubiKey, and not just software pretending to be one?
When a server claims it has a TPM 2.0 chip protecting your signing keys, you have no reason to simply trust that claim. The server could be compromised. The TPM could be emulated in software. Someone could have replaced the real TPM responses with fake ones. Attestation solves this by creating a chain of cryptographic evidence that traces back to a known hardware manufacturer — proof that no software can forge.
There are two distinct forms of hardware attestation relevant to TPM HSM: TPM remote attestation, which proves a server has a genuine TPM chip and reports its system state, and YubiKey key attestation, which proves a specific cryptographic key was generated inside a genuine YubiKey device.
The core idea: Attestation shifts trust from “the server says it has a TPM” to “the TPM manufacturer cryptographically vouches for this specific chip, and I can verify the certificate chain myself.” It is the difference between a claim and a proof.
Why Attestation Matters
Without attestation, every interaction with remote hardware is built on blind trust. You connect to a server, it says it has a TPM, and you import your private keys into it. But what if the server is lying? What if the “TPM” is actually a software simulator that logs every key it receives?
Attestation eliminates this class of attack. Here are the real-world scenarios where it is essential:
- Onboarding a new server: Before importing any keys, you need to verify that the remote machine actually has a genuine TPM — not a software emulator. Attestation provides this proof before you trust the server with any secrets.
- Remote key management: When managing HSM keys across multiple servers, attestation lets you verify that each key is genuinely hardware-bound, even when you have no physical access to the machines.
- Compliance and auditing: Regulations like PCI DSS, SOC 2, and eIDAS require proof that cryptographic keys are stored in hardware. Attestation provides the cryptographic evidence auditors need — not just a configuration screenshot, but a verifiable certificate chain from a known manufacturer.
- Zero trust architecture: Machine identity must be rooted in hardware. Attestation proves that a machine is what it claims to be, with keys bound to a specific physical chip that has a verifiable identity from the manufacturer.
TPM Remote Attestation — How It Works
TPM remote attestation is a multi-step challenge-response protocol that proves three things: the TPM is genuine hardware from a known manufacturer, a specific Attestation Key (AK) lives on that TPM, and the system’s boot state matches expectations. Here is exactly how TPM HSM implements it, based on the actual attestation code.
Step 1: Get the TPM’s Identity
The client calls GetEKInfo on the server. The server returns three pieces of data: the Endorsement Key (EK) public key, the EK certificate (a DER-encoded X.509 certificate issued by the TPM manufacturer during production), and the Attestation Key (AK) public key.
The EK is the TPM’s permanent identity — it is burned into the chip during manufacturing and never changes. The EK certificate is essentially the TPM’s “birth certificate,” signed by the manufacturer. The AK is a restricted signing key created on the TPM specifically for attestation purposes.
Step 2: Verify the EK Certificate Chain
The client verifies the EK certificate against known TPM manufacturer root CA certificates. TPM HSM ships with root CAs for Intel, Infineon, STMicroelectronics, Nuvoton, and AMD. The client identifies the manufacturer from the certificate issuer, fetches any intermediate CA from the certificate’s Authority Information Access (AIA) extension if needed, and verifies the full chain: EK cert → intermediate CA → manufacturer root CA.
This step proves the TPM chip is genuine hardware from a real manufacturer. A software TPM emulator cannot produce an EK certificate signed by Intel or Infineon’s root CA.
Step 3: MakeCredential — The Challenge
The client generates a random 32-byte secret and runs MakeCredential entirely client-side. This operation encrypts the secret to the EK’s RSA public key using RSA-OAEP (with the label IDENTITY), bound to the AK’s cryptographic Name. The binding is critical: it uses KDFa to derive an AES-128 key from the seed, encrypts the secret with AES-CFB, and computes an HMAC over the encrypted secret concatenated with the AK Name.
The result is a credential blob and an encrypted seed. Only the real TPM can decrypt this because only it holds the EK private key. And because the secret is bound to the AK’s Name, the TPM will only release it if the AK is actually loaded on the same TPM as the EK.
Step 4: ActivateCredential — The Proof
The client sends the credential blob and encrypted seed to the server, which passes them to the TPM’s ActivateCredential command. Inside the TPM silicon, the chip decrypts the seed using its EK private key, re-derives the AES and HMAC keys, verifies the HMAC against the loaded AK’s Name, and decrypts the secret. The server returns the recovered secret to the client.
If the recovered secret matches what the client originally generated, this proves co-residency: the AK lives on the same physical TPM chip as the EK. No software can fake this because the EK private key never leaves the TPM.
Step 5: PCR Quote
Simultaneously with ActivateCredential, the server produces a PCR quote — a snapshot of Platform Configuration Registers (PCRs 0, 1, 2, 3, 7) signed by the now-verified AK. The client provides a random nonce as qualifying data to ensure freshness.
PCRs record cryptographic measurements of the system’s boot chain: BIOS firmware (PCR 0), BIOS configuration (PCR 1), option ROMs (PCR 2), bootloader (PCR 3), and Secure Boot policy (PCR 7). These values cannot be reset or forged — they can only be extended with new measurements.
Step 6: Verify the Quote
The client verifies the quote signature using the AK’s RSA public key (RSASSA-PKCS1-v1_5 with SHA-256), confirms the nonce in the quote data matches the one it sent (preventing replay attacks), and inspects the PCR values to confirm the system booted the expected software.
Client (Desktop) Server (TPM)
| |
| 1. GetEKInfo() |
|--------------------------------------------->|
| |
| EK public + EK certificate + AK public |
|<---------------------------------------------|
| |
| 2. Verify EK cert chain |
| (Intel/Infineon/STMicro/Nuvoton/AMD) |
| |
| 3. MakeCredential(EK, AK Name, secret) |
| [client-side, pure crypto] |
| |
| credential_blob + encrypted_seed + nonce |
|--------------------------------------------->|
| |
| 4. TPM: ActivateCredential
| (proves AK + EK co-residency)
| 5. TPM: PCR Quote signed by AK
| (PCRs 0,1,2,3,7 + nonce)
| |
| recovered_secret + quote_data + signature |
|<---------------------------------------------|
| |
| 6. Verify: secret match? |
| Verify: quote signature valid? |
| Verify: nonce fresh? |
| Inspect: PCR values expected? |
| |
What TPM Attestation Proves
After successful TPM attestation, you have cryptographic proof that:
- The TPM is genuine hardware — the EK certificate is signed by a known manufacturer (Intel, Infineon, STMicro, Nuvoton, or AMD), not a software emulator.
- The TPM is from a specific manufacturer — you know the exact chip vendor and can verify independently against their published root CAs.
- The Attestation Key lives on the same TPM as the Endorsement Key — the ActivateCredential co-residency proof ensures the AK is not on a different device or in software.
- The system’s boot state matches expectations — PCR values prove the firmware, bootloader, and OS components are the ones you trust.
- The attestation is fresh — the nonce in the PCR quote proves this is not a replay of a previous valid attestation.
YubiKey Key Attestation — How It Works
YubiKey attestation solves a different but equally important problem: proving that a specific cryptographic key was generated inside a genuine YubiKey and has never existed outside of it. This is critical when registering a YubiKey as a trusted signer in TPM HSM — you need to know the key is hardware-bound and cannot be cloned.
Step 1: Generate the Attestation Certificate
The client calls attest_key(SLOT.SIGNATURE) on the YubiKey’s PIV applet. This commands the YubiKey to generate an attestation certificate for the key in slot 9c (the Digital Signature slot). This certificate contains the public key from slot 9c and is signed by the YubiKey’s internal intermediate CA.
Crucially, this attestation only works for keys that were generated on-device. If a key was imported into the YubiKey from software, the attest command will fail. This is the fundamental guarantee: attestation proves the key was born inside the YubiKey.
Step 2: Read the Intermediate CA
The client reads the certificate from slot f9 (the Attestation slot). This is an intermediate CA certificate that was pre-loaded by Yubico during manufacturing — it is unique to each YubiKey and serves as the device’s “birth certificate.” This intermediate is signed by Yubico’s PIV Root CA.
Step 3: Verify the Certificate Chain
The client verifies a three-level chain: the attestation certificate (from step 1) must be signed by the intermediate CA (from slot f9), and the intermediate must be signed by the Yubico PIV Root CA (a well-known public certificate published by Yubico). TPM HSM bundles the Yubico PIV Root CA and performs both signature verifications locally.
The verification supports both RSA and ECC keys — RSA signatures are verified with PKCS1v15, ECC with ECDSA. If either signature check fails, the attestation is rejected.
Step 4: Extract Metadata from Attestation OIDs
The attestation certificate contains Yubico-specific X.509 extensions encoded as custom OIDs. TPM HSM extracts:
- YubiKey serial number (OID 1.3.6.1.4.1.41482.3.7) — uniquely identifies the physical device
- Firmware version (OID 1.3.6.1.4.1.41482.3.3) — confirms the YubiKey’s software version
- PIN policy (OID 1.3.6.1.4.1.41482.3.8) — whether a PIN is required (never, once per session, or every operation)
- Touch policy (OID 1.3.6.1.4.1.41482.3.9) — whether physical touch is required (never, always, or cached for 15 seconds)
These policies are hardware-enforced. If the attestation certificate says touch is required for every signature, no software can bypass that requirement. The YubiKey enforces it at the silicon level.
What YubiKey Attestation Proves
After successful YubiKey attestation, you have cryptographic proof that:
- The key was generated inside the YubiKey — it was never imported from software and has never existed outside the device. It cannot be cloned or extracted.
- The YubiKey is genuine Yubico hardware — the intermediate CA in slot f9 traces back to Yubico’s published PIV Root CA.
- The specific device is identified — the serial number and firmware version are cryptographically bound to the attestation.
- PIN and touch policies are hardware-enforced — the policies reported in the attestation certificate are enforced by the YubiKey’s firmware and cannot be overridden by software.
Why This Matters for TPM HSM Users
TPM attestation and YubiKey attestation are not abstract security concepts — they solve concrete problems that TPM HSM users face every day.
When you connect to a TPM HSM server for the first time, attestation tells you the TPM is genuine before you import any keys. Without this step, you could be importing your private signing key into a software emulator that logs everything. Attestation eliminates that risk by verifying the EK certificate chain against the manufacturer’s root CA and running the MakeCredential/ActivateCredential challenge.
When someone registers a YubiKey as a trusted signer, attestation proves the key was generated on-device and cannot be cloned. This is essential for the PKI trust model: you need to know that the authorization key is genuinely hardware-bound, not a software key that someone could copy.
Together, they create end-to-end hardware trust. You know the signing key is in a real TPM (via TPM attestation) and the authorization key is on a real YubiKey (via YubiKey attestation). The signing policy is hardware-enforced on both ends — the TPM will not sign without a valid YubiKey signature, and the YubiKey will not sign without physical touch and PIN entry.
For CI/CD code signing, attestation lets you verify the build server’s TPM before importing your signing key. You get cryptographic proof that your key is going into genuine hardware, not a compromised environment.
For compliance, attestation provides the cryptographic evidence auditors require. You can present the EK certificate chain, the MakeCredential/ActivateCredential exchange results, the PCR quote, and the YubiKey attestation chain — all verifiable by any third party with access to the manufacturer root CAs.
Attestation vs. Other Trust Models
Not all trust models are equal. Here is how hardware attestation compares to the alternatives:
| Trust Model | What It Proves | Hardware Guarantee | Key Origin Proof |
|---|---|---|---|
| Self-attestation (“just trust me”) | Nothing — the server claims it has a TPM | ✕ | ✕ |
| Certificate-based (HTTPS/TLS) | Server identity via CA-signed certificate | ✕ | ✕ |
| Software attestation | Software version / configuration hash | ✕ | ✕ |
| TPM remote attestation | Genuine TPM chip + system boot state | ✓ | ✓ |
| YubiKey key attestation | Key generated on genuine Yubico device | ✓ | ✓ |
TLS certificates prove that a server is who it claims to be, but they say nothing about whether the server’s keys are in hardware or software. Software attestation (like a hash of a binary) proves what code is running, but any software can be emulated. Only hardware attestation provides proof rooted in physical silicon, with certificate chains tracing back to chip manufacturers. It is the strongest foundation for trust because it cannot be faked by software alone.