Verify two enclaves running on same system

[Svart_K_]

I have the following scenario, two applications A1 and A2 are creating there own enclaves E1 and E2. A third application A3 is connected via network individually to the two applications. Is it possible for A3 to somehow determine if E1 and E2 are running on the same system?

[Surenthar_S_Intel]

Hi,

Please refer the below link for your reference

https://software.intel.com/en-us/forums/intel-software-guard-extensions-intel-sgx/topic/702143

-Surenthar

[Svart_K_]

Hi,

I don't need a communication between the two enclaves.

I just want to know if it is possible for A3 when communicating with A1 and A2 to determine if they are actually running on the same system. Maybe for the enclave to determine the underlying platform, then both A1 and A2 send that information to A3 and A3 can see if the received values are equal?

Does the enclave provide some sort of function for a system fingerprint (maybe CPU Hash) which can be obtained? So that both enclaves could send there received value and then A3 can just compare them?

[Prabu_R_Intel]

Hi,

The Signing Identity provided by an authority, which signs the enclave prior to distribution. This value is called MRSIGNER and will be the same for all enclaves signed with the same authority. So in the same development firm all enclaves should have same MRSIGNER value, if they are signed with same Signing Identity.

This MRSIGNER values from two different enclaves in a development environment can be used to check whether two enclaves belongs to the same environment.

Please refer  "Intel-SGX-SDK-Users-Guide-for-windows-OS" for MRSIGNER value and it's significance.

Thanks,

R.Prabu

[Rodolfo_S_]

Hi Svart.

I can see one possible way of doing it, but it may not be so straightforward.

1. Perform remote attestation of enclave E1. As a result, A3 and E1 will have a shared key (sk31), and A3 will know E1's MRENCLAVE;
2. Perform remote attestation of enclave E2. As a result, A3 and E1 will have a shared key (sk32), and A3 will know E2's MRENCLAVE;
3. A3 sends a secret along with E2's MRENCLAVE to E1, encrypted using sk31;
4. E1 decrypts the secret and E2's MRENCLAVE;
5. E1 performs local attestation of E2 (this can only be done if they both are on the same platform);
6. E1 and E2 exchange a shared key sk12 (e.g.: via diffie-hellman);
7. E1 sends the secret encrypted with sk12 to E2 via ECALL/OCALL;
8. E2 decrypts the secret;
9. E2 sends the secret to A3, encrypted with sk32;
10. A3 decrypts the secret, and checks if it matches the original secret.

This is the only secure way that I could think of, since no other system information is sent along with the attestation structures.

Best regards,

Rodolfo

[Svart_K_]

Hi Rodolfo,

Unfortunately I cannot perform a Local Attestation between E1 and E2 due to some other restrictions.

But wouldn't it be possible to create hashes of platform components such as CPU, volumes etc. from both enclaves, send them to A3 and then A3 simply compares the received hashes?

Thanks

[Rodolfo_S_]

Hi, Svart.

I believe this would involve system calls, which can't be done inside enclaves. Because of that, you'd need to execute an OCALL to obtain the hash, so the hash would no longer be guaranteed to be generated in the same system as the enclave.

[Svart_K_]

Hi,

but shouldn't the application that created the enclave be in charge of handling the OCALL? How is it possible that the application and the enclave would not reside on the same system?

Thanks

[Rodolfo_S_]

Hi, Svart.

I'm considering here the threat model where an attacker has full control over a system, and thus could modify the application that creates and handles the OCALLS from the enclave. The enclave doesn't know how the OCALL will be handled. The application could forward the request of the hash to another application/system (the same where enclave B is running), and return this hash created elsewhere to the enclave. Because of that, application C would think that both enclaves are running on the same system, but they really are not.

[Svart_K_]

Hi,

okay that makes sense.

Thanks for the great help!