Dark Reading is part of the Informa Tech Division of Informa PLC

This site is operated by a business or businesses owned by Informa PLC and all copyright resides with them.Informa PLC's registered office is 5 Howick Place, London SW1P 1WG. Registered in England and Wales. Number 8860726.


10:30 AM
Yehuda Lindell
Yehuda Lindell
Connect Directly
E-Mail vvv

Foreshadow, SGX & the Failure of Trusted Execution

Trusted execution environments are said to provide a hardware-protected enclave that runs software and cannot be accessed externally, but recent developments show they fall far short.

One of the primary challenges in today's computing environments is that of trust. How do I know that the software that I am actually running is the correct software that I want to run? How do I protect the privacy of my data while it's in memory? How can I even think of solving these problems when I'm running my applications on remote machines or in the cloud? These acute challenges and more can be addressed by running software in trusted execution environments such as SGX, TrustZone, and more.

Such environments are said to provide a hardware-protected enclave that runs the software and cannot be accessed externally. Data can be encrypted in memory and then only decrypted inside the enclave, where it remains safe. This prevents malware, service providers, and any unauthorized entity from accessing private data. Furthermore, cryptographically enforced attestation can be used to identify and ensure that authentic software is running in the enclave, even remotely and in a cloud. As such, trusted execution environments can significantly boost the security of the modern computing environment.

Unfortunately, recent developments have shown that existing trusted execution environments fail to meet their promise. The reason is something called side channels. A side channel is an unexpected (and unintended) channel through which private information is leaked. It has been known for two decades that seemingly benign information such as the time it takes to compute a function, the power that a device uses during computation, and even the noise emitted by a computer's fan can all leak secrets. More recently, it was discovered that two isolated software applications running on the same physical machine can leak information to each other due to joint resources provided by the hardware.

A prime example of this type of software leakage is called a cache side-channel attack. Because main memory is very slow (relative to the speed of modern processors), memory caches are used to speed up memory access. These caches are shared by different applications on the same machine, meaning that the time that it takes one application to read from memory is influenced by another application's behavior. For example, if an application has just read a certain instruction from memory, then it will reside in cache. If another application reads the same instruction, therefore, it will retrieve it much faster than if the first application had not read that instruction.

Amazingly, this can be used by the latter application to know what the first application is doing. These attacks are so effective that they have been used to extract cryptographic keys of all types, without utilizing any operating system or software vulnerability; the entire attack is launched by issuing special instructions and measuring response times.

This type of attack is devastating because it means that virtual machines in the cloud can be attacked by other virtual machines running on the same hardware, even when the isolation provided by the software layers are perfect. As a result, sensitive code — like the code that carries out cryptographic operations — is written carefully to not leak anything via the cache. This is achieved by ensuring that the memory access pattern of the code is independent of the secret key. Although this may be theoretically possible, in practice, it is extremely hard and the best code written by the best experts on the subject has been broken time and again over the past few years. In part, this is due to the complexity of the software layers (it isn't always clear what happens when high-level instructions are called) and to the complexity of the hardware.

New Vulnerabilities
This year saw the discovery of new powerful vulnerabilities in the form of speculative execution: Spectre, Meltdown, and now Foreshadow. These attacks utilize the fact that modern hardware chips will run instructions and only later check whether these should have been carried out. This enables the chip's pipeline to be better utilized, since often the chip's "guesses" as to what to compute are correct.

These sophisticated techniques, and others, have provided the world with the ever-increasing speed of computation that it was used to due to Moore's Law, and continues to demand even though the physical barriers of size are an obstacle. However, as this year's headlines have taught us, speculative execution also leaks and provides attackers with new effective side channels that can be used to read secrets. Foreshadow is especially devastating because even perfectly written software is vulnerable, and the entire attack is due to the way that the hardware processes memory.

To make all of the above even worse, trusted execution environments like SGX have been constructed so that they also share resources with other applications running on the same hardware. As a result, speculative execution attacks are effective on SGX, and Foreshadow demonstrated that encrypted memory can be easily dumped out of an SGX enclave. Foreshadow is even able to steal the special Intel enclave attestation key, completely breaking the integrity mechanism of SGX. (Note that although such attacks are very nontrivial to design, once an attacker has written the attack, it can be quite easily deployed on a large scale.)

Although local patches have been issued by Intel, the fundamental flaw of SGX (and other trusted execution environments) is that they are not isolated from other processes. I don't believe that it is possible to construct a truly secure trusted execution environment without full isolation; side channels are abundant and we are only just seeing the beginning. Indeed, instead of SGX being a powerful tool to provide strong and proven guarantees of security, it is part of the constant cycle of break, fix, and break again. This is indeed a sad time for the security of our digital world.

Trusted execution can only be trusted if the execution environment is truly isolated from the rest of the chip. Despite its attractive promise, SGX cannot be used today to effectively protect secrets. One can only hope that truly isolated trusted execution environments can be built in the coming years. Because this would require great cost and a complete redesign, it is sadly not something that we will see soon.

Related Content:


Black Hat Europe returns to London Dec. 3-6, 2018, with hands-on technical Trainings, cutting-edge Briefings, Arsenal open-source tool demonstrations, top-tier security solutions, and service providers in the Business Hall. Click for information on the conference and to register.

Yehuda Lindell is the CEO and Co-Founder of Unbound Tech (previously, Dyadic Security) as well as professor in the Department of Computer Science at Bar-Ilan University. Prior to Bar-Ilan in 2004, he was a Raviv Postdoctoral fellow in the Cryptographic Research Group at the ... View Full Bio

Recommended Reading:

Comment  | 
Print  | 
More Insights
Newest First  |  Oldest First  |  Threaded View
Former CISA Director Chris Krebs Discusses Risk Management & Threat Intel
Kelly Sheridan, Staff Editor, Dark Reading,  2/23/2021
Security + Fraud Protection: Your One-Two Punch Against Cyberattacks
Joshua Goldfarb, Director of Product Management at F5,  2/23/2021
Cybercrime Groups More Prolific, Focus on Healthcare in 2020
Robert Lemos, Contributing Writer,  2/22/2021
Register for Dark Reading Newsletters
White Papers
Cartoon Contest
Write a Caption, Win an Amazon Gift Card! Click Here
Latest Comment: This comment is waiting for review by our moderators.
Current Issue
2021 Top Enterprise IT Trends
We've identified the key trends that are poised to impact the IT landscape in 2021. Find out why they're important and how they will affect you today!
Flash Poll
Building the SOC of the Future
Building the SOC of the Future
Digital transformation, cloud-focused attacks, and a worldwide pandemic. The past year has changed the way business works and the way security teams operate. There is no going back.
Twitter Feed
Dark Reading - Bug Report
Bug Report
Enterprise Vulnerabilities
From DHS/US-CERT's National Vulnerability Database
PUBLISHED: 2021-02-27
SerComm AG Combo VD625 AGSOT_2.1.0 devices allow CRLF injection (for HTTP header injection) in the download function via the Content-Disposition header.
PUBLISHED: 2021-02-27
An issue was discovered in through SaltStack Salt before 3002.5. salt.modules.cmdmod can log credentials to the info or error log level.
PUBLISHED: 2021-02-27
In SaltStack Salt before 3002.5, eauth tokens can be used once after expiration. (They might be used to run command against the salt master or minions.)
PUBLISHED: 2021-02-27
An issue was discovered in SaltStack Salt before 3002.5. Sending crafted web requests to the Salt API can result in salt.utils.thin.gen_thin() command injection because of different handling of single versus double quotes. This is related to salt/utils/thin.py.
PUBLISHED: 2021-02-27
i-doit before 1.16.0 is affected by Stored Cross-Site Scripting (XSS) issues that could allow remote authenticated attackers to inject arbitrary web script or HTML via C__MONITORING__CONFIG__TITLE, SM2__C__MONITORING__CONFIG__TITLE, C__MONITORING__CONFIG__PATH, SM2__C__MONITORING__CONFIG__PATH, C__M...