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?

Comments

printed/scanned versions are fine

[Anonymous Coward]

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...

Re:printed/scanned versions are fine

[Z00L00K]

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.

Re:printed/scanned versions are fine

[arglebargle_xiv]

I have another approach, I simply never have an original or interesting thought, ever. Because of that there's nothing to keep secret, so I don't need any encryption keys.

Oh, I'm head of programming for a major US network, in case you were curious.

QR Code?

[Anonymous Coward]

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

Re:QR Code?

[RabidReindeer]

The first thing to bear in mind is that the keyfile doesn't have to be stored on anything more durable than whatever the backup files are on.

Personally, if it's important, I back up to multiple media anyway on the assumption that a fire, flash flood and massive EMP/magnetic anomaly won't all be hitting me at the same time. I also copy the important stuff to fresh media occasionally. Which is why I still have files that started life on 8-inch floppy disks.

So for me, a thumb drive for key files isn't such a bad idea.

Now if you want to chisel QR codes with 3-inch high pixels into granite slabs and bury them under 30 feet of sand just as a precaution, I won't stop you...

Re:QR Code?

[bhspencer]

I tried storing a key file in a QR code and my experience was that once you get above 800 characters none of the QR code parsers can reliably parse the data out of the code.

Re:QR Code?

[Junta]

Yes, I've never seen a QR code have a problem scanning in from even pretty crappy photos.

However, I'd probably store the actual keys and encrypt them as usual, using the QR code to only store the key that decrypts the key (which can be 20 printable characters and still be damn near impossible to crack, requiring on average 20 billion millienia even if you could brute force a quadrillion guesses a second).

QR Codes w/wo Shamir Secret Sharing

[Ronin Developer]

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.

Re:QR Codes w/wo Shamir Secret Sharing

[Anonymous Coward]

QR codes would probalby work well for Curve25519 keys, but when I looked at generating QR-codes from the output of paperkey with a normal GNUPG RSA key they were way too large to be practical.

I recommend Shamir Secret Sharing, though. Pick N friends, preferably who don't know each other that well and keep good backups, pick some K N, and hand out your shares to your friends. Offer to keep a share of their keys, too, if they want. The upside is that you only have to prove to people who know you well that you are yourself. (Something that people who aren't you would, ideally, not be so good at.)

Re:QR Codes w/wo Shamir Secret Sharing

[pdbogen]

A variant of this would be to use shamir's secret sharing to back up shards of your key in places you trust. Back it up one share in each of ten places with 5 share threshold; 5 have to get compromised before your secrets are lost, and if you hear about one getting compromised you can rekey for the other 9.

Re:QR Codes w/wo Shamir Secret Sharing

[Anonymous Coward]

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.

There should be a federal registry

[Anonymous Coward]

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.

Re:There should be a federal registry

[qeveren]

"a secure backup maintained by the government"

It's mean of you to make coffee shoot out of my nose like that, you know.

Optical Disk

[gurps_npc]

Is the way to go.

The fact that fewer and fewer people use them simply increases your security.

If and when you replace your PC with a device that doesn't have an optical drive, then the last thing you do with your old PC is to copy the data from the disks to something new.

Till then, the fading popularity of DVDs is just an added layer of security for you.

Re:Optical Disk

[Aighearach]

Optical disks have horrible shelf life. They degrade over time. They are not suitable for important backups. Magnetic tapes OTOH can be purchased in archival quality.

Plastics often take a long time to fully decompose, but their optical properties degrade rapidly.

That's leaving aside the "obscurity" flamebait. ;)

Use a passphrase

[mangobrain]

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).

Re: Best thing to do

[Anonymous Coward]

Saying this isn't any better than saying "if you've done nothing wrong, you've got nothing to hide."

You use encryption to protect your privacy from a US government that no longer understands what the 4th amendment is.

As for backups, you can backup your private key with a password and throw it on a couple USB drives stored in different locations. I've printed out my encrypted RSA key. Elliptic curve keys are small enough that you can usually print them out with QR codes (even after encrypted).

Failing figuring out how to encrypt your key for every random program, I would just throw them all in veracrypt, and then again, few different USB drives, ideally not stored in the same place. Check on them every six months or a year or so.

Re:Fuck, is this really so hard?

[Striek]

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.

Some best practices

[h4ck7h3p14n37]

Keep one copy in a safe in a tamper evident container. Either hardcopy or something like a read-only SD card or USB thumb drive will work. Routinely open the safe and verify that the key container hasn't been compromised.

Distribute copies to trusted parties in tamper evident containers. You can also split the key up into multiple pieces and distribute different pieces to different people. Don't let anyone know who else has copies. You will also need to routinely visit these trusted parties and confirm that they have not tampered with the key container.

Be sure to protect your private key with a wrapping passphrase if supported, otherwise use encrypted media. You should also specify a reasonable expiration date for your key and use the appropriate revocation mechanism, e.g. CRLs for x509 certs and revocation certificates for PGP. You shouldn't be too worried about the longevity of your storage media since you should be periodically updating your keys. I would recommend against media with photosensitive dyes and go with the more robust M-Disc based discs.

If at all possible, do not ever let your private key touch a networked/unsecure device. Use a hardware based key manager if possible, e.g. Yubikey. Keep a separate machine booted from read-only media for the sole purpose of key creation in a secured location. You can also use this machine for encryption/decryption, but you need to transfer data via sneakernet. Definitely don't keep a WiFi card or even an audio output device in the machine. Do all of your work inside a Faraday Cage if possible.

Read up on guidance from the various organizations. E.G. NIST's Computer Security Resource Center

Stuff

[Sax Russell 5449D29A]

Get a safety deposit box from a bank, put the key there as an ASCII armored plaintext paper and as a QR code printed on paper. And remember to use quality paper and a laser printer. The only ones who could get access to the key would be robbers and government officials with warrants.

Re:Just FYI

[gweihir]

In a police-state, that is everybody.

Key Files

[sexconker]

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.

Re:Key Files

[the_skywise]

The problem is death. :)

I keep a mnemonic around in my phone because I've got nearly 100 accounts online for various things - but I know what the password is from that and, even then, I can usually cycle through any variations to get to the one it was.

But how do you pass that info along to family members... especially ones like mine who are not tech savvy!!!

Paper in a lockbox!

Re:Key Files

[Sowelu]

Memorizing a key is a pretty bad solution. I'm way more afraid of brain damage than I am of fire/flood/tornado. A large part of my old documents are stuff I should remember and not need anyway--unless I need to get my life back in order after brain damage, dementia, Alzheimer's, etc.

Keepass

[Anonymous Coward]

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.

Yubikey

[darkain]

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.