This article focuses on how to set up full system encryption on Arch Linux, using dm-crypt with 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.
LUKS is an additional convenience layer which stores all of the needed setup information for dm-crypt on the disk itself and abstracts partition and key management in an attempt to improve ease of use.
For more details on how dm-crypt+LUKS compares to other disk encryption solution, see Disk Encryption#Comparison table.
The installation of a LUKS-encrypted system is largely the same as installing an unencrypted system. Routine creation of an encrypted system follows these general steps:
- Preparation of the drive(s) where the system will be installed
- Creation of the needed encryption layers
- Configuration of the system to handle the encryption
- Installation of the system following the Installation Guide or the Beginners' Guide
Note that the Arch installation media comes with all the tools required for system encryption.
Swap device encryption
A swap partition may be added to an encrypted system, if required. The swap partition must be encrypted as well to protect any data swapped out by the system. This part details methods without and with suspend-to-disk support.
This part deals with special operations like securing the unencrypted boot partition, using GPG or OpenSSL encrypted keyfiles, a method to boot and unlock via the network, or setting up discard/TRIM for a SSD.
Securing the unencrypted boot partition
Referring to an article from the ct-magazine (Issue 3/12, page 146, 01.16.2012 http://www.heise.de/ct/inhalt/2012/03/6/) 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 MBR. 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 crypted system this makes it infeasible for an attacker to recognize that an automatic checksum comparison of the partition is done upon boot.
The script with installation instructions is available here: ftp://ftp.heise.de/pub/ct/listings/1203-146.zip (Author: Juergen Schmidt, ju at heisec.de; License: GPLv2). There is also an AUR package: AUR and a slightly updated AUR package AUR which includes systemd support.
- For classical sysvinit: add
/usr/local/bin/chkboot.sh &to your
- For systemd: add a service file and enable the service: systemd. The service file might look like:
[Unit] Description=Check that boot is what we want Requires=basic.target After=basic.target [Service] Type=oneshot ExecStart=/usr/local/bin/chkboot.sh [Install] WantedBy=multi-user.target
There is a small caveat for systemd: At the time of writing the original
chkboot.sh script provided contains an empty space at the beginning of
#!/bin/bash which has to be removed for the service to start successfully.
/usr/local/bin/chkboot_user.sh need to be excuted after login, add it to the autostart (e.g. under KDE -> System Settings -> Startup and Shutdown -> Autostart; Gnome3: gnome-session-properties).
With Arch Linux 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:
#!/bin/bash # # Note: Insert your <user> and execute it with sudo for pacman & chkboot to work automagically # echo "Pacman update  Quickcheck before updating" & sudo -u <user> /usr/local/bin/chkboot_user.sh # insert your logged on <user> /usr/local/bin/chkboot.sh sync # sync disks with any results sudo -u <user> /usr/local/bin/chkboot_user.sh # insert your logged on <user> echo "Pacman update  Syncing repos for pacman" pacman -Syu /usr/local/bin/chkboot.sh sync sudo -u <user> /usr/local/bin/chkboot_user.sh # insert your logged on <user> echo "Pacman update  All done, let's roll on ..."
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 bootmenu 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 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.