Intel SGX MRENCLAVE

[ssziy]

Good afternoon,

I have questions about using mrenclave for a purpose I have in mind.  Let's say we have a peer to peer network with a service provider and IAS.  With this I want to ensure that all members of the network run exactly the same same enclave (same source code).  First, all network members must perform remote attestation towards the service provider.  Then my idea was for a network member to send the IAS signed attestation report, which he obtained in the remote attestation process, to another network member as a way of proving that he runs the code that the report recipient trusts.  The attestation report receiver would verify the IAS signature and then compare his mrenclave with that of the report and if the values ​​were equal then the receiver would be sure that the report issuer runs exactly the same enclave (source code) as itself.

So with all this, can mrenclave be used this way or to prove to a network member that I run the same trusted code I have to do another process ?

Thank you and I look forward to a reply.

[Dokmai__Natnatee]

Hello Stevie, From what I understand, mrenclave should be the same if the enclave code (including the underlying SDK) is the same. However, if I understand your idea correctly, the larger problem with the idea is the key exchange step: how would you establish an attested secure channel between all the peers in the network? This has been a problem because Intel's reference RA isn't designed to attest to multiple parties: Diffie-Hellman key exchange in RA is only two-way authenticated. According the Code Sample (https://software.intel.com/en-us/articles/code-sample-intel-software-guard-extensions-remote-attestation-end-to-end-example), Enclave authenticates key exchange by signing the SHA-256 digest of (Ga || Gb || VK) in the report data using EID; this is to be verified by SP through IAS. In the other direction, SP authenticates key exchange by signing SigSP(Gb || Ga) in Msg2; this is to be verified by Enclave using the hard-coded SP's verification key. If the verification key isn't hard-coded in some way, then key exchange will be susceptible to MITM attacks. (For example, a malicious OS may switch SP's key with its own key.) In your idea, if each network member hard-codes a verification key into the enclave, then you would end up with many different versions of the same enclave and therefore different mrenclave values. Now, you may work around this problem by hard-coding all the verification keys into one enclave code which runs multiple instances of the key exchange protocol (one per network member-pair), but there are two major problems with this approach. First, this implies that the network members and they verification keys must be determined in advance. Second, an active man-in-the-middle may try to mix-and-match different instances of key exchange to compromise the overall protocol. A theoretical solution to this problem has been suggested in this (very dense) paper: https://eprint.iacr.org/2016/1057.pdf If you are not planning to establish secure channels, then you can't input any secret information into the enclave. Moreover, you still need to solve the authentication problem to prevent a replay attack: how do you prevent a malicious party from taking an attestation report from a legitimate party and pretending its her own? Let me know if you have any further questions!

[Junli_S_Intel]

Now sure whether I have caught your point:

1. Are you want to make sure: every member has the same environment: the same enclave?

2. Or you want to make sure: every member should have one trusted execution environment?

And in your post, when you say: send the IAS signed attestation report, could you please explain what are your mean: the IAS signed attestation report?

[Junli_S_Intel]

By the way, please consider the local attestation process: whether it could meet your requirement.

[ssziy]

Good Morning,

Answering your questions:

1. Are you want to make sure: every member has the same environment: the same enclave?

2. Or you want to make sure: every member should have one trusted execution environment?

I want to guarantee both. I want to make sure all members run the enclave (source code) that I, the developer, produced. And I want to make sure that all members run that enclave on an machine with a processor with SGX enabled, genuine, trustworthy, non-revoked platform.

By the way, please consider the local attestation process: whether it could meet your requirement.

How can I use local attestation on a peer-to-peer network?  Each enclave is on a different machine in a network, the only solution i can see here is inter-platform attestation (in my case I'm thinking using Intel Attestation Service (IAS).

And in your post, when you say: send the IAS signed attestation report, could you please explain what are your mean: the IAS signed attestation report?

I mean the return of the request to IAS endpoint /attestation/v3/report

[Junli_S_Intel]

For this point: every member should have one trusted execution environment

you use IAS to ensure it.

For another point: every member has the same environment: the same enclave

MRENCLAVE indeed can be used to achieve the target. 

[ssziy]

JUNLI S. (Intel) wrote:

For this point: every member should have one trusted execution environment

you use IAS to ensure it.

For another point: every member has the same environment: the same enclave

MRENCLAVE indeed can be used to achieve the target. 

So using these guarantees, in a peer-to-peer network of enclaves how can I attest one enclave to another using the IAs?

[Rodolfo_S_ · Accepted solution]

Hi Stevie,

I believe that what you want to do can be done using the following considerations:

* When peers communicate with each other, they should mutually perform the remote attestation process (IAS comes in this step). There are several resources provided by Intel indicating how to perform the Remote Attestation process, including this example. Receiving confirmation from IAS indicates that the QUOTE structure received was indeed produced inside a genuine Intel SGX enclave, now the peers still need to verify if the identity of the peer enclave is the same as theirs.
* To verify if the identity of the peer enclave is the same, an enclave can obtain its own identity following the process described here, and check if it matched the identity contained in the QUOTE structure.

Regards,
Rodolfo

[ssziy]

JUNLI S. (Intel) wrote:

For this point: every member should have one trusted execution environment

you use IAS to ensure it.

For another point: every member has the same environment: the same enclave

MRENCLAVE indeed can be used to achieve the target. 

Thanks for the answer, it's completely clear

[ssziy]

Rodolfo S. wrote:

Hi Stevie,

I believe that what you want to do can be done using the following considerations:

* When peers communicate with each other, they should mutually perform the remote attestation process (IAS comes in this step). There are several resources provided by Intel indicating how to perform the Remote Attestation process, including this example. Receiving confirmation from IAS indicates that the QUOTE structure received was indeed produced inside a genuine Intel SGX enclave, now the peers still need to verify if the identity of the peer enclave is the same as theirs.
* To verify if the identity of the peer enclave is the same, an enclave can obtain its own identity following the process described here, and check if it matched the identity contained in the QUOTE structure.

Regards,
Rodolfo

This is really the peer-to-peer way of solving the problem. But there is still room for two final questions:

- When obtaining IAS API keys a SPID is provided. Do all peers use the same SPID to communicate with IAS?

- Having done mutual attestation and identity verification between two peers in the network, if perhaps one of them wants to send some type of information, what information do I associate this information with? Given the anonymous EPID group signature scheme, I cannot identify which peer communicates with which.

A big thank you in advance for all the answers I've already received.

[JesusG_Intel]

Hi Stevie,

Platforms cannot share the SPID, they each must have their own unique SPID. The T&Cs when you sign up with IAS explicitly say the SPID and keys cannot be shared.

To identify peers within your network you can have each peer pass a randomized, unique GUID that is associated with the remote party. You can pass this GUID as a shared secret. Does this help?

Regards,

Jesus