Integrity

An understanding of integrity is crucial to an understanding of TPs and warrants this separate description, even though aspects of these processes have already been described. Chapter 6 is devoted to a more detailed explanation of TCPA functionality for integrity measurement and reporting. Chapter 12 covers how such functionality can be used to allow users to check out a platform online before entering into transactions with that platform and to provide a basis of trust.

You may recall that the RTM and measurement agents cooperate to measure and store condensed values of integrity metrics in PCRs inside a TPM.

• The Root of Trust for Measurement (RTM) and associated measurement agents measure information about the platform and store a condensed summary in the PCRs in the TPM.

• At the same time, the RTM and measurement agents store a measurement log in any convenient unprotected memory.

• The measurement log contains primitives of measurements that can be compared with statements made by entities that attest to certain parts of the platform.

• The measurement log must contain both the primitives and information about the order in which successive pieces of software have been executed, to enable reproduction of the condensed summary stored in the TPM.

Each entry in the log inside the Trusted Platform Measurement Store (see the preceding section) contains a description of a measured entity plus an appropriate integrity metric that has been recorded inside a TPM. The log can be used to reproduce the value of each sequence of integrity metrics inside the TPM. If the log and the TPM are consistent and the TPM is trustworthy, the log can be trusted. If the values derived from the log and the values reported by the TPM are the same, the log is presumed to be an accurate record of the steps involved in building the software environment of the target platform. Consequently, the descriptions in the log of the measured entities represent the actual entities that contributed to the software environment inside the platform. Any difference between the values derived from the log and the values reported by the TPM indicates an undesirable inconsistency in the state of the target platform.

Integrity Metrics in a PC

Figure 3-4 illustrates the process for measuring integrity metrics in a PC and ignores the other processes that execute during the boot process. These operate as normal, but it is unnecessary to describe them in a description of the measurement of integrity metrics. The CRTM in this example is part of the BIOS called the Bios Boot Block (BBB). In this example, the BBB starts the boot process and measures its own integrity and the integrity of the entire BIOS. This involves running measurement programs, storing a log in the Trusted Platform Measurement Store, and saving a summary of the log (in PCR-0 within the TPM, for example). The BBB then passes control to the BIOS proper, which measures the option ROMs, stores the measurement log in the Trusted Platform Measurement Store, and saves a summary in PCR-1. The BIOS passes control to the option ROMs, which carry out their usual operations and then pass control back to the BIOS. The BIOS then measures the OS loader, stores the measurement log in the Trusted Platform Measurement Store, and saves a summary in PCR-2. Next, the BIOS passes control to the OS loader, which does whatever it normally does, measures and stores the integrity values of the OS (using PCR-3), and then passes control to the OS. Finally, the OS measures and stores the metrics of OS components and any additional software or applications that are loaded onto the platform (i.e., software and applications that are either part of the Trusted Computing Base (TCB) or can potentially subvert the TCB), using PCR-4. If this subsequently changes, the value of the PCR-4 is updated using the sequence modification process mentioned previously. In this way, a chain of trust is built from the CRTM. (Of course, a different number of PCRs may be used to record both the boot process and events that occur when the OS is running.)

As is the case with the analogous process in other platforms, the central idea is that each component in the platform measures the next component in the chain and stores this value in such a way that this value cannot later be modified by another component. Therefore, if a component is untrustworthy, its “bad” integrity value will be recorded before that untrustworthy component is able to alter this value. The integrity values stored after that point in the process will be untrustworthy, and yet a challenger can be assured that by analyzing the integrity information, he or she will be able to detect whether a platform is potentially untrustworthy.

Integrity Challenge, Response, and Verification

Integrity challenge and integrity response are the TCPA processes that reliably report the current hardware and software configuration of a computing device to local and remote challengers. Integrity verification is the process of verifying that the configuration is the desired configuration.

The integrity metrics enable an entity to determine the consistency of the measurement information and compare the actual and expected states of the platform. So an entity seeking the state of (the computing environment inside) a TP depends critically on the values of the integrity metrics. It follows, then, that the integrity metrics must be reported by a trusted mechanism. That trusted mechanism is the TPM. The TPM proclaims its trustworthiness by signing data using one of its identity keys, but (as usual) it requires authorization to use that key.

TCPA does not specify either the nature of the TPM identity or the authorization method to use that identity. Presumably, the identity will always be one with a label that actually identifies the platform or its owner, rather than one chosen to obscure the identity of the platform. As far as authorization is concerned, three choices are obvious:

• The identity could be set up so that it doesn't require authorization.

• The challenger itself could hold the authorization secret and directly request an integrity response.

• The TPA could keep a value that it uses as the authorization secret and could have a policy stating the names of challengers who have the privilege of using that value to request an integrity response.

Each of these choices has advantages and disadvantages, and the chosen method varies from situation to situation.

A challenger who wishes to know the state of a target platform invents a nonce and sends an integrity challenge to the target platform. The TP might or might not respond to a particular challenger, depending on the policy of the TP and whether the challenger has access to authorization to use a TPM identity. If the TP decides to respond to the challenge, the Trusted Platform Agent coordinates the integrity response. The TPA sends the nonce to the TPM and makes the TPM sign the nonce and the current PCR values, using a TPM identity. Next, the TPA gets the logs of the measured software from the Trusted Platform Measurement Store and gets certificates from the relevant repositories. The TPA bundles this information and sends it to the challenger. This is the integrity response.

The challenger must verify the integrity response before it can decide whether to trust the target platform. In general, the challenger must inspect these aspects:

• The certificate signed by the Privacy-CA that attests to the TPM identity—to know whether the TPM identity is a genuine TPM identity

• The nonce signed by the TPM identity—to know whether the integrity response is live (and not a replay of a previous message)

• The PCRs signed by the TPM identity—to know whether the PCRs are an accurate summary of the state of the platform

• The PCR values and the logs of measured software—to know whether the logs accurately represent the current state of the platform

• The logs of measured software and the certificates signed by entities that vouch for individual parts of the platform—to determine whether the platform is in the expected state

In practice, this will be simplified by the use of an entity that directly vouches for the PCRs themselves. Then the challenger must inspect these aspects:

• The certificate signed by the Privacy-CA that attests to the TPM identity

• The nonce signed by the TPM identity

• The PCRs signed by the TPM identity

• The PCR values and the certificate signed by the entities that vouch for the platform—to determine whether the platform is in the expected state

Now the challenger can decide whether he or she has sufficient reason to trust the target platform and interact with it. The challenger makes this decision because only the challenger knows the platform state that provides enough trust for the intended purpose. In many cases, the challenger will want to know that the target has the correct identity, is running an OS with the latest security upgrades, and has a virus checker that uses the latest virus definitions. If the challenger decides to interact with the target platform, the platform should sign all information that it sends to the challenger, for the duration of the session. Otherwise, the challenger is vulnerable to a man-in-the-middle attack. A TPM identity can sign the information if a special signing command (that incorporates PCR values) is used. Signing completely arbitrary data must be done with an ordinary signing key that is itself certified by a TPM identity: TCPA does not permit TPM identities to sign arbitrary data for fear of forgery of special data structures that are generated by the TPM and signed by identity keys.

It is important to note that there is a time interval between the beginning and the end of a trusted transaction. In general, therefore, the integrity metrics must be requested by the challenger both before and after the proper transaction.