
Intel Software Guard Extensions for Linux - snaky
https://01.org/intel-softwareguard-eXtensions
======
the8472
>protection

Except from ever more sophisticated side-channel attacks.

I can see why someone would want to have it in cloud machines. But I hope it
never makes it into enduser devices, it's only going to be used for DRM there.

~~~
teacup50
Genuine question since I haven't read the SGX docs in detail;

What's to stop us from implementing a broken SGX via trap-and-emulate?

~~~
drdaeman
I suppose a CPU would contain some secret key material of its own, that can be
used to authenticate the hardware.

------
pierrec
Skimming through the docs, I'm still not sure how they can guarantee that an
enclave can't be meaningfully emulated. Do they simply mean that you can't
emulate a specific processor (since each processor uses a unique key)? That
wouldn't be the same guarantee at all. Or is it just impractical to emulate
SGX with acceptable performance? I'm probably missing something. (Note, I know
SGX can be virtualized properly, but I'm specifically referring to emulation
that would allow you to effectively debug an SGX-protected program).

~~~
the8472
[https://software.intel.com/sites/default/files/332680-002.pd...](https://software.intel.com/sites/default/files/332680-002.pdf)

Page 36. After building the enclave you can have the CPU sign the state with
an intel key. You can then check the signed state against a known-good state
and only submit your secret data to the enclave if signature can be verified
against intel's pubkey.

Additional overview:
[https://software.intel.com/sites/default/files/managed/3e/b9...](https://software.intel.com/sites/default/files/managed/3e/b9/SF15_ISGC003_81_SGX_DL_100_small.pdf)

~~~
kuschku
So, I only have to take apart one single CPU to destroy the whole concept?

~~~
the8472
Probably not, I would guess that they're using something similar to a
certificate chain, i.e. a per-CPU key which is signed by intel which could
then be revoked when the leak gets noticed.

------
MichaelGG
So is SGX open to everyone? We don't need a key signed or blessed by Intel to
use it? If so that's great. Provably secure mixing services. Secure data
processing clouds. Sounds neat.

You could build a secure webmail system and verify it's running as designed.

~~~
amluto
Probably yes, kind of.

On newer CPUs (unclear which ones yet), there is a set of MSRs called
IA32_SGXLEPUBKEYHASH. If available and unlocked by BIOS, then SGX is open to
everyone.

Looking at the provided Launch Enclave source
([https://github.com/01org/linux-
sgx/blob/master/psw/ae/le/lau...](https://github.com/01org/linux-
sgx/blob/master/psw/ae/le/launch_enclave.cpp#L254)), it appears that, even on
existing CPUs, the LE can be configured to launch anything. There's a file in
the git tree ([https://github.com/01org/linux-
sgx/blob/master/psw/ae/data/p...](https://github.com/01org/linux-
sgx/blob/master/psw/ae/data/prebuilt/white_list_cert_to_be_verify.bin)) that
sounds promising, but I haven't checked whether it's signed with production
keys or whether it works for this purpose.

------
realo
This would have been very,, very useful and immensely popular in the Embedded
world (and all those Internet-Of-Thingies).

Intel: make this work on some future generation of Baytrail, with a proper
version of Linux (Yocto comes to mind), and you might become relevant again.

------
ComodoHacker
Is my understanding correct that this is basically a built-in virtual HSM,
with the advantages of being a) fully programmable and b) not performance-
limited?

------
zmanian
I'm really impressed by how easy it is to get NISTP256 key from the enclave. I
think Intel got a lot of things right and then completely failed on the
signing and attestation process. Hopefully we can see a future iteration of
SGX that builds on this early promise.

------
karianna
We're working on versions of Java, Nginx, MySQL etc that can run inside the
secure enclaves, it's interesting and challenging work!
[http://www.serecaproject.eu/](http://www.serecaproject.eu/)

------
eximius
Does anyone know how much room one of these things would have anyway?

~~~
matthewaveryusa
It's yet to be determined what best practices will be, but I have a hunch SGX
will be used along the following lines:

1) load an encrypted symmetric key into an enclave

2) decrypt the symmetric key in the enclave

3) create a private key in the enclave, and encrypt it with the symmetric key
inside the enclave. Give the encrypted data back to the user for storage.

4) All operations using the private key (sign, decrypt) are marshaled to the
SGX enclave. You'll give the enclave the encrypted private key and the
operation to be performed, and the enclave will return the result. The private
key is decrypted by the symmetric key inside the enclave, and unloaded from
the enclave memory as soon as the operation is completed.

There's obviously some churn copying the encypted private key to the enclave
each time, but the private key is typically used for very few operations until
an ephemeral symmetric key is negotiated. If you're super-paranoid the
ephemeral key can marshal its operations to the enclave, but I think most
people will agree that the only thing you can realistically protect without
sacrificing performance is the private key.

~~~
bogomipz
So you would load the symmetric key into the enclave out of band i.e via the
BIOS or IPMI? Could this be use the encrypt filesystem or block devices using
something like LUKs I wonder?

------
bogomipz
What current Intel CPUs contain this secure enclave?

~~~
wtallis
Looks like all _Skylake_ processors, even the low-end ones that miss out on a
lot of other features:
[http://ark.intel.com/products/codename/37572/Skylake#@All](http://ark.intel.com/products/codename/37572/Skylake#@All)

~~~
mtgx
Except for the very first models, from like the first two months or so of last
fall. They had an issue with it.

