
Intel Software Guard Extensions – Memory Encryption Engine - mrb
https://drive.google.com/file/d/0Bzm_4XrWnl5zOXdTcUlEMmdZem8/edit
======
transpute
Note that Intel signs [1] software which runs in SGX enclaves. Windows 10 uses
[2][3] SGX.

    
    
      Intel got a pretty long patent on SGX a few years ago. 
      In it, they say that the launch enclave will only issue
      launch tokens after ensuring that the enclave's author has
      a business agreement with Intel. The patent also states
      that they expect enclaves to be useful for DRM, so I'm
      guessing they want to insert themselves into the
      entertainment content distribution systems and collect 
      some royalties.
    

[1] [https://jbeekman.nl/blog/2015/10/intel-has-full-control-
over...](https://jbeekman.nl/blog/2015/10/intel-has-full-control-over-sgx/)

[2] [http://www.alex-
ionescu.com/Enclave%20Support%20In%20Windows...](http://www.alex-
ionescu.com/Enclave%20Support%20In%20Windows%2010%20Fall%20Update.pdf)

[3] [https://software.intel.com/en-us/sgx-
sdk/documentation](https://software.intel.com/en-us/sgx-sdk/documentation)

~~~
wsxcde

        I'm guessing they want to insert themselves into the
        entertainment content distribution systems and collect 
        some royalties.
    

AFAIK the initial request for SGX came from the paranoid-types at HFT firms
who were worried malware would steal their algorithms or something.

The signing mechanism is important because SGX is useless unless you have a
trusted way of getting your code into the enclave. The only reasonable way out
of this is to have a certificate authority and that's what they're doing. If
you think there's a different architecture for SGX that provides the same
security guarantees, I'd love to hear about it.

Intel has much simpler mechanisms than SGX for enforcing DRM. They've been
baking a ton of keys into their processors for many generations now; there was
a proposal to stick a few keys in there that belonged to entities like netflix
and do all the decryption in hardware.

If netflix is going to send us encrypted streams, this is probably the best
architecture to handle it, because you can setup a high-performance power-
efficient hardware streaming pipeline for decryption and decoding.

~~~
amluto
> The signing mechanism is important because SGX is useless unless you have a
> trusted way of getting your code into the enclave. The only reasonable way
> out of this is to have a certificate authority and that's what they're
> doing. If you think there's a different architecture for SGX that provides
> the same security guarantees, I'd love to hear about it.

I don't think so. Unless Intel stuck a back door in their Intel-signed-only
features, the Intel key serves only to restrict which enclaves are permitted
to run. The whole system is designed such that a malicious enclave can neither
compromise another enclave nor can it obtain the symmetric key assigned to
another enclave.

The remote attestation mechanism may depend on Intel keys, but that's about
it.

IOW, the Intel key appears to be almost entirely a business thing.

Anyway, don't get too excited yet. AFAIK Intel hasn't released any signed blob
whatsoever (except maybe to MS so they can test their code), so the policy
simply doesn't exist right now.

~~~
wsxcde
Suppose you have a program that uses SGX. Perhaps this program requires some
public keys which it uses as a root of trust. Presumably you've baked these
public keys into your program, you load this binary with the code+public keys
into the enclave and execute it.

Now, how do you know that malware didn't modify the public key sitting in your
binary before your code was loaded into the enclave? You need hardware to
ensure that it only loads your code and not the modified code. This is where
Intel's signing process comes in. There isn't really any way around it.

~~~
ENOTTY
Not necessarily. The enclave's symmetric keys are bound to its identity, which
is a hash of the memory and permission bits before the enclave starts to run.
If the malware modifies the public key in the binary before it is loaded into
the enclave, the enclave's identity (and its keys) will be completely
different.

------
gruez
Can someone explain to me why intel is implementing these features? Surely no
consumer wants them, so I don't see how it gives them an edge over amd. plus
they're leagues ahead of amd already. The only explanation I can think of is
that supporters of DRM are somehow subsidizing intel's development efforts.

~~~
munin
let's say that I want to do some secure banking, so I fire up the secure
banking app and off I go.

problem: what if my whole operating system is owned, right down to the
keyboard interrupt handler? everything I do with this secure banking app is
compromised.

okay, so instead what if I could put all the keyboard I/O, all the network
I/O, the code, and the data, of the secure banking app into a trusted enclave,
where the trusted enclave is cryptographically signed and verified from the
BIOS up? now the OS can be totally owned but it can't read anything that goes
on inside, or comes out of, this little enclave that's doing my banking.

that would be cool, right? now what if you could do that for all kinds of
apps, like your email, and your web browser, and your key agent, and so on.
and they're all in different secure enclaves that can't interfere with each
other, and the host operating system can't reach in and touch their memory.

wouldn't that be cool?

~~~
teraflop
If I'm understanding this correctly, it doesn't provide any kind of protection
against a compromised operating system. How could it? The encryption is
transparent to applications, so the OS could just lie and say that encryption
is enabled.

What it _does_ provide is protection against hardware attacks like memory bus
snooping, or chilling and extracting DRAM modules.

~~~
anonymousDan
Not necessarily, depends on what exactly you put in the enclave. It's possible
to design a system where the OS lives outside the enclave in untrusted memory.
The assurance that your enclave memory is protected is provided by the
hardware, and can be confirmed remotely by an attestation protocol. For more
information I would recommend checking out a paper by Microsoft Research
called "Shielding applications from an untrusted cloud with Haven" from OSDI'
14.

~~~
teraflop
Sure, but that's a totally different mechanism than the one discussed in this
link. According to the presentation, it uses ephemeral keys that are randomly
generated at boot, so it doesn't help with things like remote attestation.

~~~
anonymousDan
No, the whole point of SGX is that there is a unique key burned into each
machine from which other keys are derived that allows you to attest the
contents of each enclave's memory.

~~~
teraflop
I thought we were talking about the "Memory Encryption Engine", which is what
the link is describing. Slide 7 says the keys are "randomly generated at
reset".

------
jrockway
This is only for DRM, right?

Very few people are getting viruses because someone has come into their house,
connected the DRAM bus on their PC to a logic analyzer, and injected malicious
code directly into memory. Instead, the malicious code is coming in through
trusted code the user is running (web browser, faulty samba server), which
encrypted memory does nothing to protect against.

I believe ARM has had this in the form of TrustZone for a while.

~~~
iofj
So I do see a number of advantages :

1) transforms all RAM into ECC RAM

2) consumers may not care, but large server cpu customers certainly will see
it as a bonus, some will see it as required. Of course, this won't protect
against the NSA.

(server cpu customers are the biggest market for intel [1], and also it's the
market that's not declining at an alarming rate)

[1]
[http://www.technologyreview.com/sites/default/files/images/m...](http://www.technologyreview.com/sites/default/files/images/moores.law_.chartx519.png)
(if you know a more recent one, do let me know)

~~~
m_eiman
_1) transforms all RAM into ECC RAM_

Not quite; it doesn't correct errors, just detects them.

------
ChuckMcM
Wow, I did not think Intel would go this far in the general purpose CPU line.
There has always been a small set of people with "cost no object" requirements
for security (thing 3 letter agencies) but if you get this in a "normal" chip
I could imagine it being used for copy protection of many forms, or for
enterprise security laptops. I does shut down the "but you can snoop memory
anyway with the GPU" loophole.

------
rwmj
Is it possible to decap a processor without damaging it? (ie. so it will
continue to work) If you could do that, then you could attempt to probe the
unencrypted data or the key.

~~~
ctz
Yes. Probing at 14nm is immensely challenge but seemingly possible (see, eg,
[http://dcgsystems.com/products/nanoprobing/nprober-
ii/](http://dcgsystems.com/products/nanoprobing/nprober-ii/) which looks
terribly expensive!)

