A Practical Guide to Confidential Computing

Recently, I threat-modeled an environment where a sensitive machine would run a customer-supplied agent. This was a challenging exercise, as most threat models begin with separate entities interacting over a network. In this case, however, the customer-supplied agent would execute locally with significant privileges.

During my research, I explored offerings from AWS, Azure, and GCP, as well as hardware implementations by Intel and AMD. My goal was to understand how to mitigate potential risks effectively. What I found, however, was a mountain of marketing jargon that made it challenging to distill practical, actionable information. To help others facing similar challenges, I’ve documented what I learned in hopes of creating the kind of guide I wish I had during my research.

What is Confidential Computing?

Confidential computing protects data while it is in use—unlike encryption, which secures data at rest or in transit. It leverages hardware and software to create isolated environments that shield sensitive workloads from both external and internal threats, including those within the cloud provider’s infrastructure.

I identified three currently offered levels of confidential computing, each offering progressively greater security guarantees, more complex implementations, and targeting significantly different use cases:

1. Trusted Launch (Azure Only)

Trusted Launch ensures that a virtual machine boots only the intended image. It is essentially the cloud-based version of Secure Boot that we know in UEFI; the operating system is cryptographically verified during startup against a set of trusted keys to ensure that the bootloader and operating system kernel have not been modified since being signed. Essential for scenarios where trust in the initial boot environment is critical, this feature protects against rootkits and other malicious firmware modifications.

2. Confidential Virtual Machines (VMs)

AWS Nitro Systems, Azure Confidential VMs, and GCP Confidential VMs fall under this category. These solutions encrypt the control plane (within AWS, this is the side of their network that provisions and manages resources), sign the to ensure hypervisor integrity, encrypt disks (without providing access to AWS operators), and optionally encrypt memory. This ensures that neither the cloud provider nor attackers can access your VM’s memory or control plane data.

Intel and AMD both have their own hardware implementations to support this. While these are not the exact same thing, they have many similarities. AMD has SEV-SNP (Secure Encrypted Virtualization with Secure Nested Paging), and Intel has TDX (Trusted Domain Extensions).

These technologies are comparable and ensure that sensitive data remains encrypted even from the hypervisor or underlying infrastructure. You can use special images provided by the cloud provider or build custom ones based on their images to leverage these features.

3. Application Enclaves

This is where things get exciting. Enclaves, such as AWS Nitro Enclaves and Azure VMs with Application Enclaves, use hardware-based protections, such as Intel SGX (Software Guard Extensions), to isolate portions of an application to protect sensitive data, even from the operating system or root users. These do not have internet access or any persistent storage. The following image from Azure shows this clearly:

Confidential VMs vs Application Enclaves

An enclave is a signed and isolated portion of an application. Even if malicious software compromises the host OS, the enclave’s memory remains protected. This enables scenarios where multiple parties can jointly process sensitive data without exposing it to one another, and data can be processed securely without revealing its contents to the application or cloud provider.

Imagine a scenario where a financial institution wants to analyze encrypted customer data using a third-party application. Instead of anonymizing it, deidentifying it, or pseudo-anonymizing it, with an enclave the application can process the data while keeping it secure and inaccessible to third parties.

Attack Surface for Enclaves

If you’re using enclaves or considering using them, you have already broadly considered how these protections are used and how they sit in the threat model. You will want to continue to fully secure your environment in the normal ways to prevent security issues outside of enclaves.

Beyond threat modeling and environmental controls, the most important aspect is analyzing the enclave itself to make sure it’s properly limited in what it can do, and ensuring the enclave is not capable of doing anything malicious or unintended. This would most likely involve analyzing any functionality that could be abused for data extraction, which would generally include code review, or penetration testing for especially complex enclaves.

Final Thoughts

Confidential computing is a game-changer for scenarios requiring maximum data security in the cloud.

While I haven’t yet implemented these technologies in a cloud environment, I plan to at some point. It looks fairly simple according to the AWS’s guide.

I hope this guide helps others navigate the confusing landscape of confidential computing. I’m sure the cloud providers and hardware vendors will be introducing more offerings soon to make this easier to implement and to support a wide number of scenarios.

Additional Resources

• Confidential Computing in Microsoft Azure – Who do you trust? The attestation section towards the end is a good, detailed summary.
• Protect Data in the Cloud using App Enclaves | Intel SGX & Azure Confidential Compute
• The Security Design of the AWS Nitro System