This is how they did it ......
Quote
Using Intel's SGX to Attack Itself
Researchers have
demonstrated using Intel's Software Guard Extensions to hide malware and steal cryptographic keys from inside SGX's protected enclave:
Malware Guard Extension: Using SGX to Conceal Cache Attacks
Abstract: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.
Quote:
Boffins show Intel's SGX can leak crypto keys
Software Guard Extensions are supposed to hide data. But the 'Prime+Probe attack' fixes that
By
Richard Chirgwin
Posted in
Security,
7th March 2017 05:58 GMT
A researcher who in January helped highlight
possible flaws in Intel's Software Guard Extensions' input-output protection is back, this time with malware running inside a protected SGX enclave.
Instead of protecting the system, Samuel Weiser and four collaborators of Austria's Graz University of Technology
write that the proof-of-concept uses SGX to conceal the malware – and that within five minutes, he can grab RSA keys from SGX enclaves running on the same system.
It's the kind of thing SGX is explicitly designed to prevent. SGX is an isolation mechanism that's supposed to keep both code and data from prying eyes, even if a privileged user is malicious.
Weiser and his team created a side-channel attack they call “Prime+Probe”, and say it works in a native Intel environment, or across Docker containers.
The PoC is specifically designed to recover RSA keys in someone else's enclave in a complex three-step process: first, discovering the location of the victim's cache sets; second, watch the cache sets when the victim triggers an RSA signature computation; and finally, extracting the key.
As the paper puts it:
We developed the most accurate timing measurement technique currently known for Intel CPUs, perfectly tailored to the hardware. We combined DRAM and cache side channels, to build a novel approach that recovers physical address bits without assumptions on the page size. We attack the RSA implementation of mbedTLS that is used for instance in OpenVPN. The attack succeeds despite protection against sidechannel attacks using a constant-time multiplication primitive. We extract 96 % of a 4096-bit RSA private key from a single Prime+Probe trace and achieve full key recovery from only 11 traces within 5 minutes.
The attack even works across different Docker containers, because the Docker engine calls to the same SGX driver for both containers.
Docker containers share the same SGX driver
Timing: A cryptography side-channel attack needs a high resolution timer, something forbidden in SGX. Weiser and his collaborators combed Intel's specs, and settled on the inc and addinstructions, because these have “a latency of 1 cycle and a throughput of 0.25 cycles/instruction when executed with a register as an operand”.
To emulate the forbidden timer, the researchers used these x86 instructions:
mov &counter , %rcx
1: inc %rax
mov %rax , (%rex)
jmp lb
”Eviction set" generation: This step is designed to discover virtual addresses “that map to the same cache set”: we scan memory sequentially for an address pair in physical proximity that causes a row conflict. As SGX enclave memory is allocated in a contiguous way we can perform this scan on virtual addresses.”
With those two steps completed, Weiseret al worked out how to monitor vulnerable cache sets, looking for the characteristic signature of RSA key calculation.
This part of the attack has to happen offline – that is, separately to the cache monitoring that collects the data – because you end up with lots of data that has lots of noise in it (from timing errors, context switching, non-RSA-key activity in the victim's enclave, and CPU timing changes due to power management, and so on).
Key recovery comes in three steps. First, traces are preprocessed. Second, a partial key is extracted from each trace. Third, the partial keys are merged to recover the private key.
On an SGX-capable Lenovo ThinkPad T460s running Ubuntu 16.10, they found:
- With 340 trials, their malware was able to find a vulnerable cache set from the 2048 cache sets available;
- Capturing a trace from the vulnerable cache set took 72 seconds, on average;
- A single cache trace provided access to 96 per cent of a 4096-bit RSA key, and with 11 traces, the full RSA key is available.
The researchers say their attack can be blocked, but the fix will have to come from Intel, because modifications to operating systems risk weakening the SGX model. ®