Thus far in this blog series on Intel Software Guard Extension (Intel SGX), we have touched on what Intel SGX is (, how it secures and accesses sensitive data (, and securely provisioning secrets in Intel SGX enclaves ( There is still another dimension of Intel SGX that we need to cover: how do enclaves save their state information?

If you recall, Intel SGX enclaves are protected regions of system memory. Enclaves are instantiated (and later provisioned) after each system start up, and they go away when systems shut down. Enclaves are by nature short lived. However, securely provisioning enclaves with secrets can be challenging, so it is highly desirable to preserve enclave secrets from session to session.

A number of scenarios drive the need to save enclaves’ state data. Power events are the most obvious. Application upgrades are another. And if a secret has been remotely provisioned, protecting that secret while offline can also be important. All of these cases use the same method to save enclaves states: data sealing.

Sealing Enclave Data to Disk

Data sealing produces a small piece of encrypted data that can be saved to disk or unprotected memory for later use by an enclave. An OCALL sends the state data out of the enclave to be saved to the disk (or memory). By default, the data sealed to the disk is encrypted in such a way that any enclave on the same computer using the same key can decrypt the sealed enclave data.[1]

Furthermore, data sealing is intended only for small bits of data that an enclave only needs on one system. Two factors drive this focus on small data sizes for sealing:

  1. OCALLs are computationally expensive. They are effectively context switches, and invoking them to seal large swathes of data can significantly impact application performance.
  2. Data sealing uses Advanced Encryption Standard (AES) Galois/Counter Mode (GCM) encryption, which is not meant for encrypting large amounts of data. Using this encryption algorithm on large amounts of data can be detrimental to application performance.

In short, data sealing is meant to save only the enclave state, not all of the data in the enclave. For example, data sealing is viable for saving the key with which a digital rights management (DRM)-protected movie is encrypted, but it’s not viable for saving the entire movie.

When to Seal Data

Even for small data batches, the computational toll from invoking OCALLs to seal data too frequently can impact application performance. At the same time, recreating an enclave state can take time, particularly if you have many secrets provisioned within the enclave. Determining how often to seal data is something of an art. It depends both on the nature of the workload in question and of the tolerance of that workload’s users for application lag. A good rule of thumb is to seal data whenever the state of the enclave changes significantly or when the effort to obtain the data was extensive. In practice, this works out to trying to seal data shortly after every time a secret is provisioned into the enclave.

For more details on data sealing in Intel SGX, see this article on the Intel Software Developer Zone: And for more insights on technology, follow @ProwessConsult on Twitter.

[1] This is just the default, however. Data can be also sealed with a key derived from a cryptographic hash of the enclave measurement as it goes through the build and initialization processes. Data sealed in this fashion can be accessed only by a particular enclave (rather than by any enclave produced using the same signing certificate). Note, however, that different builds or versions of an enclave will result in different enclave measurements. Sealed data based on enclave measurements will not be available to different versions of the same enclave, meaning this sealed data is not viable for saving enclave state between different application versions.

Share this: