Intel® SGX Data Sealing
06/16/2023
Last updated
Was this helpful?
English
06/16/2023
Last updated
Was this helpful?
By Gavin
Intel® Software Guard Extensions (Intel® SGX) is a set of extension instruction sets implemented after the sixth-generation CPU, aiming to provide a trusted execution environment for user-mode applications. Therefore, Intel® SGX provides a secure memory container/region Enclave. Enclave provides a secure memory space for the applications running inside it and implements strict access control and encryption operations in this protected space for the confidentiality and integrity of sensitive data, so that even Hypervisor, BIOS, operating system and other privileged applications cannot freely access this address space.
The basis of SGX hardware-based encryption is that the CPU adds 17 instructions through microcode (ucode), together with Intel® ME (secure processor on Intel® CPU) to process key data such as the root private key of the Enclave.
Intel® SGX defines 17 new instructions, 12 among which are used by Supervisor while the other 5 are by the user.
Refer to the table below
SGX extension instruction set has 17 new instructions, 5 among which are user instructions, including:
EENTER Enter an enclave
EEXIT Exit an enclave
ERESUME Re-enter an enclave
EGETKEY Create a cryptographic key
EREPORT Create a cryptographic report
User instructions can be called directly when programming in an enclave. The simple operation is achieved through a number of system instructions. Since the creation of the enclave must take place in kernel space, and the interaction of the enclave is limited to user-space applications, privileged code cannot access the enclave, and non-privileged code cannot create an enclave.
Each CPU with support for SGX contains two root keys that are stored inside e-fuses: the Root Provisioning Key (RPK) and the Root Seal Key (RSK). The RPK is known to Intel® to enable the remote attestation process, while the RSK is only known to the platform for implementing the data seal. Despite the attacker model of SGX excluding physical attacks, efforts have been made to make the processor architecture difficult to tamper with, or at least to make extracting the keys a very costly operation. With enough hardware, it is possible to read the e-fuse, but in a destructive way. That is why only an encrypted version of the keys is stored on the e-fuses.
Key Architecture in SGX as below
The first key created by Intel® during the manufacturing process is the Root Provisioning Key (RPK). This key is generated randomly on a dedicated Hardware Security Module (HSM) located inside a facility called the Intel® Key Generation Facility (iKGF). Intel® is responsible for maintaining a database containing all keys produced by the HSM as those keys are the base for the following SGX service implementation attestation. The RPKs are sent to multiple production facilities to be embedded inside the processors' e-fuses.
The second key located inside the e-fuses is called the Root Sealing Key (RSK). It is created randomly and guaranteed to differ statistically between each unit produced. Contrary to the RSK, Intel® declares erasing every trace of these keys from their production chain, in order for each platform to have a unique key only known by itself.
By design, an enclave does not have access to the root keys. Nevertheless, it can access keys derived from the root keys.
Enclave can use EGETKEY instruction to generate keys for different purposes in combination with root keys, based on different request parameters and types of keys generated by requests.
Here are some important parameters for EGETKEY request:
Security Version Number (SVN): CPU SVN represents the updated version of the processor's microinstructions and ISV SVN indicates the Enclave code version. Versions can be compatible, but the old version cannot access the new version.
KeyName: EGETKEY sets the KEYNAME value in KEYREQUEST to generate different types of keys.
MRENCLAVE: Enclave Identity, a measure used to detect the integrity of an enclave, contains attributes, page location and content hash.
MRSIGNER: Enclave Identity, contains enclave author’s public key hash.
The derivation function allows an enclave author to specify a key derivation policy. These policies allow the use of trusted values like the MRENCLAVE, MRSIGNER and/or the attributes of the enclave (about MRENCLAVE and MRSIGNER will be explained later). Enclaves cannot derive keys belonging to an MRENCLAVE or MRSIGNER of another enclave.
As shown above, there are 5 derived keys:
Provisioning Key: Derived from RPK, the root of trust used for remote attestation
Provisioning Seal Key: Derived together from RPK and RSK, to encrypt Provisioning Key
EINITTOKEN Key: Launch Key, derived from the RSK and used by the Launch Enclave to generate an EINITTOKEN. Each enclave that is not signed by Intel® must obtain this token otherwise the processor cannot instantiate it
Seal Key: derived from the RSK, to encrypt data related to the current platform
Report Key: derived from the RSK and used for local attestation
Developers can only use Seal Key and Report Key.
Sealing is the process to encrypt sensitive data in the enclave for persistent storage to disk. Even though the enclave is torn down (either due to power event or by the application itself), the sealed data can be retrieved and subsequently brought back up. The sealing, which is essentially encryption, is performed using a private Seal Key that is unique to that particular platform and enclave, unknown to any other entity.
During the manufacturing process, a unique set of keys are generated and stored in the processor's fuse array. One of these keys, unknown to Intel®, is one of the key components used to derive subsequent seal keys. Among other components regarding derivation, choosing which enclave identity attribute to use (key derivation policy) is an important decision. This value is specified by the key_policy parameter of the sgx_seal_data_ex() function or the KEYREQUEST policy parameter of the EGETKEY instruction.
We first need to understand two enclave-related identities. One is Enclave Identity, another one is Signing Identity. The Enclave Identity is represented by the value of MRENCLAVE , which is the cryptographic hash of the enclave log that goes through each step from building to initialization. The value of MRENCLAVE corresponds to a specific Enclave Identity. So, Enclave Identity is used to limit access to sealed data. In other words, only instances of that enclave access those sealed data. The value of MRENCLAVE will also change if the enclave is built in different versions. So when using Enclave Identity for sealing, the data sealed only corresponds to the relevant enclave instance, not multiple versions of the enclave.
If choose the SGX_KEYPOLICY_MRENCLAVE policy, the enclave exclusively has the encrypted data sealed by Seal Key derived from the current Enclave Identity.
Signing Identity is provided by an authority that signs the enclave as it is built. This value is called MRSIGNER and is the same for all enclaves signed by the same authority. Therefore, it will allow one Seal Key to be used in different enclaves, including different versions of the same enclave. Developers can make use of the Signing Identity attribute to share sensitive data across multiple enclaves.
If choose the SGX_KEYPOLICY_MRSIGNER policy, multiple enclaves share data encrypted by a Seal Key derived from the same Signing Identity.
Alon Jackson. Trust is in the Keys of the Beholder: Extending SGX Autonomy and Anonymity.
Intel® 64 and IA-32 Architectures Software Developer's Manual Volume 3D
