2023-11-05, nulya
As part of a longer analysis of the Signal contact discovery service, I wrote up a high-level overview of how Intel SGX enclaves work, copied verbatim below. For a more detailed and still very readable description, see this paper or this article.
Intel SGX (Software Guard Extensions) is a hardware isolation feature available on some Intel CPUs, which allows applications to run code in a special execution environment, called an "enclave", which is isolated from the rest of the system. Additionally, the CPU monitors the content and state of the enclave and allows local and remote applications to verify that the enclave is running trusted code and establish a secure communication channel. Although SGX is often used on client machines for implementing DRM, it is designed as a general-purpose trusted computing and isolation platform.
SGX enclaves are designed to run in untrusted environment and still preserve integrity and confidentiality against attacks from user applications, other enclaves, the operating system, startup code and hardware components. However, no attempts were made to thwart side-channel attacks, an issue made more severe by the kernel having full control over the scheduling of the enclave code.
Memory used by an SGX enclave is transparently encrypted by the CPU to prevent unauthorized access by other hardware and software components, using an enclave-specific encryption key. Each enclave is typically associated with a host application, and has access to its memory space. The host application can request services from the enclave by calling predefined entry points, using a mechanism very similar to kernel system calls, and the enclave can invoke services provided by the host application, since the enclave cannot execute system calls directly and all I/O must be mediated by the host application. To store persistent data, the enclave can seal data by encrypting them with an enclave-specific key and then passing them to the host application for storage.
The setup and execution of an enclave is implemented using a set of new complex CPU instructions implemented in microcode, and several new structures and checks in the memory paging implementation. During the setup of an enclave, the CPU internally computes a SHA-256 digest of the content, position and attributes of all memory pages loaded into the enclave, producing a value called MRENCLAVE, which serves as the identity of an enclave and is not machine-dependent. Additionally, the author of the enclave may sign the MRENCLAVE value, and the signature is then used to derive a MRSIGNER value; enclaves with the same MRSIGNER value may share data by encrypting them with a shared key -- this is typically used to allow newer versions of the enclave to access data stored by previous versions. Both of these values are stored as part of the SGX Enclave Control Structure (SECS), along with other enclave metadata.
Developers wishing to create SGX enclaves can use an SDK provided by Intel, which provides a high-level interface for SGX setup and communication, cooperating with Intel-provided OS drivers. The enclave is described in an EDL (Enclave Definition Language) file, a text file with C-like syntax, where the entry points, exit points and other attributes of the enclave are defined. The SDK then compiles the EDL file into a set of C files that provide wrappers over the raw enclave calls, allowing the developer to call into the enclave using ordinary C function calls. The enclave code is compiled into a shared library, which is loaded by the OS driver into a new SGX enclave during initialization.
SGX allows both local and remote applications to verify that the enclave is executing trusted code by retrieving the MRENCLAVE value of the enclave in a way that prevents forgery, and comparing it to a known-good value. This process is known as "attestation".
Local attestation occurs between two enclaves running on the same CPU, mediated by a host application, which serves as an untrusted communication channel. The key to local attestation is the EREPORT CPU instruction, which combines the contents of the SECS structure of the calling enclave with a block of custom user data provided by the enclave, and adds a symmetric authentication tag, creating a REPORT structure. The authentication tag is generated using an encryption key, called a \"Report Key\", that's specific to a single target enclave to which the REPORT is addressed, and only only accessible to the CPU itself and the owning enclave. This ensures that each REPORT is specific to a single pair of a generating and target enclaves and cannot be forged by any other enclave. Effectively, the tag serves as a signature over the data, but thanks to the shared trusted computing base (the CPU), a symmetric tag based on a hardware-protected key serves the same purpose with lower complexity. The custom user data stored in the REPORT is typically used for passing key material (an ephemeral public key or Diffie-Hellman exchange values) that's later used by the target to establish a secure communication channel with the current enclave.
Let us call ES the enclave whose identity is to be verified, and EV the verifying enclave. The following steps are undertaken for local attestation:
EV sends its MRENCLAVE value (uniquely identifying the enclave) to ES.
ES generates a REPORT as described above using the MRENCLAVE value of EV.
The REPORT is sent back to EV.
EV retrieves its Report Key and uses it to validate the authentication tag.
EV is now sure that the REPORT was not tampered with, and can read the MRENCLAVE and MRSIGNER values from the REPORT to get the identity of ES.
(optional) EV can use the included user data to establish a secure channel with ES.
Unlike with local attestation, there's no shared trusted platform between the peers during remote attestation, and asymmetric cryptography must be used to prove the identity of the enclave. However, asymmetric cryptography tends to be complex, and implementing it fully in hardware as part of a CPU instruction would be prohibitively expensive. Therefore, remote attestation is done in two steps -- first, a built-in trusted enclave called the Quoting Enclave verifies the target enclave using local attestation, and then signs the received REPORT using an asymmetric signing key trusted by Intel, which is then passed to the remote verifier, who can verify it against Intel attestation servers.
EPID (Intel Enhanced Privacy ID) is a group signature algorithm which allows an Intel attestation server to verify that a signature originated from a trusted Quoting Enclave, without revealing which exact CPU generated it, but allowing it to revoke leaked keys. Quoting Enclave uses a set of keys fused into the CPU during manufacturing to negotiate an attestation key with Intel servers, which it then seals and uses whenever it receives a remote attestation request.
Omitting a lot of details, a remote attestation resulting in a secure communication channel between the remote service RS and the enclave ES may be done with the following steps:
RS generates a cryptographic challenge and sends it to the host application. This prevents replay attacks, and is also needed for the internals of the attestation signing algorithm to be secure.
The host application retrieves the MRENCLAVE of the local Quoting Enclave and passes it to ES together with the challenge.
ES calculates the challenge response, generates an ephemeral public key and includes them into a REPORT addressed to Quoting Enclave generated using the EREPORT instruction.
The REPORT is passed to the host application, which passes it to Quoting Enclave.
Quoting Enclave verifies the authenticity of the REPORT, strips the authentication tag and signs the REPORT using an EPID private key. The resulting structure is called a QUOTE.
Quoting Enclave passes the QUOTE to the host application, which sends it to RS.
RS verifies the response to the sent challenge.
RS verifies the authenticity of the QUOTE by communicating with an Intel attestation server.
RS uses the ephemeral public key included in the QUOTE by ES to create a secure communication channel with ES.