Slashdot Mirror
Ask Slashdot: How To Keep Keyfiles Secure, But Still Accessible?
New submitter castionsosa writes: With various utilities like borgbackup, NetBackup, zbackup, and others, one uses a keyfile on the client as the way to encrypt and decrypt data. Similar with PGP, GnuPG, and other OpenPGP utilities for the private keys. However, there is a balance between security (keeping the keyfile in as few places as possible) and recoverability (keeping many copies of it). Go too far one way, and one will be unable to restore after a disaster. Go far the other way, and the encryption can wind up compromised.
I have looked at a few methods. PaperBack (which allows one to print a binary file, then scan it) gives mixed results, and if there is any non-trivial misalignment, it won't retrieve. Printing a uuencoded version out is doable, but there would be issues for scanning, or worse retyping. There is obviously media storage (USB flash drive, CD-ROM), but flash isn't an archival grade medium, and optical drives are getting rarer as time goes on. Of course, stashing a keyfile in the cloud isn't a wise idea, because once one loses physical control of the medium the file is stored on, one can't be sure where it can end up, and encrypting it just means another key (be it a passphrase or another keyfile) is stored somewhere else. I settled upon having a physical folder in a few locations which contains a USB flash drive, CD-R, and a printed copy, but I'm sure there is a better way to do this.
Has anyone else run into this, either for personal recoverability of encrypted data, or for a company? Any suggestions for striking a balance between being able to access keyfiles after disasters of various sizes (ransomware, fire, tornado, hurricane) while keeping them out of the wrong hands?
I have looked at a few methods. PaperBack (which allows one to print a binary file, then scan it) gives mixed results, and if there is any non-trivial misalignment, it won't retrieve. Printing a uuencoded version out is doable, but there would be issues for scanning, or worse retyping. There is obviously media storage (USB flash drive, CD-ROM), but flash isn't an archival grade medium, and optical drives are getting rarer as time goes on. Of course, stashing a keyfile in the cloud isn't a wise idea, because once one loses physical control of the medium the file is stored on, one can't be sure where it can end up, and encrypting it just means another key (be it a passphrase or another keyfile) is stored somewhere else. I settled upon having a physical folder in a few locations which contains a USB flash drive, CD-R, and a printed copy, but I'm sure there is a better way to do this.
Has anyone else run into this, either for personal recoverability of encrypted data, or for a company? Any suggestions for striking a balance between being able to access keyfiles after disasters of various sizes (ransomware, fire, tornado, hurricane) while keeping them out of the wrong hands?
I don't know why you think that scanning things is going to be hard, OCR works very well these days, especially if you use a font like OCR-A which is intended for scanning. You can also print out a checksum of the key if you'd like as well. Or you could use some QR code variant to store the key too. Storing digital data on paper is mostly a solved problem these days.
Then again, it doesn't sound like you actually want any solutions, you just want to rule all of them out...
How big are these keyfiles? QR codes can encode up to 4,296 characters, and have alignment-assisting and error-correcting features built in.
https://en.wikipedia.org/wiki/QR_code
Why not print the encrypted key as a QR Code?
Similarly, you could use Shamir Secret Sharing with a theshold to break the key up into N shares which could be provided to people you trust. Then, your (or those you designate - include law enforcement) could recover the keys provided they have the threshold number of shares.
Maybe when burning such info into a crystal becomes cheaper and feasible for the common person, it could be burned into one for all posterity.
There should be a federal registry for keyfiles. That way, in the event of having a warrant and needing to conduct a search, law enforcement readily has access to the keyfile. You benefit from this because there's a secure backup maintained by the government rather than a business that can change the services they provide, be sold, or cease to operate. A federal registry is a great solution to these problems.
Simple: require a passphrase to access the private keys, then back then up like any other file. PGP utilities allow this, and it should suffice for anything interactive.
For anything non-interactive, it may be still be possible to use a passphrase if there is a way to load the passphrase from disk (rather then keyboard); keep the files containing passphrases as private as they keys themselves, but just recreate them if they're lost. *Something* along the line has to be committed to human memory, otherwise you fall foul to the cryptographic equivalent of the "analogue hole" (I.e. if everything needed to decrypt the data is available without human intervention, an attacker just needs that data, they don't need you).
Mod parent up.
Yes - USB drives are not archival quality storage. But no - they're not expensive. I have several dozen el cheapo flash drives in my desk drawer, most of which were freebies. Just back up on to a cheap storage medium multiple times. If you're so worried that a flash drive won't survive until you need it (Protip: it will, for about 10 years. Then just rewrite it and you're good for another ten years. They wear out from use, not electrical charge leakage.), then make 10 backups. I'd bet my big toe that at least one of them will survive a couple of generations. Keep one or two passphrase encrypted copies online somewhere (not necessarily cloud storage - online meaning you don't need to fetch a thumb drive for it), and you've got a good compromise. For corporate use, just use a safety deposit box with a few thumbdrives and reflash them once a year. That's simple, effective, and secure enough for most applications.
What do I do? I keep my KeePass database (which contains many encryption keys) on a cloud storage provider. The combination of passphrase and keyfile encryption is good enough for me, and strikes the balance I need between ease of use, accessibility, and security.
You're overanalyzing. This is a solved problem. Make multiple backups, some offline, and store them in a secure location, e.g. the parent's suggestion of a safety deposit box.
"Government is like fire; a handy servant, but a dangerous master." -- George Washington
Key files, certs, etc. are all convoluted versions of the same thing - a secret.
Your question is really: "How do I keep my secrets secure?"
The answer is, as always: "Memorize them."
If your secrets are too complex or too numerous to memorize, you will need to write them down.
Because you're not an idiot, you write them down encrypted, and memorize that key so you can decrypt it later. This key is your secret.
If you're doing it correctly, you won't care where you store the encrypted secrets, because the security requirement is effectively binary. If you have security set to "on" because you used strong encryption, then you can turn accessibility to over 9000.
Throw your password database on a public FTP and let the world have it. You'll be long dead before the encryption is cracked.
If you're paranoid and you think usable quantum computers are really 5-10 years away, or that every encryption algorithm is flawed and backdoored, then you need to rely on hiding as well to turn security on. Put your shit on a micro SD card and hide it. Or, hide your shit by embedding it into innocuous data (digital or physical) steganographically. Or both. Or you could roll your own crypto on top of an established crypto.
In my organization, we've switched over to using Yubikeys for handling our private key storage. Our primary use case is SSH keys for remote terminals and git repositories, but there is no reason why it couldn't be used for other secure encryption methods too.