Veracruz Attestation
Attestation is how Veracruz assures a client (which is providing data, providing a program, or retrieving a result) that the software it is communicating with is the Veracruz runtime executing inside of a supported enclave.
Since Veracruz supports multiple platform types (Intel SGX, Arm TrustZone, and AWS Nitro Enclaves at this time of writing), and each of those platform types has a different protocol for attestation, we have come up with a unique solution for the Veracruz Project.
Before we get into the details of the Veracruz solution, it is helpful to describe the native attestation flows for each of the supported platforms.
The diagram below shows a simplified Intel SGX Attestation protocol.
As the diagram shows, there are 2 full back-and-forths between the client device and the Intel SGX device, and then a full back-and-forth between the client device and the Intel Attestation Service.
In addition, the Client Device must have established credentials with the Intel Attestation Service.
A simplified diagram showing the AWS Nitro Enclave Attestation flow is shown
below.
The client authenticates the attestation document received from the veracruz runtime by authenticating it against the long-lived Nitro Root Attestation Certificate, which is provided to the client.
In theory, the PSA Attestation Token that the client receives from the Veracruz runtime can be authenticated using a PSA Attestation service operated by the platform vendor.
In reality, this infrastructure does not exist at this point, so Veracruz fakes it.
The Veracruz Proxy Attestation flow with an Intel SGX client is shown below.
The Veracruz Proxy Attestation Flow abstracts the platform-dependent parts of the attestation process to allow a single client to attest a veracruz runtime executing on any of the above platforms without having to know the details of the various attestation flows.
Instead, the proxy attestation service handles the native attestation process, and generates a certificate that contains the hash of the client code that is executing on the platform inside an extension in the certificate.
This means that all the client needs to know ahead of time is the hash of the client code that it expects, along with the Proxy Attestation Service's CA certificate.
When the client receives a certificate from software purporting to be the veracruz runtime executing inside of an enclave, the client first authenticates the certificate against the Proxy Attestation Service's CA Certificate to ensure that it is running inside of a supported enclave technology.
It then checks the hash contained in the extension of the received certificate, and compares it against the hash of the runtime that it expects (which is contained inside the global policy file). If it matches, it is now assured that the software it is communicating with is indeed the veracruz runtime, and that it is indeed executing inside of a supported enclave.
After the client receives the "TLS Server Hello" message from the SGX device, it authenticates it's certificate, which is signed by the Proxy Attestation Service. Since the client has previously established trust with the Proxy Attestation Service, it can has the Proxy Attestation Service root CA Certificate in its root CA store. Therefore, the certificate received from the SGX device is also trusted.