I have a situation:
I have a scenario that I must connect to a web server and I need to keep the response data safe: I connect to a REST API that will return credit card data. I sign the key in the trusted code and I sent the HTTP request in the untrusted part using the signature via and OCALL. The app receives the HTTP response in the untrusted part and is sent to the trusted part immediately to the enclave via an ECALL. However, from my point of view, I have a security leak in the app: the user credit data should be received in the untrusted part.
From my research, and also because of some posts in here I think there is no way to do an HTTP call from the enclave.
@JesusG_Intel wrote at https://community.intel.com/t5/Intel-Software-Guard-Extensions/Rest-API-or-HTTP-API-call-from-inside...:
"It is not possible to make calls directly to the outside world from inside an enclave. You must create ocalls from the enclave to your application, then the application can make the REST API or HTTP requests on behalf of the enclave."
I am new to sgx technology and I know if this is a real security leak or not. I think intel won't allow this security risk. What I am missing? Can you guide me on how to make a safe HTTP request using sgx tech?
Intel SGX enclaves are implemented in the form of a shared library that is linked to an "untrusted" application. The untrusted application acts as the interface from the enclave to the rest of the world. Due to the security requirements of SGX, SGX enclaves can be linked only with a limited number of "trusted" libraries as described in section "Trusted Libraries" of Intel SGX Developer Reference Guide for Linux, which I suggest you read entirely. Web access libraries are not trusted.
You can write your own custom trusted libraries, section "Library Development for Enclaves," which are subject to the same restrictions as the rest of the enclave.
In your scenario, if you don't want the untrusted application to "see" the secret data, then the application must pass the secret data in encrypted form to the enclave using an ecall. The enclave can then unencrypt the data using a shared key. Refer to the SGX SDK sample, RemoteAttestion, for an example of passing encrypted data to an enclave after doing remote attestation. In RemoteAttestation, the untrusted app calls the function put_secret_data to pass the data to the enclave. The enclave decrypts the data using a previously provisioned shared key from the remote service provider.
From the Remote Attestation End-to-End Sample:
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."
Intel Customer Support
I thank you for the response.
I have read the remote attestation not very deeply.
I will read it now more carefully. However, it seems to me that the server needs to be prepared for providing the service attestation. From
"The first step in Remote Attestation involves the client asking the service provider to provision secrets. This is usually a specific API endpoint that the service provider implements for making such a request. The service provider responds to this request by issuing a challenge requesting the client to attest itself."
In my case, I have no way to modify the server. I just need to ensure that the received is safe. Maybe I have some concepts wrong but it has to be a common situation that the application needs to obtain the data from the outside world and also keep it safe at all times.
again I kind of lost in here. Any help is appretiated.
Remote attestation is used when a service provider needs proof that the client it is communicating with is a trusted SGX platform before the service provider sends the client a secret.
In your case, does the service provider need proof that the SGX client is trusted?
Intel Customer Support
In my case, The service provider doesn't need proof that the SGX client is trusted. then the remote attestation can't be used.
Then as you say, my untrusted app needs to establish a secure channel with the service provider and pass on the encrypted data to the SGX enclave. It is the "passing" process, however, that confuses my head. I can establish a secure connection with the service provider, for example using HTTPS, but the return will be a plain text with the info that I need to keep secure. As the plain data is received in the untrusted part, then is insecure until be sent to the enclave. Then, during that process of receiving until passing the data to the enclave, the data can be considered insecure. Am I right?
Maybe it doesn't make sense that provider's services that don't request proof that SGX client is trusted, need its data to be treated as such.
If you never want the secret data to be in plain text format in unprotected memory at the client, then the service provider must encrypt the secret data before sending it over the secure channel. SGX remote attestation achieves this via a shared key exchange using a Diffie-Hellman Key Exchange (DHKE) algorithm as I pointed out earlier and described in the end-to-end code sample. This is exactly the type of problem that SGX remote attestation was designed to solve.
If you do not use SGX remote attestation, then you must find another way to encrypt the data before it reaches the client and figure out a way to give the enclave the capability of decrypting the data. If you cannot modify the service provider to encrypt the data before sending it then I don't know what to advise.
After the data reaches the client, the untrusted app passes the data to the enclave using an ecall. The untrusted app and enclave do not communicate directly, instead, they marshal data back and forth using automatically generated proxy calls. You can find more information about how SGX marshals data from the untrusted domain and the trusted domain by reading the section Enclave Programming Model, Intel SGX Developer Reference Guide for Windows.
SGX101, which is not an Intel website, also has a very good explanation of the marshaling process.
Intel Customer Support