PaperlayerView exact revision on arXiv

Source-linked AI summary

Malware Guard Extension: Using SGX to Conceal Cache Attacks

Michael Schwarz, Samuel Weiser, Daniel Gruss, Clémentine Maurice, Stefan Mangard

arXiv:1702.08719v3cs.CR

TL;DR

The paper asks whether SGX enclaves can conceal malware that attacks co-located enclaves despite SGX’s restrictions and isolation goals. It develops an enclave-based Prime+Probe attack against mbedTLS RSA and demonstrates automated private-key recovery in native and Docker environments. The attack extracts 96% of a 4096-bit RSA private key from one trace and recovers the full key from 11 traces within 5 minutes.

  • Problem

    SGX was intended to protect software from other processes, the operating system, and physical attackers, but enclave malware and side-channel attacks lack several required primitives.

  • Method

    The paper combines cache and DRAM side channels with enclave timing and eviction-set techniques to monitor RSA cache accesses from a malicious co-located SGX enclave.

  • Results

    96% of a 4096-bit RSA private key is extracted from a single Prime+Probe trace, and the full key is recovered from 11 traces within 5 minutes.

  • Takeaways & Limitations

    The demonstrated malware runs on real SGX hardware, remains concealed by SGX protection features, and succeeds across Docker container boundaries.

Abstract

from arXiv · show

In modern computer systems, user processes are isolated from each other by the operating system and the hardware. Additionally, in a cloud scenario it is crucial that the hypervisor isolates tenants from other tenants that are co-located on the same physical machine. However, the hypervisor does not protect tenants against the cloud provider and thus the supplied operating system and hardware. Intel SGX provides a mechanism that addresses this scenario. It aims at protecting user-level software from attacks from other processes, the operating system, and even physical attackers. In this paper, we demonstrate fine-grained software-based side-channel attacks from a malicious SGX enclave targeting co-located enclaves. Our attack is the first malware running on real SGX hardware, abusing SGX protection features to conceal itself. Furthermore, we demonstrate our attack both in a native environment and across multiple Docker containers. We perform a Prime+Probe cache side-channel attack on a co-located SGX enclave running an up-to-date RSA implementation that uses a constant-time multiplication primitive. The attack works although in SGX enclaves there are no timers, no large pages, no physical addresses, and no shared memory. In a semi-synchronous attack, we extract 96% of an RSA private key from a single trace. We extract the full RSA private key in an automated attack from 11 traces within 5 minutes.

I. INTRODUCTION

The paper challenges SGX’s isolation guarantees by demonstrating malware inside an enclave that attacks co-located enclaves while concealing its code. It evaluates this threat in native and Docker-based environments.

  • SGX protection model: SGX protects enclave code and data from malicious privileged software and physical attackers through hardware-isolated, encrypted memory.Enclaves execute in protected memory areas isolated from the operating system by hardware.
  • Motivation: Prior work argued that enclave malware was impractical because enclaves lack user-space privileges, system calls, I/O, and key side-channel primitives.The paper identifies the absence of timers, large pages, physical addresses, and shared memory as major restrictions.
  • Contribution: The paper demonstrates cache attacks from a malicious enclave against secret-dependent computations in co-located enclaves.The attack recovers RSA keys by monitoring cache access patterns during signature processing.
  • Contribution: The malware code remains invisible to the operating system through SGX isolation and encrypted attack-code provisioning after remote attestation.The attack also succeeds across Docker containers, showing that this additional isolation does not prevent the attack.
  • Contribution: The contributions include recovering physical-address bits without 2 MB pages, achieving highly accurate enclave timing, and automating end-to-end RSA key recovery.The evaluation targets the widely used mbedTLS RSA implementation.

B. Microarchitectural Attacks

Microarchitectural attacks infer activity in other processes from hardware timing behavior, with cache attacks providing a route to cryptographic-secret recovery. The paper positions SGX as restrictive but still vulnerable to enclave-to-enclave cache and DRAM attacks.

  • Attack background: Microarchitectural attacks exploit hardware properties to infer information about other processes, and cache attacks have recovered AES and RSA secrets.Cache timing differs between CPU caches and main memory.
  • Cache organization: The last-level cache is shared across CPU cores, and physical-address bits determine cache-set placement while the CPU selects the cache way.The lowest 6 bits determine the byte offset, followed by log2 S bits for the cache set.
  • Prime+Probe: Prime+Probe primes a cache set with an eviction set, then uses the elapsed prime time to infer victim accesses.The eviction set contains addresses mapping to the same cache set, with its size depending on cache associativity and replacement policy.
  • Related techniques: Flush+Reload requires shared memory, whereas DRAM timing attacks exploit shared row buffers without requiring shared memory.These techniques provide alternative cross-boundary observation mechanisms.
  • SGX implications: SGX prevents Flush+Reload through memory isolation but still permits enclaves to mount DRAM-based attacks on other enclaves sharing the physical EPC.Intel does not treat side channels as part of the SGX threat model, despite recommending SGX for protecting secrets.
  • RSA target: RSA square-and-multiply exposes exponent bits because multiplication occurs only for selected exponent bits, although current mbedTLS uses constant-time Montgomery multiplication.The paper targets secret-dependent accesses that remain despite using the same multiplication routine for squaring and multiplication.

III. THREAT MODEL AND ATTACK SETUP

The threat model places an unprivileged attacker and victim on the same host, with the victim’s RSA computation protected inside SGX. The attack combines online cache monitoring with offline private-key recovery and hides its code inside an enclave.

  • Threat model: The attacker and victim run as separate SGX enclaves on the same physical machine, which may be a local computer or cloud host.The cloud setup can place the victim inside a Docker container.
  • Attack phases: The online phase locates and monitors cache sets during triggered signatures, while the offline phase recovers the private key from collected traces.This separates measurement from key reconstruction.
  • Threat model: The attacker triggers the victim’s signing API and seeks to stealthily extract the private key from the victim enclave.Both attacker and victim consist of an enclave and a loader.
  • Victim computation: The attack targets RSA exponentiation in mbedTLS, which uses a fixed-window-size-1 square-and-multiply algorithm in the Montgomery domain.The authors state that the approach can extend to arbitrary window sizes if successful for window size 1.
  • Stealth mechanism: The malware encrypts its attack code and decrypts it only after successful remote attestation, using SGX’s writable-and-executable pages to support self-modification.Exfiltrated data is passed to the loader only in encrypted form.

D. Operating System and Hardware

The attack assumes only co-location on a Skylake host and operates without privileged software, while SGX restrictions require new timing, eviction-set, and monitoring techniques. The implementation uses a counting thread and a register-held shadow counter to obtain fine-grained timing.

  • Assumptions: The attacker requires no malicious operating system or privilege escalation and works on a fully patched operating system with no known software vulnerabilities.Both attacker and victim are unprivileged user-space applications.
  • Assumptions: The main hardware assumption is that attacker and victim share a Skylake host, whose last-level cache is shared across all CPU cores.This includes personal computers and co-located Docker instances in the cloud.
  • Required primitives: Prime+Probe requires a high-resolution timer and an eviction set, but SGX prevents standard implementations because enclave code cannot use rdtsc or rdtscp.Enclaves also cannot directly translate virtual addresses to physical addresses or rely on large pages.
  • High-resolution Timer.: A dedicated counting thread emulates rdtsc by incrementing a shared counter, providing timing differences rather than absolute timestamps.The target resolution is approximately 10 cycles for distinguishing cache hits, misses, and DRAM row behavior.
  • High-resolution Timer.: The implementation achieves one counter increment every 4.7 cycles, improving approximately 2% over gcc’s highest-optimization assembly output.Loop unrolling was tested but reduced performance on the test machine.
  • High-resolution Timer.: A register-held shadow counter eliminates repeated CPU reads from memory and improves timing resolution.Arithmetic operations use the register operand rather than operating directly on the memory-resident counter.
  • Eviction sets: The attack must construct eviction sets without physical-address translation, motivating techniques that combine DRAM and cache observations.The lack of SGX large-page support makes prior large-page-based methods inapplicable.

Eviction Set Generation.

The attack reconstructs cache-set information without large pages or physical-address access, using DRAM timing and contiguous enclave memory before pruning candidate addresses into minimal eviction sets.

  • SGX enclaves cannot directly translate virtual addresses to physical addresses or use large-page assumptions for eviction-set construction.
  • The method exploits physically contiguous enclave pages and DRAM row-conflict timing to recover cache-set information from virtual addresses.Pairs mapping to the same bank but different rows produce distinctive timing differences.
  • Four address pairs exist within each 4 MB physical block, with each pair mapping to the same bank but different rows and lying 64 B apart.
  • The recovered cache-set index uses bits 6–17, and adding multiples of 256 KB generates addresses with the same cache-set index.
  • Because cache slices cannot be calculated directly from available information, pruning removes addresses that map to other slices.

B. Identifying Vulnerable Sets

The attacker scans cache sets with Prime+Probe while the victim performs RSA exponentiation, identifying sets whose activity follows the target’s initialization, exponentiation, and cleanup pattern.

  • Each cache set is primed with an eviction set and then probed while the victim executes the exponentiation step.
  • A high probe runtime indicates victim activity because at least one attacker address was evicted from the monitored cache set.
  • The target signature consists of an initial high-cache-usage peak, secret-dependent exponentiation activity, and a final cleanup peak.
  • Peak detection identifies the rightmost peak and an earlier peak within a specified range to classify cache sets used by the target buffer.

C. Monitoring Vulnerable Sets

After locating vulnerable cache sets, the attacker repeatedly monitors them during RSA signatures, minimizing measurement overhead and retaining timestamps for offline processing.

  • The same Prime+Probe measurement used for set discovery collects traces from cache sets used during exponentiation.
  • Deterministic heap allocation keeps the attacked buffer at the same address across consecutive exponentiations, enabling multiple traces.
  • Only cache-miss timestamps are saved during measurement to maintain a high sampling rate and limit additional cache noise.
  • Cache-miss intervals indicate high victim cache usage, while intervals without misses indicate no victim cache usage; the sampling rate varies accordingly.Post-processing must account for the resulting non-constant sampling interval.
  • Key recovery processes recorded traces in three stages: preprocessing, partial-key extraction, and merging partial keys into the private key.

A. Pre-processing

The preprocessing pipeline converts variable-rate cache-miss measurements into resampled traces, detects reliable peaks for partial-key extraction, and merges noisy partial keys bitwise.

  • Raw measurements are filtered and resampled because cache misses delay subsequent measurements and create a varying sample rate.
  • The resampling procedure evaluates points 1000 cycles apart using normalized squared measurements within a 10 000-cycle window.
  • A. Pre-processing: Peak detection removes duplicate or low peaks using an adaptive threshold based on the median of the previous 10 detected peaks.Peaks below 90% of that threshold are discarded.
  • B. Partial Key Extraction: Remaining peaks represent RSA exponent ‘1’ bits, while gaps between peaks reveal ‘0’ bits indirectly because square operations do not trigger monitored cache activity.‘0’ bits correspond to one multiplication and are roughly twice as fast as ‘1’ bits.
  • B. Partial Key Extraction: Partial keys can contain bit flips, insertions, and deletions caused by false peak decisions or attacker and victim descheduling.
  • C. Final Key Recovery: The final recovery proceeds from the most-significant bit, using majority votes and local edit-distance corrections to reconcile inconsistent partial keys.

B. Native Environment

The native attack identifies vulnerable cache sets and reconstructs an RSA private key from noisy cache traces. It recovers about 96% from one trace and the full key from 11 traces.

  • The attacker and victim enclaves run on the same machine, with signatures triggered through the victim enclave’s public API.
  • The attacked buffer spans 9 cache sets, but the attack selects 1 of 6 low-error sets because 3 sets suffer excessive noise.Noise mainly results from cache-set misalignment and hardware prefetching.
  • 340 trials are required on average to detect one vulnerable cache set among 2048 sets.
  • 72 s is the maximum estimated time to capture a trace from a vulnerable cache set, while cache-set detection takes under 3 min when successful.The estimate uses 0.21 s per cache set.
  • The 734-cycle Prime+Probe measurement avoids artificially slowing the victim and preserves stealthiness.A trace spans 220.47 million CPU cycles on average, and the average multiplication takes 107,662 cycles.
  • 96% of the RSA private key is recovered from a single trace.
  • 11 traces recover the full RSA private key without bit errors in 18.5 s, with offline key recovery taking under 130 s.

Generalization.

The attack generalizes beyond the native setup: it succeeds against unprotected applications and across Docker containers. Virtual-machine applicability is presented as an expectation rather than an experiment.

  • The setup shares the host SGX driver between containers to enable SGX enclaves.
  • Docker leaves memory- and CPU-dependent operations, including caches, unaffected because they are not virtualized.
  • Docker containers do not add protection: unchanged malware attacks victims within a container and across different containers using the same number of traces.
  • The authors expect the malware to work across virtual machines with minor changes or without adaptations because enclaves share the last-level cache there.This is based on experimental KVM support and prior cross-VM cache attacks.

VII. COUNTERMEASURES

The paper discusses source-level countermeasures, including exponent blinding and bit slicing, while emphasizing their algorithmic, hardware, performance, or randomness constraints.

  • Countermeasures are grouped by whether they modify the enclave, operating system, or hardware.
  • Exponent Blinding: Exponent blinding randomizes the RSA exponent for each signature, making repeated-trace recovery depend on collisions of the same blinding value.
  • Exponent Blinding: A sufficiently large 64-bit blinding factor makes such collisions infeasible, but increases the exponent and creates a performance trade-off.
  • Exponent Blinding: Exponent blinding does not help when a key can be recovered from a single trace and requires a random number source.
  • Bit Slicing: Bit slicing removes lookup tables and branches, preventing cache attacks for supported cryptographic algorithms.
  • Bit Slicing: Bit slicing is algorithm-specific and requires cryptography-library support plus SSE hardware for reasonable performance.

B. Operating System Level

Operating-system-level defenses face a trust-model conflict: protecting enclaves from malicious enclaves requires trusting the operating system, which weakens SGX’s premise. The paper discusses detection and cache-partitioning countermeasures, while showing that timer removal alone is ineffective.

  • Timer defenses: Removing precise timers does not prevent a high-resolution Prime+Probe attack and can yield lower resolution than the enclave’s timing thread.The timing thread can provide higher resolution than the native high-resolution timestamp counter on recent microarchitectures.
  • Detection: Performance counters cannot detect enclave cache activity, making current antivirus and related detection mechanisms unable to detect the malware.Intel does not expose SGX enclave activity in thread-specific or last-level-cache performance counters.
  • Cache partitioning: Enclave coloring partitions cache sets among enclaves, but its software implementation requires a trusted operating system.This requirement conflicts with SGX’s goal of supporting enclaves despite an untrusted operating system.
  • Scope: System-wide cache coloring is needed to protect operating systems and other processes, but coloring cannot prevent malware inside enclaves.The cited evaluation found cache coloring feasible only for a small number of partitions.
  • Heap randomization: Heap randomization changes cache-set locations, preventing automatic cache-set detection and increasing the required traces by multiple orders of magnitude.A malicious operating system can restrict allocations to selected cache sets, reducing the randomization benefit.

Intel CAT.

The paper considers hardware-assisted isolation and secure memory as defenses against cache and DRAM side channels. These approaches can block sharing-based attacks, but their applicability depends on hardware support and the system’s trust model.

  • Intel CAT: Intel CAT can restrict cores to cache slices or pin cache lines, and modifying enclave entry could eliminate cache sharing with outside software and co-located enclaves.The proposed hardware-level use would also protect the operating system and user programs from malicious enclaves.
  • Secure RAM: A secure memory element inside the CPU would store sensitive data without caching, preventing cache and DRAM-based attacks.The design requires fast memory to avoid performance penalties and could support parallel execution with one element per core.
  • Threat demonstrated: SGX malware can steal private keys in an automated end-to-end attack despite having no timers, large pages, physical addresses, or shared memory.The paper reports this attack on real SGX hardware.
  • Measured outcome: The attack extracts 96 % of a 4096-bit RSA private key from one Prime+Probe trace and recovers the full key from 11 traces within 5 minutes.It targets mbedTLS despite its constant-time multiplication primitive.
Loading 1702.08719v3…