Sealing and Unsealing using _sgx_mrenclave (different platform)

[tiagorvmartins]

Hey Gramine team just wanted to confirm something,

According to the documentation:

Key names beginning with underscore (_) denote special keys provided by Gramine:

"_sgx_mrenclave" (SGX only) is the SGX sealing key based on the MRENCLAVE identity of the enclave. This is useful to allow only the same enclave (on the same platform) to unseal files.

And also while skimming through this discussion here:
#855

Came to the conclusion that if an enclave app encrypts some file A using the _sgx_mrenclave key on the fs.mount specification in manifest, and then even if the same enclave code (same MRENCLAVE measurement) tries to use (unseal) that encrypted file A but on different machine (so different CPU -> different SGX Platform), it won't actually work right?

[Process A]
I guess, to overcome this issue we would then need to implement an internal process of keeping the old enclave (using old CPU) alive, then unseal the file and send the unencrypted file contents to the new platform and seal it again?

Did I got it right?
Unless we assume we always use the same CPU and SGX Platform (which is unrealistic ant not future proof), then we will need the process described on A), correct?

Thank you in advance!

EDIT: Process A assumes RA-TLS when sharing this secure data between two enclaves.

[kailun-qin]

then even if the same enclave code (same MRENCLAVE measurement) tries to use (unseal) that encrypted file A but on different machine (so different CPU -> different SGX Platform), it won't actually work right?

Right, it won't be able to unseal the data on another platform.

Unless we assume we always use the same CPU and SGX Platform (which is unrealistic ant not future proof), then we will need the process described on A), correct?

Yes, a migration process (e.g., unseal-transfer-reseal) is needed.

[tiagorvmartins]

Perfect, thank you for confirming!