Chapter 5. Platform Identification and Certification
In this chapter, we extend the description given in Chapter 2 of the mechanism of platform identification (including the supporting certification process). TCPA platform identification provides evidence of basic behavioral trust: The meaning of a TP identity is that the host entity contains a TPM that can be trusted to operate as expected and that the host entity will measure and report integrity metrics as expected. Verification of this basic behavioral trust evidence requires social trust mechanisms. This chapter, however, describes just the TCPA mechanisms that prove basic behavioral trust; it describes neither the verification of basic behavioral trust nor the verification of arbitrary behavioral trust, which are described in Chapter 12. Neither TCPA nor this book gives guidance on the issues of providing sufficient trust for a particular purpose.
The primary purpose of TCPA platform identification mechanisms is to provide a recipient of data from that platform with confidence in that data. The precise level of confidence depends on individual circumstances. It varies from recipient to recipient and varies with use of data (even for the same recipient). This is because only the entity intending to interact with a platform is able to assess the level of protection provided by a TP relative to the sensitivity of the data. To reach a decision about confidence, the recipient must know that a platform contains a genuine TPM and that the platform has been designed to properly support and use that TPM. In some circumstances, the recipient also must repeatedly identify the same platform. So a platform must prove that it is a genuine TP, and it may need to repeatedly provide the same proof to a given recipient. This doesn't imply that it is necessary to provide the same proof to all recipients. In fact, for privacy, the user of a platform may wish to deliberately provide different proofs to different recipients.
The TCPA specification deliberately differentiates between proving that a platform is a genuine TP and proving that a platform is a given TP. Both of these TCPA platform identification mechanisms use secrets and asymmetric cryptography. The first mechanism, called endorsement, amounts to using a secret to identify a particular assembly of hardware and software that complies with the TCPA specification. A platform must have at least one such endorsement secret, installed by someone who will vouch that the secret belongs to a TPM with the necessary properties. The second mechanism, called identity (sometimes called attestation identity), amounts to a statement that an entity with knowledge of a given secret has previously proven that it is an assembly of hardware and software that complies with the TCPA specification. Clearly, a given platform can have any number of such identity secrets. It can be argued (and is argued by some commentators) that both mechanisms identify the platform, so they amount to platform identities, but TCPA goes to great lengths to make these mechanisms as different as possible.
Identity keys are used only to sign data (presumably for third parties); the endorsement key is used only to decrypt data for use by the local platform.
The owner of a TPM can associate identity keys (but not the endorsement key) with a textual string that is the name of the identity (which can be absolutely anything).
It is true that the presence in a platform of data decrypted by a particular endorsement key is proof that the platform contains that endorsement key. But we argue that this is a far cry from providing third parties with data that demonstrates its point of origin. Neither TCPA nor the authors of this book classify the endorsement key as an identity.
Normally, a manufacturer installs an endorsement key before shipping a platform to a customer, but this is not necessarily the case. The requirement is simply that attestation for the endorsement key and the construction of the TP must be acceptable to an entity that vouches for TP identities. In many cases, only the TPM manufacturer or platform manufacturer have sufficient reputation to provide this attestation, but a closed user group requires just someone trusted by that user group.
After someone has attested that a particular endorsement key belongs to a genuine TPM, someone must attest that a TPM with that particular endorsement key is attached to a genuine TP, and someone must attest that the design of the TPM and the platform are compliant with the TCPA specification. This is necessary and sufficient to show that the endorsement key identifies a platform that complies with the TCPA specification. Someone has put his or her reputation at risk by vouching for an endorsement key and its platform. If a recipient receives data vouched for by a third party and the recipient trusts the third party, the recipient can trust the received data (to an extent depending on the particular interaction). This expression of social trust is normally given in the form of X.509 digital certificates, each of which is signed by the trusted third party. Similarly, you can believe that a given key is really a TP identity because someone has put his or her reputation at risk by vouching for that identity. If a recipient receives data vouched for by a TP identity and the recipient trusts the entity that vouches for the TP identity, the recipient can trust the received data (to an extent depending on the particular interaction).
As we shall see, identities can prove that they belong to a TP, each identity using a different fixed proof. This property means that the identities are “pseudonymous.” The pseudonymous identities are used indirectly to attest that certain data was processed inside a TPM. They never directly sign data that was generated exclusively outside the TPM, for fear of a rogue user submitting data that duplicates a data structure used by a TPM. This would enable the rogue to create bogus data structures that appear to be generated by the TPM. Instead, an identity can be used to certify another key, which is in turn used to sign data generated outside the TPM.
An identity requires attestation that it represents a platform that conforms to the TCPA specification. Normally, the identity will be used within a public key infrastructure (PKI). These rely on Certification Authorities (CAs), which act as the trust points within the PKI and attest that a given secret really does belong to an entity with a particular name. TCPA chose to define a special type of CA, called a Privacy-CA, which additionally checks that the name and secret represent a genuine TP. This requires the Privacy-CA to inspect data produced by a platform and the attestation provided for the endorsement key and the platform. If the data and attestation are consistent and the Privacy-CA believes the attestation, the Privacy-CA creates new attestation that vouches for the identity. Often only a public CA has sufficient credibility to act as a Privacy-CA, but a closed user group requires just someone trusted by that user group.
Whenever the platform uses an identity to present data to a third party, it supplies just data signed by the identity plus the attestation from the Privacy-CA. This provides the recipient with exactly the identification context selected by the platform owner when he chose the identity's name and a generic description of the type of platform—nothing more. (The platform does not supply the attestation for the endorsement key and the platform.) The recipient checks the consistency of the information. If it is correct and if the recipient trusts the Privacy-CA, the recipient “knows” that a genuine TP generated the data and can recognize that particular TP in the future, even if the identity name is just an arbitrary label that gives no useful information about the platform.
This chapter now introduces issues in approximately the same order as they are encountered during the lifetime of a TP. A platform must have an endorsement key before it is useful. So we first describe issues related to the endorsement key. Then a platform requires expression of the social trust in that platform. So we describe the certification process underlying identity creation. Then a platform requires identities, so we describe the generation of a TPM identity. Next, we briefly list the permitted usages of TPM identities. Finally, we list the TPM capabilities (in the sense of functions) that implement these mechanisms.