Very interested in ActivateCredential documentation about go-attestation HOT 7 OPEN

Hey Tom (@twitchy-jsonp)

Thank you very much! I read the page 109 of "A Practical Guide to TPM 2.0" following your comments, and everything became clear :)

There is one thing I still find confusing...
Wouldn't it possible for an attacker to load an external owned AK into TPM? Thus, the attacker would influence the creation of credential using the name of this external AK, which could be used in the activate credential operation to discover the challenge and get credential for an external AK.

Maybe this is resolved by looking the properties of the AK (fixedTpm, signOnly, ...) that was send to attestor, but I still don't know how I would check its integrity.

By the way, thanks for your help :)

from go-attestation.

It would be possible to import an AK into the TPM, but as you have identified, this will be revealed by the properties of the AK. This is exactly what go-attestation checks when performing activation, and will return an error if the AK has bad properties:

Section 23.6 of the architecture spec states that the combination of fixedTPM and fixedParent means:

This combination indicates an object that was created on a specific TPM and no duplicate of the object is
possible.

Where duplicate is a reference to TPM2_Duplicate(), which exports a key.

Because the name (the digest of important stuff, including key properties like fixedTPM) of the AK is part of the computation of the challenge key included in the activation blob, lying about the properties of the AK to the remote end would result in an activation blob the TPM would not be able to decrypt.

from go-attestation.

I wrote up some notes on the TPM key hierarchy including credential activation and certification. Hope this helps a little https://ericchiang.github.io/post/tpm-keys/

from go-attestation.

Hi!

I haven't gotten around to writing that section yet, but the next best thing is the code here.

Formally, its documented in the 'Architecture' PDF of the TPM 2.0 specification. I've found it helpful to think about the process in terms of three parts:

• Asymmetric encryption of the 'seed' key using the EK
• Symmetric encryption of the secret, using a key derived from the AIK digest + the seed
• Integrity HMAC that wraps the encryption above.

I'm happy to answer any questions you have :) I got stuck a lot when implementing this, and it took a solid week to get anything working at all.

from go-attestation.

Oh, looks like I wrote it but never got the PR over the line!

You can read it here: https://github.com/google/go-attestation/pull/97/files

from go-attestation.

Hi @twitchy-jsonp

I read your MD, the TPM 2.0 book, and some other references (your code), but it's not 100% clear to me why only the public part of the EK and AK name is enough for make credential operation. I mean... I know that the EK is used to encrypt a random nonce, which is the challenge, but how the AK name is used in this process.

When this challenge (credential) gets to the VM with TPM, i.e., VM being attested, I use the handle of AK public key for the activate credential operation... How is the AK used in the activate credential operation? What is the role of the AK in the activate credential operation?

This text summarizes my main concern and question: "how do I check the AK is bound to a given EK?"

Best regards :)

from go-attestation.

I know that the EK is used to encrypt a random nonce, which is the challenge, but how the AK name is used in this process.

Almost - the EK encrypts a random nonce, the seed. This encrypted seed is included alongside the rest of the data generated by the server. The seed is not the challenge. This is just an input to the key derivation function, who's output is used to encrypt the challenge.

This step can be thought of as entirely separate to the rest of the flow. The EK public is used to encrypt the seed, and you need all the inputs to the key derivation function to get the correct key to decrypt the challenge.

This is where the AK name comes in. The AK name is another input to the key derivation function. If it doesnt match on client + server, you wont get the correct key and hence wont decrypt the challenge. Ultimately, you need both the seed and AK name to generate the right key, you can only get the seed by decrypting using the EK, and the TPM will use the AK you provide to compute the AK name. As a result, a successful activate credential operation proves control of the EK, and that the same TPM has control of the AK.

from go-attestation.