[Question] How to produce an audit log to remotely validate an audit session?

[loicsikidi]

Hi,

I'm currently working on audit session in order to achieve the following goals:

1. remotely attest that a TPM really executed a sequence of commands w/ success
2. (bonus) get the Response of each audited command

After reading a bunch of resources:

• A Practical Guide to TPM 2.0: Chapter 16 Auditing TPM Commands
• TCG TPM 2.0 Part 1: Architecture v184
  • section 18 Audit Session
  • section 33 Command Audit

I've unsterstood the following: we have an untrusted component¹ (outside the TPM) which maintain an audit log w/ TPM command & response parameters and TPM2_GetSessionAuditDigest allows to get an attestation about the digest of the audit session.

Theoretically, from the untrusted audit log a remote party is able to recompute a digest and check if it matches the one produced by TPM2_GetSessionAuditDigest to know if it can be trusted.

go-tpm/tpm2/audit.go

Lines 17 to 53 in bf12020

	// NewAudit initializes a new CommandAudit with the specified hash algorithm.
	func NewAudit(hash TPMIAlgHash) (*CommandAudit, error) {
	h, err := hash.Hash()
	if err != nil {
	return nil, err
	}
	return &CommandAudit{
	hash: hash,
	digest: make([]byte, h.Size()),
	}, nil
	}
	// AuditCommand extends the audit digest with the given command and response.
	// Go Generics do not allow type parameters on methods, otherwise this would be
	// a method on CommandAudit.
	// See https://github.com/golang/go/issues/49085 for more information.
	func AuditCommand[C Command[R, *R], R any](a *CommandAudit, cmd C, rsp *R) error {
	cc := cmd.Command()
	cpHash, err := auditCPHash[R](cc, a.hash, cmd)
	if err != nil {
	return err
	}
	rpHash, err := auditRPHash(cc, a.hash, rsp)
	if err != nil {
	return err
	}
	ha, err := a.hash.Hash()
	if err != nil {
	return err
	}
	h := ha.New()
	h.Write(a.digest)
	h.Write(cpHash)
	h.Write(rpHash)
	a.digest = h.Sum(nil)
	return nil
	}

CommandAudit & AuditCommand functions seems to provide this logic but not in a way that is suitable for my use case.

Ideally would like to obtain this kind of output:

hash(commandA)<DELIMITER>marshal(responseA)
hash(commandB)<DELIMITER>marshal(responseB)
hash(commandC)<DELIMITER>marshal(responseC)
...

1. It would allow to keep command privacy²
2. It would allow the remote party to unmarshal the response to access some values (e.g. GetCapability, etc.)
3. It would allow to reproduce the hash w/ the same logic implemented in AuditCommand (i.e. auditRPHash)

It doesn't seems that Command or/and Response to be marshallable which prevent me to achieve my goals.

Does my request make sense or I miss something obvious?

Thank you in advance for your support!

Footnotes

1. an application ↩

2. I would like to avoid to have access to auth value but maybe that even the marshal version is encrypted ↩

[chrisfenner]

Hi @loicsikidi, I'd like to understand the context of your use-case a bit better before taking a look at your PR.

In your message, you mentioned you'd like output that looks like:

hash(commandA)<DELIMITER>marshal(responseA)
hash(commandB)<DELIMITER>marshal(responseB)
hash(commandC)<DELIMITER>marshal(responseC)
...

CPHash is (unfortunately but for good reasons) a little complicated because of the inclusion of the object Names in the calculation, See TPM 2.0 Part 1, Command Parameter Hash and Response Parameter Hash. So you have to know the Names of the objects involved in order to compute the hashes. So, I'm not sure if hash(commandA) includes this information or if it's somehow implicit.

For purposes of discussion, let's say label the two parties here: Attester (the system with the TPM) and the Verifier (the system checking these audit sessions produced by Attester).

1. It would allow to keep command privacy

I'm not sure what privacy you're talking about here. Are you saying you'd like the Attester to be able to prove it executed certain commands without revealing what those commands were?

2. It would allow the remote party to unmarshal the response to access some values (e.g. GetCapability, etc.)

This part of your use-case makes sense to me. The current design of the Audit object assumes some out-of-band mechanism to tell the Verifier exactly what happened. For example, in an audited GetCapability, you might be able to get Attester and Verifier to agree a-priori what commands should be executed and in what order, but of course the results from the TPM won't always be known ahead of time, so they need to be transmitted to the Verifier.

3. It would allow to reproduce the hash w/ the same logic implemented in AuditCommand (i.e. auditRPHash)

The Audit object reproduces the hash already, I'm not sure what the gap is yet.

[loicsikidi]

Hi @chrisfenner,

Thank you for your feedback.

The current design of the Audit object assumes some out-of-band mechanism to tell the Verifier exactly what happened. For example, in an audited GetCapability, you might be able to get Attester and Verifier to agree a-priori what commands should be executed and in what order, but of course the results from the TPM won't always be known ahead of time, so they need to be transmitted to the Verifier.

Yes, this is exactly what I want to do!

To achieve this goal, it seems to me, that it's a requirement to be able to Marshal/Unmarshal a Command and a Response. This way, the Verifier would be able to replay the audit log by itself (thanks to AuditCommand) to check if the digest is trustworthy.

In my head, the cinematic is as follow:

1. Attester & Verifier agree to a sequence of commands
2. The Attester starts an audit session
3. The Attester runs a sequence of commands
   • in addition an audit log is produced by marshaling each Command/Response
4. The Attester attests the audit log w/ an AK (i.e. TPM2_GetSessionAuditDigest)
5. The Attester sends over the wire the attestation and the audit log to the Verifier
6. The Verifier validates the sequence of commands
   • check attestation's signature
   • unmarshal the audit log to recalculate the digest and compare w/ the one in the attestation
   • check response values, etc.

Do you agree?

[salrashid123]

(this is a bit of a digression...)

not sure if it helps out much because its not about audit sessions but i also needed to know the request commands (not response).

In my case, i wanted to locally authroize a remote tpm to execute a highly specific command (vs audit of that executed command).

I wanted to authorize based on a policy_signed which requires knowing the hash of the commands+nonce+name to authorize

---

anyway, wha ti got was the following uses the name of the key and the discrete commands to authorize, then signs it:

https://github.com/salrashid123/tpm2/blob/master/policy/signed/rsa/main.go#L428-L486

(yes, i need to know locally know the noceTPM (tpm2-software/tpm2-tools#3512)

the other usecase for the plain command (w/o nonce or name) is with TPMPolicy format which critically is just a draft

[chrisfenner]

From a protocol perspective,

Attester & Verifier agree to a sequence of commands

...

The Verifier validates the sequence of commands

• check attestation's signature
• unmarshal the audit log to recalculate the digest and compare w/ the one in the attestation
• check response values, etc.

If the attester and the verifier already agreed to the sequence, why send the entire (possibly large) sequence of marshalled commands and responses? Why not just pass some values to be filled in by the verifier (e.g., "we agreed to call GetCapability 10 times, here are the 10 capability values we got").

BTW I think it makes sense to support generally marshalling and unmarshalling commands and responses. I just want to get a sense for what "success" looks like

[loicsikidi]

Why not just pass some values to be filled in by the verifier (e.g., "we agreed to call GetCapability 10 times, here are the 10 capability values we got").

It's certainly a more elegant way of doing things but I'm a simple man. I said to myself what is the simplest way to produce cpHash and rpHash ¹ on the verifier side ➡️ get a representation of a command/response to be able to call AuditCommand function.

In addition, in my use case the sequence of commands is limited (2, 3 max) and I don't have concerns about space.

Finally, I have the feeling that I'm applying the concepts exposed in A Practical Guide to TPM 2.0:

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 response-parameter 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
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.

Source: Chapter 16 Auditing TPM Commands

I would like to tackle 1.a & 1.b (i.e. #415) in order to achieve this goal but I'm open to your expertise if you think that there is a better path.

Footnotes

1. to get the audit digest ↩

[chrisfenner]

Thanks @loicsikidi, makes sense and I think we are aligned now. There's a preciseness I'd like to capture and confirm from what you just said: I think the most useful thing for you will be the preimage of cpHash and rpHash. That's almost the same as "command and response parameters":

https://trustedcomputinggroup.org/wp-content/uploads/Trusted-Platform-Module-2.0-Library-Part-1-Version-184_pub.pdf#page=103

$\mathit{cpHash} := {\mathbf{H}}_{\mathit{sessionAlg}} (\mathit{commandCode} (\parallel \mathit{Name1} (\parallel \mathit{Name2} (\parallel \mathit{Name3}))){\parallel \mathit{parameters} }) $

$\mathit{rpHash} := {\mathbf{H}}_{\mathit{sessionAlg}} (\mathit{responseCode} \parallel \mathit{commandCode}{\parallel \mathit{parameters} }) $

Do you agree? Would it be helpful to structure it in any way, or just return it as a byte buffer?

[loicsikidi]

Hi @chrisfenner,

Sorry for the late answer...

Do you agree? Would it be helpful to structure it in any way, or just return it as a byte buffer?

1. Yes I totally agree on how cpHash and rpHash are computed!
2. I think a byte buffer is acceptable for now

What is the next step?

[chrisfenner]

I'll take a look at your PR (sorry I haven't had time til now) with this in mind!

[chrisfenner]

Thank you, @loicsikidi for implementing this in #415. I will cut a release to make it easy to pick up a version of go-tpm with this change.