STE WILLIAMS

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 add instructions, 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, Weiser et 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:

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. ®

Article source: http://go.theregister.com/feed/www.theregister.co.uk/2017/03/07/eggheads_slip_a_note_under_intels_door_sgx_can_leak_crypto_keys/