Difference between revisions of "Dm-crypt"

From ArchWiki
Jump to: navigation, search
(Configuring LUKS: moved to Dm-crypt with LUKS/Device encryption)
(Encrypting the Swap partition: moved to Dm-crypt with LUKS/Swap encryption)
Line 167: Line 167:
This is the recommended solution if you want to have a single user's home directory on a partition.
This is the recommended solution if you want to have a single user's home directory on a partition.
To automount user homes on login see [[Pam mount]].
To automount user homes on login see [[Pam mount]].
== Encrypting the Swap partition ==
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. Depending on the requirements, different methods may be used which are described in the following. A setup where the swap encryption is re-initialised on reboot (with a new encryption) provides higher data protection. However, re-encrypting swap also forbids using a suspend-to-disk feature generally.
=== Without suspend-to-disk support ===
In systems where suspend to disk is not a desired feature, it is possible to create a swap file that will have a random master key with each boot. This is accomplished by using dm-crypt directly without LUKS extensions.
The {{ic|/etc/crypttab}} is well commented and you can basically just uncomment the swap line and change <device> to a persistent symlink.
{{hc|/etc/crypttab|# <name>      <device>        <password>              <options>
# swap        /dev/hdx4        /dev/urandom            <nowiki>swap,cipher=aes-cbc-essiv:sha256,size=256</nowiki>}}
; <name>: Represents the name ({{ic|/dev/mapper/<name>}}) to list in /etc/fstab.
; <device>: Should be the symlink to the actual partition's device file.
; <password>: {{ic|/dev/urandom}} sets the dm-crypt master key to be randomized on every volume recreation.
; <options>: The {{ic|swap}} option runs mkswap after cryptographic's are setup.
{{Warning|You should use persistent block device naming (in example ID's) for <device> because if there are multiple hard drives installed in the system, their naming order (sda, sdb,...) can occasionally be scrambled upon boot and thus the swap would be created over a valuable file system, destroying its content.}}
Persistent block device naming is implemented with simple symlinks. Using UUID's or filesystem-labels is not possible as plain dm-crypt writes only encrypted data without a persistent header like LUKS. If you are not familar with one of the directories under {{ic|/dev/disk/}} read on in the section on [[#Preparation for Persistent block device naming]]
{{hc|#ls -l <nowiki>/dev/disk/*/* |</nowiki> grep sda2|
lrwxrwxrwx 1 root root 10 Oct 12 16:54 /dev/disk/by-id/ata-WDC_WD2500BEVT-22ZCT0_WD-WXE908VF0470-part2 -> ../../sda2}}
Example line for the {{ic|/dev/sda2}} symlink from above:
{{hc|/etc/crypttab|# <name>                      <device>                                  <password>    <options>
  swap  /dev/disk/by-id/ata-WDC_WD2500BEVT-22ZCT0_WD-WXE908VF0470-part2  /dev/urandom  <nowiki>swap,cipher=aes-cbc-essiv:sha256,size=256</nowiki>}}
This will map {{ic|/dev/sda2}} to {{ic|/dev/mapper/swap}} as a swap partition that can be added in {{ic|/etc/fstab}} like a normal swap.
If the partition chosen for swap was previously a LUKS partition, crypttab will not overwrite the partition to create a swap partition. This is a safety measure to prevent data loss from accidental mis-identification of the swap partition in crypttab. In order to use such a partition the [[#Wipe_LUKS_header|LUKS header must be overwritten]] once.
=== With suspend-to-disk support ===
To be able to resume after suspending the computer to disk (hibernate), it is required to keep the swap filesystem intact. Therefore, it is required to have a pre-existent LUKS swap partition, which can be stored on the disk or input manually at startup. Because the resume takes place before {{ic|/etc/crypttab}} can be used, it is required to create a hook in {{ic|/etc/mkinitcpio.conf}} to open the swap LUKS device before resuming.
If you want to use a partition which is currently used by the system, you have to disable it first:
# swapoff /dev/<device>
Also make sure you remove any line in {{ic|/etc/crypttab}} pointing to this device.
A simple way to realize encrypted swap with suspend-to-disk support is by using [[LVM]] ontop the encryption layer, so one encrypted partition can contain infinite filesystems (root, swap, home, ...). Follow the instructions on [[#Encrypting a LVM setup]].
The following setup has the disadvantage of having to insert an additional passphrase for the swap partition manually on every boot.
{{Warning|Do not use this setup with a key file. Please read about the issue reported [[Talk:System Encryption with LUKS for dm-crypt#Suspend to disk instructions are insecure|here]]}}
To format the encrypted container for the swap partition, follow steps similar to those described in [[#Configuring LUKS]] above and create keyslot for a user-memorizable passphrase.
Open the partition in {{ic|/dev/mapper}}:
# cryptsetup open --type luks /dev/<device> swapDevice
Create a swap filesystem inside the mapped partition:
# mkswap /dev/mapper/swapDevice
Now you have to create a hook to open the swap at boot time.
* Create a hook file containing the open command:
# vim: set ft=sh:
run_hook ()
    cryptsetup open --type luks /dev/<device> swapDevice
for opening the swap device by typing your password or
# vim: set ft=sh:
run_hook ()
    mkdir crypto_key_device
    mount /dev/mapper/<root-device> crypto_key_device
    cryptsetup open --type luks --key-file crypto_key_device/<path-to-the-key> /dev/<device> swapDevice
    umount crypto_key_device
for opening the swap device by loading a keyfile from a crypted root device
{{Note|If swap is on a Solid State Disk (SSD) and Discard/TRIM is desired the option {{ic|--allow-discards}} has to get added to the cryptsetup line in the openswap hook above. See [[#Discard.2FTRIM_support_for_solid_state_disks_.28SSD.29|Discard/TRIM support for solid state disks (SSD)]] or [[SSD]] for more information on discard. Additionally you have to add the mount option 'discard' to your fstab entry for the swap device.''}}
* Then create and edit the hook setup file:
# vim: set ft=sh:
build ()
help ()
  This opens the swap encrypted partition /dev/<device> in /dev/mapper/swapDevice
* Add the hook {{ic|openswap}} in the {{ic|HOOKS}} array in {{ic|/etc/mkinitcpio.conf}}, before {{ic|filesystem}} but after {{ic|encrypt}}. Do not forget to add the {{ic|resume}} hook after {{ic|openswap}}.
<nowiki>HOOKS="... encrypt openswap resume filesystems ..."</nowiki>
* Regenerate the boot image:
# mkinitcpio -p linux
* Add the mapped partition to {{ic|/etc/fstab}} by adding the following line:
/dev/mapper/swapDevice swap swap defaults 0 0
* Set up your system to resume from {{ic|/dev/mapper/swapDevice}}. For example, if you use [[GRUB]] with kernel hibernation support, add {{ic|resume<nowiki>=</nowiki>/dev/mapper/swapDevice}} to the kernel line in {{ic|/boot/grub/grub.cfg}}. A line with encrypted root and swap partitions can look like this:
kernel /vmlinuz-linux cryptdevice=/dev/sda2:rootDevice root=/dev/mapper/rootDevice resume=/dev/mapper/swapDevice ro
To make the parameter persistent on kernel updates, add it to {{ic|/etc/default/grub}}.
At boot time, the {{ic|openswap}} hook will open the swap partition so the kernel resume may use it. If you use special hooks for resuming from hibernation, make sure they are placed '''after''' {{ic|openswap}} in the {{ic|HOOKS}} array. Please note that because of initrd opening swap, there is no entry for swapDevice in {{ic|/etc/crypttab}} needed in this case.
=== Using a swap file for suspend-to-disk support ===
A swap file can be used to reserve swap-space within an existing partition and may also be setup inside an encrypted blockdevice's partition. When resuming from a swapfile the {{ic|resume}} hook must be supplied with the passphrase to unlock the device where the swap file is located. To create it: 
* Choose a mapped partition (e.g. {{ic|/dev/mapper/rootDevice}}) whose mounted filesystem (e.g. {{ic|/}}) contains enough free space to create a swapfile with the desired size.
* [[HOW_TO:_Create_swap_file#Swap_file_creation | Create the swap file]] (e.g. {{ic|/swapfile}}) inside the mounted filesystem of your chosen mapped partition.  Be sure to activate it with {{ic|swapon}} and also add it to your {{ic|/etc/fstab}} file afterward. Note that the swapfile's previous contents remain transparent over reboots.
* Set up your system to resume from your chosen mapped partition. For example, if you use [[GRUB]] with kernel hibernation support, add {{ic|resume<nowiki>=</nowiki>}}''your chosen mapped partition'' and {{ic|resume_offset<nowiki>=</nowiki>}}''see calculation command below'' to the kernel line in {{ic|/boot/grub/grub.cfg}}. A line with encrypted root partition can look like this:
kernel /vmlinuz-linux cryptdevice=/dev/sda2:rootDevice root=/dev/mapper/rootDevice resume=/dev/mapper/rootDevice resume_offset=123456789 ro
The {{ic|resume_offset}} of the swap-file points to the start (extent zero) of the file and can be identified like this:
# filefrag -v /swapfile | awk '{if($1==0){print $3}}'
* Add the {{ic|resume}} hook to your {{ic|etc/mkinitcpio.conf}} file and [[Mkinitcpio#Image_creation_and_activation|rebuild the image]] afterward:
HOOKS="... encrypt '''resume''' ... filesystems ..."
* If you use a USB keyboard to enter your decryption password, then the {{ic|keyboard}} module '''must''' appear in front of the {{ic|encrypt}} hook, as shown below.  Otherwise, you will not be able to boot your computer because you couldn't enter your decryption password to decrypt your Linux root partition! (If you still have this problem after adding {{ic|keyboard}}, try {{ic|usbinput}}, though this is deprecated.)
HOOKS="... '''keyboard''' encrypt ..."
== Encrypting a loopback filesystem ==
== Encrypting a loopback filesystem ==

Revision as of 13:33, 18 November 2013

zh-CN:System Encryption with LUKS

Merge-arrows-2.pngThis article or section is a candidate for merging with Plain dm-crypt without LUKS.Merge-arrows-2.png

Notes: Assess the possibility of merging the common content between the two articles in order to avoid duplication. (Discuss in Talk:Plain dm-crypt without LUKS#Merge)

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.


Warning: Encrypting a disk or partition will erase everything currently on that disk or partition:
  • Please make appropriate data backups prior to starting

Also be aware that encrypting a system might not only make the life of laptop thieves more miserable, but also yours if you don't plan ahead on

  • how to make secure backups of the encrypted system/-setup/data and
  • how to access the encrypted system manually for maintenance.
Keeping those points in mind while deciding on how to use encryption may help to decide on method and tools as well.

Initial Setup

Overview and Preparation

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:

  • Secure erasure of the hard disk drive(s)
  • Partitioning and setup of encryption (LVM optional)
  • Routine package selection and installation
  • System configuration to handle the encryption

This page covers the first two points in a general way for different configuration options available with LUKS.

The third and fourth point are covered in the later sections. Since the Arch installation media comes with all the tools required for system encryption, you can follow the Installation Guide or the Beginners' Guide after the encrypted partitions are set up. You will have to adjust the system configuration to be able to boot from your LUKS-volumes though, which is also covered in setup examples in the later sections.

Encrypting a system partition

Note: This install example covers the a full system encryption with dmcrypt+LUKS in a simple partition layout. For other partition layouts, e.g. LVM, please see the other examples.

Most of the installation of an encrypted system partition can be carried out normally. However, there are a few areas where it is important to make certain selections. These are marked below.

Prepare hard drive for Arch Install Scripts

This assumes you want to install an encrypted system with the Arch Install Scripts, have created partitions for / (e.g. /dev/sdaX) and /boot (/dev/sdaY) at least, following the Installation Guide and deciding against using LVM. Prior to creating the partitions you have done a preparation of the disk for encryption according to your necessities (the necessary tools are on the installation-ISO).

First check, if the blockdevice mapper dm_mod is loaded with

# lsmod | grep mod 

If one wants to use the default LUKS-cipher algorithm, there is no need to specify one for the luksFormat. You may want to check the defaults used by the cryptsetup version at time of installation and decide yourself. With defaults a dm-crypt/LUKS blockdevice for the crypted root can be created

# cryptsetup -y -v luksFormat /dev/sdaX


# cryptsetup open /dev/sdaX cryptroot

formatted with your desired filesystem

# mkfs -t ext4 /dev/mapper/cryptroot

and mounted

# mount -t ext4 /dev/mapper/cryptroot /mnt

At this point, just before installing the base system, it might be useful to check the mapping works as intended:

# umount /mnt
# cryptsetup close cryptroot

and mount it again to check.

If you created a separate /home partition, the steps have to be adapted and repeated for that. In LUKS#Encrypting_the_home_partition the creation is described and in LUKS#Crypttab how to activate the automount during boot. Note that each blockdevice requires its own passphrase. This may be inconvenient, because it results in a separate passphrase to be input during boot. An alternative is to use a key-file stored in the system partition to unlock the separate partition via crypttab. How that is done may be derived from the LVM example below. If you leave unpartitioned disk space, the necessary configuration for the /home partition may be done later too along with migrating data.

What you do have to setup is a non-encrypted /boot partition, which is needed for a crypted root. For a standard MBR/non-EFI /boot partition that may be achieved by formatting

# mkfs -t ext2 /dev/sdaY

creating a mount-point for installation

# mkdir /mnt/boot

and mounting it

# mount -t ext2 /dev/sdaY /mnt/boot

That is basically what is necessary at this point before installing the base system with the Arch Install Scripts. Take care to install the bootloader to /mnt/boot with the pacstrap script. Additional configuration steps must be followed before booting the installed system.

Configure initramfs

One important point is to add the hooks relevant for your particular install in the correct order to /etc/mkinitcpio.conf. The one you have to add when encrypting the root filesystem is encrypt. A recommended hook for LUKS encrypted blockdevices is shutdown to ensure controlled unmounting during system shutdown. Others needed, e.g. keymap, should be clear from other manual steps you follow during the installation and further details in the following. For detailed information about initramfs configuration and available Hooks refer to Mkinitcpio#HOOKS.

Note: The encrypt hook is only needed if your root partition is a LUKS partition (or a LUKS partition that needs to be mounted before root). The encrypt hook is not needed for any other encrypted partitions (swap, for example). System initialization scripts (/etc/rc.sysinit and /etc/crypttab among others) take care of those.

It is important that the encrypt hook comes before the filesystems hook (in case you are using LVM on LUKS, the order should be: encrypt lvm2 filesystems), so make sure that your HOOKS array looks something like this:

HOOKS="(base udev) ... encrypt ... filesystems ..."

If you need support for foreign keymaps for your encryption password, you have to specify the hook keymap as well before encrypt.

If you have a USB keyboard, you will need the keyboard hook. Without it, no USB keyboard will work in early userspace. If you still have this problem after adding keyboard, try usbinput, though this is deprecated.

In the same file, you may want to add to "MODULES" dm_mod and the filesystem types used, e.g: MODULES="dm_mod ext4"

After you are done don't forget:

mkinitcpio -p linux

Kernel parameter configuration of the bootloader

In order to enable booting an encrypted root partition, it is passed to the encrypt hook with kernel parameters to be set up in the bootloader. The main parameter is cryptdevice, with the following syntax:

The path to the raw encrypted device. Usage of Persistent block device naming is advisable.
The name given to the device after decryption, will be available as /dev/mapper/<dmname>. (<dmname> MUST NOT be set to a name already used for LVM partitions!)

So if the encrypted root device in the example is /dev/sda2 and the decrypted one should be mapped to /dev/mapper/cryptroot, the kernel parameter would be:


This will make the system prompt for the passphrase to unlock the root device on a cold boot.

Depending on the setup other parameters are required as well:

cryptdevice=<device>:<dmname> root=<device> resume=<device> cryptkey=<device>:<fstype>:<path>
The device file of the actual (decrypted) root filesystem. If the filesystem is formatted directly on the decrypted device file this will be /dev/mapper/<dmname>. If LVM is used, the device must be addressed like /dev/mapper/<volgroup>-<pvol> or /dev/<volgroup>/<pvol>.
The device file of the decrypted (swap) filesystem used for suspend2disk.
Required for reading a keyfile from a filesystem.

The syntax for the optional cryptkey parameter is:

The raw block device where the key exists.
The filesystem type of <device> (or auto).
The absolute path of the keyfile within the device.

Examples on configuration for GRUB and Syslinux are available on the respective pages.


Further, double-check the genfstab scripts result for your /dev/mapper/cryptroot and other mounts.

Encrypting the home partition

This example covers encryption of a home partition or comparable other partition containing user data. For full system encryption see Encrypting a system partition. You can either have a single user's home directory on a partition, or create a common partition for all user's home partitions.

Prepare the hard disk drive by performing a secure erasure. Create at least one partition, that will be used as home partition, with a partitioning tool of your choice. Note that the secure erasure can also be done to that single partition only. Setup the LUKS and dm-crypt magic with

# cryptsetup  [OPTION...] luksFormat <device>

as described in the section Mapping Physical Partitions to LUKS. In the above command replace <device> with the previously created home partition.

To gain access to the encrypted partition, unlock it with the device mapper, using

# cryptsetup open <device> <name> 

It is recommended to read the full explanation about this command here.

After unlocking the partition, it will be available at /dev/mapper/<name>. Now create a filesystem of your choice with

# mkfs.fstype /dev/mapper/<name>

Mount the filesystem to /home, or if it should be accessible to only one user to /home/username. Before shutting down the filesystem needs to unmounted and, in this order, the LUKS partition needs to be closed with

# cryptsetup close <name>

Automated unlocking and mounting

There are two different solutions for automating the process of unlocking the home partition and mounting its filesystem. Using crypttab, unlocking happens at boot time, and with Pam mount it happens on user login.


This is the recommended solution if you want to use one common partition for all user's home partitions. To make systemd open and mount the encrypted partition on boot, two files need to be edited, /etc/crypttab and /etc/fstab. The /etc/crypttab file describes encrypted block devices that are set up during system boot by systemd-cryptsetup-generator automatically.

For example, to open the encrypted LUKS partition on the device /dev/sdx1 with the name home, add this line:

home /dev/sdx1 none luks

The option none will trigger a prompt during boot to type the passphrase for unlocking the partition. A keyfile can also be set up and referenced instead. This results in an automatic unlocking, if the keyfile is accessible during boot. Since LUKS offers the option to have multiple keys, the chosen option can also be changed later.

See man crypttab (5) and read the file /etc/crypttab for more information.

Edit /etc/fstab and add an entry for the previously created path in /dev/mapper. Following above example the fstab entry looks like this:

/dev/mapper/home /home <filesystem> defaults 0 2

Pam mount

This is the recommended solution if you want to have a single user's home directory on a partition. To automount user homes on login see Pam mount.

Encrypting a loopback filesystem

A loop device enables to map a blockdevice to a file with the standard util-linux tool losetup. The file can then contain a filesystem, which can be used quite like any other filesystem. A lot of users know Truecrypt as a tool to create encrypted containers. Just about the same functionality can be achieved with a loopback filesystem encrypted with LUKS and is shown in the following example.

Preparation and mapping

First, start by creating an encrypted container!

dd if=/dev/urandom of=/bigsecret bs=1M count=10

This will create the file bigsecret with a size of 10 megabytes.

losetup /dev/loop0 /bigsecret

This will create the device node /dev/loop0, so that we can mount/use our container.

Note: If it gives you the error /dev/loop0: No such file or directory, you need to first load the kernel module with modprobe loop. These days (Kernel 3.2) loop devices are created on demand. Ask for a new loop device with losetup -f.
cryptsetup luksFormat /dev/loop0

This will ask you for a password for your new container file.

Note: If you get an error like Command failed: Failed to setup dm-crypt key mapping. Check kernel for support for the aes-cbc-essiv:sha256 cipher spec and verify that /dev/loop0 contains at least 133 sectors, then run modprobe dm-mod.
cryptsetup open --type luks /dev/loop0 secret

The encrypted container is now available through the device file /dev/mapper/secret. Now we are able to create a partition in the container:

mkfs.ext2 /dev/mapper/secret

and mount it...

mkdir /mnt/secret
mount -t ext2 /dev/mapper/secret /mnt/secret

We can now use the container as if it was a normal partition! To unmount the container:

umount /mnt/secret
cryptsetup luksClose secret
losetup -d /dev/loop0 # free the loopdevice.

so, if you want to mount the container again, you just apply the following commands:

losetup /dev/loop0 /bigsecret
cryptsetup open --type luks /dev/loop0 secret
mount -t ext2 /dev/mapper/secret /mnt/secret

Encrypt using a key-file

Let us first generate a 2048 byte random keyfile:

dd if=/dev/urandom of=keyfile bs=1k count=2

We can now format our container using this key

cryptsetup luksFormat /dev/loop0 keyfile

or our partition :

cryptsetup luksFormat /dev/hda2 keyfile

Once formatted, we can now open the LUKS device using the key:

cryptsetup -d keyfile open --type luks /dev/loop0 container

You can now like before format the device /dev/mapper/container with your favorite filesystem and then mount it just as easily.

The keyfile is now the only key to your file. I personally advise encrypting your keyfile using your private GPG key and storing an off-site secured copy of the file.

Resizing the loopback filesystem

First we should unmount the encrypted container:

umount /mnt/secret
cryptsetup luksClose secret
losetup -d /dev/loop0 # free the loopdevice.

After this we need to expand our container file with the size of the data we want to add:

dd if=/dev/urandom bs=1M count=1024 | cat - >> /bigsecret

Be careful to really use TWO >, or you will override your current container!

You could use /dev/zero instead of /dev/urandom to significantly speed up the process, but with /dev/zero your encrypted filesystems will not be as secure. (A better option to create random data quicker than /dev/urandom is frandom [1], available from the AUR). A faster (almost instant) method than dd is truncate , but its use has the same security implications as using /dev/zero. The size passed to truncate is the final size to make the file, so don't use a value less than that of the current file or you will lose data. e.g. to increase a 20G file by 10G: truncate -s 30G filename.

Now we have to map the container to the loop device:

losetup /dev/loop0 /bigsecret
cryptsetup open --type luks /dev/loop0 secret

After this we will resize the encrypted part of the container to the maximum size of the container file:

cryptsetup resize secret

Finally, we can resize the filesystem. Here is an example for ext2/3/4:

e2fsck -f /dev/mapper/secret # Just doing a filesystem check, because it's a bad idea to resize a broken fs
resize2fs /dev/mapper/secret

You can now mount your container again:

mount /dev/mapper/secret /mnt/secret

Encrypting a LVM setup

It is easy to use encryption with LVM. This section describes specific aspects of setting up an encrypted LVM setup and has a mini-howto for users with experiences of using both, cryptsetup and LVM. If you are looking for verbose installation instructions of such a setup, you might want to read Encrypted_LVM first.

If you do not know how to set up LVM, then read Installing with Software RAID or LVM. Using LVM is particularly helpful when a system with multiple partitions is planned. While there are a number of alternatives for unlocking multiple partitions with the same passphrase/key, the default Arch mkinitcpio hooks do not implement non-standard ways. A combination of the encrypt and lvm2 hooks, however, enables to setup a system with numerous logical volumes as partitions while using one passphrase/key to unlock them.


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.

The most important thing in setting LVM on top of encryption is to configure the initramfs for running both the encrypt hook and the lvm2 hook (and those two before the filesystems hook). In the past, it was necessary to ensure the correct ordering of these hooks in /etc/mkinitcpio.conf but the order no longer matters with the current implementation of lvm2.


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 around a mixture of encrypted and non-encrypted volumes/partitions is possible as well.

For encrypted partitions inside an LVM, the LVM-hook has to run first, before the respective encrypted logical volumes can be unlocked. So for this add the encrypt hook in /etc/mkinitcpio.conf after the lvm2 hook, if you chose to set up encrypted partitions on top of LVM.

Both these options are described in more detail in Encrypted_LVM. The following represents the historic guide from before the verbose page.

LVM and dm-crypt manually (short version)

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. For cryptsetup options, please see above.

Partitioning scheme

/dev/sda1 -> /boot
/dev/sda2 -> LVM

Setting up the encrypted system

cryptsetup -d /dev/random -c aes-xts-plain -s 512 create lvm /dev/sda2
dd if=/dev/urandom of=/dev/mapper/lvm
cryptsetup remove lvm
lvm pvcreate /dev/sda2
lvm vgcreate lvm /dev/sda2
lvm lvcreate -L 10G -n root lvm
lvm lvcreate -L 500M -n swap lvm
lvm lvcreate -L 500M -n tmp lvm
lvm lvcreate -l 100%FREE -n home lvm
cryptsetup luksFormat -c aes-xts-plain -s 512 /dev/lvm/root
cryptsetup open --type luks /dev/lvm/root root
mkreiserfs /dev/mapper/root
mount /dev/mapper/root /mnt
dd if=/dev/zero of=/dev/sda1 bs=1M
mkreiserfs /dev/sda1
mkdir /mnt/boot
mount /dev/sda1 /mnt/boot
mkdir -p -m 700 /mnt/etc/luks-keys
dd if=/dev/random of=/mnt/etc/luks-keys/home bs=1 count=256

Install Arch Linux

Now after setup of the encrypted LVM partitioning, it would be time to install: Arch Install Scripts.



Put lvm2 and encrypt (in that order) before filesystems in the HOOKS array. Again, note that this is setting encryption on top of LVM.

If you want install the system on a usb stick, you need to put usb just after udev.

Boot options for LUKS-LVM

For the above example, change the kernel options for the root-device auto-configured in the bootloader installation from root=/dev/hda3 to

cryptdevice=/dev/lvm/root:root root=/dev/mapper/root

More general, the kernel command line for LUKS <-> LVM is constructed like this:

root=/dev/mapper/<volume-group>-<logical-volume> cryptdevice=/dev/<luks-part>:<volume-group>

For example:

root=/dev/mapper/vg-arch cryptdevice=/dev/sda4:vg

Or like this:

cryptdevice=/dev/<volume-group>/<logical-volume>:root root=/dev/mapper/root

If you want install the system on a usb stick, you need to add lvmdelay=/dev/mapper/lvm-root

Filesystem mounts system
 /dev/mapper/root        /       reiserfs        defaults        0       1
 /dev/sda1               /boot   reiserfs        defaults        0       2
 /dev/mapper/tmp         /tmp    tmpfs           defaults        0       0
 /dev/mapper/swap        none    swap            sw              0       0
 swap	/dev/lvm/swap	SWAP		-c aes-xts-plain -h whirlpool -s 512
 tmp	/dev/lvm/tmp	/dev/urandom	-c aes-xts-plain -s 512
Encrypting /home after reboot
cryptsetup luksFormat -c aes-xts-plain -s 512 /dev/lvm/home /etc/luks-keys/home
cryptsetup open --type luks -d /etc/luks-keys/home /dev/lvm/home home
mkreiserfs /dev/mapper/home
mount /dev/mapper/home /home
Filesystem mounts home
 home	/dev/lvm/home   /etc/luks-keys/home
 /dev/mapper/home        /home   reiserfs        defaults        0       0


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 LVM), 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 HOOKS=" ... usb usbinput (etwo or ssldec) encrypt(if using openssl) lvm2 resume ... " and you should add "resume=/dev/mapper/<VolumeGroupName>-<LVNameOfSwap>" to your kernel parameters.

  • If you need to temporarily store the unecrypted keyfile somewhere, do not store them on an unencrypted disk. Even better make sure to store them to RAM such as /dev/shm.
  • If you want to use a GPG encrypted keyfile, you need to use a statically compiled GnuPG version 1.4 or you could edit the hooks and use this AUR package gnupg1
  • It is possible that an update to OpenSSL could break the custom ssldec mentioned in the second forum post.

Remote unlocking of the root (or other) partition

If you want to be able to reboot a fully LUKS-encrypted system remotely, or start it with a Wake-on-LAN service, you will need a way to enter a passphrase for the root partition/volume at startup. This can be achieved by running the net hook along with an SSH server in initrd. Install the dropbear_initrd_encryptAUR package from the AUR and follow the post-installation instructions. Replace the encrypt hook with dropbear encryptssh in /etc/mkinitcpio.conf. Put the net hook early in the HOOKS array if your DHCP server takes a long time to lease IP addresses.

If you would simply like a nice solution to mount other encrypted partitions (such as /home)remotely, you may want to look at this forum thread.

Modifying the encrypt hook for a non-root partition

Maybe you have a requirement for using the encrypt hook on a non-root partition. Arch 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.

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 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 root=/dev/md0 ro md=0,/dev/sda1,/dev/sdb1 md=1,/dev/sda5,/dev/sdb5,/dev/sdc5

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: chkbootAUR

After installation:

  • For classical sysvinit: add /usr/local/bin/chkboot.sh & to your /etc/rc.local
  • For systemd: add a service file and enable the service: systemd. The service file might look like:
Description=Check that boot is what we want



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.

As /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:

# 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/chkboot_user.sh		# insert your logged on <user> 
sync							# sync disks with any results 
sudo -u <user> /usr/local/bin/chkboot_user.sh		# insert your logged on <user> 
echo "Pacman update [2] Syncing repos for pacman" 
pacman -Syu
sudo -u <user> /usr/local/bin/chkboot_user.sh		# insert your logged on <user>
echo "Pacman update [3] 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.


  • cryptsetup FAQ - The main and foremost help resource, directly from the developers.
  • FreeOTFE - Supports unlocking LUKS encrypted volumes in Microsoft Windows.