Some consideration about SGX "enclave signing key"

Some consideration about SGX "enclave signing key"

Hi

When I go through the "Intel® Software Guard Extensions - Developer Guide", I notice below words about "enclave signing key"

The enclave signing key is part of the enclave identity and it is critical to protect its secrets. An
attacker who compromises the private signing key of an ISV might be able to:
1. Write a malicious enclave that successfully attests to the identity of legitimate enclaves,
and/or
2. Write malware which uses the malicious enclave to compromise sealed data on individual
platforms.
Proper key management practice should be employed to safeguard the private signing key, for
example:
1. Maintain minimum access to the private signing key.
2. Use another enclave or a Hardware Security Module (HSM) to store the private signing
key and perform enclave signing.
3. Separate test signing from release signing using separate key pairs.

I understand that the signing key is critical to be protected. My question is that why does this signing key need to be involved into the enclave identity.

I suppose that the enclave code can be developed in a local trusted environment, after that the author can sign the enclave code using the signing key and send out it to the service provider environment. Is there any case that need this sign operation to be done on the service provider environment? Or the sign operation needs some service provider's platform information to complete this operation?

So I would like to know if I can keep the signing key in my trusted environment instead of using complex procedure to protect it in the service provider side such as using HSM or other enclave as mentioned above.

Maybe I miss something, please correct me.

Thanks

Changzheng

 

 

 

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

Hi Changzheng,

Signing an enclave is a process that involves in producing signature structure that contain enclave properties such as enclave Measurement. During initial enclave build by application developer, the enclave identity like "measurement of enclave" is used to produce the signature.This signed enclave signature is verified in the target system during the enclave construction and Initialization.In the target system (system at which enclave is to be launched), the measurement data that is obtained during the enclave launch, is used to verify the signature.If the signature match, then only enclave will be allowed to run.
If there is any modification in measurement value (code, data of enclave),  signature mismatch will occur. This will not allow the enclave to run. 

Thanks and Regards,
Surenthar Selvaraj

- Surenthar Selvaraj

Quote:

Surenthar Selvaraj. (Intel) wrote:

Hi Changzheng,

Signing an enclave is a process that involves in producing signature structure that contain enclave properties such as enclave Measurement. During initial enclave build by application developer, the enclave identity like "measurement of enclave" is used to produce the signature.This signed enclave signature is verified in the target system during the enclave construction and Initialization.In the target system (system at which enclave is to be launched), the measurement data that is obtained during the enclave launch, is used to verify the signature.If the signature match, then only enclave will be allowed to run.
If there is any modification in measurement value (code, data of enclave),  signature mismatch will occur. This will not allow the enclave to run. 

Thanks and Regards,
Surenthar Selvaraj

Yes, I understand this, my question is the signing process can be done offline which means the signing process can be performed on the user's local server(called service provider, is it right?) instead of the server where the enclave will be launched. Is that right?

If so , I suppose we don't need user provision its private key on the remote host (where the encalve will be launched), is that right?

Thanks

Best Reply

Hi Changzheng,

The signing tool supports a single-step signing process, which requires the access to the signing key pair on the local build system. However, there is a requirement that any white-listed enclave signing key must be managed in a hardware security module. Thus, the ISV’s test private key stored in the build platform will not be white-listed and enclaves signed with this key can only be launched in debug or prerelease mode.

The signing process can be performed on the user's local system(called SGX Enabled System). Signed enclave signature is verified in the target system during the enclave construction and Initialization.In the target system (system at which enclave is to be launched), the measurement data that is obtained during the enclave launch, is used to verify the signature.If the signature match, then only enclave will be allowed to run.

Thanks and Regards,
Surenthar Selvaraj

- Surenthar Selvaraj

Quote:

Surenthar Selvaraj. (Intel) wrote:

Hi Changzheng,

The signing tool supports a single-step signing process, which requires the access to the signing key pair on the local build system. However, there is a requirement that any white-listed enclave signing key must be managed in a hardware security module. Thus, the ISV’s test private key stored in the build platform will not be white-listed and enclaves signed with this key can only be launched in debug or prerelease mode.

The signing process can be performed on the user's local system(called SGX Enabled System). Signed enclave signature is verified in the target system during the enclave construction and Initialization.In the target system (system at which enclave is to be launched), the measurement data that is obtained during the enclave launch, is used to verify the signature.If the signature match, then only enclave will be allowed to run.

Thanks and Regards,
Surenthar Selvaraj

 

OK, I see. Thanks a lot!

Hi Surenthar,

Per you discussion with ChangZheng,I also have some questions about enclave signature and the signing key:

1. How to generate the enclave signature?

2.The signing key is the private key ? How to use the private key sign the enclave?

Use signing tool in the target system (system at which enclave is to be launched) or on the user's local system(called SGX Enabled System)?

3."The signing tool supports a single-step signing process, which requires the access to the signing key pair on the local build system. "

Who provides the signing tool? Should be ISV or SGX?

4."there is a requirement that any white-listed enclave signing key must be managed in a hardware security module. "

Can we use another enclave to protect the private key instead of being managed in HSM?

Hi Nia,

1. How to generate the enclave signature?

  • Enclave Signing Tool is used to generate the enclave signature

2.The signing key is the private key ? How to use the private key sign the enclave? Use signing tool in the target system (system at which enclave is to be launched) or on the user's local system(called SGX Enabled System)?

  • Use signing tool in the User's local system(called SGX Enabled System)

3."The signing tool supports a single-step signing process, which requires the access to the signing key pair on the local build system." Who provides the signing tool? Should be ISV or SGX?

  • Intel® Software Guard Extensions Evaluation SDK provides the signing tool.

4."There is a requirement that any white-listed enclave signing key must be managed in a hardware security module." Can we use another enclave to protect the private key instead of being managed in HSM?

  • No. it not possible.

Thanks and Regards,
Surenthar Selvaraj

- Surenthar Selvaraj

Surenthar,

For last question,as "Intel® Software Guard Extensions - Developer Guide" describes,

"

Safeguarding the Enclave Signing Key
Proper key management practice should be employed to safeguard the private signing key, for
example:
l Maintain minimum access to the private signing key.
l Use another enclave or a Hardware Security Module (HSM) to store the private signing
key and perform enclave signing.
l Separate test signing from release signing using separate key pairs.

"

why you said it was not possible to use another enclave to protect the signing key? 

Yes, We can use another enclave to protect the private key and perform the enclave signing.

-Thanks

I'm a little confused with what keys we are supposed to use for signing? When developing our SGX application, I understand that we can just generate a local RSA keypair and use that to sign the code and run it in Debug/Pre-Release/Simulation modes on our local systems. However, for Release mode, it sounds like we can't use this method. What key do we use, and how can we obtain it to sign our SGX application? 

Hi

You need to use the 2 step signing Method. 

Enclave Signing Key Management:
2-step method using an external signing tool:
First step: At the end of the enclave build process, the signing tool generates the enclave signing material. The ISV takes the enclave signing material file to an external signing platform/facility where the private key is stored, signs the signing material file, and takes the resulting signature file back to the build platform.

Second step: The ISV runs the signing tool with the catsig command providing the necessary information at the command line to add the hash of the public key and signature to the enclave’s metadata section.

The 2-step signing process protects the signing key in a separate facility. Thus it is the default signing method for the Intel SGX project release profile. This means it is the only method for signing production enclave applications.

Enclave Signing Example:
Two-step signing process:
Signing an enclave using a private key stored in an HSM, for instance:
1. Generate the enclave signing material.
sgx_sign gendata -enclave enclave.so -config config.xml -out enclave_hash.hex

2. At the signing facility, sign the file containing the enclave signing material (enclave_hash.hex) and take the resulting signature file (signature.hex) back to the build platform.

3. Sign the enclave using the signature file and public key.
sgx_sign catsig -enclave enclave.so -config config.xml -out enclave_signed.so -key public.pem -sig signature.hex -unsigned enclave_hash.hex

Currently the evaluation SDK allows the developer to create and run enclaves using the Debug and Pre-release profiles. Enclaves compiled under the Release profile will not work until the developer completes the production licensing process. If you would like to deliver a production-quality application using SGX, please contact the SGX Program<sgx_program@intel.com> for more information about a production license.

Once you get the license for release mode product, use this key to sign the enclave.

-Surenthar

- Surenthar Selvaraj

Hello Selvaraj, Is there a way to skip going to signing facility for demo purpose? With this constraint there is no mechanism to prove SGX protection works right now. With Debug buid, I can read the contents of an enclave through toolhelp API and the Release build fails to create an enclave. Please suggest a work around. Thank you. -Ram

 

 

 

 

Hi,

If you want to build the SGX application in release mode, then you need to get the license from Intel. Please refer the below link for your reference 

-Surenthar

- Surenthar Selvaraj

Quote:

ramakrishna bikumalla wrote:

Hello Selvaraj, Is there a way to skip going to signing facility for demo purpose? With this constraint there is no mechanism to prove SGX protection works right now. With Debug buid, I can read the contents of an enclave through toolhelp API and the Release build fails to create an enclave. Please suggest a work around. Thank you. -Ram

Is there a way to skip going to signing facility for demo purpose?

  • By default, a Post Build Event for generating enclave signing material is added during enclave creation with Microsoft* Visual Studio* in Intel(R) Software Guard Extensions Wizard. Thus, for the release mode, the enclave signing material is generated automatically after you compile the enclave project. You need to remove the Post build event to skip the signing operation

If you want to build the SGX application in release mode, then you need to get the license from Intel. Please refer the below link for your reference 

-Surenthar

- Surenthar Selvaraj

Thank you Surenthar for the information.

We will go through Licensing once we can show case the need and prove how this technology would be useful. In the mean time, with the debug/pre-release build a dummy malware app (using ReadProcess and kernel modules) can read the contents of the Enclave. Data in the Enclave is acting just like any other data in the process space. I tried removing the post build event then the Enclave creation is failing just like any release build. Enclave creation is failing when I build for release, the same pattern when DisableDebug flag is enabled or "SGX_DEBUG_FLAG" flag is set to 0 in "sgx_create_enclave" function.

Please suggest if there is any alternative. Thank you. Greatly appreciate your help.

-Ram

Hi,

Why you want to disable the signing facility? Because if you disable the “Post Build” Event in Enclave, then it will not generate the “Enclave.signed.dll”. Without this signed.dll, you are not able to create Enclave. “ENCLAVE_FILE” is one of the parameter for “sgx_create_enclave”.

-Surenthar

- Surenthar Selvaraj

Surenthar,

I don't want to disable, I thought you were suggesting that is the way to make it work in "Release" mode. All I want is to prove the use of the technology. Right now in debug mode I can't because I can read the contents of enclave from another application/process. This breaks the usability of the Enclave and SGX.

I hope you understand. Please suggest if you see an alternative.

Thank you.

Best regards,

Ram

 

Hi,

If you want to execute the release mode build, you need to get the license for that. Currently the evaluation SDK allows the developer to create and run enclaves using the Debug and Pre-release profiles. Enclaves compiled under the Release profile will not work until the developer completes the production licensing process. If you would like to deliver a production-quality application using SGX, please contact the SGX Program <sgx_program@intel.com> for more information about a production license. Please refer the below link for your reference.

-Surenthar

- Surenthar Selvaraj

Thank you.

Hello,

I would like to understand better the threats posed by revealing the private signing key. The guide states:

" The enclave signing key is part of the enclave identity and it is critical to protect its secrets. An attacker who compromises the private signing key of an ISV might be able to:

- Write a malicious enclave that successfully attests to the identity of legitimate enclaves, and/or

- Write malware which uses the malicious enclave to compromise sealed data on individual platforms. "

For the first bullet point: How could an attacker write another enclave that "successfully attests to the identity of legitimate enclave"? Another part of the identity being the processor itself, I would assume there is a mechanism that prevents two enclaves to have the same identity on the same processor ..?

For the second bullet point: Does it mean the a malicious enclave could compromise data form another enclave? Or does it mean that an enclave signed by an ISV could become malicious if an attackers obtains the private key? In the second case, wouldn't the ISV notice the problem by requesting a remote attestation, or could the intrusion happen between two attestation?

Thanks, David

I got this Error "Public key is required for the "catsig" command."

Regards

Sai Satish

Indian Servers, FreshersPlane

Hi,

While using catsig command we need to input the public key in .pem format. 
sgx_sign catsig -enclave enclave.so -config config.xml -out enclave_signed.so -key public.pem -sig signature.hex -unsigned enclave_hash.hex

Public key file should follow the PEM format which contains an unencrypted RSA 3072-bit key and the public exponent must be 3. 

Hi,

I'm still struggling to understand the threats posed by revealing the private signing key (as I mentioned above). Can someone help me on this?

The guide states:

" The enclave signing key is part of the enclave identity and it is critical to protect its secrets. An attacker who compromises the private signing key of an ISV might be able to:

- Write a malicious enclave that successfully attests to the identity of legitimate enclaves, and/or

- Write malware which uses the malicious enclave to compromise sealed data on individual platforms. "

For the first bullet point: How could an attacker write another enclave that "successfully attests to the identity of legitimate enclave"? Another part of the identity being the processor itself, I would assume there is a mechanism that prevents two enclaves to have the same identity on the same processor ..?

For the second bullet point: Does it mean the a malicious enclave could compromise data form another enclave? Or does it mean that an enclave signed by an ISV could become malicious if an attackers obtains the private key? In the second case, wouldn't the ISV notice the problem by requesting a remote attestation, or could the intrusion happen between two attestation?

Hi, David.

I'm not sure if you read the white paper here, but sections 1 and 2 may be helpful to understand the threats of having the private signing key revealed.

When talking about SGX, there are two different IDs:

  1. MRENCLAVE - The enclave identity
  2. MRSIGNER - The signing identity

Regarding the first question, if someone only checks the MRSIGNER in the attestation process, a malicious enclave could be attested if it was signed with the revealed private key.

Regarding the second question, section 1.1 of the white paper I mentioned explains why the private signing key is important, and why a malware can compromise sealed data if it acquires the private key.

Best regards,
Rodolfo

Thanks Rodolfo,

After reading section 4.1 of the white paper you suggested, it seems to me that loosing the private signing key is mostly a problem for the "Sealing to the Sealing Identity" policy but not so much for the "Sealing to the Enclave Identity" policy.

"Sealing to the Sealing Identity" is needed if one needs to transfer sealed data to a new version of the enclave. However, if data transfer is not needed and "Sealing to the Enclave Identity" is used, then attestation using MRENCLAVE ensures that data is safe even if the private signing key is compromised.

Am I getting this right?

Hi, David.

Regarding the sealing/unsealing process you are correct - "Sealing to the Sealing Identity" is only necessary when transferring data to a new version of the enclave.

But there is a little more to revealing the private signing key. Let's say you are a big company, XPTO, with multiple applications, and after some time people started trusting you/your applications. If your signing key is revealed, other people could sign their applications, even rogue ones, with it, and they would be shown as developed by XPTO, ruining its trustworthiness.

Leave a Comment

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