Identify how to transfer additional data for remote attestation

[tiziano88]

We should clarify how we expect the remote attestation protocol to convey additional data, for instance inclusion proofs or intermediate certificates necessary to validate the remote attestation report.

Currently it seems that the field below is meant to be used for this purpose, but I am not sure we actually want this data to originate from inside the TEE, since it seems in most cases it will actually originate from the untrusted part of the runtime. Then again, in some cases there may not be a separate untrusted part of the application, so maybe it makes sense to keep it where it is? But in that case we should have a mechanism for provisioning this data at initialization time.

https://github.com/project-oak/oak/blob/37b17805e43511c446140ee5f0fc0cae3ffdb66c/remote_attestation/rust/src/message.rs#L122-L127

@rbehjati WDYT? How do you expect this to work with respect to Transparent Release Process?

cc @ipetr0v @jul-sh @conradgrobler

The outcome of this issue should be either code changes (if we decide to go that way), or some additional documentation on how this is expected to work.

[rbehjati]

Possibly a duplicate of #2535. See also #2248.

[rbehjati]

What to do with additional_info?

We have to clarify what additional_info is for. Is this additional info that the server sends to the client to verify, or does it contain additional info that should be included in the attestation report?

In any case, inclusion proofs (more accurately the endorsement statement and the proof of its inclusion in Rekor (I call these together endorsement evidence)) do not need to be verified as part of the remote attestation handshake, and do not need to be included in the attestation report. Endorsement evidence still needs to be verified prior to sending requests to the server, but not as part of the remote attestation handshake or key exchange protocol. This is also what we agreed on earlier (see #2535). So we should at least update the doc comment to be clear about this.

For configuration info, we have to discuss the process. I believe it only needs to be included as the data that is passed to the AttestationGenerator, and should not be included in additional_info, but I am not sure. @ipetr0v What do you think? Does the protocol for some other reason require the additional_info field, or can we remove it?

How to transfer additional data for remote attestation?

Here is a bit more about my understanding of the attestation and verification behaviour, and some design ideas that will lead to code changes.

We have two flavours of remote attestation. One is offline attestation, the other is interactive attestation.

In offline attestation, provisioning of attested public key (session key) happens non-interactively on the server side. This info is provided to the client out-of-band, possibly via an untrusted service. The untrusted service is good enough for providing endorsement evidence to the client; and is possibly also good enough for providing server configuration info to the client (assuming that the config info is separately included in the attestation report). The untrusted server, could either pack all this information into a single data structure and pass that to the client:

struct GetServerIdentityResponse {
  attested_public_key_info: byte[], // as in offline attestation 
  endorsement_evidence: byte[], // endorsement statement + inclusion proof 
  server_config: byte[], // 
}

Or have separate APIs for serving each piece of information to the client separately:

struct GetSessionKeyResponse {
  attested_public_key_info: byte[], 
}

struct GetEndorsementEvidenceResponse {
  endorsement_evidence: byte[], 
}

struct GetServerConfigurationResponse {
  server_config: byte[],
}

With interactive attestation, we don't have an untrusted service for an out-of-band transfer of public key to the client. In this case, the handshake sequence is performed to generate a pair of shared session keys. There is no need to validate the endorsement evidence prior to generating the session keys. But if the client's policy requires, before sending requests to the server, the client would have to request and validate the endorsement evidence, and the server configuration. We can exchange this information between the server and client similar to the offline attestation case.

On the client-side, we can cover both cases using a state machine. This would allow reusing most of the verification functionality. We can discuss this in more depth separately.