Intel® Software Guard Extensions (Intel® SGX)
Use hardware-based isolation and memory encryption to provide more code protection in your solutions.

Local Attestation Man in the Middle

AlvaroPastor
Beginner
343 Views

Hi, 

when I was working with Local Attestation, I came up with a problem. 

- Enclave A and B start communication.

- Enclave B sends MRENCLAVE to Enclave A.

- Enclave C (MITM) intercepts this message and gets MRENCLAVE's from B. Enclave C calls EREPORT to create REPORT with his own data and MRENCLAVE from B. I know that this will create MAC from data from enclave C and signed with report key with MRENCLAVE from B. Enclave C sends this REPORT to enclave B.

- Enclave B decrypt it with the report key (and no error occured) but, how Enclave B knows that the data in the report belongs to A (and not to other enclave, in this case, C)? Is this part of the programmer to check something in special, or am I missing something?.

Thanks.

0 Kudos
1 Solution
JesusG_Intel
Moderator
324 Views

Hello Alvaro,


The man in the middle attack you describe is not possible because a third enclave cannot intercept the messages.

 

In local attestation, the two enclaves do not communicate directly with each other. Instead, the enclaves communicate using encrypted channels via the untrusted application as an intermediary.

 

Read the section Local Attestation in the SGX SDK Developer Reference Guide for full details. In summary, section Protected Channel Establishment states:

 

The application initiates a session between the source enclave and the destination enclave by doing an ECALL into the source enclave, passing in the enclave id of the destination enclave. Upon receiving the enclave id of the destination enclave, the source enclave does an OCALL into the core untrusted code which then does an ECALL into the destination enclave to exchange the messages required to establish a session using ECDH Key Exchange* protocol.


Sincerely,

Jesus G.

Intel Customer Support


View solution in original post

4 Replies
JesusG_Intel
Moderator
325 Views

Hello Alvaro,


The man in the middle attack you describe is not possible because a third enclave cannot intercept the messages.

 

In local attestation, the two enclaves do not communicate directly with each other. Instead, the enclaves communicate using encrypted channels via the untrusted application as an intermediary.

 

Read the section Local Attestation in the SGX SDK Developer Reference Guide for full details. In summary, section Protected Channel Establishment states:

 

The application initiates a session between the source enclave and the destination enclave by doing an ECALL into the source enclave, passing in the enclave id of the destination enclave. Upon receiving the enclave id of the destination enclave, the source enclave does an OCALL into the core untrusted code which then does an ECALL into the destination enclave to exchange the messages required to establish a session using ECDH Key Exchange* protocol.


Sincerely,

Jesus G.

Intel Customer Support


AlvaroPastor
Beginner
306 Views

Hi, 

as I seen in: https://community.intel.com/t5/Intel-Software-Guard-Extensions/How-Local-Attestation-Prevent-Man-in-... Dr Greg said "An interposing enclave attempting to mount an MITM attack cannot change the contents of any of the identity characteristics in the SGX_reportbody structure without causing a perturbation in the computed MAC value.  In addition, it cannot generate the symmetric key on which the MAC is predicated.  If it were to attempt to abstract the reportdata element from the SGX_reportbody structure and generate its own report, that report would contain the identity characteristics of the interposing enclave and not those of the attesting enclave."

So actually, before the encryption of messages, another enclave can intercept the message and create his own report? Then, my original message could happen if the text above is correct, no?

JesusG_Intel
Moderator
291 Views

Hello Alvaro,


Enclaves encrypt the messages within their own isolated, protected memory space so another enclave cannot access the messages before they get encrypted. Dr. Greg described why a MITM attack cannot succeed.


Sincerely,

Jesus G.

Intel Customer Support


JesusG_Intel
Moderator
280 Views

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


Reply