Question about recover enclave after recreated

[ThuongNguyen]

Hi all, 

I've been experimenting some stuff with Intel SGX and have a question regarding MRENCLAVE and enclave recovering.

Let's say I use the sgx_mrenclave to seal/encrypt my data, and for some reasons the enclave being recreated and I lost the access to the old sgx_mrenclave (as I understand, this seal key is created base on the enclave that runtime runs on).

In this case, I can't decrypt my data since the enclave is new, and so sgx_mrenclave. Is there any way that I can recover the old enclave along with sgx_mrenclave to restore my encrypted data (assuming I'm using Gramine to run my workload).

Thanks,

[Scott_R_Intel]

Hello.

If I understand your scenario correctly, in short, no, you cannot get back your sealed data.  If you use MRENCLAVE as your seal key derivation and for some reason you actually lose the exact enclave binary or can't recreate it (reproducible build), any new key derived will be from a new gramine-SGX binary with a new MRENCLAVE and therefore will be different from the original key derived from the original enclave binary.

FYI, most SGX applications/deployments these days first spin up a key management service which firsts attests remote enclaves and then deploys randomly created seal keys, so the keys can never be lost if the enclave is.  This is especially important if running inside a CSP, as your enclave could (almost assuredly will be) at some point in time have to be migrated from one server to another, and because seal keys (both MRENCLAVE and MRSIGNER based keys) are derived from the CPU fuse keys, sealing keys will always be different from one server to another.  Meaning, data sealed on one physical server using fuse-based keys can't be unsealed on another physical server.

Hope this helps.

Regards.

[ThuongNguyen]

Thanks Scott for the quick and clear answer.

I've a follow up question regarding the "for some reason", do we have any method to debug this thing, like know how the ISV/TCB changed, or what kind of metadata got changed that trigger the enclave recreation?

This will help us to get the deeper understanding on how SGX works under the hood.

Regards,

[Scott_R_Intel]

Hello again.

What do you mean by "enclave recreation"?  If it's the exact same enclave on the same physical server/platform, you won't have any issues deriving the exact same MRENCLAVE based sealing key.  That phrase I typed meant that if you somehow actually lost the original enclave binary and couldn't somehow reproduce it...  in this case, there's no way you could unseal the original MRENCLAVE based sealed data.

If you're running in a CSP, they will almost assuredly alert you (emails, alerts, etc.) way ahead of time that you need to migrate your enclave and therefore your data before they do any kind of TCB increase (CPU microcode update, etc.) and/or server migration.

Regards.

[ThuongNguyen]

Sorry for the confusion. I meant the enclave has been replaced by the new one.

This is our own server, so still trying to understand what changes have been made that caused our enclave to be replaced, even that was run on the same physical server, same docker image, we haven't changed the codebase for weeks, this server has been running stable for months.

Just one reboot and the enclave can't read the encrypted data anymore (we tried to reboot a few times in the past and the data was decrypted successfully), so this one is still confusing to me.

We accept the fact that we can't recover the data, just trying to dig deeper as much as we can, so in the future, we can prevent this from happening. Even with the KMS system in place as you mentioned in the previous answer, as an engineer, I still want to understand the root cause of this issue if possible.

Thanks Scott for your time here btw.