Can two enclaves have same MRENCLAVE ?

Can two enclaves have same MRENCLAVE ?

Hi Intel 

I have a doubt regarding MRENCLAVE. Suppose two different enclaves have same code, data, heap, everything. They only differ at MRSIGNER. Will the MRENCLAVE be same for both of them ? What if, these two enclaves are loaded at exactly same BASEADDR and the whole address layout is same. In that case, while calculating MRENCLAVE, SECS pages are not taken into account (which are the only pages which will be different in my opinion), so my guess is MRENCLAVE can be same for both of them

If yes, then dont we have a problem, because seal keys based on enclave identity will generate same keys, right ? Then one enclave's secret can be accessible by different enclave. What am I missing here ?

4 posts / 0 new
Last post
For more complete information about compiler optimizations, see our Optimization Notice.

You must sign the Enclave library with a key which makes the MRENCLAVE unique. Even you have identical code base, different signing keys will generate different MRENCLAVE identity and ensure that one Enclave cannot access the secret of other Enclaves.

Hi Hoang !

Thank you for your response. I understand your suggestion can generate different MRENCLAVEs. But I am concerned about scenarios where the same .so is used by everyone. For e.g. an open source software can have its .so as downloadable which runs an enclave. In these cases, everyone uses same .so file and hence probably can generate same MRENCLAVEs. Is there something to prevent this ? Or we simply assume that this wont be a usage model and enclave authors should take care of this (by generating different .so for each download or something like that). Apologies if this sounds silly, I am just trying to understand the usage model.


Open source for the enclave implementation and running the production enclave are two separate activities.

Currently, if you want to run the Enclave in production, you must register and create an entry in Intel whitelist

And in that process, you must provide a unique key to sign your Enclave which will generate a different MRENCLAVE values.


Sorry for opening an old thread.. but are you saying you cannot execute an enclave signed by an independant ISV?

I don't imagine most organizations would be inclined to have their own signing key to sign code from vendors.  If we take the example of Ledger; they have a blockchain wallet application which is SGX enabled to ensure the key material doesn't exist out side of the enclave.  Based on the fact that Ledger signs the application it would seem to be that the MRENCLAVE value of 2 instances of Ledger would end up being the same.  The CPU checks the MRENCLAVE value vs the SIGSTRUCT which is constructed at signing time.  

The fact that every instance of an enclave will have the same MRENCLAVE value is what allows the code signing feature to work; justs as it is the reason why remotely attesting an enclave isn't fully sufficient in order to grant access to secrets.  

Leave a Comment

Please sign in to add a comment. Not a member? Join today