Community
cancel
Showing results for 
Search instead for 
Did you mean: 
1,185 Views

Some consideration about SGX "enclave signing key"

Jump to solution

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

 

 

 

0 Kudos
1 Solution
1,146 Views

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

View solution in original post

25 Replies
1,121 Views

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

1,121 Views

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

1,147 Views

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

View solution in original post

1,121 Views

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!

nia_b_
Beginner
1,121 Views

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?

1,121 Views

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

nia_b_
Beginner
1,121 Views

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? 

Sam5
New Contributor I
1,121 Views

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

-Thanks

Esmond_L_
Beginner
1,121 Views

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? 

1,121 Views

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

ramakrishna_b_
Beginner
1,121 Views

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

 

 

 

 

1,121 Views

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

1,121 Views

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

ramakrishna_b_
Beginner
1,121 Views

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

1,121 Views

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

ramakrishna_b_
Beginner
1,121 Views

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


 

1,121 Views

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

ramakrishna_b_
Beginner
1,121 Views

Thank you.

David_B_1
Beginner
1,121 Views

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

sai-satish
Beginner
355 Views

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

Regards

Sai Satish

Indian Servers, FreshersPlane

Reply