Skip to content
The methodOpen data
Back to the collection

Malware Guard Extension: Using SGX to Conceal Cache Attacks

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

2017 · arXiv

Security & cryptographyComputer systems
Read the paper
HN score
0
Mentions
4
Readers
4
Months
3
What’s in a score?

From the 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.

Metadata: arXiv. Abstracts retain their original authors’ rights.

In the conversation

Original HN comments, with labels from simple text rules. A label describes the whole comment and may miss context or irony. Read the discussion to make up your own mind. About the labels

4 selected excerpts · 4 total mentions

ChrisLomont
Neutral mention · rule
> Constant time" in cryptography means that there is no information flow from secrets to timings If "constant time" cryptography were achievable don't you think we'd have it and there'd be no more timing attacks breaking encryption schemes? "Constant time" cryptography is a mathematical abstraction, a goal, like "unbreakable cipher" and "unbreakable hash" and "frictionless surface." They don't occur in practice. This article breaks itself breaks a "constant time" cryptography with a timing attack. The problem is, as this paper demonstrates (along with many others) coding up a constant time crypto and especially making it portable over time and architectures, is nearly…
Read the full comment
impossible. Caches, chip nuances, power draw mixed with power scaling, and other chip architecture complexity, contribute to attacks. Compiler changes, architecture changes (some even unpublished), architecture variety, user settings, even flaws in any part of the chain, all contribute to making holes in crypto in the real world. This paper [1], for example, is one of many that shows the "constant time" goal is likely not possible, and is certainly not possible in portable code. Here's [2] a paper tying to make simple AES "timing-attack resistant" - and you note they did not claim they could make it "constant time" because they realize that is not possible. "Timing-attack resistant" is at least professionally defensible. Here's [3] a paper referencing [2], trying to make systems more resistant to cross process leaks using Intel SGX to hide things that leaking. And here [4] is the attack on Intel SGX that shows there are still exploitable leaks. This type of chain is not unique. If you want to read literally thousands of papers on such things use google scholar or surf the cryptology eprint archive. Both make searching on such topics pretty easy. We could go on and on. The literature of crypto is littered with such threads - "constant time" crypto is the goal, but so is "unbreakable encryption" - both are mathematical fantasies that do not play out in practice. [1] https://arxiv.org/pdf/1711.08002.pdf [2] https://link.springer.com/chapter/10.1007/978-3-642-04138-9_... [3] https://arxiv.org/pdf/1702.08719.pdf [4] https://arstechnica.com/information-technology/2020/03/hacke...
Original comment Hertzbleed Attack
Confiks
Neutral mention · rule
"Confidential computing" might seem to refer to homomorphic encryption, but has nothing to do with it in its usage here. After searching around a bit, I suspect that Microsoft Azure first used it in 2017 to refer to code running within a trusted enclave. It looks to me that while Asylo is agnostic about the specific TEE used, it is primarily targeted at Intel SGX [1]. Instead of having to trust Google to run your code correctly and not read your data, you'd have to trust Intel to manufacture a secure enclave and essentially bake in a private key that cannot be read. You could use the public key to encrypt your code and workload, and it would run in a part of the processor…
Read the full comment
that Google presumably cannot access (or measure [2]). A good further introduction might be this paper [3] (especially the diagram on page 2), or this answer [4]. I'll repeat my main concern with this system: you will reinforce Intel's position as 'feudal lord' in this model [5]. [1] https://github.com/google/asylo/tree/master/asylo/identity/s... [2] https://arxiv.org/abs/1702.08719 [3] https://eprint.iacr.org/2016/086.pdf [4] https://security.stackexchange.com/questions/175749/what-are... [5] https://news.ycombinator.com/item?id=15936121
Original comment Asylo: an open-source framework for confidential computing
j_s
Neutral mention · rule
Yes it was specifically called out in someone's tweet I'm trying to find but I believe this was mentioned in the paper. Edit: My mix-up on the paper! Malware Guard Extension: Using SGX to Conceal Cache Attacks (Extended Version) | https://arxiv.org/pdf/1702.08719.pdf (2017) Recently, Intel introduced an instruction set extension called CAT (cache allocation technology) [51]. With Intel CAT it is possible to restrict CPU cores to one of the slices of the last-level cache and even to pin cache lines. Liu et al. [83] proposed a system that uses CAT to protect general purpose software and cryptographic algorithms. Their approach can be directly applied to protect against a…
Read the full comment
malicious enclave. However, this approach also does not allow to protect enclaves from an outside attacker. [...] Instead of using Intel CAT on the operating level it could also be used to protect enclaves on the hardware level. By changing the eenter instruction in a way that it implicitly activates CAT for this core, any cache sharing between SGX enclaves and the outside as well as co-located enclaves could be eliminated. Thus, SGX enclaves would be protected from outside attackers. Furthermore, it would protect co-located enclaves as well as the operating system and user programs against malicious enclaves. [83] https://www.researchgate.net/profile/Yuval_Yarom/publication...
Original comment CPU cache-based communication between two co-located virtual machines
wfn
Neutral mention · rule
> seeing cracks that allows a virtualised system to break out to the is scary Hate to break this to you, but it's been shown time and time again that due to how caching and CPU pipelining works in modern processors, any "isolation" including full-on VM which is not "physical isolation" is leaky: https://pdfs.semanticscholar.org/e544/00824814fed2ef52bb8415... (overview of attacks) Here is a particularly nice paper (proper methodology, well-explained intro, etc.) showing one example (a more or less regular cache timing attack, but with actual private info extraction from host, etc.): https://arxiv.org/abs/1702.08719 - these come up several times a year for various VMs, etc.
Original comment Virtual machine escape fetches $100k at Pwn2Own hacking contest

Keep following the thread.

More in Security & cryptography

More from the same topics.

2014arXiv

Explaining and Harnessing Adversarial Examples

Ian J. Goodfellow, Jonathon Shlens, Christian Szegedy

Several machine learning models, including neural networks, consistently misclassify adversarial examples---inputs formed by applying small but intentionally worst-case perturbations to examples from the dataset, such that the perturbed input results in the model outputting an incorrect answer with high confidence.

Machine learningSecurity & cryptography
16 mentions11 months
1.5HN score