🏦Memory Encryption

Memory Layout

The Enclave Page Cache (EPC) serves as a specialized memory region that contains an enclave's code and data. Each page within the EPC is encrypted using the Memory Encryption Engine (MEE). The Enclave Page Cache Map (EPCM) stores metadata about each page, including configuration, permissions, and page type. Under SGX, the operating system and hypervisor retain complete control over the page tables, and the address translation process and page tables used by the host application are shared with the code of each enclave.

Memory layout

The EPCM ensures memory protection and prevents virtual address translations from compromising enclave security. For example, if the system software attempts to allocate the same EPC page to two enclaves, the corresponding SGX instruction for allocation will fail.

There are four data structures associated with enclave operation within the EPC:

Regular Structure

Regular EPC pages contain the code and data of an enclave.

SGX Enclave Control Structure (SECS)

Each enclave has one SECS, which holds metadata used by the hardware to protect the enclave.

Thread Control Structure (TCS)

Each enclave contains one or more TCSs, which store metadata used by the hardware to preserve thread-specific information during enclave entry and exit.

Version Array (VA)

Version Array pages consist of 512 slots, where each slot can store a version number for a page that has been evicted from the EPC.

During boot time, keys are generated specifically for decrypting the contents of encrypted pages within the CPU. These keys are managed by the Memory Encryption Engine (MEE) and are never exposed externally. Consequently, only the specific CPU can decrypt the memory since the keys are stored internally and inaccessible to any software. Furthermore, privileged software operating outside enclaves is restricted from reading or writing the EPC or EPCM pages.

The MEE utilizes a complex combination of Merkle trees, a modified version of AES Counter Mode, and a Carter-Wegman MAC construction. It employs a 128-bit confidentiality key, a 56-bit counter, a 128-bit integrity key (producing 56-bit MAC tags), and a 512-bit universal hash key (used in the MAC construction). These keys are generated during boot, stored in dedicated MEE registers, and destroyed upon system reset. The MEE operates on 512-bit cache lines, requiring four AES operations for each encryption.

The MEE implements a proprietary mechanism to encrypt and authenticate the EPC and EPCM. However, the ability to read and write each page table in an encrypted form results in a significant number of message authentication tags. While the MEE was designed to minimize the number of tags, in the context of SGXv2 with up to 1TB EPC, approximately 25% of memory is allocated for these tags. To free up more memory for enclaved applications, SGXv2 introduced Total Memory Encryption - Multi-Key (TME-MK), which replaces the MEE algorithm with a Merkle-Tree-based AES-XTS.

Identities

Two identities are associated with each enclave:

Enclave Identity

Represented by the value of MRENCLAVE, which is a SHA256 digest of the enclave log (measurement) throughout the build and initialization process. The log includes memory content such as code, data, stack, and heap, as well as the relative location of each page within the enclave and the security flags being used. MRENCLAVE uniquely identifies a specific enclave, ensuring that sealed data is only accessible to instances of that enclave. It's important to note that different builds or versions of an enclave will result in different MRENCLAVE values.

Signing Identity

Provided by an authority and referred to as MRSIGNER. The authority signs the enclave using a 3064-bit RSA signature algorithm before distribution. MRSIGNER represents the SHA256 hash of the signing public key modulus and uniquely identifies all enclaves issued by the same signer.

In addition to the enclave and signer measurements, developers are expected to define a product ID and Security Version Number (SVN). With the introduction of KSS in SGXv2, new build attributes include a family ID and extended product ID, while new enclave launch attributes consist of Config ID and Config SVN. These identifiers, along with a user-defined 64-byte string, are part of the EREPORT, a hardware instruction that generates a data structure containing the enclave's measurement, signer identity, attributes, and additional information.

The EREPORT is typically used during local attestation and is embedded into the quote. The attributes are also utilized by SGX key derivation to generate different keys for each configuration. Thus, the introduction of new launch and build attributes enables a finer-grained key derivation mechanism, allowing a single authority to build, enclave, and attest various categories and versions of a program.

Keys

Enclaves can employ the hardware instruction EGETKEY to obtain derivatives of device keys. EGETKEY generates symmetric keys based on invoking enclave attributes and the requested key type. There are five different key types, two of which are sealing and report keys available for all enclaves, while the remaining three are exclusive to SGX architectural enclaves. EGETKEY utilizes the requested enclave's SVN to define key characteristics, CPUSVN to reflect the processor microcode version, or ISVSVN to reflect the enclave software version.

Device Root Keys

There are two device root keys that are fused into SGX CPUs during production:

Root Provisioning Key (RPK)

This key is randomly generated on a dedicated Hardware Security Module (HSM) within the Intel Key Generation Facility (iKGF), a highly secure offline production facility. Intel maintains a database of all keys produced by the HSM, which are delivered to different factory facilities for integration into processors' fuses. RPKs serve as the basis for demonstrating the authenticity of SGX processors through an online provisioning protocol. Different derivations of each RPK are also forwarded to Intel's online servers.

Root Sealing Key (RSK)

This key is automatically generated within each CPU during production, ensuring statistical uniqueness across different platforms. Intel aims to erase all residues of this key on the production line, ensuring that each platform assumes its RSK value is both unique and known only to itself. Many keys provided by the enclave's trusted interface are derived from the platform's RSK to prevent other parties from accessing the keys.

Derived Keys

The following platform-specific byte strings are derived from the device keys:

Report

EREPORT verification key.

EINIT Token

EINIT Token creation key. The EINIT token is used by EINIT to verify if an enclave is authorized to launch. The EINIT token is generated by an enclave possessing the EINITTOKEN key, which is the Launch Enclave.

Seal Key

Protects enclave secrets that need to be shared outside the enclave for long-term retention.

Provision Seal Key

An attestation key provisioning enclave uses this key to protect attestation keys for long-term retention outside the enclave.

Provisioning Key

An attestation key provisioning enclave uses this key to demonstrate that the platform is the Trusted Computing Base (TCB) it claims to be.

SGX Key derivation hierarchy

Derivation Mechanism

The key derivation process involves two stages. Each update to the processor logic is signed and assigned a Security Version Number (SVN), representing the security revision of the platform. By employing a pseudorandom function (PRF) with the Security Version Number and the Root Provisioning Key as inputs, a "versioned" key is derived, bound to the current platform version. This "versioned" key, along with other inputs, is then used to derive the keys mentioned above (refer to the Figure above). The parameters used in this process include:

MRENCLAVE

A SHA256 hash measurement of the enclave computed during the build.

MRSIGNER

A SHA256 hash of the public key modulus used to sign the enclave SIGSTRUCT.

CPUSVN

The set of Security Version Numbers (SVNs) of firmware components in the Trusted Computing Base (TCB).

ISVSVN

The SVN of the software component in the TCB assigned by the enclave signer through SIGSTRUCT.

ISVPRODID

A product identifier assigned by the enclave signer through SIGSTRUCT.

OwnerEpoch

A value provided by the platform, created when a new owner takes possession of the platform.

The table below summarizes the inputs to the key derivation mechanism for different types of keys.

Inputs to the key derivation mechanism