Remote Attestation How-to with a Hands-on Experiment in Azure

"I will take you through an example attestation workflow from Azure in this blog. You can try this out in the Azure cloud, which will help you be comfortable with this critical aspect of confidential computing.

Before we delve into the attestation workflow, a quick recap of the different entities that are involved in the attestation workflow.

• Attester: The component which collects the evidence from the Trusted Execution Environment(TEE) and sends requests to the verifier
• Verifier:?The component which accepts TEE evidence from the client, validates it and returns the attestation token to the client. This is the Microsoft Azure Attestation service.
• Relying party: The component which receives the attestation result from the attester and gets a token. This entity also releases a secret (eg. key) on successful attestation.
• Key Management Service:?The component responsible for providing certificates, keys etc

The following diagram depicts an example Azure attestation workflow along with the?generic model?(or pattern) on which it’s built.

Source:?https://docs.microsoft.com/en-in/azure/attestation/workflow

With the above workflow in our mind, let’s go through a working example as described in the following diagram.

Source:?https://github.com/edgelesssys/ego/tree/master/samples/azure_attestation

Here is a brief description of the workflow steps:

1. The server (attester) running in the enclave generates a self-signed certificate and a?report?for remote attestation that includes the certificate’s hash. It thereby binds the certificate to the enclave’s identity.
2. An Attestation Request containing the report and the generated certificate is sent from the server to the?Azure Attestation Provider (Verifier).
3. The?Azure Attestation Provider?validates the report and ensures that the report contains the hash of the self-signed certificate.
4. If the validation succeeds, the Attestation Provider generates a signed JSON Web Token (JWT) and returns the token to the server in the Attestation Response. The token contains the certificate and information for the token verification.
5. The server runs HTTPS and provides the following endpoints to the client: “/token”?returns the JSON Web Token. “/secret”?receives the secret via a query parameter named?s.
6. The client?(relying party)?queries the token signing key from the?Attestation Provider’s OpenID Metadata Endpoint.?TLS is used?to securely get the signing keys.
7. The client verifies the token’s signature and the claims from the token body. If the token is valid and contains the correct report, the identity and integrity of the server is guaranteed. The certificate is extracted from the report.
8. The client?can now establish a secure TLS connection to the enclaved server using the validated certificate and send its secret.

Steps to execute the workflow in Azure

You’ll need an Azure cloud account to execute the following steps.

Create an Azure VM with SGX support

Follow the instructions mentioned in the following link to create an Ubuntu 20.04 VM with SGX support:

Setup and verify OpenEnclave (OE)

Follow the guide here to setup OE and related dependencies for Ubuntu 20.04:

Follow these instructions to install the latest OE SDK (2.17.1 as of this writing)

wget https://download.01.org/intel-sgx/sgx-linux/2.17.1/distro/ubuntu20.04-server/sgx_linux_x64_sdk_2.17.101.1.bin

chmod +x sgx_linux_x64_sdk_2.17.101.1.bin
sudo ./sgx_linux_x64_sdk_2.17.101.1.bin        

Verify the setup by running OE "helloworld" sample by following the instructions mentioned in the link below:

You should see an output like the one shown below:

host/helloworldhost ./enclave/helloworldenc.signed
Hello world from the enclave
Enclave called into host to print: Hello World!
        

Setup Azure attestation demo

I’m using the?ego?demo?available from the following?link.

You can run the demo by following the steps mentioned in the above link.

Additionally, you can also create an “Azure Attestation Provider” by following the instructions mentioned here?and updating the demo code to use the newly created attestation provider.

When using your own attestation provider, remember to change the following lines in the code and replace them with your Attestation URI.

Server:?https://github.com/edgelesssys/ego/blob/master/samples/azure_attestation/server.go#L22

Client:?https://github.com/edgelesssys/ego/blob/master/samples/azure_attestation/ra_client/client.go#L19

Here is a sample run from my setup:

ubuntu@bpradipt-cc-vm:~/ego/samples/azure_attestation$ ./ra_client/client -s `ego signerid public.pem`

EGo v1.0.0 (f1255317ec583ed72947f65d83881a0e46ad1ed8)
?? Loaded server attestation token from https://localhost:8080/token.
? Azure Attestation Token verified.
? SignerID of the report equals the SignerID you passed to the client.
? ProductID verified.
? SecurityVersion verified.
?? Server certificate extracted from token.
?? Sent secret over attested TLS channel.
ubuntu@bpradipt-cc-vm:~/ego/samples/azure_attestation$
ubuntu@bpradipt-cc-vm:~/ego/samples/azure_attestation$ ego sign server
EGo v1.0.0 (f1255317ec583ed72947f65d83881a0e46ad1ed8)
ubuntu@bpradipt-cc-vm:~/ego/samples/azure_attestation$ ego run server
EGo v1.0.0 (f1255317ec583ed72947f65d83881a0e46ad1ed8)
[erthost] loading enclave …
[erthost] entering enclave …
[ego] starting application …
?? Generated Certificate.
?? Created an Microsoft Azure Attestation Token.
?? Token now available under https://0.0.0.0:8080/token
?? Listening on https://0.0.0.0:8080/secret for secrets…
?? 127.0.0.1:54208 sent secret [thisIsTheSecret]        

Trying out the available samples from OpenEnclave or ego is a great way to start experimenting with confidential computing.

Feel free to also refer to a curated list of confidential computing resources that I maintain in the following?project.