Linux Unified Key Setup (LUKS) is a method for encrypting + block devices that is built-in to the Linux Kernel. In this tutorial + I will be showing how to create an encrypted USB drive with LUKS, but + this process is applicable to other types of storage. + This process will wipe all data on the device that you + encrypt so make backups beforehand if needed.

+ +

Install Packages

Install cryptsetup and its dependencies

+ +

apt install cryptsetup

+ +

Prepare the Drive

If the device you are encrypting was previously used, you will + want to completely overwrite any data on it before encryption. This + can be done using dd as shown below. This could take + a very long time depending on the size and type of your drive. + Be sure that you enter the correct path to your drive as the + argument to of, and do not specify a partition: + /dev/sdb is correct, /dev/sdb1 is + wrong. Obviously this will destroy any data on the device so be + absolutely sure you specify the correct device in the command + and have backups of data previously stored if needed.

+ +

dd if=/dev/zero of=/dev/sdX status=progress

+ +

Encrypt the Drive

cryptsetup is the main command used to perform + LUKS-related tasks. This main command is followed by a subcommand + that specifies which action to perform. To create a LUKS partition + on a drive we need to use the subcommand luksFormat. + We also use the type option to explicitly say to use LUKS version 2 + encryption. Run the command and then enter and confirm the + encryption password.

+ +

cryptsetup --type luks2 luksFormat /dev/sdX

+ +

Now we need to open and map the encrypted LUKS device. This is done + by using the luksOpen subcommand. This subcommand takes + the device as the first argument and then a map target as the second. The + map target can be any string as long as a map does not already exist with + that name. In the example I will use crypt. + +

cryptsetup luksOpen /dev/sdX crypt

+ +

And then we just need to create a filesystem on the device; I will + be making an ext4 filesystem in the example. To + interact with an encrypted drive after it has been opened you need + to refer to its device mapper target, which is found under /dev/mapper. + Since we used crypt as the map target, our encrypted drive + is /dev/mapper/crypt.

+ +

mkfs.ext4 /dev/mapper/crypt

+ +

After creating the filesystem created the encrypted drive + can now be mounted and used like any other device. Remember that + when mounting the device you refer to the device mapper target + (mount /dev/mapper/crypt /mnt/crypt).

+ +

In addition to unmounting the filesystem you should always close + the device mapping before removing your encrypted drive. This is + done with the luksClose subcommand and takes + the device mapping as the argument.

+ +

cryptsetup luksClose /dev/mapper/crypt

+ +

The LUKS Header

The LUKS header sits at the front of your encrypted drive and is + responsible for managing access to the device. If the header is + damaged accessing your encrypted data will not be possible. Because of + this, you may want to make backups of the header, but before doing so + you need to weigh the risks and benefits.

+ +

The obvious benefit is that + in the event of damage to the LUKS header, you can easily restore a + backup and regain access to the data. However, having a backup of the + header makes it harder to wipe the LUKS device. Without a header + backup, overwriting the LUKS header on the device is enough to securely + wipe the drive. With backups, you need to either destroy all header + backups or overwrite all encrypted data on the device. The other main risk + is that an encryption password that is valid at the time you make a + backup will always be valid for that backup. For example, say you change + the encryption password on your device after making a backup because it + has been compromised. An attacker would be able to restore the header + backup and then use the compromised password to access the data.

+ +

The cryptsetup documentation refers to creating header backups + as making a trade-off between safety and security. You need to make a + decision based on your individual use-case. It's a good idea to + routinely update your header backups if you do choose to make them

+ +

When creating or restoring a header backup you always refer to the + block device in the command, not the device mapper taget. To create + a header backup:

+ +

cryptsetup luksHeaderBackup /dev/sdX --header-backup-file path/to/backup

+ +

To restore a header from a backup:

+ +

cryptsetup luksHeaderRestore /dev/sdX --header-backup-file path/to/backup

+ +

Note that is not necessary to store header backups on an encrypted + device. I would recommend storing backups on at least one non-encrypted + drive in case of an emergency.

+ +