6 ms·

I am by no means an SGX expert, but my understanding has been that it allows you to shorten the "trust stack." What you're referring to as "the server" is real

I am by no means an SGX expert, but my understanding has been that it allows you to shorten the "trust stack." What you're referring to as "the server" is really a technology stack that starts with the CPU hardware and extends to the service operator. Without SGX, the trust stack probably looks something like: Intel, the OS, the VM, the cloud provider (Amazon, Google, Microsoft), the server software, the server operator. Any of those points on the trust stack can be compromised by their principals or by an attacker (for example, Amazon could choose to interfere with Signal, or someone could hack Amazon and do the same). This is true for the OS, the software, the service provider, and everything else in the stack. Users have to trust all of those points, and additionally trust them not to be compromised. SGX shortens the trust stack all the way down to the CPU. It takes the OS, the VM, the cloud provider, the service operator, and everything else out of the equation. Clients no longer have to trust any of them, either to be honest or to avoid compromise. If trusting the CPU isn't acceptable to you, then that might be a bigger problem than you realize, since all computing has to. If you'd rather put your trust in AES, the problem is that you still have to trust the CPU to perform AES the way you would like it to.

Confiks 9y ago
I understand that you will have to trust the CPU to do any computation. In a sense, it indeed shortens the 'trust stack', and as said in another comment "now, you need only trust that Intel hasn't backdoored their hardware". Maybe the main point should have been that that this scheme "encourages a centralization of trust into a private key managed by processor manufacturers". You might say that by integrating SGX mechanisms into your security model, you create a set of 'feudal lords' [1] which can wield their power over you. A manufacturer may legitimately establish an enclave in you most trusted hardware which you may not audit or even measure. And if that security model becomes commonplace, for example when only allowing Widevine DRM inside SGX, you eventually cannot use your self-chosen hardware, but will have to pick a feudal lord. [1] https://www.schneier.com/blog/archives/2013/06/more_on_feudal.html https://www.schneier.com/blog/archives/2013/06/more_on_feuda...
im3w1l 9y ago
There is a difference between trusting a local and a remote CPU. Selling compromised CPU's to end users is much riskier than colluding with a megacorp to create "altered" CPU's for their servers.

Confiks 9y ago

I understand that you will have to trust the CPU to do any computation. In a sense, it indeed shortens the 'trust stack', and as said in another comment "now, you need only trust that Intel hasn't backdoored their hardware". Maybe the main point should have been that that this scheme "encourages a centralization of trust into a private key managed by processor manufacturers". You might say that by integrating SGX mechanisms into your security model, you create a set of 'feudal lords' [1] which can wield their power over you. A manufacturer may legitimately establish an enclave in you most trusted hardware which you may not audit or even measure. And if that security model becomes commonplace, for example when only allowing Widevine DRM inside SGX, you eventually cannot use your self-chosen hardware, but will have to pick a feudal lord. [1] https://www.schneier.com/blog/archives/2013/06/more_on_feudal.html https://www.schneier.com/blog/archives/2013/06/more_on_feuda...

im3w1l 9y ago

There is a difference between trusting a local and a remote CPU. Selling compromised CPU's to end users is much riskier than colluding with a megacorp to create "altered" CPU's for their servers.