Mutual Attestation

[simplelins]

Hi,
if we need to do a attestation between two enclaves from different platform that they all untrust each other, what's different from remote attestation.beacause our platform consists of multiple enclave services and most of the enclave-to-enclave RPC communications need bidirectional authentication.
thanks !

[GuilhemN]

Hi,

I believe you should first move all the crypto verifications to the enclave (that is the IAS response signature check here, and the message processing in the SP).
I've done it for DCAP in a personal project: https://github.com/labri-progress/SGX-DCAP-Quote-Generation-Dockerfile/tree/ddaafe0904efbec4244491a1908307e4f45846da/RemoteAttestation/sgx-ra-sample.
You may get some inspiration from the ServerEnclave directory. (I no longer communicate with the IAS server though so I did not transform iasrequest.cpp).

Once this is done, you'll have to adapt a little bit the protocol provided by the SDK. I believe sending a quote from the second enclave containing a hash of G_a || G_b || VK should do the job. What do you think?

Edit: to add some security, you may also sign your quote with the SPK key.

[simplelins]

actually, you donot check the value from peer enclave's mr_enclave, so which you are making a attestation maybe not that you want to connect. the question is how to distinguish the peer enclave's identity. and what you do same as a remote attestation. thanks !

[GuilhemN]

An easier solution could be to:

• attest both enclaves (attest A from B, and attest B from A) using the sdk's protocol (you only need to move sp's verifications to the enclaves). This will provide you two secure channels:
  chan1 from A to B (with B attested), chan2 from B to A (with A attested)
• then send B's public key through the channel chan1
  and send A's public key through the chan2.

This way you should be ensured all entities are correct (A=A' and B=B') and both are attested.

[simplelins]

@GuilhemN
I also try to use this way, but we can not verify the value of mr_enclave from peer,this will be conflict and can not distinguish the peer enclave's identity.

[GuilhemN]

Isn't it sufficient to check mrsigner, prodid and isvsvn?

[simplelins]

Isn't it sufficient to check mrsigner, prodid and isvsvn?
@GuilhemN According to my understanding,only the value of mr_enclave can represent the unique enclave,and which enclave we are communicating with.

[GuilhemN]

Well it depends to what extent you trust your signature, if the private key you're signing with is well protected there is no way an attacker could create a fake enclave reproducing your mrsigner.

Besides you can specify which enclave you are communicating with using the prodId (it is also protected by your signature and thus cannot be modified).

[simplelins]

yeah，if we can not guarantee that the private key is protected safely,so we need to check mrenclave value. in this way , we can not check the value of the peer's mrenclave, because mrenclave value need to be coded in enclave at building time for mutual attestation.

thank for you reply