“There’s no silver bullet solution with cybersecurity, a layered approach is the only viable defence.”
— James Scott, Institute for Critical Infrastructure Technology
TL;TR
This blog entry aims at answering following questions:
- What is an enclave and how does it work
- How is my sensible data kept confidential and integrity protected?
- Why is my sensible data safe from unauthorized access and modification?
Introduction
While the danger from inside the internet gets bigger and bigger, attacks on uncritical as well as on critical systems get more common, its daily business in the present world. As long as you or your company are interested in long term safety.
If your boss doesn’t want to spend a few dollars for IT-Security with the reason that you can simply unplug the ethernet cable from the critical systems in the company, you’re fine. It’s the ultimate way on the lowest layer to make your system secure. If that’s not the case, feel free to use this guide on why and how to use Intel’s Security Guard Extension for your programming projects to ensure security from the hardware layer on. You’re welcome.
Intel introduced the Security Guard Extensions (SGX) in the 3rd quarter of 2015 together with the start of the new Skylake processor series. The focus of SGX is to protect sensitive data against untrusted user, even on already compromised systems, with the help of hard implemented security and crypto mechanism inside the CPU. New instructions and memory access changes making it possible for the software developer to create encrypted enclaves containing sensible data from banking apps or key wallets while retaining confidentiality and integrity. These enclaves are only accessible from inside itself and plain text is only visible while it is processed inside the CPU, keeping the stored information safe, even from privileged software like VMM’s, BIOS or OS’.
About apps and enclaves
The security goals of SGX are to protect the confidentiality and integrity of its enclaves. This means untrusted parties like applications or system software should not be able to gain information from the enclave or manipulate the enclaves data and code. We start with information of the data structure and the general architecture of SGX, which lead to the desired safety.
In the SGX model an app is divided into a trusted and an untrusted part. The untrusted part is the one communicating with the rest of the system as well as creating the enclave, which is considered as the safe part of the app. Inside the enclave the sensible data is stored. Fixed starting positions inside the enclave ensure the correct execution inside the enclave. To enter this enclaves, the CPU has to be in enclave mode, which acts like a switch into the safe world.
Further enclave instances are isolated from each other, so they can only interact through their untrusted part. A specific enclave can only be addressed by its trusted app part. This makes it even impossible for malicious programs to get into an enclave, when the CPU is in enclave mode, but the access command comes from an (for the enclave) untrusted memory address.
The enclave bunker
Enclaves are stored in the Enclave Page Cache (EPC). Following figure shows the specific SGX structures, including data used to security check and manage the enclave entry points. These are, besides the SIGSTRUCT and the Version Page Array, enclave related elements. Each enclave has its own SECS, one or more TCS’ and corresponding SSA’s. The EPC in general has it’s SIGSTRUCT and VA Page.
Further the Enclave Page Cache Map (EPCM) is used to manage the security attributes of the Enclave Pages. The EPCM contains further information for each page listed in the EPC. The figure below lists the data acquired for each page.
The EPC is located inside the Processor Reserved Memory (PRM) inside the DRAM, the EPCM is a look-up table inside the CPU with enclave related data.
Since we store our data outside the CPU in the PRM, we must ensure its safeness by encrypting it with the help of the Memory Encryption Engine (MEE). This way the data in the PRM is nothing more than noise to other parties, only the MEE is capable to real time decrypt the data inside the CPU. Therefore, the CPU is the only place in the system capable of reading the clear data stored inside the enclaves.
The CPU as our doorman
As we have seen before, the only participant privileged to enter the EPC, respectively the PRM, is the CPU. The method of deciding whether the processor can enter this secure area depends on the mode, the CPU is running at. SGX implements an Enclave Mode, which the CPU must enter to get specific memory access semantics.
This mode gets enabled, once internal enclave code wants to run inside its specific enclave area in the EPC. To sum up, there are three requirements an access must fulfil to get protected memory access: the processor runs in enclave mode, the requested page is part of the same enclave the access has been requested and the page access must be through the right specific virtual address.
If a running enclave is stopped or interrupted, any context information like registers are removed from the CPU, therefore by interrupting the enclave an attacker cannot gain any in-formation from the enclave. But before this happens, related registers are evacuated into their explicit enclave, where they are saved in an encrypted state in the EPC in the PRM on the DRAM.
Blue line: Enclave 1 can access every page inside its own enclave. Additionally, it can access non PRM memory. That means, that only our enclave can run commands inside itself. Further the enclave can run commands outside its safe space trough the untrusted side of its app. Access from the PRM into the enclave is only possible through defined call functionalities for entering an enclave trough the untrusted app side, there is no other way entering an enclave.
Red line: If code inside a page from e.g. enclave n wants to enter a page of enclave 1, it gets redirected to a nonexistent memory. This is backed by the virtual memory address check of the MMU. If an access is tried from a virtual address outside the explicit enclaves’ virtual address, it gets either redirected to nonexistent memory or it throws a signal fault. This behaviour prevents attackers entering from the safe PRM area to neighbouring enclaves, just because of the point, that the CPU is running in enclave mode. Entering from the non PRM area is generally blocked by the circumstance, that the CPU isn’t running in enclave mode.
More detailed information for SGX structures available at Intel, Innovative Instructions and Software Model for Isolated Execution.