Skip to main content

Secure enclaves

Secure enclaves are one out of two forms of confidential-computing environments (CCE). The other form are confidential virtual machines (CVMs).

The most widely known and adopted secure enclaves platform is Intel SGX, which is short for Software Guard Extensions. Intel started adding SGX to its processors in 2015. By now, SGX is available in many Xeon server processors. On an SGX-enabled system, enclaves can be created at runtime within virtually any application (or process to be more precise). The original intent of SGX was to enable programmers to selectively isolate and protect sensitive parts of an application. This could, for example, be the cryptographic library in a web server or the password manager within a browser. However, today, the most common approach is to run entire applications inside enclaves.

Technical details

Distinctive for SGX is its programming model. It requires a programmer to split an application into “enclave” and “host”. The enclave part has all the CCE features. The enclave contains all sensitive code, whereas the host contains non-sensitive code such as basic networking or file I/O. The enclave is protected from the rest of the system, whereas the host is not. “The rest of the system” from which the enclave is protected includes:

• the enclave’s own host

• other applications

• the operating system

• the hypervisor and host operating system

• the bootloader and other firmware such as the BIOS

• hardware other than the processor

Enclave and host talk to each other over an interface (or API) that is defined in advance. The host can call into the enclave, e.g., to have it perform a cryptographic operation. These calls are also referred to as ecalls. The enclave relies on the host to interact with the rest of the system. For example, to write to disk or to receive data over the network, the enclave needs to call into the host. These calls are referred to as ocalls. Ocalls are required because the enclave cannot talk to the operating system and the hardware directly. The host needs to do this for the enclave.

Splitting an application into enclave and host such that the result runs securely and stably can be challenging. The bigger the application, the bigger the challenge. Hence, a common approach today is to move all functional parts of an application into the enclave and use a boilerplate host for I/O. Modern SDKs and frameworks like EGo often even hide the split between host and enclave from the programmer.

Nitro Enclaves

Another implementation of secure enclaves are Nitro Enclaves, which are only available on AWS. The AWS Nitro platform, with a custom hypervisor and PCIe card, offers attestation features for enclaves. Depending on the underlying processor, Nitro Enclave memory may be encrypted at runtime. Nitro Enclaves are designed for privilege separation within the app, rather than protecting against the cloud operator or infrastructure, therefore it doesn't protect against infrastructure-based threats. Nitro Enclaves don’t have built-in memory encryption. Consequently, there is debate in the community whether Nitro Enclaves provide “real” confidential computing or not.