Hacker News Reader

Comment by anonymousDan | Hacker News Reader

Pretty incoherent article. Not sure what point they are trying to make about the threat model of SGX. SGX was/is a groundbreaking attempt to solve a very difficult problem IMO. TEEs are still an active area of research that has benefited massively from the availability of an actual implementation in mainstream processors. And most other CPU manufacturers are also offering their own flavour of TEE, many of which have learned lessons from SGX.

View on HN

The point about the threat model of SGX is that insulating an enclave with it does nothing to protect the code actually handling the data from the enclave. It really does not even protect against firmware side attacks. For that, TPM attestation is just as good.

At some point, somewhere, data processed by the SGX enclave has to pass through the usual VTd or such. Unless SGX enclave is used to feed data directly into hardware, in which case the weak point is the firmware and bus instead.

If it ensured no side channel attacks, it would be useful for some operations. But it does not therefore it isn't.

SGX is very useful. Source: I built a product that made it easier to use and we explored a lot of use cases as part of that.

Firstly yes SGX is designed to block firmware attacks. That's a part of the threat model indeed.

Secondly, you can't feed data from SGX enclaves directly to hardware devices. It's encrypted data in, encrypted data out. Of course, data must pass through the untrusted host OS and hypervisor, but that is no problem, it's how it's designed to work. That's why the clients of the enclave handshake with it using remote attestation.

You can block side channel attacks with SGX if you are careful. The enclave transitions do clear uarch state in the ways needed, the rest is app-level stuff (but it has to be).

I used to see a lot of confusion about stuff like SGX because some people don't realize it's only intended to be used with remote attestation. If you don't have a smart client that's remotely attesting the enclave over a network, it isn't going to get you anything. That requires changes to app architectures.

It was touted as making cloud computing secure. How anyone could actually believe this is beyond me. The cloud provider has physical access to the host machine. For all I know it could all be smokes and mirrors, emulated on a C64, while all my data is getting exfiltrated. The only people who ever bought into this is cryptobro crackheads and government contractors doing it for compliance bullshit. Up to 0% of cloud customers went as far as to even try to verify the thing does what it says it does.

Case in point: TeleMessage. Supposedly E2E-Encrypted message archival turns out to be a plain text database on some servers. Surprised Pikachu face.

This is some tinfoilhat stuff. An extreme suggestion that a cloud provider would physically open up machines and exfiltrate the keys so that they could then read the memory of a customer workload, for what reason? Remember that hardware is virtualised and makes it difficult to pin point which server is running what. Not using such tech makes it easier for the cloud provider to inspect memory so that is not a better approach.

If you argue that you can trust the cloud provider not to be malicious, you also just argued that you don't need SGX at all. No tinfoil hat required.

And yes, not using that tech is not a better approach then, but not worse either. But better in the way that Intel doesn't need to build convoluted shit into their cpus that might actually worsen security through exploits.

Reply on news.ycombinator.com