SGX Initial Communication

[Gerhard_M_]

Hello,

I am a researcher and have a question regarding the communication initialization with the SGX as a remote application. I understood it to be the following process, so please correct me if I am mistaken.

1. Check that the SGX is available and enabled
2. Create an enclave with a chosen application
3. Request an attestation report to verify the identity of the SGX and the correctness of the application
   1. The attestation contains an EREPORT structure as well as a manifest
   2. The manifest contains a newly created public key to continue secure communication
4. Use the enclave as intended

My main concern is creating this secure channel with the SGX. Did I understand it correctly that the public key is newly created for the enclave and has no affiliation to any of the EPID keys? If that is the case then I would also like to know how long that key exists as it has been described as "ephemeral". Is this just for initiating communication and a separate key exchange should be called afterwards? Or can I keep using that key for the duration of the lifecycle of the enclave?

Thanks in advance and have a nice day,

G.M.

[Anusha_K_Intel]

Hi,

The ephemeral public/private key is different from EPID key.

Once the server has been authenticated, the enclave can generate an ephemeral public/private key pair and include the public key in the user data portion of the report. This key is used to pass the encryption key from the server to the enclave and after the encryption key has been shared it is not required. hence it is used only for session establishment and not for the entire life cycle of the enclave.

you can find the detailed information in the secret Provisioning section of this document.

More information regarding Remote attestation can be found here

[Gerhard_M_]

Hi,

thank you very much. Could you also tell me which encryption scheme is being used? Or is it possible to select a certain scheme? If so I'd be interested in the list of supported algorithms.

[Anusha_K_Intel]

Hi,

Intel(R) SGX uses an anonymous signature scheme, Enhanced Privacy ID (EPID), for authentication (for example, attestation). The supplied key exchange libraries implement a Sigma-like protocol for session establishment. Sigma is a protocol that includes a Diffie-Hellman key exchange, but also addresses the weaknesses of DH. The protocol Intel(R) SGX uses differs from the Sigma protocol that’s used in IKE v1 and v2 in that the Intel(R) SGX plat-form uses EPID to authenticate while the service provider uses PKI. Finally, the KE libraries require the service provider to use an ECDSA, not an RSA, key pair in the authentication portion of the pro-tocol and the libraries use ECDH for the actual key exchange.

Developers wishing to debug their remote attestation service provider should be able to temporarily modify their cryptographic subsystem to behave in a similar manner as the sample_libcrypto.lib and replay the pre-com-puted messages stored in sample_messages.h. The responses from their own remote attestation service provider should match the ones generated by ours, which are also stored in sample_messages.h.

[Martim_C_]

If an enclave can generate an ephemeral public/private key pair and bind the public key to the attestation quote and send it to the provisioning entity, why does there need to be a key exchange protocol?

Anusha K. (Intel) wrote:

Hi,

Intel(R) SGX uses an anonymous signature scheme, Enhanced Privacy ID (EPID), for authentication (for example, attestation). The supplied key exchange libraries implement a Sigma-like protocol for session establishment. Sigma is a protocol that includes a Diffie-Hellman key exchange, but also addresses the weaknesses of DH. The protocol Intel(R) SGX uses differs from the Sigma protocol that’s used in IKE v1 and v2 in that the Intel(R) SGX plat-form uses EPID to authenticate while the service provider uses PKI. Finally, the KE libraries require the service provider to use an ECDSA, not an RSA, key pair in the authentication portion of the pro-tocol and the libraries use ECDH for the actual key exchange.

Developers wishing to debug their remote attestation service provider should be able to temporarily modify their cryptographic subsystem to behave in a similar manner as the sample_libcrypto.lib and replay the pre-com-puted messages stored in sample_messages.h. The responses from their own remote attestation service provider should match the ones generated by ours, which are also stored in sample_messages.h.