Source-linked AI summary
Software Grand Exposure: SGX Cache Attacks Are Practical
Ferdinand Brasser, Urs Müller, Alexandra Dmitrienko, Kari Kostiainen, Srdjan Capkun, Ahmad-Reza Sadeghi
TL;DR
SGX cache leakage was assumed but not previously shown to be practical or well characterized. The paper develops uninterrupted cache attacks with noise-reduction techniques and demonstrates confidential-information recovery from RSA decryption and genome indexing, while finding known defenses ineffective in practice.
Problem
Before this work, the practicality and extent of cache-based information leakage from SGX were not well understood, despite concerns that shared caches could leak enclave data.
Method
The paper runs Prime+Probe monitoring in parallel with uninterrupted victim enclaves and develops noise-reduction techniques using privileged adversary capabilities.
Results
The attacks recover confidential information in two cases: 70% of a 2048-bit RSA key after 300 repeated executions, with full-key recovery, and specific human genome sequences.
Takeaways & Limitations
Cache attacks are practical against SGX, affect non-cryptographic applications, and are more effective and harder to mitigate than previous SGX side-channel attacks.
Takeaways & Limitations
Known defenses have serious limitations, while disabling caching can cause severe performance degradation and may be prohibitively expensive for large datasets or expensive computations.
Abstract
from arXiv · showhide
Side-channel information leakage is a known limitation of SGX. Researchers have demonstrated that secret-dependent information can be extracted from enclave execution through page-fault access patterns. Consequently, various recent research efforts are actively seeking countermeasures to SGX side-channel attacks. It is widely assumed that SGX may be vulnerable to other side channels, such as cache access pattern monitoring, as well. However, prior to our work, the practicality and the extent of such information leakage was not studied. In this paper we demonstrate that cache-based attacks are indeed a serious threat to the confidentiality of SGX-protected programs. Our goal was to design an attack that is hard to mitigate using known defenses, and therefore we mount our attack without interrupting enclave execution. This approach has major technical challenges, since the existing cache monitoring techniques experience significant noise if the victim process is not interrupted. We designed and implemented novel attack techniques to reduce this noise by leveraging the capabilities of the privileged adversary. Our attacks are able to recover confidential information from SGX enclaves, which we illustrate in two example cases: extraction of an entire RSA-2048 key during RSA decryption, and detection of specific human genome sequences during genomic indexing. We show that our attacks are more effective than previous cache attacks and harder to mitigate than previous SGX side-channel attacks.
1 Introduction
SGX protects enclave execution from untrusted software, but prior work showed page-fault leakage and only assumed cache leakage. This paper demonstrates practical cache attacks, including recovery of RSA secrets and genomic information, while finding existing defenses ineffective in practice.
- SGX isolates security-critical code from untrusted system software and supports sealing and remote attestation for protected applications.
- OS-controlled paging lets an attacker induce page faults during enclave execution and learn secret-dependent control flow.
- Before this work, cache-based leakage from SGX was assumed but neither demonstrated nor evaluated for practicality and extent.
- 70% of a 2048-bit RSA key was extracted after 300 repeated executions, enabling effective recovery of the full key.
- Monitoring genome-dependent hash-table accesses reliably identified whether indexed human DNA contained a particular microsatellite sequence.
- Known defenses have serious limitations, and none prevented the demonstrated attacks effectively in practice.
2 Background
The paper’s background covers SGX’s enclave architecture, Intel cache organization, and performance monitoring counters. These components explain both the protected execution model and the hardware state relevant to cache side channels.
- Intel SGX: SGX isolates enclave code from system software, encrypts and integrity-protects data leaving the CPU, and relies on the OS to manage enclave memory.
- Intel SGX: During interrupts, SGX hardware saves enclave context and clears registers before transferring control to the OS through an asynchronous enclave exit.
- Cache Architecture: Intel Skylake and Kaby Lake use the relevant cache architecture for this work, with three levels: shared L3 and per-core L1/L2 caches.
- Cache Architecture: L1 separates instruction and data caches, while code and data compete for space in L2 and L3.
- Performance Monitoring Counters: Performance monitoring counters record hardware events such as cycles, cache hits, cache misses, and branch mispredictions.
- Performance Monitoring Counters: SGX’s ASCI feature suppresses enclave-triggered performance monitoring except for fixed cycle counters, preventing PMC observation of enclave cache misses.
3 System and Adversary Model
The threat model gives a privileged Linux adversary control of system software and knowledge of enclave internals while leaving enclave code itself protected. The attacker uses cache-access observations to infer secrets and sensitive inputs.
- System Model: The model assumes SGX isolates an enclave while its execution resources remain shared with untrusted software.
- Adversary Model: A compromised Linux OS manages enclaves, and an attacker process shares a CPU core with the victim enclave using Prime+Probe.
- Adversary Model: The adversary seeks secret enclave information, including keys generated internally or sensitive data received through secure channels.
- Adversary Capabilities: The attacker knows enclave code, memory layout, cache mappings, and initial state, and can replay inputs and reinitialize the enclave repeatedly.
- Attack Scenarios: Secret-dependent memory-access patterns reveal cryptographic keys or genomic subsequences through precomputed data and hash-table accesses.
4 Our Attack Design
The attack adapts Prime+Probe to infer victim memory accesses from cache evictions while reducing noise through privileged control of scheduling, cache isolation, and uninterrupted execution.
- Prime+Probe primes the cache, observes victim-induced evictions, and probes those lines to infer secret-dependent memory accesses.The attacker fills cache lines, lets the victim execute, then measures which attacker lines were evicted.
- Isolation and pollution: The attack reduces noise by isolating the victim and attacker on a dedicated CPU core, preventing other processes from polluting per-core caches.The modified scheduler reserves one core for the victim and attacker, excluding unrelated processes from its L1/L2 caches.
- Isolation and pollution: Using the L1 cache separates instruction accesses from data-cache observations, but unrelated victim data accesses can still create side-channel noise.The L1 instruction/data split prevents code accesses from mapping to the monitored data-cache lines.
- Uninterrupted execution: The victim runs uninterrupted so it cannot detect interruption-based defenses, while the attacker monitors cache effects concurrently through simultaneous multithreading.The attacker and victim execute on separate SMT units of the same core and share the L1 cache.
- Eviction monitoring: Monitoring cache evictions through timing is noisy because distinguishing hits from misses requires precise measurements, motivating alternative event-based monitoring.An L1 cache hit takes at least 4 cycles, making timing measurements sensitive to interference.
5 RSA Decryption Attack
The RSA attack targets fixed-size sliding-window exponentiation in an SGX SDK enclave and infers private-key information from monitored multiplier accesses. Repeated monitoring distinguishes most accesses, enabling recovery of the complete private key.
- Victim enclave: The victim is a standard Intel SGX SDK RSA implementation using fixed-size sliding-window exponentiation, rather than its cache-hardened variant.The implementation uses default compiler settings and decrypts a single message with a randomly chosen private key.
- Victim enclave: A 2048-bit RSA decryption with CRT performs two 1024-bit exponentiations using exponents derived from the private key primes.The two exponents are dp and dq, pre-computed from the private-key primes p and q.
- Victim algorithm: Each exponent window determines which precomputed multiplier g[ei] is accessed, thereby determining the corresponding cache-line update.The attack exploits the mapping from exponent-window values to table entries and cache locations.
- Attack procedure: Monitoring two cache sets every 500 cycles in epochs of 33 probes, repeated 15 times, produced accurate multiplier-access observations.Monitoring multiple multipliers simultaneously or probing more frequently than every 500 cycles significantly reduced detection accuracy.
- Attack results: Figure 5 shows most monitored multiplier accesses as distinguishable colored vertical lines across the 15 monitoring rounds.Each dot represents 16 repeated memory accesses, and each horizontal row represents one complete monitoring round.
- Comparison: The attack required 300 repeated decryptions, compared with tens of thousands for the closest previous LLC-based cache attack, although the scenarios are not directly comparable.The 300 decryptions comprise 10 observed multipliers, 15 repetitions, and two exponents.
6 Genomic Data Processing Attack
The attack targets genome-indexing enclaves by correlating sensitive k-mer insertions with cache-line activity. Monitoring hash-table accesses can reveal whether a specific microsatellite occurs in the processed genome.
- Victim Enclave: Genome preprocessing divides sequences into fixed-length k-mers and stores their positions in a hash table for fast lookup.The hash table also supports extracting k-mer statistics.
- Attack Design: The attack reverses the known hash mapping from observed cache activity to infer which genome subsequences were inserted.Each k-mer insertion accesses a hash-table pointer, producing cache activity linked to the input sequence.
- Attack Design: Cache-line collisions obscure individual table indexes, so each observed line initially corresponds to multiple candidate k-mers.Four table indexes can map to one cache line, preventing direct identification of the inserted k-mer.
- Attack Design: The attacker splits a target microsatellite into k-mers and tracks the resulting sequence of cache lines to identify its occurrence.The ordered cache-line pattern is derived from the target’s component k-mers and their hash-table locations.
- Evaluation: For k = 4, the experiment used 256 possible 4-mers, with eight table entries per 64-byte cache line.Each table entry is an 8-byte pointer, so cache-line observations group eight entries.
- Attack Results: Monitoring cache lines 62, 63, 22, and 39 revealed the target (ATCG)10 near x ≈25,000 when all four lines became active together.The four-line pattern distinguished the target from noise and from other sequences, except for rotations of the microsatellite.
7 Countermeasure Analysis
The section evaluates cache-side-channel countermeasures, finding that existing defenses often impose substantial costs, require difficult data randomization, or fail against uninterrupted parallel attacks.
- Cache disabling: Disabling caches during enclave execution can severely degrade performance, especially for large datasets and expensive computations.The paper notes examples including human-DNA processing, cryptography, and large applications.
- Obfuscation: Periodic cache scrubbing, flushing, or injected noise introduces significant overhead and may not eliminate attacks under simultaneous multithreading.Parallel attackers can observe accesses between rounds and aggregate traces to filter injected noise.
- Application-level hardening: Application-level hardening can require manual developer effort or impose performance overhead up to 4000x.The section presents system-level memory randomization as more broadly applicable, but data-object randomization remains challenging.
- Randomization: SGX Shield randomizes code but not data, so it cannot hide data-dependent memory access patterns.Randomizing data is difficult because of dynamic allocations, large objects, and pointer arithmetic.
- Attack detection: Attack-detection defenses based on frequent enclave interruption cannot defeat attacks that monitor cache accesses without preempting the victim.The attack runs in parallel, avoiding the mode switches and cache flushing on which some defenses rely.
8 Discussion
The discussion generalizes the demonstrated leakage pattern beyond RSA decryption and genome indexing. It identifies table structure, access frequency, and repeated data patterns as determinants of vulnerability.
- Other algorithms: Secret-dependent repeated table accesses can leak information in database indexing, compression, and image-processing algorithms.The authors state that practical attacks on these additional domains remain future work.
- Lessons learned: Larger table entries, frequent accesses, and repeating confidential-data patterns make cache leakage more observable.Table size affects cache-set collisions; access frequency determines monitoring time; repeated patterns generate repeated accesses.
9 Related Work
Related work covers SGX applications, prior cache and page-fault attacks, and hardware-counter techniques, while emphasizing that prior SGX cache-attack evidence was incomplete.
- SGX applications: SGX applications developed for cloud and other settings are potential cache-attack targets when they lack side-channel resistance.The related-work discussion identifies SGX-supported applications as a relevant attack surface.
- Prior SGX attacks: A prior cache attack cannot be quantitatively compared because it omits repetition requirements and ran on a platform more than 10 years old.The missing reporting details prevent a direct performance comparison with the present attack.
- Cryptographic defenses: Side-channel-free RSA implementations use scatter-gather memory layouts, but within-line offset timing can still leak exponent bits.The related work cites CacheBleed as exploiting this residual variation.
- Cache attacks: Earlier cache-attack work established techniques such as Evict+Time and Prime+Probe for monitoring cache behavior.These techniques were applied across cryptographic implementations and multiple hardware platforms.
- Hardware counters: Hardware performance counters can observe an attacker’s Prime+Probe activity, but SGX enclaves do not update the counters directly.The paper therefore uses counters to record cache events generated by the attacker’s monitoring code.
10 Conclusion
The paper demonstrates practical cache attacks against SGX despite uninterrupted enclave execution. Novel noise-reduction techniques recover information from RSA decryption and human-genome indexing, making the attacks difficult to mitigate.
- Conclusion: Cache attacks on SGX are a serious concern, demonstrated through RSA decryption and human-genome indexing.The paper frames these experiments as evidence addressing the previously unresolved practicality and extent of SGX cache leakage.
- Conclusion: The attacks monitor uninterrupted enclave execution and use novel noise-reduction techniques to address the resulting technical challenges.This design targets known countermeasures that rely on interrupting or preempting enclave execution.
- Conclusion: The authors report greater efficiency than previous cache attacks and greater resistance to mitigation than previous SGX side-channel attacks.These are the paper’s stated comparative conclusions across the demonstrated attacks.