Revision as of 22:09, 25 March 2014

The following are examples of common scenarios of full system encryption with dm-crypt. They explain all the adaptations that need to be done to the normal installation procedure. All the necessary tools are on the installation image.

Overview

Securing a root filesystem is where dm-crypt excels, feature and performance-wise. When a system's root filesystem is on a dm-crypt device, nearly every file on the system is encrypted. Unlike selectively encrypting non-root filesystems, an encrypted root filesystem can conceal information such as which programs are installed, the usernames of all user accounts, and common data-leakage vectors such as mlocate and /var/log/. Furthermore, an encrypted root filesystem makes tampering with the system far more difficult, as everything except the boot loader and kernel is encrypted.

All scenarios illustrated in the following share these advantages, other pros and cons differentiating them are summarized below:

While all above scenarios provide much greater protection from outside threats than encrypted secondary filesystems, they also share a common disadvantage: any user in possession of the encryption key is able to decrypt the entire drive, and therefore can access other users' data. If that is of concern, it is possible to use a combination of blockdevice and stacked filesystem encryption and reap the advantages of both. See Disk Encryption to plan ahead.

Simple partition layout with LUKS

This example covers a full system encryption with dmcrypt+ LUKS in a simple partition layout:

LVM on LUKS

The straight-forward method is to set up LVM on top of the encrypted partition instead of the other way round. Technically the LVM is setup inside one big encrypted blockdevice. Hence, the LVM is not transparent until the blockdevice is unlocked and the underlying volume structure is scanned and mounted during boot.

This method will not allow you to span the logical volumes over multiple disk, even in the future. For a solution that allows to do so, see #LUKS on LVM.

After that, create the LUKS encrypted container (sdx3. We do not encrypt /boot or the BIOS partition)

# cryptsetup luksFormat /dev/sdx3

NOTE: cryptsetup has a TON of options (which you can find in its man page). The defaults now are quite secure (aes-xts-plain64 with 256bit keysize results in a 128 bit AES encryption for the data), but you may change whatever settings you like here. A description of the options you find in the LUKS page too. Enter your password twice.

Preparing the boot partition

In most setups, a dedicated /boot partition is not necessary, but it is in a complex setup like this one, because GRUB needs to be able to read the kernel, initramfs, its own configuration files, etc. from the /boot directory. Since GRUB does not itself know how to unlock a LUKS partition (that's the kernel's job), /boot must not be encrypted, and therefore must be a separate disk partition.

Create an ext2 filesystem on the partition you created for /boot earlier (/dev/sdx2 in the example above).

# mkfs -t ext2 /dev/sdx2

Mount this partition under the /boot partition of the installed system. If you skip this step (or if you mount /mnt after /mnt/boot), GRUB's installation scripts will be writing to the root partition's /boot directory, which will be encrypted and thus unreadable by GRUB at the next reboot. Note: you may wish to delete the /boot/* directory contents from /dev/sdx3 (root partition) to make it obvious that /boot is not mounted, in case you need to make changes in the future.

# mount /dev/sdx2 /mnt/boot #if you are outside the chroot, OR
# mount /dev/sdx2 /boot #if you are inside the chroot

Now continue through the Arch setup. (Pacstrap, arch-chroot /mnt, and so on. This HOWTO will assume you are also installing grub-bios to GPT as per the install guide.)

Note: When reinstalling GRUB, you may receive warnings like /run/lvm/lvmetad.socket: connect failed: No such file or directory or WARNING: failed to connect to lvmetad: No such file or directory. Falling back to internal scanning. This is because /run is not available inside the chroot. These warnings will not prevent the system from booting, provided that everything has been done correctly, so you may continue with the installation.

Checking fstab

"genfstab -p /mnt >> /mnt/etc/fstab" will make the proper entry in fstab, so that no further manual intervention is needed and the /boot partition is automatically mounted when the system starts.

LUKS on LVM

To use encryption on top of LVM, the LVM volumes are set up first and then used as the base for the encrypted partitions. This way, a mixture of encrypted and non-encrypted volumes/partitions is possible as well. Unlike #LVM on LUKS, this method allows normally spanning the logical volumes over multiple disks.

The following short example creates a LUKS on LVM setup and mixes in the use of a key-file for the /home partition and temporary crypt volumes for /tmp and /swap. The latter is considered desirable from a security perspective, because no potentially sensitive temporary data survives the reboot, when the encryption is re-initialised. If you are experienced with LVM, you will be able to ignore/replace LVM and other specifics according to your plan.

Encrypting /home after reboot

Below we will be editing /etc/crypttab. This is necessary to unlock each non-root LUKS container (like /home, /media, etc) -- these logical volumes are just as important as /root, and if they are not visible the entire system will fail to boot! LVM must have all volumes present and accounted for.
Now, in order to avoid typing in multiple passwords (1 per container) every boot, we may generate some strong encryption keys and save them in /etc. Some more background about possible encryption keys, you find here.
When the PC is powered off, these keys are perfectly safe: they are being saved inside the root LVM container, which must be unlocked by you at boot with a password. As well, having different passwords for each disk makes breaking the encryption even more difficult -- even if one password is compromised, the LVM WILL NOT activate without the other partitions.

Note: If you do not want to use a keyfile, simply leave the third column empty (/etc/luks-keys/home in the example) and you will be asked for a password at boot.

/etc/fstab

/dev/mapper/home /home reiserfs defaults 0 0

Expanding LVM on multiple disks

The encrypt hook only allows for a singlecryptdevice= entry. For example, take "LVM on LUKS": The entire LVM exists inside a LUKS container. This is perfectly fine for a single-drive system: there is only one container to decrypt. But what happens when you want to increase the size of your LVM? This is in fact the main advantage of LVM: you can add and remove entire drives without having to change the underlying partition.

So, you add another hard drive in order to expand home (which is a logical volume of its own). You encrypt the second drive, add it to the volume group, expand the home LV. But now, how do you tell initrd to unlock BOTH drives at the same time? You cannot, at least not without modifying the encrypt hook. And as stated in the section above: if only a part of an LVM is available, it will not boot. So, adding a second drive that requires decryption before it can be read is out of the picture.

Luckily, we can get around this by making the LVM's visible to the system even before they are encrypted. This is why LUKS on LVM is, in general, the option offering more flexibility to change partitioning.

Adding a new drive

Assuming you now have a working single-drive LUKS-on-LVM configuration, it's now time to expand one of your logical volumes.

Connect your drive (if it's new, or completely randomize it as you did with your root drive). Open gdisk and create a single partiion:

/dev/sdy1: Use ALL space, Partition type 8E00 (Linux LVM)

Now, attach this new disk to your existing LVM:

# pvcreate /dev/sdy1
# vgextend MyStorage /dev/sdy1

Extending the logical volume

You will have to unmount whatever partition you want to grow, meaning you may need to boot via an install cd. Details for this will follow below.
In this example, we will extend the "HOME" logical volume by 100% of the free space of our new drive (ie, put the WHOLE thing into /home!)

Note how /home now includes the span of the new drive, and you DO not have to change or add any more encryption keys -- the key for your Home LVM will continue to work and fill into the newly added space.

A note on extending your root partition:

The procedure works exactly the same for your root LVM, with the exception that it must be done from an Arch INSTALL CD. (you cannot unmount your root partition while it's in use).

Troubleshooting

The system does not boot

First, DONT PANIC! You can always boot a rescue CD and get into your LVM manually!

Start up via the Arch installer.
When you reach the root shell, for each encrypted LVM:

# cryptsetup open --type luks /dev/mapper/MyStorage-rootvol

Simply unlock each logical partition -- they will appear in /dev/mapper/<lv> and you can mount each from there.

LUKS on software RAID

Plain dm-crypt

This scenario sets up a system on a dm-crypt a full disk with plain mode encryption. Note that for most use cases, the methods using LUKS described above are the better options for both system encryption and encrypted partitions. LUKS features like key management with multiple pass-phrases/key-files are unavailable with plain mode.

The scenario uses an USB stick for the boot device and another one to store the encryption key. The disk layout is:

The boot loader options required to open/unlock a plain encrypted device are detailed. Typing them each boot is error prone, storing them on an unencrypted /boot partition on the same device results in security concerns.

This scenario uses a key file, storing the keyfile on a second USB stick for security again. A passphrase with good entropy may be used instead.

The main consideration for choosing plain over LUKS mode for the scenario is:

dm-crypt plain mode 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, which is the desired attribute for this scenario.

Plain dm-crypt encrypted disks can be more resilient to damage than LUKS encrypted disks, because it does not rely on an encryption master-key which can be a single-point of failure if damaged. However, using plain mode also requires more manual configuration of encryption options to achieve the same cryptographic strength. See also Disk_Encryption#Cryptographic_metadata

Note: If you have a requirement for a blockdevice without a cryptheader but want to use LUKS instead of plain mode for above noted disadvantages, cryptsetup offers a --header option too. While it cannot be used with the encrypt hook, it can generally be used to place the LUKS header remote from the encrypted blockdevice. For example it could be placed on the usb-key /dev/sdZ instead of the key-file (using a passphrase instead gives easy two-factor authentication).

Preparing the disk

It is vital that the mapped device is filled with data. In particular this applies to the scenario usecase we apply here.