Any remote-attestation scheme is theoretically vulnerable to attacks where the CPU manufacturer includes backdoors in the processor hardware (either deliberately, accidentally, or under compulsion from a third party).
Intel's implementation is considerably worse than that. Even if you assume the hardware itself isn't compromised, every remote attestation has to go through the "Intel Attestation Service" which has no end-to-end protection. The IAS is what actually validates the enclave's signature, and it returns a "success" or "failure" message which is signed with an Intel key. But there's absolutely no technical measure that prevents Intel from being compelled to sign a falsified response; a client would have no way of telling the difference.
This is documented by Intel [1] and I'm hardly the first to notice it [2] but people still seem to talk about SGX as if compromising it is equivalent to backdooring the CPU, which is inaccurate.
So you can not start running any code session on the SGX at ALL without this Remote Attestation call to Intel? That seems silly, considering the SGX has two 128 bit keys on board (one known to Intel, and one known only to the SGX).
Oh, it's not quite that bad. You can run SGX code and work with encrypted data, including generating attestation messages. It's just that there's no way to verify those attestation messages yourself; you have to ask Intel to do it.
It's also worth noting that SGX can run in two modes. There's "debug mode", which provides absolutely no security because a debugger has complete access to the state of the enclave. And then there's "release mode", which requires a key that you can only obtain by signing a commercial agreement and NDA with Intel.
Intel's implementation is considerably worse than that. Even if you assume the hardware itself isn't compromised, every remote attestation has to go through the "Intel Attestation Service" which has no end-to-end protection. The IAS is what actually validates the enclave's signature, and it returns a "success" or "failure" message which is signed with an Intel key. But there's absolutely no technical measure that prevents Intel from being compelled to sign a falsified response; a client would have no way of telling the difference.
This is documented by Intel [1] and I'm hardly the first to notice it [2] but people still seem to talk about SGX as if compromising it is equivalent to backdooring the CPU, which is inaccurate.
[1]: https://software.intel.com/en-us/articles/intel-software-gua...
[2]: https://www.blackhat.com/docs/us-17/thursday/us-17-Swami-SGX...