This post is intended to introduce developers to the Sealing capability available on Intel® SGX enabled platforms. Sealing is the process of encrypting enclave secrets for persistent storage to disk. This allows secrets to be retrieved if the enclave is torn down (either due to power event or by the application itself), and subsequently brought back up. Encryption is performed using a private Seal Key that is unique to that particular platform and enclave, and is 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 fuse keys is not known by Intel and is one of the components used to form the basis for consistent derivation of subsequent sealing keys. Among other components included in the derivation, the selection of which enclave identity property to use is an important developer decision. This value is specified by the key_policy argument provided to the sgx_seal_data_ex() SDK function, or in the KEYREQUEST Policy argument to the EGETKEY instruction (if using the SGX extensions directly).
There are two identities associated with an enclave. The first is the Enclave Identity, and is represented by the value of MRENCLAVE, which is a cryptographic hash of the enclave log (measurement) as it goes through every step of the build and initialization process. MRENCLAVE uniquely identifies any particular enclave, so using the Enclave Identity will restrict access to the sealed data only to instances of that enclave. NOTE: Different builds/versions of an enclave will result in a different MRENCLAVE value. Thus, when sealing using the Enclave Identity, sealed data will not be available to different versions of the same enclave, only to identical enclave instantiations.
The second is the Signing Identity provided by an authority, which signs the enclave prior to distribution. This value is called MRSIGNER and will be the same for all enclaves signed with the same authority. Thus, it will allow the same sealing key to be used for different enclaves, including different versions of the same enclave. A developer can take advantage of sealing using the Signing Identity to share sensitive data via a sealed data blob between multiple enclaves for a given application and/or enclaves of different applications produced by that same development firm. NOTE: For SDK users, a simplified sgx_seal_data() function is available which does not require the key_policy parameter and uses the Signing Identity by default.
For a more detailed treatment of SGX sealing capabilities, refer to the following documents: