Linux supports encrypted volumes with luks. When a luks encrypted volume is set up during installation to be booted from, the volume is already configured and set up. When an encrypted volume is set up afterwards, the volume remains locked until the volume is first accessed from the GUI file manager or is mounted manually.
Such a volume as described in Created luks encrypted partition on Linux Mint is not directly available during or after system startup. To mount an encrypted volume during system startup, a key needs to be available to the system to unlock and mount the volume. Usually this key is a password entered while creating the encrypted partition.
Create a key to unlock the volume
Luks encryption supports multiple keys. These keys can be passwords entered interactively or key files passed as an argument while unlocking the encrypted partition.
The following command will generate a file with 4 KB of random data to be used as a key to unlock the encrypted volume.
$ dd if=/dev/urandom of=/etc/luks-keys/disk_secret_key bs=512 count=8
With the following command the created key file is added as a key to the luks encrypted volume. The /dev/sdb1 should be replaced by the encrypted partition already set up as described in Created luks encrypted partition on Linux Mint.
$ sudo cryptsetup -v luksAddKey /dev/sdb1 /etc/luks-keys/disk_secret_key Enter any passphrase: passphrase Key slot 0 unlocked. Command successful.
Adding an additional key to the encrypted volume requires the user to enter one of the already assigned keys or passphrases. The output (-v for verbose) shows that the passphrase for slot 0 was entered.
Using the “luksDump” action, the details of the encrypted volume can be shown. What’s interesting at this point are the assigned keys. The 7 key slots of the encrypted volume are shown together with other information. A quick “grep” shows the key slots. At the beginning only one key is assigned in key slot 0. Now, key slot 1 is also used with the keyfile we just created.
$ sudo cryptsetup luksDump /dev/sdb1 | grep "Key Slot" Key Slot 0: ENABLED Key Slot 1: ENABLED Key Slot 2: DISABLED Key Slot 3: DISABLED Key Slot 4: DISABLED Key Slot 5: DISABLED Key Slot 6: DISABLED Key Slot 7: DISABLED
To verify that the key is working, the following command can be executed manually. This command instructs the cryptsetup command to open the luks volume (action “luksOpen”) on the device “/dev/sdb1” and map it as sdb1_crypt. The option at the end (–key-file=…) specifies the key file created and added in the previous steps.
$ sudo cryptsetup -v luksOpen /dev/sdb1 sdb1_crypt --key-file=/etc/luks-keys/disk_secret_key Key slot 1 unlocked. Command successful.
The success message indicates that the key file was successfully added and is working. To close the encrypted volume again, the “luksClose” action can be executed.
$ sudo cryptsetup -v luksClose sdb1_crypt Command successful.
Automatically open the encrypted volume
With the possibility to mount the volume without user interaction, the volume can be mounted on system startup. The Linux operating system provides the “/etc/crypttab” file to open encrypted volumes automatically.
To configure the encrypted volume in crypttab, the UUID (the unique identifier) of the volume is needed. This identifier can be retrieved again with the “luksDump” action. This time the output is filtered for “UUID” via grep.
$ sudo cryptsetup luksDump /dev/sdb1 | grep "UUID" UUID: 2a2375bf-2262-413c-a6a8-fbeb14659c85
Using the UUID and the key file name, the volume can be added to the crypttab. Edit the /etc/crypttab configuration file and add the encrypted volume in the following format.
sdb1_crypt UUID=2a2375bf-2262-413c-a6a8-fbeb14659c85 /etc/luks-keys/disk_secret_key luks
The first field is the mapping name for the opened volume. This mapping name will be found under “/dev/mapper/…” and will be used later on for mounting the volume.
Second field is the UUID as shown in the liksDump output.
With the third field the key file with absolute path is provided.
The fourth field contains additional cryptsetup options. In this case the option “luks” as described in the cryptsetup man page encrypted volume.
After adding the encrypted volume to the crypttab, it might look like this on a system with an already encrypted root (sda5_crypt) partition.
$ sudo cat /etc/crypttab sda5_crypt UUID=594f01cd-bfe1-400b-8af3-f770af9317b2 none luks,discard sdb1_crypt UUID=2a2375bf-2262-413c-a6a8-fbeb14659c85 /etc/luks-keys/disk_secret_key luks
To verify the configuration, the following command can be executed to test the configuration. This command will execute the configured crypttab entry identified by the mapping name “sdb1_crypt”.
$ sudo cryptdisks_start sdb1_crypt * Starting crypto disk... * sdb1_crypt (starting).. * sdb1_crypt (started)... [ OK ]
At this point, the encrypted volume can be opened automatically using the assigned key file but the opened luks volume is not yet mounted.
Automatically mount the encrypted volume
Mounting the opened luks volume does not take place in the crypttab but in the /etc/fstab file as it does with any other volume. At this point the mapping name is used to address the open luks volume.
Edit the /etc/fstab file using the editor of your choice and add a line similar to the following to the fstab file.
/dev/mapper/sdb1_crypt /media/gerhard/Daten ext4 defaults 0 2
The first field is the mapping name of the opened luks volume. It has to be provided with an absolute path.
Second field is the mount point where the volume should be mounted.
In the Third field is the filesystem type. The example assumes a ext4 filesystem was created in the encrypted volume.
The fourth field lists the mount options where in the example the “default” options are used.
On the last two fieldsare the reference to the filesystem dump (fifth field) and the filesystem check order (sixth field). Details about these parameters can be found in the fstab(5) man page.
As usual, verify the configuration by restarting the operating system. Whereas before the volume was not automatically mounted, this time the encrypted volume should be mounted and ready to use as soon as the system is started.
Read more of my posts on my blog at https://blog.tinned-software.net/.