Discuss...

Historically cryptsetup and LUKS only supported good old passwords; however recent systemd versions extend cryptsetup with additional key types such as FIDO tokens and TPM devices.

I like the idea of encrypting the rootfs with a TPM2 key; it allows booting without ugly LUKS password prompts but still it keeps data encrypted at rest, and when combined with secure boot also still protects the running system against unauthorized access.

Secure boot will prevent others from placing custom kernels on the unencrypted EFI system partition and booting these, or changing the kernel cmdline, in order to obtain root access to the unlocked rootfs. LUKS encryption with a TPM-based key bound to secure boot state protects the data if someone removes the hard disk and attempts to access it offline, or tries to disable secure boot in order to boot a custom kernel.

I’ve covered secure boot setup in a past article; this article talks about the TPM2-based encryption.

Enroll TPM key

Check that the system supports TPM2:

$ systemd-cryptenroll --tpm2-device=list
PATH        DEVICE      DRIVER 
/dev/tpmrm0 MSFT0101:00 tpm_crb

Then enroll a new TPM2 key (use the appropriate block device path of course):

$ systemd-cryptenroll --tpm2-device=auto /dev/disk/by-partlabel/linux 
New TPM2 token enrolled as key slot 1.

Then add recovery key:

$ systemd-cryptenroll --recovery-key  /dev/disk/by-partlabel/linux
🔐 Please enter current passphrase for disk /dev/disk/by-partlabel/linux: 
A secret recovery key has been generated for this volume:

    🔐 efcfbdlt-rhkdjjul-inbhbvhi-nfkvbbbv-didjbjel-butkrrig-ugbrivdd-evnkkkgn

Please save this secret recovery key at a secure location. It may be used to
regain access to the volume if the other configured access credentials have
been lost or forgotten. The recovery key may be entered in place of a password
whenever authentication is requested.
New recovery key enrolled as key slot 2.

As suggested save this key in a secure location outside of the system. If TPM2 unlocking fails systemd will prompt for a password where you can enter this key. This lets us access the data even if the TPM2 key became invalid (e.g. when the secure boot configuration changes).

Configure dracut

Force dracut to include the TPM2 software stack, by adding /etc/dracut.conf.d/tpm.conf:

add_dracutmodules+=" tpm2-tss "
# And add files dracut currently fails to add, see
# https://github.com/dracutdevs/dracut/issues/1676
install_items+=" /usr/lib/cryptsetup/libcryptsetup-token-systemd-tpm2.so "

The last line adds necessary cryptsetup plugins which dracut doesn’t yet add (see https://github.com/dracutdevs/dracut/issues/1676).

Make sure to use dracut newer than 055-106-g813577e2; dracut 55 has a typo in the tpm2-tss module dependencies which breaks the module (see https://github.com/dracutdevs/dracut/pull/1526), and another issue with systemd-sysusers which interferes with TPM2 support in early boot (see https://github.com/dracutdevs/dracut/pull/1658). As of Dec 2021 you’ll need to install dracut-git from AUR.

Reboot and cleanup

Reboot to verify that the system now boots without a LUKS prompt. Afterwards remove the password key from the rootfs:

$ systemd-cryptenroll --wipe-slot=password /dev/disk/by-partlabel/linux

Now the system only unlocks with the TPM2 key or the recovery key.

Tighten security

Check that

• secure boot is enabled (bootctl status or sbctl status),
• secure boot uses custom keys,
• all kernels are signed (sbctl verify; also check the firmware updater and other relevant EFI binaries), and
• no unsigned initramfs or microcode image is used (at best use bundled UEFI executables).

For users consider to use systemd-homed which offers per-user encrypted home “areas”, backed by LUKS encrypted loopback files.

Discuss...

Discuss...

Installing Arch on a LUKS-encrypted dsik traditionally required a few careful configuration steps to configure the proper root device for booting; if any of these steps was omitted or done wrongly the system would fail to boot. With systemd and dracut however a LUKS-encrypted Arch system can boot safely and reliably without any configuration:

• Dracut builds a unified EFI kernel image including microcode and a generic initrd with systemd and cryptsetup.
• systemd-boot automatically discovers unified kernel images installed by dracut and automatically adds them to the boot menu without explicit boot loader configuration.
• At boot systemd automatically discovers and mounts the root file system following its DISCOVERABLE PARTITIONS specification.

The following commands demonstrate a fresh Arch installation from the Arch installation media into a libvirt VM. Installing to a pristine physical machine or a different virtual machine provider should require only minimal changes; adapting an existing system may be more difficult and require more work.

Prepare the disk

$ sgdisk 
    -n1:0:+500M  -t1:ef00 -c1:EFISYSTEM 
    -n2:0:+1000M -t2:ea00 -c2:XBOOTLDR 
    -N3          -t3:8304 -c3:linux 
    /dev/vda
$ mkfs.fat -F32 -n EFISYSTEM /dev/disk/by-partlabel/EFISYSTEM
$ mkfs.fat -F32 -n XBOOTLDR /dev/disk/by-partlabel/XBOOTLDR
$ cryptsetup luksFormat /dev/disk/by-partlabel/linux
$ cryptsetup luksOpen /dev/disk/by-partlabel/linux root
$ mkfs.btrfs -L linux /dev/mapper/root

This creates a 500M EFI system partition for the boot loader and the kernel, a 1000M extended boot loader partition for systemd-boot (entirely optional, but helpful for rescue systems or Windows dual-boot), and fills the rest of the partition with a LUKS parition holding a btrfs filesystem. Each partition gets the proper type code (-t) corresponding to the discoverable partition GUID (e.g. 8304 refers to the “Linux x86-64 root (/)” partition); this enables systemd to automatically mount the partition. For convenience each partition also gets a GPT partition label (-c) which we can use to refer to the partition by name under /dev/disk/by-partlabel instead of remembering the numeric order of partitions as in /dev/vda1.

Install and configure the base system

We now install a base Arch system on top of the new file system:

$ mount /dev/mapper/root/ /mnt
$ mkdir /mnt/{boot,efi}
$ btrfs subvolume create /mnt/var
$ btrfs subvolume create /mnt/home
$ mount /dev/disk/by-partlabel/EFISYSTEM /mnt/efi
$ mount /dev/disk/by-partlabel/XBOOTLDR /mnt/boot
$ reflector --save /etc/pacman.d/mirrorlist --protocol https --latest 5 --sort age
$ pacstrap /mnt base linux linux-lts linux-firmware intel-ucode btrfs-progs dracut neovim
$ arch-chroot /mnt
$ ln -sf /usr/share/zoneinfo/UTC /etc/localtime
$ nvim /etc/locale.gen /etc/locale.conf /etc/vconsole.conf /etc/hostname /etc/hosts
$ locale-gen
$ passwd

Note that we explicitly do not create /etc/fstab.

Generate unified kernel image

While still in chroot we install the optional dependencies dracut requires to build unified kernel images and then run dracut for all kernels we installed above.

$ pacman -S --asdeps binutils elfutils
$ for kver in /lib/modules/*; do dracut -f --uefi --kver "${kver##*/}"; done

Install the boot loader

Next we install the systemd-boot boot loader, again still from chroot; we need no further configuration as we mount the EFI and boot loader paritions at their standard paths /efi and /boot respectively.

$ bootctl install

Continue installation

At this point we can install additional packages and enable services; for the purpose of this demonstration we’ll add a simple network configuration:

$ cat > /etc/systemd/network/20-wired.network <<EOF
[Match]
Name=enp1s0

[Network]
DHCP=yes
EOF
$ umount /etc/resolve.conf
$ ln -sf /run/systemd/resolve/stub-resolve.conf /etc/resolve.conf
$ systemctl enable systemd-network.service
$ systemctl enable systemd-timesyncd.service
$ systemctl enable systemd-resolved.service

At the time of writing arch-chroot bind-mounts the live disk resolve.conf into the chroot; we need to unmount it explicitly before we can setup the systemd stub resolver for the new installation.

For a real server or desktop installation we would likely install more packages and services and setup user accounts at this point to boot into a fully working system. I usually run my arch/install.bash script when installing a desktop system (for servers I tend to use other distributions, or one of the Arch Linux cloud images)

Reboot into the new system

$ exit
$ poweroff

Now we can remove the installation media and start the system again; by holding the space key during boot we make the boot menu appear to verify that the generated unified kernel images are indeed recognized by systemd-boot:

systemd-boot seems to pick the image with the highest version number automatically. Upon boot the image automatically discovers the LUKS root partition and offers to unlock it:

All this happens automatically; we did not have to configure /etc/fstab and /etc/crypttab.initramfs to specify the root filesystem, nor /etc/mkinitcpio.conf to include the right systemd and cryptsetup hooks.

Configuring for more convenience

At this point the system boots perfectly fine without any configuration, but nonetheless there are a few relevant configuration switches.

Generate kernel images upon installation

Currently the dract package includes no libalpm hooks to build new EFISTUB binaries on kernel updates. The Arch wiki documents the hooks necessary to make this happen; I use dracut-hook-uefi-systemd from AUR to automate this.

Optimize the initrd

By default dracut builds a generic initrd which works on any hardware and system; this mode is intended for distribution vendors which ship a prebuilt initrd as a package. Arch however builds the initrd on the system after installation; this allows us to enable host-only mode to reduce the size of the image and embed host-specific kernel flags. Dracuts reads configuration files from /etc/dracut.conf.d, e.g. /etc/dracut.conf.d/50-host-only.conf:

# Hide all systemd messages at startup
kernel_cmdline="quiet"
# Use hostonly to exclude unnecessary modules, but do not include the hostonly
# cmdline in the image, because at the time of writing it has a few issues with
# discoverable partitions.
# See <https://github.com/dracutdevs/dracut/issues/723#issuecomment-792248568>
hostonly="yes"
hostonly_cmdline="no"

Configure the boot menu

systemd-boot enables the kernel command line editor by default, to aid with fixing unbootable systems. With physical access to the machine we can gain root access by booting into /bin/sh with proper kernel parameters. In our system the impact of this security hole is limited since the attacker cannot unlock the encrypted root disk to do anything with the system, but nonetheless it’s recommended to disable the editor in /efi/loader/loader.conf. At this place we can also change the boot menu timeout, and set the default kernel.

# Disable the editor to improve security a bit.
editor no
# Directly boot the default kernel; to make the boot menu appear
# press any key during the firmware splash screen.
timeout 0
# Boot the LTS kernel by default.
default linux-*-lts-*

The default stanza supports glob patterns; systemd boot then picks the matching image with the highest version. The pattern in the above example matches the linux LTS kernel.

Conclusion

This setup now boots seamlessly into the getty prompt:

Discuss...