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.

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.

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

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

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

Fantastic :(

- Casey

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

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

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.

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.

Here's a side-channel-like attack that gives allows to do arbitrary memory reads on SGX protected memory: https://foreshadowattack.eu/
It also allows to read host's memory from guest VM.

Basically SGX currently is completely broken. There are probably microcode and OS patches incoming to try to fix this.