Desktop version

Home arrow Computer Science arrow A Practical Guide to TPM 2.0

PCRs for Attestation

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/

10 babcdc3f576c949591cc4a30e92a19317dc4b65a ima 028afcc7efdc253bb69cb82bc5dbbc2b1da2652c /etc/

10 68549deba6003eab25d4befa2075b18a028bc9a1 ima df2ad0965c21853874a23189f5cd76f015e348f4 /usr/lib64/

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.

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. [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. [2]

  • [1]
  • [2]
< Prev   CONTENTS   Next >

Related topics