Revision as of 22:15, 7 August 2013

This article focuses on system disk encryption using plain dm-crypt without LUKS.

dm-crypt is the standard device-mapper encryption functionality provided by the Linux kernel. It can be used directly by those who like to have full control over all aspects of partition and key management.

Plain dm-crypt vs LUKS format

For most use cases, dm-crypt with LUKS is by far the better option for both system encryption and encrypted partitions. Below are some considerations for choosing one over the other.

Advantages

dm-crypt does not require a header on the encrypted disk. This means that an unpartitioned, encrypted disk will be indistinguishable from a disk filled with random data. This may be useful in a country that can force you to give up an encryption key where a reasonable suspicion of encrypted data exists.

plain dm-crypt encrypted disks are more resilient to damage than LUKS encrypted disks, because of the one-to-one mapping of unencrypted data to encrypted data.

Disadvantages

dm-crypt does not allow multiple pass-phrases, nor does it allow changes to the pass-phase or key-file after initial set-up. LUKS allows for up to eight passphrases, and key-files and passphrases can be changed without having to re-encrypt the entire disk or partition.

plain dm-crypt requires manual configuration of encryption options each time a device is opened, whereas LUKS stores those details in its header.

LUKS uses pass-phrase salting and hash iteration, and as such can be more secure than plain dm-crypt. It is essential that a pass-phrase or key-file with very high entropy is used with dm-crypt.

Encrypting system partitions

A separate /boot partition is required, as it needs to remain unencrypted to be accessed by the bootloader. In the scenario that follows, it is assumed that no evidence of encryption is to be left on the main system drive, and so we install the /boot partition and the bootloader to a separate USB stick, and the encryption key to yet another USB stick. Throughout the guide, the system disk will be shown as /dev/sdX, the USB stick containing /boot will be shown as /dev/sdY, and the USB stick containing the encryption key will be shown as /dev/sdZ, where X, Y and Z represent their respective device letters.

Tip: The essential process of filling an encrypted drive can take over a day to complete on a multi-terrabyte disk. It is therefore suggested that the following steps, up until #Mount the partitions, be done from another installation rather than the Arch installation media.

Preparation

Safety first

We must first make absolutely sure we are targeting the correct disk:

# fdisk -l

Load the kernel module

# modprobe dm-crypt

Setup encryption

Cryptsetup is used to create the mapping between an encrypted disk and a named device. Its form in this case is:

# cryptsetup <options> --open --type plain <device> <name>

Options

Option

Description

Examples

Default

--hash

The hash is used to create the key from the passphrase or keyfile

whirlpool, sha1, sha256, sha512, ripemd160

ripemd160

--cipher

The cipher consists of three parts: cipher-chainmode-IV generator. Please see Wikipedia:Disk encryption theory for an explanation of these settings, and DMCrypt for some of the options available.

aes-xts-plain64, twofish-cbc-essiv:sha256, serpent-cbc-plain

aes-cbc-essiv:sha256

--key-size

The key size (in bits). The size will depend on the cipher being used and also the chainmode in use. Xts mode will require twice the key size of cbc, which should be apparent from the output of cryptsetup benchmark.

128, 256, 512

256bits

--offset

The offset from the beginning of the target disk from which to start the mapping

Offset from the beginning of the key file (in bytes) from which to read.

2049

0

--keyfile-size

Limits the bytes read from the key file. However, I've found that this is ignored when using plain dm-crypt. Instead, the size will depend on the key-size used.

512B

8192kB

Dm-crypt does not need a partition table and the existence of one could provide a reasonable suspicion that the drive is encrypted. We therefore set up the encryption directly on the physical disk. If a partition table already exists on the target disk, it will be wiped when we later fill the disk.

Example with default options

Using default options with the device /dev/sdX and using enc for the mapped name, we have:

Unlike encrypting with LUKS, the above command must be executed in full whenever the mapping needs to be re-established, so it is important to remember the cipher, hash and key file details.
We can now check that the mapping has been made:

# fdisk -l

An entry should now exist for /dev/mapper/enc.

Fill the mapped device

Note: It is vital that the mapped device is filled with data. Without doing so, the encrypted data that is written to disk will be easily distinguishable from areas not yet written to.

Warning: The following operation will destroy all data on the underlying physical disk.

In this case, with /dev/mapper/enc, we use:

# dd if=/dev/zero of=/dev/mapper/enc

or

# cat /dev/zero > /dev/mapper/enc

Use of /dev/urandom is not required here, as anything written to the mapped device is passed through the encryption cipher before being written to disk.

When the process is finished, you may wish to check to see if any existing partition table has been wiped:

# fdisk -l

Note: The partition table will only have been wiped if the offset was set to 0. As a side effect of this, the disk will no longer be addressable by UUID, however it can still be addressed by physical ID (/dev/disk/by-id).

Install the system

Much of the following steps are identical to those in the Installation Guide. Where they differ is:

the target installation device is the mapped device under /dev/mapper/* instead of the physical device /dev/sdX;

/boot and the bootloader will be installed to a USB stick;

the initramfs hook encrypt is added to mkinitcpio.conf;

the details of the encryption are added to the kernel options in the bootloader.

For the remainder of this guide we will use the simple LVM volume set created above, which will have created the volumes /dev/store/root, /dev/store/home and /dev/store/swap. The choice of volume group name and logical volume names is arbitrary.