6 ms·
let's say that I want to do some secure banking, so I fire up the secure banking app and off I go. problem: what if my whole operating system is owned, right d
by munin 11y ago
let's say that I want to do some secure banking, so I fire up the secure banking app and off I go.
problem: what if my whole operating system is owned, right down to the keyboard interrupt handler? everything I do with this secure banking app is compromised.
okay, so instead what if I could put all the keyboard I/O, all the network I/O, the code, and the data, of the secure banking app into a trusted enclave, where the trusted enclave is cryptographically signed and verified from the BIOS up? now the OS can be totally owned but it can't read anything that goes on inside, or comes out of, this little enclave that's doing my banking.
that would be cool, right? now what if you could do that for all kinds of apps, like your email, and your web browser, and your key agent, and so on. and they're all in different secure enclaves that can't interfere with each other, and the host operating system can't reach in and touch their memory.
wouldn't that be cool?
- teraflop 11y agoIf I'm understanding this correctly, it doesn't provide any kind of protection against a compromised operating system. How could it? The encryption is transparent to applications, so the OS could just lie and say that encryption is enabled. What it does provide is protection against hardware attacks like memory bus snooping, or chilling and extracting DRAM modules.
- anonymousDan 11y agoNot necessarily, depends on what exactly you put in the enclave. It's possible to design a system where the OS lives outside the enclave in untrusted memory. The assurance that your enclave memory is protected is provided by the hardware, and can be confirmed remotely by an attestation protocol. For more information I would recommend checking out a paper by Microsoft Research called "Shielding applications from an untrusted cloud with Haven" from OSDI' 14.
- therein 11y agoRing -1?
- teraflop 11y agoSure, but that's a totally different mechanism than the one discussed in this link. According to the presentation, it uses ephemeral keys that are randomly generated at boot, so it doesn't help with things like remote attestation.
- anonymousDan 11y agoNo, the whole point of SGX is that there is a unique key burned into each machine from which other keys are derived that allows you to attest the contents of each enclave's memory.
- teraflop 11y agoI thought we were talking about the "Memory Encryption Engine", which is what the link is describing. Slide 7 says the keys are "randomly generated at reset".
- ENOTTY 11y agoThe OS can't lie because it is unable to generate the same keys the hardware uses. Without those keys, the enclave can't decrypt whatever sensitive data it sealed earlier.
- lfam 11y agoYou should check out Genode on i.MX53: http://genode.org/documentation/articles/trustzone http://genode.org/documentation/articles/trustzone
- mtgx 11y agoIt would be even cooler if Intel itself wouldn't own the private key to decrypt those enclaves remotely.
- pjc50 11y agoI call this the "black boxes survive plane crashes, so why don't we make the whole plane out of that stuff?" argument. The more code that goes into the box, the more opportunities there are for exploits. That's why it's important to put as little as possible in the box and make carefully defined interfaces to it. iOS is supposedly cryptographically verified from the boot upwards, to inhibit jailbreaking of phones and people sneaking past the platform holder's tax, but it's not entirely hackproof. So it has an enclave within the enclave: an ARM TrustZone secure enclave running the sel4 formally verified microkernel. Similarly hypervisor systems are trying to divide a system into segregated apps that can't interfere, but are vulnerable to (rare) hypervisor exploits. It can't be crypto-turtles all the way down, there has to be a root of privilege. And there's always the hardware; have you seen how long the Intel errata list is?