This blog-post provides the reader with an overview of the Intel SGX technology. In this first part, we explore the additions made to Intel platforms to support SGX, focusing on the processor and memory. We then explain the management and life cycle of an enclave. Finally, we detail two features of enclaves: secret sealing and attestation.
Intel SGX is a technology that was developed to meet the needs of the Trusted Computing industry, in a similar fashion to the ARM TrustZone, but this time for desktop and server platforms. It allows user-land code to create private memory regions, called enclaves, that are isolated from other processes running at the same or higher privilege levels. The code running inside an enclave is effectively isolated from other applications, the operating system, the hyper-visor, et cetera.
It was introduced in 2015 with the sixth generation Intel Core processors, which are based on the Skylake micro-architecture. SGX support can be checked by executing the CPUID instruction with the Structured Extended Feature Leaf flag set, and checking if the second bit of the EBX register is set. To be able to use SGX, it must have been enabled by the BIOS, and only a few BIOSes actually support this technology. That is one of the reasons it is not widely used.
The implementation of Intel SGX can be summarized in a few points:
- an application is split into two parts: a secure one and a non-secure one;
- the application launches the enclave, which is placed in protected memory;
- when an enclave function is called, only the code within the enclave can see its data, external accesses are always denied; when it returns, enclave data stays in the protected memory.
The secure execution environment is part of the host process, which means that:
- the application contains its own code, data, and the enclave;
- the enclave contains its own code and its own data too;
- SGX protects the confidentiality and integrity of the enclave code and data;
- enclave entry points are pre-defined during compilation;
- multi-threading is supported (but not trivial to implement properly);
- an enclave can access its application's memory, but not the other way around.
Intel SGX defines 18 new instructions: 13 to be used by the supervisor and 5 by the user. All these instructions are implemented in micro-code (so that their behavior can be modified). See below for the complete instructions list.
|EADD||Add a page||EENTER||Enter an enclave|
|EBLOCK||Block an EPC page||EEXIT||Exit an enclave|
|ECREATE||Create an enclave||EGETKEY||Create a cryptographic key|
|EDBGRD||Read data by debugger||EREPORT||Create a cryptographic report|
|EBDGWR||Write data by debugger||ERESUME||Re-enter an enclave|
|EINIT||Initialize en enclave|
|ELDB||Load an EPC page as blocked|
|ELDU||Load an EPC page as unblocked|
|EPA||Add a version array|
|EREMOVE||Remove a page from EPC|
|ETRACE||Activate EBLOCK checks|
|EWB||Write back/invalidate an EPC page|
Intel SGX also defines 13 new data structures: 8 are used for enclave management, 3 for memory page management, and 2 for resources management. See below for the complete structures list.
- SGX Enclave Control Structure (SECS)
- Thread Control Structure (TCS)
- State State Area (SSA)
- Page Information (PAGEINFO)
- Security Information (SECINFO)
- Paging Crypto MetaData (PCMD)
- Version Array (VA)
- Enclave Page Cache Map (EPCM)
- Enclave Signature Structure (SIGSTRUCT)
- EINIT Token Structure (EINITTOKEN)
- Report (REPORT)
- Report Target Info (TARGETINFO)
- Key Request (KEYREQUEST)
In the following sections, we detail the relevant instructions and structures, before giving a high-level explanation of how they are used to achieve some functionality.
Enclave Page Cache (EPC)
Enclave code and data are placed in a special memory area called the Enclave Page Cache (EPC). This memory area is encrypted using the Memory Encryption Engine (MEE), a new and dedicated chip. External reads on the memory bus can only observe encrypted data. Pages are only decrypted when inside the physical processor core. Keys are generated at boot-time and are stored within the CPU.
The traditional page check is extended to prevent external accesses to EPC pages.
Enclave Page Cache Map (EPCM)
The Enclave Page Cache Map (EPCM) structure is used to store the pages state. It is located inside the protected memory and its size limits the size of the EPC (set by the BIOS, 128MB maximum). It contains the configuration, permissions and type of each page.
The EPC memory is defined by the BIOS and limited in size. SGX has a way for removing a page from the EPC, placing it in unprotected memory, and restoring it later. Pages maintain the same security properties thanks to the EPC pages management instructions, that allow to encrypt an page and produce additional meta-data. A page cannot be removed until all cache entries referencing this page have removed from all processor logical cores. Content is exported or imported with a granularity of a page (which is 4KB).
- The application requests the loading of its enclave into memory;
- The ECREATE instruction creates and fills the SECS structure;
- Each page is loaded into protected memory using the EADD instruction;
- Each page is added to the measure of the enclave using the EEXTEND instruction;
- The EINIT instruction finalizes the enclave creation.
- EENTRY instruction is executed;
- The application context is saved;
- The processor is put in enclave mode.
- EEXIT instruction is executed;
- The processor is put in normal mode.
Interruptions and exception result in Asynchronous Enclave Exits (AEX). The Asynchronous Exit Pointer (AEP) points to a handler located inside the application that will resume the execution after the exception has been handled by the Interrupt Service Routine (ISR). The handler can decided to resume or not the execution of the enclave, by executing the ERESUME instruction.
When an AEX happens, the context of the enclave is saved in the current SSA and the application context is restored. The enclave context is restored when the ERESUME instruction is executed. The TCS contains a counter denoting the current SSA, forming a stack of contexts.
Handling an Interruption
- The interruption or exception arrives to the processor;
- The enclave context is saved, the application context is restored;
- The execution continues in the handler of the operating system;
- The handler returns (IRET) to the AEP, a trampoline function;
- AEP execute ERESUME if it decides to resume enclave execution;
- The enclave context previously saved is restored;
- The execution resuming where it stopped within the enclave.
When an enclave is instantiated, its code and data are protected from external accesses. But when it stops, all of its data is lost. Sealing is a way of securely saving the data outside of an enclave, on a hard-drive for example. The enclave must retrieve its Seal Key using the EGETKEY instruction. It uses this key to encrypt and ensure its data integrity. The algorithm used is chosen by the enclave author.
Using the Enclave Identity
The sealing can be done using the enclave identity. The key derivation is then based on the value of MRENCLAVE. Two distinct enclaves have different keys, but also two versions of the same enclave, which prevent the local migration of data.
Using the Signer Identity
The sealing can also be done using the signer identity. The key derivation is then based on the value of MRSIGNER. Two distinct enclaves still have different keys, but two versions of an enclave share the same key and can read the sealed data. If multiples enclaves are signed using the same keys, then they can all read each other's data.
Security Version Number (SVN)
Older versions of an enclave should not be allowed to read data sealed by a newer version of an enclave. To prevent it, the Security Version Number (SVN) is used. It is a counter incremented after each update impacting the security of the enclave. Keys are derived using the SVN in a way that an enclave can retrieve the keys corresponding to current, or older, security level, but not newer.
The enclave code and data are in plain-text before its initialization. While sections could technically be encrypted, the decryption key cannot be pre-installed (or it would not provide any additional security). Secrets have to come from the outside, might they be keys and sensitive data. The enclave must be able to prove to a third-party that it can be trusted (has not been tampered with) and is executing on a legitimate platform.
Two types of attestation exists:
- local attestation: an attestation process between two enclaves of the same platform;
- remote attestation: an attestation process between an enclave and third-party not on the platform.
- A channel must have already been established between enclave A and enclave B. It is used by enclave A to retrieve the MRENCLAVE of B.
- Enclave A calls EREPORT with the MRENCLAVE of B to generate a signed report for the latter.
- Enclave B calls EGETKEY to retrieve its Report Key and verify the MAC of the EREPORT structure. If valid, the enclave is the one expected and running on a legitimate platform.
Remote attestation requires an architectural enclave called the Quoting Enclave (QE). This enclave verifies and transforms the REPORT (locally verifiable) into a QUOTE (remotely verifiable) by signing it with another special key, the Provisioning Key.
- Initially, the enclave informs the application that it needs a secret located outside of the platform. The application establishes a secure communication with a server. The server responds with a challenge to prove that the enclave executing has not been tampered with and that the platform it executes on is legitimate;
- The application gives the Quoting Enclave identity and the challenge to its enclave;
- The enclave generate a manifest including the challenge answer and an ephemeral public key that will be used later to secure the communications between the server and the enclave. It generates a hash of the manifest that it includes in the user data section of the EREPORT instruction. The instruction generates a REPORT for the Quoting Enclave that ties the manifest to the enclave. The enclave passes the REPORT to the application.
- The application transfers the REPORT to the Quoting Enclave for verification and signing.
- The QE retrieves its Report Key using the EGETKEY instruction and verifies the REPORT. It creates the QUOTE structure and signs it using its Provisioning Key before giving it back to the application.
- The application sends the QUOTE and associated manifest to the server for verification.
- The server uses the attestation service provided by Intel to validate the QUOTE signature. It then checks the manifest integrity using the hash from the QUOTE user data. Finally, it makes sure that the manifest contains the expected answer to the challenge.
This blog-post gives an overview of the SGX internals. We've seen how memory is managed, how to load and call an enclave, and we detailed sealing, local and remote attestation.
In the next blog-post, we will present the SGX externals (everything that is not embedded in the CPU). We will talk about the development process of an SGX enclave, the SDK and PSW (Architectural Enclaves).
If you would like to learn more about our security audits and explore how we can help you, get in touch with us!