Security Working Group meeting - Wednesday August 31 - results

[George Almasi]

On 9/9/22 3:53 AM, Michael Richardson wrote:
> Thank you for the post.
> I'm interested in understanding how you will do provisioning of the TPM keys.
Hi Michael. I'm going to describe the standard keylime agent 
registration process in a bit more detail -- but not too much, or this 
will be a very long post indeed.

1. EK certificate.

What this is for: The EK certificate on each TPM is verifiable against 
the root CA of the manufacturer, which gives us confidence that the TPM 
is the genuine article and not a counterfeit.

Keylime makes the assumption that the TPM device's EK certificate is 
available on the device. While the
EK certificate can be deleted from the TPM by the end user, devices 
[ought to] ship with it from the TPM manufacturer.

It is possible to use self-signed EK certificates for TPM devices. But 
that weakens the chain of trust provided by keylime, since it involves 
you -- the creator of said certs -- in the process, instead of using the 
likes of Infineon or Nuvoton for the purpose. We think it is *always* 
better to use the manufacturer's key if it is available, rather than 
create our own keys and headaches. Keylime comes with a pre-populated 
list of manufacturer certificates it will accept, and said list includes 
the most widely used manufacturers of TPM devices. FWIW our AST2600 EVBs 
have Nuvoton devices, whereas my Raspberry Pi has an Infineon Optiga :)

2. Public EK (endorsement key)

What this is for: This key defines the identity of the TPM device, and 
is used as such by keylime. It is signed by the EK certificate. To some 
degree of approximation this key pair is "burned into the device" -- not 
literally true, but can be re-generated at will from seeds that *are* 
burned into the device.


The keylime agent usually (re)generates the EK and sends the public part 
(the only part available to anyone outside the device) to the keylime 
registrar, together with the EK certificate. The registrar can then make 
a decision about whether the keylime agent has a genuine TPM device in 
possession, and whether the message coming from network address X and 
hostname Y really corresponds to the correct EK. This guards against say 
spoofing an entire node with keylime.


3. AK (attestation key)

What this is for: the attestation key is the key pair the TPM device 
will use for signing its reports ("quotes") when asked to do so by the 
keylime agent.

The attestation key is established and authenticated cooperatively 
between the TPM device, the keylime agent and the keylime registrar 
using a very careful choreography. The keylime agent must guard against 
someone spoofing the registrar (we use a pre-established server TLS cert 
for this purpose, much like your browser does when it decides to trust 
e.g. ibm.com). The keylime registrar decides whether to trust the 
keylime agent sending it the EK pubkey and certificate as described above.

I will not describe the roundtrip process to establish and activate the 
attestation key.

But *once this roundtrip is complete*, the TPM is "tied" to the keylime 
registrar and will be able to respond to quote requests in a manner that 
is not susceptible to MitM attacks ... which is the goal of the exercise.

That's it. There are additional keys used by keylime for the purpose of 
establishing direct connection between the agent and third parties 
(called "tenants"), but those keys do not involve the TPM device so I'm 
not going to describe them here.


-- George