The beginning of the chapter said that command and response parameter hashes are logged on the host, and the auditor can validate the signed log. This section outlines the required steps:
1. The auditor retrieves a list of command and response parameters from an audit log that the host stored as it executed the commands. From these, command parameter and response parameter hashes are calculated.
a. Fortunately, the command-parameter and responseparameter hash calculations used for audit are exactly the same as those used for authorization. The command and response parameters are serialized (marshaled), and a digest over the resulting byte stream is calculated.
b. For a command, the hash calculation, which requires marshaled parameters, should be straightforward. A TSS would naturally expose command-parameter marshaling to assist in the command-parameter authorization operation. Responses are trickier, because a TSS naturally unmarshals responses but doesn't marshal them. One approach is for the audit log to hold the marshaled response as well as the response parameters. The auditor can use the TSS to unmarshal and then validate those response parameters. If the TSS doesn't expose the unmarshal function, or if the audit log doesn't hold the marshaled response, the auditor has no choice but to write or obtain a marshaling function. Because a TPM naturally has this function, it's possible that it can be copied from a future open source TPM implementation.
c. Either way, at the end of this step, the auditor should have command and response parameter hashes that are cryptographically validated against the command and response parameters.
2. The auditor performs the equivalent of an extend calculation, accumulating each command plus response parameter hash from step 1 into an audit digest.
3. The digital signature is verified. The calculated audit digest from step 2 is validated against the TPM signature and a public key.
4. The auditor walks a certificate chain back to a trusted root certificate, thereby establishing trust in the verification public key.
For continuous auditing, it's likely that the public key will be cached.
in addition to auditing tpM functions, the tpM audit facility can secure an application audit log. the application creates an nV extend index to record its events. each time it records an event, it first extends that event into the nV index. it later gets a signature over the nV index data and uses it to verify that the event log has not been tampered with.
the tpM commands are as follows:
• TPM2_NV_DefineSpace: define a hybrid extend index
• TPM2_NV_Extend: extends the application event while also recording the event in the application event log.
When the application wishes to validate the audit log:
• TPM2_StartAuthSession: starts the audit session
• TPM2_NV_Read: reads the event digest
• TPM2_GetSessionAuditDigest: gets a signature over the nV read data
if available, TPM2_NV_Certify can be used to get a signature over the nV read data, but that command may not be present on all tpMs.