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?
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
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).
I store my keyfiles in Keepass, where I can use them with hotkeys. My keypass syncs to all my devices (and my wife's devices in case I die) and I just need to know the master key to my container database which contains the keyfile to my real database, which is in my head and nonlinguistic and nowhere else. (actually it's not even in my head - it's in my fingers' muscle memory).
You can put the master and recovery instructions into a QR - but where are you going to hide that and protect it?
My wife has her own key which opens here keypass database, which has the key to my personal database.
My wife's database opens my personal, and my master database open's hers and my work databases. and yes my gaming passwords that my wife doesn't care for are in another database she doesn't care about.
As a keyfile - use a text that is present in many copies over the internet. Only you know the actual text and length of it to be used as a key. That way you will never actually lose your key.
If builders built buildings the way programmers wrote programs, then the first woodpecker would destroy civilization.
With respect to the lifetime of USB flash drive and CD-ROM media for key backup, your key should change more often than those items fail. That is, a typical CD-R or flash device can provide reliable storage on a shelf for about 10 years with good storage conditions.
In six years, computing will be much more powerful and a dedicated hacker would be able to break the encryption in 3 years of brute force attack. So if you kept your key for 10 years, you may already be compromised anyway. Microsoft actually ran into this problem with Windows XP. This was evidenced by the Flame malware which was able to spread more easily because it looked like a legitimately signed Microsoft product. That is just one example (and not the only one).
You should have key management policies that cycle your keys. The frequency of this cycling depends upon your own risk analysis. You may cycle the keys every time an employee with access to the key leaves, for example. You might have a policy for a maximum lifetime for the key (popular time frames are 5 years, 3 years, or 1 year). Let's Encrypt is recommending quarterly. Thus an unknown key compromise will have a finite time to take advantage of that knowledge. Combined with other defenses (such as penetrating normal network boundary defenses), an attacker may not have the time to take advantage of the key before a new one is deployed.
With that in mind, CD or thumb drive are viable again.