Desktop version

Home arrow Computer Science arrow A Practical Guide to TPM 2.0


The TPM can of course act as a certificate authority. In fact, even before you consider unique TPM features such as PCR, authorization policies, audit, and hierarchies, it's valuable simply as a hardware key store. The private signing key is protected by the hardware and a wide range of authorization options, but it can be easily backed up. This widely available and very inexpensive part offers far better protection than a software key.

A third-party certificate authority can also sign a X.509 certificate for a TPM key.

For decryption keys, there is a complication due to a typical CA requirement for proof of possession. The certificate requestor must provide evidence to a CA that it possesses the private key. This is typically done by self signing the certificate signing request (CSR). [1]

For decryption keys, the TPM can't simply sign the CSR, because these keys are restricted to decryption and can't sign. The TPM has a workaround (see “Activating a Credential” in Chapter 9), but this requires a nonstandard CA.

Less obvious is that the TPM can certify data located on the device. The TPM offers several commands to support this feature.

TPM2_Certify asserts that an object with a Name is loaded on the TPM. Because the name cryptographically represents the object's public area, a relying party can be assured that the object has an associated private part. The Name also incorporates the key's attributes, including whether it's restricted, fixed to a parent or fixed to a TPM, and the authorization policy.

a signing key is used for attestation: for example, to quote (sign) a set of pCr values. the quote is far more useful if the relying party verifying the quote is assured that the signing key is restricted to the tpM, and therefore that the pCr values were actually on the tpM. the party first uses TPM2_Certify to get a certificate over the quote key's public area.

Naturally, the certifying key itself requires a certificate. eventually, a useful certificate chain leads back to a root. Chapter 19 explains how tpM key certificates are provisioned and how these chains can be validated back to a trusted root key.

a signing key is located deep in a key hierarchy. a relying party wants to be assured that all keys in the chain back to a primary key are suitably protected, that all encryption algorithms and key sizes are of sufficient strength. the party uses tpM2_Certify to get a certificate chain that cryptographically signs the public areas of all keys in the chain.

TPM2_Certify signs the entire public area, including a key's policy. This leads to other use cases.

a relying party wants assurance that only a restricted role can use a signing key, indicated by a signature with a particular authorizing key. It uses TPM2_Certify to certify a key. It then validates that the policy includes a TPM2_PolicySigned with the public key corresponding to that role.

In this case, the policy need not have a policyRef parameter. the digital signature is over the challenge but not over any additional information specific to the signer.

a relying party can validate that a signing key's policy includes a fingerprint authorization, indicated by a TPM2_PolicySigned with the fingerprint reader's public key and a policyRef parameter referring to a particular user identity.

this case is a variation of the previous case. the fingerprint reader signs not only the challenge but also a policyRef. the digital signature proves both possession of the private key and that the correct user's finger was supplied. [2]

TPM2_NV_Certify serves a similar purpose for an NV defined index. It certifies that the data at an NV index is indeed on the TPM. See Chapter 11 for details on the NV index options.

an application is using an NV index as a counter or bit map together with a policy for a signing key. the index is used to revoke key usage: for example, when a count is reached or when a bit is set in a bit map. the application wants certainty that the NV index has been updated and uses TPM_NV_Certify to get a signature over the NV data.

an application is using a hybrid index as an extend index to effectively create a new pCr that is authorized, under control of the application. (Using a hybrid extend index as a pCr is explained in Chapter 11.) the explicit quote command only reports

the standard pCr values. the application can use TPM_NV_Certify to sign the equivalent of a quote.

As with TPM2_Certify, TPM2_NV_Certify signs the NV index policy. The relying party can validate the NV index access policy before entrusting the NV index value in another policy.

  • [1] See, for example the PKCS #10 standard in IETF RFC 2986.
  • [2] Chapter 14 discusses the details of policies—in particular, the variations of the TPM2_ PolicySigned command.
< Prev   CONTENTS   Next >

Related topics