Side-Channel Attack Surfaces in SGX Enclaves

Conventional side-channel attacks impose real costs on the attacker. Noise requires statistical averaging across many trials. Repeatability demands the victim reliably perform the same operation. Physical proximity or privileged instrumentation may be prerequisites. These constraints, taken together, limit practical exploitability in most settings.

The OS-level adversary that SGX explicitly tolerates operates under almost none of them.

Scheduling is attacker-controlled, so enclave execution can be interrupted at will. Page table management belongs to the attacker, so memory access permissions for enclave pages can be manipulated unilaterally. Interrupt delivery timing is programmable. These three capabilities combine to produce what researchers term controlled side-channel attacks: observations that are deterministic rather than probabilistic. No statistical averaging. No repeated runs. A single execution trace is often sufficient to reconstruct sensitive enclave behavior.

The OS adversary can also compose attack classes. A page table manipulation that induces faults on specific pages isolates individual memory accesses; a subsequent cache-timing measurement reads the access pattern within that page. No single primitive is required to do all the work.

This asymmetry, strong software isolation enforced by an entity that is itself the defined adversary, is the structural condition every subsequent attack class exploits. Intel built a hardened vault and handed the key to the person the vault is supposed to keep out, at least for this particular category of attack. One reading of that design is oversight. Another is that it represents a deliberate boundary, one that shifts responsibility for the remaining attack surface onto enclave developers. The research record fits both readings well enough that I have never found the question cleanly settleable, which is itself worth noting before proceeding.

How page table control turns memory access patterns into an open book

In 2015, Xu et al. demonstrated at IEEE S&P what they called controlled-channel attacks. The mechanism is straightforward: mark enclave pages as non-present in the page table, collect a page fault on every new page the enclave touches, and reconstruct the enclave's coarse control-flow graph from the fault sequence. Each fault corresponds to one page transition. There is no noise to average out.

A fault-less variant exists for quieter operation. Rather than inducing faults, the attacker reads the accessed and dirty bits in page table entries and observes caching behavior of page table memory itself. The granularity is identical, 4 KB page boundaries, but the noise signature is lower and detection is harder.

Both variants share a granularity ceiling. They reveal which page was touched, not which byte within it. For many secrets, that ceiling is too coarse to be conclusive. Gyselinck et al. demonstrated in 2018 that abusing the x86 segmentation unit in 32-bit SGX applications can push observation to byte-level precision under specific conditions, effectively piercing that limit.

Even without byte-level refinement, page-level leakage is frequently sufficient. Library function call graphs have distinguishable page access footprints. Image processing branches produce characteristic fault sequences. Cryptographic table lookups in non-constant-time implementations touch predictable page subsets. The signal at 4 KB resolution is richer than it first appears.

Here is the thing that took me some time to sit with: if page-level granularity already suffices to reconstruct meaningful secrets in many real implementations, byte-level precision changes the attacker's practical capability less than one might expect. It closes the cases that page-level analysis leaves ambiguous. That is a narrower marginal gain than the technique's sophistication implies, but it is still a gain, and the line between ambiguous and conclusive matters a great deal when the secret is a private key.

Cache-timing attacks and why SGX enclaves are no safer than any other software

The four canonical cache-timing primitives, Evict+Time, Evict+Reload, Prime+Probe, and Flush+Reload, exploit one measurable physical fact: a cache hit takes tens of cycles, a cache miss takes hundreds. SGX provides no mechanism to suppress or obfuscate memory access patterns. Enclaves share the cache hierarchy with untrusted code. All four primitives apply to enclave targets without modification. This is not a subtle point, but its implications are routinely underweighted in enclave threat modeling.

Two distinct enclave targets deserve separate treatment. Code access patterns reveal secret-dependent execution paths: which branches were taken, which functions were called. Data access patterns reveal secret-dependent object usage: which lookup table entries were read, which operands were loaded. Both are exploitable; each requires somewhat different defensive treatment, and an implementation that addresses one often leaves the other open.

The FAU Erlangen-Nürnberg group demonstrated an access-driven cache-timing attack against AES running inside an SGX enclave, recovering the secret key by examining 480 encrypted blocks on average in under ten seconds. That result is years old now, which matters precisely because it establishes the baseline. AES-NI and constant-time cipher implementations raise the bar, but they do not dissolve the underlying threat.

CrossTalk complicates the defensive picture further. Most cache-timing mitigations assume the attacker shares a physical core with the victim, or at least an L3 cache slice. CrossTalk invalidates that assumption by sampling an undocumented staging buffer shared across all cores, enabling cross-core attacks on enclave memory. The attacker and victim need not be co-located on the same core. Mitigations designed against single-core threat models are incomplete against this variant, and a substantial fraction of deployed hardening guidance predates this finding, which means a lot of real deployments are operating on an incomplete map.

Branch prediction structures as a control-flow side channel

The Branch Target Buffer is a shared microarchitectural structure, unpartitioned per process or per privilege level. Lee et al. demonstrated that an attacker operating outside an enclave can manipulate BTB state to infer sensitive control-flow decisions made inside it. The attacker primes the BTB with known entries, observes which entries are evicted or cause mispredictions after enclave execution, and maps collisions back to taken branch addresses within the enclave. The mechanism works in both directions: inference out, and, as later work showed, injection in.

The Frontal Attack, published at USENIX Security 2021 by Puddu et al., approaches the same problem from a different microarchitectural angle. Rather than relying on cache state, it exploits timing differences in how the CPU frontend fetches and decodes instructions depending on which execution path was taken, leaking control-flow information without any cache-based observation at all.

Branch prediction state is not flushed on enclave entry or exit. Prior enclave execution leaves observable residue in shared prediction structures. A subsequent attacker-controlled execution can read that residue, inferring what the enclave did even after the enclave has exited and architectural state has been cleaned up.

There is a defense asymmetry here worth holding clearly in mind. Constant-time coding discipline, which eliminates data-dependent memory addresses and secret-dependent conditional branches at the instruction level, addresses cache-timing and page-fault leakage reasonably well. It does not eliminate data-dependent branch targets in the branch predictor's view, because the predictor operates on physical addresses and micro-op patterns that constant-time source code does not fully control. Enclave code that satisfies a constant-time audit can still be vulnerable to branch prediction side channels. The two failure modes require separate review criteria, and they do not often get separate review criteria in practice. The argument that rigorous constant-time discipline covers the branch predictor case implicitly does not survive contact with how branch predictors actually operate at the microarchitectural level; the abstraction is just too leaky.

Interrupt-based single-stepping and why AEX-Notify did not close the door

SGX's Asynchronous Enclave Exit mechanism is a defensible design choice in isolation: any interrupt causes the enclave to save state and exit cleanly, resuming when the interrupt is handled. The problem is that the attacker controls interrupt delivery timing through the OS. The SGX-Step attack exploits this by configuring the APIC timer to fire after every instruction, achieving deterministic single-stepping that reduces observation granularity to one instruction per measurement window, producing a remarkably precise execution trace of a supposedly opaque enclave.

Intel responded with AEX-Notify, an ISA extension that modifies enclave re-entry to prevent attackers from reliably extending instruction execution windows and inferring interrupt landing points. The design goal was to make the single-stepping primitive unreliable enough to be practically useless.

In October 2025, Dutly et al. at ETH Zurich published AEX-NStep, accepted at IEEE S&P 2026. Their central finding is that deterministic single-stepping is not a prerequisite for interrupt counting attacks to be practical. AEX-NStep constructs two probabilistic interrupt counting attacks that function on AEX-Notify-enabled enclaves and demonstrates that AEX-Notify's guarantee of obfuscated forward progress does not hold under these attack conditions. The practical result is concrete: ECDSA key leakage from an AEX-Notify-enabled SGX enclave.

AEX-Notify hardened one specific stepping primitive. The underlying interrupt-counting capability survived the architectural countermeasure. This pattern has appeared often enough in SGX's research history that it probably deserves more weight in architectural security evaluations than it typically receives. A targeted mitigation narrows an attack class; it does not close it. Those are different things, and conflating them is a recurring failure mode in how these mitigations get communicated to practitioners.

Transient execution attacks and how SGX's design makes some of them easier

Out-of-order and speculative execution produce transient microarchitectural state: cache lines loaded, prediction structures modified, buffers populated. That state persists briefly even when the triggering instruction's architectural effect is rolled back, and the window is measurable.

Foreshadow exploited speculative execution flaws to read enclave secrets from the L1 cache without kernel access and without any assumptions about enclave code behavior. SgxPectre exploits the race between speculative memory references and branch resolution: an attacker outside the enclave manipulates branch prediction to redirect speculative control flow inside the enclave transiently, producing observable cache traces without breaching the isolation boundary architecturally. The enclave code runs, but along an attacker-chosen path.

Load Value Injection, disclosed in 2020 by researchers at KU Leuven, WPI, TU Graz, the University of Michigan, and the University of Adelaide, reverses the Meltdown direction. Rather than leaking data out of the enclave, it injects attacker-controlled values into transient load operations, then uses Spectre-style gadgets to exfiltrate secrets constructed from those injected values. SGX specifically facilitates LVI because page tables for enclave memory are managed by untrusted software. An attacker can deliberately create page faults for enclave loads, which is precisely the triggering condition LVI requires. The authors claimed at disclosure that LVI bypassed all prior transient-execution mitigations, a claim that has not been meaningfully disputed.

CrossTalk's transient-execution dimension samples an undocumented staging buffer shared across all physical cores, enabling leakage from enclaves even when attacker and victim run on different cores entirely.

Foreshadow, SgxPectre, LVI, CrossTalk: each exploited a different internal CPU buffer or timing window. The attack surface here is bounded by the completeness of CPU microarchitecture documentation, which is incomplete by design. I have watched each of these disclosures arrive with the same basic structure: a buffer nobody had publicly characterized, a timing window nobody had closed, an assumption about isolation that turned out to be wrong below the level of the specification. Anchoring a security argument to an incomplete map is not a comfortable place to stand.

Power side channels and what software-only isolation cannot stop

The PLATYPUS attack, published by Lipp et al., demonstrated that Intel's Running Average Power Limit interface could be accessed without elevated privileges and used to construct a power side channel requiring no physical access to the target system. At instruction granularity, RAPL leaks differences between instruction types, Hamming weights of operands, and cache-hit versus cache-miss status of load destinations. That granularity is sufficient to distinguish individual operations inside an enclave. The SGX-specific results are concrete: AES-NI keys extracted from an SGX enclave in 26 hours, RSA private keys extracted from mbed TLS in 100 minutes by inferring instruction sequences from power traces.

Intel responded by restricting RAPL access to reduce its precision. Follow-on research demonstrated that the interface remains exploitable. Frequency scaling and CPU throttling provide related power-correlated signals; researchers have used both to leak secrets from enclaves. The restriction did not close the class.

Power leakage is a physical property of computation. Every instruction dissipates energy in patterns that reflect the data being processed, and no software isolation mechanism can suppress physical emanations. This is not a gap in SGX's implementation; it is a category of attack that software-only isolation cannot address by definition. Every software-focused mitigation framework is therefore incomplete by construction against this class. What that implies for the broader project of enclave security is not a comfortable place to leave the analysis: if a class of attacks exists that no software countermeasure can reach, any security argument resting entirely on software controls has a structural gap that careful coding discipline cannot fill, no matter how thorough the audit.

Physical bus interception and the limits of memory encryption without integrity

The WireTap attack, disclosed at ACM CCS 2025 by researchers at Georgia Tech and Purdue University, placed a passive interposer on the DDR4 memory bus to observe encrypted traffic between the CPU and DRAM. Equipment cost: under $1,000. No malware was required.

The vulnerability is not weak encryption. SGX uses deterministic encryption for memory, meaning the same plaintext at the same address produces the same ciphertext. An attacker who observes ciphertext repeatedly can build a ciphertext oracle and perform full key recovery without decrypting a single block directly. The researchers targeted SGX's Quoting Enclave, which holds the ECDSA private key used for remote attestation. Recovering that key allows an attacker to forge arbitrary SGX attestation reports. Remote parties relying on attestation to verify enclave integrity cannot distinguish a legitimate report from a forged one.

WireTap also enables replay and memory aliasing because SGX's memory encryption lacks per-access freshness guarantees at the DRAM interface. The absence of integrity protection compounds the confidentiality issue in ways that are not always obvious from reading the SGX specification in isolation.

The researchers validated the attack against multiple blockchain projects using SGX: Secret Network, Phala Network, and Crust Network. Phala subsequently announced deprecation of SGX and migration to Intel TDX and NVIDIA Confidential Computing. That decision reflects a deployment calculus specific to Phala's threat model, not a universal verdict on SGX, but it illustrates that deployment contexts with physical access considerations require a different analysis than cloud-only deployments.

Confidentiality-only memory encryption, without integrity or freshness, is insufficient against a physical adversary. That adversary sits entirely outside the software threat model SGX was designed to address, which is precisely why the attack succeeded, and why the specification's silence on the point is not reassuring.

What these attack classes have in common and what that means for enclave developers

Every attack class discussed here exploits a resource SGX shares with, or delegates management of to, an untrusted layer: the page table manager, the cache hierarchy, the branch predictor, the interrupt controller, the power measurement interface, or the memory bus itself. Isolation and leakage resistance are not the same property. SGX achieves strong isolation of memory contents while leaving execution behavior observable through shared physical and microarchitectural state. Conflating the two is where enclave security designs reliably go wrong.

The mitigation landscape is asymmetric in a way that should discipline developer expectations. Software defenses, oblivious RAM, constant-time coding, memory access pattern obfuscation, can meaningfully reduce exposure to page-fault and cache-timing attacks. They have no purchase on power channels or physical bus interception. And even within the software-addressable classes, the research community has consistently found that architectural countermeasures close specific attack vectors without closing the underlying classes. AEX-Notify narrowed one stepping primitive; AEX-NStep demonstrated the underlying capability persisted. RAPL restrictions reduced one power channel; frequency scaling provided another. Meltdown mitigations preceded LVI.

For developers building enclave-based systems, this accumulation of evidence argues for something closer to a posture than a checklist. I am skeptical of that framing too, because posture is easy to invoke and genuinely hard to operationalize. But treating each attack class as a discrete item to check off has not fared well against a decade of research that keeps finding new territory inside supposedly closed classes.

Some practical orientations follow from the above. Treat the OS as an active adversary in code design, not merely an untrusted guest; the threat model SGX delegates to enclave developers is not hypothetical. Audit cryptographic code separately for data-dependent memory access patterns and data-dependent branch targets, because they require different mitigations and addressing one does not imply the other. Take deployment environment seriously: a cloud enclave on multi-tenant hardware faces a different realistic threat subset than an enclave on a physically accessible embedded device, and WireTap demonstrates that a threat model excluding physical adversaries can be invalidated for under $1,000. Platform firmware interfaces, power measurement APIs, and frequency scaling signals belong in threat models.

SGX's exclusion of side-channel attacks from its threat model is a documented boundary, not a specification flaw. What a decade of watching this research accumulate makes harder to dismiss is that the boundary is holding in the sense Intel intended while the attack surface on the other side of it keeps expanding. Enclave developers inherit that expansion whether or not they planned for it.