The Endorsement Key (EK), the Public part, is available directly on the TPM chip, I know that you can generate an AIK key and then sign with that key, the hash must be generated by the TPM.

The idea is to execute remote attestation with the following artifacts:

  • Endorsment Key (EK)
  • AIK public Key
  • Some nonce sent in order to be signed by the private Key from the AIK

1 Answer 1


In short, no. But, that doesn't mean that asking the TPM to use the EK is difficult -- definitely no more difficult than asking for a quote (the primary part of an attestation).

First, a nitpick: the AIK (attestation identity key) is a key type of the TPM 1.2 (and before). The TPM 2.0 has a similar key type called an AK (attestation key). Though these keys have similar roles, they are not the same. AIKs can only sign a few (3) different structures. AKs will sign anything that was hashed by the TPM, however the TPM will not hash any data that starts with a magic number, such as a quote. This is how TPM 2.0 ensures that the AK cannot be used to sign a fake quote. TPMs can have non-AK signing keys that could sign a fake quote, however.

A quote is just a chunk of data which comes with a signature. If you fully trust a client to send attestation data without a TPM, then you wouldn't have a reason to use a TPM. If you are going to use a TPM, then you want to know that they signature over the quote actually came from a real TPM. Having a signature from an AK is a good way to know trust the quote (because of that hash/magic number thing), but you need to have some sort of proof that the signing key is actually an AK. To do that, you need a way to bind the signing key back to something that only a real TPM can have: an EK certificate signed by the manufacturer of that TPM.

The EK is not a signing key, and so it will never produce a signature. To bind an AK to an EK involves a process that is covered under two processes: MakeCredential and ActivateCredential. MakeCredential can be done by a TPM, but does not have to be. This requires an EK certificate for the TPM in question, and the "name" of the AK. After validating that the EK certificate is valid, you will use the name in a complex process to encrypt a challenge with the public EK. Then you send that data back to the TPM, have it perform ActivateCredential, and if everything is right, return the challenge to you for comparison. Only when you verify that the challenge returned matches the one sent inside the encrypted package can you trust that the key that signed the quote is a real AK, and that the quote is real.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .