D3.9: Study on the Impact of Trusted Computing on Identity and Identity Management

Title: TRUSTED PLATFORM MODULE (TPM) SPECIFICATION OVERVIEW

Trusted Platform Module (TPM) Specification Overview

The TPM Specification is the main part of the TCG Specifications. It defines all platform independent aspects and functions that must be provided by a trusted platform. All system specific aspects have been sourced out to system specific documents like the PC Specific Specification. 

TPM Components and Tamper Protection

The TPM provides an RSA key generation algorithm, cryptographic functions like RSA encryption and decryption, a secure random number generator (RNG), non-volatile tamper-resistant storage, and the hash function SHA-1.

The TCG Specification does not prescribe that TPM devices have to be implemented in hardware but to provide the degree of security claimed by the TCG Specifications with a software implementation may be an infeasible task. Thus most TPM implementations are in hardware.

Hardware TPM devices can be compared to integrated smartcards containing a CPU, some memory, and special applications. The assumption is that the chip is tamper-evident (see section 3.1.2) and mounted on (or integrated in) the motherboard [98] such that removal is evident to visual inspection. The main chip contains a special security controller with some internally shielded memory for the firmware, non-volatile EEPROM for the data and RAM. Furthermore, it contains a cryptographic engine for accelerating RSA encryption and decryption processes, a hash accelerator and a random number generator that is needed to generate secure cryptographic keys. Figure 1 shows the main components of the chip.

Fig1: Simplified Architecture of the TPM 

1. The components of a TPM must be trusted to work properly which is intended to be guaranteed by Common Criteria (CC) evaluation and Evaluation Assurance Levels (EAL) [6, 7, 8].

The I/O-Interface of TPMs has not been specified by the TPM Specification but has been left to the platform specific ones. The PC Specific Specification [97] recommends to use the synchronous Low Pin Count-I/O-Interface (LPC-I/O) that is available on most PC motherboards to communicate with the host PC. The connection of the TPM to the motherboard is illustrated in figure 2.

The protocols defining the order of commands and transmissions between the host and the TPM are a command-and-response dialogue, i.e., after every command the host waits for the corresponding response from the TPM before it sends a new request.

Fig2: Integration of the TPM into a PC platform 

Due to the physical properties of the LPC interface, checksums for block protection are not required. To configure the chip, configuration registers can be used to enable or disable functions of the TPM chip, and to configure the I/O addresses for communication with the chip. Data registers are used for data transfer between the host PC and the TPM chip; status and command registers are used to audit and control the performed operations. Depending on the used TPM chip, different layers may exist above the hardware to transport control information, vendor-specific information, or application data (e.g., data to be signed or commands to generate keys). 

In terms of compliance to Tamper Protection standards, a TCG compliant TPM should be able to achieve FIPS PUB-140-2 certification [100, 51].

TPM Key Types and Credentials

A TPM contains a Root of Trust of Storage (RTS) which protects data and keys entrusted to the TPM. 

The RTS manages a small amount of volatile storage inside the TPM device that is used to hold currently used keys (key slots). Unused keys may be encrypted with a storage key and moved off the TPM chip, e.g., to a hard disk drive. The storage key might be encrypted with another storage key which leads to a key hierarchy as shown in figure 4 with the Storage Root Key (SRK) being the root. The key slots of the TPM are managed by a trusted service outside the TPM which is called Key Cache Manager (KCM). 

Key Types 

Each TPM protected key is stored with several attributes that identify the type of the key and what it is intended to be used for. These attributes are set during the generation of the particular key and cannot be altered later. 

1. Storage Root Key: The Storage Root Key (SRK) is used to wrap TPM protected keys which can be stored outside the TPM. This builds a hierarchy of keys represented in figure 4 on an external storage device like a hard disk drive. The SRK is embedded into the TPM and is generated during the process of taking logical ownership of the platform. It can be re-generated by creating a new platform owner which destroys the previous key hierarchy and all the data and keys it contains.

2. Endorsement Key: Each TPM device is shipped with an embedded non-migratable Endorsement Key (EK) that has been generated as a part of the manufacturing process in or outside the TPM. Embedded means that the key cannot be removed from the TPM and thus uniquely identifies it and the surrounding platform. The entity that generates the EK issues an Endorsement Credential which should provide evidence that the EK has been properly created and embedded into a valid TPM. Besides the two special keys described above, a TPM can create four different types of asymmetric keys:

3. Migratable keys (MK): Migratable keys are cryptographic keys that are only trusted by the party who generated them (e.g., the user of the platform). A third party has no guarantee that such a key has indeed been generated on a TPM. 

4. Non-migratable keys (NMK): Contrary to a migratable key, a non-migratable key is guaranteed to reside in a TPM-shielded location. A TPM can create a certificate stating that a key is an NMK. 

5. Certified-migratable keys (CMK): This type of encryption key, introduced in version 1.2 of the TCG specification, allows a more flexible key handling. Decisions to migrate and the migration itself is delegated to two trusted entities, chosen by the owner of the TPM upon creation of the CMK: The Migration-Selection Authority (MSA) controls the migration of the key, but does not handle the migrated key itself. In contrast, the Migration Authority (MA) handles the migration of the key: To migrate a CMK to another platform, the TPM expects a certificate of an MA stating that the key to be migrated can be transferred to another destination. Furthermore, the certificate of the CMK that the owner/user uses to prove that it was really created by a TPM contains information about the identity of the MA resp. MSA. 

Fig3: TPM Key Management and Hierarchy 

1. Attestation identity keys (AIK): These non-migratable signature keys provide pseudonymity resp. anonymity of platforms including a TPM. AIKs are locally created by the TPM. The public part is certified by a Privacy Certification Authority (Privacy CA) stating that this signature key is really under control of a secure TPM. In order to overcome the problem that this party can link transactions to a certain platform, version 1.2 of the TCG specification defines a cryptographic protocol called Direct Anonymous Attestation (DAA) [27], eliminating the Privacy CA. AIKs can be used to attest to specific platform configuration states (see section 3.1.4 and 3.1.5). A platform can have multiple AIKs to avoid correlation of platform identities. In order to generate AIKs, the Endorsement, Conformance and Platform Credentials (which are delivered with the platform), the EK and the authorization by the platform owner to use them is required. 

TPM Credentials 

A trusted platform is delivered with several credentials (digital certificates) that should provide assurance that its components have been constructed to meet the requirements of the TCG Specifications. 

Endorsement Credential As already mentioned, the Endorsement Credential should provide evidence that the EK has been properly created and embedded into a valid TPM. It is issued by the entity that generated the EK. This credential contains the name of the TPM manufacturer, the TPM part model number, its version and stepping and the public part of the EK. The EK is a RSA encryption/decryption key pair which is used along with the Endorsement, Platform and Conformance credentials to provide evidence of the platform’s identity in a protocol to establish AIKs.

Conformance Credentials The Conformance Credential is issued by an evaluation service (e.g. the platform manufacturer, vendor or an independent lab) with sufficient credibility to properly evaluate TPMs or platforms containing a TPM. It should indicate that the Trusted Building Block (TBB) design and implementation has been accepted according to the evaluation guidelines. A single platform may have multiple Conformance Credentials for multiple TBBs. They typically contain the name of the evaluator, platform manufacturer, the model number and version of the platform, the TPM manufacturer name, TPM model number and version or stepping and a pointer to the location of the TPM and platform conformance documentation. The Conformance Credential does not contain privacy sensitive information or information that can be used to uniquely identify a specific platform.

Platform Credential The Platform Credential is issued by the platform manufacturer, vendor or an independent entity. It should provide evidence, that the platform contains a TPM as described by the Endorsement Credential. The Platform Credential contains the name of the platform manufacturer, the platform model number and version and references to the Endorsement Credential and the Conformance Credentials. The Platform Credential is privacy sensitive since it contains information that can be used to uniquely identify a specific platform.

Integrity Measurement and Reporting

A trusted platform collects information about its current configuration and stores it in a log outside the TPM, called Stored Measurement Log (SML). This enables the detection of modified code and malicious or unwanted software which might compromise the platform’s security and thus its level of trust. The information stored in the SML cannot be stored inside the TPM device since it may become very large. Manipulations of the SML will be detected because the digest of the original sequence is securely stored inside the TPM. For this purpose the TPM provides a set of registers called Platform Configuration Registers (PCR) that can be used to store hash values. The TPM hardware ensures that the registers can only be modified as follows: Ri+1 := SHA1(Ri || I), with the old register value Ri, the new register value Ri+1, and the input I. The process of modifying a PCR value is called extending a PCR and ensures that previous will not be ignored and the order of operations is preserved.

The content of the PCRs can be used for verifiable attestation (see section 3.1.5) of the platform’s configuration based on Validation Credentials and the chain of trust (see figure 4). Validation Credentials are digital certificates issued by hard- or software manufacturers that provide measurable components (like video and disk storage adapters, memory controllers, processors or software) or other qualified validation entities. They contain the validation entity name, component manufacturer name, component model number, version or stepping and digitally signed reference measurement values taken in a clean-room environment when the component is believed to work properly. The verification of a platform configuration state requires the re-computation of the measurement digest using the reference measurements from the Validation Credentials and a simple comparison of the resulting digest value with the actual content of the PCR. A TPM can attest to a PCR value by digitally signing it with an AIK (see section 3.1.5).

Chain of Trust 

As already mentioned, a trusted platform subsequently reports integrity measurement information to the TPM. The idea is that each firm- or software component that is to be loaded or executed is measured before it is started. The result of this check, a message digest, is reported to the TPM in a cryptographically secure manner. Once the value has been submitted to the TPM, it cannot be changed. This means that any change or manipulation of the software state can be recognized since malicious software cannot hide itself by manipulating PCR values or the SML. This implies that the instructions that start the chain of measurements must be trusted which means that they have to function as expected. These instructions are called Core Root of Trust for Measurement (CRTM). Ideally the CRTM would reside in the TPM to profit from its tamper-resistance but due to architectural requirements of the specific platform it might also be located in another device (like the BIOS of the PC platform) which can hardly be manipulated from an remote adversary and should be trusted. After the CRTM measured the system environment consisting of firmware and other components required to give control to the platform’s computing engine, which typically consists of the system’s CPU, memory and chipset, the CRTM passes control to the Root of Trust for Measurement (RTM). Typically the RTM actually is the platform’s normal computing engine which has been previously checked by the CRTM. The RTM inherently generates reliable integrity measurements and reports them to the TPM device building a “chain of trust” as presented in figure 4.

Fig4: Chain of Trust 

Trust Assumptions

Trusted Building Blocks (TBB), like the system’s main processor (which may function as RTM), BIOS (which may act as CRTM), TPM, memory controller, RAM and the paths between those components that are necessary for integrity measurement and reporting have to be trusted. This means that they have to behave in a way that does not compromise the goals of trusted platforms. 

Binding, Signing, Sealing, Sealed Signing and Attestation

In this section, we revisit the basic TC functionalities supported by the TPM, focusing on the specifications of the TCG. 

Binding 

Binding means that a message can be bound to a certain TPM (and platform) using encryption. When encrypting a message with an asymmetric encryption scheme, the sender uses the public key of the recipient to encrypt a message. The recipient is then able to decrypt the ciphertext with his corresponding private key which can be managed by a TPM. If this private key is a non-migratable key then only the TPM that generated it is able to use the key and thus decrypt the message. Therefore the message is bound to the TPM that protects the corresponding private key. 

Signing 

By signing a message, the integrity of this message is associated with the key used to generate the signature. This means that a verifier can detect manipulations of a (signed) message and is able to identify its origin by the verification key which might be bound to an identity using a digital certificate. The TPM tags some managed keys as signing only keys. Those keys are only allowed to be used for signature generation. This should prevent them from being used as encryption keys which might comprise security. 

Sealing 

Sealing is an extension of binding since sealed messages are additionally bound to a set of platform metrics specified by the sender of the encrypted message. These metrics describe a specific platform configuration state that must exist before the decryption of the message is allowed. Therefore Sealing binds a message to a set of PCR values and a non-migratable key protected by a TPM. This provides assurance that protected messages are only recoverable when the platform is in a specific known configuration which is considered to be trusted by the sender of an encrypted message.

Sealed Signing 

Signing operations can be linked to specific PCR values and thus a specific platform configuration state. For this reason PCR values are included into the signature. This enables a verifier to inspect a platform’s configuration at the time when the signature has been generated. The verifier is then able to decide whether to trust the given platform configuration state and accept the signature or not. 

Attestation 

Attestation is the process of vouching for the accuracy of information. A TPM can attest to information by digitally signing internal TPM data like PCR values using an AIK. The correctness of this information then can be verified by a third party that checks the integrity measurements and the AIK itself. The AIK can be obtained and verified by using a Privacy CA or a trusted attestation protocol like DAA [27].