From ParabolaWiki
Jump to: navigation, search

Back to Dm-crypt.

1 Securing the unencrypted boot partition

The /boot partition and the Master Boot Record are the two areas of the disk that are not encrypted, even in an encrypted root configuration. They cannot usually be encrypted because the boot loader and BIOS (respectively) are unable to unlock a dm-crypt container in order to continue the boot process. An exception is GRUB, which gained a feature to unlock a LUKS encrypted /boot - see GRUB#Boot partition.

This section describes steps that can be taken to make the boot process more secure.

Warning: Note that securing the /boot partition and MBR can mitigate numerous attacks that occur during the boot process, but systems configured this way may still be vulnerable to BIOS/UEFI/firmware tampering, hardware keyloggers, cold boot attacks, and many other threats that are beyond the scope of this article. For an overview of system-trust issues and how these relate to full-disk encryption, refer to [1].

1.1 Booting from a removable device

Warning: systemd version 230 cryptsetup generator emits RequiresMountsFor for crypto keyfile. Therefore, when the filesystem that holds this file is unmounted, it also stops cryptsetup service. This behavior is incorrect because the filesystem and cryptokey is required only once, when the crypto container is initially setup. See issue 3816 [2]

Using a separate device to boot a system is a fairly straightforward procedure, and offers a significant security improvement against some kinds of attacks. Two vulnerable parts of a system employing an encrypted root filesystem are

These must be stored unencrypted in order for the system to boot. In order to protect these from tampering, it is advisable to store them on a removable medium, such as a USB drive, and boot from that drive instead of the hard disk. As long as you keep the drive with you at all times, you can be certain that those components have not been tampered with, making authentication far more secure when unlocking your system.

It is assumed that you already have your system configured with a dedicated partition mounted at /boot. If you do not, please follow the steps in dm-crypt/System configuration#Boot loader, substituting your hard disk for a removable drive.

Note: You must make sure your system supports booting from the chosen medium, be it a USB drive, an external hard drive, an SD card, or anything else.

Prepare the removable drive (/dev/sdx).

# gdisk /dev/sdx #format if necessary. Alternatively, cgdisk, fdisk, cfdisk, gparted...
# mkfs.ext2 /dev/sdx1
# mount /dev/sdx1 /mnt

Copy your existing /boot contents to the new one.

# cp -R -i -d /boot/* /mnt

Mount the new partition. Do not forget to update your fstab file accordingly.

# umount /boot
# umount /mnt
# mount /dev/sdx1 /boot
# genfstab -p -U / > /etc/fstab

Update GRUB. grub-mkconfig should detect the new partition UUID automatically, but custom menu entries may need to be updated manually.

# grub-mkconfig -o /boot/grub/grub.cfg
# grub-install /dev/sdx #install to the removable device, not the hard disk.

Reboot and test the new configuration. Remember to set your device boot order accordingly in your BIOS or UEFI. If the system fails to boot, you should still be able to boot from the hard drive in order to correct the problem.

1.2 chkboot

Warning: chkboot makes a /boot partition tamper-evident, not tamper-proof. By the time the chkboot script is run, you have already typed your password into a potentially compromised boot loader, kernel, or initrd. If your system fails the chkboot integrity test, no assumptions can be made about the security of your data.

Referring to an article from the ct-magazine (Issue 3/12, page 146, 01.16.2012, [3]) the following script checks files under /boot for changes of SHA-1 hash, inode, and occupied blocks on the hard drive. It also checks the Master Boot Record. The script cannot prevent certain type of attacks, but a lot are made harder. No configuration of the script itself is stored in unencrypted /boot. With a locked/powered-off encrypted system, this makes it harder for some attackers because it is not apparent that an automatic checksum comparison of the partition is done upon boot. However, an attacker who anticipates these precautions can manipulate the firmware to run his own code on top of your kernel and intercept file system access, e.g. to boot, and present the untampered files. Generally, no security measures below the level of the firmware are able to guarantee trust and tamper evidence.

The script with installation instructions is available (Author: Juergen Schmidt, ju at; License: GPLv2).

After installation add a service file (the package includes one based on the following) and enable it:

Description=Check that boot is what we want



There is a small caveat for systemd. At the time of writing, the original script provided contains an empty space at the beginning of #!/bin/bash which has to be removed for the service to start successfully.

As /usr/local/bin/ needs to be executed right after login, you need to add it to the autostart (e.g. under KDE -> System Settings -> Startup and Shutdown -> Autostart; GNOME 3: gnome-session-properties).

With Parabola, changes to /boot are pretty frequent, for example by new kernels rolling-in. Therefore it may be helpful to use the scripts with every full system update. One way to do so:

# Note: Insert your <user>  and execute it with sudo for pacman & chkboot to work automagically
echo "Pacman update [1] Quickcheck before updating" & 
sudo -u <user> /usr/local/bin/		# insert your logged on <user> 
sync							# sync disks with any results 
sudo -u <user> /usr/local/bin/		# insert your logged on <user> 
echo "Pacman update [2] Syncing repos for pacman" 
pacman -Syu
sudo -u <user> /usr/local/bin/		# insert your logged on <user>
echo "Pacman update [3] All done, let us roll on ..."

1.3 Other methods

Alternatively to above scripts, a hash check can be set up with AIDE which can be customized via a very flexible configuration file.

While one of these methods should serve the purpose for most users, they do not address all security problems associated with the unencrypted /boot. One approach which endeavours to provide a fully authenticated boot chain was published with POTTS as an academic thesis to implement the STARK authentication framework.

The POTTS proof-of-concept uses Arch Linux as a base distribution and implements a system boot chain with

  • POTTS - a boot menu for a one-time authentication message prompt
  • TrustedGrub - a GRUB Legacy implementation which authenticates the kernel and initramfs against TPM chip registers
  • TRESOR - a kernel patch which implements AES but keeps the master-key not in RAM but in CPU registers during runtime.

As part of the thesis installation instructions based on Arch Linux (ISO as of 2013-01) have been published. If you want to try it, be aware these tools are not in standard repositories and the solution will be time consuming to maintain.

2 Using GPG or OpenSSL Encrypted Keyfiles

The following forum posts give instructions to use two factor authentication, gpg or openssl encrypted keyfiles, instead of a plaintext keyfile described earlier in this wiki article System Encryption using LUKS with GPG encrypted keys:

Note that:

  • You can follow the above instructions with only two primary partitions, one boot partition (required because of encryption) and one primary LVM partition. Within the LVM partition you can have as many partitions as you need, but most importantly it should contain at least root, swap, and home logical volume partitions. This has the added benefit of having only one keyfile for all your partitions, and having the ability to hibernate your computer (suspend to disk) where the swap partition is encrypted. If you decide to do so your hooks in /etc/mkinitcpio.conf should look like this:
    HOOKS=" ... usb usbinput (etwo or ssldec) encrypt (if using openssl) lvm2 resume ... "
    and you should add
    to your kernel parameters.
  • If you need to temporarily store the unencrypted keyfile somewhere, do not store them on an unencrypted disk. Even better make sure to store them to RAM such as /dev/shm.
  • It is possible that an update to OpenSSL could break the custom ssldec mentioned in the second forum post.

3 Remote unlocking of the root (or other) partition

There are few ways to provide early networking and cryptsetup configuration.

They all require making changes to initramfs with help of packages contributing various mkinitcpio build hooks.

3.1 Remote unlock via wifi (hooks: build your own)

The net hook is normally used with an ethernet connection. In case you want to setup a computer with wireless only, and unlock it via wifi, you can create a custom hook to connect to a wifi network before the net hook is run.

Below example shows a setup using a usb wifi adapter, connecting to a wifi network protected with WPA2-PSK. In case you use for example WEP or another boot loader, you might need to change some things.

  1. Modify /etc/mkinitcpio.conf:
    • Add the needed kernel module for your specific wifi adatper.
    • Include the wpa_passphrase and wpa_supplicant binaries.
    • Add a hook wifi (or a name of your choice, this is the custom hook that will be created) before the net hook.
      BINARIES="wpa_passphrase wpa_supplicant"
      HOOKS="base udev autodetect ... wifi net ... dropbear encryptssh ..."
  2. Create the wifi hook in /lib/initcpio/hooks/wifi:
    run_hook ()
    # sleep a couple of seconds so wlan0 is setup by kernel
    sleep 5

    # set wlan0 to up
    ip link set wlan0 up

    # assocciate with wifi network
    # 1. save temp config file
    wpa_passphrase "network ESSID" "pass phrase" > /tmp/wifi

    # 2. assocciate
    wpa_supplicant -B -D nl80211,wext -i wlan0 -c /tmp/wifi

    # sleep a couple of seconds so that wpa_supplicant finishes connecting
    sleep 5

    # wlan0 should now be connected and ready to be assigned an ip by the net hook

    run_cleanuphook ()
    # kill wpa_supplicant running in the background
    killall wpa_supplicant

    # set wlan0 link down
    ip link set wlan0 down

    # wlan0 should now be fully disconnected from the wifi network
  3. Create the hook installation file in /lib/initcpio/install/wifi:
    build ()
    help ()
    Enables wifi on boot, for dropbear ssh unlocking of disk.
  4. Add ip=:::::wlan0:dhcp to the kernel parameters. Remove ip=:::::eth0:dhcp so it does not conflict.
  5. Optionally create an additional boot entry with kernel parameter ip=:::::eth0:dhcp.
  6. Regenerate the intiramfs image.
  7. Update the configuration of your boot loader, e.g. for GRUB:
    # grub-mkconfig -o /boot/grub/grub.cfg

Remember to setup wifi, so you are able to login once the system is fully booted. In case you are unable to connect to the wifi network, try increasing the sleep times a bit.

4 Discard/TRIM support for solid state drives (SSD)

Solid state drive users should be aware that, by default, TRIM commands are not enabled by the device-mapper, i.e. block-devices are mounted without the discard option unless you override the default.

The device-mapper maintainers have made it clear that TRIM support will never be enabled by default on dm-crypt devices because of the potential security implications.[4][5] Minimal data leakage in the form of freed block information, perhaps sufficient to determine the filesystem in use, may occur on devices with TRIM enabled. An illustration and discussion of the issues arising from activating TRIM is available in the blog of a cryptsetup developer. If you are worried about such factors, keep also in mind that threats may add up: for example, if your device is still encrypted with the previous (cryptsetup <1.6.0) default cipher --cipher aes-cbc-essiv, more information leakage may occur from trimmed sector observation than with the current default.

The following cases can be distinguished:

  • The device is encrypted with default dm-crypt LUKS mode:
    • By default the LUKS header is stored at the beginning of the device and using TRIM is useful to protect header modifications. If for example a compromised LUKS password is revoked, without TRIM the old header will in general still be available for reading until overwritten by another operation; if the drive is stolen in the meanwhile, the attackers could in theory find a way to locate the old header and use it to decrypt the content with the compromised password. See cryptsetup FAQ, section 5.19 What about SSDs, Flash and Hybrid Drives? and Full disk encryption on an ssd.
    • TRIM can be left disabled if the security issues stated at the top of this section are considered a worse threat than the above bullet.
See also Securely wipe disk#Flash memory.
  • The device is encrypted with dm-crypt plain mode, or the LUKS header is stored separately:
    • If plausible deniability is required, TRIM should never be used because of the considerations at the top of this section, or the use of encryption will be given away.
    • If plausible deniability is not required, TRIM can be used for its performance gains, provided that the security dangers described at the top of this section are not of concern.
Warning: Before enabling TRIM on a drive, make sure the device fully supports TRIM commands, or data loss can occur. See Solid State Drives#TRIM.

In linux-libre 3.1 and up, support for dm-crypt TRIM pass-through can be toggled upon device creation or mount with dmsetup. Support for this option also exists in cryptsetup version 1.4.0 and up. To add support during boot, you will need to add :allow-discards to the cryptdevice option. The TRIM option may look like this:


For the main cryptdevice configuration options before the :allow-discards see Dm-crypt/System configuration.

If you are using a systemd based initrd, you must pass:


Besides the kernel option, it is also required to periodically run fstrim or mount the filesystem (e.g. /dev/mapper/root in this example) with the discard option in /etc/fstab. For details, please refer to the TRIM page.

For LUKS devices unlocked manually on the console or via /etc/crypttab either discard or allow-discards may be used.

5 The encrypt hook and multiple disks

The encrypt hook only allows for a single cryptdevice= entry. In system setups with multiple drives this may be limiting, because dm-crypt has no feature to exceed the physical device. For example, take "LVM on LUKS": The entire LVM exists inside a LUKS mapper. This is perfectly fine for a single-drive system, since there is only one device to decrypt. But what happens when you want to increase the size of the LVM? You cannot, at least not without modifying the encrypt hook.

The following sections briefly show alternatives to overcome the limitation. The first deals with how to expand a LUKS on LVM setup to a new disk. The second with modifying the encrypt hook to unlock multiple disks in LUKS setups without LVM. The third section then again uses LVM, but modifies the encrypt hook to unlock the encrypted LVM with a remote LUKS header.

5.1 Expanding LVM on multiple disks

The management of multiple disks is a basic LVM feature and a major reason for its partitioning flexibility. It can also be used with dm-crypt, but only if LVM is employed as the first mapper. In such a LUKS on LVM setup the encrypted devices are created inside the logical volumes (with a separate passphrase/key per volume). The following covers the steps to expand that setup to another disk.

Warning: Backup! While resizing filesystems may be standard, keep in mind that operations may go wrong and the following might not apply to a particular setup. Generally, extending a filesystem to free disk space is less problematic than shrinking one. This in particular applies when stacked mappers are used, as it is the case in the following example.

5.1.1 Adding a new drive

First, it may be desired to prepare a new disk according to Dm-crypt/Drive preparation. Second, it is partitioned as a LVM, e.g. all space is allocated to /dev/sdY1 with partition type "8E00" (Linux LVM). Third, the new disk/partition is attached to the existing LVM volume group, e.g.:

# pvcreate /dev/sdY1
# vgextend MyStorage /dev/sdY1

5.1.2 Extending the logical volume

For the next step, the final allocation of the new diskspace, the logical volume to be extended has to be unmounted. It can be performed for the cryptdevice root partition, but in this case the procedure has to be performed from a Parabola Install ISO.

In this example, it is assumed that the logical volume for /home (lv-name homevol) is going to be expanded with the fresh disk space:

# umount /home
# fsck /dev/mapper/home
# cryptsetup luksClose /dev/mapper/home
# lvextend -l +100%FREE MyStorage/homevol

Now the logical volume is extended and the LUKS container comes next:

# cryptsetup open --type luks /dev/mapper/MyStorage-homevol home
# umount /home      # as a safety, in case it was automatically remounted
# cryptsetup --verbose resize home

Finally, the filesystem itself is resized:

# e2fsck -f /dev/mapper/home
# resize2fs /dev/mapper/home

Done! If it went to plan, /home can be remounted

# mount /dev/mapper/home /home

and now includes the span to the new disk. Note that the cryptsetup resize action does not affect encryption keys, they have not changed.

5.2 Modifying the encrypt hook for multiple partitions

5.2.1 Root filesystem spanning multiple partitions

It is possible to modify the encrypt hook to allow multiple hard drive decrypt root (/) at boot. One way:

# cp /usr/lib/initcpio/install/encrypt /etc/initcpio/install/encrypt2
# cp /usr/lib/initcpio/hooks/encrypt  /etc/initcpio/hooks/encrypt2
# sed -i "s/cryptdevice/cryptdevice2/" /etc/initcpio/hooks/encrypt2
# sed -i "s/cryptkey/cryptkey2/" /etc/initcpio/hooks/encrypt2

Add cryptdevice2= to your boot options (and cryptkey2= if needed), and add the encrypt2 hook to your mkinitcpio.conf before rebuilding it. See Dm-crypt/System_configuration.

5.2.2 Multiple non-root partitions

Maybe you have a requirement for using the encrypt hook on a non-root partition. Parabola does not support this out of the box, however, you can easily change the cryptdev and cryptname values in /lib/initcpio/hooks/encrypt (the first one to your /dev/sd* partition, the second to the name you want to attribute). That should be enough.

The big advantage is you can have everything automated, while setting up /etc/crypttab with an external key file (i.e. the keyfile is not on any internal hard drive partition) can be a pain - you need to make sure the USB/FireWire/... device gets mounted before the encrypted partition, which means you have to change the order of /etc/fstab (at least).

Of course, if the cryptsetup package gets upgraded, you will have to change this script again. Unlike /etc/crypttab, only one partition is supported, but with some further hacking one should be able to have multiple partitions unlocked.

The factual accuracy of this article or section is disputed.
Please help improve the article and verify/correct/remove disputed content. (Discuss)

If you want to do this on a software RAID partition, there is one more thing you need to do. Just setting the /dev/mdX device in /lib/initcpio/hooks/encrypt is not enough; the encrypt hook will fail to find the key for some reason, and not prompt for a passphrase either. It looks like the RAID devices are not brought up until after the encrypt hook is run. You can solve this by putting the RAID array in /boot/grub/menu.lst, like

kernel /boot/vmlinuz-linux-libre md=1,/dev/hda5,/dev/hdb5

If you set up your root partition as a RAID, you will notice the similarities with that setup ;-). GRUB can handle multiple array definitions just fine:

kernel /boot/vmlinuz-linux-libre root=/dev/md0 ro md=0,/dev/sda1,/dev/sdb1 md=1,/dev/sda5,/dev/sdb5,/dev/sdc5

5.3 Encrypted system using a remote LUKS header

This example follows the same setup as in Dm-crypt/Encrypting an entire system#Plain dm-crypt, which should be read first before following this guide.

By using a remote header the encrypted blockdevice itself only carries encrypted data, which gives deniable encryption as long as the existence of a header is unknown to the attackers. It is similar to using plain dm-crypt, but with the LUKS advantages such as multiple passphrases for the masterkey and key derivation. Further, using a remote header offers a form of two factor authentication with an easier setup than using GPG or OpenSSL encrypted keyfiles, while still having a built-in password prompt for multiple retries. See Disk encryption#Cryptographic metadata for more information.

See Dm-crypt/Device encryption#Encryption options for LUKS mode for encryption options before performing the first step to setup the encrypted system partition and creating a header file to use with cryptsetup:

# truncate -s 2M header.img
# cryptsetup luksFormat /dev/sdX --header header.img

Open the container:

# cryptsetup open --header header.img --type luks /dev/sdX enc

Now follow the LVM on LUKS setup to your requirements. The same applies for preparing the boot partition on the removable device (because if not, there is no point in having a separate header file for unlocking the encrypted disk). Next move the header.img onto it:

# mv header.img /mnt/boot

Follow the installation procedure up to the mkinitcpio step (you should now be arch-chrooted inside the encrypted system).

There are two options for initramfs to support a detached LUKS header.

5.3.1 Using systemd hook

First create /etc/crypttab.initramfs and add the encrypted device to it. The syntax is defined in [[6]]

MyStorage    PARTUUID=00000000-0000-0000-0000-000000000000    none    header=/boot/header.img

Modify /etc/mkinitcpio.conf to use systemd and add the header to FILES.


HOOKS="... systemd ... block sd-encrypt sd-lvm2 filesystems ..."

Recreate the initramfs and you are done.

Note: No cryptsetup parameters need to be passed to the kernel command line, since/etc/crypttab.initramfs will be added as /etc/crypttab in the initramfs. If you wish to specify them in the kernel command line see [[7]] for the supported options.

5.3.2 Modifying encrypt hook

This method shows how to modify the encrypt hook in order to use a remote LUKS header. Now the encrypt hook has to be modified to let cryptsetup use the separate header; base source and idea for these changes published on the BBS). Make a copy so it is not overwritten on a mkinitcpio update:

# cp /usr/lib/initcpio/hooks/encrypt /etc/initcpio/hooks/encrypt2
# cp /usr/lib/initcpio/install/encrypt /etc/initcpio/install/encrypt2
/etc/initcpio/hooks/encrypt2 (around line 52)
warn_deprecated() {
    echo "The syntax 'root=${root}' where '${root}' is an encrypted volume is deprecated"
    echo "Use 'cryptdevice=${root}:root root=/dev/mapper/root' instead."

local headerFlag=false
for cryptopt in ${cryptoptions//,/ }; do
    case ${cryptopt} in
            cryptargs="${cryptargs} --allow-discards"
            cryptargs="${cryptargs} --header /boot/header.img"
            echo "Encryption option '${cryptopt}' not known, ignoring." >&2 

if resolved=$(resolve_device "${cryptdev}" ${rootdelay}); then
    if $headerFlag || cryptsetup isLuks ${resolved} >/dev/null 2>&1; then
        [ ${DEPRECATED_CRYPT} -eq 1 ] && warn_deprecated

Now edit the mkinitcpio.conf to add the encrypt2 and lvm2 hooks, the header.img to FILES and the loop to MODULES, apart from other configuration the system requires:



HOOKS="... encrypt2 lvm2 ... filesystems ..."

This is required so the LUKS header is available on boot allowing the decryption of the system, exempting us from a more complicated setup to mount another separate USB device in order to access the header. After this set up the initramfs is created.

Next the boot loader is configured to specify the cryptdevice= also passing the new header option for this setup:


To finish, following Dm-crypt/Encrypting an entire system#Post-installation is particularly useful with a /boot partition on an USB storage medium.

Tip: You will notice that since the system partition only has "random" data, it does not have a partition table and by that an UUID or a name. But you can still have a consistent mapping using the disk id under /dev/disk/by-id/

6 Acknowledgement

This wiki article is based on ArchWiki. We may have removed non-FSDG bits from it.