Intel® Software Guard Extensions (Intel® SGX)
Discussion board focused on hardware-based isolation and memory encryption to provide extended code protection in solutions.

Doubt about authentication enclaves and encryption

Mateus_T_
Beginner
1,027 Views

Hello guys,
I did some reading materials on the Intel SGX, but I have some more basic questions about the issue of authentication to perform an enclave on a server for example.

Assuming the following:
I have a machine with the SGX, and have the need to run a program that requires a lot of processing and, because of this, I need a cloud service to process this data.

So to run my program using enclaves in an online service provider, I need to run an enclave on my machine and another in the provider in order to establish a kind of connection between the two enclaves? To this regard the Remote Attestation? To connect to the server you want to run my program in order enclave and start the creation / execution of this enclave, all this is implemented by the commands contained in the SDK?

After the enclave be initialized on the server, you can no longer send customer enclave of data to it in order to process this data?

Finally, as the question of encryption, there functions in the SDK that enable the already encrypted sending the code and data to be entered into the service provider's enclave? As these data would be decrypted there in the cloud service provider? From what I read in some articles, data and code remain encrypted at all times, just being undone encryption by the CPU, and once processed, since these data would be encrypted again, however, as the CPU would also to decrypt?

Anyway, I'm a little confused by these issues run, if anyone knows better explain and want to share I am very grateful.

Thank you,
Mateus

 

0 Kudos
7 Replies
PadmaPriya_M_Intel
1,027 Views

Hi,

If the Intel SGX application (with enclave) running in client platform wants to communicate with remote system/server, then it needs remote attestation service. It is no mandatory that remote server should run in Intel SGX enabled platform.

In Intel SGX, Remote attestation process helps to exchange the secret information between the client and server. This secret information contains the secret key. After completion of remote attestation, both client and server exchange information by encrypting the data/code using the secret key.

The encrypted information sent by the  server is received by the client application. Then client application send this information to the enclave. Since the enclave already have the exchanged secret key, it is decrypted and processed by the CPU.

Please refer to this link to know more about Remote Attestation service : https://software.intel.com/en-us/articles/intel-software-guard-extensions-remote-attestation-end-to-end-example#prerequisites.

-Thanks

0 Kudos
Mateus_T_
Beginner
1,027 Views

Hi Padma,
Thanks for your help!
I understood the question of Remote Attestation, but before establishing remote communication, is to ensure that the remote server also run on a platform with the SGX? Does it have something to do with this authentication IAS?

Another issue that was in doubt is that you commented that having the secret key data is decrypted and executed on the CPU. However I read that for data to be processed on the CPU they arrive encrypted to, and being decrypted in the context of the CPU for processing there, and as soon as processed, would already be encrypted again. The data is only decrypted on the CPU? And if so, how he has the secret key for this?

Thanks!

0 Kudos
PadmaPriya_M_Intel
1,027 Views

Hi,

1.  Is to ensure that the remote server also run on a platform with the SGX?

It is not mandatory that remote server should run in Intel SGX enabled platform.

2. Does it have something to do with this authentication IAS?

The Service Provider sends the client enclave report information to the IAS to verify that the client enclave is trustworthy.

Basically, Remote Attestation completes six steps,

    1. Enclave built & measured.

    2. Enclave requests REPORT(HW- signed blob that includes enclave identity information).

    3. REPORT sent to server & verified.

    4. Application(secret) Key sent to enclave, first secret provisioned.

    5. Enclave-Platform-specific Sealing Key generated( EGETKEY).

    6. Application Key encrypted via Sealing Key & stored for later (offline)use.

- Thanks

0 Kudos
Mateus_T_
Beginner
1,027 Views

Thanks Padma,
My question is more the question of how is the beginning of the communication between two enclaves and how is the validation of information from one another (in the way as is done for each one to have the key used by the other in order to verify the validity of the message for example)

From what I've read so far, to take place this certificate between two enclaves A and B, the enclave A sends to B its MRENCLAVE. How is this sending? For what I understood is that if used the EREPORT instruction, which sends a REPORT with some data (including the MRENCLAVE) and a MAC tag generated from the data using a REPORT with a Report Key.

After the enclave B receive MRENCLAVE from enclave A, he then through EREPORT generate a REPORT using MRENCLAVE as enclave A correct? This REPORT contains the MAC generated with the Report Key B right?

The enclave B then sends it to the enclave At your REPORT. The enclave A when receiving REPORT, will need the Report Key that B used to generate your MAC to check it right? How do the enclaves for the Report Key used and can confirm the message MAC?

 

Thanks!

0 Kudos
Rodolfo_S_
New Contributor III
1,027 Views

Hi, Mateus,

First of all, I believe you are confusing the Remote attestation process with the Local attestation process.

The process that you described below is the process of local attestation. This means that both enclaves would be running on the same machine.

To understand the process of remote attestation please check the link sent by Padma above.

Regarding on how the structures (Msg1, Msg2, Msg3, Msg4) are sent, it is completely up to the service provider to determine how it should be done (e.g.: the SP could run a REST service and the client application would send the messages via HTTPS requests). This exchange of information is NOT done by using the SGX SDK. Keep in mind that your application should be divided into two parts: the enclave, and the untrusted code. The communication part of the application should then reside in the untrusted code.

Cheers,

Rodolfo Marinho

Mateus T. wrote:

Thanks Padma,
My question is more the question of how is the beginning of the communication between two enclaves and how is the validation of information from one another (in the way as is done for each one to have the key used by the other in order to verify the validity of the message for example)

From what I've read so far, to take place this certificate between two enclaves A and B, the enclave A sends to B its MRENCLAVE. How is this sending? For what I understood is that if used the EREPORT instruction, which sends a REPORT with some data (including the MRENCLAVE) and a MAC tag generated from the data using a REPORT with a Report Key.

After the enclave B receive MRENCLAVE from enclave A, he then through EREPORT generate a REPORT using MRENCLAVE as enclave A correct? This REPORT contains the MAC generated with the Report Key B right?

The enclave B then sends it to the enclave At your REPORT. The enclave A when receiving REPORT, will need the Report Key that B used to generate your MAC to check it right? How do the enclaves for the Report Key used and can confirm the message MAC?

 

Thanks!

0 Kudos
Mateus_T_
Beginner
1,027 Views

Hi, Rodolfo.

Thanks for the support. 

This untrusted code you mention is that in some articles deal with the application host that "manages" the enclave? The application would, in the way that is defined by it and the remote server, the connection is established between the two sides?

Thanks!

0 Kudos
Rodolfo_S_
New Contributor III
1,027 Views

Hi, Mateus.

The untrusted code I mention is indeed the application that launches the enclave. It is called untrusted because it doesn't run inside an SGX enclave. The connection should be established between the untrusted part of the application and the service provider. This connection should be used to exchange the messages involved  in the remote attestation process, and then messages can be safely sent from the SP to the enclave by encrypting the messages with the secret symmetric key that has been derived during the remote attestation process, since this key will only be known by the SP and by the enclave.

Cheers,

Rodolfo

Mateus T. wrote:

Hi, Rodolfo.

Thanks for the support. 

This untrusted code you mention is that in some articles deal with the application host that "manages" the enclave? The application would, in the way that is defined by it and the remote server, the connection is established between the two sides?

Thanks!

0 Kudos
Reply