"A public and private key each have a specific role when encrypting and decrypting documents. A public key may be thought of as an open safe. When a correspondent encrypts a document using a public key, that document is put in the safe, the safe shut, and the combination lock spun several times. The corresponding private key is the combination that can reopen the safe and retrieve the document. In other words, only the person who holds the private key can recover a document encrypted using the associated public key."
In a world where the US government is scanning all your electronic communications, and (we'll next discover) searching your OS X- and Windows-based computers at will, how do you, as a practical matter, keep your private key "private"?
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.
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
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.
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.
Only use your private key with Tinfoil Hat Linux on an offline air-gapped computer: http://tinfoilhat.shmoo.com/
I recommend disconnecting your monitor and only receiving output by having it blinked out at you through your capslock light on your keyboard. Bonus points if you can get your hands on some TEMPEST hardened hardware, and/or tamper-resistant hardware.
Anything less will leave you vulnerable to the black helicopters!
Note: I'm joking obviously, but this is something to take seriously.
The light reflected off your eyes from the capslock key is readable from high-res cameras. It's better to have leads hooked up to one of your toes and to toggle a 24V source so you can interpret the pulses in morse code.
Edit: obviously the 24V must come from a battery which is charged only at specific intervals -- otherwise they can interpret your messages by watching mains voltage variation.
Those leads are gonna generate magnetic distortions. You should only do this with your feet next to a giant 18" subwoofer while blasting dubstep in order to mask any electromagnetic fluctuations.
Bonus: Anyone surveilling you via audio bugs will need new ears.
I know this is all in good fun, but you all are uncomfortably close to describing things that will soon get added to the practical threat landscape.
As long as you have a flexible hardware platform that lets you crank up some of the voltage regulator outputs, gpios that can be attached to a long trace/external wire as a makeshift antenna and have a decently fast cpu clock you have all the ingredients for a crude but usable software defined radio. maybe not super fast if you can't repurpose a hardware phy or radio interface, but more than enough bandwidth to exfil a secret key or 10 for maybe a couple dozen meters.
Tools to do sdr utilizing only general purpose processors and no radio specific gear are already available here and there as research implementations, and code that uses gpus/audio dacs/ and re-purposed phys to make a radio interface with a different spec or broadcast frequency is already in production use (wifi phy using a dvb radio interface -> tv whitespace communicator).
Using an approach like that to exfil or bridge an air gap is just too tempting for it to not happen. Honestly, I'd be willing to bet there's already an example of that somewhere out there in the wild today.
Paranoid thinking is an extremely valuable asset for security researchers. The things we're all joking about are impractical for an average person, but in a spy vs. spy scenario, especially when each side is well funded, these are the kind of things that will actually get used.
Examples of genuine vulnerabilities that would make you look paranoid just by defending against:
* Make educated guesses about passwords from a microphone recording of the keypresses. Both the intervals between keypresses indicate the region of the keyboard being touched, and the sound of each key differs slightly. Given a statistically significant sample of typing, you could deduce which keys are which based on the frequency of their use. http://www.securityfocus.com/news/11318
Well, if you can do that (program a computer via a blinking keyboard LED in Morse code to avoid Van Eck phreaking,) you're well on your way to discovering the lost Nazi gold in the Philippines.
Keep it public, but use a very good passphrase. That's not impossible to do.
I'm not a crypto type but I believe what you want is a password-based key derivation function such as scrypt, the output of which you can then use as the symmetric key to encrypt/decrypt the private key. (This might even be what GPG/SSH does for you; I'm not at all sure)
"A public and private key each have a specific role when encrypting and decrypting documents. A public key may be thought of as an open safe. When a correspondent encrypts a document using a public key, that document is put in the safe, the safe shut, and the combination lock spun several times. The corresponding private key is the combination that can reopen the safe and retrieve the document. In other words, only the person who holds the private key can recover a document encrypted using the associated public key."