Platform Endorsement

A platform endorsement key is an asymmetric key pair located in a TPM's internal persistent memory. A TPM has exactly one such endorsement key pair. The TPM uses the private part of that key pair for decryption, never for encryption or signature operations. The public part of the key will be exported outside the TPM to be used for encryption by other parties. We will see later in more detail the specific uses of the private endorsement key that are allowed by a TPM.

There are both security and privacy concerns about maintaining this key pair. For security reasons, it must be impossible to export the private key from the TPM. Otherwise, other entities can pretend to be a TPM. Also, access to the public key should be restricted for security reasons. Otherwise, there is a reduced defense against a rogue attempting to take ownership of a TPM. There may also be privacy reasons for restricting access to the public endorsement key. After all, it can be considered to be a label attached to a TP, even if it is not obvious how a rogue would take advantage of it.

An endorsement key is embedded in a TPM in order to enable a few critical messages to be sent to that TPM. A third party knows that it is sending messages to a genuine TPM because of social trust: Some entity provides attestation (e.g., an X.509 certificate [ISO/IEC 9594-8]) that a particular public key is the public endorsement key of a genuine TPM. (We will discuss this in more detail later in this chapter.) This enables a third party to construct messages that can be interpreted only by genuine TPMs. These messages are used to take ownership of a TPM and to activate identities that have been vouched for by a Privacy-CA.

Private endorsement keys must be known only to the TPM that holds the endorsement key. The TCPA specification originally required that an endorsement key be generated on the TPM that holds that particular key. This restriction was later relaxed, however, because of the potentially high costs involved. The problem is that there is a statistical variation in the time needed to generate an asymmetric (RSA) key. Some of the “good” TPM chips on a silicon wafer would not complete generation of their endorsement key in an economic time. (It should not be inferred that these slower chips are inferior to faster chips. The difference in time depends on random numbers generated during the key generation process. One chip could be slower to generate a key this time, but faster next time, depending on the random numbers.) So the TCPA specification permits manufacturers to generate an asymmetric key outside a TPM and inject the key into the TPM, instead of generating the key inside the TPM. Such a process is standard in the smart card marketplace, and should not be a cause for concern. The TCPA specification mandates that injected keys must be as secure and as private as those generated inside the TPM. This means that the injection must be done in a secure environment and that the key-generation equipment must forget keys after it has injected them. In order to provide credentials for endorsement keys injected in this way, the credentials issuer must be able to assess the quality of this endorsement key injection process. (See the endorsement credential section later in this chapter.)

The endorsement key is tagged with TCPA_VERSION to indicate the version of the TPM protected capability (TPM_CreateEndorsementKeyPair) that created the key at the time the key was generated. This may be useful in the event that capabilities are modified (to reflect an improved method of selecting RSA keys, for example).

TPMs permit the public endorsement key to be read. Access to the public endorsement key is desirable during the process of manufacturing TPMs and platforms, in order to generate attestation for the TPM and its host platform. Access is also desirable when the platform belongs to a customer, because it is impossible to take ownership of a TPM if its public endorsement key is unknown. Unfortunately, access to the public endorsement key may be a security concern and even a privacy concern for the same reasons. So it is possible to prevent reading of the public endorsement key except after proof of TPM-owner privilege.

Naturally, the private endorsement key is stored inside the TPM and is available only to the TPM. After this private key has been associated with a given TPM, it is never revealed outside that TPM. The private endorsement key is used by the capabilities TPM_TakeOwnership (taking ownership of a TPM) and TPM_ActivateIdentity (the first of two steps to obtain identity attestation data from a Privacy-CA). The public endorsement key is stored by the TPM and is exported by the TPM using the capabilities TPM_ReadPubek, which is available to all users, and TPM_OwnerReadPubek, which can be used only by the authorized TPM owner. Users can be prevented from reading the public endorsement key through the use of TPM_DisablePubekRead. The public endorsement key will also be incorporated into digital certificates, which express attestation for a TPM and its host TP. Access to such certificates should be under the control of the TPM owner, because of privacy considerations related to the public endorsement key, as described in the previous paragraph.