Number of PCRs
In practice, a TPM contains multiple PCRs. The PC Client platform requires 24 PCRs, and this minimum is expected to be the actual number in PCs. Automotive TPMs may have many more. The platform TPM specification specifies the PCR attributes, and a platform software specification standardizes what measurements go into which PCRs.
The platform specifications may set aside several PCRs for user-level applications. And one PCR (16), the debug PCR, is reserved for testing software. As such, it's resettable without a power cycle.
As described in Chapter 11, TPM 2.0 provides for user-defined NV extend indexes, which are essentially PCRs. They have additional flexibility in that the hash algorithm, password, and policy can be individually set for each index. The metadata (mainly algorithm and authorization) is nonvolatile, whereas the actual data values are likely to be volatile through the use of a hybrid index.
The remainder of this chapter is limited to architecturally defined PCRs.
PCR commands include the following:
• TPM2_PCR_Extend: Likely to be the most-used PCR command. Extends a digest into a PCR.
• TPM2_PCR_Event: Permits the TPM to do the digest and then extend the digest in one operation. The message is limited to 1,024 bytes.
• TPM_PCR_Read: Reads a PCR, which is useful when validating an event log as described later.
• TPM2_PCR_Reset: Resets a PCR, which is useful for some application-defined PCRs that permit this. Most PCRs can't be reset.
• TPM_PCR_Allocate: Assigns digest algorithms to PCRs. This is likely to be done once at most, if the default algorithm is to be changed.
• TPM2_PCR_SetAuthPolicy: Assigns an authorization policy to a PCR group. It isn't required in the PC Client.
• TPM2_PCR_SetAuthValue: Assigns an authorization value to a PCR group. It isn't required in the PC Client.
PCRs for Authorization
Authorization is a common use for PCRs. An entity can have a policy that prevents it from being used unless specific PCRs have specific values. Chapter 14 explains this in detail. The policy can specify a subset of PCRs and a value for each. Unless the PCRs are in this state, the policy is not satisfied and the entity can't be accessed.
full-disk encryption applications are far more secure if a tpm protects the encryption key than if it's stored on the same disk, protected only by a password. first, the tpm hardware has anti-hammering protection (see Chapter 8 for a detailed description of tpm dictionary attack protection), making a brute-force attack on the password impractical. a key protected only by software is far more vulnerable to a weak password. second, a software key stored on disk is far easier to steal. take the disk (or a backup of the disk), and you get the key. When a tpm holds the key, the entire platform, or at least the disk and the motherboard, must be stolen.
sealing permits the key to be protected not only by a password but by a policy. a typical policy locks the key to pCr values (the software state) current at the time of sealing. this assumes that the state at first boot isn't compromised. any preinstalled malware present at first boot would be measured into the pCrs, and thus the key would be sealed to a compromised software state. a less trusting enterprise might have a standard disk image and seal to pCrs representing that image. these pCr values would be precalculated on a presumably more trusted platform. an even more sophisticated enterprise would use tpm2_policyauthorize, and provide several tickets authorizing a set of trusted pCr values. see Chapter 14 for a detailed description of policy authorize and its application to solve the pCr brittleness problem.
although a password could also protect the key, there is a security gain even without a tpm key password. an attacker could boot the platform without supplying a tpm key password but could not log in without the os username and password. the os security protects the data. the attacker could boot an alternative os, say from a live DVD or usB stick rather that from the hard drive, to bypass the os login security. however, this different boot configuration and software would change the pCr values. Because these new pCrs would not match the sealed values, the tpm would not release the decryption key, and the hard drive could not be decrypted.
these are the steps to seal:
1. Construct the policy, a TPM2_PolicyPCR, specifying the pCr values that must be present at the time of the unseal operation.
2. use either of the following (similar to tpm 1.2 seal)
• TPM2_GetRandom() to create the symmetric key external to the tpm
• TPM2_Create(), specifying the symmetric key and the policy to create the sealed object
• or (new tpm 2.0 alternative)
• TPM2_Create(), specifying just the policy, to let the tpm create the symmetric key used in the sealed data object
use the following to unseal:
• TPM2_Load() to load the object
• TPM2_PolicyPCR() to satisfy the sealed object policy
• TPM2_Unseal() to return the symmetric key
similar to the previous use case, a Vpn private key can be locked to pCrs. the tpm permits the use of the Vpn to connect to the enterprise intranet only if the software is in an approved state.
a platform administrator (for example, the it administrator) wishes to grant the end user permission to change a Bios setting, perhaps changing the boot order. the Bios needs the administrator password. the administrator must pass the
privileged-access password to the Bios but doesn't want to reveal the password to the end user.
the administrator seals the password to the pCr state present while the Bios is running (after a reboot). the admin supplies this sealed password to the user at the os level. the user can't unseal the password while the os is running, but the Bios can unseal and use it after a reboot.
these are the steps at the os level:
1. Construct a policy, a TPM2_PolicyPCR specifying that PCR is all zeroes. this pCr will only have this value very early in the boot cycle, when the Crtm passes control to the first part of the Bios.
2. use TPM2_Create(), specifying the password and the policy to create the sealed object. the password is supplied via an encrypted session (see Chapter 17), essentially a secure tunnel into the tpm.
these are the steps at the Bios level:
3. use TPM2_Load() to load the object.
4. use TPM2_PolicyPCR() to satisfy the sealed object policy.
5. use TPM2_Unseal() to return the secret.
A typical use of PCRs for authorization would be to tie the use of an entity to the platform software state, but other uses are possible. For example, a password can be extended into a PCR, thus unlocking access. When access is no longer desired, the PCR can be reset (if permitted) or just extended with some other value.