RFC: Change the proxy attestation service to act as a Certificate Authority

[dreemkiller]

As currently implemented, the proxy attestation service follows the following model:

This is working well for us, but it requires that the client be able to perform attestation with the Proxy Attestation Service before establishing the TLS session.

This means the client must perform 2 full round-trips with the Execution Enclave, and 1 full round-trip with the Proxy Attestation Service. It also must have quite a bit of custom code.

#Proposal
I propose modifying the Proxy Attestation Service to act as a Certificate Authority.

When the Root Enclave boots, it performs Native Attestation with the Proxy Attestation Service, which then generates a certificate, signed by a Proxy CA private key. Thus, the generated certificate "roots" back to a Proxy CA Certificate.

Then, when the Execution Enclave boots, it performs attestation (either local or remote, depending upon the properties of the platform) submitting a Certificate Signing Request (CSR) to the Root Enclave. The Root Enclave then authenticates the attestation of the Execution Enclave, and generates an Execution Enclave Certificate, with extensions describing the Execution enclave properties, signed by the Root Enclave private key. Thus, the Execution Enclave Certificate "roots" back to the Proxy CA Certificate.

When the client is configured, it is configured with the Proxy CA Certificate as a trusted certificate. When it wants to connect with the Execution Enclave, it sends a ClientHello (with it's client certificate) and then received a ServerHello message from the Execution Enclave. This ServerHello message contains the certificate chain (Execution Enclave Cert->Root Enclave Cert -> Proxy CA Cert), which the client can then authenticate using it's copy of the Proxy CA Certificate that it trusts.

Variant 1

One possible variant to the above solution is for the Proxy Attestation Service to have multiple Proxy CA Certificates, each used for a different platform profile:

This allows the Proxy Attestation Service to sign the Root Enclave certificate with different keys depending on the characteristics of the execution platform.

Then, when the client is configured, it is configured to trust only Proxy CA Certificate that match the profile that it wants to trust the Execution Enclave on. When it connects, if it receives an Execution Enclave Certificate that does not root back to one it trusts, but nevertheless is signed by one of the Proxy CA Certificate, it will reject it. This allows the client configuration to accept only trusted platforms, and reject untrusted ones.

Variant 2

Another possible variable is for the Proxy Attestation Service to have a "tree of Certs" as below:

Above is shown a tree data structure, showing a hierarchy of certificates. Each of the certificates off of the root represents a feature or set of features that is supported by a target platform (for example, at the first level, Profile A may represent support for encrypted DRAM). The features for one node flow down to their children (for example, Profile AB may represent "DRAM encryption and TrustZone").

When signing the Root Enclave Cert, the Proxy Attestation Service will select the appropriate certificate to sign the Root Enclave Certificate with.

When the client it configured, it is provided with a list of Proxy CA Certificates from the tree that it will trust. If the Execution Enclave Certificate does not root back to one of them, even if it is one of the other certificates in the tree, the client will reject the certificate as untrusted.

Conclusion

At this point, it's not clear which of the above models is best for Veracruz. The work is in progress, but discussions about which one works best are appreciated.