Understanding Remote Attestation by taking Azure example
I wrote about remote attestation in confidential computing and what we are doing for confidential containers in the following blog.
In this blog, I will take you through an example attestation workflow from Azure. 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:
- 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.
- An Attestation Request containing the report and the generated certificate is sent from the server to the Azure Attestation Provider (Verifier).
- The Azure Attestation Provider validates the report and ensures that the report contains the hash of the self-signed certificate.
- 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.
- 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.
- 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.
- 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.
- 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
2. Setup and verify OpenEnclave (OE)
Follow the guide here to setup OE and related dependencies for Ubuntu 20.04 — https://github.com/openenclave/openenclave/blob/master/docs/GettingStartedDocs/install_oe_sdk-Ubuntu_20.04.md
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.binchmod +x sgx_linux_x64_sdk_2.17.101.1.binsudo ./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!3. 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 create an “Azure Attestation Provider” by following the instructions mentioned here — https://docs.microsoft.com/en-us/azure/attestation/quickstart-portal and update 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 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 serverEGo v1.0.0 (f1255317ec583ed72947f65d83881a0e46ad1ed8)ubuntu@bpradipt-cc-vm:~/ego/samples/azure_attestation$ ego run serverEGo 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 OE 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.
