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?
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.
I can see one possible way of doing it, but it may not be so straightforward.
This is the only secure way that I could think of, since no other system information is sent along with the attestation structures.
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?
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.
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?
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.