Who has the original hash of enclave in remote attestation?

[Zhicong_H_]

Hi,

I came across the following helpful article on your site:

https://software.intel.com/en-us/articles/intel-software-guard-extensions-remote-attestation-end-to-end-example

It gives a clear demonstration of remote attestation. But I still has a doubt. One of the purposes of remote attestation is to verify that the enclave has not been tampered with. So, some party must own a copy of its original hash. My question is: who has this hash of the enclave in the procedure of remote attestation? Is it the Client SGX machine, the Service Provider, or the Intel Attestation Server?

Thanks,

Zhicong

[Rodolfo_S_]

Hi Zhicong,

After getting a positive response from the IAS, the SP can be sure that the client it has been communicating with is running an SGX enclave. But the SP still needs to know that it is communicating with the right enclave. To do so, the SP must know beforehand the MRENCLAVE from the client enclave, and compare it to the MRENCLAVE contained in the QUOTE structure.

Hope it was helpful.

Cheers,

Rodolfo Silva

[Zhicong_H_]

Hi Rodolfo,

Thanks, it helps! So, the SP must have this MRENCLAVE before the whole system runs. Could you please also confirm the following two ways about how SP can have this MRENCLAVE from the beginning:

1. If the ISV who develops the client enclave is also the one who implements the SP, then it has the MRENCLAVE for sure.
2. As the following page points out,
   
   https://software.intel.com/en-us/articles/intel-software-guard-extensions-remote-attestation-end-to-end-example
   
   considering the complexity of building the SP, the ISV who develops the client enclave could hand over the MRENCLAVE to another ISV who implements the SP and provides Remote Attestation support.

Am I correct about the two ways? Is there any other possibility?

Thanks,

Zhicong

Rodolfo S. wrote:

Hi Zhicong,

After getting a positive response from the IAS, the SP can be sure that the client it has been communicating with is running an SGX enclave. But the SP still needs to know that it is communicating with the right enclave. To do so, the SP must know beforehand the MRENCLAVE from the client enclave, and compare it to the MRENCLAVE contained in the QUOTE structure.

Hope it was helpful.

Cheers,

Rodolfo Silva

[Rodolfo_S_]

Hi Zhicong,

You are correct about those two possible ways. The client enclave developer ISV is not required to be the same as the SP developer. The details on how the client enclave developer ISV hands over the MRENCLAVE to the SP are not very relevant to the remote attestation process. Each SP could have different rules/protocols to register trusted MRENCLAVEs. The key information here is that the SP must know the MRENCLAVE before starting the remote attestation process.

Cheers,

Rodolfo

Zhicong H. wrote:

Hi Rodolfo,

Thanks, it helps! So, the SP must have this MRENCLAVE before the whole system runs. Could you please also confirm the following two ways about how SP can have this MRENCLAVE from the beginning:

1. If the ISV who develops the client enclave is also the one who implements the SP, then it has the MRENCLAVE for sure.
2. As the following page points out, https://software.intel.com/en-us/articles/intel-software-guard-extension...

   considering the complexity of building the SP, the ISV who develops the client enclave could hand over the MRENCLAVE to another ISV who implements the SP and provides Remote Attestation support.

Am I correct about the two ways? Is there any other possibility?

Thanks,

Zhicong

[David_Z_3]

Hi,

I got the same question and thanks for the response. I still missing something, how the SP can get the MRENCLAVE value for the ISV?

Do the ISV developer need to call sgx_create_report() function and then extract the mr_enclave value from it and then insert it to SP?

Or may be the mr_enclave is also generated from during the signature process?

Another question If a malware enclave get somehow this mr_enclave value he will be able to spoof his identity with valid enclave, how do you prevent that ?

thanks

David

[Rodolfo_S_]

Hi, David.

As stated above, the MRENCLAVE is part of the QUOTE structure. The QUOTE is generated and signed by a special enclave called Quoting Enclave (QE) using its EPID key. The QUOTE is then sent for verification by IAS, thus it could not be spoofed. The details of the full process are described in the white paper available at https://software.intel.com/en-us/articles/innovative-technology-for-cpu-based-attestation-and-sealing.

Best regards,

Rodolfo

[David_Z_3]

Hi,

Thanks for your quick response.

My concern is not about having a spoofed QUOTE, but a spoofed REPORT. I understand that the QUOTE is signed. But the security of the REPORT from a local attack (or interceptor) is not clear. The MRENCLAVE is different for each enclave, but is it possible for a "bad" enclave to use the MRENCLAVE of a "good" one, and then create some sort of man-in-the-middle attack between the "good" enclave and the QE, since as it appears in "3.1 Intra-Platform Enclave Attestation", the QE (or Enclave B in this case) is checking that the REPORT comes from an enclave running on the same platform, which is the case in this attack. After that, the "bad" enclave could spoof a request for a QUOTE (and getting provisioned instead of the "good" one)? I'm sure something is preventing this, but I'm not sure what. 

A guess would be that it lies in the next part of the local attestation
: "Enclave B can then examine Enclave A’s REPORT to verify the software components of the TCB:
o MRENCLAVE reflects the contents of the software image running inside the enclave.
o MRSIGNER reflects the sealer’s identity"

But how is it securely verified?

Thanks

David

[Rodolfo_S_]

Hi, David.

The Quoting Enclave is the one responsible to verify the REPORT before generating a QUOTE. It does so by performing the local attestation process. The REPORT structure is generated by the EREPORT instruction. This instruction generates a signed REPORT of the enclave being attested along with a MAC of the REPORT using the QE's key. The QE can then verify if this is a valid REPORT (i.e.: if the report was really generated by the SGX capable processor). 

The  QE doesn't need to verify if the MRENCLAVE matches the one expected, since this should be done by the SP who is interested in communicating with the enclave being attested. So it only creates a QUOTE structure, which includes the REPORT, and sign it with the EPID key. The only possible way to spoof the REPORT would be if the QE ran malicious functions. In that manner, one must trust Intel to provide a non-malicious QE to be used in this process.

Best regards,

Rodolfo