Comment by trotsky | Hacker News Reader

Comment by trotsky | Hacker News Reader

Parent Full thread

If you want a realistic chance of not losing control of your private key the only real answers are hardware based - using a tamper resistant smart card, hardware security module, tpm or similar systems in which the signing is done inside the chip that contains your signing keys and no general purpose device ever sees the key at all.

Most people using software only solutions won't ever have their keys stolen, but that's because nobody tried to steal them. The compromise of a client os is inevitable if targeted by a competent actor, given enough time.

Smartcards and HSM's may not be infallible, but their rate of compromise appears to be negligable at best and an extremely rare capability for an offensive team to have access to.

Smartcards are surprisingly cheap and easy to work with, and due to their simplicity and long history are quite secure. The only real attack on them involves physical access and causes obvious physical damage that'd be impossible to miss.

I would be very interested in a a tutorial or guide for getting something like this set up on OS X.

OS X has smart card support for FileVault 1 but not FileVault 2. It only includes enough drivers to support US DoD CAC cards, and other NATO countries that have standardized on our stuff.

With regard to PGP, you can get a reader and smartcard from Kernel Concepts. Assuming you already know how to use GPG, it's pretty easy to set up.

http://shop.kernelconcepts.de/index.php?cPath=1_26&sort=2a&l...

The answer depends on what kind of key material and applications you use. Sadly there is no one size fits all system.

https://www.opensc-project.org/opensc/wiki/OverView

this would probably be the place to start, at least to figure out which type of card you'd want. The main choices are a) support pgp and ssh b) support x.509 certificate based signing c) support time or use type tokens (like smartphone 2 factor apps) or d) some non standardized system running custom code on a tiny jvm inside the card.

a) would be what you'd want in the context of this conversation, but b) is much more supported and has a wider set of use cases.

In most cases it amounts to making sure you buy the right card & reader, plugging it in, and compiling the opensc and related packages

I may be on the edge but a "Trusted Platform Module" doesnt automatically let me conclude that indeed the hardware module is to be trusted.

It seems quite unlikely the masses would have access to a trusted platform of any kind, especially considering that any secure platforms for communication that have existed, like Skype, have been opened up. Even good old GSM (AS/1 was it called?) voice-talk encryption was designed with a backdoor in mind at the urging of NATO.

When I wrote that I definitely debated whether to include tpm in the list because of concerns along those lines. But in the end it's a widely deployed example of that type of technology which makes it a good example. It definitely wouldn't be my first choice in any case just due to the complexity of it - there is > 10k loc inside your typical tpm as i understand it. One thing to keep in mind though is that tpm is a spec/standard that's been implemented by several different vendors. They're the ones that write the code that goes inside as it was considered an implementation detail in the spec. So that means you can buy a german tpm (infineon) or a french tpm (stm) or a us tpm (intel, atmel?) and so on including taiwan and china. So you can sort of pick your poison, presumably they aren't exactly sharing their backdoors with each other at least not france+us+china.

Even assuming it's a compromised platform it's still a hell of a lot more likely to keep your key material safe as compared to having it sit on disk or in addressable address space. One presumes backdoors like that are used sparingly as they become considerably less valuable once publicly exposed.

Reply on news.ycombinator.com