How to encrypt the message from Enclave to Application?

[Domonic]

Hi, I’m new to the Intel SGX. And have some doubts about data secret between Enclave to Application. Let’s say Application call a simple function from Enclave – get_size(), then Enclave will return a fixed number “100” to Application. It seems that the return value of Enclave is plaintext. The question here is that can Enclave support the secret data for the return value 100. So Application can’t directly decode the return value of get_size(). It must need a key to decode the message from Enclave. Any recommendation?

//appication.cpp
int main() {
 int size = 0;
 size = get_size();
}

//enclave.cpp
int get_size() {
 return 100;//how to encode the value of 100?
}

[JesusG_Intel]

Hello Domonic,

The application that calls the enclave is considered "untrusted" for this very reason. If you encode the returned data and you want the untrusted application to read and understand that data, then the untrusted application must know how to decode it.

If you need to securely extract a secret from an enclave then you can use the seal and unseal capabilities of SGX or, local or remote attestation to pass that data to a relying third party. These techniques are discussed in the Intel SGX Developer Reference guides for your OS, e.g. Intel® Software Guard Extensions Developer Reference for Windows.

[Domonic]

Hi Jesus,

In distribution system, data center will receive raw information from different Applications. But, how to make sure data center can filter the fake data from Application? e.g Application receives the result from Enclave - 100, but it can be modified -> 200 by Application during submit to data center as below:

Enclave ---[100]---> Application ---[200]---> Data Center 

Does SGX have any mechanisms to prevent data tampering for Application? Like data-signature function for all output from Enclave. So data center can verify the info from Application is generated by vendor's Enclave.

Enclave ---[MSG = 100 + signature]---> Application ---[MSG]---> Data Center 

Data Center will decode MSG by using private key.

[JesusG_Intel]

Yes, this is exactly what remote attestation does. Check out this article for more information: https://software.intel.com/content/www/us/en/develop/articles/code-sample-intel-software-guard-extensions-remote-attestation-end-to-end-example.html

[Domonic]

Yes, Remote Attestation can verify the Enclave if provided by s/w vender. But, how about the data communication between Application and Data Centre after passing Remote Attestation? I mean Application may provide data tempering for Data Centre. So, how to solve this kind of problem (Fig. 3) through SGX?  Please check the more details explanation as below:

[JesusG_Intel]

Hello Domonic,

It is the responsibility of the ISV to implement the application, service provider, and secure, encrypted channel for communication between the components. The remote attestation sample article, https://software.intel.com/content/www/us/en/develop/articles/code-sample-intel-software-guard-extensions-remote-attestation-end-to-end-example.html, explains:

"While the Intel SGX SDK provides convenient wrappers for the entire attestation flow, including encapsulating cryptographic functionality, no such convenience exists for implementing the remote service provider. This sample shows how to create a service provider capable of facilitating Remote Attestation with a client, utilizing cryptographic routines from the OpenSSL* libraries."

[Domonic]

Hi Jesus,

Thanks for your suggestion. Could you also help to check the conclusion for the SGX as below?

1. Enclave can make sure that data/code privacy inside enclave. But, we can't confirm that the input data of ISV/Data Centre is generated from Enclave. Which means that Application may send Service Provider fake data  after passing Remote Attestation.
2. Remote Attestation only can verify whether Enclave if  provided by ISV - Independent Software Vender. And can't guarantee output data of Application is from Enclave. 
3. To solve the security issue of Application, can we add private key in Enclave & can't be hacked by others? So we can encrypt all the output data of enclave (ensure output data of Application is from target Enclave). Are there any mechanisms allow to put private key in Enclave for encrypt the output data? Thanks a lot.

[JesusG_Intel]

Hello Domonic,

Please read this article carefully, https://software.intel.com/content/www/us/en/develop/articles/code-sample-intel-software-guard-extensions-remote-attestation-end-to-end-example.html.

The enclave encrypts the messages it sends with the public key provided by the service provider. The service provider then decrypts the received messages using it's own private key. There are many mechanisms in place, mainly consisting of secure key exchanges, to ensure that the messages between the parties originate from the intended source and are not tampered with.

"Remote Attestation utilizes a modified Sigma protocol to facilitate a Diffie-Hellman Key Exchange (DHKE) between the client and the server. The shared key obtained from this exchange can be used by the service provider to encrypt secrets to be provisioned to the client. The client enclave is able to derive the same key and use it to decrypt the secret."

"The Service Provider's public key should be hardcoded into the enclave. This, combined with enclave signing, ensures that the key cannot be changed by end users so that the enclave can only communicate with the intended remote service."

[Domonic]

Hi Jesus,

"The enclave encrypts the messages it sends with the public key provided by the service provider. The service provider then decrypts the received messages using it's own private key. There are many mechanisms in place, mainly consisting of secure key exchanges, to ensure that the messages between the parties originate from the intended source and are not tampered with."

I see. But it uses for Remote Attestation.  How about after RA? Can ensure that output value of Enclave is encrypted? Because I find that can get the the pain-text (return value) from Enclave. Just like mention before self-define simple method in Enclave - get_size().

[JesusG_Intel · Accepted solution]

This thread has been marked as answered and is now closed. Intel will no longer monitor this thread. If you want a response from Intel in a follow-up question, please open a new thread.

Hello Domonic,

Now we are back to my original answer. Outside of remote attestation, it is the responsibility of the ISV to implement their own encryption and data protection mechanisms to protect the data after it gets into the untrusted domain. If you encode the data within the enclave, the untrusted application must know how to decode it. The ISV can implement their own encryption key protocols to make this happen. For example, in remote attestation, the public key of the service is hard coded in the enclave.

[Dr__Greg]

Hi Domonic, I hope the week is going well for you and everyone else who may be following this thread.

I see that Jesus marked this thread as closed but I thought it might be helpful if I could provide some additional illumination that may assist with understanding of the issues involved, as they are essential to developing relevant SGX based application architectures.

in order to address the concerns that you describe, you need to establish a security context between an enclave and whatever application, presumably "In the Cloud", that desires to trust data that the enclave is generating.  The security context has a shared secret that allows the enclave to provide confidentiality and integrity guarantees that protect the data while it passes through an untrusted domain between the enclave and whatever application is relying on the data generated by the enclave, in your example the value of 100.

This is classical security theory and has nothing to do with SGX.  What SGX brings to the table are tools, in the form of remote attestation, that allow the security context to be established.  In addition, SGX provides a guarantee that the security context could not have been compromised by the surrounding platform.

So in order to address the scenario you describe. the remote application that needs to trust data coming out of the enclave, uses remote attestation to authenticate that the data will be coming from a known enclave authored by a known entity.  An appropriate key exchange algorithm is used to generate a shared secret between the application and the enclave, that shared secret is then used to impart confidentiality and integrity guarantees to data that the enclave outputs.

In the model you describe a method must be supplied in order for the enclave to authenticate the remote application that it is corresponding with.  Presumably this would be done via an asymmetric public key that is embedded in the enclave.  The enclave code would use this key to authenticate the remote application that it is corresponding with in order to avoid a Man In The Midde (MITM) attack.

Reduced to its most simple form, the whole purpose of SGX remote attestation is to authenticate the provenance of a 64 byte data field an enclave based application can provide.  If you have access to the Intel SGX/SDK, this 64 byte field is described by the sgx_report_data_t type and can be found as an embedded data element in the sgx_report_body_t structure.  All of this can be found in the sgx_report.h include file.

The 64 byte data field was designed to support the use of Elliptic Curve Diffie-Hellman (ECDH) key exchange.  The enclave and the remote application uses this infrastructure to establish a shared secret that is the foundation for the security context that was previously discussed.

I can go into significantly more detail but this is essentially the concept that the documents that Jesus provided references to discuss.  Unfortunately, the Service Provider (SP) model that Intel developed as the foundation for remote attestation tends to complicate an understanding of all this.

The SP model is predicated on the notion of a "Trusted Third Party" model where the SP, acting as a trusted party to the two communicating entities, uses the sigma protocol that Jesus mentions, to mediate the key exchange process.  Unfortunately in the process it complicates an understanding of what is actually going on.  While elegant and technically correct, the SP model was designed for an SGX ecosystem that never evolved.

The SGX architecture and development that I directed implemented an enclave<->enclave communication's model where the enclaves themselves were capable of conducting remote attestation with Intel Attestation Services (IAS) or in the case of the use of Data Center Attestation Protocol (DCAP) whatever attestation service is available from the trusted ecosystem provider.   This model is more straight forward, and arguably more secure, then the third party SP model.

Our model also provided a compelling reason for SGX to be on the endpoint but that ship has sailed given the decision to focus SGX exclusively on the cloud.

As usual though I digress.

Hopefully this summary helps to facilitate an understanding of the architecture that you, and others, need to develop in order to use SGX effectively.  I would be happy to dive into deeper technical details if there is further interest.

Best wishes for a pleasant weekend to everyone.

Dr. Greg