Introduction to Intel® SGX Sealing

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:

  1. Innovative Technology for CPU Based Attestation and Sealing
  2. Intel SGX: EPID Provisioning and Attestation Services
  3. Intel SGX Evaluation SDK for Windows
  4. Intel SGX Programmers Reference
For more complete information about compiler optimizations, see our Optimization Notice.

5 comments

Top
kostascrypto's picture

Two comments after some extra research around EGETKEY for verifiable randomness:
a) To avoid successive requests to EGETKEY (per random number request) one could use only one sealing key, then use this in a custom KDF function along with a user defined nonce.
b) As already mentioned, unlike most of the SGX use cases I'm familiar with, in this particular scenario we don't care about CPU privacy and we actually want to ensure that an output has been generated in a combination of CPU/enclave to avoid replay attacks. Slightly more complex, but there are multiple ways to achieve this functionality, i.e a naive approach would be the following:

each enclave advertises a public deterministically generated nonce via EGETKEY again (verifiable through attached attestation signatures) along with the inputs to generate it, i.e., a keyID.

then each RNG request is accompanied with this nonce and keyID.

the enclave checks if it can generate the same nonce via EGETKEY and the provided keyID to ensure we target this particular CPU/enclave combination.

If the above check passes, return the signed random number + all input values.

There are interesting extensions of the above protocol to support leader election and other interesting business cases via threshold encryption and signatures in an attempt to simplify distributed randomness protocols. I'll keep you posted with more findings and potentially a link in one of my articles in an upcoming cryptography conference.

kostascrypto's picture

EGETKEY for verifiable randomness:
I'm working on public verifiable randomness sources and wondering if EGETKEY's KDF output can also be used for deterministically generating outputs that won't necessarily be used for sealing, but rather as pseudorandom values with an attached evidence (through attestation) that the output has been generated inside a particular combination of enclave/CPU. Obviously, to avoid replay attacks until you get a desired output, the computation should be deterministic, i.e., by providing (at least) as inputs MRENCLAVE and a user-defined seed. Imagine for example a leader election where participants have agreed on a seed and then they request from an enclave to return the result of EGETKEY over MRENCLAVE and this seed.
I'm still not sure how to link it with a particular CPU/enclave combination, to avoid another type of attack where one requests such numbers from various enclaves of the same type and then he/she advertises only the one that works for him/her. Any thoughts?

is it possible to seal and unseal data  sealed to MRSIGNER across different guest VMs sharing the same MRSIGNER.

or for instance between an enclave running on the host os and another enclave running on a hyerv hosted guest vm?

 

thank you

abashmak's picture

That's quite correct Matthias. SGX guarantees confidentiality and integrity of your data, but it does NOT guarantee availability! So your system is still vulnerable to DDoS attacks or viruses. However, while secret data may be lost, at least it will not be compromised.

mhahn1's picture

hopefully your sealed data never gets lost (disk corruption ...) or corrupted (DoS attack e.g. by virus ...) 

Add a Comment

Have a technical question? Visit our forums. Have site or software product issues? Contact support.