A Technical Analysis of Confidential Computing: Hardware-Based TEEs and the Attestation Imperative

1.0 Executive Summary

Confidential Computing represents a fundamental paradigm shift in information security, addressing the long-standing vulnerability of “data in use.” Where traditional security protects data at rest (storage) and data in transit (network), confidential computing protects data during its most vulnerable state: while it is actively being processed in memory and CPU registers. This is achieved by moving computation from a model of institutional trust in cloud providers to one of cryptographic verification based on hardware.

The core technology enabling this shift is the Trusted Execution Environment (TEE), a hardware-isolated region of the processor that prevents all privileged software—including the host operating system, the hypervisor, and cloud administrators—from viewing or modifying the code and data within it. The market has evolved from first-generation, process-based TEEs (such as Intel® SGX), which require significant application refactoring, to modern, “lift-and-shift” Confidential Virtual Machines (CVMs) like AMD SEV-SNP and Intel® TDX.

This model is entirely dependent on a critical process known as remote attestation. This is the cryptographic mechanism by which a TEE proves its trustworthiness to a remote user before any sensitive data is provisioned. This report finds that while confidential computing provides powerful, provable protection against software-based threats, its entire trust model is predicated on a critical and often-misunderstood “threat model mismatch.”

The primary threat that drives enterprise adoption—a malicious insider or cloud provider with physical access to the hardware—is the exact threat that hardware vendors, including AMD and Intel, have explicitly defined as “out of scope” for their TEE architectures.1 This is not a theoretical gap. As recent (October 2025) academic research demonstrates, this vulnerability can be exploited using low-cost physical interposers to extract the root attestation keys from the CPU itself.3 This allows an attacker to completely forge attestation reports, creating a “perfect” impersonation of a secure TEE and fundamentally breaking the entire confidential computing security promise.4

2.0 The Imperative for Confidential Computing: Protecting Data-in-Use

To understand the value of confidential computing, one must first analyze the foundational “tri-state” model of data security.

2.1 The Tri-State Data Security Model

For decades, data security has focused on two of the three states of data:

1. Data at Rest: This refers to inactive data stored on a physical or logical medium, such as a hard drive, an SSD, or in a database.6 This problem is largely solved via robust technologies like full-disk or database encryption.
2. Data in Transit: This refers to data actively moving from one location to another, such as across the internet or a private network.6 This problem is solved by secure communication protocols like Transport Layer Security (TLS), which provide confidentiality and integrity during transmission.9
3. Data in Use: This is the third, and historically neglected, state. It refers to data that is actively being processed, read, modified, or computed upon within a system’s main memory (RAM) and CPU registers.6

 

2.2 The Data-in-Use Vulnerability Gap

 

The “data-in-use” state is, by definition, the most vulnerable.6 To perform any computation, data must be decrypted and loaded into memory in plaintext. In a traditional computing model, this plaintext data is vulnerable to any software with a sufficient privilege level.14

In a virtualized cloud environment, this threat vector becomes critical. The hypervisor (or Virtual Machine Monitor) and the host operating system, which are managed by the cloud service provider (CSP), have complete, privileged access to the entire system memory. A malicious or compromised administrator, or any malware that compromises the hypervisor, can freely “snoop” the memory of guest virtual machines, stealing sensitive data, intellectual property, and cryptographic keys.14 Software-based protections like Data Loss Prevention (DLP) or simple access controls are insufficient, as they operate at a lower privilege level than the hypervisor and can be trivially bypassed by it.11

 

2.3 Defining Confidential Computing

 

Confidential computing is the technology designed to close this third gap. The Confidential Computing Consortium (CCC), an industry group formed to standardize these technologies, provides the formal definition: “Confidential Computing protects data in use by performing computation in a hardware-based, attested Trusted Execution Environment”.19

This technology provides the third pillar of data security, augmenting encryption at rest and in transit to create a complete, end-to-end protected lifecycle for data.14

 

2.4 The Modern Threat Model: The Untrusted Cloud Provider

 

The “data-in-use” vulnerability, while technically always present, was strategically ignorable in on-premise data centers where the “owner of the machine” was also the “owner of the data.” The advent of cloud computing shattered this model, as users now “routinely run their workloads on computers they don’t own”.16

This separation of infrastructure ownership from data ownership created a new, critical threat model. Confidential computing “flips the focus to protecting the users’ data from whoever owns the machine”.16 The threat model for confidential computing explicitly assumes that the following are untrusted, and potentially malicious:

• The cloud provider’s system administrators.14
• The cloud provider’s hypervisor and host OS.23
• Other tenants on the same shared hardware.14
• Even the cloud provider itself, which may be a business competitor.23

The goal of confidential computing is to replace institutional trust in a CSP’s contractual promises and operational policies with technological assurance—a verifiable, cryptographic proof that data is protected, thereby encouraging the migration of highly sensitive workloads (e.g., in finance, healthcare, and AI) to public cloud environments.14 This shift from “trust” to “verify” is the very definition of a zero-trust architecture, applied for the first time to the cloud infrastructure itself.

 

3.0 Core Components: The Trusted Execution Environment (TEE)

 

The “what” behind confidential computing is the TEE, the hardware-enforced mechanism that creates the secure boundary.

 

3.1 Defining the Trusted Execution Environment (TEE)

 

A TEE is a secure, isolated area of a main processor.25 It is established at the hardware level, using processor-specific mechanisms to partition CPU and memory resources and isolate them from all other software on the system.27

A TEE provides a higher level of security than the main “Rich Execution Environment” (REE)—where the normal, untrusted OS like Windows or Linux runs—and provides more computational functionality than a “Secure Element” (SE), which is typically a simpler co-processor designed only for secure key storage.25 A TEE is capable of running its own lightweight “Trusted OS” and “Trusted Applications” (TAs), which are isolated even from each other.29

 

3.2 The “Secure Enclave”: Clarifying Terminology

 

The terms “Trusted Execution Environment” and “Secure Enclave” are often used interchangeably, leading to market confusion.27 A more precise hierarchy is necessary for technical analysis:

• Trusted Execution Environment (TEE): This is the overarching architectural concept of a hardware-isolated processing environment.
• Secure Enclave: This is a vendor-specific term, not a general one. It can refer to:

1. A dedicated co-processor that implements a TEE, such as Apple’s Secure Enclave Processor (SEP), which is a physically separate processor with its own kernel, memory, and crypto engines.31
2. The instance of isolated memory created by a TEE, such as an “Intel SGX enclave”.25

This report uses TEE to refer to the general concept. The specific, vendor-named instances of isolation (e.g., an “enclave,” “Trust Domain,” or “Realm”) will be referred to by their proper names.

 

3.3 The Three Pillars of TEE Guarantees (per CCC)

 

According to the CCC, a TEE must provide three fundamental security properties 14:

1. Data Confidentiality: Unauthorized entities (e.g., the hypervisor) cannot view the data inside the TEE.14
2. Data Integrity: Unauthorized entities cannot add, remove, or alter the data inside the TEE.14
3. Code Integrity: Unauthorized entities cannot add, remove, or alter the code executing inside the TEE.14

A TEE may also provide Code Confidentiality (preventing the viewing of the code itself, to protect IP), but this is considered an additional, non-mandatory property.22

 

3.4 Foundational Architectural Principles

 

All modern TEEs operate on two shared architectural principles:

1. Hardware-Based Isolation: The TEE is isolated from the REE (main OS) and other TAs using hardware-enforced mechanisms, not software-based policies that a privileged attacker could override.27
2. Transparent Memory Encryption: All code and data belonging to the TEE are stored in an encrypted state in main memory (RAM). This makes the TEE’s memory opaque to the OS, the hypervisor, or even an attacker with physical probes on the memory bus.15 This encrypted memory is decrypted on-the-fly only after it is pulled inside the secure boundary of the CPU package. It is processed in plaintext within the CPU’s registers and caches, and then re-encrypted before being written back to RAM.26 At no point does plaintext data ever leave the CPU die.

The entire security model of a TEE, however, rests on a single, non-cryptographic, institutional assumption: the hardware vendor must be trusted.36 The “hardware root of trust” (HRoT) is a set of private cryptographic keys that are permanently fused into the silicon by Intel, AMD, or Arm during manufacturing.16 All security guarantees are derived from these keys. Therefore, the root of all trust is an institutional belief that the vendor’s hardware design is not flawed and, more critically, not backdoored. This is the foundational, unprovable assumption of the entire TEE model.

 

4.0 Remote Attestation: The Cryptographic Proof of Trust

 

A TEE’s isolation is useless if a user has no way of verifying that their workload is actually running inside one. This verification mechanism, remote attestation, is the central, enabling process of confidential computing.

 

4.1 The Imperative for Attestation

 

Attestation is the process that “establishes trust” in a TEE.40 It functions as a “digital certificate of authenticity” for a remote computing environment.41 The CCC formally added attestation to its definition of confidential computing 39 because, without it, a user has no evidence that their data is protected. It is the “see for themselves” mechanism that moves the model from “trust me” to “prove it to me”.39

It directly answers the critical question: “How can a remote party trust that the TEE is running the intended code on a genuine, uncompromised platform?”.42 Without attestation, there is no way to securely provision secrets or data into the TEE; any data sent would be based on blind trust and could be intercepted by a malicious, non-TEE environment.

 

4.2 The IETF RATS Framework: A Common Language

 

To prevent a fractured ecosystem of incompatible attestation protocols, the industry is standardizing on the Internet Engineering Task Force (IETF) Remote Attestation Procedures (RATS) architecture.44 This framework provides a common, interoperable language for attestation.

The RATS architecture defines three key roles:

1. Attester: The TEE itself (e.g., a Confidential VM) which provides cryptographic “Evidence” about its hardware and software state.44
2. Verifier: A trusted service (e.g., Azure Attestation) that evaluates the Evidence against known-good reference values and policies. If valid, it generates a signed “Attestation Result”.44
3. Relying Party: The end-user or service (e.g., a Key Broker) that consumes the Attestation Result to make a trust decision.44

The CCC and IETF have a complementary relationship: the IETF defines the standards (e.g., RFC 9334) 50, while the CCC hosts open-source implementations of those standards, such as the Veraison project.20

 

4.3 The Attestation Process (Step-by-Step)

 

The attestation flow generally follows these four steps:

1. Measurement: The TEE’s hardware root of trust computes a series of cryptographic hashes (measurements) of its entire Trusted Computing Base (TCB). This includes the firmware, bootloaders, OS kernel, application code, and critical configuration settings.41 These measurements are often stored in secure hardware registers (e.g., Platform Configuration Registers, or PCRs).30
2. Signing (The “Quote”): The TEE uses its unique, hardware-embedded private key—which never leaves the CPU—to digitally sign these measurements, along with a “nonce” (a unique, one-time challenge provided by the Verifier to prevent replay attacks).16 This signed, tamper-proof report is the “attestation quote”.57
3. Verification: The Attester sends this quote to the Verifier.41 The Verifier performs two critical checks:

• It validates the digital signature using the hardware vendor’s (e.g., Intel’s or AMD’s) public key. This confirms the quote came from genuine hardware.
• It parses the TCB measurements (the hashes) from the quote and compares them against a “golden” database of reference values—the known-good hashes of trusted, uncompromised software.49

1. Result: If the quote’s signature is valid and its measurements match the “golden” reference values, the Verifier issues its own cryptographically signed “Attestation Result” (often a JSON Web Token, or JWT) to the Relying Party.45

 

4.4 The Primary Use Case: Secure Key Release

 

This attestation flow is not merely an audit log; it is an active gatekeeper for secrets. Its most critical application is “secure key release,” which is essential for bootstrapping a confidential workload.44

The workflow is as follows:

1. A Confidential VM (the Attester) boots up. Its OS disk and application data are encrypted. To do any work, it needs the decryption key.
2. It contacts a Key Broker Service (KBS) (the Relying Party), which stores the key.44
3. The KBS refuses to release the key and issues a challenge: “Prove to me you are a genuine, uncompromised CVM”.49
4. The CVM generates an attestation quote and sends it to a Verifier (e.g., Microsoft Azure Attestation).
5. The Verifier validates the quote (as described in 4.3) and sends a signed Attestation Result (e.g., “Success, this is a valid SEV-SNP VM running the correct kernel”) to the KBS.49
6. Only if the Attestation Result is successful does the KBS release the decryption key to the CVM, typically over a secure channel established using the TEE’s ephemeral keys.44

This flow cryptographically ensures that sensitive data (like disk encryption keys) is never released to a compromised, untrusted, or non-TEE environment.23

However, this architecture introduces a new, high-level trust dependency. In public cloud environments, the Verifier is almost always a service operated by the cloud provider (e.g., “Azure Attestation” 45, “Google Cloud Attestation” 46). This creates a potential logical conflict: the user must trust the CSP’s attestation service to verify the TEE that is being used to distrust the CSP.

 

5.0 Architectural Deep Dive I: Process-Based TEEs (The First Generation)

 

The first mainstream TEE for data centers was Intel’s Software Guard Extensions (SGX), which introduced a “process-based” isolation model.

 

5.1 Intel Software Guard Extensions (SGX) Architecture

 

SGX provides process-level isolation, meaning it protects specific portions of a single application, not the entire virtual machine.59 It is implemented as a set of new CPU instruction codes 64 that allow a user-space application to request the creation of a secure, isolated memory region called an “enclave”.35

The primary design goal of SGX is to achieve a minimal Trusted Computing Base (TCB). The TCB is limited to only the application code running inside the enclave and the CPU hardware itself.35 All other software—including the operating system, any hypervisors, and all other privileged processes—are explicitly untrusted and are hardware-blocked from accessing the enclave’s memory.35 Enclave memory is protected by a hardware Memory Encryption Engine (MEE), which transparently encrypts and decrypts data as it leaves and enters the CPU package.38

 

5.2 The SGX “Application Partitioning” Model

 

SGX is not a “lift-and-shift” solution. It is often described as “efficient yet difficult to use”.63 Developers cannot simply run existing applications in an enclave. Instead, they must manually partition their application into two parts 70:

1. An Untrusted Component: This portion runs as a normal process and handles all “untrusted” operations, such as OS calls, network I/O, and disk access.
2. A Trusted Component (the Enclave): This portion is loaded into the secure enclave and performs only the most sensitive computations (e.g., processing a cryptographic key, executing a proprietary algorithm).35

While this model provides the smallest possible trust boundary 35, its “difficult” 63 development model has been a major barrier to adoption. The primary strength of SGX—its minimal TCB—is the direct cause of its primary weakness—its poor usability. To achieve that minimal TCB, the application must be fundamentally re-architected. The market’s significant friction in adopting this model is what directly led to the development of the “lift-and-shift” CVM paradigm.

 

5.3 Key Vulnerabilities and Strategic Deprecation

 

SGX’s architectural purity was undermined by a critical, and ultimately fatal, flaw in its threat model. Intel’s original threat model explicitly excluded side-channel attacks.38 This has been described as a “disconnect between vendor marketing and security reality,” as some vendor-aligned material claimed SGX rendered such attacks “useless” 72, while academic and encyclopedic sources confirmed they were out of scope.38

A vast body of academic research subsequently proved that SGX was highly vulnerable to a range of practical side-channel attacks, including:

• Page-based (Controlled-Channel) Attacks: Where the untrusted OS manipulates page faults to observe the enclave’s memory access patterns, allowing an attacker to infer its control flow and data.73
• Cache-based Timing Attacks: Using well-known techniques like Flush+Reload, an attacker can monitor shared CPU caches to determine which memory lines the enclave is accessing, leaking data.67
• Speculative Execution Attacks: Microarchitectural flaws like Spectre allow an attacker to “trick” the CPU’s speculative execution engine into leaking data from within the enclave.67

Partly due to these security challenges and its use in consumer DRM, Intel deprecated SGX on its 11th and 12th-generation client processors. However, it continues development for data center (Xeon) processors, where it is offered as a Platform-as-a-Service (PaaS) solution by cloud providers.38

 

6.0 Architectural Deep Dive II: The Rise of Confidential Virtual Machines (CVMs)

 

The usability challenges of SGX led the market to converge on a new model: the Confidential Virtual Machine (CVM). This model represents a “paradigm shift” 63 by isolating the entire Virtual Machine rather than a small part of an application.62

This coarse-grained approach enables “lift-and-shift” confidentiality, allowing organizations to migrate existing, unmodified applications and entire guest operating systems into a secure TEE.63 In the CVM model, the hypervisor (VMM) is explicitly untrusted, and the TEE hardware primitives are designed to enforce isolation against it.71 This market-driven pivot deliberately trades a larger TCB (the entire guest OS is now “trusted”) for dramatically improved usability.

 

6.1 AMD Secure Encrypted Virtualization (SEV)

 

AMD’s CVM architecture relies on a AMD Secure Processor (AMD-SP), a dedicated Arm TrustZone-based co-processor integrated onto the main CPU die. This SP is separate from the main x86 cores and is responsible for all key management, memory encryption, and attestation functions.59

The evolution of SEV demonstrates a clear “cat-and-mouse game” between AMD and security researchers:

1. SEV (Gen 1): Provided memory confidentiality. It encrypted each VM’s memory with a unique key, preventing the hypervisor from snooping.79 However, it did not encrypt the CPU registers, which leaked data to the hypervisor on every VM “exit” (context switch), nor did it prevent memory integrity attacks.82
2. SEV-ES (Encrypted State): In response, AMD added CPU state confidentiality. This generation encrypts all CPU register contents before passing control to the untrusted hypervisor, plugging the register-leak vulnerability.81
3. SEV-SNP (Secure Nested Paging): Researchers then demonstrated that even with encrypted memory and registers, a malicious hypervisor could still perform integrity attacks like re-mapping memory pages or replaying old copies of data. SEV-SNP, the modern standard, adds memory integrity protection.79 It uses hardware mechanisms to cryptographically prevent these hypervisor-based replay and re-mapping attacks.

 

6.2 Intel Trust Domain Extensions (TDX)

 

TDX is Intel’s CVM solution and the strategic successor to SGX for data center workloads.59 It creates a hardware-isolated CVM known as a “Trust Domain” (TD).86 It uses Intel® Multi-Key Total Memory Encryption (MKTME) to provide confidentiality and integrity, with unique hardware keys for each TD.87

Architecturally, Intel took a fundamentally different approach than AMD. Instead of offloading security to a co-processor, Intel integrated it into the main CPU via a new CPU operation mode called Secure Arbitration Mode (SEAM).59

• SEAM is a new, highly privileged execution mode, existing above the hypervisor (which runs in VMX-root mode).
• This SEAM mode hosts an Intel-provided, digitally signed firmware component called the “TDX Module”.90
• This TDX Module acts as a secure intermediary, managing the TD’s lifecycle and securely handling all VM exits and entries, thereby protecting the TD’s state from the now-untrusted hypervisor.87

 

6.3 Arm Confidential Compute Architecture (CCA)

 

Arm’s CVM solution is the Confidential Compute Architecture (CCA), an evolution of its long-standing TrustZone technology.95

• From TrustZone to CCA: TrustZone (on Armv8-A) partitioned the processor into two worlds: a “Normal World” (for the REE) and a “Secure World” (for the TEE).95
• The “Realm World”: The Armv9-A architecture, which implements CCA, introduces a new execution state called the “Realm World”.56
• Realms: A “Realm” is a new TEE specifically designed to host a CVM, isolating it from the Normal World hypervisor.100 The Realm Management Extension (RME) is the hardware feature that allows the untrusted hypervisor to manage the Realm’s resources (e.g., schedule it, allocate memory) while being hardware-blocked from accessing or modifying its contents.103

A key differentiator for Arm CCA is its reliance on a small, formally verified software component (the Realm Management Monitor, or RMM) to manage the Realm.79 This is a direct philosophical challenge to the “black box” trust model of its competitors.

 

7.0 Comparative Analysis: A Showdown of Modern TEE Architectures

 

The modern TEE market has converged on VM-based isolation as the de facto standard for cloud workloads, driven by the “lift-and-shift” requirement. This has created a fragmented market of competing, incompatible architectures.

A key differentiator among these CVM architectures is the nature of their TCB. Both Intel and AMD rely on complex, “intricate, unverified microcode and firmware” 79 that must be accepted as an opaque “black box.” Arm CCA’s use of a “verified software monitor” 79 is a deliberate architectural choice to provide a provable TCB, aiming to solve this “unverifiable black box” problem.

The performance overhead of CVMs is generally lower and more predictable than that of SGX. SGX suffers from high overhead during “enclave transitions” (switching between the untrusted OS and the trusted enclave), especially for I/O-intensive workloads.61 CVM overhead is primarily the cost of on-the-fly memory encryption. Benchmarks indicate AMD SEV-SNP adds roughly 2-5% overhead for CPU-intensive and 5-10% for memory-intensive workloads, while Intel TDX shows 3-8% for CPU-intensive and 8-15% for memory-intensive, potentially due to its more complex isolation mechanisms.108

The following table provides a comparative analysis of the dominant TEE architectures.

Table 7.1: Comparative Analysis of Modern TEE Architectures

 

Feature	Intel SGX (First Gen)	AMD SEV-SNP (CVM)	Intel TDX (CVM)	Arm CCA (CVM)
Isolation Model	Process-Based (“Enclave”) [59, 62]	VM-Based (“Guest”) [62, 71]	VM-Based (“Trust Domain”) [59, 86]	VM-Based (“Realm”) [100, 103]
Granularity	Fine-Grained (Application Function) [71]	Coarse-Grained (Entire VM) [71]	Coarse-Grained (Entire VM) 86	Coarse-Grained (Entire VM) [103]
“Lift-and-Shift” Support	No (Requires app refactoring) 63	Yes (Unmodified apps/OS) 63	Yes (Unmodified apps/OS) [70, 80]	Yes (Unmodified apps/OS) [100]
Key Mechanism	CPU instructions; MEE [64, 69]	AMD Secure Processor (Arm core) [59]	New CPU Mode (SEAM) + TDX Module [59, 90]	Realm Management Extension (RME) [104, 105]
TCB Size	Smallest (App Code + CPU) [35, 66]	Large (Guest OS + Apps + SP-Firmware) [66, 109]	Large (Guest OS + Apps + TDX Module) [66, 109]	Large (Guest OS + Apps + RMM) [103]
Performance Overhead	High (Enclave transitions, I/O) [71, 106]	Low (~2-10% from memory encryption) [71, 108]	Low-Medium (~3-15% from mem/MMU) 108	Low (Designed for virtualization) 79
Trust Differentiator	Minimal TCB 35	Hardware co-processor isolation [59]	Opaque, Intel-signed SEAM module [59]	Formally verified software monitor (RMM) 79
Known Attack Vector	Side-channels (Cache, Page) [67, 73]	Physical (TEE.Fail) 3	Physical (TEE.Fail) 3	(Emerging; less research)

8.0 The New Frontier: Confidential AI and GPU TEEs

 

The explosive growth of generative AI has created a new, high-stakes market for confidential computing. The computational demands of training and running Large Language Models (LLMs) require massive GPU acceleration.110 This presents a dual security risk: protecting the sensitive training data (e.g., proprietary financial data or protected health information) 112 and protecting the resulting model as high-value intellectual property.112

A CPU-only CVM is insufficient for this task. Any data sent from the CVM to the GPU accelerator for processing would have to cross the PCIe bus in plaintext, where it could be intercepted by the untrusted hypervisor, completely breaking the confidential boundary.116

 

8.1 NVIDIA H100 & Blackwell GPU TEE Architecture

 

To solve this, NVIDIA introduced confidential computing support in its H100 GPU (and forthcoming Blackwell) architecture.111 The GPU itself is a TEE, anchored in its own on-die hardware root of trust.116 This allows for the creation of a “full CPU-to-GPU trust chain” 118 for secure AI workloads.119

 

8.2 The CPU-GPU Secure Channel

 

The NVIDIA GPU TEE must be used in conjunction with a CPU CVM (either AMD SEV-SNP or Intel TDX).116 This creates a complex I/O challenge: the CPU CVM’s hardware is designed to block I/O devices (like the GPU) from directly accessing its private memory (a security feature called DMA protection).116

The solution is an “encrypted bounce buffer”:

1. The NVIDIA driver, running inside the trusted CPU CVM, allocates a buffer in shared (untrusted) memory.116
2. The driver encrypts data and command buffers inside the CVM and places this ciphertext into the bounce buffer.
3. The GPU TEE securely fetches the encrypted data, decrypts it inside its own secure boundary, performs the computation, re-encrypts the result, and places it back in the buffer for the CPU.

This entire process, including the encryption and signing of all CUDA kernels before they cross the PCIe bus, is handled transparently by the trusted CUDA driver and the GPU firmware.116

 

8.3 Composite Attestation (CPU + GPU)

 

This complex, multi-vendor stack requires a correspondingly complex attestation process. A user must verify both the CPU TEE and the GPU TEE.122

1. First, the user attests the CPU CVM (using the SEV-SNP or TDX process).
2. Second, the user must attest the GPU. The driver (inside the CVM) requests an attestation quote from the GPU, which is then verified by the NVIDIA Remote Attestation Service (NRAS).118
3. New services like Intel Trust Authority (ITA) are emerging to simplify this. The ITA client can perform a “composite attestation,” collecting both the Intel TDX evidence and the NVIDIA GPU evidence and returning a single attestation token that verifies the entire CPU+GPU stack.122

This Confidential AI stack, however, is directly targeted by recent physical attacks. The TEE.Fail vulnerability was used to steal the CPU’s attestation key, which in turn allowed attackers to “fake Intel and NVIDIA attestations,” effectively compromising the entire CPU-to-GPU trust chain.3

 

9.0 Real-World Implementation: Confidential Computing in the Cloud

 

The major cloud providers have adopted divergent strategies for implementing these TEE hardware primitives as consumable products.

 

9.1 Microsoft Azure

 

Microsoft has broadly adopted the x86 CVM standard, offering “lift-and-shift” Confidential VMs based on both AMD SEV-SNP and Intel TDX.77 It also continues to offer Intel SGX enclaves as a PaaS solution for application partitioning.77

For verification, Azure provides a unified verifier service called Azure Attestation.125 This service acts as a single point of trust for validating all TEEs supported on the platform (SGX, SEV-SNP, TDX, and TPMs).60 Attestation is integrated directly into the VM boot path: a CVM will fail to boot if its platform attestation fails, providing a strong “fail-closed” guarantee.80 Azure also supports “Guest Attestation,” allowing a user to independently verify the CVM’s integrity after it has booted.126

 

9.2 Google Cloud Platform (GCP)

 

Like Azure, GCP has adopted the CVM model, offering Confidential VMs based on AMD SEV and SEV-SNP.46 As of late 2024, GCP has also rolled out support for Intel TDX and NVIDIA H100 GPUs for Confidential AI workloads.46

GCP offers CVMs as both IaaS and as the foundation for PaaS services like Confidential GKE Nodes (running containers in CVMs) and Confidential Space.46 Confidential Space is a high-level service designed for secure multi-party computation (e.g., data clean rooms).128 GCP’s attestation mechanism, Google Cloud Attestation 46, uses the IETF RATS “passport model” 46 and relies heavily on a virtual Trusted Platform Module (vTPM) to hold and report on platform measurements.59

 

9.3 Amazon Web Services (AWS)

 

AWS has taken a fundamentally different strategic path. It has largely avoided the AMD and Intel CVM standards, opting instead for a proprietary solution built on its own custom hardware: AWS Nitro Enclaves.132

The Nitro Enclave is not a “lift-and-shift” CVM. Its architecture is philosophically closer to Intel SGX (a minimal, single-function TEE) than to a full VM. It is created by the custom Nitro Hypervisor, which isolates CPU and memory from the parent EC2 instance.132 Nitro Enclaves are highly restrictive by design:

• They have no persistent storage.132
• They have no interactive access (e.g., no SSH).132
• They have no external networking.132

The only way to communicate with a Nitro Enclave is via a secure, local VSOCK channel from the parent EC2 instance that created it.132

Attestation is handled by the Nitro Hypervisor itself, which acts as the root of trust and generates a signed attestation document containing PCR hashes of the enclave image.55 The primary use case is direct, attestation-based integration with AWS Key Management Service (KMS). An enclave can present its attestation document to KMS to prove its identity and, if successful, be authorized to perform cryptographic operations.132 This was a clear strategic decision by AWS to maintain full control over its TEE stack, avoid dependency on x86 vendor roadmaps, and enforce a more restrictive, minimal-TCB security model.

 

10.0 Critical Vulnerabilities and the Boundaries of the Threat Model

 

The security guarantees of any TEE are not absolute; they are strictly defined by its threat model. Any attack vector that falls “out of scope” of this model is an accepted, unmitigated risk for the end-user. This is the single most important and least understood aspect of confidential computing.

 

10.1 The “Out of Scope” Culpability

 

Hardware vendors and standards bodies have been explicit about what confidential computing does not protect against.

• CCC Definition: The official CCC threat model excludes “Sophisticated physical attacks” (e.g., invasive chip probing, memory bus interposers) and “Upstream hardware supply-chain attacks”.14
• AMD’s Stance: AMD has repeatedly and explicitly stated that physical attacks are “out of scope of the published threat model for SEV-SNP”.1 In response to disclosures of physical attacks like Voltage Fault Injection 136 and bus interposers 3, AMD’s formal position is that it “does not plan to release any mitigations”.1
• Intel’s Stance: Intel has a similar position. The original SGX threat model famously excluded physical and side-channel attacks.38 While the newer TDX model claims to defend against “limited forms of attacks that use physical access” 90, this has been proven insufficient against sophisticated bus-level attacks.3

 

10.2 The Central Contradiction: The Attacker Model Mismatch

 

This “out of scope” designation creates a critical, paradoxical vulnerability for the entire confidential computing value proposition.

1. The User’s Goal: The primary driver for enterprise adoption of CVMs is to protect sensitive data from the Cloud Service Provider (CSP).14
2. The Attacker’s Capability: The CSP (or a malicious insider, or a state-level actor that has compromised the data center) is the one and only entity in this model that possesses sophisticated, long-term, persistent physical access to the hardware.138
3. The Mismatch: This creates a fundamental “misalignment in the threat model”.140 The exact threat users are defending against (a malicious CSP insider with a screwdriver) is the exact threat the hardware vendors have declared “out of scope.”

This is the central, unmitigated risk of the current confidential computing paradigm. TEEs are designed to protect against a malicious hypervisor, but they do not, by design, protect against the owner of that hypervisor if they choose to escalate to a physical attack.

 

10.3 Physical Attacks in Practice: TEE.Fail

 

This threat is not theoretical. Academic researchers have successfully built and demonstrated low-cost physical memory bus interposer devices for both DDR4 (e.g., Battering RAM, WireTap) 137 and, as of October 2025, for modern DDR5 servers.3

These devices are physically plugged in between the CPU and the DRAM modules to “snoop” all memory traffic.3 They exploit a fundamental weakness in the AES-XTS encryption mode used by both Intel and AMD: it is deterministic.3 This means that if the same block of plaintext is written to memory twice, the resulting ciphertext on the bus will be identical. By observing these patterns, attackers can compare ciphertext blocks and infer data without decryption.4

 

10.4 The Ultimate Consequence: Complete Attestation Forgery

 

The TEE.Fail attack (October 2025) demonstrates the devastating culmination of this vulnerability. The attack moves from passive snooping to active, total compromise.

• The Attack: Researchers used their DDR5 interposer device to monitor the TEE during an attestation signing operation. By observing the ciphertext patterns, they were able to successfully extract the root ECDSA attestation keys directly from Intel’s Provisioning Certification Enclave (PCE)—the most secure part of the chip.3
• The Result: With these stolen private keys, the researchers were able to forge valid TDX attestation quotes that appeared perfectly legitimate. These forged quotes passed verification by Intel’s official DCAP Quote Verification Library and were assigned the highest possible trust level: “UpToDate”.4
• The Impact: This attack represents an existential crisis for the current TEE model. It means a malicious CSP can:

1. Tell a user they are deploying a Confidential VM.3
2. Instead, run the user’s workload on a standard, unencrypted VM.
3. Monitor the workload, steal all data and IP, and even manipulate the results.
4. When the user’s Key Broker Service requests an attestation quote, the attacker simply forges a perfect quote using the stolen keys.
5. The KBS, seeing a valid quote, releases the decryption keys to the malicious environment.

This attack breaks the entire trust model from end to end. The research explicitly notes this forgery extends to faking NVIDIA attestations as well, compromising the “Confidential AI” stack.3

This vulnerability forces the industry back to the very trust model TEEs were designed to replace. If the hardware’s cryptographic proof can be forged via physical access, the only mitigation is perfect physical security. The only entity that can provide this is the CSP. Therefore, in a bitter irony, to use confidential computing to distrust the cloud provider’s software, one must now fully trust that provider’s physical security, operational procedures, and employee screening to be perfect and infallible.

 

11.0 The Ecosystem: Standardization and The Open-Source Horizon

 

In response to this fragmented and high-stakes market, a parallel ecosystem is emerging focused on standardization and open-source alternatives.

 

11.1 The Confidential Computing Consortium (CCC)

 

The CCC is a Linux Foundation project 20 whose mission is to accelerate the adoption of TEE technologies and standards.20 It is a consortium of direct competitors, including hardware vendors (Intel, AMD, Arm), cloud providers (Google, Microsoft, Red Hat), and software developers.19

The CCC’s role is not to create standards itself, but to harmonize them. It works closely with standards bodies like the IETF RATS 20 and hosts open-source projects (like Veraison 52 and RA-TLS 146) to serve as reference implementations. It also publishes white papers to define common terminology.21 This work is inherently slow, as it requires consensus from the very competitors who benefit from proprietary, non-interoperable architectures.149

 

11.2 The Open-Source Frontier: RISC-V TEEs

 

A fundamental alternative to the proprietary, “black box” TEEs from Intel, AMD, and Arm is emerging from the RISC-V ecosystem. RISC-V is an open-source, license-free Instruction Set Architecture (ISA) that allows for full auditability and customization of the hardware itself.150

The RISC-V Confidential Computing SIG is developing open TEE specifications, such as CoVE (Confidential Virtual Machine Extensions).152 Several key open-source projects are leading this charge:

• Keystone: An open-source project to build customizable TEEs for RISC-V.154 It is designed as a flexible framework 156, not a fixed product, that can run on unmodified RISC-V hardware using standard features like Physical Memory Protection (PMP) for isolation.157
• IBM ACE: An effort to build a formally verified TEE for embedded RISC-V systems.160
• OP-TEE: A popular, mature TEE OS (originally from the Arm TrustZone ecosystem) that is being actively ported to RISC-V.157

This ecosystem is bifurcating into two philosophical camps. The incumbents (Intel, AMD) offer powerful but opaque, “unverified” 79 hardware black boxes. The open-source community (RISC-V, Keystone) is building a transparent and auditable alternative from the ground up, directly in response to the “black box” trust problem.

 

12.0 Strategic Recommendations and Concluding Analysis

 

Confidential computing is at a critical inflection point. It is a “revolution” 78 in cloud security, but one that is facing an existential crisis from physical-layer attacks. The following strategic recommendations are for organizations seeking to navigate this volatile but promising landscape.

 

12.1 For Adopters (CISOs/CTOs)

 

1. Align Threat Models Explicitly: Do not deploy TEEs as a “silver bullet.” Your primary threat model (e.g., protection from malicious co-tenants vs. protection from a malicious cloud provider) must be explicitly aligned with the hardware vendor’s “in-scope” threats.
2. Accept the Physical Risk: The “out of scope” physical attack vector 1 is your single greatest unmitigated risk. This risk must be formally accepted by your organization. Your only mitigation is trusting the CSP’s physical data center security.139
3. Treat Attestation as a “Fail-Closed” Control: Do not deploy any confidential workload without a
   robust, automated remote attestation pipeline.80 This pipeline must “fail closed”—
   if attestation fails for any reason (stale-but-valid quote, network error, failed measurement), the
   workload must be immediately terminated and keys revoked.
4. Monitor Academic Research: The TEE.Fail attack 3 proves that vendor security
   bulletins are insufficient. They will not report on “out of scope” attacks. Your security intelligence
   team must actively monitor academic security conferences and archives (e.g., USENIX, arXiv) 67, as this is the only public source of truth for these critical, model-breaking vulnerabilities.
5. Prefer CVMs for Lift-and-Shift, SGX for Granular IP: Use CVMs (SEV-SNP, TDX) for migrating
   existing legacy workloads.63 Use SGX-style enclaves (SGX, Nitro) for new
   applications where you can surgically isolate small, high-value IP (like a single crypto function)
   .35

 

12.2 For Cloud Service Providers (CSPs)

 

1. Physical Security is Your #1 Differentiator: The hardware vendors have punted on physical
   security.1 This makes your data center’s physical access controls 139 the
   single most important layer of the confidential computing stack. This must be your primary
   security control and marketing message.
2. Embrace Verifier Transparency: The “CSP as Verifier” loop 46 is a weak point. Lead the
   market by offering transparent, auditable, and third-party-verifiable attestation services. Provide
   reference hashes for all TCB components, including your paravisor 54, and enable paths for
   on-chain or customer-hosted verification.

 

12.3 Concluding Analysis & Future Outlook

 

Confidential computing is not a “product” to be bought, but a security posture to be

managed. Its adoption requires a CISO to have a deep, critical understanding of its present-day

limitations and to accept that they are entering a cat-and-mouse game being played at the silicon

level.

The TEE.Fail attack has proven the “black box” trust model 79 to be fallible. The short-term industry response will likely involve moving away from deterministic encryption 3 and adding cryptographic freshness checks for memory 137, which will almost certainly incur a significant performance penalty.24

The long-term future, however, must be in verifiable trust. This strongly suggests a market shift away from opaque hardware and toward architectures that embrace transparency and auditability, such as the formally verified monitors pioneered by Arm CCA 79 and IBM 160, and the fully open-source TEEs (like Keystone) 154 running on open hardware (RISC-V).150