Enclaves Attestation in TLS

Attestation is a central feature of secure enclaves. It offers a cryptographic guarantee of the remote enclave's integrity — the server you're speaking to is exactly as expected.

Attesting a remote server can be difficult to get right, but can be extremely powerful. Evervault Enclaves embed the attestation check within the TLS handshake. This ensures that, when using an Evervault client, you cannot connect to an Enclave that fails attestation.

CA Provisioning

When your Enclave boots within Evervault's Infrastructure for the first time, it generates a key pair to use for terminating TLS. This public key of this pair is then used to create an order with a Trusted CA using the ACME process. Note: the generated private key never leaves the Enclave in plaintext. The Evervault managed process that runs on the host EC2 instance forwards this ACME order to the Trusted CA. The trusted CA then returns an ACME challenge which will be used to prove ownership over the requested domain. The Enclave begins to poll the order status with the Trusted CA, which will eventually resolve to the issued cert.

The ACME challenge, the generated public key, and the encrypted private key are uploaded to an AWS S3 bucket by the host process. This allows us to reuse the same key pair across deployments of your Enclave, and speeds up subsequent deployments.

The Trusted CA then sends an HTTP challenge to the the Enclave's domain. This is routed to an Evervault managed service, which maps the challenge request to the challenge value stored in S3. We serve the challenge in the response to the Trusted CA who then issues an end-entity Certificate for our Enclave.

The order status being polled will then resolve with a link to the location of our newly issued certificate. The Enclave downloads the certificate and can use it to begin terminating TLS. The Enclave also uploads this certificate to S3 via the host process to allow subsequent deployments, or other instances of the Enclave to download and reuse the same certificate.

Performing Attestation from the Client

Now that the Enclave has a trusted TLS Certificate, we can walk through the process of how a client will attest the Enclave.

First, when initializing a client, you provide a set a map of Enclave Names to accepted PCRs. While the implementation differs based on the language being used, the client will begin intermittently polling the Enclave hostnames in the background. The polling requests will hit the publicly available /.well-known/attestation endpoint which returns an Attestation Document. These Attestation Documents are then stored in an in-memory cache which is checked on every Enclave call.

So, when a client is sending a request to an Enclave, it begins by performing a standard TLS handshake:

• Validates the hostname corresponds with the requested domain
• Validates that there is a valid trust chain going back to a trusted Root CA.

The client then attests the connection:

• Checks the Attestation Document Cache for the requested Enclave
• Validates the signature over the Attestation Document against the public AWS Nitro CA.
• Validates that the embedded PCRs match a set of PCRs given to the Client on initialization — the remote Enclave is running the expected service.
• Confirms that the public key of the server cert is embedded within the attestation document

Once all of the above checks have passed, the client can begin sending sensitive data into the Enclave. This guarantees that the data is sent over a TLS connection directly to the enclave which is running the expected code.