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.

[1]: https://software.intel.com/en-us/articles/intel-software-gua...

[2]: https://www.blackhat.com/docs/us-17/thursday/us-17-Swami-SGX...

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.

Why the hell would Intel require an NDA to give you the private key?

That's shady af.

It's not actually an NDA (I've signed it). You have to agree to not use SGX to make un-debuggable malware.

At the end of the day, trust is still required. For example, if you use Bitcoin, you're trusting the people that wrote the code and the libraries it linked to and the people that ran the server you downloaded it from, and you're trusting that Koblitz didn't put a backdoor into the ECC somehow. I could go on for a while here but I think this describes the basic idea. You can change the level of trust required or who you're trusting but not the mere requirement of it.

I've met some of the people working on this at Intel and I do have confidence that this isn't some conspiracy, I do think they have the intention of improving the crypto space with projects like this.

This is the best way to test SGX, there will be huge incentives to find a vulnerability of any kind (including hardware).

No, but probably worth a shot. I think AMD's Secure Encrypted Virtualization (SEV) sounded better, though. But it's a shame AMD only offers it on the EPYC server chips. they ought to make it a mainstream feature in Zen 2 chips if they want it to gain popularity and use. That said, that's probably not an obstacle for a company that plans on using server chips anyway.

https://developer.amd.com/amd-secure-memory-encryption-sme-a...

In multiple verticals of the industry, there exists a clear trend of utilizing hardware security modules for cryptographic operations. Almost all mobile phones have them, cloud providers offer HSM services, and Trezor wallets generate bitcoin private keys. It makes sense to build a service that relies heavily on HSM.

Adapt or die

I am pessimistic about SGX. It's basically a DRM system that was dressed up to look like something else. Even if one trusts Intel, the entire security model hinges on Intel's ability to detect a compromised key and revoke it; that makes plenty of sense for DRM, where compromised keys are typically announced on forums etc., but why would a service operator or government agency tell anyone?

Moxie has good ideas, but SGX is a trap and he fell into it.

It does rely on sgx being unhackable. Just hard to hack.