John M. of Intel has a new blog post with status on his next Intel SGX tutorial. Nice, it looks like there are many upcoming articles!
[…] Part 4 of the Intel Software Guard Extensions (Intel SGX) Tutorial Series will be coming out in the next few days. In it, we’ll be starting our enclave implementation, focusing on the bridge/proxy functions for the enclave itself as well as the middleware layer needed for the C++ code to interact with it. If you recall from the introduction, we are planning five broad phases in the series. With part 4 we complete our transition from the first phase, which focused on concepts and design, to the development and integration in the second. I want to take a few minutes to talk about what else is coming up and roughly where we are headed over the coming weeks. Part 5 will complete the development of the enclave. While part 4 is focused on the enclave interface layer and the enclave definition language (EDL), in part 5 we will code up the internals of enclave itself. In part 6, we’ll add support for dual code paths so that the application runs on hardware that is both Intel SGX capable and incapable. In a change from our original plan for the series, part 7 will look at power events (specifically, suspend and resume) and its impact on enclaves. After that, we’ll enter into the third phase of the tutorial which focuses on testing and validation. Here, we’ll demonstrate that Intel SGX is providing the expected security benefits. We’ll also look at tuning the enclave configuration to better match our usage. The final two phases, packaging and deployment, and disposition, will follow.
Thanks to John M. of Intel for noting on this blog that part 3 of his tutorial is now available:
“In Part 3 of the Intel® Software Guard Extensions (Intel® SGX) tutorial series we’ll talk about how to design an application with Intel SGX in mind. We’ll take the concepts that we reviewed in Part 1, and apply them to the high-level design of our sample application, the Tutorial Password Manager, laid out in Part 2. We’ll look at the overall structure of the application and how it is impacted by Intel SGX and create a class model that will prepare us for the enclave design and integration.”[…]
parse_enclave.py takes an enclave in binary form and extracts some metadata
parse_quote.py takes a quote in binary form and extracts its fields
parse_sealed.py takes a sealed blob of data and extracts its fields
AsyncShock: Exploiting Synchronisation Bugs in Intel SGX Enclaves
Nico Weichbrodt, Anil Kurmus, Peter Pietzuch, Rüdiger Kapitza
Intel’s Software Guard Extensions (SGX) provide a new hardware-based trusted execution environment on Intel CPUs using secure enclaves that are resilient to accesses by privileged code and physical attackers. Originally designed for securing small services, SGX bears promise to protect complex, possibly cloud-hosted, legacy applications. In this paper, we show that previously considered harmless synchronisation bugs can turn into severe security vulnerabilities when using SGX. By exploiting use-after-free and time-of-check-to-time-of-use (TOCTTOU) bugs in enclave code, an attacker can hijack its control flow or bypass access control. We present AsyncShock, a tool for exploiting synchronisation bugs of multithreaded code running under SGX. AsyncShock achieves this by only manipulating the scheduling of threads that are used to execute enclave code. It allows an attacker to interrupt threads by forcing segmentation faults on enclave pages. Our evaluation using two types of Intel Skylake CPUs shows that AsyncShock can reliably exploit use-after-free and TOCTTOU bugs.
The antivirus-centric conference VirusBulletin is happening this October, and there’s an Intel SGX talk on the agenda:
Trusted Code Execution on Untrusted Platform Using Intel SGX
Prof. Guevara Noubir (Northeastern University)
Amirali Sanatinia (Northeastern University)
Today, isolated trusted computation and code execution is of paramount importance to protect sensitive information and workflows from other malicious privileged or unprivileged software. Intel Software Guard Extensions (SGX), is a set of security architecture extensions introduced in the Skylake microarchitecture that enables a Trusted Execution Environment (TEE). It provides an ‘inverse sandbox’, for sensitive programs, and guarantees the integrity and confidentiality of secure computations even from the most privileged malicious software (e.g. OS, Hypervisor). SGX-capable CPUs only became available in production systems in Q3 2015, however they are not yet fully supported and adopted in systems. Besides the capability in the CPU, the BIOS also needs to provide support for the enclaves, and not many vendors have released the required updates for the system support. This led to many wrong assumptions being made about the capabilities, features, and ultimately dangers of secure enclaves. By having access to resources and publications such as white papers, patents and the actual SGX-capable hardware and software development environment, we are in a privileged position to be able to investigate and demystify SGX. In this paper, we first review the previous Trusted Execution technologies, such as ARM Trust Zone and Intel TXT, to better understand and appreciate the new innovations of SGX. Then we look at the details of SGX technology, cryptographic primitives and the underlying concepts that power it, namely the sealing, attestation, and the Memory Encryption Engine (MEE). Then we look at the use cases such as trusted and secure code execution on an untrusted cloud platform, and Digital Rights Management (DRM). This is followed by an overview of the software development environment and the available libraries.
Read the above twitter link for some more background (including Intel PDF link) and security ramifications of this.
Alexander B. of Intel has written a blog post describing the Sealing abilities of Intel SGX:
Introduction to Intel® SGX Sealing:
This post is intended to introduce developers to the Sealing capability available on SGX enabled platforms. Sealing is the process of encrypting enclave secrets for persistent storage to disk. This allows secrets to be retrieved if the enclave is torn down (either due to power event or by the application itself), and subsequently brought back up. Encryption is performed using a private Seal Key that is unique to that particular platform and enclave, and is unknown to any other entity. […] For a more detailed treatment of SGX sealing capabilities, refer to the following documents: […]
Jethro Beekman has released libenclave, a Rust-based tool for Intel SGX’s SDK for Windows:
This guide will get you started building SGX secure enclaves in Rust using libenclave and sgxs-tools. […]
Dan Zimmerman of Intel posted a status update regarding Linux availability of an SDK for Intel SGX:
Excerpting the blog:
The Intel intends to:
* Open-Source the Intel® SGX SDK for Linux* and associated Platform Software in June 2016.
* There will be a few user-space components where binaries will be provided instead of source
It sounds like this will be a freeware release that includes partial source, not a proper open source project. At least, I am not sure how it can be called “Open Source” if it includes a few binaries instead of source…
Going a bit off SGX-topic, in his blog post, Dan mentions:
“Whenever I talk with developers about Intel® SGX, one of the first questions asked is ‘When will Linux support be available’?”
I am glax Intel SGX team is paying attention to Linux. There are many other Intel teams that only pay attention to Windows. 😦
Intel has a new document available on SGX, discussing EPID Provisioning and Attestation Services:
Intel SGX: EPID Provisioning and Attestation Services
One of the critical features of Intel SGX is the ability to attest that an enclave was successfully established on an SGX enabled platform. Our Attestation and Sealing Whitepaper from 2013 on the subject gives a high level overview of the attestation process, however it did not cover how the attestation key was delivered to the platform. In order to explain this process and the services that Intel has developed to support EPID provisioning, and the subsequent verification of EPID attestations, for SGX we have written a companion whitepaper. EPID provisioning takes place through enclaves that are provided as part of the SGX SDK and distributed along with SGX applications. The attestation service is available to all SGX developers. For developers that have built their enclaves and are ready to access the Intel Attestation Verification Service referenced in the paper, please contact email@example.com for additional information.
Cryptographic protection of memory is an essential ingredient for any technology that allows a closed computing system to run software in a trustworthy manner and handle secrets, while its external memory is susceptible to eavesdropping and tampering. An example for such a technology is Intel’s emerging Software Guard Extensions technology (Intel SGX) that appears in the latest processor generation, Architecture Codename Skylake. This technology operates under the assumption that the security perimeter includes only the internals of the CPU package, and in particular, leaves the DRAM untrusted. It is supported by an autonomous hardware unit called the Memory Encryption Engine (MEE), whose role is to protect the confidentiality, integrity, and freshness of the CPU-DRAM traffic over some memory range. To succeed in adding this unit to the micro architecture of a general purpose processor product, it must be designed under very strict engineering constraints. This requires a careful combination of cryptographic primitives operating over a customized integrity tree that mostly resides on the DRAM while relying only on a small internally stored root. The purpose of this paper is to explain how this hardware component of SGX works, and the rationale behind some of its design choices. To this end, we formalize the MEE threat model and security objectives, describe the MEE design, cryptographic properties, security margins, and report some concrete performance results.
Matthew Green has a thread on Twitter about concerns of Intel SGX attestation keys, including some text of how the SGX uesr docs differ from the SGX patent docs.
“Intel appears to have dropped the idea of securely provisioning SGX attestation keys. Now you have to contact Intel.”
I can’t claim to understand SGX well enough to give any useful comments on this post. ;-( I still need to spend time to learn SGX… I’m going to read that new SGX Explained document… 🙂
Victor Costan and Srinivas Devadas have a new document on SGX:
Intel’s Software Guard Extensions (SGX) is a set of extensions to the Intel architecture that aims to provide integrity and privacy guarantees to security-sensitive computation performed on a computer where all the privileged software (kernel, hypervisor, etc) is potentially malicious. This paper analyzes Intel SGX, based on the 3 papers that introduced it, on the Intel Software Developer’s Manual (which supersedes the SGX manuals), on an ISCA 2015 tutorial, and on two patents. We use the papers, reference manuals, and tutorial as primary data sources, and only draw on the patents to fill in missing information. This paper’s contributions are a summary of the Intel-specific architectural and micro-architectural details needed to understand SGX, a detailed and structured presentation of the publicly available information on SGX, a series of intelligent guesses about some important but undocumented aspects of SGX, and an analysis of SGX’s security properties.
Joe Birr-Pixton has an interesting new blog post — with source code — on using Intel SGX in enclaves to help with creating strong passwords:
Using SGX to harden password hashing: SGX is a way of running security-sensitive user-mode code in an ‘enclave’. Code running in an enclave has its memory encrypted and authenticated, and cannot be observed by code running anywhere else. It’s able to use device-specific keys to encrypt (‘seal’) data to future executions of itself or enclaves signed by the same key. We can use SGX to harden password hashing, by imposing the restriction that it is only possible on our hardware. That means offline attack is no longer possible, and a database leak only contains undecryptable ciphertext. […]
Intel SGX: Debug, Production, Pre-release what’s the difference?
Simon Johnson, Dan Zimmerman, and Derek B., all of Intel, presumably on the Intel SGX team, posted a new article on the Intel blog, on Intel SGX.
Since release the SDK we’ve had a few questions about debug vs pre-release vs release mode (production) enclaves. Part of the security model of Software Guard Extensions is to prevent software from peaking inside and getting at secrets inside the enclave… but no-one writes perfect code the first time round; so how do you debug an enclave?
Real World Cryptography Conference 2016
6-8 January 2016, Stanford, CA, USA
Intel® Software Guard Extensions (Intel® SGX)
Memory Encryption Engine (MEE)
Intel Corp., Intel Development Center, Haifa, Israel
University of Haifa, Israel
I just noticed Jethro Beekman’s blog.
The last post, from October, on Intel SGX, is interesting:
His blog is much better than mine w/r/t use of tags, so it’s easy to find earlier SGX posts. One was revised this month, all very good reading: