Remote Attestation Protocols in Confidential Computing
Every attestation protocol, regardless of vendor or hardware family, instantiates the same abstract structure. The IETF and the Trusted Computing Group both formalize this as a three-participant model, and understanding it at this level is the prerequisite for reasoning about any specific implementation.
The first participant is the Attester: the device or environment whose trustworthiness is in question. The attester hosts a TEE or a Trusted Platform Module that collects cryptographically protected evidence about its own state, including measurements of boot-time code, hashes of runtime state, firmware version identifiers, and user-authentication status.
The second participant is the Verifier: a trusted third party that receives the evidence, applies policy, and evaluates it against endorsements and reference values supplied through a separate supply chain. The verifier issues an attestation verdict. It does not grant access to anything.
The third participant is the Relying Party: the entity that actually wants to make a trust decision, whether releasing a decryption key, granting access to a resource, or accepting data. The relying party consumes the verifier's verdict and applies its own policy to determine whether to proceed.
This two-stage appraisal structure deliberately separates authentication from authorization. The relying party delegates signature verification and measurement comparison to a specialized verifier while retaining control over what it will actually permit. Conflating those two distinct trust decisions produces systems that are either too rigid or too permissive, often both at different points in the lifecycle.
Three security properties follow directly from this structure. Authenticity: only the verified device can produce a valid signed report, because the signing key is fused into silicon and not exportable by software. Integrity: the measured region cannot be altered without invalidating the measurement. Atomicity: the attestation routine runs under auditable, defined entry points and cannot be interrupted or bypassed mid-measurement.
The reference-value layer is where things quietly come apart in practice. A valid signature from a known hardware key proves the hardware is authentic. But does it prove the software is correct? It does not. Without a known-good baseline to compare measurements against, attestation becomes an identity check without a policy check, and those are two distinct things. The endorsement and reference-value supply chain is a distinct layer of trust, and it is frequently less mature than the cryptographic plumbing beneath it. I have watched organizations stand up technically correct attestation infrastructure, validate every signature, and then deploy it with no meaningful reference values, accepting any measurement from a known chip as sufficient. The hardware is genuine. The software running on it is anyone's guess.
How Hardware Roots of Trust Anchor the Measurement Chain
The chain of trust starts at manufacture. Hardware vendors fuse unique identity keys into silicon during fabrication. These keys cannot be extracted or cloned by software; they are the physical anchor that makes everything above them meaningful. Without that anchor, attestation is a signature over a self-referential assertion.
The boot measurement sequence extends this anchor upward through the software stack. Each stage of boot, from firmware to bootloader to OS to enclave initialization, is hashed and recorded in hardware-protected registers before control passes to the next stage. In TPM-based systems, these are Platform Configuration Registers, PCRs. In Intel SGX, the analogous values are MRENCLAVE, which captures what code is running, and MRSIGNER, which captures who signed it. Tampering at any stage produces a different measurement; the verifier detects the discrepancy.
The TEE then signs a report over these accumulated measurements using the hardware identity key. The verifier confirms two things: that the signature was made by a key it recognizes as belonging to authentic hardware, and that the measurements match expected reference values for the intended software. Both checks must pass. One without the other is a different, weaker guarantee than most architects assume they have deployed — not a partial solution.
TPMs and TEEs operate at different granularities and serve different purposes. TPMs provide a platform-level root, attesting the state of the whole machine across its boot sequence. TEEs like SGX enclaves provide per-application attestation, covering a specific workload running in isolation from the rest of the system. Production deployments increasingly rely on both, which means managing two distinct measurement chains, two endorsement hierarchies, and two sets of reference values. The complexity compounds in ways that are not always visible until something fails verification unexpectedly.
How Intel SGX, AMD SEV-SNP, and ARM TrustZone Each Implement Attestation Differently
The three most widely deployed TEE families reflect three different adversary models, and those models produce distinct attestation architectures. A verifier cannot, without an abstraction layer, consume evidence from all three in a uniform way. The differences are not superficial; they go to the fundamental question of what each architecture is designed to protect against.
Intel SGX
SGX operates at the finest-grained trust boundary among the major TEE families: per-enclave memory encryption at the userspace process level. The model assumes a compromised OS or hypervisor and provides isolation for small, well-defined secrets within a single machine. The attestation quote is generated by a special Provisioning Certification Enclave running on the same platform, signed with an ECDSA key fused into silicon, and structured to carry the MRENCLAVE and MRSIGNER values the verifier needs to confirm both code identity and code provenance. SGX has found particular traction in blockchain deployments and scenarios where the asset is a small, isolated secret rather than an entire virtual machine.
AMD SEV-SNP
SEV-SNP encrypts entire virtual machines, with the specific goal of protecting VMs from an untrusted hypervisor. That is a different adversary assumption than SGX's; SEV-SNP is designed for cloud operators who want to offer tenants a hardware-enforced guarantee that the platform operator cannot read their workload memory. Attestation in SEV-SNP covers independent VMs rather than sub-process enclaves. Published performance overhead figures from AMD, Intel, and Google place the cost at roughly two to fifteen percent for typical cloud workloads, with higher overhead for memory-bandwidth-bound operations; hardware revisions in 2024 and 2025 narrowed that gap considerably. SEV-SNP, alongside Intel TDX, now dominates confidential cloud VM deployments.
ARM TrustZone
TrustZone partitions the entire system-on-chip into a Secure World and a Normal World, with hardware-enforced separation between them. It dominates mobile and embedded device deployments. The relevant limitation for attestation practitioners is that TrustZone does not provide native mechanisms for attesting software running in the trusted environment; the attestation layer must be built on top of the hardware primitives. That work has been done with varying degrees of rigor, and the variance matters operationally. TrustZone-M, the microcontroller variant, supports a root of trust that enables more tractable implementations, but the architectural gap relative to SGX and SEV-SNP is real. RISC-V is in a similar position: it lacks native attestation primitives, and community-developed solutions fill the gap, making it a platform where the attestation layer is more visibly decoupled from the hardware. Visibility into that decoupling is useful. It forces explicit choices that SGX and SEV-SNP implementations sometimes leave implicit.
The practical interoperability implication is direct: deploying applications across multiple TEE families requires either a translation layer or an abstraction standard. The same evidence format does not work across SGX, SEV-SNP, and TrustZone. That fragmentation is the problem RATS was designed to address.
What the IETF RATS Standard (RFC 9334) Does and Why It Exists
RFC 9334, the Remote ATtestation procedureS architecture, was published in January 2023 by the IETF RATS Working Group. Its goal is narrow: let relying parties establish confidence in the trustworthiness of remote peers across heterogeneous hardware and vendor ecosystems. RATS does not replace vendor attestation protocols. It provides the architectural vocabulary, the data formats, and the interaction models that vendor-specific implementations can map onto, enabling cross-platform verifiers.
RFC 9334 formalizes the attester, verifier, and relying party model and defines how evidence, endorsements, reference values, and attestation results flow between them. Three interaction models are defined in the accompanying reference-interaction-models draft. The Challenge-Response model has the verifier send a nonce and the attester sign evidence over that nonce; this prevents replay attacks and is the most common choice for interactive attestation. The Uni-Directional model has the attester push evidence without a fresh challenge, suited to constrained devices or logging scenarios where a live challenge is impractical. The Streaming Remote Attestation model provides continuous or periodic evidence flow for long-running workloads where software state can change after initial attestation.
The data formats reflect the current state of the standardization effort. CBOR Web Token (RFC 8392) and JSON Web Token (RFC 7519) serve as token structures. The Entity Attestation Token, EAT, is the standard format for conveying attestation evidence itself, at revision 31 as of September 2024. The EAT Attestation Results format, EAR, remains a work in progress as of early 2026. The results layer is less settled than the evidence layer, and that asymmetry is not accidental: standardizing policy expression across heterogeneous relying parties is genuinely hard, and the working group has been honest about not rushing it.
A December 2025 IDC survey of more than 600 IT leaders across 15 industries, commissioned by the Confidential Computing Consortium, identified skills gaps and interoperability barriers as persistent obstacles to confidential computing adoption. RATS is the structural response to the interoperability problem. The more pressing operational question, though, is which parts of the stack are lagging in implementation maturity. Standards work tends to run ahead of adoption, sometimes by years.
GPU Attestation and the Additional Complexity of CPU–GPU Composite Trust
The NVIDIA H100 is the first GPU to introduce support for confidential computing. It can run in virtualized environments via traditional VMs or Kubernetes with Kata Containers launching confidential microVMs. NVIDIA's GPU-CC attestation follows the RFC 9334 architecture: each H100 is provisioned at manufacture with a hardware-fused device identity key and a corresponding Device Identity Certificate, providing the same kind of hardware anchor that CPU TEEs rely on.
The trust model immediately introduces a dependency that does not exist in CPU-only deployments. The CPU TEE must first establish trust in the GPU, then manage a secure channel for data flow and computation between them. GPU-only attestation is considered insufficient; composite attestation of both the CPU and GPU is the recommended model. That dependency is also an attack surface. The secure channel between CPU TEE and GPU TEE is itself a target, and one that the literature on TEE attacks has not yet exhaustively characterized.
The performance tension is severe. A 2024 study by Tan and Mi found that encryption overhead in H100 Confidential Computing can reduce AI workload throughput by up to 93%. The overhead stems from encrypting high-bandwidth memory traffic that GPU architectures were not originally designed to protect. Whether that gap narrows through better hardware, software optimization, or selective application of confidential computing to only the most sensitive workloads is an open engineering and product question. The answer has significant implications for which AI workloads can realistically operate under confidential computing constraints at scale.
It is also worth considering the transparency problem without an easy resolution. NVIDIA's GPU-CC implementation is largely closed-source, which constrains independent verification of its security properties and limits the ability of external researchers to evaluate the attack surface. For organizations whose threat model includes adversaries capable of sustained technical effort against a production target, that asymmetry deserves explicit consideration in the risk model, not a footnote.
Attested TLS: Binding the Attestation Result to an Encrypted Channel
Attestation proves what is running. TLS provides an encrypted channel. Neither alone is sufficient for a deployment where a remote party needs both assurances simultaneously. Attested TLS composes both: the party you are encrypting to is also the party whose code you have verified. Attestation without a bound channel is susceptible to man-in-the-middle substitution; a channel without attestation provides no guarantee about the software at the other end.
The integration point is the TLS handshake. Attestation evidence or results are embedded in the handshake, or bound to it post-handshake, linking the enclave's identity measurement to the session keys. The IETF draft "Using Attestation in TLS and DTLS" (draft-fossati-tls-attestation) is the standardization effort for this composition, and it was still a work in progress as of October 2024. The results layer being unsettled in RATS and the channel-binding layer being unsettled in attested TLS are related problems; both reflect the difficulty of standardizing policy expression across diverse deployment environments, and progress on one tends to clarify what is needed from the other.
The two binding approaches produce different tradeoffs. Embedding evidence during the handshake is the simpler security model: evidence is exchanged before application data flows, and the session cannot be established without mutual attestation. The cost is latency and a requirement that both sides support the extension. Post-handshake binding attaches evidence to the application traffic key after the session is already established, which substantially changes the deployment shape. Clients, verifiers, proxies, load balancers, service meshes, and application protocols must all agree on when and where the attestation point occurs. Getting that agreement in a heterogeneous production environment is harder than the protocol design implies.
Research published in 2025 by Muhammad Usama Sardar at TU Dresden identified a vulnerability that deserves direct attention: attested TLS is susceptible to diversion attacks, where a connection intended for a legitimate server is silently redirected to a compromised machine without the client detecting the substitution. This is not an edge case. It exploits the gap between when attestation is verified and when the channel is used, a timing and binding problem, rather than a flaw in the underlying cryptography. Attestation and channel binding can both be in place and the connection can still be diverted, which means the composability guarantee is weaker than it appears. But how does this affect our original promise? Any organization treating attested TLS as a complete solution without accounting for this gap is accepting risk that may not appear in their threat model until it matters.
Known Attacks That Have Broken or Bypassed TEE Attestation in Practice
The academic literature on TEE attacks is extensive. Practitioners benefit most from attacks that demonstrate real-world impact on actual attestation mechanisms.
TEE.Fail (October 2025)
TEE.Fail is a memory-bus interposition attack on DDR5 systems, demonstrated against Intel SGX, TDX, and AMD SEV-SNP. It was performed with hardware available to hobbyists at a cost under $1,000. That cost threshold matters considerably. Prior attacks targeting DDR4 systems required more specialized equipment, and the lower bar substantially changes the attacker population that can realistically exploit the vulnerability.
The consequences are specific and serious. Researchers extracted ECDSA attestation keys from Intel's Provisioning Certification Enclave in a single signing operation, then used those keys to forge valid TDX attestation quotes that passed verification using Intel's official DCAP Quote Verification Library. The forged quotes carried the highest trust designation, "UpToDate," meaning any relying party applying standard policy would have accepted them without suspicion. The same extracted keys were used to compromise NVIDIA GPU Confidential Computing. TEE.Fail is the first demonstrated attack against DDR5 systems, and its significance extends beyond the specific vulnerability: hardware generational improvements do not automatically close the attack surface. That assumption is easy to carry into a deployment and hard to dislodge once it is embedded in a risk model.
The Broader Pattern
TEE.Fail is the most recent dramatic example, but the pattern is not new. The history of TEE security research includes side-channel attacks, speculative execution vulnerabilities, rollback attacks against sealed data, and implementation flaws in attestation quote generation. What these attacks share is a focus on the gap between what the hardware guarantees in the abstract and what the implementation actually delivers under adversarial conditions. The attestation chain provides cryptographic integrity over what is measured; it does not guarantee that what is measured is free of vulnerabilities, nor that the measurement infrastructure itself is unreachable from the attacker's position.
Attestation is one layer in a defense-in-depth posture, not a terminal guarantee. The reference-value supply chain, the verifier infrastructure, the channel binding, and the physical hardware interface are all part of the attack surface. A thorough evaluation of any confidential computing deployment requires accounting for all of them.
What TEE.Fail makes concrete is that the hardware root of trust, the anchor point the entire chain depends on, is reachable from outside the cryptographic boundary if the physical bus is accessible. No software-layer improvement addresses that. Deployments in physically accessible environments, edge hardware, co-location facilities without strict physical controls, and similar settings carry a different risk profile than deployments in hyperscale data centers with rigorous physical security. The attestation architecture is the same in both cases. The threat model is not.
