Endorsement Key (EK)

What an Endorsement Key is

The Endorsement Key (EK) is the cryptographic root of a TPM's identity. Every TPM 2.0 chip is provisioned by its manufacturer with an EK — typically an RSA-2048 or ECC-P256 key — whose private half is generated and stored inside the chip and never leaves it. The public half is signed into an X.509 certificate by the TPM manufacturer's certificate authority and stored in a well-known NV index on the chip (0x01C00002 for RSA, 0x01C0000A for ECC).

That EK certificate is the single most important artifact for trusting a TPM. It says, in effect: "The vendor certifies that a TPM they manufactured holds this specific EK." Chain-verify it to a manufacturer root you trust (Intel, Infineon, ST, Nuvoton, AMD, IBM, Microsoft), and you have hardware-anchored identity for the device.

The EK is deliberately restricted:

• It is generated inside the TPM by the manufacturer during provisioning.
• Its private key can never be exported.
• It cannot be used to sign arbitrary data — only for very specific TPM protocol operations, primarily Credential Activation.
• Only one EK exists per hierarchy at a time; wiping and regenerating one is a significant operation.

Why the EK is not the signing key

A common source of confusion: given that every TPM ships with a certified EK, why not just use it directly to sign quotes and CSRs?

Two reasons — one privacy, one architectural:

1. Privacy. The EK is a unique, permanent identifier for the specific TPM. Using it directly for every operation would let anyone correlate all activity by that device across services. The TCG designed the architecture explicitly to prevent this by requiring a separate Attestation Key (AK) for signing.
2. Usage restrictions. TPM 2.0 policy attributes on the EK (restricted, decrypt, no sign) mean the chip will refuse to use it for general signing. It exists to certify other keys, not to be one.

Instead, the device generates one or more AKs. Each AK is bound to the EK through a one-time protocol called Credential Activation. After that, the AK is what signs quotes; the EK just proves the AK belongs to a real TPM.

How the EK gets used: Credential Activation

The protocol has two round trips:

1. Challenge. The verifier receives the device's EK certificate and the public area of the new AK. It parses the EK certificate, chain-verifies it to a trusted manufacturer root, decodes the AK public area to derive the AK's canonical Name (a SHA-256 hash of the public structure), generates a random secret, and calls the TCG-standard credactivation.Generate function. The output is a credential blob wrapped so that only the holder of the EK private key can unwrap it — with the wrapped secret itself HMACed with a key derived from the AK Name.
2. Response. The device executes TPM2_ActivateCredential with its EK and AK handles, which forces the TPM to prove it holds both keys (the EK to unwrap the blob, the AK to derive the HMAC key). If both hold, the TPM returns the plaintext secret. The device sends the recovered secret back to the verifier, which compares its hash to the stored value. Match → the AK is now bound to the EK.

The elegance is that there is no way to fake this externally. Only a TPM holding both the exact EK the manufacturer certified and the exact AK whose Name went into MakeCredential can recover the secret. An attacker with just the EK cert (which is public) cannot pass the challenge.

What problem the EK solves

Without an EK, you have to bootstrap device identity from scratch — pre-shared keys, manufacturing enrolment servers, or "trust on first use" that quietly ships every deployment. Every one of those approaches has failure modes at scale: PSKs get leaked, enrolment servers get impersonated, TOFU accepts whatever shows up first.

An EK anchors identity to something the attacker cannot forge without compromising the manufacturer. If you trust Intel to only put valid EKs into real Intel PTT chips, and you can chain-verify a device's EK to Intel's root, you have inherited Intel's identity guarantees for free.

The manufacturer trust store

To verify EK certificates you need the corresponding manufacturer root CAs. TPM vendors distribute these under their own licences, which is why platforms like TigerTrust do not vendor them in the shipping code — operators download them once at install time:

TigerTrust's verifier reads any *.pem, *.crt, or *.cer file from a configured directory (ek_trust_bundle_dir) at startup. If the directory is empty, chain verification is skipped with a warning — dev-friendly, but production deployments should always populate it.

Common misconceptions

"The EK signs my TLS traffic." It does not. The EK signs the credential activation response only. Signing keys (for TLS, for CSRs) are separate objects created under the EK's hierarchy and certified by an AK.

"Every TPM has an EK certificate." Most do. Some older or specialty TPMs ship without one, expecting the operator to run a manufacturer enrolment protocol at first use. TigerTrust's verifier can be configured to allow EK-cert-less devices in policy mode skip — but the resulting attestation loses the "which manufacturer certified this chip" guarantee.

"EK certificates never expire." Manufacturer EK CAs do have expiry, though timelines are decades not years. Plan for CA rotation like you would for any long-lived trust anchor.

"Two devices with the same EK is a security problem." It cannot happen with correctly manufactured TPMs — each EK is generated inside its chip. If you see it, you have a counterfeit TPM or a bug in your parsing.

"I can use the EK to identify a device forever." You can, but doing so re-introduces the privacy problem the TCG designed around. Prefer using AKs for identity and EK only for enrolment.

How TigerTrust uses the EK

TigerTrust's enrolment verifier lives in services/pki-core/internal/attestation/enrollment.go. During first-time device enrolment it parses the presented EK certificate, chain-verifies it against the configured manufacturer trust store, extracts the manufacturer name for policy filtering (allowedEkManufacturers), runs the Credential Activation challenge/response, and — on success — persists the enrolled AK's Name alongside the EK cert for all future attestations to look up. The full protocol and file references are in the TPM_ATTESTATION design doc §3.1 and §5.

Related reading

• TCG TPM 2.0 Library Specification, Part 1 — EK hierarchy and template definitions.
• github.com/google/go-tpm-tools credactivation package — reference implementation of the challenge generator.