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.

  • bacon_pdp@lemmy.world
    link
    fedilink
    English
    arrow-up
    7
    ·
    3 days ago

    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

  • noodNinja@sh.itjust.works
    link
    fedilink
    English
    arrow-up
    1
    ·
    2 days ago

    A dumbass question maybe - Is this what the “keys” category in Bitwarden is meant for? I always thought it was for SSH related keys. I don’t encrypt by backup HDD as I don’t really care but this is kind of a good idea.

  • irmadlad@lemmy.world
    link
    fedilink
    English
    arrow-up
    6
    ·
    3 days ago

    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.

  • istdaslol@feddit.org
    link
    fedilink
    English
    arrow-up
    1
    ·
    3 days ago

    Have you tried printing it out ? For a last ditch effort it’s actually good, as the physical attack vector isn’t that high for home users.

  • observantTrapezium@lemmy.ca
    link
    fedilink
    English
    arrow-up
    1
    ·
    3 days ago

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

  • IanTwenty@piefed.social
    link
    fedilink
    English
    arrow-up
    1
    arrow-down
    2
    ·
    3 days ago

    Don’t encrypt the drive, encrypt the backups and put your keepassdb alongside. Use restic or similar that encrypts backups.