Desktop version

Home arrow Computer Science arrow A Practical Guide to TPM 2.0

Platform Configuration Registers

Platform Configuration Registers (PCRs) are one of the essential features of a TPM. Their prime use case is to provide a method to cryptographically record (measure) software state: both the software running on a platform and configuration data used by that software. The PCR update calculation, called an extend, is a one-way hash so that measurements can't be removed. These PCRs can then be read to report their state. They can also be signed to return a more secure report, called an attestation (or quote). PCRs can also be used in an extended authorization policy to restrict the use of other objects.

The TPM never passes judgment on the measurements. Internally, it doesn't know which measurements are good or bad, or more or less secure or trusted. At the time of measurement, TPM PCRs just record values. Security or trust comes later, when an application uses PCR values in an authorization policy, or a remote party asks for a signed attestation (quote) of the values and judges their trustworthiness.

New for TPM 2.0, TPMs no longer hard-code the SHA-1 algorithm for PCRs. The algorithm can be changed. Some implementations include banks of PCRs, with each bank implementing a different algorithm.

A TPM implements a number of PCRs: for example, 24 for a PC TPM. The PCRs are allocated by convention to the various software layers, from early boot code to the operating system and applications. They're also allocated for both the software to be run (often the even-numbered PCRs) and the configuration files that customize the boot process (typically the odd-numbered PCRs.)

PCR Value

The primary use case for a PCR is to represent the platform software state, the history of the critical software (and configurations) that have run on the platform until the present. The TPM initializes all PCRs at power on, typically to either all zeroes or all ones, as specified by the TPM platform specification. The caller can't directly write a PCR value. Rather, a PCR value is changed through what the TPM calls an extend operation, as described in Chapter 2. Cryptographically, it is as follows:

PCR new value = Digest of (PCR old value || data to extend)

In words, it takes the old PCR value and concatenates some data to be extended. The data to be extended is almost always a digest, although the TPM can't enforce this.

The TPM digests the result of the concatenation and stores the resulting digest as the new PCR value.

After reboot, a platform begins with trusted software called the core root of trust measurement (CRTM). The CRTM measures (calculate a digest of) the next software to be run and extends that digest into an even PCR. It then extends that software's configuration data into an odd PCR. This software, perhaps a BIOS, in turn measures and extends the next software, perhaps a master boot record. The measurement chain continues through the early OS kernel code and perhaps further. Security-critical configuration files are also measured.

The net result is that the PCR value represents the history of all measurements extended into it. Because of the one-way nature of a secure digest, there is no way to undo a measurement (to extend the PCR back to a desired value).

As a typical example, the PC Client specification allocates the PCRs as shown in Table 12-1.

Table 12-1. Example PCR Allocation

The security of this process depends on the security of the CRTM. The CRTM, being the first software to run, can't be measured or validated. It's a root of trust. The platform manufacturer can protect the CRTM from attack by making it immutable, putting it in ROM, or otherwise preventing software updates. Because this precludes bug fixes, an alternate method is to use signed code and have the current CRTM validate the signature before updating itself.

The Linux open source Integrity Measurement Architecture (IMA) integrates boot-time measurements into the kernel. An IMA policy determines which software elements are measured. These typically include libraries and executables run under root privilege during boot, as well as Linux configuration files that determine the boot path. It doesn't typically measure user-level applications.

< Prev   CONTENTS   Next >

Related topics