Some consideration about SGX "enclave signing key"

[Changzheng_W_Intel]

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

[Anusha_K_Intel]

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. 

[David_B_1]

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?

[Rodolfo_S_]

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

[David_B_1]

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?

[Rodolfo_S_]

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.