8 ms·

Intel Software Guard Extensions for Linux

93 points by snaky 10y ago

pierrec 10y ago
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 10y ago
  https://software.intel.com/sites/default/files/332680-002.pdf https://software.intel.com/sites/default/files/332680-002.pd... 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/SF15_ISGC003_81_SGX_DL_100_small.pdf https://software.intel.com/sites/default/files/managed/3e/b9...
  - kuschku 10y ago
    So, I only have to take apart one single CPU to destroy the whole concept?
    - the8472 10y ago
      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.
- amluto 10y ago
  You can emulate an enclave, but, if you do, the emulated enclave doesn't get access to its seal key, etc. The idea is that you provision secrets accessible only with access to the key and then write an enclave to access those secrets. An enclave can verify itself to another enclave on the same machine, and Intel supplies a mechanism by which licencees (sigh) can verify their enclaves remotely.
  - derefr 10y ago
    I think the question is, is there any way to verify—from the userland of a cloud VM instance, where the enclave is talked to via hypercalls—that you're "installing" an enclave and its key into the processor itself (where it would be protected from access by rogue datacenter ops staff) rather than just into a hypervisor-emulated processor that is actually fully accessible to the machine owner? The sibling post mentions that the processor signs its enclaves' outputs with an Intel private key, which would help a bit—but if that key is static, that'd be pretty easily thwarted by decapping a single processor to get the key, just like extracting the DRM keys from set-top boxes or game consoles. (TPMs are supposed to "self destruct" when you try to decap them, but that's only scary for the individualized keys in a TPM; if you're willing to sacrifice 1000 chips to reconstruct one key common to them all, it becomes just a matter of persistence.)
    - amluto 10y ago
      This is, indeed, a problem. I'm not aware of any mechanism to protect against it.
the8472 10y ago
>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.
- SXX 10y ago
  > it's only going to be used for DRM there. It's will be also useful for spyware developers too.
  - the8472 10y ago
    Thinking about it, an alternative would be the ability to use user-supplied debug keys (in the BIOS) instead of intel signing keys. That way neither DRM nor malware would not be possible because the user could enter debug mode to inspect the enclaves if he wanted to but could still use SGX to secure his own applications because malicious code would not have access to the private keys.
    - userbinator 10y ago
      Intel clearly wants complete control over what gets to run on the PC platform --- which is rather disturbing, but seems to be the way a lot of other companies are moving these days. Introducing SGX and "verified" software and promoting it as the best thing for everyone is only the first step. It's only a matter of time before they convince everyone to eventually deprecate "insecure" (i.e. free) software that doesn't use it, completely killing the "P" in "PC". I'd consider SGX a small step forward for security and a big step backward for personal freedom... it makes me sad just how accurate Stallman was nearly 20 years ago: https://www.gnu.org/philosophy/right-to-read.en.html https://www.gnu.org/philosophy/right-to-read.en.html As such, I don't consider this announcement great news at all --- it's downright scary, an indicator of where things are going.
      - digi_owl 10y ago
        Its been a slow boiling frog ever since the Palladium debacle.
eximius 10y ago
Does anyone know how much room one of these things would have anyway?
- zimmerfrei 10y ago
  Around 100MB of physical RAM, to be shared among all enclaves active at a given time in the platform. Enclaves can be swapped out (if the OS/VMM is sophisticated enough), so in principle memory can be overbooked.
  - JoshTriplett 10y ago
    That's not a hardware limitation; SGX supports arbitrarily large enclaves. The encrypted region of physical memory has to be reserved during early boot (using the PRMRR_BASE and PRMRR_MASK MSRs), so typically it's a small portion of physical memory to avoid taking too much memory from the OS; however, that could be configured to be larger if needed. And as you noted, SGX supports the kernel paging memory in and out of the enclave (encrypting it before giving it to the kernel to store), which allows for arbitrarily large enclaves regardless of the amount of reserved physical memory. Typically you do want to minimize the amount of code that you put inside the enclave to minimize your attack surface and the amount of code you trust, but there isn't any architectural limitation on size.
- matthewaveryusa 10y ago
  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.
realo 10y ago
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.
bogomipz 10y ago
What current Intel CPUs contain this secure enclave?
- wtallis 10y ago
  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 10y ago
    Except for the very first models, from like the first two months or so of last fall. They had an issue with it.
  - the8472 10y ago
    It also needs bios-support. Luckily it's off by default and not supported by most bioses.
ComodoHacker 10y ago
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 10y ago
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.
MichaelGG 10y ago
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 10y ago
  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/launch_enclave.cpp#L254 https://github.com/01org/linux-sgx/blob/master/psw/ae/le/lau...), 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/prebuilt/white_list_cert_to_be_verify.bin https://github.com/01org/linux-sgx/blob/master/psw/ae/data/p...) that sounds promising, but I haven't checked whether it's signed with production keys or whether it works for this purpose.
karianna 10y ago
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/

93 points by snaky 10y ago

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 10y ago
https://software.intel.com/sites/default/files/332680-002.pdf https://software.intel.com/sites/default/files/332680-002.pd... 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/SF15_ISGC003_81_SGX_DL_100_small.pdf https://software.intel.com/sites/default/files/managed/3e/b9...
- kuschku 10y ago
  So, I only have to take apart one single CPU to destroy the whole concept?
  - the8472 10y ago
    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.
amluto 10y ago
You can emulate an enclave, but, if you do, the emulated enclave doesn't get access to its seal key, etc. The idea is that you provision secrets accessible only with access to the key and then write an enclave to access those secrets. An enclave can verify itself to another enclave on the same machine, and Intel supplies a mechanism by which licencees (sigh) can verify their enclaves remotely.
- derefr 10y ago
  I think the question is, is there any way to verify—from the userland of a cloud VM instance, where the enclave is talked to via hypercalls—that you're "installing" an enclave and its key into the processor itself (where it would be protected from access by rogue datacenter ops staff) rather than just into a hypervisor-emulated processor that is actually fully accessible to the machine owner? The sibling post mentions that the processor signs its enclaves' outputs with an Intel private key, which would help a bit—but if that key is static, that'd be pretty easily thwarted by decapping a single processor to get the key, just like extracting the DRM keys from set-top boxes or game consoles. (TPMs are supposed to "self destruct" when you try to decap them, but that's only scary for the individualized keys in a TPM; if you're willing to sacrifice 1000 chips to reconstruct one key common to them all, it becomes just a matter of persistence.)
  - amluto 10y ago
    This is, indeed, a problem. I'm not aware of any mechanism to protect against it.

the8472 10y ago

>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.

SXX 10y ago
> it's only going to be used for DRM there. It's will be also useful for spyware developers too.
- the8472 10y ago
  Thinking about it, an alternative would be the ability to use user-supplied debug keys (in the BIOS) instead of intel signing keys. That way neither DRM nor malware would not be possible because the user could enter debug mode to inspect the enclaves if he wanted to but could still use SGX to secure his own applications because malicious code would not have access to the private keys.
  - userbinator 10y ago
    Intel clearly wants complete control over what gets to run on the PC platform --- which is rather disturbing, but seems to be the way a lot of other companies are moving these days. Introducing SGX and "verified" software and promoting it as the best thing for everyone is only the first step. It's only a matter of time before they convince everyone to eventually deprecate "insecure" (i.e. free) software that doesn't use it, completely killing the "P" in "PC". I'd consider SGX a small step forward for security and a big step backward for personal freedom... it makes me sad just how accurate Stallman was nearly 20 years ago: https://www.gnu.org/philosophy/right-to-read.en.html https://www.gnu.org/philosophy/right-to-read.en.html As such, I don't consider this announcement great news at all --- it's downright scary, an indicator of where things are going.
    - digi_owl 10y ago
      Its been a slow boiling frog ever since the Palladium debacle.

eximius 10y ago

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

zimmerfrei 10y ago
Around 100MB of physical RAM, to be shared among all enclaves active at a given time in the platform. Enclaves can be swapped out (if the OS/VMM is sophisticated enough), so in principle memory can be overbooked.
- JoshTriplett 10y ago
  That's not a hardware limitation; SGX supports arbitrarily large enclaves. The encrypted region of physical memory has to be reserved during early boot (using the PRMRR_BASE and PRMRR_MASK MSRs), so typically it's a small portion of physical memory to avoid taking too much memory from the OS; however, that could be configured to be larger if needed. And as you noted, SGX supports the kernel paging memory in and out of the enclave (encrypting it before giving it to the kernel to store), which allows for arbitrarily large enclaves regardless of the amount of reserved physical memory. Typically you do want to minimize the amount of code that you put inside the enclave to minimize your attack surface and the amount of code you trust, but there isn't any architectural limitation on size.
matthewaveryusa 10y ago
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.

realo 10y ago

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.

bogomipz 10y ago

What current Intel CPUs contain this secure enclave?

wtallis 10y ago
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 10y ago
  Except for the very first models, from like the first two months or so of last fall. They had an issue with it.
- the8472 10y ago
  It also needs bios-support. Luckily it's off by default and not supported by most bioses.

ComodoHacker 10y ago

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 10y ago

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.

MichaelGG 10y ago

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 10y ago
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/launch_enclave.cpp#L254 https://github.com/01org/linux-sgx/blob/master/psw/ae/le/lau...), 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/prebuilt/white_list_cert_to_be_verify.bin https://github.com/01org/linux-sgx/blob/master/psw/ae/data/p...) that sounds promising, but I haven't checked whether it's signed with production keys or whether it works for this purpose.

karianna 10y ago

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/