0

I would like to protect the data on my backup system, in case it gets (physically) stolen. I would encrypt the hard drives where the data resides. Since the backup system typically acts non-interactive (wake-on-lan and rsync/ssh), I would like to avoid entering a password each time it gets booted.

What could be a suitable way to achieve this?

I think I would need to have a keyfile that unlocks the encrypted drive, which does not reside on the backup system itself (unless it is fully encrypted, with the same boot/password problem). Are there any common strategies for this?

I thought about having the keyfile stored on a 2nd machine on the local network that is running 24/7 (such as RaspberryPi), and is either fully encrypted or is standing in a different room. The backup system would mount the remote filesystem with the keyfile on it. Any drawbacks for this?

The other 'solution' I thought of would be to not fully shutdown the backup machine after copying data, but just suspend it - which requires just occasionally entering a password.

2
  • Are you running Windows? BitLocker supports this with auto-unlock drives, by storing the volume unlock key for the external drive on a local volume that uses BitLocker, e.g. your C drive. So when you boot, the BitLocker volume for your C drive is unlocked, and when you click on the external volume BitLocker automatically unlocks it for you.
    – Polynomial
    Commented Sep 13, 2021 at 12:23
  • I'm using Debian for the backup machine, and Arch and CentOS for the clients.
    – user236012
    Commented Sep 13, 2021 at 12:30

1 Answer 1

1

You can use a keyfile for LUKS.

First, create a file with strong random values using `openssl´:

openssl genrsa -out /path/to/keyfile 4096
chmod -v 0400 /path/to/keyfile
chown root:root /path/to/keyfile

Now we have /path/to/keyfile with 4096 bytes of random data, and only root can read it.

Now, add this keyfile to the device with luksAddKey:

cryptsetup luksAddKey /dev/sdx /path/to/keyfile

When you mount the device afterwards, pass the keyfile to it:

cryptsetup luksOpen /dev/sdx MyBackupDisk --key-file /path/to/keyfile
mount /dev/mapper/MyBackupDisk /mnt/backup

If you ever lose the keyfile, you can still mount it using the passphase.

Now, on how to store the keyfile.

If you keep the keyfile on the system, it can be stolen together with the system and thus being a not good method of unlocking the disk. You could store it offsite, on a remote NFS share, or use curl or wget to download it, mount the LUKS disk, and remove the keyfile afterwards. The file is only needed during the mount operation and not used anytime after that.

3
  • That sounds good for the first part of my issue. The second part would be where to store that keyfile. If it is stored on the backup system itself, the person who (physically) stole the system could unlock the encrypted data anyway, because he has the encrypted drives, and the keyfile.
    – user236012
    Commented Sep 13, 2021 at 14:06
  • You can store it on a NFS share, and umount the share afterwards.
    – ThoriumBR
    Commented Sep 13, 2021 at 14:40
  • Any drawbacks for this?
    – user236012
    Commented Sep 13, 2021 at 14:58

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .