Hi! > > > Preventing cold boot attacks is really just icing on the cake. The > > > real point of this is to allow you to run an "enclave". An SGX > > > enclave has unencrypted code but gets access to a key that only it can > > > access. It could use that key to unwrap your ssh private key and sign > > > with it without ever revealing the unwrapped key. No one, not even > > > root, can read enclave memory once the enclave is initialized and gets > > > access to its personalized key. The point of the memory encryption > > > engine to to prevent even cold boot attacks from being used to read > > > enclave memory. > > > > Ok, so the attacker can still access the "other" machine, but ok, key > > is protected. > > > > But... that will mean that my ssh will need to be SGX-aware, and that > > I will not be able to switch to AMD machine in future. ... or to other > > Intel machine for that matter, right? > > That's the whole point. You could keep an unwrapped copy of the key > offline so you could provision another machine if needed. > > > > > What new syscalls would be needed for ssh to get all this support? > > This patchset or similar, plus some user code and an enclave to use. > > Sadly, on current CPUs, you also need Intel to bless the enclave. It > looks like new CPUs might relax that requirement. Umm. I'm afraid my evil meter just went over "smells evil" and "bit evil" areas straight to "certainly looks evil". > > > Replay Protected Memory Block. It's a device that allows someone to > > > write to it and confirm that the write happened and the old contents > > > is no longer available. You could use it to implement an enclave that > > > checks a password for your disk but only allows you to try a certain > > > number of times. > > > > Ookay... I guess I can get a fake Replay Protected Memory block, which > > will confirm that write happened and not do anything from China, but > > ok, if you put that memory on the CPU, you raise the bar to a "rather > > difficult" (tm) level. Nice. > > It's not so easy for the RPMB to leak things. It would be much easier > for it to simply not provide replay protection (i.e. more or less what > the FBI asked from Apple: keep allowing guesses even though that > shouldn't work). Yup. > > But that also means that when my CPU dies, I'll no longer be able to > > access the encrypted data. > > You could implement your own escrow policy and keep a copy in the > safe. And then Intel would have to bless my own escrow policy, which is, realistically, not going to happen, right? > > And, again, it means that quite complex new kernel-user interface will > > be needed, right? > > It's actually fairly straightforward, and the kernel part doesn't care > what you use it for (the kernel part is the same for disk encryption > and ssh, for example, except that disk encryption would care about > replay protection, whereas ssh wouldn't). So we end up with parts of kernel we can not change, and where we may not even change the compiler. That means assembly. Hey, user, you have freedom to this code, except it will not work. That was called TiVo before. We'd have security-relevant parts of kernel where we could not even fix a securit holes without Intel. If anything, this is reason to switch to GPLv3. I'm sorry. This is evil. Pavel -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html -- To unsubscribe from this list: send the line "unsubscribe linux-doc" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
