Attestation is a more advanced use case for PCRs. In a non-TPM platform, remote software can’t usually determine a platform’s software state. If the state is reported through strictly software means, compromised software can simply lie to the remote party.
A TPM attestation offers cryptographic proof of software state. Recall that a measurement can’t be undone. A PCR can’t be rolled back to a previous value. The attestation is a TPM quote: a number of PCR are hashed, and that hash is signed by a TPM key. If the remote party can validate that the signing key came from an authentic TPM, it can be assured that the PCR digest report has not been altered.
We say this is a more advanced use because it’s insufficient to simply validate the signature and the key’s certificate. The party has to next validate that the digest of the PCR matches the reported PCR values. This is straightforward.
Next, the party has to read an event log—a log of all software and other states measured, with their hashes—and validate that the event log matches the PCR values. This is still not too hard; it just involves some math.
The TCG Infrastructure Work Group (IWG) and PC Client Work Group specify the details of the event log format. The Platform Trust Services (PTS) specification from the IWG specifies how to report measurements through Trusted Network Connect (TNC). Standardizing the logging and reporting formats permits standard software to parse and validate the log against the attestation (quote).
The Integrity Measurement Architecture (IMA) for Linux specifies an event-log file format. Typical entries looks like this and includes a PCR index, a template hash, a template name, the file hash, and a hint (untrusted) as to the file name:
10 88da93c09647269545a6471d86baea9e2fa9603f ima
a218e393729e8ae866f9d377da08ef16e97beab8 /usr/lib/systemd/systemd
10 e8e39d9cb0db6842028a1cab18b838d3e89d0209 ima
d9decd04bf4932026a4687b642f2fb871a9dc776 /usr/lib64/ld2.16.so
10 babcdc3f576c949591cc4a30e92a19317dc4b65a ima
028afcc7efdc253bb69cb82bc5dbbc2b1da2652c /etc/ld.so.cache
10 68549deba6003eab25d4befa2075b18a028bc9a1 ima
df2ad0965c21853874a23189f5cd76f015e348f4 /usr/lib64/libselinux.so.1
The hardest part comes next. Through the TPM signed attestation quote, the party knows the platform software state. It now has to decide whether that software state is secure. The party has to match the measurement hashes against a whitelist, potentially requiring cooperation from third-party software providers.
This is the essence of the Trusted Computing concept. PCRs provide a means to trust that a list of software modules indeed reflects the software state of a platform. It doesn’t make any value judgments as to whether that software is secure.
USE CASE: QUOTE
A networking device wants to decide whether to let a client platform connect to a network. It wants to know whether the platform is running fully patched software. The device quotes the TPM PCR and validates the result against a whitelist of patched software modules. If the platform is current, it’s permitted on the network. If not, it’s routed to a patch server but not otherwise permitted network access.
The StrongSwan open source VPN solution can use the TCG TNC standard, combining TPM quotes and a policy to gate access to a VPN.Footnote 1
The Kaspersky antivirus software end user license agreement (EULA) permits the software to report on the files processed, versions of the software, and more. The license permits use of the TPM, if present, to authenticate the report.Footnote 2
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 numberTPM_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.Footnote 3 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.
USE CASE: DETECTING A REBOOT BETWEEN TRANSACTIONS
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.
PCR Attributes
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.
USE CASE: NO INCREMENT ATTRIBUTE PCRS FOR VMS
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.
USE CASE: NO INCREMENT ATTRIBUTE PCRS FOR AUDIT
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.
PCR Algorithms
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.