
Thoughts on Intel's upcoming Software Guard Extensions (Part 1) - andyjohnson0
http://theinvisiblethings.blogspot.co.uk/2013/08/thoughts-on-intels-upcoming-software.html
======
xradionut
The summary paragraph sums up the only thing I was thinking of while reading
this:

"Finally, we should discuss the important issue of whether this whole SGX,
while providing many great benefits for system architects, should really be
blindly trusted? What are the chances of Intel building in backdoors there and
exposing those to the NSA? Is there any difference in trusting Intel
processors today vs. trusting the SGX as a basis of security model of all
software in the future?"

There is no full trust of any modern hardware or commercial software or even
complex OSS software anymore. None. I made poked fun at some of my paranoid
technical buddies in the '90s, but so far have apologized recently. Their
customized systems don't seem so silly anymore.

~~~
tptacek
Put yourself 20 years into the future, looking back onto 2013, and try to ask
yourself whether the x86_64 architecture we have today, with the x86 MMU as
understood by Linux 3.11, and the Intel chipset & DMA controllers we use
today, whether that bundle of hardware is likely to seem like a reasonable
platform on which to build trustworthy applications.

Today, in 2013, a trivial software bug is all it takes to allow the author of
a web page to upload and run code in your browser process. That is a
consequence of the architecture we run on.

Are we at any point in the near future going to have fully transparent
hardware? No we are not.

Do we badly need architectural improvements for hosting trustworthy code on
general purpose hardware? Yes we certainly do.

We're going to have to get over the NSA stuff, at least for the most part.
Perhaps there are applications that will need some kind of assurance that they
aren't generating secrets from RDRAND (I'm not a believer in that problem, but
I'm not committed to the argument). But for the most part, we're going to have
to trust hardware vendors to design better security architectures and deploy
them in new chipsets and processors, because they are badly needed.

If it helps you, think of your resistance to things like SGX as the product of
an NSA psy-ops campaign to get you to distrust technologies that will cut off
NSA's supply of new software bugs.

~~~
cmccabe
Every modern browser uses sandboxing to avoid having a "trivial software bug
allow the author of a web page to upload and run code in your browser
process." You simply run the potentially insecure code in a separate,
unprivileged process. Apple has a special set of sandbox APIs that make it
easy for applications to irrevocably give up privileges such as the ability to
write to the file system, etc. It's not as easy on Linux and Windows, but it
is possible.

SGX really exists for one reason, and one reason only-- it's another attempt
to implement some kind of un-bypassable DRM. Joanna points this out in her
writeup. All of the other so-called advantages you can already get simply by
running a VM.

Get ready to jailbreak your PC I guess. I can just feel the security oozing
from my pores.

~~~
tptacek
Has a year gone by since they were introduced where some kind of sandbox
jailbreak hasn't been published? And: it cost Google many hundreds of
thousands of dollars to engineer the sandbox system it has, just as it cost
Adobe huge amounts of money to retrofit sandboxes onto PDF.

How well sandboxed is nginx? Answer: not at all.

Also, you understand that any VM system that grants the security capability
you're talking about also grants content software the ability to protect
content, right? They're two sides of the exact same coin. You don't see that
they are, because the "security" sign of the coin implicitly but subtly
presupposes hostile code is running on the machine already, where the "DRM"
side of the coin obviously hosts adversarial code, because that adversarial
code is the "protagonist" of its story.

~~~
cmccabe
A lot of the Chrome jailbreaks were done through attacking the embedded Flash
player, which wasn't sandboxed at the time.

 _How well sandboxed is nginx? Answer: not at all._ Actually, that's not the
answer. ngnix is sandboxed by using selinux, using a chroot jail, using
AppArmor, or any one of a number of different ways.

How many years have gone by without a Java or web-based exploit being
announced? 0. Maybe you should not throw stones, when your own house is made
of glass.

Security and DRM are _not_ two sides of the same coin. There are lots of
insecure systems that aren't DRMed. And there are lots of ultra-secure OSes,
like OpenBSD, that don't include DRM.

I'm not a tinfoil-hat type of person, but I have a healthy fear of code
written by firmware engineers. That's why things like EFI and now this are
terrible. They're basically shovelware that you can't get rid of on your PC.
Like the uninstallable android apps, but 100x worse.

------
comex
> But our SGX-isolated VMs have one significant advantage over the other VM
> technologies we got used to in the last decade or so – namely those VMs can
> now be impenetrable to any other entity outside of the VM. No kernel or
> hypervisor can peek into its memory. Neither can the SMM, AMT, or even a
> determined physical attacker with DRAM emulator, because SGX automatically
> encrypts any data that leave the processor, so everything that is in the
> DRAM is encrypted and useless to the physical attacker.

So basically, when used for real security, it is a more modular substitute for
a subset of the functionality of secure boot that has the dubious benefit of
protecting against an attacker with a DRAM emulator - except it currently
doesn't even do that, because there is no way to secure user input.

When used for DRM, of course, it works just fine. It's basically the rebirth
of the whole Trusted Computing brouhaha, but worse, because it doesn't depend
on securing the entire boot path and is thus actually practical to implement
in some browser plugin. While it will not be possible to depend on this
feature being present in users' CPUs for the next few years, it could become
very dangerous after that.

Ugh.

------
RDeckard
I must be missing something, but how does one bootstrap an enclave securely? A
malicious VM can emulate the new SGX mode, but lift the restriction of not
being able to access the enclave's memory.

~~~
anologwintermut
TXT handles this with a TPM that stores a key and has hardware to check that
the proper instructions executed and signs an attestation to that fact with
its key. SGX doesn't need a TPM. Does it possibly have similar hardware on
die?

~~~
sweis
SGX adds the ability to attest and seal individual enclaves, with a root
attestation key in the CPU die:
[https://docs.google.com/file/d/0B_wHUJwViKDaSUV6aUcxR0dPejg/...](https://docs.google.com/file/d/0B_wHUJwViKDaSUV6aUcxR0dPejg/edit)

This key has some similarities to a TPM EK / AIK, but rather than PCRs for the
measurements they have a cryptographic log of the enclave.

------
devx
When the NYT article said NSA has succeeded in putting backdoors into
"commercial encryption hardware", what were they talking about? Weren't they
referring to chip companies like Intel?

If Intel wants our trust again, they should open source this stuff, and make
it very transparent so we can verify if it's clean or not. At this point this
should worry them a lot more than "giving their competitive advantage to AMD"
or whatever. Same goes for the other chip makers, too, of course. So maybe
they can all do it at once, to level the playing field.

------
SolarNet
This seems to remind me of the SHE from Vernor Vinge's Rainbows End. Obviously
we are a ways away from that, but this is an interesting step in that
direction.

------
throwwit
The new PR name for Palladium ([http://www.geek.com/chips/palladium-
microsofts-big-plan-for-...](http://www.geek.com/chips/palladium-microsofts-
big-plan-for-the-pc-549258/\)\(2002\)) After the effects of the leak I'm
feeling somewhat confident a standard like this doesn't have any legs
internationally.

~~~
wging
thanks for the link. fyi, it doesn't go where you wanted it to. your (2002)
annotation is being interpreted as part of it.

unmangled version: [http://www.geek.com/chips/palladium-microsofts-big-plan-
for-...](http://www.geek.com/chips/palladium-microsofts-big-plan-for-the-
pc-549258/)

------
sweis
SGX is a very interesting development. I agree with Johanna Rutkowska that
"SGX might profoundly change the architecture of the future operating
systems".

Enhanced Privacy IDs are particularly interesting, since it will allow you to
anonymously or pseudonymously authenticate a particular CPU:
[http://csrc.nist.gov/groups/ST/PEC2011/presentations2011/bri...](http://csrc.nist.gov/groups/ST/PEC2011/presentations2011/brickell.pdf)

It's also very powerful to be able to attest secure enclaves with a root of
trust within the CPU, rather than a TPM. It removes TPMs and the LPC bus as an
attestation attack vector.

------
malkia
So no jitting then?

