More Information

YouTube* Playlist

Subscribe to the Intel® Software Channel on YouTube

Hi, I'm John Mechalas with Intel. In this video, we're going to discuss the data sealing capability of Intel® Software Guard Extensions, or Intel® SGX.

There are situations where your Intel SGX application may need to save secrets outside of its enclaves. Enclaves are essentially stateless. They're destroyed when the system goes to sleep, when the application exits, and, of course, when the application explicitly destroys them. When an enclave is destroyed, all of its contents are lost.

To preserve the information that's stored in an enclave, you must explicitly send it outside the enclave to untrusted memory. The problem, of course, is that untrusted memory is just that—untrusted. It can be inspected and even modified by a malicious user.

To solve this problem, Intel SGX provides a capability called data sealing. When data is sealed, it is encrypted inside the enclave using an encryption key that is derived from the CPU. This encrypted data block, also called the sealed data, can only be decrypted or unsealed on the same system where it was created. The encryption itself provides assurances of confidentiality, integrity, and authenticity on the data.

When you seal data, you choose from one of two key policies: MRENCLAVE and MRSIGNER. These policies affect the derivation of the encryption key. The MRENCLAVE policy derives a key that is specific to that enclave on that system. This means that only that exact enclave on that computer can unseal the data.

The MRSIGNER policy derives a key that is specific to the developer signing key on that system. This allows data sealed by one enclave to be unsealed by another enclave by the same software vendor on the same system. The MRSIGNER policy allows you to seal data that can be read by later versions or builds of your enclave and application. You can also share data between two different enclaves in two different applications.

Note that in both of these key policies, the computer that is sealing the data is one of the key derivation inputs. If sealed data is copied to a second computer, that second computer will not be able to unseal it, even if it is running the exact same application. Another input to key derivation is the debug mode of the enclave. Enclaves built in debug mode cannot unseal data that was sealed by enclave's built-in release mode and vice versa. This is a security mechanism to prevent the Intel SGX debugger from using a debug enclave to expose secrets that were sealed by a production Intel SGX application.

There is an important caveat with data sealing that can have significant security implications. Enclaves do not authenticate the untrusted application. You must not assume that only your application will load your enclave or that your ECALLs will be invoked in a specific order. Anyone can load your enclave and execute its ECALLs in any order they choose. Your enclave's API must not allow the sealing and unsealing capabilities to leak secrets or grant unauthorized access to them.

Data sealing is an important capability offered by Intel SGX. With it, you can safely export secrets outside an enclave and be sure that these secrets have not been manipulated, altered, inspected, or even copied to another computer system when they are read back in.

Be sure to watch the rest of this playlist to learn more about Intel SGX application development. And remember to like this video and subscribe.