I’m planning to setup backup on my nas with the 3-2-1 backup rule.
For the backup disks I want full disk encryption, but I also want to be really sure that I don’t lose the encryption keys if I lose my phone and computer where I have my password manager.
What is a good practice to store the encryption key(s)?
One thought I had was to have an unencrypted partition on the backup disks that stores an encrypted keepass database with the key.
Any tips or experiences are welcome.
PS. I want to avoid cloud-based options.
You must log in or register to comment.
I don’t do full disk encryption on my backups. I use duplicity and encrypt the backups with three gpg keys: one that is for the IT department with a known passphrase, one for the business with a different known passphrase, and my personal key.
I’m a one man show but I set this up with the future in mind. Different data might not have all three keys, but this arrangement allows me to spin off bits of the data management as needed. The passphrases can be changed as/when needed without invalidating old backups.
Combined with ssh certificates it helps organize my IT needs.
Buy a physical safe. Encrypt a flash drive using a 128bit pass phrase that you memorize.
Combine with a ubikey storing a 256bit password that is stored somewhere hard to get to
Write in on a post-it/piece of paper you keep near your PC
If you’re using LUKS don’t forget you can dump/backup the header. It isn’t the encryption key but is critical if you accidentally do a stupid. As to the keys themselves, how about convert them to qr codes, print them, and store them in a safe.
convert them to qr codes,
Never crossed my mind, but that’s a good idea. Might have to implement that on my next rotation.
This is smart.
I also want to be really sure that I don’t lose the encryption keys if I lose my phone and computer where I have my password manager.
Keep a copy on your (PIN-secured) phone and a copy on your PC and dont lose both at the same time.
A chain is as strong as its weakest link. If you store your encryption keys in plain text in an unencrypted partition you are not very resilient against an attack.
There is no general advise for security, you always have to frame it in a treat model. What do you use encryption to protect for?
If you want to be able to safely dispose the drives without having to wipe them, storing the keys in a different drive (not partition) could be good. If you want to protect your data against physical thief, storing the decryption keys in plain text in the same server doesn’t make sense.
If you want to protect by a state sponsored actor, keep in mind https://xkcd.com/538/
Something you have to consider is how likely your drives and your encryption keys can be stolen together. How quickly you can realize that only one of them got stolen, and how quickly you can protect the other one to keep you data safe.
A simple approach could be: print them down and put them in a safe box, maybe at a trusted relative or friend’s home. But again, it boils down to what do you want to protect most, because there is no definitive answer to your question
Also, keep in mind that really good passwords can be easy to remember or recover. Pick your favourite book at home, get the last word of the first 10 chapters and put all of them together. You get a password that is impossible to bruteforce, literally written in your home but impossible to guess for anyone else but you. Of course it won’t be easy to type. But is still a good main password for a password manager which stores all the others.
Personally I don’t go with full disk encryption for backups. I use Borg that encrypts its repositories on a plain ext4 partition, and the key is saved in the config file (wrapped in passphrase of course). Obviously it just moved the problem of what to do with the passphrase… I also have Vaultwarden (with a separate backup mechanism).
For the backup disks I want full disk encryption
I encrypt everything.
I have a repository set up with all my keys for all my encrypted drives. The keys get rar’d with a strong, known, 50 character password, and the filenames encrypted so no one can just open the rar file and gaze at the keys.
- drive_xxxxx1_2_14_26.rar
- drive_xxxxx2_2_14_26.rar
- drive_xxxxx3_2_14_26.rar
These get backed up in a 3,2,1 schema, and also to thumb drives stored in secure places. I also rotate the passwords on a regular basis, so the process starts all over again.
- Check keys:
sudo cryptsetup luksDump /dev/sdX - Add new key:
sudo cryptsetup luksAddKey /dev/sdX - Delete old key:
sudo cryptsetup luksRemoveKey /dev/sdX - Verify keys:
sudo cryptsetup luksDump /dev/sdX
The headers are not secret. Anyone with physical, read access to the device can run
luksDump. It reveals algorithm, key derivation parameters, number of keys, but not the passphrase or master key.As far as ‘best practice’, that will be determined by subsequent replies to your post. LOL That’s just how I do it.
You can dettach your headers with
--header.I’ve started putting the header and key on my boot partition on a USB key. Without the usb, the hard drives appear to be filled only with random data (plausible deniability). After booting, the USB can be removed to prepare for a panic shutdown.
You can dettach your headers with --header.
I did not know this. That would seem, abiding by your system, to be more secure. I will have to investigate.
Thanks for sharing.
Don’t encrypt the drive, encrypt the backups and put your keepassdb alongside. Use restic or similar that encrypts backups.
