33 ms·

SGX always involved trusting Intel. It was Intel basically telling a third party "yup, this machine is running the binary code you expect it to be running". Wh

SGX always involved trusting Intel. It was Intel basically telling a third party "yup, this machine is running the binary code you expect it to be running". Which is exactly why it's nefarious, of course - a third-party has no business forcing me to run their proprietary binaries on my own machine in order to access their service. If they want that kind of trust, they're still free to establish that by sending me a physical dedicated-use device that can authenticate itself to whatever service they care about.

dTal 8y ago
Hm, while I completely agree about not wanting proprietary garbage on my machine, I'm not sure about this logic. A third party can stipulate anything it likes, in order to use their service - you're always free not to use that service. Arguably, the ability to certify that you, the user, are indeed running the code you say you are is a feature provided to you, rather than a restriction imposed upon you. Not a feature I have interest in using, but nevertheless it's possible to frame it that way around. The fact that such code tends to be proprietary is (again, very arguably) besides the point.
- 0815test 8y ago
  > you're always free not to use that service Unless that service has monopoly power. SGX makes it far too easy for an entity to abuse monopoly power, by directly turning it into power over what their customers have to run. This is why this sort of thing should only ever be done via physical devices - "monopoly" over a single, dedicated device is far more obvious and less insidious.
rficcaglia 8y ago
SGX only guarantees the isolated memory region remains isolated. It doesn’t guarantee the code running in it is secure or even leak-free. Microsoft Research has studies this and release a compiler for making stronger claims about code running inside the enclave but I think this is still very much an open problem. You will always want layers of security and even then security is an illusion .... there will always be a way, just with different costs to exploit and thus risk/reward frontier.

dTal 8y ago

Hm, while I completely agree about not wanting proprietary garbage on my machine, I'm not sure about this logic. A third party can stipulate anything it likes, in order to use their service - you're always free not to use that service. Arguably, the ability to certify that you, the user, are indeed running the code you say you are is a feature provided to you, rather than a restriction imposed upon you. Not a feature I have interest in using, but nevertheless it's possible to frame it that way around. The fact that such code tends to be proprietary is (again, very arguably) besides the point.

0815test 8y ago
> you're always free not to use that service Unless that service has monopoly power. SGX makes it far too easy for an entity to abuse monopoly power, by directly turning it into power over what their customers have to run. This is why this sort of thing should only ever be done via physical devices - "monopoly" over a single, dedicated device is far more obvious and less insidious.

rficcaglia 8y ago

SGX only guarantees the isolated memory region remains isolated. It doesn’t guarantee the code running in it is secure or even leak-free. Microsoft Research has studies this and release a compiler for making stronger claims about code running inside the enclave but I think this is still very much an open problem. You will always want layers of security and even then security is an illusion .... there will always be a way, just with different costs to exploit and thus risk/reward frontier.