[Cryptography] Intel SGX: Augean stables piled higher & deeper?

[Steve Weis]

On Mon, May 18, 2015 at 6:11 AM, Ryan Carboni <ryacko at gmail.com> wrote:

> There actually is a very simple solution to that.
> Insist on WSIWYG.
> It shouldn't be so trivial to inject malware into winlogin or create root
> kits.
> Actually I don't even understand rootkits, file systems shouldn't be able
> to reference sectors that it doesn't make the user aware of.
>

I think SGX is one of the most significant new security architecture
features from Intel. I'm looking forward to experimenting with it as a
defensive tool.

For those who aren't familiar with SGX, see the links below. Some pros and
cons that I see:
+ You can run code in a "secure enclave" that is not accessible from either
ring-0 code or SMM.
+ Secure enclaves are backed by physically encrypted memory, and thus not
exposed to cold boot attacks or non-volatile RAM.
+ Enclaves should be remotely attestable with CPU-bound public keys using
anonymized or pseudonymized signatures.
- Enclaves are limited in size; I think 128MB initially.
- Enclaves are user-land code only.

I expect adoption will be slow since there needs to be support in build
tools, the kernel, and around enclave management. There are also limited
applications since it's user mode only, but performing cryptographic
operations is a nice use case.

That is one of the reasons there are concerns about SGX enclaves being used
for DRM (see [2]). I think the flip side is the potential as a
privacy-preserving technology. You could run your own code on leased
hardware without the service provider being able to see what it is doing.

[1]
https://www.nccgroup.trust/en/blog/2015/01/intel-software-guard-extensions-sgx-a-researchers-primer/
[2]
http://theinvisiblethings.blogspot.com/2013/08/thoughts-on-intels-upcoming-software.html
[3]
http://theinvisiblethings.blogspot.com/2013/09/thoughts-on-intels-upcoming-software.html
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.metzdowd.com/pipermail/cryptography/attachments/20150518/1d981a1b/attachment.html>