Communication with a Trusted Platform
In today's world, and particularly with increasing device connectivity, more and more platforms interact with each other using networked facilities that are either fixed (such as LAN, modem, Internet connection, etc.), or mobile (such as GSM connection, wireless networks, UMTS, etc.). The main purpose of these interactions is either to exchange data between locations (i.e., move or copy it), or to perform a remote operation on the platform (which is an extension of the former case). Regardless of the security of the underlying protocols used for communication (whether TCP-IP, IPSEC, HTTP, HTTPS, and so on), both platforms can benefit from the TCPA features, described in previous chapters, in order to increase trustworthiness in the reliability of information that is exchanged.
The Aim of a Challenge
The aim of the challenge is to provide information about the configuration of a target platform to a requesting entity (referred to as the challenger) in a trusted manner. By configuration, we mean any piece of code or relevant platform-specific information that has been reported to the target platform's TPM (reporting mechanisms as described in Chapter 6). The exact content that gets reported will depend on the request from the challenger, and on the type of system that is running on the target platform. In other words, what is reported to the challenger will depend on the context in which the challenge is performed. As discussed in Chapter 11, the reported information, and how it can be trusted to be reliable by the challenger, will depend upon the trust relationship between the challenger and the relevant Trusted Third Parties (TTPs) used by the TP owner.
There is no requirement on the design of the challenger, but it needs to be a device trusted by its user to behave as expected and interpret the result of a challenge. This is achieved by using either a very well-controlled device (such as a smart card, or a PDA, etc.), or using another TP to perform the challenge. Whichever solution is used, the requirement is to have an entity with its own computing engine. Chapter 15 discusses how the information resulting from the challenge of a TP can be communicated to a human user by the device used as a challenger.
The Main Steps of a Challenge
Regardless of how the two platforms physically communicate and which protocol is in use, the challenging process involves many different steps in order to gather the required information. Some of these steps are mandatory, and some are optional—depending upon the usage model and the underlying communications protocol. TCPA does not specify how a challenge should occur between two computing platforms, but it does define the TPM_Quote command that serves as the basis for responding to a challenge. So, the main steps of a challenge would look like this:
Sending the challenge request [by the challenger]. The challenger needs to locate the TP it wants to challenge, and establish a connection with a process on that TP that can service the challenge request. This function is not defined as such within the TCPA specification, and can rely on any kind of network communication layer (TCP/IP, HTTP, etc.). The process that receives the challenge can be any type of process, as long as it can have access to network resources (most usually a TCP/IP stack, but it can also be a proprietary protocol over a point-to-point link for instance, such as a smart card using the ISO/IEC 7816 protocol [ISO/IEC 7816]). The process also needs to have the privileges required for accessing the TPM_Quote command. In PCs, the usual type of implementation would be a daemon or a service.
Authorizing the challenge [at the target TP]. Optionally, the target TP OS can restrict access to the process that will respond to a challenge request by requiring the challenger to authenticate itself. Once again, the details of this access control are not prescribed by TCPA, and any authentication mechanism could be used, depending on the context (i.e., password or cryptographic authentication, for instance). However, in some contexts, it may be required that the challenger knows the authorization data for the TPM key that will be used to sign the result of the TPM_Quote operation that must be performed on the target TP in order to respond to the challenge. In such a case, a challenger ignorant of the authorization data for that TPM key would not be able to obtain a response to its challenge request. A more general method of performing such authorization of a TPM key is discussed in Chapter 10.
Performing the challenge and responding to the challenger [at the target TP]. The TP process receiving the challenge request has to issue a TPM_Quote command to the TPM. The exact input to this command will depend on the TP's policy on responding to a challenge, and on authorizing the use of TPM keys for that purpose. It will include a choice of Platform Configuration Registers (PCRs) of the TP's TPM that must be signed by the TPM (this is to allow for a challenge to be performed on the values of selected PCRs). In order to avoid a replay attack, the challenger should provide its own random data to be included in the data signed by the TPM_Quote command. The result of the TPM_Quote operation will be a digitally-signed data structure. The signature can be produced either by a TPM identity key or a TPM signing key, as described in Chapter 6. The data structure represents a summary of the current software state and configuration of the TP. It consists of the TPM's current PCR values for the chosen set of PCRs, and the “random” data provided by the challenger. Note that the TPM_Quote command is described in more detail in Chapter 6.
Because the signature uses a TPM key, this key needs to be authorized, and therefore one of the components needs to provide the authorization data. This will either be the challenger, the TP process issuing the TPM_Quote command, or any other entity. The signed structure is then sent back to the challenger, along with a detailed history of the TP's software state and configuration events. This history information is clear text (plain text) data, collected since the platform's last reboot, that describes every event that has been reported to the TPM's PCRs, whether execution of a software component or configuration information. Information about each of these events must include the hash value that was input to the TPM_Extend command when the hash was reported to the TPM, as described in Chapter 6. For the challenger to be able to validate and interpret the response to the challenge, every entry of the history information returned by the challenged TP must include the following information:
The index of the TPM's PCR to which the event measured in this entry was reported
The hash value that was reported to the above TPM PCR as a result of that event being measured
Information that allows the challenger to identify the event that was measured and reported to the TP's TPM. For example, if an entry corresponds to a software or firmware component that was executed on the TP, the corresponding entry in the history information should describe what software component it is, and what version it is. If the entry corresponds to information reported about the configuration of the platform, it has to describe what configuration it relates to, and how it was measured.
The actual validation certificate for the component measured in this entry, or a reference (i.e., component vendor name) to where a validation certificate for this component can be found
Validating the response to the challenge [by the challenger]. During this step, the challenger establishes whether the information provided in response to the challenge can be trusted to accurately reflect the history of events that were reported to the challenged platform's TPM since that platform's last reboot. Note that this is not the same as verifying the behavior of the challenged TP, or whether the behavior is the desired behavior (these aspects are discussed in the next section).
The challenger will take the following steps:
1. | Verify that the digital signature on the reported TPM
PCR values was performed with a key that belongs to a TPM on a genuine TP, or belongs to the expected TPM in the case where the challenger had previous knowledge of the TP that is being challenged. The mechanism designed by TCPA to satisfy this first step makes use of TPM identity certificates (see Chapter 5). If the challenger trusts the Privacy-CA that issued such a certificate to certify that it has checked TCPA-conformance for both the TPM and its integration into the TP, then the challenger can establish that the signed PCR values reported by the challenged TP can be trusted to have been collected and reported in conformance with the TCPA specification. Finally, if the TPM key used by the challenged TP to sign the reported PCR values was not a TPM identity key, the challenged TP must provide another means for the challenger to establish the information described above. This can be achieved through the use of the TPM_CertifyKey command (described in Chapter 9) in conjunction with a TPM identity. |
2. | Re-compute the values that should be reported by the challenged TP's TPM for each PCR if the history information is to be trusted to accurately reflect what was reported to that TPM since the challenged platform's last reboot. The challenger needs to use the history information provided by the challenged TP in order to re-compute what these PCR values should be. To do this, the challenger will use the following information for each event entry in the history information:
|
3. | For each PCR value reported in the signed response to the challenge, the challenger must check that the digest re-computed for that PCR (in step 2) matches the value reported by the TPM for that PCR in the signed response to the challenge. |
If in step 1 the challenger cannot validate the signature on the challenge's response, the challenger will not be able to trust any of the reported information. If step 1 did validate that signature, the challenger can trust that the signed response to the challenge comes from a genuine TP. If step 3 validates that the re-computed PCR values match the reported signed PCR values, the challenger can trust that the hash values (and the TPM PCR indices to which they were reported) in the history information are correct, and accurately represent what was reported to the challenged TP's TPM since that TP's last reboot. If step 3 doesn't validate, the challenger can infer that the history information for the PCRs that didn't verify isn't correct. This suggests that the history information on the challenged TP was corrupted, or that a third element involved in the communication is trying to subvert the process (a 'man in the middle' attack) by modifying the history information. The important point is that the challenger is likely to require that multiple PCRs verify correctly in order to establish sufficient confidence that the challenged TP has reached a given software state. If the PCRs used to record the execution of firmware components don't verify, but other PCRs reflecting higher-level software execution do, the challenger cannot trust the latter to be reliable. The chain of trust would have been broken during the boot process of the challenged TP.
Interpreting information from the challenge [by the challenger]. At this stage, the trustworthiness of the hash values (and indices of the TPM PCRs to which they were reported) in the history information has been verified, and the genuineness of the TPM has been confirmed by a successful verification of the signature on the response to the challenge. Now, the challenger must evaluate what each component reported in the history information represents, and whether it is sufficient for (and compatible with) the challenger's intended purpose.
Fundamentally, a challenger should inspect every detail of every event in the history information. For example, for an event representing execution of software or firmware, this would require checking the effects of the instructions that were executed. This is extremely complicated, and therefore TCPA introduces the concept of validation entities
TCPA defines validation entities as third parties responsible for certifying such events and the hash value that should be obtained if this component is measured and reported. The validation certificates issued for software components in the history information by their corresponding validation entities are necessary for the challenger to make a trust decision about this component. For each entry, the challenger will use the following data from each entry in the history information:
Information that allows the challenger to identify the event that was measured and reported to the TP's TPM. For example, if an entry corresponds to a software or firmware component that was executed on the TP, the corresponding entry in the history information should describe what software component it is, and what version it is. If the entry corresponds to information reported about the configuration of the platform, it has to describe what configuration it relates to, and how it was measured.
The validation certificate for the hash value of the component measured in this entry, or a reference (i.e., component vendor name, etc.) to where a validation certificate for this component can be found. A validation certificate will certify what the measured digest should be for a given component.
Failing to provide a validation certificate would make it harder for the challenger to make a trust decision about a given component, although it is still theoretically possible. With such validation certificates, and if the challenger trusts the issuing validation entity, the challenger can answer the question “the challenged platform says that the measured software component was software X, version V, by vendor Y, but was it really?” This does not prove that the software component does what it is intended to do, or should do, but it establishes that a software component running on the challenged platform is the one identified in its validation certificate.
The challenger must then decide whether to trust the target TP. This involves evaluating trust in all the reported components. There are at least three tests that might result in a component becoming untrusted (the term 'untrusted' used here can carry three slightly different meanings):
If the challenger either does not trust the validation entity that certifies a component, or no validation certificate is available, this component is unidentifiable as far as the challenger is concerned, and is untrusted.
If a component is validated by a trustworthy certificate, but the challenger has no confidence in the ability of this component to maintain the chain of trust on the challenged platform, the history information for any entry after this untrusted component can not be trusted.
If a component is identified, but is simply deemed unsuitable (from the point of view of the challenger's policy) for the intended purpose of interacting with the challenged TP, this component is untrusted.
If an untrusted component is discovered, the challenger must apply a policy to decide whether it can continue interacting with the challenged platform.
Simplifying the Use of an Integrity Challenge
One onerous aspect of using an integrity challenge is that it can become overly complex. This will usually be due to the context in which the challenge mechanism is used, and in the way it is implemented. An integrity challenge starts to become difficult when the number of entries in the history information is high, and a lot of different validation entities are used by the challenged TP to certify these entries, or when the challenged platform has been up-and-running for a long time, and reports extremely long history information.
In a constrained environment, where the “acceptable” software state of a challenged platform is known to be limited to a small number of alternative software states, the TPM PCR values that represent these software states can be directly certified by a validation entity. This allows a challenger to use a single validation certificate (directly certifying all TPM PCR values representing a given platform software state) in order to check the whole software state of the challenged platform in a single step. The challenger needs to be able to make sense of what that software state implies, but this can be part of what is certified by the validation entity. (The next section will look at how a corporate IT department could play that role.) In another plausible situation, the challenger could have been involved in setting up the software environment of a platform. In this case, the expected TPM PCR values (software state) are already known to the challenger, who can then perform just a simple check against these known PCR values.
In the situation where the history information is likely to grow to a size that becomes impractical to interpret as a result of challenge, intermediate validation steps should be considered. This would consist in some third party verifying the history information of a target TP at a point in time, and certifying that the whole history information up to that point matches certain policies. The history information can then be shortened to a single entry representing the whole certified previous history. It would then grow again with subsequent entries. If this is done at regular intervals, a challenger will always be provided with a reasonably sized history information as a result of a challenge. Validating its content will require that the challenger trusts the third party that performed the last intermediate certification. This can also be envisioned in an environment where a third party is trusted to evaluate the whole software state of a platform on behalf of a challenger. For example, a company's corporate IT may regularly challenge and re-certify the state of a company server required to be accessible only when it is in a company-certified software state.
More generally, the value of a challenge mechanism will greatly depend on the application context in which it is used, and on how it is implemented. It is unlikely to be useful if it involves a human user in manually checking a multitude of validation certificates in order to try and make sense of the software state of a remote platform.