Identity

This section describes the notion of multiple attestation platform identities, which provide privacy for users and owners.

The Concept of a Trusted Platform Identity

A Trusted Platform identity is (statistically) unique, difficult to forge or counterfeit, and verifiable to either a local or remote entity. The TP achieves this by using the TPM, which has a physical tamper-protected presence and protection from software interference and which uses cryptographic secrets and algorithms. A TP identity provides the following major advantages:

• A TP identity guarantees that certain properties hold for the platform associated with it. This is useful information for entities communicating with that platform, even on a one-off basis. These properties result from the fact that the platform is a TP, so it will include the properties of having a tamper-resistant TPM with standardized cryptographic functionality, being able to measure and report integrity metrics in a trustworthy way, and so on. In particular, an identity provides sufficient evidence that a target platform contains the capabilities and data that must be trustworthy if reports about the software environment in that platform are to be trusted.

• A TP identity allows linkage of behavior to previous usage of a platform using that same identity. Among other things, this allows a business relationship to be built over time between the TP user and external entities.

• Only the Privacy-CA that issued identity certificates for a TP can correlate a TP identity with other TP identities.

Usefulness of Trusted Platform Identities

A TP needs at least one externally accredited identity if an owner wants to prove that a TP is genuine without disclosing details about the precise TPM in that TP. TPM identity keys are, however, never permitted to sign information that wasn't generated by a TPM. This rule is necessary to prevent an identity key from being used to sign arbitrary data, which would potentially enable a rogue to produce information that appeared to come from a genuine TPM.

As a result, the following are the most valuable methods of using a TPM identity:

Providing an integrity signature: To prove that some particular data existed in a particular platform when the platform was in a particular state, the platform creates a digital signature over those data plus the current PCRs, using a platform identity (TPM identity). The platform sends the data, along with the PCRs, the signature, and a certificate vouching for the platform identity, to some peer entity. The peer entity verifies the trustworthiness of the certificate by inspecting the signature on the certificate. Then the peer entity uses the public key inside the certificate to verify the origin and integrity of the data. The PCR values provide proof of the state of the platform when the data was signed. A degenerate version of this process provides just a statement about the current state of the platform, and it is used in an integrity challenge (described briefly in Chapter 6 and in more detail in Chapter 12). In this degenerate case, the signed data is just a nonce sent by the entity testing the platform.

Certifying other keys: One use of a TPM identity is to sign a statement about secondary asymmetric keys available to the TPM. These secondary keys may be used for any legitimate purpose by the OS or by applications within the platform (part of some protocol, for example). Certification provides a signed statement of the secondary key's properties: what type of key is it (e.g., RSA, bit length)? Can a TPM use it for signing? Can a TPM use it for confidentiality? Has the use of authorization been disabled? Can it be used in any platform state, or are certain values of PCR required? (Other questions may come up also.) The only restriction is that the secondary key must be fixed to the platform that has the TPM identity (in other words, the secondary key can't be migrated to other platforms). The process is straightforward: The TPM is loaded with an identity key and the secondary key; the TPM extracts a description of the secondary key; the TPM signs that description with the identity key and exports the description from the TPM. When a third party is presented with information signed, for example, by the secondary key, the third party can also be given the key's certified description and the TPM identity's certification (from a Privacy-CA). The third party can check the TPM identity, check the certified description, and decide whether the properties of the secondary key are suitable for the intended purpose.

These properties of TPM identities enable a number of possibilities, including the following:

Confidence in the platform: A platform identity can enable a user to trust the platform on which he is working. A user will work on a platform and eventually send some data to others. If the platform is rogue, it may alter, misrepresent, snoop, or monitor the work done by the user—unknown to the user—with the effect that others incur harm or loss. For example, a rogue platform can surreptitiously alter work done on the platform before that work is shipped, or it can send messages apparently signed by the user, without permission of the user. The user will, nevertheless, be held responsible for those ill effects, because it is his responsibility to manage his platform. This can have enormous legal and financial ramifications, especially in business environments or where highly confidential material is involved. An integrity signature can, however, be used to prove the state of the platform when data was shipped. If the PCR values indicate that the platform was in an unapproved state when data was shipped, the recipient should refuse to accept the data and the provider should not be held accountable for that data. So it is a significant advantage to the user to know that his platform is a TP, vouched for by the organization that gave an identity to the platform. The user could always work on the same platform, known to be a TP. Alternatively, the user could verify that an arbitrary platform is a TP, by using a PDA to obtain an integrity challenge from the platform. Similarly, integrity signatures and integrity challenges provide confidence to organizations, when a user employs remote login to access that organization. A TP enables the organization to verify that a remote platform is the correct platform and that it is running the correct software (refer to the related scenarios of Chapter 2).

Remote management: A platform identity enables organizations to better manage their platforms in the absence of a user, particularly in the case of distribution and control of software that is associated with a platform instead of a user (for example, enhancing automatic upgrading), and diagnosis and correction of faults (using a history of individual platforms).

Insurance: A platform identity may be considered in terms of insurance. An organization can choose to imply that an identity provided by another organization means that the platform design and operation has been investigated by that other organization and has been considered sufficient to provide a given level of integrity. The organization then sells an insurance policy that underwrites the risks associated with using that platform for commercial use.

Auditing: Platform identity may be used to support an independent log of a user's activities. A TP could maintain a log of platform activity, signed using the platform's identity to establish the authenticity and integrity of the log. Although users' privacy rights need to be safeguarded, there are circumstances in which such a log would be critical to proving the innocence or guilt of a user in the event of inappropriate use of a platform.

Creation of a Platform Identity

This section describes TPM identities (sometimes called attestation identities); the roles of the TPME, PE, and Privacy-CA in creating this identity; and how the TPM identity can be used as a platform identity.

A Cryptographic Identity

The TPM identity is a cryptographic identity, based on an asymmetric encryption algorithm, such as RSA. A cryptographic identity requires a secret that is statistically improbable to guess and the ability to prove the possession of that secret without disclosing it. This requires an engine to operate on input data using the secret and produce output data, such that the input/output pair is statistically extremely improbable to produce without the secret. The capability to produce data with this property is taken as proof of possession of the secret and, hence, as proof of identity.

The public representation of the platform identity (refer to Figure 3-5) is a digital certificate, containing a label and a public key, all digitally signed by some trusted entity (a Privacy-CA, as explained in detail below). The public part may be distributed at the discretion of the owner. The private part of that identity is a private key, which is a secret known only to the TPM inside a platform.

The Roles of the TPME and PE in Creating a TPM Identity

The Trusted Platform Module Entity (TPME) vouches that a TPM is a genuine TPM by installing an endorsement key pair in a TPM and embedding the public key of the pair into an endorsement credential. That certificate binds the public endorsement key to information about the characteristics of the TPM. A reputable TPME produces exactly one endorsement credential per TPM. As described earlier (in a section title “Integrating a TPM into a platform”), the TPME could be the manufacturer of the TPM or the manufacturer of the platform, for example, and the endorsement key could be generated outside the TPM and loaded into the TPM, or it could be created inside the TPM. In either case, the same high standards of key generation are required. In particular, there must be no record outside the TPM of the private endorsement key inside the TPM (although, of course, the public part is published or otherwise made available by the owner of a platform). When a third entity receives an endorsement credential, it can verify the signature. If the third party trusts the TPME, it believes that a genuine TPM is the only entity that knows the private endorsement key corresponding to the public endorsement key in the credential.

The manufacturer of a platform must provide analogous proof that a platform is a genuine TP. A so-called Platform Entity (PE) does this via a certificate that attests to the correct incorporation of a particular TPM into a platform. The platform manufacturer also provides other proof, called the conformance credential, that the design of the TPM and the design of the platform meet the TCPA specification.

So if a third party receives the endorsement credential, platform credential, and conformance credential (all in the form of digital certificates), and can verify the signatures and trusts the entities that signed the signatures, the third party believes that the platform is a TP. The problem, however, is that the same information must be sent to support all transactions. This worries some privacy advocates, even though the information could be encrypted (and rendered confidential) while passing through a network. Those privacy advocates assert that forced presentation of the same identification information is a loss of privacy.

The following paragraphs introduce a mechanism to overcome this problem: The concepts of TPM identities and Privacy-CAs are TCPA's solution to the privacy problem created by the need to prove that a platform is a TP.

The Role of the Privacy-CA in Creating a TPM Identity

The previous section introduced the problem that certificates and an endorsement key prove that a platform is a genuine TP, but they may permit the activities of a platform to be correlated. As an example of potential conflict, consider the case of potential e-business applications where the platform owner may not (for privacy reasons) want to disclose information about the platform that discloses the owner. On the other hand, it is necessary for the supplier of the e-business to check that the owner's platform is a TP with a genuine TPM. Otherwise, the application cannot take advantage of the features of a TP.

TCPA overcomes the privacy problem by using a Privacy-CA as a go-between, to attest that attestation identities actually belong to genuine TPs.

After the TP creates an attestation identity, some third party (a Privacy-CA) is chosen by the owner of the platform and uses the certificates to verify that a platform is a TP with a genuine TPM. The Privacy-CA attests to a TPM's identity by creating an identity certificate that binds the identity key to the identity label and generic information about the platform. That identity certificate can be presented to other entities, allowing the owner of the platform to prove that an identity belongs to a genuine TPM in a genuine TP, without presenting the fundamental proof that the platform is a TP.

The platform (strictly, the TPM) can have as many or as few of these identities as the owner wishes. The owner chooses the label associated with an identity, which may be any arbitrary Unicode string. The key associated with an identity is derived from a random source and belongs to one specific TPM. So each identity is pseudonymous—it can have any value but always identifies the same platform.

This design ensures that only the Privacy-CA can use TCPA protocols and TCPA data to collate (TCPA) platform identities and trace them back to a specific owner. (Of course, the design does not prevent an adversary from correlating conventional information, such as network addresses. That is a separate problem!) An owner should choose a Privacy-CA whose polices meet the owner's privacy requirements. An owner should act as his own Privacy-CA if he has sufficient credibility or if he does not need to prove himself to other parties.

The protocol for obtaining a TPM identity is described in considerable detail in the main TCPA specification and in Chapter 5; it is only briefly described here. There are no known defects in the protocol—it prevents man-in-the-middle attacks, for example—but at first sight, it appears somewhat bizarre. The peculiarity of the protocol stems from a predication on trust in the Privacy-CA. If the Privacy-CA does “the wrong things,” the protocol itself breaks, not just the trust in the certificate issued by the Privacy-CA. Nothing is lost in this approach, because if the Privacy-CA can't be trusted, its attestation can't be trusted.

The advantage of trusting the Privacy-CA during the protocol is that only small operations are done in the TPM; large operations can be done using normal software running on a TP. In particular, the protocol eliminates the need for the TPM to keep track of TPM identities that have not yet received attestation and eliminates the need for a TPM to do detailed interpretation of digital certificates.

• First, the TPM is told to generate a new key pair and associate that key pair with a particular Privacy-CA and an identity label defined by the owner. The TPM is presented with a digest that compresses the identity's label and the “name” (i.e., the public key) of the Privacy-CA into a single value. It then creates a new key pair that it labels as an identity key pair and outputs a signature value (signed by the new identity key) that binds the new (public) key to that digest (and, hence, to the identity label and the Privacy-CA).

• Then untrusted software (outside the TPM, but inside the TP) collates all the information that must be sent to a Privacy-CA. This includes the signature just produced by the TPM, the identity label, and the various certificates (endorsement, platform, conformance). The conformance certificate is produced by the Conformance Entity (CE) that vouches for the correctness of the PE information; see the section “Vouching for a TP” earlier in this chapter.

• The Privacy-CA inspects the information and deduces that the documentation describes a genuine TPM, but it can't be sure that the new key actually came from a genuine TPM because none of the information is actually signed by the TPM's endorsement key. This is a deliberate omission. The original designers of the TCPA specification believed that it was necessary to avoid signing anything with the endorsement key, to prevent the perception of a lack of privacy (such as that encountered by Intel corporation when processor serial numbers were first introduced). The private endorsement key is necessarily used for decryption when an owner takes control of a platform. It is considered a poor security practice to use the same key for both encryption/decryption and signing, which reinforces the decision to avoid signing with the endorsement key.

• If the Privacy-CA agrees to vouch for the new identity (perhaps having carried out additional checks on the owner, user, or platform in order to feel more certain that the identity will not be misused), the Privacy-CA creates an identity certificate and encrypts it using a symmetric algorithm. (This encryption is to ensure that only a specific genuine TPM can recover the identity certificate and hence that the identity certificate does describe an identity of a genuine TPM.) The Privacy-CA creates a digest of the identity's public key, encrypts the digest and the symmetric key under the TPM's public endorsement key, and sends both the encrypted identity certificate and the encrypted key/digest back to the TP.

• The TPM decrypts the symmetric key/digest (using the private endorsement key). Only a genuine TPM can do this, because only a genuine TPM has the endorsement key described in the information sent to the Privacy-CA. The TPM then checks that the decrypted digest matches the requested TPM identity. If the test passes, the TPM exports the plain text symmetric key to untrusted software in the TP.

• The main processor in the TPM decrypts the identity certificate using the plain text symmetric key and obtains the identity certificate that attests to the new TPM identity.

Each TPM identity created by such a process is completely independent of other TPM identities.

A TPM Identity as a Platform Identity

Just one particular TPM is bound to a particular platform, either physically (for example, by cryptography, soldering, tearable labels, or a ball-grid array) or logically (see earlier sections of this chapter on integration of the CRTM and TPM into a platform). The platform manufacturer attests to this binding in the platform certificate, and the TPM contains summaries of measurements about its host platform. It follows that an identity of the TPM can be considered as an identity of the computing platform. This differentiates TPs from existing platforms incorporating cryptographic co-processors.

Privacy and Owner Control

The privacy of the owner is reinforced by giving the owner express and explicit control over the creation and use of identities.

The TPM owner has explicit control over making a TPM identity because the relevant TPM commands require the use of owner authorization. Further, one field of these owner authorization commands is the authorization information required to use the identity (for further details, see Chapter 4). Only the TPM can use a TPM identity, and it will not use an identity unless correct authorization is received. So the identity cannot be used without permission from the TPM owner.

TP Identity Summary

TPs provide identities that guarantee that a user is using a TP.

TPM identities are platform identities, because the TPM can sign data on behalf of the whole platform. TPM identities must be created by an owner; TPs do not ship with any identities installed. TPM identities are created and accessed via a TPM. A TPM can have multiple identities, each vouched for by exactly one Privacy-CA. Different TPM identities may be used by the same user or by different users. Identities can be used for integrity signatures, integrity challenges, and to certify descriptions of other keys in the platform.