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.

News article.

Posted on March 16, 2017 at 5:54 AM25 Comments


Thoth March 16, 2017 6:53 AM

@Bruce Schneier, all

Put it simply, don’t bring a knife to a gun fight.

If you want to protect a cryptographic key, use a proper HSM or smart card. The paper talks about side-channel attacks which the HSMs and smart cards have been designed to give protection against.

The cheap man’s Intel SGX or ARM TrustZone is not designed to provide robust security for security critical operations. Use separate devices to handle separate levels of security which myself, @Clive Robinson, @Nick P et. al. have long been hammering but it simply does goes deep into the thick skulls of people who trip over something with a method of prevention (via separate protected devices).

r March 16, 2017 6:54 AM


So then, maybe…

It is designed for higher ground functionality of hiding an attacker? 😉

Thoth March 16, 2017 6:57 AM


I have talked about my reservations and doubts on these “Secure Enclaves sharing same processor” concepts. Go and dig up my rant on ARM TrustZone. They use the same ideas and go and look for poor TrustZone implementation exploits (i.e. Qualcomm QSEE crap).

Just use a separate device already ………….

Thoth March 16, 2017 7:00 AM


Oh and if you are lazy to dig TL;DR, you effectively have no way to verify the condition of the kernel running the SGX or TZ kernel and firmware layer. Better off to load your keys elsewhere at least in a smartcard which have side-channel protection to some degrees.

Whose the Worlds Best Hacker? March 16, 2017 9:07 AM

Is it NSA SGX or Intel SGX? Are their FBI approved backdoors?
Can ‘secure’ malware be placed inside?

Great place to set up Command and Control with lowest possibly of detection. It has it own memory too.
Does it interface with Intel Management Engine to report ‘home’ when the computer is turned “off” or sleeping?

From Intel
Much of the motivation for Intel® SGX can be summarized in the following eight objectives:
1. Allow application developers to protect sensitive data from unauthorized access or modification by rogue software running at higher privilege levels.
2. Enable applications to preserve the confidentiality and integrity of sensitive code and data without disrupting the ability of legitimate system software to schedule and manage the use of platform resources.
3. Enable consumers of computing devices to retain control of their platforms and the freedom to install and uninstall applications and services as they choose.
4. Enable the platform to measure an application’s trusted code and produce a signed attestation, rooted in the processor, that includes this measurement and other certification that the code has been correctly initialized in a trustable environment.
5. Enable the development of trusted applications using familiar tools and processes.
6. Allow the performance of trusted applications to scale with the capabilities of the underlying application processor.
7. Enable software vendors to deliver trusted applications and updates at their cadence, using the distribution channels of their choice.
8. Enable applications to define secure regions of code and data that maintain confidentiality even when an attacker has physical control of the platform and can conduct direct attacks on memory.
More detail:

keiner March 16, 2017 9:22 AM

…sometimes I get the feeling these “leaks” on 3-letter-agencies doing kiddy-stuff for hacking (and best-practices for cryptography etc. 😀 ) is just a big distraction of what is really going on.

Ross Snider March 16, 2017 1:34 PM

Wow great research. Only part way through the paper. This reminds me a bit about the blue pill rootkit and the answer being to add a ring -1 to control ring 0.

Turtles all the way down.

POLAR March 16, 2017 2:26 PM

This proves once again that security on the most used x86 cpus is non existent. There’s something new every month, yet it doesn’t officially exist. AMD releases much less crap, and has the decency to avoid all that vpro/management engine stuff, which is pointless and insecure. Yet when we offer AMD system people insist on Intel because it’s supposedly “more compatible” and “safer”.
I guess everyone got what they deserve, and Darwin always wins.

AlexT March 16, 2017 4:10 PM

I muss say this is a very nice hack!
Is Apple / iPhone using this (or similar) technology?

Clive Robinson March 16, 2017 6:27 PM

@ The usuall suspect’s,

At last a paper to give some very serious thought to.

@ Thoth,

Use separate devices to handle separate levels of security which myself, @Clive Robinson, @Nick P et. al. have long been hammering

This paper apprars to be one that has relevance to the C-v-P design so I shall have to realy dig in more than the paper does.

It will be interesting to see what @Wael will make of it as he had an interest in such things.

Thoth March 16, 2017 6:45 PM


AMD has a SGX alternativr called the SP.


Apple iPhone Secure Enclave uses similar technology based on ARM TrustZone. Think of ARM TrustZone as the ancestor which give rise to subsequent variations like Intel SGX, AMD SP, iPhone Secure Enclave, Samsung KNOX and Qualcomm’s QSEE/SecureMSM.

The nost research and buggy variant is the Qualcomm QSEE and this technology exist in every single Qualcomm Snapdragob chip with an ARM A7 and above processor which means every modern Qualcomm Snapdragon has QSEE enabled whether you are aware of it’s existance or not. Even if your phone manufacturer does not specify that is actively uses QSEE to do Trusted Boot, it has to be assumed that every single modern Snapdragon chip has active QSEE running in the background and due to the nature of such technology, the TrustZone partition alike a Ring -1 or sort of super duper hardware root us capable of modifying your userspace Android anytime it likes, accessing it’s resources, deleting or meddling your userspace environment if it likes to. That means if you have encryption software on userspace, the TZ partition is able to reach below (if it has been compromised or is maliciously backdoored) to be able to read your plaintext and grab your signing and decryption keys (i.e. Signal) or even meddle with your plaintext or ciphertext and silently report to some remote server with direct access to the phone’s internal modem without your userspace control and you have no known way to remove the QSEE or TZ unlike Intel AMT where you can attempt to delete the Intel AMT firmware.

For those advocating Signal and stuff on any Qualcomm or ARM A7 and above ARM chips, good luck with the TZ partition because you have no access to it’s partition openly with all the NDAs and fees and you don’t know the firmware and binary but the TZ knows what you are doing and can be remotely used (if necessary) to enable massive hardware based surveillance on all ARM chipa with TZ that may have been implemented in such a way.

Samsung Exynos has it, Qualcomm Snapdragon definitely has it, Apple A series chips has it and almost every single ARM A series chips has TZ baked in but whether it has been implemented to have HW backdoors or not is unknown and we must presume there is.

Good luck with all that encryption done with userspace layer and some might advocate use kf the TZ layer (i.e. Android keymaster library) for HW protected keys via ARM chips with TZ partition, good luck with that as it may also be backdoored. No one is escaping this mess as Qualcomm et. al. has most market share and assume all phones itself are backdoored and all data are accessible by NSA and Qualcomm at a snap of finger if Qualcomm wants to assist the NSA to use the TZ partition massively global dragnet style HW assisted surveillance.

I have warned about this but it has fallen on deaf ears.

Go ahead and continue to keep calm and use Signal while “they” happily decrypt all your “secure” messages. We need to move crypto onto dedicated secure and separate device if we want to survive possible mass dragnet surveillance that maybe HW assisted.


Thoth March 16, 2017 6:48 PM

@Clive Robinson

My tongue starts to feel dry these days. I wonder if all the discussions and suggestions we give are even worth it. This place is too noisy. Or maybe I am feeling the pressure from my work bleeding into daily life 🙂 .

Thot March 16, 2017 8:13 PM

Why dont you, Clive and Wael get together and build the secure systems that we need.

Wael March 16, 2017 10:45 PM

@Clive Robinson,

It will be interesting to see what […] will make of it as he had an interest in such things.

Still do. Not feeling well at all these days, though…

Figureitout March 16, 2017 11:46 PM

The countermeasures section at the end, after detailing the apocalypse of computer security, are always the best parts of these kinds of papers in my view. This one has quite a few, at different levels as well.

furloin March 17, 2017 2:28 AM

I did not know about there being direct derivitives of their implementation. I wonder if apple’s attempt is a direct copy paste or created in house. They did fork the mach kernel after all.

@The usual suspects
I may not be the best at reading but I am pretty good at searching.
I beseech thee, is it legal for me to read this treasure trove and speak of it? Gru’s and trolls need not respond. Just from a glance at the issues I have no doubt at its authenticity. I fear the worst of coding quality (Using C extensions).

Thoth March 17, 2017 3:09 AM


If yoy think of how the entire concept works, it has two operating environments. One is the operating under the userspace and the other is deeper of the likes of TZ and SGX. They require their own kernels and for TZ and SGX, you don’t get to see the proprietary firmware and kernels and who knows the quality of codes and possible backdoors.

Clive Robinson March 17, 2017 5:37 AM

@ Thoth,

I have warned about this but it has fallen on deaf ears.

You and me both, I first started going on about this need for seperation back in the 1990’s with banking that was moving online. It was horribly clear to me that “authenticating the user” was trivialy defeatable, then “authenticating the channel” was only slightly harder to defeat and that a sepetate –now called side– channel was required. In the foolishness of comparative youth, I decided that the SMS channel of a mobile phone was the way to go. I should note that this was more than half a decade befor getting what would become known as “mobile data” was got working even for “rocket scientists” or a decade and some before the first Smart Phone happened. When I saw which way that was going I changed my tune about mobile phones and went to independent tokens that had shared secret. After a few more trips, I realised just what level of token was required and how it had to be used. You had to put the human into the loop to prevent covert channels and the end point had to be beyond this and every transaction had to be authenticated this way. The problem humans are on average no good at typing random appearing data, and will not do the 128charecters necessary without error, therefor it would not “be usable”. With a few side trips via a tealy bad captcher idea, I realised users could not evaluate even non abstract risk even close to realisticaly.

The message “Ease of use will trump risk even that of bankruptcy and death every time” with 99.999% of users.

You will also find that there is “half house backlash” caused by two other human failings. That is people will recomend “Signal” or other “end-runnable” security trying to be helpfull, and those that will get hurt by it will lashback at all people talking what they will call “security trash”. Thus all will be tared with the brush of “half assed security” that Signal and Tor are.

As you say,

Go ahead and continue to keep calm and use Signal while “they” happily decrypt all your “secure” messages.

It’s not just the “key stealing” on the device or man in the middle server, it’s the endrun attacks with shims in the IO so they see what the user types before it gets to an app like Signal and likewise they will see what comes from an app like Signal effectivly before the user sees it displayed.

With such shims we know from malware attacks on banking apps that they can change what you type and change what you see. So they are a MITM on the “plaintext channel” from the app like signal to the user. That is a game over senario no matter how good the app may be.

No if’s, no but’s and no maybe’s, the only question is When and Why you will get made an example of. The most likely Why is because will be seen as a threat with the When an appropriate oportune moment to do the most damage. But there are other Why’s such that you are “a useful fool to frame” we see the FBI doing this already with their making then entraping faux terrorists, so that they can have a public show to keep the FUD going.

Why more people are not “joining the dots” is what surprises me. It’s something even our host appears to not want to think about.

There is a small matrix of things you can do one of which is “see nothing, say nothing thus do nothing” which might or might not lead as it has to chronic depression. Another is to go into total denial and change what you do in life. Others are to get strident or even take direct action of some form. None of which I would recommend, thus for sake of sanity and to be lawfull, just plainly and unemotionaly state the case and eventually others will by their and others misfortune get forced out of their denial zones. We are starting to see this with Tor we will see it with apps like Signal, and eventually increasing numbers of users will realise they have to change their habbits and shift the security end points beyond the SigInt and other IC Agencies grasp.

How ever as it approaches that point, there will be the usual security con artists getting into the game with their half arsed and insecure patent medicine snake oil solutions. That will be when the real fight starts.

Hopefull more than just you will read these words and take it onboard and learn what they need to know. However I can predict that there will be disagrement from some of those who don’t want people to learn for what boils down to their own personal gain…

For those who still don’t get the problem look up the sword of Damocles. In essence the bargin was he had to sit under a sword suspended by a human hair. Now imagine some enterprising smith comes along and says you need something stronger and presents a hugh unbreakable link to put in between the hair and the sword… It will achive less than nothing, that is what Signal and similar apps are a heavy weight to make the dangerous load not just heavier but more noticable…

Clive Robinson March 17, 2017 6:05 AM

@ Wael,

Still do. Not feeling well at all these days, though…

I’m glad for the good news that you are still interested and still with us.

However I’m sad to hear that you are not well. You were around and provided your wisdom and support when I was considerably a lot worse than I am now, thus my thoughts are with you now as I suspect are many of the regulars. I will not say “get well soon” as it sounds more like an order than a wish, but just hope that whatever ails you passes with the minimum of hurt, thus the healing be brief and thorough.

Clive Robinson March 17, 2017 6:18 AM

@ furloin,

I beseech thee, is it legal for me to read this treasure trove and speak of it?

It is a published academic document, thus has been put into the public domain in the interests of the common good.

As far as I am aware it is not derived from classified information, nor am I aware that it has been classified.

Nor do I think the information breaches criminal codes in the west.

As for civil legislation, you would have to have entered into some kind of contract with people for that to apply. And for a contract to be in existance and enforceable something has to be offered for something to have been gained without force in both directions.

So unless you have been bound by contract of employment or NDA by you or your employer then probably “it is legal for [you] to read this treasure trove and speak of it”.

furloin March 17, 2017 2:10 PM


I think this code is the userland portion visible to the linux kernel and this portion is the hardware layer.


They have a hardware defined direct memory access via the sim modem here starting at line 8407 are memory adresses for it. That is just confirming the obvious. No doubt they do that to all their chipsets with a modem.

At line 327 it seems they implemented a way to update the trustzone image over usb by sending a special key in some manner. That is to say a backdoor/debug access.

Also have any idea what this is? Going through it with vi just shows some plaintext about aes keys.

Who? March 19, 2017 2:08 PM

@ all

The MediaTek MT6735 repository has been “disabled due to a DMCA takedown notice.” It was lasting too much time. I understand most of you got a copy in the last days, am I wrong?

@ furloin

Good analysis… keep up the good work!

Leave a comment


Allowed HTML <a href="URL"> • <em> <cite> <i> • <strong> <b> • <sub> <sup> • <ul> <ol> <li> • <blockquote> <pre> Markdown Extra syntax via

Sidebar photo of Bruce Schneier by Joe MacInnis.