PCR Quote in Detail
It's interesting to examine the quote data in detail. Through this data, the reader can understand the security properties of the quote. A quote's structure—the structure that is hashed and signed—contains these fields:
• Magic number TPM_GENERATED: Prevents an attacker from signing arbitrary data with a restricted signing key and claiming later that it was a TPM quote. See Chapter 10 for the interaction between restricted signing keys and TPM_GENERATED.
• Qualified name of the signing key: A key could appear strong but be protected by an ancestor with a weaker algorithm. The qualified name represents the entire ancestry of the key.
• Extra data provided by the caller: This data is typically an anti-replay nonce, which is proof that the quote is current.
• TPM firmware version: Included so that the verifier can decide if it trusts a particular TPM code version.
• TPM clock state: The variable resetCount is of particular importance for the next use case. For privacy, the clock information is obfuscated when signing with a key outside the endorsement hierarchy.  This isn't an issue, because the attester only wants to detect if resetCount changes, not read its actual value.
• The type of attestation structure (a quote, in this case).
• The selection of PCRs included in the quote.
• A digest of those selected PCRs.
a platform is performing financial transactions. a monitoring device performs a quote every 15 minutes to detect changes to the platform software state. however, an attacker sneaks in between quotes, reboots into compromised software, performs an unauthorized transaction, and then reboots the platform back to the trusted state. the next quote will show the same trusted pCr values. however, the resetCount change tells the monitoring software that two unexpected reboots occurred.
Each PCR comes with several attributes. The attributes are defined in the TPM library specification, but which PCR indexes have which attributes is left to the platform-specific specification. Generally, most PCR indexes are assigned by convention to specific software, but a few are unassigned and open for use by applications.
The PCR Reset attribute indicates whether the PCR can be reset using the TPM2_PCR_
Reset command. Typically, the reset value is all zeroes. Most PCRs are not resettable, because this would permit compromised software to set the PCR value to a known good state. Some PCRs are resettable only in a certain locality, corresponding to dynamic root of trust measurement (DRTM) sequences.
The PCR Extend attribute indicates whether the PCR can be extended using the TPM2_PCR_Extend or TPM2_PCR_Event command. Obviously, a PCR that couldn't be extended would be useless, but some can be extended only in some localities.
The PCR Reset attribute via DRTM indicates whether a PCR can be extended through writes directly to the TPM interface, as opposed to the normal TPM command format. These are both platform specific and linked to the particular TPM hardware interface. This attribute typically varies by locality.
All PCRs are reset at reboot when TPM2_Startup is issued with the CLEAR parameter. Most are typically reset to all zeroes, but some can have other values, such as all ones or a value related to the locality at which the startup command was issued.
The No Increment attribute is tied to the TPM2_PolicyPCR command. A policy tied to a PCR is an immediate assertion. The PCR values at the time of the TPM2_PolicyPCR command are extended into the policy session hash. However, a PCR value could change after the immediate assertion, which should normally invalidate the policy session. This invalidation is implemented though a counter that is normally incremented whenever a PCR is changed. The policy session records the value during TPM2_PolicyPCR and then checks it when the session is used. If the count values aren't equal, the TPM knows that a PCR changed, and the policy session use fails.
Note the word normally in the previous paragraph. The TPM specification provides the No Increment attribute. PCRs with this attribute, when changed, don't increment the counter and thus don't invalidate policy sessions in use. Most PCRs don't have this attribute, but the PC Client specification assigns it to a debug PCR and a few reserved for applications.
an application-level pCr may be assigned to measure a virtual machine. this pCr is reset because the Vm is instantiated and extended frequently over the lifetime of the Vm. if each extend invalidated a policy session, the TPM2_PolicyPCR command would be useless.
an application-level pCr may be assigned to secure an audit log. see Chapter 16 for details on this use case. this pCr is reset when the audit log is initialized and is extended as the log is updated. if each extend invalidated a policy session, the TPM2_PolicyPCR command would be useless.
PCR Authorization and Policy
As with other entities, a PCR may have an authorization value or policy. The library specification permits either to be set per PCR or per group of PCRs.
The PC Client TPM has neither. No authorization is required to access the PCR. The rationale is that authorization would increase the boot time, which is often an important parameter.
The first requirement that led to TPM 2.0 was the removal of TPM 1.2's hard-coding of the SHA-1 hash algorithm. Because PCRs are closely tied to hash algorithms, TPM 2.0 theoretically offers many PCR possibilities through the TPM2_PCR_Allocate command.
The key word is theoretically. PCRs can be allocated in banks, with each bank corresponding to a hash algorithm. The command permits PCRs to be allocated in any combination, and a PCR can be assigned to more than one bank and have more than one algorithm. The TPM2_Extend command must now specify not only a PCR index and a digest but also an algorithm. If no index exists with that algorithm, the extend operation is ignored.
So, in theory, software would perform multiple measurements, create multiple digests, and then extend each digest into the appropriate bank. What does the PC Client specification do in practice?
That specification requires only one bank with all PCRs in it. The bank defaults to SHA-1 but can be changed to SHA-256. Although a TPM vendor is free to implement more complicated combinations, we expect most TPMs to be operated as either purely SHA-1 or purely SHA-256. The supporting software knows the TPM's algorithm and measures, digests, and extends accordingly.
Further, we expect that TPMs won't change algorithms very often. If fact, the most likely scenario is that it's shipped with SHA-256 and remains SHA-256 forever, or that it's shipped with SHA-1 and then updates to SHA-256 once as the support software is simultaneously updated.
PCRs have two basic uses. Their value may be reported in a signed attestation quote, permitting a relying party to determine the platform software's trust state. They may be used in a policy to authorize the use of other objects based on PCR values. Whereas TPM 1.2 PCRs were hard-coded to use the SHA-1 algorithm, TPM 2.0 PCRs can use other hash algorithms.
-  For a detailed explanation of this privacy issue, see the “Other Privacy Considerations” section of Chapter 9.