Handmade Hero » Forums » Code » Possible SGX bypass techniques
mmozeiko
Mārtiņš Možeiko
1440 posts
1 project
#5886 Possible SGX bypass techniques
1 year, 6 months ago

If you are asking about Intel master cpu-specific key, then no - you cannot replace it with your own.

As for your own keys - you can load into encrypted enclave whatever data you want. Is it a key, an bitmap, an email - it doesn't matter, CPU doesn't care about that. You don't really load your own key into CPU. You load into memory that is under protection (enclave).

For keeping whole OS in enclave, that wont work well. At least for current generation CPUs. Because the max size of enclave is not very large. For example, Insipiron 13 i7359 laptop has only 128MB available for running enclaves. If you will want to operate with larger data, a lot of swapping out to regular memory will be required. That will decrease performance even more.

If you don't keep whole OS and apps into protected memory, SGX could still help for full-disk encryption. You could keep FDE key in enclave, and do the encryption/decryption in there. When driver needs to decrypt or encrypt block of disk data, it sends buffer to SGX enclave, and receives back decrypted or encrypted buffer. This way key won't be available in plain anywhere. You won't be able to lift it from memory.

And SGX will definitely help data centers - you will be able to store SSL private keys, ssh private keys (if needed) and similar sensitive data. No more need for expensive HSMs. It's great for platform security.
people
39 posts
#5888 Possible SGX bypass techniques
1 year, 6 months ago

Thanks for the answers, I find it amazing how well you able to help everyone on the forums, thanks for the effort :)

It's a shame you can't store your own keys in the cpu directly, then you wouldn't have to get your enclaved program signed by intel, or have to rely on intel being uncompromised.

I wonder if future computers will lift the enclave size limit.

While it's nice to be able store the FDE keys in an enclave, it would be better if all the data in memory were not plaintext.
cmuratori
Casey Muratori
802 posts
1 project

Casey Muratori is a programmer at Molly Rocket on the game 1935 and is the host of the educational programming series Handmade Hero.

#5900 Possible SGX bypass techniques
1 year, 6 months ago

Pseudonym73
And putting the tinfoil hat on, what's the chance that the next Stuxnet somehow gets signed, and Intel has no idea how it happened?

I'm fairly certain that's exactly what will happen. I guess one thing we will be able to say for sure soon (perhaps even just by carefully reading the PDF - I only skimmed it) is whether or not their signature scheme is quantum-secure. If it's not (I'm guessing it's not), then we can at least say that if quantum factoring does come to fruition in the near future, state actors will definitely be able to run as much malware through SGX as they want, and security professionals won't even be able to look at the disassembly.

What a wonderful world that will be!

- Casey
mmozeiko
Mārtiņš Možeiko
1440 posts
1 project
#5902 Possible SGX bypass techniques
1 year, 6 months ago

It's not quantum secure. They are using RSA.
cmuratori
Casey Muratori
802 posts
1 project

Casey Muratori is a programmer at Molly Rocket on the game 1935 and is the host of the educational programming series Handmade Hero.

#5905 Possible SGX bypass techniques
1 year, 6 months ago

mmozeiko
It's not quantum secure. They are using RSA.

Fantastic :(

- Casey
mmozeiko
Mārtiņš Možeiko
1440 posts
1 project
#6166 Possible SGX bypass techniques
1 year, 5 months ago

New whitepaper from Intel describing infrastructure, key provisioning and attestation services: https://software.intel.com/en-us/...isioning-and-attestation-services

cmuratori
Casey Muratori
802 posts
1 project

Casey Muratori is a programmer at Molly Rocket on the game 1935 and is the host of the educational programming series Handmade Hero.

#6174 Possible SGX bypass techniques
1 year, 5 months ago

Holy shit dude - look at that, the revocation stuff is right there in the diagram! So my hypothetical was not in any way hypothetical.

- Casey
mmozeiko
Mārtiņš Možeiko
1440 posts
1 project
#6524 Possible SGX bypass techniques
1 year, 3 months ago Edited by Mārtiņš Možeiko on April 27, 2016, 3:03 a.m.

Here's similar technology from AMD - "Secure Memory Encryption" and "Secure Encrypted Virtualization":
http://amd-dev.wpengine.netdna-cd...cryption_Whitepaper_v7-Public.pdf

But this seams to do security for different purposes. It only guards against dumping memory from RAM modules. It doesn't isolate individual processes. It simply does AES encryption transparently when pages are pushed to RAM modules.
With full memory encryption, all DRAM contents are encrypted utilizing the random key which provides strong protection against cold boot, DRAM interface snooping, and similar types of attacks.
Its main use seems to be virtual machine environments. If hypervisor exposes this extension to guests, then guests can encrypt their memory with guest specific key. Thus memory for each guest VM will not be exposed in case some other guest VM is compromised.
mmozeiko
Mārtiņš Možeiko
1440 posts
1 project
#11903 Possible SGX bypass techniques
3 months, 2 weeks ago Edited by Mārtiņš Možeiko on May 10, 2017, 3:50 p.m.

Here's a paper about how researchers can extract private RSA key out from SGX (which uses constant-time multiplication primitive) just by monitoring CPU cache behavior: https://arxiv.org/pdf/1702.08719.pdf

In this paper, we demonstrate fine-grained software-based side-channel attacks from a malicious SGX enclave targeting co-located enclaves. Our attack is the first malware running on real SGX hardware, abusing SGX protection features to conceal itself. Furthermore, we demonstrate our attack both in a native environment and across multiple Docker containers. We perform a Prime+Probe cache side-channel attack on a colocated SGX enclave running an up-to-date RSA implementation that uses a constant-time multiplication primitive. The attack works although in SGX enclaves there are no timers, no large pages, no physical addresses, and no shared memory. In a semisynchronous attack, we extract 96% of an RSA private key from a single trace. We extract the full RSA private key in an automated attack from 11 traces within 5 minutes.