Background

It’s been 2 years since AWS introduced AWS Nitro Enclaves. Looking back, it was really difficult for developers to build their enclave applications. But today, there are already many tools and cloud platforms which allow us to easily build and use Nitro Enclaves to process sensitive data.

If you are new to AWS Nitro Enclaves, please read my previous blog posts to understand more:

  1. Running Python App on AWS Nitro Enclaves
  2. How to Use AWS Nitro Enclaves Attestation Document

Security is not always inherited

In the following weeks, I’m going to share my thoughts on different open-source tools and cloud platforms that are built on top of AWS Nitro Enclaves, from a security perspective.

There is no shortage of documents telling you how secure the Nitro Enclaves infrastructure is. But building on top of a secure infrastructure doesn’t always mean the application you use is also secure and trustworthy.

So before sharing my thoughts on different tools, I want to talk about chain of trust and what role does attestation document play in this topic.

Trust hierarchy of an enclave application

AWS Nitro Enclaves provides a function called attestation document. It provides you with an assurance that you are interacting with something which is running inside a Nitro Enclave.

There is a caveat: The attestation provides me with the measurement of the application, which is a hash value, but what value should I expect and how trustworthy is this hash value?

This question goes down to how far an end-user can gain visibility along the supply chain of the application.

Chain of trust

This diagram shows an example of the chain of trust: (In the following section, I will use (1), (2), etc. to represent the annotation in the diagram)

Attestation chain of trust

Attestation Document

As (1) shows, the attestation document is generated by the hardware (in Nitro Enclaves, it’s generated by the Nitro Hypervisor), and it includes the measurements (PCR values) of the application image.

Software providers

If a software provider provides an expected PCR value to us, we can use it to compare if this value equals the one in the attestation, to check if we are interacting with a genuine application that the software provider hosts.

In this case, the end-user’s trust ends at (2) because we don’t know what the software does, we can only trust the software provider is running a trustworthy application.

Application code

If the software provider publishes their source code, the end-users can review it, calculate the PCR value themself, and compare it to the attestation PCR value (3).

In this case, the end-user can expect a higher trust level because they can validate the logic of the application and the live one is also running the same logic.

External audit

Of course, not everyone can read source code and sometimes we need to trust external audits.

In our case, we can have an external auditor review the source code, calculate the PCR value and publish it (4). Anyone who trusts the auditor can use the published PCR value to compare with the attestation they get. This is also a way the end-users can assure they are interacting with trustworthy software.

Platform provider - sidecar

Sometimes software providers build their software on top of platforms that provide features like encryption, secret storage, and even enclave provisioning.

These platforms may install sidecar into the enclave, alongside the software code, to achieve their features (e.g. export the attestation document to the platform control plane for validation)

Just like the application code, if we don’t know how these sidecars work, the end-users cannot guarantee the enclave is trustworthy and secure.

For software developers, if their application is being deployed with a platform provider sidecar, the PCR value of the enclave will be different from their application. If the developers don’t have a copy of the sidecar, they have no way to tell if the PCR value from the attestation is expected or not (i.e. The PCR value of Unmodified application + sidecar)

Just like application code, the trust issue of the platform sidecar can be solved by publishing source code (5) and performing external code audit (6).

Platform provider - security control

Some platform provider offer encryption or secret storage features, which touch the sensitive data itself. So whether their security controls support attestation (7) is also important to data security.

E.g. if a provider offers data encryption feature, but their decryption feature doesn’t support attestation document authentication, then how can they guarantee that only the enclave can read the plaintext?

Infrastructure provider

Cloud infrastructure provider is the one who owns the hardware (e.g. AWS hosting the EC2 instance, Azure hosting the Virtual Machine, etc.), so they have the physical control of your data (i.e. the encrypted data inside the memory).

For AWS Nitro Enclaves, because it’s running on the Nitro system, which is also designed by AWS. So in theory, if AWS want, they can forge the attestation document to impersonate a legit enclave application. In this case, we can only trust AWS won’t do it (And I think it’s very unlikely they will breach their compliance and destroy their reputation by doing it).

For Azure, their enclave solution is built on top of Intel SGX technology, so even if Microsoft wants, they cannot compromise the enclave application running on top of SGX. Also, Intel doesn’t have access to the CPU inside the Azure VMs, so they also cannot compromise the data on it. This separation (8) would increase the trust level of an attestation document.

What’s next

This post is to share my thought on the chain of trust behind an attestation document. This is very important when we compare different service offering built on top of AWS Nitro Enclaves because using them means you are building a multi-party solution and you need to know how far the trust can go.

In the coming weeks, I’ll try out different enclave services and share my thought on them.