Can two enclaves have same MRENCLAVE ?

[Deep_S_]

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 ?

[Hoang_N_Intel]

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.

[Deep_S_]

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.

Thanks

[Hoang_N_Intel]

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

https://software.intel.com/en-us/articles/intel-software-guard-extensions-product-licensing-faq

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

[Gardiner__Mike]

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.  

[Rd3]

Hoang Nguyen (Intel) wrote:

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,

I am confused. Doesn't the MRENCLAVE only relate to build chain and enclave's content? It is written in intel sdm 38.4.1. "MRENCLAVE represents the enclave's contents and build process. MRSIGNER represents the entity that signed the enclave's SIGSTRUCT".

why "Even you have identical code base, different signing keys will generate different MRENCLAVE identity"? I thought identical code base and buildchain will lead to same MRENCLAVE. Different signing keys will lead to different MRSIGNER?

Am I getting anything wrong?

Thanks!

Rd

[Francisco_C_Intel]

Rd - you are correct.

The same enclave, regardless of who signed it, will produce the same MRENCLAVE.

Thanks,

Francisco

[Rd3]

Francisco C. (Intel) wrote:

Rd - you are correct.

The same enclave, regardless of who signed it, will produce the same MRENCLAVE.

Thanks,

Francisco

Yes, thank you Francisco.  Btw, any chance you know a server that would support flexible launch control? I can only find the new NUC supports but I need a server for deploying DCAP. Also, I am wondering if all cpu that supports SGX will support Flexible launch control in the end? Since Flexible launch control does not requires new instructions. I am thinking an update of BIOS would be enough. Am I right or wrong?

I notice that from https://download.01.org/intel-sgx/dcap-1.0.1/docs/Intel_SGX_DCAP_ECDSA_Orientation.pdf, it claims "Intel® Xeon® E Processor based servers with Intel® SGX Flexible Launch Control feature enabled in BIOS are currently supported". My current guess is Xeon E series CPUs already support flexible launch control, but the BIOS is not following up. I am wondering if Flexible Launch Control feature requires a hardware update or a BIOS update is enough.

Thanks!

Rd