Intel Software Guard Extensions (SGX) is a set of processor instructions which leverage trusted hardware to enhance application security by allowing developers to isolate sensitive information using encrypted containers.
In this post I’m going to introduce Intel SGX, describe the basic architecture and functionality and also position SGX in the context of related technologies such as ARM TrustZone. Finally, I’ll give a high-level overview of the literature on SGX and discuss what I think the future might look like.
What is SGX?
SGX belongs to a relatively new group of technologies concerned with providing a secure environment for application code and data, also known as a Trusted Execution Environment (TEE) or trusted computing. SGX allows an application to instantiate an isolated container, known as an enclave, which provides confidentiality and integrity to its contents. Each SGX enclave can be thought of as a `reverse sandbox’ which protects the application code and data from a compromised host. Critically, this means that it’s possible to protect selected code and data from disclosure or modification, even when all of the privileged software (OS, hypervisor, firmware, etc.) is potentially compromised.
Since SGX enclaves provide a TEE on an otherwise untrusted platform, providing integrity and confidentiality guarantees for selected code and data, it enables secure computing on someone else’s computer.
For example, SGX can be used for Digital Rights Managements (DRM) and to prevent reverse engineering by having an enclave securely provision a public-key pair, encrypting all sensitive content using the enclave public key and then having the trusted CPU decrypt and execute the encrypted content. The `killer-app’ for SGX however is in enabling sensitive computation and data to be outsourced to the cloud. In particular, SGX can be used to build applications for processing confidential medical images, for privacy-preserving machine learning as a service, to enhance the security and privacy of the Tor privacy network and for outsourcing databases that guarantee confidentiality and integrity despite a malicious cloud provider, administrator, operating system etc.
Trusted Hardware and Attestation
For SGX to provide meaningful confidentiality and integrity assurances, the source of sensitive code and data must be able to determine that an enclave is being executed on trusted hardware. How can we be sure that a malicious OS or hypervisor hasn’t emulated the hardware and is planning to decrypt and read the contents of the enclave?
Like it’s predecessors the Trusted Platform Module (TPM) and Intel Trusted Execution Technology (TXT), SGX uses hardware secrets and an attestation protocol to enable remote authentication of genuine enclaves and their contents. Unlike TPM and TXT which authenticate the entire system software stack and the virtual machine code, respectively, the attestations necessary for SGX only concern the contents of a particular enclave and therefore result in a much smaller Trusted Code Base (TCB). In other words, SGX hardware-based attestation provides a guarantee that “this is the right application executing on the right platform”.
Each SGX-compatible Intel processor contains two unique 128-bit secret keys that are permanently fused into the chip during manufacture. There is a root provisioning key which is retained by Intel and a seal key which never leaves the chip. The keys used for attestation and for protecting data are all derived using both keys and so cannot be computed by either Intel or any other third party.
In more detail the SGX architecture is as follows. SGX appropriates a contiguous region of DRAM called the Processor Reserved Memory (PRM) which is used to store an enclaves’ code and data and that cannot be accessed by any other software or peripheral. Within the PRM is the Enclave Page Cache (EPC) where the enclaves’ code and data are stored in 4KB pages.
The initial code and data in an enclave is first loaded by the untrusted system. In particular, data is copied from outside the PRM into EPC pages which are then assigned to the enclave. The Enclave Page Cache Metadata (EPCM) ensures that each page in the EPC is only assigned to a single enclave.
As the enclave is loaded into the EPC by the untrusted system its contents are cryptographically hashed. Once the enclave is fully loaded into the EPC, the CPU marks the enclave as initialised and the finalised hash becomes the enclave’s measurement hash.
Once initialised, the enclave can begin a software attestation process which proves, either to another local enclave or to a remote verifier, that the enclave software is both unmodified and hosted inside a container that is protected by trusted hardware. Whilst local attestation is based on the enclave’s measurement hash and it’s certificate-based identities, remote attestation requires heavy-weight primitives which are too complex to be implemented in CPU hardware. To solve this problem, SGX remote attestation requires a special purpose, privileged enclave called the Quoting Enclave (QE).
The QE is issued by Intel and contains the signing functionality for remote attestation in SGX. During remote attestation, the attested enclave first uses local attestation to prove to the QE that it is running the correct software. Next, the QE uses the Intel Enhanced Privacy IDentification (EPID) attestation scheme to prove to the remote party that the attested enclave is running trusted software on trusted hardware. EPID is a scheme for Direct Anonymous Attestation (DAA) that has improved revocation capabilities. Like DAA, EPID is based on zero-knowledge proofs and allows signers to anonymously prove group membership.
In SGX, the EPID signature computed by the QE is derived from the seal and provisioning secrets that are unique to the trusted hardware, a key received from Intel’s provisioning service and the local attestation of the attested enclave. Remote SGX attestation succeeds when the remote party receives valid EPID signature, computed by the QE, on the local attestation report output by the attested enclave.
Once remote attestation has succeeded, the enclave can be provisioned secrets from a remote client and can then be expected to execute sensitive code and operate on confidential data without risking exposure or modification from the untrusted parts of the system.
Earlier in this post I mentioned TPM and Intel TXT, predecessors to SGX. While these technologies are also based on trusted hardware, they address a different problem and are not directly comparable to SGX. The TPM is an auxiliary, tamper-resistant chip that provides a measured boot process based on cryptographically hashing the code that is run at each stage. For example, the BIOS firmware is verified first followed by the boot loader, the OS and then the kernel modules. A TPM can be used to verify an arbitrary system state provided that the list of acceptable measurement hashes can keep pace with the provision of new software versions. Similarly to SGX, TPM supports a software attestation model based on DAA or EPID and can be used to anonymously attest to the presence of trusted hardware and software to a remote verifier. Unlike SGX the TPM trusts all of the software on the system and does not provide any isolation between applications.
Intel TXT uses the TPM chip and attestation model but reduces the secure container to a virtual machine supported by an appropriate CPU. Unlike the TPM, TXT does provide software isolation by ensuring that the virtual machine has exclusive control over the entire system while it is active. Unlike SGX, TXT does not protect the contents of the isolated container from the rest of the system and its code and data are not encrypted.
ARM TrustZone is similar to SGX in that it provides a mechanism for using trusted hardware to ensure isolation between different software components. In TrustZone, which is a collection of IP cores for use in proprietary integrated circuit designs, a system’s resources are partitioned into a secure world and a normal world. Similarly to SGX enclaves, code and data in the TrustZone secure world are protected by hardware from untrusted software located in the normal world. Beyond this, the precise security properties of TrustZone are largely dependent on the specific configuration of IP cores selected by the circuit designer and cannot be directly compared.
Some high-level and development-oriented details on SGX are provided by Intel in their tutorial slides and developer guide, respectively. They also have a page dedicated to showcasing academic research papers that either propose new applications, theory or attacks relating to SGX.
A thorough, academic explanation and evaluation of SGX from 2016 is given by Costan and Devadas in their paper, Intel SGX Explained. Their paper identifies a number of gaps in the security guarantees provided by SGX, highlights missing information in the publicly available documentation which prevent further analysis and concludes that
“… a security-conscious software developer cannot in good conscience rely on SGX for secure remote computation.”
The main criticism of SGX given by Costan and Devadas, and also Costan et al. in a later publication, is that while the SGX threat model protects against all direct attacks; it excludes side-channel attacks including those that can be performed in software alone.
As might be expected from this discovery, there are a number of side-channel attacks on Intel SGX in the literature. Foreshadow, for example, is a practical software-only architectural attack on SGX which abuses speculative execution to reliably leak plaintext enclave secrets from the CPU cache. Similarly, Götzfried et al. present a practical root-level cache-timing attack that is able to extract an AES secret key from an SGX enclave in less than 10 seconds.
Can we do better?
SGX addresses an important problem in an efficient way, but its present security model and lack of transparency prevent it from delivering strong security guarantees in all practical settings. Sanctum is an open-source set of hardware security extensions that provably provides the intended security guarantees of SGX in a security model which includes all known software side-channel attacks.
Whether using SGX or Sanctum, the provision of provably secure software containers presents an opportunity to develop new application and system architectures that are provably secure against all known direct and side-channel attacks.