Confidential Computing: Protecting Customer Data in the Cloud

Confidential Computing: Protecting Customer Data in the Cloud

Speaker: Jordan Mecom

Conference: BSidesSF 2025 — April 26-27, 2025, San Francisco

YouTube: Watch on YouTube

Reading time: ~10 minutes

TL;DR

Confidential computing uses hardware-backed Trusted Execution Environments (TEEs) combined with remote attestation to cryptographically prove how customer data is processed — shifting trust away from cloud service providers and into hardware manufacturers like AMD and Intel. Jordan Mecom, a security engineer at Block working on Bitcoin security, delivered a comprehensive technical breakdown of AMD SEV-SNP, AWS Nitro Enclaves, and Intel TDX, explaining how each technology works at the memory encryption and attestation level, and where the technology does and does not provide protection.

Introduction

When a company sends data to a cloud server for processing, it typically has no way to verify what actually happens to that data at runtime. Encryption protects data at rest and in transit, but the moment code executes — the moment data lives in registers and RAM — traditional controls provide no guarantees. Confidential computing changes this by introducing a cryptographically attestable trusted execution environment (TEE) where a third party can verify both what code is running and that it is running in an isolated, hardware-protected context.

Mecom, who focuses on low-level systems, embedded security, and applied cryptography at Block, framed the value proposition clearly: "What if you could cryptographically prove how your data was handled and processed inside a secure enclave isolated from everything else?" The answer to that question has become increasingly practical as AMD, Intel, and AWS have all shipped production confidential computing offerings available in major public clouds today.

The talk covered the complete stack: threat model, building blocks (TEEs and remote attestation), the specific technologies implementing them, and real-world use cases in cryptocurrency, LLMs, healthcare, and traditional payments.

The Threat Model: What Confidential Computing Actually Protects

▶ Watch: Threat model and where confidential computing fits (07:00)

In the traditional cloud model, the tenant (the company running workloads) trusts everything about the cloud service provider (CSP): the operators, the hypervisor, the host OS, and the underlying hardware. Confidential computing shifts trust away from the CSP and toward the hardware manufacturer. The tenant no longer has to trust the CSP's software stack — instead, trust is rooted in AMD's or Intel's silicon, backed by public-key infrastructure chains anyone can verify.

Critically, Mecom was precise about what confidential computing does and does not address:

It helps with:

• Protecting data in use (in RAM and registers while code is executing)
• Reducing trust in the cloud service provider's hypervisor and host OS
• Providing cryptographic attestation that lets customers verify how their data is handled

It does not help with:

• Data at rest — you still need separate encryption
• Data in transit — TLS is still required
• Availability — a CSP can still pull the plug
• Application vulnerabilities — code running inside a TEE is just as exploitable as code outside one
• Side-channel attacks — these remain a concern

"TEEs are not magic," Mecom emphasized. "Just because you put your code in a TEE doesn't mean security vulnerabilities go away."

Building Blocks: TEEs and Remote Attestation

▶ Watch: TEE architectures and remote attestation model (15:00)

A TEE is hardware-isolated execution environment — and TEEs already exist in most smartphones (iOS Secure Enclave, ARM TrustZone, Android Strongbox). Confidential computing brings the same concept to server hardware.

There are three architectural approaches to TEE implementation:

1. Separate chips — the TEE is a physically distinct chip from the main SOC. Clearest isolation, but expensive and slower.
2. Co-processor within the same silicon die — a separate CPU implemented alongside the main processor within the same chip. This is AMD's and Intel's approach for server confidential computing: fast, cost-efficient, and physically isolated enough to protect cryptographic operations.
3. Single processor with privilege separation — ARM TrustZone's "secure world / insecure world" model, common in mobile and embedded devices but not standard in server confidential computing.

Remote attestation is the second building block and what makes confidential computing meaningfully different from simple sandboxing. The attestation process involves four components:

• The TEE — where the workload actually runs
• The attester — hardware and software that cryptographically measures (hashes) the workload at a specific point in time and produces a signed attestation statement
• The verifier — checks the attestation statement against a policy (e.g., "is this signed by AMD's root of trust? does the code hash match what we expect?")
• The relying party — consumes the verifier's yes/no decision and acts accordingly

For a third party to meaningfully verify an attestation, the code being measured must be open-source and reproducible — so anyone can build it, confirm they get the same hash, and then trust that a signed attestation statement proves that exact code is running in a hardware-protected environment.

A key term that appears frequently in confidential computing implementations is key broker: a separate service that receives attestation statements and, if they pass verification, provisions cryptographic keys into the TEE. The key broker must be separate from the environment that produced the attestation to avoid circular trust.

AMD SEV-SNP: The Current Leading Technology

▶ Watch: AMD SEV-SNP deep dive (22:00)

AMD's SEV-SNP (Secure Encrypted Virtualization — Secure Nested Paging) is available today on GCP, AWS, and Azure. Understanding it requires tracing the technology lineage:

Secure Memory Encryption (SME): The foundational layer — it encrypts CPU RAM transparently using an AES engine within the memory controller, communicating keys from AMD's Platform Security Processor (PSP, the dedicated ARM co-processor within the AMD chip). SME uses the XEX cipher mode rather than AES-GCM: XEX introduces a "tweak" based on the physical memory address, meaning the same plaintext at different memory locations produces different ciphertext — without the IV overhead that makes GCM unsuitable for DRAM throughput requirements.

Secure Encrypted Virtualization (SEV): Extends SME to give each virtual machine a unique encryption key. The hypervisor cannot read a guest VM's memory because it lacks the per-VM key — that key lives only between the memory controller and the secure processor. VMs are confidential to each other and to the hypervisor.

SEV-SNP: Fixes SEV's integrity gap. SEV provided confidentiality but no integrity — a hypervisor could tamper with or remap guest memory even without reading it. SEV-SNP adds the Reverse Map Table (RMP), a CPU data structure that associates each 4KB memory page with an owner (the AMD SP, the hypervisor, or a specific VM) and enforces that only the owner can write to that page. A second feature, VM Privilege Levels (VMPLs 0–3), lets a guest VM divide its own address space into different security regions — enabling software-emulated TPMs (vTPMs) unique to each VM.

AWS Nitro Enclaves and Intel TDX

▶ Watch: AWS Nitro Enclaves and Intel TDX (34:00)

AWS Nitro Enclaves provide TEE plus remote attestation within an EC2 instance, carved out as an isolated region with no persistent storage and no network access (communicating with the parent EC2 instance only over a vsock). The attestation chain roots in the Nitro chip — AWS's own custom silicon. Mecom noted an important trust model distinction: unlike AMD or Intel, where trust shifts to a hardware manufacturer separate from the cloud provider, Nitro Enclaves root trust in AWS itself, which is both the hardware vendor and the CSP. "You're not really shifting trust into a different place," he observed.

Nitro Enclaves use an Enclave Image File (EIF) format that supports code signing, giving verifiers more flexible policy options: rather than pinning to a specific code hash, a relying party can trust any attestation signed by a known code-signing authority.

Intel TDX (Trust Domain Extensions) follows a conceptually similar architecture to AMD SEV-SNP but with different implementation details. TDX introduces the concept of a Trust Domain (TD) — an isolated VM protected from the hypervisor. Intel's equivalent of AMD's PSP is its Security Protocol and Model (SEAM) module, which handles attestation. For attestation, TDX uses a software component called a quoting enclave to produce signed quotes that chain back to Intel's attestation service. Intel also provides a cloud-agnostic verification service.

Real-World Applications

▶ Watch: Use cases and industry examples (43:00)

Mecom walked through several categories of real production deployments:

Cryptocurrency and blockchain: Secure key management and transaction signing, where TEE guarantees that private keys never leave the enclave in plaintext.

AI and LLMs: Privacy-preserving inference — a customer can submit sensitive data to an LLM service and receive a cryptographic attestation that the data was processed only by a specific, audited model without being logged or retained. This is an active area of development for companies handling healthcare or financial data through AI systems.

Healthcare and payments: Processing sensitive records or payment data with the ability to prove to regulators and customers that data isolation requirements were met — a compliance capability that traditional cloud deployments cannot offer.

Multi-party computation: Confidential computing enables scenarios where multiple parties contribute private data to a joint computation without any party seeing the others' inputs, with attestation proving the computation was correct.

Notable Quotes

"What if there was some way that you could cryptographically prove how your data was handled and processed inside of a secure enclave isolated from everything else? You can — and that's what confidential computing is all about." — Jordan Mecom (01:30)

"TEEs are not magic. Just because you put your code in a TEE doesn't mean that security vulnerabilities go away. Your code is just as exploitable as it was outside the TEE — it's just a sandboxing mechanism." — Jordan Mecom (18:00)

"The less trusted things you have in the system, the less you have to worry about overall." — Jordan Mecom (11:00)

Key Takeaways

• Confidential computing provides cryptographic proof of how data is processed at runtime — a capability that traditional cloud security controls (TLS, disk encryption, access controls) do not offer.
• AMD SEV-SNP is available today on GCP, AWS, and Azure and provides per-VM memory encryption plus integrity enforcement via the Reverse Map Table. It is the current leading server confidential computing technology.
• Remote attestation requires open-source, reproducible builds — a third party can only meaningfully verify an attestation if they can independently build the code and confirm the hash matches.
• AWS Nitro Enclaves shift trust within AWS, not away from it. For organizations that need trust shifted to a hardware manufacturer independent of their CSP, AMD and Intel offerings are the appropriate choice.
• Confidential computing does not replace other security controls. Application vulnerabilities, side-channel attacks, data-at-rest and in-transit encryption, and availability remain entirely outside the TEE threat model.