3 ms·

Wow. MM is really going all-in on for Software Guard Extensions (secure enclave) on the server. What does HN say? Do we trust Intel (motivation and implement

Wow. MM is really going all-in on for Software Guard Extensions (secure enclave) on the server. What does HN say? Do we trust Intel (motivation and implementation) that much?

21 9y ago
This is the best way to test SGX, there will be huge incentives to find a vulnerability of any kind (including hardware).
chatmasta 9y ago
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
mtgx 9y ago
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-amd-secure-encrypted-virtualization-sev/ https://developer.amd.com/amd-secure-memory-encryption-sme-a...
kyledrake 9y ago
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.
alexnewman 9y ago
It does rely on sgx being unhackable. Just hard to hack.
teraflop 9y ago
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-guard-extensions-remote-attestation-end-to-end-example#msg3 https://software.intel.com/en-us/articles/intel-software-gua... [2]: https://www.blackhat.com/docs/us-17/thursday/us-17-Swami-SGX-Remote-Attestation-Is-Not-Sufficient-wp.pdf https://www.blackhat.com/docs/us-17/thursday/us-17-Swami-SGX...
- rjromero 9y ago
  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).
  - teraflop 9y ago
    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.
    - 9y ago
betterunix2 9y ago
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.

Wow. MM is really going all-in on for Software Guard Extensions (secure enclave) on the server. What does HN say? Do we trust Intel (motivation and implementation) that much?

21 9y ago

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

chatmasta 9y ago

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

mtgx 9y ago

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-amd-secure-encrypted-virtualization-sev/ https://developer.amd.com/amd-secure-memory-encryption-sme-a...

kyledrake 9y ago

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.

alexnewman 9y ago

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

teraflop 9y ago

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-guard-extensions-remote-attestation-end-to-end-example#msg3 https://software.intel.com/en-us/articles/intel-software-gua... [2]: https://www.blackhat.com/docs/us-17/thursday/us-17-Swami-SGX-Remote-Attestation-Is-Not-Sufficient-wp.pdf https://www.blackhat.com/docs/us-17/thursday/us-17-Swami-SGX...

rjromero 9y ago
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).
- teraflop 9y ago
  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.
  - 9y ago

betterunix2 9y ago

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.