How to ensure that keys are created inside TPM?

Question

I need to

• run .exe on client machine, which will create key pair within TPM.
• And then I will create CSR with public key part of key pair generated by TPM.

My concerns are how do i ensure that keys are created inside TPM , and not by spoofed TPM. Which would enable private key to be migrated and copied.

I heard that is what AIKs are for , but i don't understand how can this prevent TPM for being spoofed?

One solution that i can think of is : I go to client, boot from USB with trusted OS, and then obtain EKpub.

However

TPM 1.2 or TPM 2.0? – Tarnation

In the meantime i found out that EKpub should be signed with vendor public key, still searching if i can get EKpub hash from vendor. This should in theory prove that i'm talking with genuinie TPM – However

That proves that the EKpub was signed by the manufacturer, but it does not prove that the chip you're talking to has access to the corresponding EKpriv. It also doesn't prove that the key you created belongs to the TPM and not a spoofing entity. One way to do both of these things at once is with a process called credential activation, which is different based on the TPM version. Also, your idea about booting from USB does not help if you have concerns about a spoofed TPM. – Tarnation

Yea, but maybe i can encrypt message to TPM with signed EKpub that i trust, if i obtain hash from vendor. In that case only genuine TPM will able to decrypt it. But as i said im still researching. btw I'm talking about TPM 1.2. If genuine TPM creates keypair and it is signed by genuine TPM then i can check if it is legit. No? – However

I don't know what hash you're talking about. The only thing you need from the manufacturer is their CA keys, which you can download from their website if they're any good. And again, the thing that's signed by the manufacturer is the EKpub, not the key you just created, which is what you're trying to prevent from being spoofed in your question. Read my previous comment. – Tarnation

Are you saying that generated keypair will not be signed by EKpub from TPM? If they are signed, in that case i can verify that EKpub that signed keypair is signed by vendor in theory. But if i can't get hash of EKpub that means that i can't verify if I'm talking to specific machine. – However

No. The EK is not a signing key. And even if it was, simply getting it to sign something would not prove that the object belongs to the TPM. – Tarnation

Ok thanks , so activating credential is way to go? I will research that later. If you have some relevant links on activating credential at hand please do post it. – However

Answer 1

The process of proving that a key originates from a TPM is known as:

• For TPM 2.0: Credential activation, enforced with TPM2_ActivateCredential
• For TPM 1.2: Identity activation, enforced with TPM_ActivateIdentity

This technique accomplishes many things, but one of them is proving that the key generated after issuing a request to the TPM actually originates from a trusted TPM and was not spoofed. For TPM 1.2, since that's what the question is about, identity activation is an 8-step process that goes like this (what follows is an excerpt from TCG's AIK Certificate Enrollment):

• Step 1: Platform asks the TPM to create the AIK key pair.

  • (a) The platform (or application software on the platform) issues to the TSS the CollateIdentityRequest command. In turn the TSS issues the MakeIdentity command to the TPM. This results in the TPM generating a fresh AIK public key pair.
  • (b) Within the MakeIdentity function the TPM creates the IDENTITY_CONTENTS structure containing the following items: (i) The structure version, (ii) TPM command ordinal, (iii) PrivCADigest label and (iv) AIK_pub_key.
  • (c) The TPM signs IDENTITY_CONTENTS structure using the AIK_priv_key, with the resulting signature portion being referred to as the identityBinding.
  • (d) The TPM outputs two (2) items as a result of the MakeIdentity command: AIK_pub_key and the identityBinding.

• Step 2: TSS produces proof structure concerning the AIK

  • (a) Following from the previous step, the TSS creates the IDENTITY_PROOF structure. This structure consists of the following items: (i) The identityBinding structure from Step 1(d). (Note: The identityBinding structure is the signature portion only over the IDENTITY_CONTENTS structure). Note: It must be noted that the identityBinding structure is NOT cryptographic proof that the AIK is a TPM-resident key and that the AIK has been certified using the EK. It only demonstrates that some key pair exists. (ii) The TPM spec version (iii) The SubjectPublicKeyInfo (i.e. the AIK_pub_key) (iv) The IdentityLabel (v) EK certificate (vi) Platform certificate
  • (b) The TSS then generates a symmetric key K1 (local random number from the TPM) and encrypts the IDENTITY_PROOF structure using this symmetric key K1.
  • (c) The TSS then encrypts key K1 using the public key of the ACA. This encryption using public-key of the Attestation CA is intended to limit disclosure of K1 to the ACA only. The results of this step are two items: the encrypted IDENTITY_PROOF structure and the encrypted symmetric key K1. Encrypted IDENTITY_PROOF and encrypted K1 are bundled into an IDENTITY_REQ structure that includes identifiers for the symmetric and asymmetric algorithms used to encrypt the structures plus sizes of the encrypted structures.
• Step 3: Platform sends AIK certificate request to the ACA. The platform (or application software on the platform) takes the IDENTITY_REQ resulting from the previous step, encrypts it, and sends it to the ACA.
• Step 4: ACA verifies certificate request. Upon receiving the certificate request, the ACA must perform a number of verifications.
  • (a) To get access to the AIK certificate request structure, ACA must first decrypt the key K1 using its ACA private key.
  • (b) The ACA then uses K1 to decrypt the IDENTITY_PROOF structure.
  • (c) The ACA must then recreate the IDENTITY_CONTENTS structure and verify that the signature (as represented by the received identityBinding) is correct. The ACA can perform the verification because it now has the items listed in Step 2 above and can assemble the same PrivCADigestLabel as was provided to the TPM. As part of the verification, the ACA is expected to validate the received certificates (ie. EK and Platform Certificates). It is expected that the ACA will use standard X.509 certificate validation techniques, such as CRL checking [14] and/or querying the appropriate OCSP responders [15] to the issuer of the EK certificate (e.g. TPM manufacturer site).
• Step 5: ACA issues a new AIK certificate. The ACA then creates a new AIK certificate, using (as the public key) the received AIK public key in the previous step. The ACA issues (signs) the new AIK certificate using its own AIK signing key.
• Step 6: ACA encrypts the new AIK certificate. In this phase, the ACA must prepare the newly issued AIK certificate in a form recognizable by the TPM. As part of the TPM_ActivateIdentity command (Section 15.2 of [5]), the TPM expects input in the TPM_EK_BLOB or the (older spec version) ASYM_CA_CONTENTS structure. The ACA performs the following tasks:
  • (a) The ACA generates a random symmetric encryption key K2. This random K2 is unique for each AIK certificate request.
  • (b) The ACA encrypts the new AIK certificate using key K2.
  • (c) The ACA then creates either a TPM_EK_BLOB or ASYM_CA_CONTENTS (depending on the TPM version) structure which contains the following: (i) The hash of the AIK public key (namely the AIK public key as found in the original request). (ii) The symmetric key K2. (iii) Optional PCR information – for TPM_EK_BLOB only. The TPM checks to ensure that the TPM PCR’s and locality are in the correct state as anticipated by the ACA to unlock K2.
  • (d) The ACA encrypts the TPM_EK_BLOB or ASYM_CA_CONTENTS structure using the EK public key (as found in the EK certificate in the original request). The purpose of the last step is to ensure that only the same requesting TPM will be the sole entity that can decrypt the newly issued AIK certificate, since only that TPM possesses the EK private key (which is a TPM-resident key).
• Step 7: ACA delivers the new AIK certificate to the TPM on the Platform. The ACA then delivers the encrypted result (encrypted AIK certificate + either the blob or ASYM struct) to the requestor platform/TPM.
• Step 8: Decryption of new AIK certificate by the TPM. Upon receiving the (encrypted) AIK certificate from the ACA, the platform must input the structure (either the blob or ASYM struct) (into the TPM and activate it using the TSS Tspi_TPM_ActivateIdentity command. This command decrypts the (encrypted) symmetric key K2 from the ACA using the EK-private-key (which resides only in the TPM) after ensuring an AIK with a matching pub key resides in the TPM. It then uses the symmetric key K2 to decrypt the AIK certificate.

The crucial part here is the next-to-last sentence:

This command decrypts the (encrypted) symmetric key K2 from the ACA using the EK-private-key (which resides only in the TPM) after ensuring an AIK with a matching pub key resides in the TPM.

It is enforced by the spec that the EK will not decrypt the TPM_EK_BLOB object unless the private key that the activation is requested for is found within the TPM. And because the object was encrypted by the TSS without using the TPM secrets, and you have already verified the EK public key up the manufacturer's CA cert chain, it is ensured that the key that identity activation is requested for has originated within a TPM manufactured by a trusted entity.

Tarnation