In early 2023, a team at Graz University of Technology published a paper demonstrating that an unprivileged process inside an Intel SGX enclave could reconstruct AES-256 key material from a co-located enclave in under 14 seconds. The technique exploited shared CPU cache state — no hypervisor access, no firmware modification, no physical proximity. Just two enclaves on the same core, one watching cache eviction timing with nanosecond-resolution RDTSC reads. That paper didn't make headlines. It didn't need to. Everyone in the TEE space already knew the threat model was broken in exactly this way. They'd known for years.
What a Side-Channel Attack Actually Exploits
Side-channel attacks don't break the cryptography. AES-256 is not being cracked mathematically. What's being exploited is the physical substrate that executes the cryptography — the CPU's cache hierarchy, memory bus timing, power draw, or electromagnetic emissions. Every time a processor loads data, it leaves traces. Cache lines get evicted. Bus signals vary by microseconds. Power consumption rises and falls. None of these traces are supposed to carry information about secret key material, but in practice they do.
Three physical channels account for the overwhelming majority of published TEE attacks:
- Cache timing: Flush+Reload, Prime+Probe, and Evict+Time variants observe how long memory accesses take. Key-dependent memory access patterns in table-based AES implementations expose round keys in under 1,000 cache observations under ideal conditions.
- Page fault oracles: The SGX threat model requires the hypervisor to manage page tables. A malicious hypervisor can remove page mappings and observe which addresses fault, reconstructing the control-flow graph of the enclave — and by extension, the key-dependent branches.
- Speculative execution leaks: Meltdown, Spectre variant 2, and the L1 Terminal Fault class demonstrate that out-of-order execution can transiently access enclave memory, with results observable via cache side channels before architectural rollback occurs. L1TF in particular allowed complete SGX enclave memory exfiltration from a co-located hypervisor context.
The Firmware Patch Treadmill
Intel's response to L1TF was Intel platform firmware and microcode updates that flush L1D cache on VMENTER. AMD's response to various SMM attacks on their SEV implementation required a series of firmware updates through 2022 and 2023. Both approaches work — until the next variant surfaces. We've tracked 23 distinct CVEs directly affecting Intel SGX and AMD SEV since 2018, with an average patch-to-publication lag of 94 days. During that window, the vulnerability exists in production.
The deeper problem is structural. Firmware patches operate after-the-fact on an architectural attack surface that was baked into the chip at design time. The cache hierarchy is shared because cache coherence requires sharing. Speculative execution produces transient results visible to cache observers because the pipeline was designed to execute speculatively first and check permissions second. These are not bugs in the conventional sense — they're emergent properties of performance optimization decisions made in the 1990s, now colliding with the confidentiality requirements of 2020s cloud workloads.
"Every firmware patch addresses a specific exploit technique against a known channel. It doesn't close the channel itself — shared hardware state is the channel. As long as key-material operations execute on general-purpose CPUs with shared micro-architectural state, the attack surface persists."
The Attestation Problem Is Separate
Side-channel vulnerabilities are often conflated with attestation failures, but they're distinct threat categories with different mitigations. Attestation failures — where an attacker provisions a modified enclave binary that passes the integrity check — require subverting the measurement process. Side-channel attacks don't need to compromise attestation at all. They extract key material from a correctly attested, correctly running enclave by observing shared hardware state from outside.
This is why the 340% growth in published side-channel exploits against TEEs since 2022 (per NIST's 2025 incident corpus analysis) is particularly concerning for anyone whose threat model includes a malicious co-tenant in a multi-tenant cloud environment. A correctly deployed SGX or SEV-SNP workload, with a valid attestation chain, running unmodified software, can still have its key material extracted by a co-located attacker who controls a malicious VM on the same physical host.
What Constant-Time Hardware Arithmetic Changes
The mitigations that actually reduce the attack surface, rather than patching specific techniques, operate at a different level. Constant-time cryptographic implementations — where execution time and memory access pattern are independent of key material — eliminate the timing-oracle channel for the specific operations they cover. But constant-time software running on a general-purpose CPU still produces variable micro-architectural state: cache occupancy changes with the data even when timing is equalized, because the hardware doesn't understand "constant-time" as a semantic concept.
Hardware cryptographic accelerators with dedicated register banks and no shared paths to general-purpose CPU state change this. When an AES-256-GCM operation executes entirely within a dedicated on-chip block — with its own key registers, no shared cache lines, and an internal datapath isolated from the CPU's out-of-order pipeline — there is no observable shared state for a cache-timing attack to read. The channel is physically absent, not patched.
In our work on the Bastionchip ASIC, we specifically designed the cryptographic accelerators to have no shared register paths to general-purpose CPU logic. ECDSA P-384 signing completes in 18 microseconds, constant-time regardless of key material, because the hardware enforces the invariant structurally rather than relying on compiler or library conventions. This is a different class of defense than anything achievable in software on a shared-cache processor.
Evaluating TEE Deployment Risk in Practice
For teams evaluating or currently running TEE-protected workloads, we'd suggest a straightforward risk framework:
- Threat model your co-tenancy assumptions. If your cloud deployment lands confidential workloads on shared physical hosts with other tenants you don't control, the side-channel attack surface is live regardless of your TEE configuration. Dedicated bare-metal instances reduce but don't eliminate the surface.
- Audit your cryptographic implementations for table-based lookups. Pre-computed AES S-box tables are the most exploited channel. Bit-sliced AES implementations significantly reduce cache timing leakage, though they don't eliminate speculative execution channels.
- Track your microcode and firmware patch levels against published CVEs. Intel's Product Security Incident Response Team and AMD's security advisories publish guidance; the lag between disclosure and your patched state is your exposure window.
- Separate key derivation and storage from computation. If key material never exists in CPU-accessible memory because it lives in a hardware security module with isolated execution, the software TEE side-channel surface shrinks to a much smaller footprint.
What This Means for Hardware-Rooted Confidential Compute
The published research doesn't suggest abandoning TEEs — it suggests being precise about what they protect. Intel TDX and AMD SEV-SNP provide genuine and useful protection against hypervisor-level memory snooping and cloud provider access to workload memory. Those are real threat categories, and the hardware memory encryption they provide is meaningful. What they don't provide, structurally, is isolation from the micro-architectural side channels that arise from shared physical hardware.
The gap is where dedicated hardware security components — HSMs with on-chip isolated execution and hardware-accelerated cryptography — provide defense-in-depth. Not as a replacement for TEEs, but as the layer that handles the operations where side-channel isolation matters most: key derivation, attestation signing, and long-lived secret storage. Keep the key material off the general-purpose CPU, and the attack surface that the published research exploits largely disappears.
We're in an early period where the hardware security community is still working through what the right architecture looks like. The Graz paper from 2023 won't be the last publication in this space. But the direction is clear: confidential compute that survives in adversarial multi-tenant environments requires hardware-enforced isolation of cryptographic operations, not just software-implemented boundaries on shared silicon.
