These are brief notes on setting up an encrypted disk partition on Linux. I am no expert, so they could be wrong!

Threat model

We can use encryption in lots of different ways, but my needs are simple: if the machine gets stolen, I want it to be hard to read the user information on the drives. I also want it to be fairly easy to use the machine in normal operation.

The default installer

If you install Debian Buster, you get gieven the chance to encrypt the root partition automatically. This leaves /boot in the clear, but I don’t mind about that.

However, I do mind about other, non-root, partitions. The Debian installer doesn’t help here, so we’re on our own. Happily, it seems reasonably straightforward.

The basic instructions


As with all disk related projects, begin by partitioning the disk. We will use /dev/sda here, change this if it’s not appropriate:

$ sudo fdisk /dev/sda

Inside fdisk invoke these commands:

Set up the crypto

The cryptsetup1 command is a convenient way to manage encrypted volumes. Begin by using it to create an encrypted volume, and mount it in /dev/mapper2. You’ll need to provide a passphrase for the volume when you create it or want to access it.

$ sudo cryptsetup luksFormat /dev/sda1
$ sudo cryptsetup open /dev/sda1 foo

This leaves us with an encrypted block device at /dev/mapper/foo which is hosted by the underlying block device /dev/sda1. We can proceed as normal to set up a new file-system:

$ sudo mkfs.ext4 /dev/mapper/foo
$ sudo mkdir /bar
$ sudo mount /dev/mapper/foo /bar

At this point, the task is basically done: we have an encrypted file-system mounted on the system. However, if we left things here, every time we booted the system we’d need to enter two fiddly passphrases: one to unlock the root filing-system; the other to unlock the filing-system we’ve just created. That's a nuisance, and if we added more encrypted partitions, the problem would get worse.

Enable automounting

To mount the device automatically on boot, we need to fix a few things.

We begin by adding a second key to the encrypted volume, such that it can be unlocked by either the original key we used above, or this new key which we’ll use automatically. Since we don’t have to type the new key, we can make it long:

$ sudo dd if=/dev/urandom of=/root/.vol.key bs=1024 count=4
$ sudo chmod 0400 /root/.vol.key
$ sudo cryptsetup luksAddKey /dev/sda1 /root/.vol.key

You’ll see that the key is stored in the open in /root, which will typically be on an encrypted root volume. So once /root is mounted, anyone who can read it can access the information on this new drive. I am relaxed about that, but you might not be!

To use this new key at boot, we need to edit /etc/crypttab3. For me, that meant adding this line:

sda1_crypt UUID="...." /root/.vol.key luks,discard

Where UUID=".." gives the ID of the underlying block device. You can see these with blkid:

$ sudo blkid

If you reboot now, you’ll find that the new encrypted block device appears automatically at /dev/mapper/sda1_crypt.

All that remains is to ask Linux to mount the device just like any other filing system by editing /etc/fstab4:

$ sudo emacs /etc/fstab

I needed to add this:

/dev/mapper/sda1_crypt /data ext4 defaults 0 2

Final testing

All that remains is to reboot the system and check everything appears as it should:

$ sudo shutdown -r now

You might find lsblk gives you some comfort that things are as you intended:

$ lsblk 
sda                       8:0    0   1.8T  0 disk
└─sda1                    8:1    0   1.8T  0 part
  └─sda1_crypt          254:3    0   1.8T  0 crypt /data
nvme0n1                 259:0    0 931.5G  0 disk 
├─nvme0n1p1             259:1    0   512M  0 part  /boot/efi
├─nvme0n1p2             259:2    0   244M  0 part  /boot
└─nvme0n1p3             259:3    0 930.8G  0 part 
  └─nvme0n1p3_crypt     254:0    0 930.8G  0 crypt 
    ├─nucky1--vg-root   254:1    0 914.9G  0 lvm   /
    └─nucky1--vg-swap_1 254:2    0  15.9G  0 lvm   [SWAP]

Encrypting the root

As noted above, the Debian installer offers you the option of encrypting the root filing system on installation.

I don’t have much to say about that, but it leaves the machine in a state where you can only boot it by entering a long access key on the keyboard. Sometimes, that’s ideal, but I would prefer to unlock the machine remotely, so I can just paste the key.

To do this, we need to have a ssh server running before root is mounted, which leads us to the initial ramdisk filing system: initramfs.

Community wisdom is to use Dropbear5 as the ssh server, and happily these days the dropbear-initramfs6 package in Debian does most of the configuration.

I just followed a helpful article by thej6s7 which boils down to:

Although there are many other articles which discuss this topic, most of them seemed to be out-of-date.