What does it mean to "certify a key"

Question

I'm going through a TPM tutorial at https://google.github.io/tpm-js/#pg_keys It says:

Hierarchies differ by when their seeds are created and by who certifies their primary keys.

and

Generally speaking, the endorsement hierarchy is reserved for objects created and certified by the TPM manufacturer.

What does it mean to "certify a key" in this context? My understanding is that the hierarchies in TPM are like a storage space, where various secrets may be stored. So, here's how I imagine a hierarchy (could be endorsement hierarchy, as mentioned by the quote):

ENDORSEMENT HIERARCHY:

• SEED (a string of bytes)
• PRIMARY KEY (a string of bytes generated from the SEED)

So, I believe both SEED and PRIMARY KEY are just some strings, although I am not sure exactly what they are (symmetric keys?). How are they certified? Does it have any relation with the X.509 certificates? Does it imply that each object in the hierarchy not only includes the actual secret (a string of bytes), but also some kind of signature?

Answer 1

First of all, (primary) keys do not need to be certified.

I am not sure exactly what they are (symmetric keys?)

The seed is secret random data. The seed and a template (some more data, usually the default template is used) will be thrown at a key derivation function. The output is the primary key, an asymmetric key (e.g. RSA or EC).

The primary key can only wrap (i.e. encrypt) other keys. That is to protect their confidentiality. It cannot sign arbitrary data.

Does it imply that each object in the hierarchy not only includes the actual secret (a string of bytes), but also some kind of signature?

Not really. In general, a key is not certified. However, a key is always wrapped by its parent key. The only exceptions are primary keys, where there is no parent.

What does it mean to "certify a key" in this context?

You can do attestation. That is, you can create certificates with specific guarantees. But you have to do that "manually" after key creation. Note however, that not only you can do attestation for your TPM, but also your TPM manufacturer and your platform manufacturer.

Hierarchies differ by when their seeds are created and by who certifies their primary keys.

That statement tries to justify why there are different hierarchies (as opposed to a single one). For example, the endorsement hierarchy is used for manufacturer guarantees. Usually, the manufacturer generates an endorsement certificate for you which you can find in your TPM's NV memory (e.g. at index 0x01c0000a). This endorsement certificate certifies that your TPM is a genuine hardware TPM by that specific manufacturer.

For more information about this (most commonly used) type of attestation, see https://security.stackexchange.com/a/235391/168229.

Similarly, the platform manufacturer (e.g. the manufacturer of your PC or laptop) can attest to platform properties in a platform certificate, related to the platform hierarchy.

Lastly, there is the owner hierarchy (previously storage hierarchy). Technically, you could even setup your own off-TPM CA and certify your own keys, if you wanted. If you have no use case for that you don't have to worry about that too much.