HW_Release mode Intel SGX applications without whitelisted keypair over sgx_lc enabled processor

[Anandakumar]

Hello All,

Recently I came across a weird behavior of the Intel SGX application built on Ubuntu20(kernel 5.13) with Intel SGX SDK, PSW 2.14 or above. I was able to load and run an application built with HW_Release mode and signed by the random RSA3072 keypair (not by a whitelisted keypair).

The same was observed in the Debian11( kernel 5.10 ) setup with the DCAP driver installed. Both machines support sgx_lc.

Someone, please explain why this is possible? I thought the enclave need to be signed by a whitelisted keypair in order to be loaded by LE(Launch Enclave). 

Thanks

Anand

[Sahira_Intel]

Hi Anand,

The white keypair must be RSA 3072 signed by the signer of the ref-LE.

Sincerely,

Sahira

[Anandakumar]

Hello Sahira,

I understood whatever the whitelisted keypair and enclave signing is. We have already completed the whitelisting process and we have one keypair for our application.

Here, the thing is, I am able to run an HW_Release mode build signed by a random RSA 3072 keypair.

Procedure to reproduce the behavior,

1. Go to the SampleEnclave project under the sgxsdk installation folder.

2. Open makefile and Set SGX_DEBUG ?= 0. 

3. Line 178: replace  $(Enclave_Name) with$(Signed_Enclave_Name). This will sign the HW_Release mode enclave with the test keypair.

4. Open the Enclave.config.xml file and set  <DisableDebug>1</DisableDebug>

5. run make

Now you will have an HW_Release build signed by the test keypair. This shouldn't be allowed to load. In my setup, it is loaded and running without any issue.

[Scott_R_Intel · Accepted solution]

Hi Anand.

With both the Linux DCAP and in-kernel drivers, any enclave is allowed to launch, by design, as you found out.  You don't actually need to be added to Intel's SGX Launch Policy Allow List (formerly known as the SGX Whitelist) to launch an enclave in HW production mode.  You can see how this is allowed directly in the code:

DCAP driver

In-kernel driver

In short, no matter what enclave is about to be launched or what key is used to sign it, the hash of that signing key from the enclave about to be launched is written into the 4 MSR_IA32_SGXLEPUBKEYHASH MSRs.

Scott

[Anandakumar]

Hi Scott,

Why this restriction was removed? Could you please explain the context?

With the new drivers, no need to get the whitelisted keypair. So, no need to sign an agreement with Intel to use Intel SGX in production mode?

Previously, whitelisting keypair is a part of the commercial licensing agreement signing.

Thanks,

Anand

[Scott_R_Intel]

Hi again Anand.

The biggest reason is the open source community never liked the Launch Policy Allow List, so it was removed.

You're correct... you no longer need to sign a commercial license agreement with Intel and supply your signing key hash to launch enclaves in production mode with CPUs that support the Flexible Launch Control feature.  Older CPUs still do not, so you would still need the commercial license and be added to the Allow List to launch on those CPUs.

Also be aware, if you plan to use the EPID based Intel Attestation Service (IAS) for SGX remote attestation, you would still need to sign a commercial license.  See the table at the link below for more detail:

https://www.intel.com/content/www/us/en/developer/tools/software-guard-extensions/request-license.html

Scott

[Anandakumar]

Scott,

Whitelisted keypair signing of an enclave acted as authorization to be loaded into production mode. Now, we don't validate the whitelist sign, then what is the purpose of signing it with a random key pair? Or signing the enclave is not required anymore?

If I seal any data using MRSIGNER, then we may need to maintain the same keypair. But, If I am not gonna use MRSIGNER in that case what is the use of enclave signing.

Thanks,

[Scott_R_Intel]

Hi Anand.

Yes, you still need to sign your enclaves and maintain your keys in a secure manner.  Though the DCAP and in-kernel drivers don't use a launch allow list, as I mentioned before, they still read MRSIGNER from the enclave being launched and write it into those registers so that that enclave is allowed to launch.  Also, an SGX user could theoretically build and maintain their own SGX kernel/driver and Launch Enclave and create their own launch policy just as Intel used to do.

You're correct about sealing with MRSIGNER...  you need to keep your keys if you plan to create and sign other enclaves that may need to seal/unseal the same data.  Also note that I mentioned "maintain your keys in a secure manner"... the reason I mention this is that if your keys get out (ie. stolen), then someone else could unseal your previously unsealed data.

One last note about using sealing keys that is sometimes missed by developers...  Sealing keys are CPU/platform specific.  Meaning, if you seal keys with a certain enclave using a certain sealing policy on one platform, you will not be able to unseal that data with the same enclave using the same policy on another platform.  If you need to seal/unseal data across multiple platforms you would need to create a key management service that would first use SGX remote attestation to verify your remote enclaves and the platforms, then dole out the same sealing/keys amongst those enclaves.

Hope this helps.

Scott

[Anandakumar]

Hi Scott,

Thanks for sharing this info.

Meaning, if you seal keys with a certain enclave using a certain sealing policy on one platform, you will not be able to unseal that data with the same enclave using the same policy on another platform.

I am aware of the sealing key retrieval process will yield different keys on different platforms for the same enclave implementations.

If you need to seal/unseal data across multiple platforms you would need to create a key management service that would first use SGX remote attestation to verify your remote enclaves and the platforms, then dole out the same sealing/keys amongst those enclaves.

We have plans to create a cluster of SGX enclaves with the same encryption/seal key. We have tested the same with the help of remote attestation between two enclaves which kind of a similar method you mentioned above. 

Is there any example implementation available for enclave to enclave remote attestation that I can make you of? Please share if any.

Thanks

Anand