Intel Software Guard eXtensions (SGX)

Intel Software Guard eXtensions (SGX) is an extension to the X86-64 instruction set architecture (ISA) that enables the creation and management of ‘enclaves’

in which sensitive code and data is hosted and executed. In general, Intel SGX aims to protect primarily against software-based adversaries originating from any protection mode, e.g. untrusted user- (ring 3) and kernel-mode (ring 0)

applications. At run-time, enclave code and data is protect by a hardware TCB including only the Intel CPU. This is achieved predominantly by allocating a DRAM region known as Processor Reserved Memory (PRM) containing the Enclave Page Cache (EPC) that holds four-kilobyte pages for enclave code and data. The CPU protects enclave pages in PRM from non-enclave and DMA memory accesses from external devices. An additional region, the Enclave Page Cache Metadata (EPCM), is used to store meta-data regarding the mapping of EPC pages to enclave identities. Enclave pages are encrypted outside the CPU using a proprietary Intel Memory Encryption Engine (MEE) to prevent divulging secrets stored in DRAM using certain hardware-based attacks, namely bus probing and cold-boot attacks. During execution, enclaves are still subject to conventional OS techniques like context switching and exceptions, e.g. interrupts.

When launching an SGX-enabled application, the Intel SGX run-time module requests the CPU to load SGX data from untrusted memory into EPC pages. This is performed using dedicated CPU instructions: ECREATE for creating a new Secure Enclave Control Structure (SECS) that stores the enclave meta-data; EADD to load code and data to new enclave pages; and EEXTEND for incrementally constructing the enclave measurement hash in 256-byte chunks. The initial application state is considered untrustworthy; it is urged that no secrets are statically stored (hard-coded) within the enclave code [103]. After the enclave code and data is loaded, the EINIT instruction is used to finalise the enclave measurement SHA-256 hash constructed through the EEXTEND instructions (also known as the MRENCLAVE value).

Enclave developers, or Independent Software Vendors (ISVs), must provide a certificate that includes the enclave’s identity represented by a SHA-256 of its code, data and meta-data, such as author name and version number, which is produced during the build procedure (known as the MRENCLAVE value). This value is used when sealing data – akin to TPM sealing – such that only an enclave with the same MRENCLAVE value can unseal that data when the enclave is relaunched. Another identity, the signing identity or MRSIGNER, is the authority who signs the enclave prior to distribution. Either MRSIGNER or MRENCLAVE may be used when sealing data persistently, either to allow data to be (un-)sealed between enclaves with the same developer identity, or restricted only to a single enclave respectively.

Each SGX-enabled CPU supports two 128-bit keys stored in ROM: the root provisioning (RPK) and sealing key (RSK). Each RPK is created off-site at a Intel Key Generation Facility and retained for assuring that the chipset is a genuine Intel SGX CPU. The RSK is created randomly at manufacture-time and used for secure storage using the sealing abstraction. Intel SGX uses a set of specialist enclaves for accessing ROM-resident keys: the provisioning enclave (PE) and

FIGURE2.12: Intel SGX key infrastructure [64].

a quoting enclave (QE) used for remote attestation. All keys, except the RPK, require the RSK for derivation, which renders them unknown to Intel. The Intel SGX key infrastructure is shown in Figure2.12.

SGX supports remote attestation based on the Enhanced Privacy ID (EPID) protocol – a DAA-based group signature scheme with revocation support. It allows the SGX enclave to demonstrate to a remote authority that it is utilising an authentic Intel SGX CPU. When SGX software is deployed, the PE is used to contact the Intel EPID Provisioning Server that ‘joins’ the CPU to the EPID group from its RPK. A separate EPID attestation key is then transmitted to the PE, which is used by the QE to sign quotes of the measured value of the target enclave during the remote attestation process. The EPID protocol allows a secure channel to be bootstrapped after the target enclave has been attested successfully. This is the intended method to provision secrets – keys, passwords and other credentials – into enclaves, rather than hard-coded secrets. The high-level attestation process

is shown in Figure2.13and described message-by-message below.

In (1), the host application receives an attestation request from the remote service that its enclave must produce an attestation quote (2). Next, a procedure known as local attestation occurs between the quoting enclave (QE) – a special enclave that is launched specifically for with access to the EPID attestation key – and the enclave to be attested. Here, the target enclave requests a local attestation report from the QE in which the CPU computes an AES128-CMAC tag on the

FIGURE2.13: Intel SGX remote attestation process [104].

MRENCLAVE value using the enclave’s report key (using EREPORT), which is verified and then replaced by a signature by the QE using the EPID attestation key. This produces the final quote that is returned to the host application (5) which, in turn, returns it to the challenger in (6). Lastly, the remote entity verifies the quote using the Intel Attestation Authority (see Figure2.12), which possesses public portions of the provisioned EPID keys.