How to bind TPM2.0 AK to the "AK name" used in tpm2_makecredential, and how is trust established in AIK?

Question

During remote attestation, a device sends the server the EK certificate, AK public, AK name. By using tpm2_makecredential/tpm2_activatecredential, the attestation sever can confirm that:

1. the EK is resident in the device TPM, and
2. the AK that the "AK name" used in tpm2_makecredential referring to is resident in the device TPM. But how does the server know if the AK public and the AK name refer to the same key?

Here are more details:

I am trying to figure out a remote attestation algorithm/protocol to verify the PCR values on a device. I've read some examples on how to do this. It always involves using tpm2_makecredential / tpm2_activatecredential to validate the identity of a TPM. Below are the steps:

1. Device sends Endorsement Key (EK) certificate, Attestation public key (AK public), AK name (i.e., digest of Ak public area incluidng Ak public key and other attributes) to attestation server.
2. Server verifies EK certificate, extract EK public key.
3. Server encrypts a secret along with AK name using EK public key and sends the resulting blob to the device.
4. Device calls TPM to decrypt the blob to recover the secret. This operation will fail if TPM doesn't have a key with the "AK name". Device sends the secret back to the server.

If the device recovers the secret correctly, it approves the followings:

1. The EK certificate is from a trusted TPM.
2. The same TPM has an AK that the device has provided its name to the server.

The next steps are: 5. Device sends a PCR quote to the server. 6. Server verifies the quote to be genuine using the AK public key. 7. Server compares the PCR quote against a reference PCR quote.

My question is: how does the server trust the AK public key provided by the device? Unless the server can independently compute the NAME from AK public key and other attributes to match the provided "AK name", but how to compute? Or if device can provide more info to prove that the AK is genuine, but what other info?

Answer 1

The binding of the AIK name and the AIK public is done during the AIK generation itself. The client generally computes the AIK name by calculating the sha256 hash of the AIK public part (which can also include other parameters such as platform-specific details) and then sends the AIK name along with the public part to the server for further verification during the challenge/response mechanism (again, this can include more parameters as well)

The work of the server is not to verify the AIK name and public part directly. But it verifies that the platform's identity and integrity can be trusted. AIK is just one part of it.

EDIT: But how does the trust in AIK is established further?

In most cases, the server will have an external or internal CA that will sign the AIK certificate (Generated and sent during the tpm2_certify command stage). The signing of the AIK certificate with CA is done after TPM proves that AIK is bound to TPM (Wrap AIK with EK pub and send to TPM). Once verification is done, CA will sign the AIK with its private key. Further operations related to PCR signing can now be verified by CA using chain verification.

But again, it depends on the type of attestation. In some cases, trust is pre-established and no CA is required. DAA (Direct Anonymous attestation) is also an example.

Answer 2

I had this exact same question. We can establish that the "AK name" is bound to the same TPM that owns the EK Certificate. However, in a subsequent step when trying to create a certificate with the Public Key of AK (AK Certificate), the public key is passed in pem or der format. How do you establish that the Public Key is the same key represented by ak name?

When calling tpm2_createak, you can specify the format of the public key (pem, der, tss (default) and tpmt).

If you output the tpmt format, you can do sha256sum of the exported public key in tpmt format and this matches the the ak_name.

The weird thing is that when you create public key and you specify different output format, the ak names are different.

I thought when using tpm2_createak - the rsa keypair and therefore the public key is always the same.. so I am not sure why the ak_name changes for the different format of the public key.

I really am looking for a way to convert a tpmt formatted key to pem/der format. This way, I can verify the ak_name with the given AK public key.

Answer 3

Unless the server can independently compute the NAME from AK public key and other attributes to match the provided "AK name", but how to compute?

The "name" of a TPM Object can be calculated independently. It's the hash of the public area of the Object with the hashing algorithm in the form of its TCG Algorithm ID prepended. If you want the details of what's contained within it, it's TPMT_PUBLIC which is defined in Part 2 of the TCG TPM spec. This structure includes the Object attributes and parameters as well as the public portion of the key (when the Object is a key).

This TCG Infrastructure Workgroup ID/Attestation specification may be of interest as it defines an Attestation protocol that can be used to extend trust from the TPM to the rest of the system. Section 6.1.2 has similar steps to what you describe.

Or if device can provide more info to prove that the AK is genuine, but what other info?

The ID/Attestation specification provides and example of this data in Section 6.1.2, Step 6. In this case, you would be acting as the Platform Software, Device Software, and Certificate Authority (CA). It uses the procedure described in Section 24 of Part 1 of the TCG TPM spec. The extra information provided is the nonce generated by you. If the nonce received as part of the TPM2_ActivateCredential command matches the nonce you provided, then you know that the Endorsement Key related to the Endorsement Key Certificate you gathered is actually on the TPM. If the key weren't on the TPM, the TPM wouldn't be able to return the correctly decrypted credential blob which includes your nonce.

The beginning of Section 6.1.2 tells you what security guarantees you get if you complete the procedure:

A. A TPM is authentic (by validating the EK certificate).

B. This specific TPM is authentic and is represented by the EK certificate (the EK private key resident in this TPM corresponds to the public key in this EK certificate.)

C. This AK is authentic (the AK is resident in the same TPM as the EK private key corresponding to the public key in this EK certificate.)

If the EK certificate doesn't validate, then don't trust that the TPM is geniune.

If the returned nonce doesn't match the nonce you gave, then you have no guarantee that the private portion of the EK is resident in the TPM. There's no Proof of Possession that the TPM has the EK.

If the ActivateCredential operation doesn't return a certInfo structure (decrypted credential blob) at all and you get an error instead, then the TPM is telling you that the AK (the credentialed object) is either not resident on the TPM or that the properties of the object on the TPM don't match those passed implicitly via the inclusion of the Name of the object in the MakeCredential operation. You can look at the details of the errors returned by TPM2_ActivateCredential in Part 3 of the TCG TPM spec to determine which step failed.