It can be used as a programmable secure element. Think disk encryption (with protection against brute forcing), storage of SSH and TLS keys, credit card authentication, etc.
What I'm saying is that its current threat model also defends against any access by the owner of the machine, even though that is not necessary to achieve application security.
Not even boot time configuration can override any of it. So it is unnecessarily user-hostile because it can be used to implement DRM and similar schemes where the user has no control over the execution on his hardware.
It does not provide an escape hatch when it should.
Or are we talking about execution of pre-encrypted code on disk that the machine owner can't disassemble? Because the former sounds like a good idea, while the latter sounds like an insanely bad one.
[1] https://software.intel.com/sites/default/files/332680-002.pd...
1. plain-text code gets loaded into enclave
2. enclave generates a keypair
3. enclave authenticates itself against a 3rd party (the DRM/malware mothership) and sends it the pubkey
4. mothership sends additional secrets / code, only decryptable by the enclave
5. you now have uninspectable code running on your machine
And since the enclave can persist itself with the sealing key the handshake only has to happen once, e.g. during the installation phase which often happens with elevated privileges, i.e. also includes network access.
Oh, and the enclave also has access to the rest of the process memory, i.e. the system is not shielded from the actions of said uninspectable code.
Sure it is. Why shouldn't a laptop be able to protect itself against a nation-state the way an iPhone can? The only real way to do that is to make the enclave keys write-only. Anything less (e.g. giving the user master recovery codes) is vulnerable to the nation-state's favorite tactic—rubber-hose cryptanalysis.
That's where you are wrong.
You could install a pubkey in the bios that allowed decryption (by making the symmetric key of enclaves available through encryption with the pubkey). Then the user can choose whether he wants debuggability (by keeping the private key) or security against rubberhose-cryptanalysis (by discarding the key)
What about a cloud service that wants to deny themselves access to your data, despite the fact that they own the physical hardware?
The iPhone secure element, for example, is specifically designed to defend attackers with physical possession.
This scenario is fundamentally flawed. If you can't trust them with your data then you can't give it to them, otherwise the first side channel attack against the hardware gives them access to it.
On top of that, all you're really doing is moving the party you have to trust from Amazon/Google/Apple/Microsoft/Rackspace/yourself to Intel. Why is Intel supposed to be any more trustworthy? They're inherently worse because they have less competition, so you have less choice in who you're willing to trust.
The cloud provider could operate by accepting a pubkey provided by you, thus they would not have the private key.
I did not propose to replace intel's signing key, although that would also be possible[0]. I'm suggesting to add an additional keypair that can be used to decrypt a secure enclave's memory. Let's call it the backdoor key. Because this is a legit backdoor, to be used by the owner of the house.
Attestation would be performed with intel's key (so you know it's not an emulator) but also indicate which keypair could be used to break the enclave (so you know who has access to the backdoor).
By default that could be an invalid (unusuable) key. If you want to debug enclaves, e.g. because you suspect they run malware, you would add your own. If you want to run on a cloud provider, you send your own to the cloud provider. If you want to protect your own stuff from malware or rubberhose cryptanalysis, you don't need one and can leave the invalid key or one with a discarded private key in place.
To preempt a possible objection: This backdoor does not work retroactively. Only enclaves created after changing the key will be affected by it and it will show up in their attestation. So an attacker with physical access would not gain access to past encrypted data, forward secrecy remains intact.
[0] To fully replace intel's key it would either require a write-only procedure to get it into the hardware at boot time, which would only make sense with physical access to the machine, or one would have to replace the old key with the new one from within an enclave, that way you would ensure trust-continuity and thus avoid the emulation problem.
This wouldn't solve the malware problem. The problematic kind of malware will use attestation, because otherwise you would simply emulate it from start to finish. If the malware author is paying any attention, then their malware will simply refuse to run (C&C won't provision it with a payload) if a backdoor key is installed, just as it would refuse to run if emulated.
You would gain the ability to use SGX for your own internal purposes with a form of escrow, but I think you could achieve this even on existing SGX by writing an enclave that emulates other enclaves and tweaking the key derivation process a bit. Admittedly it would be awkward.
That looks like a solution to the malware problem to me. Only people who want to run SGX-based DRM would leave the default key in place. And DRM is structurally indistinguishable from malware.
I theory you could also use a whitelist-approach. Write an open-source enclave-loader which initializes an enclave and then pulls in signed code into the enclave (from within) to execute. But in practice malware would just trick the user to add something to the whitelist. "Want to play this porn video? Just add our DRM!"
So really, just choose between owner-only-debuggability and no malware or DRM and malware. The choice is yours.