Joanna Rutkowska

There's really no getting around the evil maid attack[1], if someone can attack your hardware directly. There's even evidence that a sufficiently clever attack can persist through formatting and re-installing a drive[2] - note, people have also found exploits in network firmware... remotely exploitable exploits. If you can do it by accident[3], then most likely it can be done with malice aforethought.

Edit: adding a strong pass-phrase /does/ give you a significant level of protection; While it doesn't offer protection from an evil maid type attack (where the attacker trojans your server, then you decrypt your key after said server was compromised) it does offer quite a bit of protection, say, from an attacker who has access to old backups but not your production system. So I think a passphrase on all of your important private keys is a worthwhile thing to have.

I just want to make it clear, once you decrypt that key from within a compromised system? all bets are off.

[1]https://www.schneier.com/blog/archives/2009/10/evil_maid_attac.html

[2]https://news.ycombinator.com/item?id=6148347
(of course, this specific attack wasn't as scary as it could have been, say if the same sort of thing was remotely accessible)

[3]http://theinvisiblethings.blogspot.com/2010/04/remotely-attacking-network-cards-or-why.html

I think I picked this up off Hacker News originally, but there's apparently new Intel stuff (aka SGX) coming out to help with this.
http://theinvisiblethings.blogspot.com/2013/08/thoughts-on-intels-upcoming-software.html

Unfortunately, I think the reason most open source people have a knee-jerk aversion to trusted platforms are that they've historically been designed to only serve the interests with the most money (read: the government and/or content industry).

There's nothing inherently anti-open source about the schemes, and they would provide innumerable benefits to increasing security confidence in a networked world.

However, when you can rattle off enough failed or botched encryption initiatives involving a hardware component to fill one hand just from the top of one's head (CSS, AACSS, HDCP, UEFI/SecureBoot, FairPlay), confidence is not inspired...

Intel's SGX is just a hardware generation away. This allows for encrypted code to run inside hardware protected regions called enclaves - the memory regions are encrypted and decrypted as they are pulled into the core.

In a curious design decision, SGX allows the code in the enclave to access all the memory of the process it's associated with so it can do whatever ugly stuff it wants.

Can we have proof carrying encrypted code? Or perhaps a trusted code verifier that's not encrypted that runs in an enclave too?

https://software.intel.com/en-us/blogs/2013/09/26/protecting-application-secrets-with-intel-sgx
http://theinvisiblethings.blogspot.co.uk/2013/08/thoughts-on-intels-upcoming-software.html

Edit: Measured boot (DRTM, e.g. implemented by Qubes) has some benefits over "Secure Boot" (SRTM), both for firmware modification and key management.

http://www.pcworld.com/article/2883903/how-intel-and-pc-makers-prevent-you-from-modifying-your-pcs-firmware.html, "There’s also a second option: “Measured Boot” mode, where the hardware securely stores information about the boot process in a trusted platform module (TPM) or Intel Platform Trust Technology (PTT). The operating system could then examine this information, and—if there was a problem—present an error to the user.

More on DRTM & SRTM: http://theinvisiblethings.blogspot.com/2011/09/anti-evil-maid.html

I didnt say it was bad... I said, I was surprised given there is a 6 month schedule, that I randomly decided to check exactly 1 day before said schedule, and yet it was still secretly available.
I don't think it runs as root either, I'm more concerned about xinput and keyloggers running as my normal user being able to snoop on even sudo/su prompts running as root in a GUI terminal window running as my user. You know about this right? https://theinvisiblethings.blogspot.com/2011/04/linux-security-circus-on-gui-isolation.html Wayland was supposed to prevent this, but I don't think its going well on OpenBSD. Does OpenBSD have a solution for this?

> Join the live presentation. Wednesday April 15, 4:15-5:30. Requires Microsoft Windows Media player.

Seriously?

Anyways, what I'd be interested to know is if Intel has found a way to ensure that if the private key is stolen, others can find out about it. Since that seems overly complex/almost impossible, then the alternative should be to let users have their own keys and allow them to change the keys as well. Intel should not have access to those keys (in a provable way).

Otherwise we'd never know if the NSA has the keys to all future "secure programs" protected by SGX.

http://theinvisiblethings.blogspot.com/2013_09_01_archive.html