When an enclave is instantiated it provides protection to the data by keeping it within the boundary of the enclave. Enclave developers should identify enclave data and/or state that is considered secret and potentially needs to be preserved across the following events during which the enclave is destroyed:
In general, the secrets provisioned to an enclave are lost when the enclave is closed. But if the secret data needs to be preserved during one of these events for future use within an enclave, then it must be stored outside the enclave boundary before closing the enclave. In order to protect and preserve the data, a mechanism is in place which allows enclave software to retrieve a key unique to that enclave. This key can only be generated by that enclave on that particular platform. Enclave software uses that key to encrypt data to the platform or to decrypt data already on the platform. SGX refer to these encrypt and decrypt operations as sealing and unsealing, respectively.
There are two options when sealing data or future unsealing conditions (different policies to derive sealing keys from Root Sealing Key, which is only known by the enclave):
Seal to Current Enclave:
This method binds the measurement of the current enclave, MRENCLAVE, to the key used by the sealing operation, using EGETKEY instruction. Therefore, only an enclave with the same MRENCLAVE will be able to generate the key to unseal the data. If any attribute related to the enclave has changed, the MRENCLAVE will also change. As a result, the sealing key will also change and the sealed data cannot be decrypted.
Seal to the Enclave Author:
This method binds the identity of the enclave author, which is stored in the enclave’s MRSIGNER register at initialization time, to the sealing key derived from the Root Sealing Key using EGETKEY instruction. The Product ID of the enclave is also binded to the derived sealing key. Therefore, only an enclave with the same MRSIGNER measurement and the same Product ID can retrieve the sealing key and unseal the data.
There are two benefits of this mechanism over sealing to the enclave identity. First, it allows an enclave to be upgraded by the enclave author without a complex upgrade process to unlock data sealed to the previous version of the enclave and reseal it to the new version. Second, it allows enclaves from the same author to share sealed data.
ISV enclaves are responsible for choosing and implementing the encryption scheme suitable for their needs when sealing their data. That is, SGX does not provide a complete sealing service, but rather a new security primitive (available exclusively for enclaves) based on EGETKEY features described.
First, allocate memory within the enclave for encrypted data and the sealed data structure which contains both the data to encrypt and additional data, such as application version and enclave information, which participates in the MAC calculation.
Then call the seal data API to perform the sealing operation, which will perform following steps:
Finally, save the seal data structure (including the key request structure) to external memory for future use within an enclave. The key request structure will be used in future enclave instantiations to obtain the seal key required for the decryption process.
First, allocate memory for the decrypted data.
Then call the unseal API to perform the unsealing operation, which will perform following steps:
We use sample code example to explain implementation details.