# Never Decrypted: When Math Is Too Slow, Silicon Keeps the Secret -- Confidential Computing and GPU TEEs
> How trusted execution environments keep a secret in silicon, not math, why attestation is the linchpin of confidential AI, and where the silicon model breaks.
*Published: 2026-07-23*
*Canonical: https://paragmali.com/blog/never-decrypted-when-math-is-too-slow-silicon-keeps-the-secr*
*© Parag Mali. All rights reserved.*
---
Trusted Execution Environments keep a secret the opposite way to the first four parts of this series. Instead of making the computation unreadable with mathematics, they decrypt it *inside* a hardware boundary that the operating system, the hypervisor, the cloud operator, and a person with a screwdriver are all locked out of -- and they prove which chip you are talking to with remote attestation.
That is what makes confidential AI real in 2026: encrypted model plus encrypted data, attested inference on an NVIDIA H100 at under nine percent overhead, where fully homomorphic encryption is orders of magnitude too slow. But the trust did not vanish; it *moved* -- to a vendor, a die, and an unprovable "no side channel" assumption that a fifty-dollar memory interposer broke in 2025. The silicon and math anchors are complements, not rivals: choose per workload, or go hybrid.
## 1. Run the Model in a Cloud That Cannot Read It
A hospital wants to run a proprietary 70-billion-parameter model on patient scans it is legally forbidden to expose. The datacenter belongs to a company neither the hospital nor the model's maker will trust with the plaintext. The model's owner will not ship the weights in the clear. [Fully homomorphic encryption](/blog/never-decrypted-how-fully-homomorphic-encryption-computes-on/) -- the mathematics of Part 1, which computes without ever decrypting -- is, as that part measured, three to six orders of magnitude too slow to answer in real time.
And yet, in 2026, this runs at under ten percent overhead, because the weights and the scans are decrypted *only* inside a GPU that the cloud operator, the hypervisor, and a technician with a screwdriver are all locked out of [@zhu-hopper-benchmark-2024] [@nvidia-h100-cc-ga-2024].
Stop and notice how strange that is. A machine is computing on a model *and* data its own owner may not read -- at GPU speed. For four installments, this series asked one question: how do you compute on data the machine's owner cannot see? Every previous answer was mathematical. Fully homomorphic encryption evaluates a circuit on ciphertext. [Zero-knowledge proofs](/blog/never-decrypted-proving-you-ran-the-computation-without-reve/) convince without revealing. [Secure multi-party computation](/blog/the-trusted-party-nobody-has-to-be-secure-multiparty-computa/) splits a secret so no single party holds it. [Private information retrieval](/blog/never-decrypted-reading-the-row-without-revealing-which-row/) reads a row without disclosing which row. All four buy confidentiality with a hardness assumption and, often, orders of magnitude of overhead.
This capstone follows the field's *other* answer, and it is almost rude in its simplicity: do not make the computation unreadable at all. Make the **hardware itself** refuse to reveal it to anyone but an authorized party you can cryptographically identify.
The protection of data *in use* -- during computation -- in a hardware-based, attested Trusted Execution Environment, against an adversary that explicitly includes privileged system software (the operating system, the hypervisor, the firmware) and the owner of the physical machine. It is the third leg of a stool whose other two legs, encryption at rest and encryption in transit, have existed for decades [@ccc-technical-analysis-v1-3].
Encryption at rest protects the disk. Encryption in transit protects the wire. Neither helps the instant the processor has to *compute*, because a CPU or GPU operates on plaintext -- values must be decrypted into registers and memory to be added, multiplied, or matrix-multiplied. That plaintext sits in DRAM, where the machine's owner can read it: a cloud operator, a compromised hypervisor, a malicious insider, or an attacker on the memory bus. That gap -- data in use -- is the entire reason this field exists.
A hardware-enforced environment that keeps the code and data running inside it *confidential and integrity-protected while executing*, even from privileged software and the physical machine owner. A TEE does not hide the computation the way homomorphic encryption does; it decrypts the data inside a boundary and relies on the silicon to refuse to leak it.
Here is the thesis of this final part, stated as a claim you should doubt until it is earned: **the first four parts keep the secret with mathematics; a TEE keeps it with hardware plus attestation, trading a cryptographic trust model for a silicon one.** Raluca Ada Popa named these two options exactly -- confidential computing or cryptographic computing -- and the honest version of the contrast is not "math versus no math," because a TEE is saturated with cryptography (AES memory encryption, digital-signature attestation). The difference is where trust is *anchored* [@popa-cc-vs-cryptographic-2024].
> **Key idea:** A TEE moves the secret from a mathematical assumption to a silicon one -- and remote attestation is what makes that silicon trust *verifiable* instead of merely *assumed*. Read the entire field through one question: if this breaks, who or what did you have to trust? For the mathematics of Parts 1 to 4, the answer is a hardness assumption. For a TEE, the answer is a vendor, a die, and the assumption that no one has exploited a side channel.
That lens is the spine of everything that follows. Every mechanism in the story -- memory encryption, process enclaves, confidential VMs, GPU confidential computing -- exists to keep your data and model confidential from the machine's owner *because you trust the chip and can prove which chip you are talking to*. The rest of the article earns that generation by generation, and the conclusion sets it beside the math model and crowns no winner.
> **Note:** Carry three things from the earlier parts into this one. First, that "compute on data the owner cannot read" is a real, recurring need, not a thought experiment. Second, that the mathematical schemes buy confidentiality with a hardness assumption and pay in overhead -- FHE most of all. Third, that a proof of correct computation (Part 2's zero-knowledge proofs) is a close cousin of what a TEE calls attestation. Those threads all reconverge here.
So if the answer is not mathematics, what is it -- and where, exactly, did the trust go? To answer that, we have to go back to a heretical question someone asked in the year 2000.
## 2. Trust Only the Chip
In 2000, most security architecture rested on a comfortable assumption: the operating system is on your side. Antivirus ran as a privileged process. Disk encryption trusted the kernel with the key. The threat was *other users*, or malware the OS had not yet caught. Then David Lie, Mark Horowitz, and their collaborators at Stanford and SRI asked a question that sounded almost paranoid: what if the operating system *itself* is the enemy? What if the person who owns the machine is exactly who you are hiding from?
Their answer, presented at ASPLOS 2000, was **XOM** -- eXecute-Only Memory. XOM declared the CPU package the sole trust boundary and treated all off-chip memory and every bus as hostile territory. Code and data lived encrypted in DRAM and were decrypted only inside the processor; the operating system was modeled explicitly as the adversary [@xom-asplos-2000]. This is the intellectual birth of the silicon trust anchor. Everything in this article is a descendant of that one move: shrink the circle of trust until it contains nothing but the chip.
The component a system trusts *by assumption*, because nothing else vouches for it -- the place where the regress of "but who verifies the verifier?" finally stops. For a TEE, the trust anchor is a key placed inside the silicon by the manufacturer. The remote-attestation standard RFC 9334 names this exactly: a verifier trusts "a manufacturer or the manufacturer's hardware" by storing the endorser's key as a trust anchor [@rfc-9334].
Three years later, G. Edward Suh, Srinivas Devadas, and colleagues at MIT built the design that every later TEE quietly inherits. **AEGIS**, presented at ICS 2003, was a single-chip secure processor that added the rigor XOM had only sketched. It gave *tamper-evident* execution by verifying off-chip memory with Merkle-style hash trees, *private tamper-resistant* execution through memory encryption, anti-replay **freshness**, and a secret rooted in a Physical Unclonable Function that even the manufacturer could not clone -- all while tolerating an untrusted operating system [@aegis-ics-2003].
Pay attention to that word **freshness**, because it seeds the irony that runs the length of this article. AEGIS insisted that memory protection needs three properties, not one: confidentiality (an attacker cannot read it), integrity (an attacker cannot silently alter it), and freshness (an attacker cannot replay a stale-but-valid value). Two decades later, the commercial TEEs that conquered the cloud would keep the first and quietly drop the third for speed -- and in 2025, a fifty-dollar device would pry open the exact gap AEGIS had closed in 2003.
AEGIS paid a real, quantifiable price for freshness: a hash or integrity tree costs $O(\log N)$ hash verifications on every protected memory access, where $N$ scales with the size of the protected region. That logarithmic tax on every load and store is precisely the overhead later server TEEs refused to pay at whole-VM scale -- the design decision that made them fast and made them breakable.
timeline
title The silicon trust anchor moves outward, 2000 to 2025
2000 : XOM, the chip is the only trust boundary
2003 : AEGIS, memory encryption plus integrity and freshness
2004 : ARM TrustZone secure world : Direct Anonymous Attestation in the TPM
2013 : Intel SGX process enclaves plus remote attestation
2016 : AMD SEV, encrypt the whole VM
2020 : AMD SEV-SNP adds integrity and VCEK attestation
2021 : Intel TDX trust domains
2023 : RFC 9334 standardizes attestation : NVIDIA H100 GPU CC preview
2024 : H100 GPU CC general availability, confidential AI ships
2025 : Battering RAM, WireTap, TEE.Fail break attestation physically
AEGIS and XOM proved the model sound -- and, commercially, a dead letter in its original form. Both required new, non-commodity silicon; both imposed that logarithmic integrity-tree overhead on general workloads; and, most damning, neither shipped a usable software model or a way for a *remote* party to check that a genuine secure processor was running the expected code. They were a correct architecture with no product [@aegis-retrospective]. The chip-only boundary was right, but it had to reach mass-market silicon, with a workable programming model and a way to prove itself across the internet.
The last of those requirements was quietly being invented in parallel. In 2003 and 2004, the Trusted Computing Group standardized **measured boot** -- hashing each stage of the boot process into a tamper-resistant TPM register, so a machine could later attest "these are the exact bits that booted" [@tcg-tpm-main-1-2].
And in 2004, Ernie Brickell, Jan Camenisch, and Liqun Chen published **[Direct Anonymous Attestation](/blog/direct-anonymous-attestation-the-zero-knowledge-proof-alread/)**, letting a TPM prove it was genuine to a remote verifier *without revealing which* TPM -- a zero-knowledge-style protocol adopted into TPM 1.2 [@daa-eprint-2004] [@daa-ibm-listing]. That is the seed of remote attestation: proving which code is running to someone who cannot see your datacenter.
Direct Anonymous Attestation put a zero-knowledge proof inside every compliant TPM two decades ago. The companion article in this series on DAA traces that lineage in full; the point to hold here is that "prove which chip and which code, without over-revealing" is old, and it is the exact primitive a TEE needs to convert local isolation into remote trust.
The same year measured boot and DAA were maturing, ARM shipped the first hardware isolation that would reach billions of devices [@genode-trustzone]. It answered "trust only the chip" for a phone. It would turn out to be the wrong shape for a cloud -- which is where the anchor has to move next.
## 3. Dual Worlds, Process Enclaves, and the First Cracks
The model shipped twice, in two very different shapes, and both started to crack.
ARM's **TrustZone**, introduced around 2003 to 2004, split the system-on-chip into two worlds -- a **Secure World** and a **Normal World** -- separated by a single processor-state bit propagated across the bus, so every memory and peripheral access is tagged secure or non-secure. One privileged Secure World, a small trusted OS and its apps, runs beside the rich Normal World, with a Secure Monitor Call the only gate [@genode-trustzone]. It was the first hardware isolation to ship in commodity silicon at scale, and it still guards the keys, biometrics, and payment secrets in billions of phones.
But a phone has one owner. A cloud has thousands of mutually distrusting tenants, and TrustZone offers *exactly one* coarse Secure World, owned by the platform operator [@trustzone-survey-2019]. You cannot hand each cloud customer an environment the provider itself cannot read, because the provider owns that single Secure World and holds its keys. There is no per-tenant confidential VM, and originally no per-tenant memory encryption at all -- isolation came from address-space partitioning, not an encryption engine.
ARM later admitted the gap, adding a separate confidential-VM world in its Confidential Compute Architecture to give each tenant an isolated domain [@sok-tz-cca-2024]. TrustZone was the right model for a device and the wrong one for a cloud.
Intel's **SGX**, defined in two companion papers at HASP 2013, answered with the opposite granularity: not one big world but many tiny ones.
A per-process, hardware-encrypted region of memory whose contents are protected from the operating system, the hypervisor, and the BIOS. Code and data inside an SGX enclave are decrypted only on-die; an enclave can be *remotely attested* (it can prove to a third party which code it is running) and can *seal* secrets to a CPU-derived key for storage. The trust base is minimal: your enclave and the CPU, and explicitly not the operating system.
SGX made "run a piece of code the OS cannot read" real at mass-market scale, and it shipped the first production remote attestation of application-enclave code, originally using EPID group signatures [@sgx-hasp-2013]. For one kind of workload -- a small, well-defined secret kernel -- it was exactly right. Signal's contact-discovery service, examined in this series' secure-multiparty-computation installment, still runs inside SGX enclaves [@signal-cdsi]. It is the natural bridge between the two trust models: a reminder that a TEE is often the practical way to deploy a cryptographic protocol.
Then the cracks. The first was a performance cliff. On client parts, the Enclave Page Cache was reserved at 128 MB with only about 90 to 96 MB usable; exceed it and SGX pages enclave memory out to normal RAM with encryption and integrity checks, at a **5 to 100 times slowdown** once the working set spills over [@vault-asplos-2018]. The second was ergonomic: you had to refactor an application into trusted and untrusted halves, a punishing model compared with "run my existing program, but private."
The third crack was the one that mattered, and it kept widening. Starting in 2018, a stacking parade of attacks showed that both an enclave's contents *and its attestation root* were extractable.
An attack that recovers secrets not by breaking the cryptography but by observing a physical or microarchitectural byproduct of the computation -- timing, cache state, speculative execution, power, or the electrical signals on a memory bus. Two sub-classes recur throughout this article and must be kept distinct: *microarchitectural* side channels (speculative-execution and cache attacks such as Foreshadow, SgxPectre, and AEPIC) that need only code on the machine, and *physical* side channels (memory-bus interposers such as the 2025 attacks) that need a device between the chip and its DRAM.
**Foreshadow**, in 2018, used the L1 Terminal Fault speculative-execution flaw to transiently read SGX enclave memory out of the L1 cache -- including, critically, the machine's private attestation key [@foreshadow-l1tf]. **SgxPectre** brought Spectre-style speculative gadgets inside the enclave to leak its secrets [@sgxpectre-2018].
Then the attacks reached the root. **SGAxe**, in 2020, extracted the machine's SGX attestation key from the architectural enclaves, letting an attacker forge quotes indistinguishable from genuine ones and impersonate any SGX machine to a verifier [@sgaxe-2020]. **AEPIC Leak**, in 2022, was the first *architectural* (non-speculative) x86 data leak: an uninitialized read of APIC MMIO registers dumped stale physical-memory contents -- including enclave secrets -- bypassing every speculative-execution mitigation [@aepic-leak-2022].
Foreshadow demonstrated how speculative execution can be exploited for reading the contents of SGX-protected memory as well as extracting the machine's private attestation key.
That last clause is the whole game. Reading one enclave's data is a local break. Extracting the *attestation key* is a systemic one: it lets you forge the proof that any enclave is genuine. Hold that distinction; it returns in 2025 with a screwdriver instead of a speculative gadget.
> **Note:** A TEE does not make the computation mathematically unreadable the way FHE does. It *decrypts inside a boundary* and depends on the chip to refuse to reveal it. The secret did not become unreadable; the **trust moved** -- from a hardness assumption to "trust this silicon, and prove which silicon." Once you feel that click, every remaining section is just a question of where the anchor moves next, and where it can be pried loose.
If a process enclave is too small, too hard to port, and its attestation root is extractable, where does the anchor move? Outward again -- this time around the entire virtual machine.
## 4. The Anchor Moves Outward, Generation by Generation
Line up the five generations and one motion becomes visible: the trust anchor marches outward -- chip, to one world, to many enclaves, to a whole VM, to a whole VM plus its GPU -- and every step is forced by the previous generation's concrete failure.
flowchart LR
G0["Gen 0: the chip (XOM, AEGIS)"] -->|"no product, no remote attestation"| G1["Gen 1: one secure world (TrustZone)"]
G1 -->|"single operator-owned world, not multi-tenant"| G2["Gen 2: many enclaves (SGX)"]
G2 -->|"tiny page cache, app rewrite, attestation-key leaks"| G3["Gen 3: whole VM (SEV-SNP, TDX)"]
G3 -->|"the GPU where AI runs is outside the boundary"| G4["Gen 4: whole VM plus GPU (H100 CC)"]
Generations 0, 1, and 2 we have met: the academic secure processors that proved the model, TrustZone's single operator-owned world, and SGX's fragile fleet of enclaves. The generation that actually conquered the cloud is the third, and it has an internal story worth telling because it re-enacts, in miniature, the whole arc of the field.
A virtual machine whose entire memory is encrypted with a key held by an on-die security processor, and whose isolation is enforced against the hypervisor and the cloud operator -- so an *unmodified* guest operating system and its applications can be "lifted and shifted" into a confidential environment with no code changes. AMD SEV-SNP and Intel TDX are the two cloud-dominant confidential-VM technologies.
AMD's line began in 2016 with **SME** (whole-DRAM encryption via an inline AES engine in the memory controller) and **SEV** (Secure Encrypted Virtualization), which gave each VM a distinct key so a compromised hypervisor could not read guest memory. David Kaplan presented the architecture at USENIX Security that year [@amd-sme-sev-wp-2016] [@kaplan-usenixsec16]. It was the anchor jumping from a process to a whole machine.
But the first version leaked. Plain SEV left the guest's CPU registers in plaintext: on every VMEXIT, the hypervisor saved the register state -- the VMCB -- in the clear, exposing in-use secrets and permitting tampering. **SEV-ES** ("Encrypted State"), in 2017, closed that by encrypting the register state at VMEXIT [@amd-sev-overview] [@suse-sev-es-guide]. One leak found, one leak patched.
The deeper problem was structural, and it is the one AEGIS had warned about in 2003. SEV and SEV-ES encrypted memory *deterministically and without authentication* -- no integrity, no freshness.
The encryption of DRAM contents so that data is ciphertext outside the processor. Server TEEs key it on the physical address and make it *deterministic*: the same plaintext at the same location always yields the same ciphertext. Intel TDX uses AES-XTS; AMD SEV uses an XEX-mode tweak (XTS without the ciphertext-stealing step). Either way it is fast and free of per-write bookkeeping, but provides confidentiality only -- it leaks whether two ciphertexts are equal, and it cannot detect an attacker who records and later replays a valid ciphertext.
Deterministic, unauthenticated encryption is a seam, and researchers pried at it. **CrossLine** (2020) broke SEV's "security-by-crash" memory isolation [@crossline-2020]. **CipherLeaks** (2021) recovered secrets straight out of the deterministic ciphertext of the register-save area, through what its authors named the ciphertext side channel -- no speculation required [@cipherleaks-2021].
The vendors answered with integrity. AMD's **SEV-SNP** (2020) added rollback protection through the **Reverse Map Table**, which gives every physical page a validated owner, plus firmware-signed attestation rooted in a per-chip key, the VCEK [@amd-sev-snp-wp-2020]. Intel's **TDX** (2021) followed: Trust Domains isolated from the hypervisor by a CPU-attested TDX module in a new SEAM mode, with per-domain AES-XTS memory encryption and Intel-signed attestation [@intel-tdx-overview]. Both deliver near-native speed -- typically single-digit-percent overhead -- across a whole multi-gigabyte VM, with no tiny-cache cliff and no application rewrite [@kaplan-cacm-2023].
Notice what SEV-SNP restored and what it did not. It restored *integrity* through the Reverse Map Table. But the underlying memory *encryption* stayed deterministic and unauthenticated at the DRAM bus -- the freshness gap AEGIS closed in 2003 remained open, a design decision traded for whole-server speed. Remember that; Section 9 collects the bill.
The third generation was mature, deployed, and, for the workload that now defines the decade, insufficient. A CPU confidential VM protects data in *CPU* DRAM. But the moment a tensor crosses the PCIe bus to a GPU, it is plaintext in GPU VRAM -- readable by the operator, the hypervisor, or a DMA attack. And modern AI does not run on the CPU. It runs on the GPU. The whole-VM anchor, however polished, could not deliver confidential AI by itself, because the accelerator where the computation actually happens sat *outside* the boundary [@nvidia-h100-cc-preview-2023].
So the anchor took its final step. NVIDIA's **H100**, the Hopper generation, became the first GPU to support confidential computing -- private preview in July 2023, general availability with the CUDA 12.4 data-center driver in early 2024, in single-GPU passthrough mode [@nvidia-h100-cc-ga-2024]. It extends the encrypted, attested boundary across PCIe and into the GPU. VRAM is encrypted with keys held in an on-die root of trust and never exposed to host software; the only CPU-to-GPU data path is an AES-GCM-protected bounce buffer; and the link itself is established and protected with the SPDM device-security protocol [@nvidia-hcc-whitepaper] [@dmtf-spdm-dsp0274].
Composed with a CPU confidential VM, this keeps a proprietary model's weights and a user's data confidential *through inference and training on the GPU*. Blackwell extends it again, bringing GPU-to-GPU NVLink traffic inside the boundary through Protected PCIe and TEE-I/O, so an eight-GPU or rack-scale job runs as one confidential domain [@nvidia-secure-ai-blackwell-wp].
Here is the whole lineage on one axis.
| Generation | Era | Trust boundary | Integrity or freshness at the DRAM bus | Attestation root | Status |
|---|---|---|---|---|---|
| Gen 0: XOM, AEGIS | 2000, 2003 | The chip package | Full integrity plus freshness trees | None (research) | Never shipped at scale |
| Gen 1: ARM TrustZone | 2003 to 2004 | One secure world | None originally | Platform-owner keys | Active in mobile |
| Gen 2: Intel SGX | 2013 | Process enclave | Integrity tree over a small cache | Intel EPID, later DCAP | Niche, minimal-TCB |
| Gen 3: SEV-SNP, TDX | 2020, 2021 | Whole VM | Integrity (RMP); deterministic, unauthenticated | AMD VCEK, Intel PCS | Active, cloud default |
| Gen 4: H100 Hopper CC | 2023 to 2024 | Whole VM plus GPU | AES-GCM on the link, vendor-protected VRAM | NVIDIA NRAS plus CPU root | Active, confidential AI |
Read down the "attestation root" column and you can see the entire trust model at a glance: every generation, no matter how far outward the boundary moves, ultimately trusts a key placed in the silicon by a vendor. That invariant is the article's quiet drumbeat. But isolation inside the box is worthless to someone on the other side of the planet unless they can *prove* which box they are talking to. How?
## 5. Remote Attestation: The Linchpin
Everything so far is local. A chip encrypts its memory and isolates a workload from the operator. But picture yourself as the hospital in the opening scene, about to send an encrypted model key into a datacenter you do not control. From where you stand, a genuine confidential VM and an ordinary VM *lying about being one* look identical. Both accept your connection. Both claim to be secure. Isolation you cannot verify is worth nothing, because you cannot tell it apart from its absence.
The single idea that converts "trust me" into "verify me" is hardware-rooted remote attestation. It is the load-bearing move of the entire field, and it is what discharges the "plus attestation" in this article's thesis.
A procedure by which a TEE proves to a remote party what code and configuration it is running, rooted in a hardware-held key. The flow is always the same shape: the environment is *measured* (hashed), the measurement is packaged into a hardware-signed *quote*, a *verifier* checks that signature against a trusted vendor root, and only an environment that matches the expected measurement is treated as trustworthy [@rfc-9334].
The modern vocabulary is standardized by IETF **RFC 9334**, the Remote Attestation Procedures (RATS) architecture, which defines three roles: the **Attester** produces Evidence, the **Verifier** appraises that Evidence and produces Attestation Results, and the **Relying Party** acts on the results. Tellingly, RFC 9334 frames the whole model in the language this article has been using: the Verifier trusts "a manufacturer or the manufacturer's hardware" by storing the endorser's key as a **trust anchor** (Section 7.4). The standard itself names the thing that moves [@rfc-9334].
The hardware-signed report a TEE emits as proof of its state -- the measurement of its code and configuration, signed by a key that chains to the silicon vendor's root. In RATS terms it is *Evidence*; in AMD, Intel, and NVIDIA tooling it is usually called a *quote*. Its security rests entirely on the signing key staying secret: a quote is only as trustworthy as the key that signed it.
sequenceDiagram
participant A as Attester (the TEE)
participant V as Verifier
participant R as Relying Party (key service)
A->>A: Measure code and configuration
A->>V: Send signed Evidence (the quote)
V->>V: Check signature against the vendor root
V-->>R: Return Attestation Result, trustworthy or not
R->>R: Compare the measurement to the expected value
R-->>A: Release the secret only on a match
The final step -- release the secret only on a match -- has a name in production systems.
A policy that gates the release of a secret (for example, the key that decrypts model weights or patient data) on a *verified* attestation. The key-management service hands over the key only when the presented quote verifies against the correct vendor root and the measurement equals the expected, approved value. It is what turns an abstract "the environment is trustworthy" into a concrete "and therefore you may now have the key."
For ordinary confidential computing, one attestation suffices: the CPU confidential VM proves itself against its vendor root (AMD's VCEK for SEV-SNP, Intel's PCS/DCAP for TDX), and Secure Key Release hands over the key [@amd-sev-snp-wp-2020] [@intel-tdx-overview]. Confidential AI needs a decisive twist, because there are now *two* pieces of silicon in the boundary -- the CPU and the GPU -- provisioned by *two different vendors*, and each must prove itself against its *own* root.
flowchart TD
CPU["CPU confidential VM"] -->|"CVM evidence"| MAA["Verifier composes both (Azure MAA)"]
GPU["NVIDIA H100 GPU"] -->|"GPU evidence"| MAA
VCEK["AMD VCEK root"] -.->|"verifies CPU"| MAA
NRAS["NVIDIA NRAS root"] -.->|"verifies GPU"| MAA
MAA -->|"one combined token"| SKR["Secure Key Release"]
SKR -->|"model and data keys"| APP["Attested workload"]
In Azure's deployed confidential-AI pipeline, Microsoft Azure Attestation **composes** the AMD confidential-VM evidence and the NVIDIA GPU evidence into a single token -- but the GPU attestation is signed by **NVIDIA's Remote Attestation Service (NRAS)**, not by Azure [@azure-attestation-overview] [@nvidia-nvtrust-docs]. Two signatures, two roots, one composed result.
The procurement-critical mistake -- and it is a real one -- is to verify the CPU VM and *assume* the GPU is covered. The trust boundary "spans confidential VM on the CPU and attached GPU," and each half has its own chain of custody back to a different manufacturer [@azure-gpu-options]. The NCCadsH100v5 virtual machine size, an AMD SEV-SNP EPYC Genoa VM with an in-boundary H100, is the reference implementation of exactly this pattern [@azure-nccadsh100v5].
{`
// Illustrative logic, not a real crypto library.
function verifyQuote(quote, expectedRoot, expectedMeasurement) {
const rootOk = quote.signedBy === expectedRoot;
const measurementOk = quote.measurement === expectedMeasurement;
return rootOk && measurementOk;
}
const cpuQuote = { signedBy: "AMD-VCEK", measurement: "cvm-image-v1" };
const gpuQuote = { signedBy: "NVIDIA-NRAS", measurement: "h100-cc-enabled" };
const cpuOk = verifyQuote(cpuQuote, "AMD-VCEK", "cvm-image-v1");
const gpuOk = verifyQuote(gpuQuote, "NVIDIA-NRAS", "h100-cc-enabled");
// Cardinal rule: release the secret ONLY when both roots verify.
console.log(cpuOk && gpuOk
? "Both attestations valid -- releasing model and data keys"
: "Attestation failed -- refusing to release keys");
// A quote signed by the wrong key must be rejected, even with a valid measurement:
const forged = { signedBy: "attacker-key", measurement: "h100-cc-enabled" };
console.log("Forged GPU quote accepted? " + verifyQuote(forged, "NVIDIA-NRAS", "h100-cc-enabled"));
`}
There is a family resemblance to Part 2 of this series. A zero-knowledge proof lets a prover convince a verifier a computation was done correctly without revealing the inputs; an attestation quote lets a chip convince a verifier the expected code is running without the verifier seeing the datacenter. Attestation is the silicon analogue of a verifiable claim -- a proof about *which machine and which code*, not *which computation*. The companion post on [Apple Private Cloud Compute versus Azure confidential AI](/blog/verify-me-dont-trust-me-apple-pcc-azure-confidential-ai-and-/) pushes this further, to attestation against a *publicly logged* build, which Section 6 reaches.
> **Key idea:** Attestation, not encryption, is the load-bearing move. A remote party cannot distinguish a real confidential VM from an ordinary VM lying about it -- unless the hardware proves itself with a signed quote checked against a vendor root, and the secret is released only on success. And confidential AI needs *two* such proofs, against *two* roots. Without attestation, silicon isolation is unverifiable and you are back to trusting the operator's word.
> **Note:** If you procure confidential AI, verify both halves. Check the CPU VM's quote against the correct CPU vendor root, check the GPU's quote against NVIDIA's root, and gate Secure Key Release on *both*. A pipeline that attests the CPU and trusts the GPU by assumption has a plaintext hole exactly where the model runs.
So the silicon works, and we can prove it works, to someone who cannot see the building. Is *this* the thing that finally makes confidential AI real at GPU speed? What does the state of the art actually ship in 2026?
## 6. Confidential AI in 2026
Return to the hospital. The model owner encrypts the weights; the hospital encrypts the scans; both keys are held by a key-management service that will release them only to an attested environment. A confidential VM boots on an AMD SEV-SNP host, an H100 in confidential-computing mode is attached to its trust boundary, and both halves attest -- the CPU against AMD's root, the GPU against NVIDIA's -- before either key is released. Now trace the data.
The single permitted data path between a CPU confidential VM and a GPU in confidential-computing mode. Because host software must never see plaintext, the CPU VM encrypts each transfer with AES-GCM into a shared buffer, and the GPU decrypts it only inside its own boundary (and vice versa on the way back). Data is never plaintext on the PCIe bus or in host memory [@nvidia-hcc-whitepaper].
A DMTF standard (DSP0274) for authenticating a hardware device and establishing an encrypted, integrity-protected session with it over a bus such as PCIe. NVIDIA H100 confidential computing uses SPDM to authenticate the GPU to the CPU confidential VM and secure the link between them [@nvidia-hcc-whitepaper] [@dmtf-spdm-dsp0274].
flowchart LR
A["Tensors inside the CPU confidential VM"] -->|"AES-GCM encrypt"| BB["Encrypted bounce buffer on the PCIe bus"]
BB -->|"SPDM-secured session"| G["Decrypt only inside the GPU TEE"]
G --> VRAM["Compute on encrypted VRAM"]
ROT["On-die GPU root of trust holds the keys"] --> G
The plaintext model and the plaintext scans exist in exactly two places: inside the CPU confidential VM's encrypted memory, and inside the H100's encrypted VRAM. On the wire between them they are AES-GCM ciphertext; to the operator, the hypervisor, and anyone with a bus analyzer, the whole pipeline is opaque. That is confidential AI, and the reason it matters is the number attached to it.
An empirical benchmark by Zhu and colleagues measured H100 confidential computing across many models and input sizes: the average throughput overhead is **under nine percent** versus the TEE disabled [@zhu-hopper-benchmark-2024]. This is the headline homomorphic encryption cannot touch. FHE on a 70-billion-parameter forward pass is orders of magnitude too slow for real time; a GPU TEE runs the same inference within a tenth of native speed.
> **Note:** The counterintuitive finding is that the *smallest* model carries the highest overhead and the *largest* carries almost none: the study reports the overhead for Llama-3.1-70B on the H100 is negligible, close to zero. The residual cost is dominated by the encrypted CPU-to-GPU transfer, not by GPU computation -- so as a model gets bigger and compute-bound, the fixed encryption cost is amortized toward nothing [@zhu-hopper-benchmark-2024].
A consequence that surprises people: a *faster* GPU can show *more* relative confidential-computing overhead. The benchmark finds the H200 -- the same Hopper confidential-computing family as the H100, with faster HBM3e memory [@nvidia-hopper-arch-hub] -- exhibits a larger overhead percentage for the same model, because its quicker compute makes the fixed PCIe-encryption cost a bigger share of a smaller total [@zhu-hopper-benchmark-2024].
Set the shipping methods side by side. The axes are the ones a practitioner actually chooses between: how big is the protected boundary, how much does it cost, whose root do you trust, does it fit AI, and how has it been broken.
| Dimension | Intel SGX | AMD SEV-SNP | Intel TDX | NVIDIA H100/H200 CC | Blackwell multi-GPU |
|---|---|---|---|---|---|
| Granularity | Process enclave | Whole VM | Whole VM | GPU plus CPU VM | Multi-GPU plus CPU VM |
| First shipped | 2015 | 2021 | 2023 | 2024 GA | 2024 to 2025 |
| Overhead | Near-native in cache; 5 to 100 times on paging [@vault-asplos-2018] | Near-native (design) | Near-native (design) | Under 9% avg; near-zero for 70B [@zhu-hopper-benchmark-2024] | Vendor near-native |
| Boundary | About 90 to 96 MB usable cache | Whole VM | Whole VM | Full VRAM, single-GPU | 8-GPU or rack domain |
| Attestation root | Intel EPID then DCAP | AMD VCEK | Intel PCS/DCAP | NVIDIA NRAS | NVIDIA NRAS plus CPU root |
| AI fit | Poor | CPU-only | CPU-only | Native, single-GPU | Native, multi-GPU |
| Representative break | WireTap, SGAxe, Foreshadow | Battering RAM, TEE.Fail | TEE.Fail forged quote | TEE.Fail keys reach GPU CC | Inherits the ceiling |
| Status | Niche | Cloud default | Intel lift-and-shift | Confidential AI | Emerging, frontier scale |
Two more methods complete the 2026 picture. NVIDIA's **Blackwell** generation extends confidential computing across multiple GPUs -- bringing NVLink traffic inside the boundary via Protected PCIe and TEE-I/O, up to a 72-GPU rack as a single confidential domain -- which is the emerging answer for frontier-model training and inference that a single GPU cannot hold [@nvidia-secure-ai-blackwell-wp]. And **Apple Private Cloud Compute**, announced in 2024 for Apple Intelligence, raises a different bar entirely.
Apple PCC's distinguishing move is not the enclave but the *verifiability of the entire fleet*. Apple publishes every production server image to an append-only transparency log with a signed measurement, and a user's device sends data **only** to a node whose attestation matches a *publicly logged* build [@apple-pcc-blog] [@apple-pcc-source]. Plain attestation proves you are talking to an approved build; PCC's transparency proves that build is one the whole world can inspect -- closing the "the provider quietly changed the software and you could not tell" gap. The companion post on Apple PCC versus Azure confidential AI develops that contrast.
A 2025 systematic security analysis reverse-engineered the internals of NVIDIA GPU confidential computing -- the SEC2 bootstrap channel and the paired work-launch and launch-confirmation channels that carry signed, encrypted work into the protected region -- mapping exactly where the trusted and untrusted seams lie [@gpu-cc-security-analysis-2025].
One myth to retire while we are here. There was no "Confidential GPT-4" general-availability release in 2024, however often the phrase circulates; the publicly demonstrated confidential-inferencing workload was a speech-to-text model [@nvidia-azure-h100-cvm-ga-2024], and the shipping CPU-plus-GPU pipeline anyone can rent is NCCadsH100v5 [@azure-nccadsh100v5]. The reality is more impressive than the folklore, because it is real.
This is real, it ships, and it is fast. So is the silicon trust model simply *better* than the mathematics of Parts 1 to 4? Time for the honest accounting.
## 7. Two Trust Models, Side by Side
Raluca Ada Popa put the fork in the road into four words. The question a system designer faces when they must compute on sensitive data is: **confidential computing or cryptographic computing?** Hardware enclaves on one side, cryptography on the other -- and the honest framing of the choice is the intellectual core of this capstone [@popa-cc-vs-cryptographic-2024].
The field offers two options for computing on data you are not allowed to read: confidential computing, which anchors trust in hardware, or cryptographic computing, which anchors it in mathematics. -- after Raluca Ada Popa, Communications of the ACM, 2024
Start with the precision that everything else depends on, because it is the single most common error people make about TEEs. **A TEE is not "math-free."** It is saturated with cryptography: AES memory encryption on the DRAM bus, AES-GCM on the CPU-to-GPU link, and ECDSA or EPID digital signatures on every attestation quote [@amd-sev-snp-wp-2020] [@nvidia-hcc-whitepaper].
So the thesis is *not* "mathematics versus no mathematics." It is about where trust is *anchored*. In the mathematical schemes of Parts 1 to 4, confidentiality rests on a computational-hardness assumption -- breaking it means solving a problem believed to be intractable. In a TEE, confidentiality rests on a vendor, a die, and the assumption that no exploitable side channel exists. Both use math. They differ in what you trust when you rely on them.
Lay the two anchors on one axis.
| Dimension | Silicon (TEEs, this article) | Mathematics (FHE, ZK, MPC, PIR -- Parts 1 to 4) |
|---|---|---|
| Trust anchored in | A vendor, a die, and "no exploitable side channel" | A computational-hardness assumption |
| Vendor in the trust base? | Yes -- attestation chains to a vendor-provisioned root key | No vendor root |
| Uses cryptography? | Yes (AES memory encryption plus signed attestation) | Yes (the computation itself is cryptography) |
| Overhead | Near-native to under 9% on a GPU | Roughly $10^3$ to $10^6$ times for FHE; scheme-dependent |
| Real-time large-model inference | Yes (H100/H200 CC) | No (too slow today) |
| Breakable by a physical adversary? | Yes -- a memory interposer (2025) | No hardware to interpose on an assumption |
| Standing weakness | Vendor plus side-channel plus physical bus | Cost; FHE gives confidentiality, not integrity |
| Best for | Native speed on an untrusted operator you can accept a vendor for | No-vendor-trust, high-assurance, or regulatory workloads |
Read the table as two lists of virtues that are also two lists of costs. The silicon model runs unmodified workloads at near-native speed and is the only thing on this page that makes confidential AI real at GPU scale [@zhu-hopper-benchmark-2024] -- but you must trust the vendor, the silicon, and the unprovable premise that no side channel is being exploited.
The mathematical model removes the vendor from the trust base entirely -- no die to trust, no fab to audit -- but pays in orders of magnitude of overhead and, for FHE, in sharp workload limits and confidentiality without integrity.
> **Key idea:** The two ceilings are mirror images. The silicon model cannot remove the vendor from the trust base and cannot prove the absence of side channels. The mathematical model has no vendor root but cannot yet reach real-time large-model speed. Neither anchor dominates the other; each one's floor is the other's ceiling. That symmetry is why this capstone crowns no winner.
Because the anchors are complementary rather than competitive, the mature answer is often to use *both*. A **hybrid** places each part of a workload where its trust costs least and delivers most: a TEE for the high-throughput bulk and the orchestration around it, and a cryptographic kernel -- an MPC step, an FHE evaluation, a zero-knowledge proof -- for the single most sensitive operation where you refuse to trust any vendor.
Signal's contact discovery is a small, real instance of the two models meeting: a privacy protocol deployed inside an SGX enclave, hardware isolation carrying a cryptographic design [@signal-cdsi]. You do not have to pick a side for the whole system. You pick an anchor per workload.
And if neither anchor dominates, the interesting question is no longer "which is better." It is "where does each one *fail*?" What, precisely, can no TEE ever promise -- not as a bug to be patched, but as a matter of structure?
## 8. What No TEE Can Promise
The limits of the silicon model are not a list of unpatched bugs. They are structural, and the field states them about itself. There are two, and they are mirror images of each other.
The **lower bound** is that you cannot remove the vendor from the trust base. Remote attestation *requires* a root that some manufacturer vouches for; there is no attestation without an endorser. RFC 9334 says this in as many words: the Verifier trusts "a manufacturer or the manufacturer's hardware" by storing that endorser's key as a trust anchor, and the components vouched for this way -- because no evidence is generated about them -- are the roots of trust (Section 7.4) [@rfc-9334].
Follow any TEE's trust chain to its end and it terminates at a key provisioned by a vendor, in a fabrication process you did not audit, running microcode you cannot read. Trusting the silicon *entails* trusting the vendor's supply chain. That is a floor the mathematical model simply does not have -- there is no vendor in the trust base of a lattice assumption.
The remote-attestation standard does not merely permit a vendor root; it names it. RFC 9334 calls the manufacturer's endorsement key a "trust anchor." The specification that makes silicon trust verifiable is also the specification that documents its irreducible dependence on the vendor -- the very thing this article argues moves.
The **upper bound** is that a TEE's confidentiality is only as strong as two things: the secrecy of its attestation key, and the integrity of its memory encryption. This is not a theoretical ceiling; both conditions have been violated in practice, which turns "upper bound" from a claim into a demonstration.
Extract the attestation signing key -- as SGAxe did with EPID, as WireTap did by recording a memory bus, as TEE.Fail did with Intel's provisioning key -- and a forged quote becomes cryptographically indistinguishable from a genuine one; the entire chain of trust collapses at once, not one machine at a time [@sgaxe-2020] [@wiretap-2025] [@tee-fail-2025]. Break the memory encryption's integrity -- as the 2025 interposers do against deterministic, unauthenticated encryption -- and the confidentiality guarantee unravels from the DRAM side [@battering-ram-2025].
Between what the model *assumes* and what it can *prove* sits a gap the field names openly.
> **Note:** The Confidential Computing Consortium's own technical analysis lists bus and cache monitoring, cold DRAM extraction, and plugging a device into an existing port as *in-scope* threats the model aims to defend, and places only long-term invasive attacks such as decapping and microprobing, fault injection, and power or electromagnetic side channels *out of scope* [@ccc-technical-analysis-v1-3]. That boundary is what makes the 2025 memory-bus interposers so serious: they broke an in-scope, claimed-defended threat, not a residual risk the model had already disclaimed. Intel, AMD, and NVIDIA scope their threat models the same way. So "no exploitable side channel" is an assumption the model *makes*. It is never a guarantee the model *provides*.
Notice the symmetry, because it is the whole point of the capstone. The silicon model's ceiling is a vendor root it cannot remove and a side-channel assumption it cannot prove. The mathematical model's ceiling is cost -- and, for FHE, integrity it does not by itself provide -- but with *no vendor root at all*. Each model's ceiling is exactly the other model's floor.
Engineering can narrow the gaps but not close them. Authenticated, fresh memory encryption could close the interposer gap, but it costs the $O(\log N)$ integrity-tree tax AEGIS paid in 2003 and the cloud dropped for speed [@aegis-ics-2003]. Formal verification could shrink the side-channel gap. But no amount of engineering removes the vendor from the trust base of a hardware root of trust; that dimension belongs, structurally, to mathematics.
These are the assumptions, stated plainly. In October 2025, three research groups put a device between the processor and its memory and turned the assumptions into demonstrations.
## 9. How the Silicon Model Breaks
In 2025, three groups, three interposers, one root cause. A device you can build for the price of a nice dinner forges an attestation that the vendor's own verifier rates at its highest trust level. This is the moment the article's third turn lands: attestation did not make the TEE unbreakable. It moved the whole guarantee onto the secrecy of a signing key and the integrity of memory encryption -- and both are physically reachable.
Producing a quote that a verifier accepts as genuine without running the genuine, expected environment. The practical route is *key extraction*: once an attacker recovers the hardware attestation signing key, the forged quote it produces is cryptographically indistinguishable from a real one, because it is signed by the real key. The break is the whole trust chain, not one machine [@tee-fail-2025].
The root cause is the freshness gap AEGIS warned about in 2003. Server memory encryption is *deterministic and unauthenticated* at the DRAM bus: keyed on the physical address (AES-XTS on Intel, an XEX-mode tweak on AMD), with no per-write nonce and no integrity tag. That has two consequences an attacker on the bus can use -- equal plaintext blocks produce equal ciphertext (a leak of equality), and a recorded ciphertext can be replayed later (a break of freshness).
{`
// Toy deterministic keyed mapping (NOT real crypto) to show the property.
function detEncrypt(block, key) {
let h = 0;
for (const ch of (block + key)) h = (h * 31 + ch.charCodeAt(0)) % 100000;
return "CT" + h;
}
const key = "vm-key";
const a = detEncrypt("balance-100", key);
const b = detEncrypt("balance-100", key);
const c = detEncrypt("balance-999", key);
console.log("Equal plaintext -> equal ciphertext? " + (a === b)); // true: leaks equality
console.log("Different plaintext -> different ciphertext? " + (a !== c)); // true
// Add per-write randomization (a nonce). This restores semantic security:
function randomizedEncrypt(block, key, nonce) {
return detEncrypt(block + ":" + nonce, key);
}
const f1 = randomizedEncrypt("balance-100", key, "nonce-1");
const f2 = randomizedEncrypt("balance-100", key, "nonce-2");
console.log("With randomization, equal plaintext -> equal ciphertext? " + (f1 === f2)); // false
// IMPORTANT: this only hides equality. It does NOT stop replay -- an attacker
// can replay the (ciphertext, nonce) pair together. Real anti-replay freshness
// needs the nonce authenticated in an on-chip version tree, exactly as AEGIS did.
`}
That toy is the whole vulnerability class in miniature. Here is what the 2025 wave did with the real thing.
flowchart TD
DET["Deterministic, unauthenticated encryption on the DRAM bus"] --> INT["Physical interposer between CPU and DIMM"]
INT --> ALIAS["Alias or replay physical addresses"]
INT --> RECORD["Record deterministic ciphertext"]
ALIAS --> KEY["Extract the attestation signing key"]
RECORD --> KEY
KEY --> FORGE["Forge a quote that verifies UpToDate"]
FORGE --> BROKEN["The whole attestation chain collapses"]
**WireTap** used a *passive* DDR4 interposer -- it only records bus traffic -- and, exploiting the deterministic encryption, extracted an SGX attestation key from a machine in fully trusted status. It then forged quotes end to end against SGX-backed blockchains with multi-million-dollar market caps [@wiretap-2025].
**Battering RAM** built an interposer for a total bill of materials of \$47.62, invisible at boot, that aliases physical addresses to grant arbitrary plaintext access to SGX memory and to break SEV-SNP attestation on fully patched systems [@battering-ram-2025] [@kuleuven-batteringram-news].
**TEE.Fail** was the first DDR5 memory-bus attack. It extracted Intel's provisioning-enclave ECDSA key and forged a TDX quote that verifies at Intel DCAP's highest trust level, "UpToDate," carrying a deliberately impossible measurement -- the value 0x1337 -- while also reaching AMD SEV-SNP and, through the extracted keys, NVIDIA GPU confidential computing [@tee-fail-2025].
Defending against Battering RAM would require a fundamental redesign of memory encryption itself. -- the Battering RAM disclosure, 2025
The word "patched" is doing dangerous work in most people's mental models here.
> **Note:** Every 2025 interposer attack works on *fully patched* silicon, because the flaw is not a bug in the firmware -- it is the deterministic, unauthenticated design of the memory encryption itself. A software or microcode update cannot close it. A fresh attestation proves the expected build booted; it does not prove that no interposer sits on the DIMM. Treat attestation as necessary, never as sufficient [@tee-fail-2025].
These are the [microarchitectural side channels](/blog/correct-constant-time-and-still-owned-a-field-guide-to-side-/)' louder cousins, but the quieter class has not gone away either. Foreshadow, SgxPectre, AEPIC, and CipherLeaks all leak enclave or VM secrets without a screwdriver, and undervolting fault-injection attacks such as Plundervolt can corrupt an enclave's computation from software [@foreshadow-l1tf] [@sgxpectre-2018] [@aepic-leak-2022] [@cipherleaks-2021] [@plundervolt]. Two attack families, one lesson: silicon trust is breakable in ways a hardness assumption is not.
The research racing to close these gaps is real, and the leading direction is a revival. **Memory encryption with integrity and freshness** at server scale -- literally AEGIS's 2003 insistence, reborn -- is the fix for the interposer class, though it must somehow avoid the logarithmic integrity-tree cost the cloud dropped for speed [@aegis-ics-2003]. **Formally verified, side-channel-resistant TEE designs** would move "no side channel" from an assumption toward a proof; the scholarly threat-model work on SGX is the starting point [@sgx-explained-2016].
Two more fronts are open. **Multi-GPU confidential AI** needs independent third-party benchmarking to match its rapid deployment [@nvidia-secure-ai-blackwell-wp]. And **shrinking or de-monopolizing the vendor root** -- Apple's publicly logged, transparent fleet is the leading move -- can make the root *accountable* even though it cannot be removed [@apple-pcc-blog]. The internals of GPU confidential computing are only now being independently dissected, exactly the adversarial scrutiny a 2024-era technology still needs [@gpu-cc-security-analysis-2025].
Here is the whole break surface on one table.
| Attack (year) | Class | Primary target | What it achieves | Works on patched systems? |
|---|---|---|---|---|
| Foreshadow (2018) | Microarchitectural | SGX | Reads enclave memory and the attestation key | Mitigated by microcode |
| SgxPectre (2018) | Microarchitectural | SGX | Leaks enclave secrets via speculation | Mitigated |
| CipherLeaks (2021) | Ciphertext side channel | SEV-ES, SEV-SNP | Recovers secrets from deterministic ciphertext | Forced the RMP |
| AEPIC (2022) | Architectural MMIO | SGX | Dumps stale enclave data, no speculation | Mitigated |
| WireTap (2025) | Physical, DDR4 (passive) | SGX | Extracts the attestation key, forges quotes | Yes |
| Battering RAM (2025) | Physical, DDR4 | SGX and SEV-SNP | Arbitrary plaintext, breaks attestation | Yes, fully patched |
| TEE.Fail (2025) | Physical, DDR5 | SGX, TDX, SEV-SNP, reaches GPU CC | Extracts keys, forges an "UpToDate" quote | Yes, fully patched |
The capstone resolves here. Because the silicon anchor is undone by a physical or microarchitectural adversary, the mathematical trust model of Parts 1 to 4 remains the higher-assurance floor for any workload that cannot accept a vendor in its trust base or an unprovable "no side channel" assumption. The two models are complements, not rivals -- which is exactly why neither made the other obsolete.
So what should *you* actually do on Monday morning -- reach for silicon, for mathematics, or for both?
## 10. Choose Your Anchor by Workload
The practitioner's question is not "which technology wins." It is "which anchor fits *this* workload and *this* threat model." Popa's framing is the north star: confidential computing or cryptographic computing, chosen deliberately, not by default [@popa-cc-vs-cryptographic-2024].
flowchart TD
START["Choose your trust anchor"] --> Q1{"GPU needed for confidential AI?"}
Q1 -->|"Yes"| GPU["H100 or H200 CC plus a CPU CVM, and enforce double attestation"]
Q1 -->|"No"| Q2{"Lift-and-shift a whole VM?"}
Q2 -->|"Yes"| VM["SEV-SNP or TDX confidential VM"]
Q2 -->|"No"| ENC["SGX minimal-TCB enclave"]
GPU --> VERIFY["Verify every quote against the correct vendor root, then gate key release"]
VM --> VERIFY
ENC --> VERIFY
VERIFY --> Q3{"Accept a vendor in your TCB and the no-side-channel assumption?"}
Q3 -->|"Yes"| SHIP["Ship on the TEE"]
Q3 -->|"No"| MATH["Reach for the mathematics of Parts 1 to 4, or a hybrid"]
Walk the flow. First: do you need the GPU inside the boundary? If you are running confidential AI, the answer is yes, and the shape is an H100 or H200 in confidential-computing mode composed with a CPU confidential VM (single-GPU today), or a Blackwell multi-GPU domain for frontier scale [@azure-gpu-options].
If the GPU is not in play, choose between VM-level and process-level isolation: SEV-SNP or TDX to lift an existing OS and application into a confidential VM with no code changes, and SGX when the sensitive kernel is small enough to justify the minimal trust base and the porting effort.
Second, the step no path skips: **actually verify the attestation.** A TEE that is never attested is just a virtual machine that claims to be private. Gate secret release on a quote checked against the *correct* vendor root or roots, enforce double attestation for CPU-plus-GPU pipelines, and release the model and data keys only on the expected measurement [@azure-attestation-overview]. The single most common and most damaging misconfiguration is to verify one half of a two-vendor pipeline and assume the other is covered.
> **Note:** If your key-release policy ever hands a secret to an endpoint whose quote you did not verify against the right root and the right measurement, you have built confidential computing with the confidentiality switched off. Everything else in this article is downstream of getting this one control right.
Third, know when *not* to reach for a TEE. If you cannot accept a silicon vendor in your trust base, cannot accept the standing "no exploitable side channel" assumption, or face an adversary with physical access to the memory bus, the silicon anchor is the wrong tool. The right one is the mathematics of the earlier parts, or a hybrid that uses a TEE for throughput and a cryptographic kernel for the most sensitive step.
The deep mechanics of deploying the CPU confidential VMs themselves live in the companion post on [Azure Confidential VMs](/blog/inside-azure-confidential-vms-sev-snp-intel-tdx-and-the-para/); this section stays at the level of *which anchor*, not *which command*.
The verification is not hypothetical hand-waving -- it is tooling you run. NVIDIA's nvTrust and its NRAS verifier attest the GPU; AMD's snpguest and the virtee project, plus Intel's DCAP, verify CPU quotes; Microsoft Azure Attestation composed with Secure Key Release gates the key; and Apple's security-pcc release lets anyone inspect the logged builds a device will talk to [@nvidia-nvtrust-docs] [@apple-pcc-source].
On an NVIDIA confidential-computing host, `nvidia-smi conf-compute -f` reports whether the GPU is in CC mode, and the nvTrust tooling runs local and remote GPU attestation against NVIDIA's verifier; on an AMD host, the `snpguest` utility fetches and validates a SEV-SNP attestation report. None of these replaces the real control -- gating key release on the verified result -- but they are how you confirm the boundary is actually on before you trust it [@nvidia-nvtrust-docs].
The series began by asking how to compute on data you are not allowed to read. Five parts in, we can finally answer -- not with one method, but with a choice, and with the judgment to make it well.
## 11. Frequently Asked Questions
No, and this is the most common misconception. A TEE is saturated with cryptography: AES memory encryption on the DRAM bus, AES-GCM on the CPU-to-GPU link, and digital-signature attestation on every quote [@amd-sev-snp-wp-2020]. The thesis of this series is not "mathematics versus no mathematics." It is about where trust is *anchored* -- in a silicon vendor and an attestation chain, rather than in a computational-hardness assumption [@popa-cc-vs-cryptographic-2024].
No. Attestation is exactly as strong as the secrecy of the signing key. Once that key leaks -- as WireTap did by passively recording a DDR4 memory bus, and as TEE.Fail did by extracting Intel's provisioning key -- a forged quote is cryptographically indistinguishable from a genuine one, and TEE.Fail's forged quote verified at the vendor's highest trust level [@wiretap-2025] [@tee-fail-2025]. Attestation is necessary, not sufficient.
No -- that is the point of it. You move trust *off* the cloud operator and *onto* the silicon vendor, and then you verify that the operator is locked out. In Azure's confidential-AI pipeline the trust boundary spans the CPU confidential VM and the attached GPU, and the operator has no path to the plaintext inside either [@azure-gpu-options]. You are not trusting the provider; you are trusting the chip and proving the provider cannot see in.
No. GPU confidential computing reached general availability in 2024, so it has seen a fraction of the adversarial scrutiny that a decade of SGX and SEV research produced [@nvidia-h100-cc-ga-2024]. No full-boundary GPU-CC compromise has been published, but its internals are only now being independently dissected. Newer is not the same as broken -- but it is not the same as battle-hardened either.
No, and the difference is the whole series in one sentence. Fully homomorphic encryption, from Part 1, keeps the data encrypted *during* the computation and never decrypts it -- the trust is in mathematics. A TEE *decrypts inside* a hardware boundary and relies on the chip to refuse to leak it -- the trust is in silicon and attestation. Same goal, opposite trust anchors, wildly different performance.
Often, yes, though the boundary is narrower than it sounds. The confidential-computing threat model places only long-term invasive attacks (decapping, microprobing), fault injection, and power or electromagnetic side channels *out of scope*; bus monitoring, cold DRAM extraction, and port-plugging are listed as *in-scope* [@ccc-technical-analysis-v1-3]. So the 2025 breaks matter more, not less: a fifty-dollar memory interposer defeated SGX and SEV-SNP attestation on fully patched systems, an in-scope threat the model claimed to withstand [@battering-ram-2025]. That is the honest limit of the silicon anchor, and it is precisely why the mathematical schemes of the earlier parts still matter.
No. There was no general-availability release of a "Confidential GPT-4" in 2024, however often the phrase is repeated. The publicly demonstrated confidential-inferencing workload was a speech-to-text model [@nvidia-azure-h100-cvm-ga-2024], and the shipping CPU-plus-GPU pipeline anyone can actually rent is the NCCadsH100v5 virtual machine, an AMD SEV-SNP VM with an in-boundary H100 [@azure-nccadsh100v5].
## Where the Trust Went
Start where we started: a hospital runs a proprietary 70-billion-parameter model on private scans, inside a cloud nobody in the room trusts, at under ten percent overhead, where fully homomorphic encryption would be three to six orders of magnitude too slow [@zhu-hopper-benchmark-2024].
The paradox dissolves once you see the move. The machine is not computing on data it cannot read; it is decrypting the data *inside a boundary its owner is locked out of*, and proving which boundary it is with a signed quote checked against a vendor root. The secret is never mathematically hidden. The *trust* is relocated -- from a hardness assumption to a die, a vendor, and an attestation chain.
That relocation is real, and it ships. Confidential AI in 2026 is not a demo; it is a rentable virtual machine with double attestation and secret release gated on a verified measurement [@azure-nccadsh100v5]. It is the one thing on the shelf that keeps a model and its inputs confidential at GPU speed, in the exact regime where mathematics is still too slow. For that class of workload, the silicon anchor is not a compromise -- it is the answer.
But the trust did not vanish; it moved somewhere with a physical address. A TEE's guarantee is exactly as strong as the secrecy of one signing key and the integrity of its memory encryption, and in 2025 a device costing less than a dinner extracted the key and forged a quote the vendor's own verifier rated "UpToDate" [@tee-fail-2025].
You cannot remove the vendor from the trust base -- the attestation standard itself says so [@rfc-9334] -- and you cannot prove the absence of side channels; the field concedes both as residual risk [@ccc-technical-analysis-v1-3]. Those are not bugs awaiting a patch. They are the shape of the silicon anchor.
So the series closes where an honest capstone must: with a refusal to crown a winner. For twenty-five years the field answered one question -- how do you compute on data the machine's owner cannot read? -- two ways. Fully homomorphic encryption, zero-knowledge proofs, secure multi-party computation, and private information retrieval answered with mathematics and paid in overhead. Trusted Execution Environments answer with hardware and attestation, and pay in a vendor you must trust and an attack surface a physical adversary can reach. Each anchor's ceiling is the other's floor.
The mature engineer does not ask which is better; they ask where the trust should live for *this* workload -- and sometimes the answer is a hybrid that uses both. The secret was never decrypted where an adversary could reach it. Across all five parts, that was only ever the beginning of the question. The end of it is knowing what, and whom, you had to trust to keep it that way.