🏦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.
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:
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:
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:
Derived Keys
The following platform-specific byte strings are derived from the device keys:
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:
The table below summarizes the inputs to the key derivation mechanism for different types of keys.
Last updated