Intel® Software Guard Extensions (Intel® SGX)
Use hardware-based isolation and memory encryption to provide more code protection in your solutions.

sealing to mrenclave question

riclee
Beginner
706 Views

If I take the 'sealing to mrenclave' policy to seal data on one computer , can i unseal the sealed data on the other computer with the same enclave code ?  I know the sealing key is derived from the root sealing key and mrenclave. If I unseal the sealed date on the other computer ,which means there is different root sealing key, because the RSK is related to the cpu which means different computer has different PSK , then the derivation sealing key could be different. So in my opinion , I think the other computer can not seal the sealed data even with the same enclave code ,  because the derivation sealing key is different, am I right? 

 

the other question, I can not find example about function 'sgx_seal_data_ex', only find 'sgx_seal_data' usage on SealUnseal example, Could you please supply an example about the usage 'sgx_seal_data_ex' ?

0 Kudos
1 Solution
Daniel_ˢᵍˣ
New Contributor I
534 Views

@riclee wrote:

If I take the 'sealing to mrenclave' policy to seal data on one computer , can i unseal the sealed data on the other computer with the same enclave code ?  I know the sealing key is derived from the root sealing key and mrenclave. If I unseal the sealed date on the other computer ,which means there is different root sealing key, because the RSK is related to the cpu which means different computer has different PSK , then the derivation sealing key could be different. So in my opinion , I think the other computer can not seal the sealed data even with the same enclave code ,  because the derivation sealing key is different, am I right?

Yes, you are correct. Sealing binds the sealed data to the processor whether the sealing policy is MRENCLAVE or MRSIGNER. This means only the sealing processor can unseal the data.

If you want to seal data in Processor 1 and unseal that data in Processor 2 (where Processor 1 and Processor 2 are different) then you could encrypt the data using e.g. sgx_rijndael128GCM_encrypt in Processor 1 and somehow pass the encryption key to Processor 2.

An alternative is using the Intel Protected File System library (with automatic keys) but this still has the problem that you are responsible for safely passing the encryption key from Processor 1 to Processor 2.

View solution in original post

7 Replies
Sahira_Intel
Moderator
671 Views

Hi,

 

sgx_seal_data_ex is used in the tSeal sample in the SGX SDK: https://github.com/intel/linux-sgx/blob/master/sdk/tseal/tSeal.cpp

This is a link to the Developer Ref Guide which has more information and syntax about this function: https://01.org/sites/default/files/documentation/intel_sgx_sdk_developer_reference_for_linux_os_pdf....

 

Sincerely,

Sahira

 

riclee
Beginner
665 Views

Thank you for supplying the example about sgx_seal_data_ex. Could you please answer the first question about sealing key?

AnaWilliam850
Beginner
634 Views

It is possible to unseal data that has been sealed using an enclave on a different computer, as long as the following conditions are met:

  1. The other computer must have an enclave with the same Mrenclave value as the one that was used to seal the data.

  2. The other computer must have access to the same sealing key that was used to seal the data. This may require that the sealing key be stored in a secure location and provided to the other computer as needed.

  3. The other computer must have the necessary software and hardware support for running enclaves and accessing sealed data.

riclee
Beginner
548 Views

sealing key is derived from the root sealing key and mrenclave with the sealing to mrenclave policy.  Different computer has different root sealing key, which means even the other computer has the same mrenclave, the sealing key could be different (because the root sealing key is different). This is my opinion, but i don't know am I right?

riclee
Beginner
548 Views

sealing key is derived from the root sealing key and mrenclave with the sealing to mrenclave policy.  Different computer has different root sealing key, which means even the other computer has the same mrenclave, the sealing key could be different (because the root sealing key is different). This is my opinion, but i don't know am I right?

Daniel_ˢᵍˣ
New Contributor I
535 Views

@riclee wrote:

If I take the 'sealing to mrenclave' policy to seal data on one computer , can i unseal the sealed data on the other computer with the same enclave code ?  I know the sealing key is derived from the root sealing key and mrenclave. If I unseal the sealed date on the other computer ,which means there is different root sealing key, because the RSK is related to the cpu which means different computer has different PSK , then the derivation sealing key could be different. So in my opinion , I think the other computer can not seal the sealed data even with the same enclave code ,  because the derivation sealing key is different, am I right?

Yes, you are correct. Sealing binds the sealed data to the processor whether the sealing policy is MRENCLAVE or MRSIGNER. This means only the sealing processor can unseal the data.

If you want to seal data in Processor 1 and unseal that data in Processor 2 (where Processor 1 and Processor 2 are different) then you could encrypt the data using e.g. sgx_rijndael128GCM_encrypt in Processor 1 and somehow pass the encryption key to Processor 2.

An alternative is using the Intel Protected File System library (with automatic keys) but this still has the problem that you are responsible for safely passing the encryption key from Processor 1 to Processor 2.

riclee
Beginner
524 Views

You mean if I want to seal data in processor1 and unseal the data in processor2, I should use the sgx sdk api sgx_rijndael128GCM_encrypt with my own seal key. If using the seal policy Mernclave or Mrsigner , the sealing key binds to the processor , so processor2 can not unseal the data sealed by processor1.

 

Thank you for your answer , I got it!

Reply