Take Zero Trust to the Next Level with Confidential Virtual Machines

• What is Confidential Computing?
• What are SPIFFE/SPIRE?
• SPIRE on AWS
• Adding Confidential Capabilities
• Conclusion

Take Zero Trust to the Next Level with Confidential Virtual Machines

SPIFFE and confidential computing are both security projects that minimize the level of implicit trust that a user needs to place into a computing system. We will show how to combine these approaches to minimize the trust we need to place in public cloud services, by extending the SPIRE node attestation process for AWS, to assert that we are running:

• On an AWS EC2 machine
• In a memory encrypted context

Let's learn how we can achieve this!

What is Confidential Computing?

Confidential computing is a new set of hardware capabilities that enables users to run workloads in memory encrypted environments. Industry-established strategies exist to protect data in transit, such as using transport layer encryption (TLS) (opens in a new tab), and data at rest, for instance using LUKS disk encryption (opens in a new tab). This memory encrypted environment provides you with confidentiality for data in use. Neither other virtual machines, the host machine, nor hypervisor itself can read any data you are processing.

Users can then remotely verify the integrity of those environments using hardware rooted attestation. The attestation report includes information about the actual hardware we are running on, and the software stack that makes up our virtual machine. The report is signed by the CPU itself and verified with a vendor-provided X.509 certificate chain. Users are therefore able to verify the integrity of a machine before placing trust in it.

If you'd like to learn more about this topic, the confidential computing consortium (opens in a new tab), a Linux foundation project, provides a technical analysis (opens in a new tab) of this technology.

In this example we will focus on AMD SEV-SNP (opens in a new tab) capabilities, introduced with AMD EPYC 7003 'Milan' (opens in a new tab). They have been available since April 2023 in AWS (opens in a new tab).

What are SPIFFE/SPIRE?

Secure Production Identity Framework for Everyone (SPIFFE) (opens in a new tab), on the other hand, is a set of open-source standards for securely identifying software systems in dynamic and heterogeneous environments. Solving the hard problem of providing an identity to each system, enabled others to implement valuable features on top, for example the X.509 based identities are utilized to create mutually authenticated and encrypted channels between all workloads. Users are then able to define the minimal amount of permissions required for each workload to talk to another when carrying out its job. This is the foundation of zero trust architectures.

The open source implementation of the SPIFFE standard is SPIRE (opens in a new tab), and is based on a server-agent architecture. The agent requests an identity for the whole node from the server. The agent is subsequently responsible for requesting identities for workloads running on the same node.

When a node wants to receive an identity it needs to authenticate itself, in a process called node attestation (opens in a new tab). This is a three-step process, where:

1. The agent gathers data about itself.
2. The SPIRE server verifies this information,
3. The SPIRE server issues the SPIFFE verifiable identity document (SVID) (opens in a new tab).

You can compare this process to requesting a government-issued identity card. Information about your person such as name, height and eye color are noted, verified and recorded in the final identity document. The degree of trust we can place in the document is determined by the soundness of the data gathering and verification process.

SPIRE on AWS

Let's have a look how this process works in AWS, today:

The agent requests an instance identity document (IID), which is issued and signed by Amazon's instance metadata service (IMDSv2) (opens in a new tab). The server verifies this document and, if verification succeeds, issues the SVID. This document is proof that our agent is a virtual machine running in AWS. It also contains additional information such as the cloud region and AWS account.

Adding Confidential Capabilities

Our goal is now to additionally proof that we are running on confidential computing hardware in a memory encrypted virtual machine. As discussed earlier we can use AMD SEV-SNP (opens in a new tab) to acquire additional platform information directly via the supported hardware. This information is signed with a key rooted inside the CPU itself, and does not require us to place any trust in the cloud provider.

Let's see how we can extend the issuing process:

After passing the initial verification of the IID, the server sends a Nonce, a random number to protect against replay attacks (opens in a new tab), and includes it in the attestation report, issued directly by the AMD CPU. This report can be verified by the server using standard X.509 certificate mechanisms and the certificate chain for Milan processors (opens in a new tab).

By incorporating the information in the attestation report, directly obtained from the hardware, into the SVID, we can enhance the confidence placed in the resulting identity document.

We can now assert two statements are true, our agent runs:

• On an AWS EC2 machine
• In a memory encrypted context

Conclusion

At the time of writing, this seems to be a novel idea. During my research I only found one mention of SPIFFE and Confidential Computing in the SPIRE RFC (opens in a new tab) on Confidential Workloads, but the focus was on Intel SGX, rather than confidential virtual machines.

The actual implementation described in this article is available as fork of SPIRE (opens in a new tab). It is implemented as an extension of the SPIRE included aws_iid plugin. If you are curious and want to take this implementation for a spin, simply:

1. Build the fork (opens in a new tab) using make (opens in a new tab)
2. Configure the aws_iid plugin as described in the official documentation (opens in a new tab).
3. Run the server: spire-server run -config server.conf
4. Run the agent: spire-agent run -config agent.conf
5. List node selectors: spire-server agent show -spiffeID spiffe://control-plane.io/spire/agent/aws_iid/1234567890/eu-west-1/i-01234567890

You will notice that a new selector (aws_iid:measurements) is available, which captures the measurement of the AMD SEV-SNP attestation report.

Just as minor improvements were already contributed back to the community (1 (opens in a new tab), 2 (opens in a new tab), 3 (opens in a new tab)), we are also excited to start a conversation with the SPIFFE/SPIRE community and make use of the results presented here.