On Mon, Nov 11, 2013 at 2:48 PM, Mike Mestnik <che...@mikemestnik.net> wrote: > I don't see how this is relevant? Obviously if hardware is seized then the > owners no longer have control. If you have suggestions as to how to secure > hardware that's great, but if you just want to point out that "Nothing can > be done." That's not helpful.
I think Jacob suggests to get a encryption hardware module that does not disclose the key. Let's get back to "how can we protect the SSL certificate of the server?" To protect against the certificate being stolen with physical access, you can encrypt the hard drive (it causes other problems, like how you enter the key to decrypt the disk -- you can SSH during the boot to provide the decryption key to Luks). But it does not protect against freezing the RAM of the server to extract the private key. But... this has both little chance to occur and little chance of the sysadmin/security guys not noticing it (and thus reacting to that immediately). This is also probably more complicated and dangerous than, say, being the US government and request a signed certificate from a US company under a sort of FISA warrant (that they cannot disclose) to do "lawful interception". But all of this is very theoretical. What Jacob suggests is to have a HSM (Hardware Security Module) that contains the private certificate and make it impossible (understand: very very hard) to extract the key. The black box signs what it gets asked without revealing the certificate. And then the idea is to do "certificate pinning" in the distribution to make sure the SSL certificate hasn't be forged by a trusted third party (see the Comodo/Diginotar problem). I doubt/really hope that Debian doesn't need that much complicated system to securely its package. -- Jérémie MARGUERIE -- To UNSUBSCRIBE, email to debian-security-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/caks89grbgt0uyq0bsn6gno-qq5xz8f3kvdggvc8qdujbwod...@mail.gmail.com