Add Oak Functions configuration information to the remote attestation information from the server

[conradgrobler]

Clients might want to validate the specific configuration state of an Oak Functions instance before sending data (e.g. which APIs are enabled etc). To support this, we should include configuration inforamtion as part of the server-provided attestation information.

For now, this can be in an unencrypted/unsinged format as part of the AttestationInfo proto. In future, once we have support for hardware-based attestation we can include this as additional data to the signed attestation report.

As an initial approach, the information should include:

• Hash of the configuration file
• Hash of the compiled web assembly business logic

These sha256 hashes should be measured by the loader when it loads the files from disk.

Potential future enhancements:

• Inclusion proofs for these hashes from rekor.sigstore.dev (optional - provided as an option input file to the loader)
• The raw configuration file, allowing the client to make more sophisticated decisions on whether the trust the server state

[tiziano88]

Thinking more about it, it is probably fine for the server to send the entire configuration (in whatever format) to the client. Even if e.g. the server uses a TOML format and the client has a pre-determined policy that it expects to receive from the server, having the server send the actual file instead of just its hash would make debugging simpler, if nothing else, and config files are expected to be small anyways (as opposed to the Wasm module, which in general may be very large).

[tiziano88]

The main open question is at what point in the remote attestation protocol this information should be sent by the server to the client. If it is sent before the session key is established, then it is prone to MitM, and should not be trusted by the client. It seems that the viable options are:

• exchange it immediately after the session key is established, effectively encrypting it with such session key; to avoid an additional round trip, the server may send this alongside the server identity message. At this point the server already has all the information to derive the session key, and the client will have it as soon as that message is received, so it can then immediately use the session key to decrypt the rest of the message.
• include it as part of additional data that gets signed over by the remote attestation primitive (either HW or SW); this would bind the remote attestation not only to the ephemeral public key of the server, but also to the config file, which may then be exchanged in plaintext in any message.

https://github.com/project-oak/oak/blob/main/oak_functions/proto/server.proto

[ipetr0v]

to avoid an additional round trip, the server may send this alongside the server identity message

The server_identity message is not encrypted, since it's a part of the initial handshake. But it will be signed by the attestation hardware.

[rbehjati]

The server_identity message is not encrypted, since it's a part of the initial handshake. But it will be signed by the attestation hardware.

Yes, and the signature is sufficient since the configuration information is not confidential, and we only care about the integrity.