Auditing TPM Commands

As used in the TPM, audit is the process of logging TPM command and response parameters that pass between the host and the TPM. The host is responsible for maintaining the log, which may be in host memory or on disk. An auditor can later use the TPM to attest to the log's integrity (that it has not been altered) and authenticity (that it was logging TPM transactions).

The underlying audit concept is similar to that of attestation using PCRs. The TPM extends command and response parameter hashes into an audit digest. The auditor can later request a signed audit digest and verify the signature and certificate chain. The auditor can then walk their local copy of the audit log to validate its integrity.

Audit always records both command and response parameters and only audits a successful command. The latter requirement vastly simplifies an implementation. ^[1]

This chapter first gives a rationale as to why you may want to audit, then describes the audit types, and finally goes on to the details of the audit mechanism.

Why Audit

Why would an auditor want a certified list of command and response parameters? This section provides several use cases, from auditing a single command to auditing an atomic sequence of commands to auditing a continuous stream of commands.

In the simplest case, the TPM can audit one command. In a sense, this is a generalization of a TPM quote, which signs PCRs. In fact, you could do a quote using audit: start an audit log, read a set of PCRs, end the audit log, and request a signed audit digest. Although it's simpler to use TPM2_Quote for a PCR attestation, it can't be used to quote NV PCRs. ^[2]Audit is the only way to quote an NV PCR.

While there is already a TPM point solution for getting a signature over PCRs, audit provides a slightly more complicated but more flexible facility.

an auditor wants to know the precise tpM properties: manufacturer, firmware revision, and so on. the auditor starts an audit log, runs several

TPM2_GetCapability commands to read the properties of interest, and then

validates the audit log to ensure that the responses are legitimate. the tpM commands are as follows:

• TPM_StartAuthSession: start a session to be used for audit

• TPM2_GetCapability: set the audit attribute, read the manufacturer and firmware version, and keep a log of the results

• TPM2_GetSessionAuditDigest: get a signature over a digest of the log. the auditor uses the signature to verify that the log containing the capabilities has not been tampered with.

these indexes might be used to revoke the use of another entity through the entity's policy. that policy would use the TPM2_PolicyNV command, where the nV index is either a counter or a bit field. Chapter 14 explains the policy use case. here, the caller is concerned that the nV index might not have been updated correctly. For example, the caller wants to ensure that a counter has been incremented or a bit set in a bit field. the caller can audit a read of this index to get a signed digest of its value. in some cases, where the index is authorized using an hMaC, the response hMaC itself provides response integrity. however, if the index is password or policy authorized, or if the caller doesn't have the hMaC key, audit provides the required integrity.

the tpM commands are as follows:

• TPM2_StartAuthSession: start a session to be used for audit

• TPM2_NV_Read: set the session attribute and read the index being used in the policy. the caller keeps an audit log.

• TPM2_GetSessionAuditDigest: get a signature over a digest of the log. the caller uses the signature to verify

that the audit log containing the nV read data has not been tampered with.

as described in Chapter 11, a hybrid extend index can be used to implement pCrs beyond the platform-specified value. these can't be attested to using the TPM2_Quote command, but a signed audit gives equivalent integrity.

the tpM commands are as follows:

• TPM2_StartAuthSession: start a session to be used for auditing.

• TPM2_NV_Read: set the session attribute and read the index being used as a pCr. the caller keeps an audit log.

• TPM2_GetSessionAuditDigest: get a signature over a digest of the log. the caller uses the signature to verify

that the audit log containing the nV pCr value has not been tampered with.

• [1] Historically, TPM 1.2 did not at first have this requirement. This led to many corner cases where the failure was itself due to the audit, where the audit digest was partially updated but then the command failed, and so on. Late in TPM 1.2, the requirement was changed to “only audit successful commands,” and this was carried forward to TPM 2.0.
• [2] See Chapter 11 for an explanation of how to create an NV extend index PCR.