Difference between revisions of "Dm-crypt/Encrypting an entire system"

From ArchWiki
Jump to: navigation, search
(Configuring the boot loader: rm tag; done.)
(fixed section fragments, flagged broken section links, simplification and beautification of wikilinks (interactive))
(Tag: wiki-scripts)
 
(248 intermediate revisions by 35 users not shown)
Line 1: Line 1:
 
{{Lowercase title}}
 
{{Lowercase title}}
[[Category:Security]]
+
[[Category:Encryption]]
 
[[Category:File systems]]
 
[[Category:File systems]]
 
[[Category:Getting and installing Arch]]
 
[[Category:Getting and installing Arch]]
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 Guide|installation procedure]]. All the necessary tools are on the [https://www.archlinux.org/download/ installation image].
+
[[de:Systemverschlüsselung mit dm-crypt]]
 +
[[es:Dm-crypt/Encrypting an entire system]]
 +
[[ja:Dm-crypt/システム全体の暗号化]]
 +
Back to [[dm-crypt]].
 +
 
 +
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 guide|installation procedure]]. All the necessary tools are on the [https://www.archlinux.org/download/ installation image].
  
 
== Overview ==
 
== Overview ==
  
Securing a root filesystem is where dm-crypt excels. 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 {{ic|/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.
+
Securing a root filesystem is where ''dm-crypt'' excels, feature and performance-wise. 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 {{ic|/var/log/}}. Furthermore, an encrypted root filesystem makes tampering with the system far more difficult, as everything except the [[boot loader]] and (usually) the kernel is encrypted.
 +
 
 +
All scenarios illustrated in the following share these advantages, other pros and cons differentiating them are summarized below: 
 +
 
 +
{| class="wikitable"
 +
! Scenarios
 +
! Advantages
 +
! Disadvantages
 +
|----------------------------------------------------------
 +
| [[#Simple partition layout with LUKS]]
 +
shows a basic and straight-forward set-up for a fully LUKS encrypted root.
 +
|
 +
* Simple partitioning and setup
 +
|
 +
* Inflexible; disk-space to be encrypted has to be pre-allocated
 +
|----------------------------------------------------------
 +
| [[#LVM on LUKS]]
 +
achieves partitioning flexiblity by using LVM inside a single LUKS encrypted partition.
 +
|
 +
* Simple partitioning with knowledge of LVM
 +
* Only one key required to unlock all volumes (e.g. easy resume-from-disk setup)
 +
* Volume layout not transparent when locked
 +
* Easiest method to allow [[Dm-crypt/Swap_encryption#With_suspend-to-disk_support|suspension to disk]]
 +
|
 +
* LVM adds an additional mapping layer and hook 
 +
* Less useful, if a singular volume should receive a separate key
 +
|----------------------------------------------------------
 +
| [[#LUKS on LVM]]
 +
uses dm-crypt only after the LVM is setup.
 +
|
 +
* LVM can be used to have encrypted volumes span multiple disks
 +
* Easy mix of un-/encrypted volume groups
 +
|
 +
* Complex; changing volumes requires changing encryption mappers too
 +
* Volumes require individual keys
 +
* LVM layout is transparent when locked
 +
|----------------------------------------------------------
 +
| [[#Plain dm-crypt]]
 +
uses dm-crypt plain mode, i.e. without a LUKS header and its options for multiple keys. <br>This scenario also employs USB devices for {{ic|/boot}} and key storage, which may be applied to the other scenarios.
 +
|
 +
* Data resilience for cases where a LUKS header may be damaged
 +
* Allows [[Wikipedia:Disk encryption#Full disk encryption|Full Disk Encryption]]
 +
* Helps addressing [[Dm-crypt/Specialties#Discard/TRIM support for solid state drives (SSD)|problems]] with SSDs
 +
|
 +
* High care to all encryption parameters is required
 +
* Single encryption key and no option to change it 
 +
|----------------------------------------------------------
 +
| [[#Encrypted boot partition (GRUB)]]
 +
shows how to encrypt the boot partition using the GRUB bootloader. <br> This scenario also employs an ESP partition, which may be applied to the other scenarios.
 +
|
 +
* Same advantages as the scenario the installation is based on (LVM on LUKS for this particular example)
 +
* Less data is left unencrypted, i.e. the boot loader and the ESP partition, if present
 +
|
 +
* Same disadvantages as the scenario the installation is based on (LVM on LUKS for this particular example)
 +
* More complicated configuration
 +
* Not supported by other boot loaders
 +
|----------------------------------------------------------
 +
| [[#Btrfs subvolumes with swap]]
 +
shows how to encrypt a [[Btrfs]] system, including the {{ic|/boot}} directory, also adding a partition for swap, on UEFI hardware.
 +
|
 +
* Similar advantages as [[#Encrypted boot partition (GRUB)]]
 +
* Availability of Btrfs' features
 +
|
 +
* Similar disadvantages as [[#Encrypted boot partition (GRUB)]]
 +
|}
 +
 
 +
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.
 +
 
 +
See [[Dm-crypt/Drive preparation#Partitioning]] for a general overview of the partitioning strategies used in the scenarios.
  
In encrypted root filesystem scenarios, dm-crypt is often combined with other disk abstraction technologies such as [[#LVM on LUKS|LVM]] and [[#LUKS on software RAID|RAID]], although it is by no means necessary.
+
Another area to consider is whether to set up an encrypted swap partition and what kind. See [[Dm-crypt/Swap encryption]] for alternatives.
  
While an encrypted root filesystem provides much greater protection from outside threats than encrypted secondary filesystems, any user of the system is able to decrypt the entire drive, and therefore can access other users' data. However, it is possible to use a combination of root and non-root filesystem encryption and reap the advantages of both. It is important to balance the benefits with the effort, as an encrypted root filesystem is more difficult to setup than an encrypted secondary filesystem.
+
If you anticipate to protect the system's data not only against physical theft, but also have a requirement of precautions against logical tampering, see [[Dm-crypt/Specialties#Securing the unencrypted boot partition]] for further possibilities after following one of the scenarios.
  
 
== Simple partition layout with LUKS ==
 
== Simple partition layout with LUKS ==
  
This example covers a full system encryption with ''dmcrypt''+ LUKS in a simple partition layout:
+
This example covers a full system encryption with ''dmcrypt'' + LUKS in a simple partition layout:
  
 
  +--------------------+--------------------------+--------------------------+
 
  +--------------------+--------------------------+--------------------------+
Line 26: Line 99:
  
 
=== Preparing the disk ===
 
=== Preparing the disk ===
Prior to creating any partitions, securely erase the disk as described in [[Dm-crypt/Drive Preparation#Secure erasure of the hard disk drive]].
+
Prior to creating any partitions, you should inform yourself about the importance and methods to securely erase the diskdescribed in [[Dm-crypt/Drive preparation]].
  
 
Then create the needed partitions, at least one for {{ic|/}} (e.g. {{ic|/dev/sdaX}}) and {{ic|/boot}} ({{ic|/dev/sdaY}}), see [[Partitioning]].
 
Then create the needed partitions, at least one for {{ic|/}} (e.g. {{ic|/dev/sdaX}}) and {{ic|/boot}} ({{ic|/dev/sdaY}}), see [[Partitioning]].
Line 32: Line 105:
 
=== Preparing non-boot partitions ===
 
=== Preparing non-boot partitions ===
  
Then follow the same procedure described in details in [[Dm-crypt/Encrypting a non-root file system#Partition]] (which, despite the title, ''can'' be applied to root partitions, as long as [[#Configuring mkinitcpio|mkinitcpio]] and the [[#Configuring the boot loader|boot loader]] are then correctly configured).  
+
The following commands create and mount the encrypted root partition. They correspond to the procedure described in detail in [[Dm-crypt/Encrypting a non-root file system#Partition]] (which, despite the title, ''can'' be applied to root partitions, as long as [[#Configuring mkinitcpio|mkinitcpio]] and the [[#Configuring the boot loader|boot loader]] are correctly configured).  
If you want to use special encryption options (e.g. cipher, key length), see the [[Dm-crypt/Device_Encryption#Encryption_options_for_LUKS_mode|encryption options]] before executing the first command:
+
If you want to use particular non-default encryption options (e.g. cipher, key length), see the [[Dm-crypt/Device encryption#Encryption_options_for_LUKS_mode|encryption options]] before executing the first command:
  
 
  # cryptsetup -y -v luksFormat /dev/sdaX
 
  # cryptsetup -y -v luksFormat /dev/sdaX
Line 46: Line 119:
 
  # mount -t ext4 /dev/mapper/cryptroot /mnt
 
  # mount -t ext4 /dev/mapper/cryptroot /mnt
  
If you created separate partitions (e.g. {{ic|/home}}), these steps have to be adapted and repeated for all of them, ''except'' for {{ic|/boot}}.
+
If you created separate partitions (e.g. {{ic|/home}}), these steps have to be adapted and repeated for all of them, ''except'' for {{ic|/boot}}. See [[Dm-crypt/Encrypting a non-root file system#Automated unlocking and mounting]] on how to handle additional partitions at boot.
  
See [[Dm-crypt_with_LUKS/Encrypting_a_non-root_file_system#Automated_unlocking_and_mounting]] for automated unlocking and mounting of additional partitions at 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 keyfile stored in the system partition to unlock the separate partition via {{ic|crypttab}}. See [[Dm-crypt/Device encryption#Using LUKS to format partitions with a keyfile]] for instructions.
 
+
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 keyfile stored in the system partition to unlock the separate partition via {{ic|crypttab}}. See [[Dm-crypt/Device Encryption#Using LUKS to Format Partitions_with a Keyfile]] for instructions.
+
  
 
=== Preparing the boot partition ===
 
=== Preparing the boot partition ===
Line 59: Line 130:
  
 
=== Mounting the devices ===
 
=== Mounting the devices ===
At [[Installation Guide#Mount the partitions]] you will have to mount the mapped devices, not the actual partitions. Of course {{ic|/boot}}, which is not encrypted, will still have to be mounted directly.
+
At [[Installation guide#Mount the partitions]] you will have to mount the mapped devices, not the actual partitions. Of course {{ic|/boot}}, which is not encrypted, will still have to be mounted directly.
 +
 
 +
Afterwards continue with the installation procedure up to the mkinitcpio step.
  
 
=== Configuring mkinitcpio ===
 
=== Configuring mkinitcpio ===
Add the {{ic|encrypt}} hook to [[mkinitcpio.conf]] before {{ic|filesystems}}:
+
Add the {{ic|encrypt}} hook to [[mkinitcpio.conf]]:
 
{{hc|etc/mkinitcpio.conf|2=HOOKS="... '''encrypt''' ... filesystems ..."}}
 
{{hc|etc/mkinitcpio.conf|2=HOOKS="... '''encrypt''' ... filesystems ..."}}
  
See [[dm-crypt/System Configuration#mkinitcpio]] for details and other hooks that you may need.
+
Depending on which other hooks are used, the order may be relevant. See [[dm-crypt/System configuration#mkinitcpio]] for details and other hooks that you may need.
  
 
=== Configuring the boot loader ===
 
=== Configuring the boot loader ===
In order to boot the encrypted root partition, the following [[kernel parameter]] needs to be set in your [[boot loader]]:
+
In order to unlock the encrypted root partition at boot, the following kernel parameters need to be set by the boot loader:  
  
  cryptdevice=/dev/sdaX:cryptroot
+
  cryptdevice=UUID=''<device-UUID>'':cryptroot root=/dev/mapper/cryptroot
  
See [[Dm-crypt/System Configuration#Boot loader]] for details and other parameters that you may need.
+
See [[Dm-crypt/System configuration#Boot loader]] for details.
 +
 
 +
The {{ic|''<device-UUID>''}} refers to the UUID of {{ic|/dev/sdaX}}, see [[Persistent block device naming]] for details.
  
 
== LVM on LUKS ==
 
== 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.
+
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 disk layout in this example is:
 +
+-----------------------------------------------------------------------+ +----------------+
 +
| Logical volume1      | Logical volume2      | Logical volume3      | |                |
 +
|/dev/mapper/MyVol-swap |/dev/mapper/MyVol-root |/dev/mapper/MyVol-home | | Boot partition |
 +
|_ _ _ _ _ _ _ _ _ _ _ _|_ _ _ _ _ _ _ _ _ _ _ _|_ _ _ _ _ _ _ _ _ _ _ _| | (may be on    |
 +
|                                                                      | | other device)  |
 +
|                        LUKS encrypted partition                      | |                |
 +
|                          /dev/sdaX                                    | | /dev/sdbY      |
 +
+-----------------------------------------------------------------------+ +----------------+
  
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]].
+
This method does not allow you to span the logical volumes over multiple disks, even in the future. The [[#LUKS on LVM]] method does not have this limitation.
  
{{Expansion|Compare to the other scenarios with advantages/disadvantages.}}
+
{{Tip|Two variants of this setup:
 +
* Instructions at [[Dm-crypt/Specialties#Encrypted system using a remote LUKS header]] use this setup with a remote LUKS header on a USB device to achieve a two factor authentication with it.
 +
* Instructions at [http://www.pavelkogan.com/2014/05/23/luks-full-disk-encryption/ Pavel Kogan's blog] show how to encrypt the {{ic|/boot}} partition while keeping it on the main LUKS partition when using GRUB, but be aware of {{Bug|43663}}.}}  
  
 
=== Preparing the disk ===
 
=== Preparing the disk ===
Prior to creating any partitions, securely erase the disk as described in [[Dm-crypt/Drive Preparation#Secure erasure of the hard disk drive]] (the necessary tools are on the installation ISO).
 
  
Then make the following partitions:
+
Prior to creating any partitions, you should inform yourself about the importance and methods to securely erase the disk, described in [[Dm-crypt/Drive preparation]].
*sdx1 - Size 2MB, Partition Type EF02  (This is so GRUB plays nice with GPT)
+
*sdx2 - Size 200mb, Partition Type 8300 (This is your /boot partition)
+
*sdx3 - Remaining space, Partition Type 8E00 (LVM)
+
  
After that, create the LUKS encrypted container (sdx3.  We do not encrypt /boot or the BIOS partition)
+
When using the [[GRUB]] bootloader together with [[GPT]], create a BIOS Boot Partition as explained in [[GRUB#BIOS systems]].
# 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 [[Dm-crypt/Device_Encryption#Encryption_options_for_LUKS_mode|LUKS]] page too. Enter your password twice.
+
Create a partition to be mounted at {{ic|/boot}} of type {{ic|8300}} with a size of 100 MB or more.
  
Now we open our container:
+
Create a partition of type {{ic|8E00}}, which will later contain the encrypted container.
  
# cryptsetup open --type luks /dev/sdx3 lvm
+
Create the LUKS encrypted container at the "system" partition. Enter the chosen password twice.
  
Your decrypted disk is now available at /dev/mapper/lvm
+
# cryptsetup luksFormat /dev/''sdaX''
 +
 
 +
For more information about the available cryptsetup options see the [[Dm-crypt/Device encryption#Encryption_options_for_LUKS_mode|LUKS encryption options]] prior to above command.
 +
 
 +
Open the container:
 +
 
 +
# cryptsetup open --type luks /dev/''sdaX'' lvm
 +
 
 +
The decrypted container is now available at {{ic|/dev/mapper/lvm}}.
  
 
=== Preparing the logical volumes ===
 
=== Preparing the logical volumes ===
 +
Create a physical volume on top of the opened LUKS container:
  
 
  # pvcreate /dev/mapper/lvm
 
  # pvcreate /dev/mapper/lvm
# vgcreate MyStorage /dev/mapper/lvm
 
# lvcreate -L 15G MyStorage -n rootvol
 
# lvcreate -L 35G MyStorage -n homevol
 
# lvcreate -L 2G MyStorage -n swapvol
 
# lvcreate -L 200G MyStorage -n mediavol
 
  
# mkfs.ext4 /dev/mapper/MyStorage-rootvol
+
Create the volume group named {{ic|MyVol}} (or whatever you want), adding the previously created physical volume to it:
# mkfs.ext4 /dev/mapper/MyStorage-homevvol
+
# mkswap /dev/mapper/MyStorage-swapvol
+
# mkfs.ext4 /dev/mapper/MyStorage-mediavol
+
  
  # mount /dev/MyStorage/rootvol /mnt
+
  # vgcreate MyVol /dev/mapper/lvm
# mkdir /mnt/home
+
# mount /dev/MyStorage/homevol /mnt/home
+
# swapon /dev/mapper/MyStorage-swapvol
+
  
  _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
+
Create all your logical volumes on the volume group:
  |Logical volume1 15GB |Logical volume2 35GB      |Logical volume3 200GB              |
+
 
  |/dev/MyStorage/rootvol|/dev/MyStorage/homevol    |/dev/MyStorage/mediavol            |
+
  # lvcreate -L 8G MyVol -n swap
|_ _ _ _ _ _ _ _ _ _ _ |_ _ _ _ _ _ _ _ _ _ _ _ _ |_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ |
+
  # lvcreate -L 15G MyVol -n root
|                                                                                      |
+
  # lvcreate -l 100%FREE MyVol -n home
  |                        (LUKS Encrypted Disk  /dev/sdxx)                              |
+
 
  |                                                                                      |
+
Format your filesystems on each logical volume:
  |--------------------------------------------------------------------------------------|
+
 
 +
# mkfs.ext4 /dev/mapper/MyVol-root
 +
# mkfs.ext4 /dev/mapper/MyVol-home
 +
# mkswap /dev/mapper/MyVol-swap
 +
 
 +
Mount your filesystems:
 +
 
 +
  # mount /dev/mapper/MyVol-root /mnt
 +
  # mkdir /mnt/home
 +
  # mount /dev/mapper/MyVol-home /mnt/home
 +
# swapon /dev/mapper/MyVol-swap
  
 
=== Preparing the boot partition ===
 
=== 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.  
+
The bootloader loads the kernel, [[initramfs]], and its own configuration files from the {{ic|/boot}} directory. This directory must be located on a separate unencrypted filesystem.  
  
Create an ext2 filesystem on the partition you created for /boot earlier (/dev/sdx2 in the example above).
+
Create an Ext2 filesystem on the partition intended for {{ic|/boot}}. Any filesystem that can be read by the bootloader is eligible.
# 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.
+
# mkfs.ext2 /dev/''sdbY''
# 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.)
+
Create the directory {{ic|/mnt/boot}}:
  
=== Configuring mkinitcpio ===
+
# mkdir /mnt/boot
Add the {{ic|encrypt}} and {{ic|lvm2}} hooks to [[mkinitcpio.conf]], before {{ic|filesystems}}:
+
{{hc|etc/mkinitcpio.conf|2=HOOKS="... '''encrypt''' '''lvm2''' ... filesystems ..."}}
+
  
{{Note|In the past, it was necessary to ensure the correct ordering of the {{ic|encrypt}} and {{ic|lvm2}} hooks, but the order no longer matters with the current implementation of {{ic|lvm2}}.}}
+
Mount the partition to {{ic|/mnt/boot}}:
  
See [[dm-crypt/System Configuration#mkinitcpio]] for details and other hooks that you may need.
+
# mount /dev/''sdbY'' /mnt/boot
  
=== Configuring the boot loader ===
+
Afterwards continue with the installation procedure up to the {{ic|mkinitcpio}} step.
In order to boot the encrypted root partition, the following [[kernel parameter]] needs to be set in your [[boot loader]]:
+
  
cryptdevice=/dev/sdx3:MyStorage
+
=== Configuring mkinitcpio ===
 +
Add the {{ic|encrypt}} and {{ic|lvm2}} hooks to [[mkinitcpio.conf]]:
 +
{{hc|/etc/mkinitcpio.conf|2=HOOKS="... '''encrypt''' '''lvm2''' ... filesystems ..."}}
  
See [[Dm-crypt/System Configuration#Boot loader]] for details and other parameters that you may need.
+
See [[dm-crypt/System configuration#mkinitcpio]] for details and other hooks that you may need.
  
{{Accuracy|Is the following note specific to encryption cases or should be moved to [[LVM]] or [[GRUB]]?}}
+
=== Configuring the boot loader ===
 +
In order to unlock the encrypted root partition at boot, the following kernel parameters need to be set by the boot loader:
  
{{Note|1=When reinstalling [[GRUB]], you may receive warnings like {{ic|/run/lvm/lvmetad.socket: connect failed: No such file or directory|}} or {{ic|WARNING: failed to connect to lvmetad: No such file or directory. Falling back to internal scanning|}}. This is because {{ic|/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.}}
+
cryptdevice=UUID=''device-UUID'':lvm root=/dev/mapper/MyVol-root
  
=== Checking fstab ===
+
The {{ic|''<device-UUID>''}} refers to the UUID of {{ic|/dev/sdaX}}, see [[Persistent block device naming]] for details.
"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.
+
 
 +
See [[Dm-crypt/System configuration#Boot loader]] for details.
  
 
== LUKS on LVM ==
 
== 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.
+
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 {{ic|/tmp}} and {{ic|/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.
+
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 {{ic|/tmp}} and {{ic|/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. If you want to span a logical volume over multiple disks during setup already, a procedure to do so is described in [[Dm-crypt/Specialties#Expanding LVM on multiple disks]].
  
{{Expansion|Compare to the other scenarios with advantages/disadvantages.}}
+
{{Expansion|The intro of this scenario needs some adjustment now that a comparison has been added to [[#Overview]]. A suggested structure is to make it similar to the [[#Simple partition layout with LUKS]] intro.}}
  
 
=== Preparing the disk ===
 
=== Preparing the disk ===
Line 177: Line 265:
 
* {{ic|/dev/sda2}} -> LVM
 
* {{ic|/dev/sda2}} -> LVM
  
Randomise {{ic|/dev/sda2}}:
+
Randomise {{ic|/dev/sda2}} according to [[Dm-crypt/Drive preparation#dm-crypt wipe before installation]]{{Broken section link}}.
cryptsetup -d /dev/random -c aes-xts-plain64 -s 512 create lvm /dev/sda2
+
dd if=/dev/urandom of=/dev/mapper/lvm
+
cryptsetup remove lvm
+
  
 
=== Preparing the logical volumes ===
 
=== Preparing the logical volumes ===
  
  lvm pvcreate /dev/sda2
+
  # lvm pvcreate /dev/sda2
  lvm vgcreate lvm /dev/sda2
+
  # lvm vgcreate lvm /dev/sda2
  lvm lvcreate -L 10G -n root lvm
+
  # lvm lvcreate -L 10G -n lvroot lvm
  lvm lvcreate -L 500M -n swap lvm
+
  # lvm lvcreate -L 500M -n swap lvm
  lvm lvcreate -L 500M -n tmp lvm
+
  # lvm lvcreate -L 500M -n tmp lvm
  lvm lvcreate -l 100%FREE -n home lvm
+
  # lvm lvcreate -l 100%FREE -n home lvm
  
  cryptsetup luksFormat -c aes-xts-plain64 -s 512 /dev/lvm/root
+
  # cryptsetup luksFormat -c aes-xts-plain64 -s 512 /dev/lvm/lvroot
  cryptsetup open --type luks /dev/lvm/root root
+
  # cryptsetup open --type luks /dev/lvm/lvroot root
  mkreiserfs /dev/mapper/root
+
  # mkfs -t ext4 /dev/mapper/root
  mount /dev/mapper/root /mnt
+
  # mount /dev/mapper/root /mnt
  
Note that {{ic|/home}} will be encrypted [[#Encrypting /home after reboot|after rebooting]].
+
More information about the encryption options can be found in [[Dm-crypt/Device encryption#Encryption options for LUKS mode]].
 +
Note that {{ic|/home}} will be encrypted in [[#Encrypting logical volume /home]]. Further, note that if you ever have to access the encrypted root from the Arch-ISO, the above {{ic|open}} action will allow you to after the [[LVM#Logical Volumes do not show_up|LVM shows up]].
  
 
=== Preparing the boot partition ===
 
=== Preparing the boot partition ===
  dd if=/dev/zero of=/dev/sda1 bs=1M
+
  # dd if=/dev/zero of=/dev/sda1 bs=1M
  mkreiserfs /dev/sda1
+
  # mkfs -t ext4 /dev/sda1
  mkdir /mnt/boot
+
  # mkdir /mnt/boot
  mount /dev/sda1 /mnt/boot
+
  # mount /dev/sda1 /mnt/boot
  
Now after setup of the encrypted LVM partitioning, it would be time to install: [[Installation_Guide#Mount_the_partitions|Arch Install Scripts]].
+
Now after setup of the encrypted LVM partitioning, it would be time to install: [[Installation guide#Mount_the_partitions|Arch Install Scripts]].
  
 
=== Configuring mkinitcpio ===
 
=== Configuring mkinitcpio ===
{{Accuracy|Does the order of {{ic|lvm2}} and {{ic|encrypt}} matter in this case? Compare to [[#Configuring mkinitcpio 2]].}}
 
  
Add the {{ic|lvm2}} and {{ic|encrypt}} hooks to [[mkinitcpio.conf]], before {{ic|filesystems}}:
+
Add the {{ic|lvm2}} and {{ic|encrypt}} hooks to [[mkinitcpio.conf]]:
{{hc|etc/mkinitcpio.conf|2=HOOKS="... '''lvm2''' '''encrypt''' ... filesystems ..."}}
+
{{hc|etc/mkinitcpio.conf|2=HOOKS="... '''block'' ''''encrypt''' '''lvm2''' ... filesystems ..."}}
  
See [[dm-crypt/System Configuration#mkinitcpio]] for details and other hooks that you may need.
+
See [[dm-crypt/System configuration#mkinitcpio]] for details and other hooks that you may need.
  
 
=== Configuring the boot loader ===
 
=== Configuring the boot loader ===
 +
In order to unlock the encrypted root partition at boot, the following kernel parameters need to be set by the boot loader:
  
For the above example, change the kernel options for the root-device auto-configured in the bootloader installation from {{ic|root<nowiki>=</nowiki>/dev/hda3}} to
+
  cryptdevice=/dev/lvm/lvroot:cryptoroot root=/dev/mapper/cryptoroot
  cryptdevice=/dev/lvm/root:root root=/dev/mapper/root
+
  
More general, the kernel command line for LUKS <-> LVM is constructed like this:
+
See [[Dm-crypt/System configuration#Boot loader]] for details.
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 {{ic|lvmdelay<nowiki>=</nowiki>/dev/mapper/lvm-root}}
+
  
 
=== Configuring fstab and crypttab ===
 
=== Configuring fstab and crypttab ===
 
{{hc|/etc/fstab|
 
{{hc|/etc/fstab|
  /dev/mapper/root        /      reiserfs        defaults        0      1
+
  /dev/mapper/root        /      ext4            defaults        0      1
  /dev/sda1              /boot  reiserfs        defaults        0      2
+
  /dev/sda1              /boot  ext4            defaults        0      2
 
  /dev/mapper/tmp        /tmp    tmpfs          defaults        0      0
 
  /dev/mapper/tmp        /tmp    tmpfs          defaults        0      0
 
  /dev/mapper/swap        none    swap            sw              0      0}}
 
  /dev/mapper/swap        none    swap            sw              0      0}}
 
+
The following [[Dm-crypt/System_configuration#crypttab|crypttab]] options will re-encrypt the temporary filesystems each reboot:
 
{{hc|/etc/crypttab|
 
{{hc|/etc/crypttab|
  swap /dev/lvm/swap SWAP -c aes-xts-plain64 -h whirlpool -s 512
+
  swap /dev/lvm/swap /dev/urandom swap,cipher<nowiki>=aes-xts-plain64,size=</nowiki>256
  tmp /dev/lvm/tmp /dev/urandom -c aes-xts-plain64 -s 512}}
+
  tmp /dev/lvm/tmp /dev/urandom tmp,cipher<nowiki>=aes-xts-plain64,size=</nowiki>256}}
  
=== Encrypting /home after reboot ===
+
=== Encrypting logical volume /home ===
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.
+
Since this scenario uses LVM as the primary and dm-crypt as secondary mapper, each encrypted logical volume requires its own encryption. Yet, unlike the temporary filesystems configured with volatile encryption above, the logical volume for {{ic|/home}} should be persistent, of course. The following assumes you have rebooted into the installed system, otherwise you have to adjust paths.  
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 [[Dm-crypt/Device_Encryption#Cryptsetup_and_keyfiles|here]].
+
To safe on entering a second passphrase at boot for it, a [[Dm-crypt/Device_encryption#Keyfiles|keyfile]] is created:  
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.
+
  mkdir -m 700 /etc/luks-keys
 +
dd if=/dev/random of=/etc/luks-keys/home bs=1 count=256
  
mkdir -p -m 700 /mnt/etc/luks-keys
+
The logical volume is encrypted with it:
dd if=/dev/random of=/mnt/etc/luks-keys/home bs=1 count=256
+
  cryptsetup luksFormat -v -s 512 /dev/lvm/home /etc/luks-keys/home
 
+
  cryptsetup -d /etc/luks-keys/home open --type luks /dev/lvm/home home
  cryptsetup luksFormat -c aes-xts-plain64 -s 512 /dev/lvm/home /etc/luks-keys/home
+
  mkfs -t ext4 /dev/mapper/home
  cryptsetup open --type luks -d /etc/luks-keys/home /dev/lvm/home home
+
  mkreiserfs /dev/mapper/home
+
 
  mount /dev/mapper/home /home
 
  mount /dev/mapper/home /home
 
+
The encrypted mount is configured in [[Dm-crypt/System_configuration#crypttab|crypttab]]:
 
{{hc|/etc/crypttab|
 
{{hc|/etc/crypttab|
home /dev/lvm/home  /etc/luks-keys/home}}
+
home /dev/lvm/home  /etc/luks-keys/home}}
 
+
{{Note|If you do not want to use a keyfile, simply leave the third column empty ({{ic|/etc/luks-keys/home}} in the example) and you will be asked for a password at boot.}}
+
 
+
 
{{hc|/etc/fstab|
 
{{hc|/etc/fstab|
/dev/mapper/home        /home  reiserfs       defaults        0      0}}
+
/dev/mapper/home        /home  ext4       defaults        0      2}}
 +
and setup is done.
  
=== Expanding LVM on multiple disks ===
+
If you want to expand the logical volume for {{ic|/home}} (or any other volume) at a later point, it is important to note that the LUKS encrypted part has to be resized as well. For a procedure see [[Dm-crypt/Specialties#Expanding LVM on multiple disks]].
  
The {{ic|encrypt}} hook only allows for a '''single''' {{ic|cryptdevice<nowiki>=</nowiki>}} 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.
+
== LUKS on software RAID ==
  
So, you add another hard drive in order to expand {{ic|home}} (which is a logical volume of its own).  You encrypt the second drive, add it to the volume group, expand the {{ic|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 {{ic|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.
+
{{Expansion|Some references: [[RAID]], [[Software RAID and LVM]], http://wiki.drewhess.com/wiki/Creating_an_encrypted_filesystem_on_a_partition , http://jasonwryan.com/blog/2012/02/11/lvm/ . Note that full-disk encryption is [https://forums.gentoo.org/viewtopic-p-7029704.html not deniable] with this configuration (consider RAID on LUKS instead?).}}
  
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.
+
== Plain dm-crypt ==
  
====Adding a new drive====
+
Contrary to LUKS, dm-crypt ''plain'' mode does not require a header on the encrypted device: this scenario exploits this feature to set up a system on an unpartitioned, encrypted disk that will be indistinguishable from a disk filled with random data, which could allow [[Wikipedia:Deniable encryption|deniable encryption]]. See also [[wikipedia:Disk encryption#Full disk encryption]].
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:
+
Note that if full-disk encryption is not required, the methods using LUKS described in the sections above are better options for both system encryption and encrypted partitions. LUKS features like key management with multiple passphrases/key-files or re-encrypting a device in-place are unavailable with ''plain'' mode.
* /dev/sdy1: Use ALL space, Partition type 8E00 (Linux LVM)
+
  
Now, attach this new disk to your existing LVM:
+
''Plain'' dm-crypt encryption can be more resilient to damage than LUKS, 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]]. Using ''plain'' mode could also be considered if concerned with the problems explained in [[Dm-crypt/Specialties#Discard/TRIM support for solid state drives (SSD)]].
# pvcreate /dev/sdy1
+
# vgextend MyStorage /dev/sdy1
+
  
====Extending the logical volume====
+
{{Tip|If headerless encryption is your goal but you are unsure about the lack of key-derivation with ''plain'' mode, then two alternatives are:
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.
+
* [[tcplay]] which offers headerless encryption but with the PBKDF2 function, or
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!)
+
* dm-crypt LUKS mode by using the ''cryptsetup'' {{ic|--header}} option. It cannot be used with the standard ''encrypt'' hook, but the hook [[Dm-crypt/Specialties#Encrypted system using a remote LUKS header|may be modified]].}}
  
From a root console:
+
The scenario uses two USB sticks:
# umount /home
+
* one for the boot device, which also allows storing the options required to open/unlock the plain encrypted device in the boot loader configuration, since typing them on each boot would be error prone;
# fsck /dev/mapper/home
+
* another for the encryption key file, assuming it stored as raw bits so that to the eyes of an unaware attacker who might get the usbkey the encryption key will appear as random data instead of being visible as a normal file. See also [[Wikipedia:Security through obscurity]], follow [[Dm-crypt/Device encryption#Keyfiles]] to prepare the keyfile.
# cryptsetup luksClose /dev/mapper/home
+
# lvextend -l +100%FREE MyStorage/homevol
+
  
Now the LV is extended.  Let us make LUKS aware of the change:
+
The disk layout is:  
# cryptsetup open --type luks /dev/mapper/MyStorage-homevol home
+
# umount /home      ((JUST IN CASE IT WAS AUTO RE-MOUNTED AGAIN))
+
# cryptsetup --verbose resize home
+
  
And finally resize the ext4 partition itself:
+
  +--------------------+------------------+--------------------+ +---------------+ +---------------+
# e2fsck -f /dev/mapper/home
+
# resize2fs /dev/mapper/home
+
+
Done!
+
# mount /dev/mapper/home /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 ==
+
 
+
{{Expansion|Some references: [[RAID]], [[Software RAID and LVM]], http://jasonwryan.com/blog/2012/02/11/lvm/}}
+
 
+
== 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.
+
 
+
The scenario uses an USB stick for the boot device and another one to store the encryption key. The disk layout is:
+
 
+
  +------------------------------------------------------------+ +---------------+ +---------------+
+
|disk drive /dev/sdaX encrypted using plain mode and LVM    | |USB stick 1    | |USB stick 2    |
+
|--------------------+------------------+--------------------| |---------------| |---------------|
+
 
  |Volume 1:          |Volume 2:        |Volume 3:          | |Boot device    | |Encryption key |
 
  |Volume 1:          |Volume 2:        |Volume 3:          | |Boot device    | |Encryption key |
 
  |                    |                  |                    | |              | |file storage  |
 
  |                    |                  |                    | |              | |file storage  |
Line 335: Line 365:
 
  |                    |                  |                    | |              | |in example)    |
 
  |                    |                  |                    | |              | |in example)    |
 
  |/dev/store/root    |/dev/store/swap  |/dev/store/home    | |/dev/sdY1      | |/dev/sdZ      |
 
  |/dev/store/root    |/dev/store/swap  |/dev/store/home    | |/dev/sdY1      | |/dev/sdZ      |
  +--------------------+------------------+--------------------+ +---------------+ +---------------+
+
  |--------------------+------------------+--------------------| |---------------| |---------------|
 
+
|disk drive /dev/sdaX encrypted using plain mode and LVM    | |USB stick 1    | |USB stick 2    |
The reasons for the use of two USB-keys are:
+
+------------------------------------------------------------+ +---------------+ +---------------+
* 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 {{ic|/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. 
+
 
+
Some considerations for choosing ''plain'' or ''LUKS'' mode are:
+
 
+
'''Advantages'''
+
* 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.
+
 
+
'''Disadvantages'''
+
* dm-crypt does not allow multiple pass-phrases, nor does it allow changes to the pass-phase or key-file after initial set-up. LUKS allows for up to eight passphrases, and key-files and passphrases can be changed without having to re-encrypt the entire disk or partition.
+
* plain dm-crypt requires manual configuration of encryption options each time a device is opened, whereas LUKS stores those details in its header.
+
* LUKS uses pass-phrase salting and hash iteration, and as such can be more secure than plain dm-crypt. It is essential that a pass-phrase or key-file with very high entropy is used with dm-crypt. 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 {{ic|--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). Alternatively, the header could be stored away from the key-file on /dev/sdY1.}}
+
{{Tip|
 +
* It is also possible to use a single usb key by copying the keyfile to the initram directly. An example keyfile {{ic|/etc/keyfile}} gets copied to the initram image by setting {{ic|1=FILES="/etc/keyfile"}} in {{ic|/etc/mkinitcpio.conf}}. The way to instruct the {{ic|encrypt}} hook to read the keyfile in the initram image is using {{ic|rootfs:}} prefix before the filename, e.g. {{ic|cryptkey&#61;rootfs:/etc/keyfile}}.
 +
* Another option is using a passphrase with good [[Disk_encryption#Choosing_a_strong_passphrase|entropy]].
 +
}}
  
 
=== Preparing the disk ===
 
=== Preparing the disk ===
  
{{Note|It is vital that the mapped device is filled with data. Without doing so, the encrypted data that is written to disk will be easily distinguishable from areas not yet written to. See [[Disk_Encryption#Preparing_the_disk]] for a more comprehensive discussion.}}
+
It is vital that the mapped device is filled with data. In particular this applies to the scenario usecase we apply here.  
  
See [[Dm-crypt/Drive_Preparation]] and [[Dm-crypt/Drive_Preparation#dm-crypt_specific_methods]]
+
See [[Dm-crypt/Drive preparation]] and [[Dm-crypt/Drive preparation#dm-crypt specific methods]]
  
 
=== Preparing the non-boot partitions ===
 
=== Preparing the non-boot partitions ===
  
See [[Dm-crypt/Device Encryption#Encryption options for plain mode]] for details.
+
See [[Dm-crypt/Device encryption#Encryption options for plain mode]] for details.  
  
 
Using the device {{ic|/dev/sd''X''}}, with the twofish-xts cipher with a 512 bit key size and using a keyfile we have the following options for this scenario:  
 
Using the device {{ic|/dev/sd''X''}}, with the twofish-xts cipher with a 512 bit key size and using a keyfile we have the following options for this scenario:  
Line 371: Line 391:
 
  # fdisk -l
 
  # fdisk -l
  
Next, we setup [[LVM]] logical volumes on the mapped device, see [[Lvm#Installing_Arch_Linux_on_LVM]] for further details:  
+
Next, we setup [[LVM]] logical volumes on the mapped device, see [[LVM#Installing Arch Linux on LVM]] for further details:  
 
  # pvcreate /dev/mapper/enc
 
  # pvcreate /dev/mapper/enc
 
  # vgcreate store /dev/mapper/enc
 
  # vgcreate store /dev/mapper/enc
 
  # lvcreate -L 20G store -n root
 
  # lvcreate -L 20G store -n root
  # lvcreate -C y -L 10G store -n swap
+
  # lvcreate -L 10G store -n swap
  # lvcreate -l +100%FREE store -n home
+
  # lvcreate -l 100%FREE store -n home
We format and mount them and activate swap, see [[File Systems#Format a device]] for further details:  
+
We format and mount them and activate swap, see [[File systems#Format a device]]{{Broken section link}} for further details:  
 
  # mkfs.ext4 /dev/store/root
 
  # mkfs.ext4 /dev/store/root
 
  # mkfs.ext4 /dev/store/home
 
  # mkfs.ext4 /dev/store/home
Line 387: Line 407:
  
 
=== Preparing the boot partition ===
 
=== Preparing the boot partition ===
The {{ic|/boot}} partition can be installed on the standard vfat partition of a USB stick, if required. But if manual partitioning is needed, then a small 200MB partition is all that is required:
+
The {{ic|/boot}} partition can be installed on the standard vfat partition of a USB stick, if required. But if manual partitioning is needed, then a small 200MB partition is all that is required. Create the partition using a [[Partitioning#Partitioning_tools|partitioning tool]] of your choice.
# fdisk /dev/sd''Y''
+
> n
+
> p
+
> 1
+
> default (2048)
+
> +200M
+
> w
+
> q
+
  
 
We choose a non-journalling file system to preserve the flash memory of the {{ic|/boot}} partition, if not already formatted as vfat:
 
We choose a non-journalling file system to preserve the flash memory of the {{ic|/boot}} partition, if not already formatted as vfat:
Line 404: Line 416:
 
=== Configuring mkinitcpio ===
 
=== Configuring mkinitcpio ===
  
Please follow [[Installation Guide#Install the base system]] until editing {{ic|mkinitcpio.conf}} is required, then add {{ic|encrypt}} and {{ic|lvm2}} to the {{ic|HOOKS}} array as follows:
+
Add the {{ic|encrypt}} and {{ic|lvm2}} hooks to [[mkinitcpio.conf]]:
 
+
{{hc|etc/mkinitcpio.conf|2=HOOKS="... '''encrypt''' '''lvm2''' ... filesystems ..."}}
{{hc|/etc/mkinitcpio.conf|HOOKS<nowiki>=</nowiki>"base udev ... encrypt '''lvm2''' ... filesystems ..."}}
+
 
+
Then rebuild the initramfs as per usual:
+
  
# mkinitcpio -p linux
+
See [[dm-crypt/System configuration#mkinitcpio]] for details and other hooks that you may need.
  
 
=== Configuring the boot loader ===
 
=== Configuring the boot loader ===
  
See [[Installation Guide#Install and configure a boot loader]] and then return to this guide.
+
In order to boot the encrypted root partition, the following kernel parameters need to be set by the boot loader:
  
In order to unlock the encrypted device in this scenario, three kernel arguments have specified to be parsed by the ''encrypt'' hook:  
+
cryptdevice=/dev/sd''X'':enc cryptkey=/dev/sd''Z'':0:512 crypto=sha512:twofish-xts-plain64:512:0:
* {{ic|<nowiki>cryptdevice=</nowiki>}} to identify the encrypted root-device,
+
* {{ic|<nowiki>cryptkey=</nowiki>}} for the location of the keyfile and
+
* {{ic|<nowiki>crypto=</nowiki>}} to specify the cryptographic options that need to be used with the key. 
+
  
For details on the arguments and the parameters, see [[Dm-crypt/System Configuration#Boot loader]]
+
{{Note|If using sd-encrypt instead of encrypt, use {{ic|''luks.uuid''}} instead of cryptdevice, see ''systemd-cryptsetup-generator(8)''.}}
  
The fully specified kernel arguments for initialising the root-device of this example plain dm-crypt disk are:
+
See [[Dm-crypt/System configuration#Boot loader]] for details and other parameters that you may need.
  
{{bc|<nowiki>cryptdevice=</nowiki>/dev/sd''X'':enc <nowiki>cryptkey=</nowiki>/dev/sd''Z'':0:512 <nowiki>crypto=sha512:twofish-xts-plain64:512:0:</nowiki>}}
+
{{Tip|If using GRUB, you can install it on the same USB as the {{ic|/boot}} partition with:
 
+
If using [[grub]], this is added to {{ic|/etc/default/grub}}:
+
{{hc|/etc/default/grub|<nowiki>
+
GRUB_CMDLINE_LINUX="cryptdevice=</nowiki>/dev/sd''X'':enc <nowiki>cryptkey=</nowiki>/dev/sd''Z'':0:512 <nowiki>crypto=sha512:twofish-xts-plain64:512:0:</nowiki>"}}
+
You may also wish to add:
+
{{hc|/etc/default/grub|<nowiki>
+
GRUB_CMDLINE_LINUX="... root=</nowiki>/dev/store/root"}}
+
Although it should not be necessary.
+
 
+
This can then be used to update {{ic|grub.cfg}}
+
# grub-mkconfig -o /boot/grub/grub.cfg
+
 
+
The bootloader can then be installed on the same USB as the {{ic|/boot}} partition:
+
 
  # grub-install --recheck /dev/sd''Y''
 
  # grub-install --recheck /dev/sd''Y''
 +
}}
  
 
===Post-installation===
 
===Post-installation===
  
You may wish to remove the USB sticks after booting. Since the {{ic|/boot}} partition is not usually needed, the following option can be added to the boot options in {{ic|/etc/fstab}}:
+
You may wish to remove the USB sticks after booting. Since the {{ic|/boot}} partition is not usually needed, the {{ic|noauto}} option can be added to the relevant line in {{ic|/etc/fstab}}:
  
 
{{hc|/etc/fstab|
 
{{hc|/etc/fstab|
 
# /dev/sd''Yn''
 
# /dev/sd''Yn''
<nowiki>UUID=</nowiki>************* /boot ext2 '''noauto''',rw,noatime 0 2}}
+
/dev/sd''Yn'' /boot ext2 '''noauto''',rw,noatime 0 2}}
  
 
However, when an update to the kernel or bootloader is required, the {{ic|/boot}} partition must be present and mounted. As the entry in {{ic|fstab}} already exists, it can be mounted simply with:
 
However, when an update to the kernel or bootloader is required, the {{ic|/boot}} partition must be present and mounted. As the entry in {{ic|fstab}} already exists, it can be mounted simply with:
  
 
  # mount /boot
 
  # mount /boot
 +
 +
== Encrypted boot partition (GRUB) ==
 +
 +
This setup utilizes the same partition layout and configuration for the system's root partition as the previous [[#LVM on LUKS]] section, with two distinct differences:
 +
 +
# The setup is performed for an [[UEFI]] system and
 +
# A special feature of the [[GRUB]] bootloader is used to additionally encrypt the boot partition {{ic|/boot}}. See also [[GRUB#Boot partition]].
 +
 +
The disk layout in this example is:
 +
 +
+---------------+----------------+----------------+----------------+----------------+
 +
|ESP partition: |Boot partition: |Volume 1:      |Volume 2:      |Volume 3:      |
 +
|              |                |                |                |                |
 +
|/boot/efi      |/boot          |root            |swap            |home            |
 +
|              |                |                |                |                |
 +
|              |                |/dev/store/root |/dev/store/swap |/dev/store/home |
 +
|/dev/sdaX      |/dev/sdaY      +----------------+----------------+----------------+
 +
|'''un'''encrypted    |LUKS encrypted  |/dev/sdaZ encrypted using LVM on LUKS            |
 +
+---------------+----------------+--------------------------------------------------+
 +
 +
{{Tip|All scenarios are intended as examples. It is, of course, possible to apply both of the two above distinct installation steps with the other scenarios as well. See also the variants linked in [[#LVM on LUKS]].}}
 +
 +
=== Preparing the disk ===
 +
 +
Prior to creating any partitions, you should inform yourself about the importance and methods to securely erase the disk, described in [[Dm-crypt/Drive preparation]].
 +
 +
Create an [[EFI System Partition]] with an appropriate size, it will later be mounted at {{ic|/boot/efi}}.
 +
 +
Create a partition to be mounted at {{ic|/boot}} of type {{ic|8300}} with a size of 100 MB or more.
 +
 +
{{Tip|When using the [[GRUB]] bootloader together with a BIOS/[[GPT]], create a BIOS Boot Partition as explained in [[GRUB#BIOS systems]] instead of the ESP.}}
 +
 +
Create a partition of type {{ic|8E00}}, which will later contain the encrypted container.
 +
 +
Create the LUKS encrypted container at the "system" partition.
 +
 +
# cryptsetup luksFormat /dev/''sdaZ''
 +
 +
For more information about the available cryptsetup options see the [[Dm-crypt/Device encryption#Encryption_options_for_LUKS_mode|LUKS encryption options]] prior to above command.
 +
 +
Your partition layout should look similar to this:
 +
{{hc| gdisk /dev/sda |
 +
Number  Start (sector)    End (sector)  Size      Code  Name
 +
  1            2048        1050623  512.0 MiB  EF00  EFI System
 +
  2        1050624        1460223  200.0 MiB  8300  Linux filesystem
 +
  3        1460224        41943006  19.3 GiB    8E00  Linux LVM
 +
}}
 +
 +
Open the container:
 +
 +
# cryptsetup open --type luks /dev/''sdaZ'' lvm
 +
 +
The decrypted container is now available at {{ic|/dev/mapper/lvm}}.
 +
 +
=== Preparing the logical volumes ===
 +
 +
The LVM logical volumes of this example follow the exact layout as the previous scenario. Therefore, please follow [[#Preparing the logical volumes|Preparing the logical volumes]] above or adjust as required.
 +
 +
=== Preparing the boot partition ===
 +
 +
The bootloader loads the kernel, [[initramfs]], and its own configuration files from the {{ic|/boot}} directory.
 +
 +
First, create the LUKS container where the files will be located and installed into:
 +
 +
# cryptsetup luksFormat /dev/sda''Y''
 +
 +
Next, open it:
 +
# cryptsetup open /dev/sda''Y'' cryptboot
 +
 +
Create a filesystem on the partition intended for {{ic|/boot}}. Any filesystem that can be read by the bootloader is eligible:
 +
 +
# mkfs.ext2 /dev/mapper/''cryptboot''
 +
 +
Create the directory {{ic|/mnt/boot}}:
 +
 +
# mkdir /mnt/boot
 +
 +
Mount the partition to {{ic|/mnt/boot}}:
 +
 +
# mount /dev/mapper/''cryptboot'' /mnt/boot
 +
 +
Create a mountpoint for the [[EFI System Partition]] at {{ic|/boot/efi}} for compatibility with {{ic|grub-install}} and mount it:
 +
 +
# mkdir /mnt/boot/efi
 +
# mount /dev/''sdaX'' /mnt/boot/efi
 +
 +
At this point, you should have the following partitions and logical volumes inside of {{ic|/mnt}}:
 +
{{hc|lsblk|
 +
NAME                MAJ:MIN RM  SIZE RO TYPE  MOUNTPOINT
 +
sda                      8:0      0  200G  0 disk 
 +
├─sda1                    8:1      0  512M  0 part  /boot/efi
 +
├─sda2                    8:2      0  200M  0 part 
 +
│ └─boot   254:0    0  198M  0 crypt /boot
 +
└─sda3                    8:3      0  100G  0 part 
 +
  └─lvm                  254:1    0  100G  0 crypt
 +
    ├─MyStorage-swapvol  254:2    0    8G  0 lvm  [SWAP]
 +
    ├─MyStorage-rootvol  254:3    0    15G  0 lvm  /
 +
    └─MyStorage-homevol  254:4    0    77G  0 lvm  /home
 +
}}
 +
 +
Afterwards continue with the installation procedure up to the mkinitcpio step.
 +
 +
=== Configuring mkinitcpio ===
 +
 +
Add the {{ic|encrypt}} and {{ic|lvm2}} hooks to [[mkinitcpio.conf]]:
 +
{{hc|/etc/mkinitcpio.conf|2=HOOKS="... '''encrypt''' '''lvm2''' ... filesystems ..."}}
 +
 +
See [[dm-crypt/System configuration#mkinitcpio]] for details and other hooks that you may need.
 +
 +
=== Configuring the boot loader ===
 +
 +
Configure GRUB to recognize the LUKS encrypted {{ic|/boot}} partition and unlock the encrypted root partition at boot:
 +
 +
{{hc|/etc/default/grub|2=
 +
GRUB_CMDLINE_LINUX="... cryptdevice=UUID=''<device-UUID>'':lvm root=/dev/mapper/MyStorage-rootvol ..."
 +
GRUB_ENABLE_CRYPTODISK=y
 +
}}
 +
 +
See [[Dm-crypt/System configuration#Boot loader]] and [[GRUB#Boot partition]] for details. The {{ic|''<device-UUID>''}} refers to the UUID of {{ic|/dev/sdaZ}} (the partition which holds the lvm containing the root filesystem), see [[Persistent block device naming]].
 +
 +
Generate GRUB's [[GRUB#Generate the main configuration file|configuration]] file and [[GRUB#Installation_2|install]] to the mounted ESP:
 +
 +
# grub-mkconfig -o /boot/grub/grub.cfg
 +
# grub-install --target=x86_64-efi --efi-directory=/boot/efi --bootloader-id=grub --recheck
 +
 +
If this finished without errors, GRUB should prompt for the passphrase to unlock the {{ic|/boot}} partition after the next reboot.
 +
 +
=== Configuring fstab and crypttab ===
 +
 +
This section deals with extra configuration to let the system '''mount''' the encrypted {{ic|/boot}}.
 +
 +
While GRUB asks for a passphrase to unlock the encrypted {{ic|/boot}} after above instructions, the partition unlock is not passed on to the initramfs. Hence, {{ic|/boot}} will not be available after the system has re-/booted, because the {{ic|encrypt}} hook only unlocks the system's root.
 +
 +
If you used the ''genfstab'' script during installation, it will have generated {{ic|/etc/fstab}} entries for the {{ic|/boot}} and {{ic|/boot/efi}} mount points already, but the system will fail to find the generated device mapper for the boot partition. To make it available, add it to [[Dm-crypt/System configuration#crypttab|crypttab]]. For example:
 +
 +
{{hc|/etc/crypttab|
 +
cryptboot  /dev/sdaY      none        luks}}
 +
 +
will make the system ask for the passphrase again (i.e. you have to enter it twice at boot: once for GRUB and once for systemd init). To avoid the double entry for unlocking {{ic|/boot}}, follow the instructions at [[Dm-crypt/Device encryption#Keyfiles]] to:
 +
 +
# Create a [[Dm-crypt/Device_encryption#Storing the keyfile on a filesystem|randomtext keyfile]],
 +
# Add the keyfile to the ({{ic|/dev/sdaY}}) [[Dm-crypt/Device encryption#Configuring LUKS to make use of the keyfile|boot partition's LUKS header]] and
 +
# Check the {{ic|/etc/fstab}} entry and add the {{ic|/etc/crypttab}} line to [[Dm-crypt/Device_encryption#Unlocking_a_secondary_partition_at_boot|unlock it automatically at boot]].
 +
 +
If for some reason the keyfile fails to unlock the boot partition, systemd will fallback to ask for a passphrase to unlock and, in case that is correct, continue booting.
 +
 +
{{Tip|Optional post-installation steps:
 +
* It may be worth considering to add the GRUB bootloader to the ignore list of {{ic|/etc/pacman.conf}} in order to take particular control of when the bootloader (which includes its own encryption modules) is updated.
 +
* If you want to encrypt the {{ic|/boot}} partition to protect against offline tampering threats, the [[Dm-crypt/Specialties#mkinitcpio-chkcryptoboot|mkinitcpio-chkcryptoboot]] hook has been contributed to help.}}
 +
 +
== Btrfs subvolumes with swap ==
 +
 +
The following example creates a full system encryption with LUKS using [[Btrfs]] subvolumes to [[Btrfs#Mounting_subvolumes|simulate partitions]].
 +
 +
If using UEFI, an [[EFI System Partition]] (ESP) is required. {{ic|/boot}} itself may reside on {{ic|/}} and be encrypted; however, the ESP itself cannot be encrypted. In this example layout, the ESP is {{ic|/dev/sda''Y''}} and is mounted at {{ic|/boot/efi}}. {{ic|/boot}} itself is located on the system partition, {{ic|/dev/sda''X''}}.
 +
 +
Since {{ic|/boot}} resides on the encrypted {{ic|/}}, [[GRUB]] must be used as the bootloader because only GRUB can load modules necessary to decrypt {{ic|/boot}} (e.g., crypto.mod, cryptodisk.mod and luks.mod) [http://www.pavelkogan.com/2014/05/23/luks-full-disk-encryption/].
 +
 +
Additionally an optional plain-encrypted [[swap]] partition is shown.
 +
 +
{{Warning|Do not use a [[swap file]] instead of a separate partition, because this may result in data loss. See [[Btrfs#Swap file]].}}
 +
 +
+--------------------------+--------------------------+--------------------------+
 +
|ESP                      |System partition          |Swap partition            |
 +
|'''un'''encrypted              |LUKS-encrypted            |plain-encrypted          |
 +
|                          |                          |                          |
 +
|/boot/efi                |/                        |                          |
 +
|/dev/sda''Y''                |/dev/sda''X''                |/dev/sda''Z''                |
 +
|--------------------------+--------------------------+--------------------------+
 +
 +
=== Preparing the disk ===
 +
 +
{{Note|It is not possible to use btrfs partitioning as described in [[Btrfs#Partitionless Btrfs disk]] when using LUKS. Traditional partitioning must be used, even if it is just to create one partition.}}
 +
 +
Prior to creating any partitions, you should inform yourself about the importance and methods to securely erase the disk, described in [[Dm-crypt/Drive preparation]]. If you are using [[UEFI]] create an [[EFI System Partition]] with an appropriate size. It will later be mounted at {{ic|/boot/efi}}. If you are going to create an encrypted swap partition, create the partition for it, but do '''not''' mark it as swap, since plain ''dm-crypt'' will be used with the partition.
 +
 +
Create the needed partitions, at least one for {{ic|/}} (e.g. {{ic|/dev/sda''X''}}). See the [[Partitioning]] article.
 +
 +
=== Preparing the system partition ===
 +
 +
==== Create LUKS container ====
 +
 +
Follow [[dm-crypt/Device encryption#Encrypting devices with LUKS mode]] to setup {{ic|/dev/sda''X''}} for LUKS. See the [[Dm-crypt/Device encryption#Encryption options for LUKS mode]] before doing so for a list of encryption options.
 +
 +
==== Unlock LUKS container ====
 +
 +
Now follow [[Dm-crypt/Device encryption#Unlocking/Mapping LUKS partitions with the device mapper]] to unlock the LUKS container and map it.
 +
 +
==== Format mapped device ====
 +
 +
Proceed to format the mapped device as described in [[Btrfs#File system on a single device]], where {{ic|''/dev/partition''}} is the name of the mapped device (i.e., {{ic|cryptroot}}) and '''not''' {{ic|/dev/sda''X''}}.
 +
 +
==== Mount mapped device ====
 +
 +
Finally, [[mount]] the now-formatted mapped device (i.e., {{ic|/dev/mapper/cryptroot}}) to {{ic|/mnt}}.
 +
 +
{{Tip|You may want to use the {{ic|1=compress=lzo}} mount option. See [[Btrfs#Compression]] for more information.}}
 +
 +
=== Creating btrfs subvolumes ===
 +
 +
==== Layout ====
 +
 +
[[Btrfs#Subvolumes|Subvolumes]] will be used to simulate partitions, but other (nested) subvolumes will also be created. Here is a partial representation of what the following example will generate:
 +
 +
subvolid=5 (/dev/sda''X'')
 +
    |
 +
    ├── @ (mounted as /)
 +
    |      |
 +
    |      ├── /bin (directory)
 +
    |      |
 +
    |      ├── /home (mounted @home subvolume)
 +
    |      |
 +
    |      ├── /usr (directory)
 +
    |      |
 +
    |      ├── /.snapshots (mounted @snapshots subvolume)
 +
    |      |
 +
    |      ├── /var/cache/pacman/pkg (nested subvolume)
 +
    |      |
 +
    |      ├── ... (other directories and nested subvolumes)
 +
    |
 +
    ├── @snapshots (mounted as /.snapshots)
 +
    |
 +
    ├── @home (mounted as /home)
 +
    |
 +
    └── @... (additional subvolumes you wish to use as mount points)
 +
 +
This section follows the [[Snapper#Suggested filesystem layout]], which is most useful when used with [[Snapper]]. You should also consult [https://btrfs.wiki.kernel.org/index.php/SysadminGuide#Layout Btrfs Wiki SysadminGuide#Layout].
 +
 +
==== Create top-level subvolumes ====
 +
 +
Here we are using the convention of prefixing {{ic|@}} to subvolume names that will be used as mount points, and {{ic|@}} will be the subvolume that is mounted as {{ic|/}}.
 +
 +
Following the [[Btrfs#Creating a subvolume]] article, create subvolumes at {{ic|/mnt/@}}, {{ic|/mnt/@snapshots}}, and {{ic|/mnt/@home}}.
 +
 +
Create any additional subvolumes you wish to use as mount points now.
 +
 +
==== Mount top-level subvolumes ====
 +
 +
Unmount the system partition at {{ic|/mnt}}.
 +
 +
Now mount the newly created {{ic|@}} subvolume which will serve as {{ic|/}} to {{ic|/mnt}} using the {{ic|1=subvol=}} mount option. Assuming the mapped device is named {{ic|cryptroot}}, the command would look like:
 +
 +
# mount -o compress=lzo,subvol=@ /dev/mapper/cryptroot /mnt
 +
 +
See [[Btrfs#Mounting subvolumes]] for more details.
 +
 +
Also mount the other subvolumes to their respective mount points: {{ic|@home}} to {{ic|/mnt/home}} and {{ic|@snapshots}} to {{ic|/mnt/.snapshots}}.
 +
 +
==== Create nested subvolumes ====
 +
 +
Create any subvolumes you do '''not''' want to have snapshots of when taking a snapshot of {{ic|/}}. For example, you probably do not want to take snapshots of {{ic|/var/cache/pacman/pkg}}. These subvolumes will be nested under the {{ic|@}} subvolume, but just as easily could have been created earlier at the same level as {{ic|@}} according to your preference.
 +
 +
Since the {{ic|@}} subvolume is mounted at {{ic|/mnt}} you will need to [[create a subvolume]] at {{ic|/mnt/var/cache/pacman/pkg}} for this example. You may have to create any parent directories first.
 +
 +
Other directories you may wish to do this with are {{ic|/var/abs}}, {{ic|/var/tmp}}, and {{ic|/srv}}.
 +
 +
==== Mount ESP ====
 +
 +
If you prepared an EFI system partition earlier, create its mount point and mount it now.
 +
 +
{{Note|Btrfs snapshots will exclude {{ic|/boot/efi}}, since it is not a btrfs file system.}}
 +
 +
At the [[Installation guide#Install the base packages|pacstrap]] installation step, the {{Pkg|btrfs-progs}} must be installed in addition to the base group.
 +
 +
=== Configuring mkinitcpio ===
 +
 +
==== Create keyfile ====
 +
 +
In order for GRUB to open the LUKS partition without having the user enter his passphrase twice, we will use a keyfile embedded in the initramfs. Follow [[Dm-crypt/Device encryption#With a keyfile embedded in the initramfs]] making sure to add the key to {{ic|/dev/sda''X''}} at the ''luksAddKey'' step.
 +
 +
==== Edit mkinitcpio.conf ====
 +
 +
After creating, adding, and embedding the key as described above, add the {{ic|encrypt}} hook to [[mkinitcpio.conf]] as well as any other hooks you require. See [[Dm-crypt/System configuration#mkinitcpio]] for detailed information. Be sure to regenerate the initial ramdisk when finished.
 +
 +
{{Tip|You may want to add {{ic|1=BINARIES="/usr/bin/btrfs"}} to your {{ic|mkinitcpio.conf}}. See the [[Btrfs#Corruption recovery]] article.}}
 +
 +
=== Configuring the boot loader ===
 +
 +
Install [[GRUB]] to {{ic|/dev/sda}}. Then, edit {{ic|/etc/default/grub}} as instructed in the [[GRUB#Encryption]] article, following both the instructions for an encrypted root and boot partition. Finally, generate the GRUB configuration file.
 +
 +
=== Configuring swap ===
 +
 +
If you created a partition to be used for encrypted swap, now is the time to configure it. Follow the instructions at [[Dm-crypt/Swap encryption]].
 +
 +
After completing this step, continue configuring your system as normal according to the [[Installation_guide#Reboot|installation guide]].

Latest revision as of 12:38, 6 August 2016

Back to dm-crypt.

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.

Contents

Overview

Securing a root filesystem is where dm-crypt excels, feature and performance-wise. 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 (usually) the kernel is encrypted.

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

Scenarios Advantages Disadvantages
#Simple partition layout with LUKS

shows a basic and straight-forward set-up for a fully LUKS encrypted root.

  • Simple partitioning and setup
  • Inflexible; disk-space to be encrypted has to be pre-allocated
#LVM on LUKS

achieves partitioning flexiblity by using LVM inside a single LUKS encrypted partition.

  • Simple partitioning with knowledge of LVM
  • Only one key required to unlock all volumes (e.g. easy resume-from-disk setup)
  • Volume layout not transparent when locked
  • Easiest method to allow suspension to disk
  • LVM adds an additional mapping layer and hook
  • Less useful, if a singular volume should receive a separate key
#LUKS on LVM

uses dm-crypt only after the LVM is setup.

  • LVM can be used to have encrypted volumes span multiple disks
  • Easy mix of un-/encrypted volume groups
  • Complex; changing volumes requires changing encryption mappers too
  • Volumes require individual keys
  • LVM layout is transparent when locked
#Plain dm-crypt

uses dm-crypt plain mode, i.e. without a LUKS header and its options for multiple keys.
This scenario also employs USB devices for /boot and key storage, which may be applied to the other scenarios.

  • High care to all encryption parameters is required
  • Single encryption key and no option to change it
#Encrypted boot partition (GRUB)

shows how to encrypt the boot partition using the GRUB bootloader.
This scenario also employs an ESP partition, which may be applied to the other scenarios.

  • Same advantages as the scenario the installation is based on (LVM on LUKS for this particular example)
  • Less data is left unencrypted, i.e. the boot loader and the ESP partition, if present
  • Same disadvantages as the scenario the installation is based on (LVM on LUKS for this particular example)
  • More complicated configuration
  • Not supported by other boot loaders
#Btrfs subvolumes with swap

shows how to encrypt a Btrfs system, including the /boot directory, also adding a partition for swap, on UEFI hardware.

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.

See Dm-crypt/Drive preparation#Partitioning for a general overview of the partitioning strategies used in the scenarios.

Another area to consider is whether to set up an encrypted swap partition and what kind. See Dm-crypt/Swap encryption for alternatives.

If you anticipate to protect the system's data not only against physical theft, but also have a requirement of precautions against logical tampering, see Dm-crypt/Specialties#Securing the unencrypted boot partition for further possibilities after following one of the scenarios.

Simple partition layout with LUKS

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

+--------------------+--------------------------+--------------------------+
|Boot partition      |LUKS encrypted system     |Optional free space       |
|                    |partition                 |for additional partitions |
|/dev/sdaY           |/dev/sdaX                 |or swap to be setup later |
+--------------------+--------------------------+--------------------------+

The first steps can be performed directly after booting the Arch Linux install image.

Preparing the disk

Prior to creating any partitions, you should inform yourself about the importance and methods to securely erase the disk, described in Dm-crypt/Drive preparation.

Then create the needed partitions, at least one for / (e.g. /dev/sdaX) and /boot (/dev/sdaY), see Partitioning.

Preparing non-boot partitions

The following commands create and mount the encrypted root partition. They correspond to the procedure described in detail in Dm-crypt/Encrypting a non-root file system#Partition (which, despite the title, can be applied to root partitions, as long as mkinitcpio and the boot loader are correctly configured). If you want to use particular non-default encryption options (e.g. cipher, key length), see the encryption options before executing the first command:

# cryptsetup -y -v luksFormat /dev/sdaX
# cryptsetup open /dev/sdaX cryptroot
# mkfs -t ext4 /dev/mapper/cryptroot
# mount -t ext4 /dev/mapper/cryptroot /mnt

Check the mapping works as intended:

# umount /mnt
# cryptsetup close cryptroot
# cryptsetup open /dev/sdaX cryptroot
# mount -t ext4 /dev/mapper/cryptroot /mnt

If you created separate partitions (e.g. /home), these steps have to be adapted and repeated for all of them, except for /boot. See Dm-crypt/Encrypting a non-root file system#Automated unlocking and mounting on how to handle additional partitions at 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 keyfile stored in the system partition to unlock the separate partition via crypttab. See Dm-crypt/Device encryption#Using LUKS to format partitions with a keyfile for instructions.

Preparing the boot partition

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, for example, execute:

# mkfs -t ext4 /dev/sdaY
# mkdir /mnt/boot
# mount -t ext4 /dev/sdaY /mnt/boot

Mounting the devices

At Installation guide#Mount the partitions you will have to mount the mapped devices, not the actual partitions. Of course /boot, which is not encrypted, will still have to be mounted directly.

Afterwards continue with the installation procedure up to the mkinitcpio step.

Configuring mkinitcpio

Add the encrypt hook to mkinitcpio.conf:

etc/mkinitcpio.conf
HOOKS="... encrypt ... filesystems ..."

Depending on which other hooks are used, the order may be relevant. See dm-crypt/System configuration#mkinitcpio for details and other hooks that you may need.

Configuring the boot loader

In order to unlock the encrypted root partition at boot, the following kernel parameters need to be set by the boot loader:

cryptdevice=UUID=<device-UUID>:cryptroot root=/dev/mapper/cryptroot

See Dm-crypt/System configuration#Boot loader for details.

The <device-UUID> refers to the UUID of /dev/sdaX, see Persistent block device naming for details.

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.

The disk layout in this example is:

+-----------------------------------------------------------------------+ +----------------+
| Logical volume1       | Logical volume2       | Logical volume3       | |                |
|/dev/mapper/MyVol-swap |/dev/mapper/MyVol-root |/dev/mapper/MyVol-home | | Boot partition |
|_ _ _ _ _ _ _ _ _ _ _ _|_ _ _ _ _ _ _ _ _ _ _ _|_ _ _ _ _ _ _ _ _ _ _ _| | (may be on     |
|                                                                       | | other device)  |
|                        LUKS encrypted partition                       | |                |
|                          /dev/sdaX                                    | | /dev/sdbY      |
+-----------------------------------------------------------------------+ +----------------+

This method does not allow you to span the logical volumes over multiple disks, even in the future. The #LUKS on LVM method does not have this limitation.

Tip: Two variants of this setup:

Preparing the disk

Prior to creating any partitions, you should inform yourself about the importance and methods to securely erase the disk, described in Dm-crypt/Drive preparation.

When using the GRUB bootloader together with GPT, create a BIOS Boot Partition as explained in GRUB#BIOS systems.

Create a partition to be mounted at /boot of type 8300 with a size of 100 MB or more.

Create a partition of type 8E00, which will later contain the encrypted container.

Create the LUKS encrypted container at the "system" partition. Enter the chosen password twice.

# cryptsetup luksFormat /dev/sdaX

For more information about the available cryptsetup options see the LUKS encryption options prior to above command.

Open the container:

# cryptsetup open --type luks /dev/sdaX lvm

The decrypted container is now available at /dev/mapper/lvm.

Preparing the logical volumes

Create a physical volume on top of the opened LUKS container:

# pvcreate /dev/mapper/lvm

Create the volume group named MyVol (or whatever you want), adding the previously created physical volume to it:

# vgcreate MyVol /dev/mapper/lvm

Create all your logical volumes on the volume group:

# lvcreate -L 8G MyVol -n swap
# lvcreate -L 15G MyVol -n root
# lvcreate -l 100%FREE MyVol -n home

Format your filesystems on each logical volume:

# mkfs.ext4 /dev/mapper/MyVol-root
# mkfs.ext4 /dev/mapper/MyVol-home
# mkswap /dev/mapper/MyVol-swap

Mount your filesystems:

# mount /dev/mapper/MyVol-root /mnt
# mkdir /mnt/home
# mount /dev/mapper/MyVol-home /mnt/home
# swapon /dev/mapper/MyVol-swap

Preparing the boot partition

The bootloader loads the kernel, initramfs, and its own configuration files from the /boot directory. This directory must be located on a separate unencrypted filesystem.

Create an Ext2 filesystem on the partition intended for /boot. Any filesystem that can be read by the bootloader is eligible.

# mkfs.ext2 /dev/sdbY

Create the directory /mnt/boot:

# mkdir /mnt/boot

Mount the partition to /mnt/boot:

# mount /dev/sdbY /mnt/boot

Afterwards continue with the installation procedure up to the mkinitcpio step.

Configuring mkinitcpio

Add the encrypt and lvm2 hooks to mkinitcpio.conf:

/etc/mkinitcpio.conf
HOOKS="... encrypt lvm2 ... filesystems ..."

See dm-crypt/System configuration#mkinitcpio for details and other hooks that you may need.

Configuring the boot loader

In order to unlock the encrypted root partition at boot, the following kernel parameters need to be set by the boot loader:

cryptdevice=UUID=device-UUID:lvm root=/dev/mapper/MyVol-root

The <device-UUID> refers to the UUID of /dev/sdaX, see Persistent block device naming for details.

See Dm-crypt/System configuration#Boot loader for details.

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. If you want to span a logical volume over multiple disks during setup already, a procedure to do so is described in Dm-crypt/Specialties#Expanding LVM on multiple disks.

Tango-view-fullscreen.pngThis article or section needs expansion.Tango-view-fullscreen.png

Reason: The intro of this scenario needs some adjustment now that a comparison has been added to #Overview. A suggested structure is to make it similar to the #Simple partition layout with LUKS intro. (Discuss in Talk:Dm-crypt/Encrypting an entire system#)

Preparing the disk

Partitioning scheme:

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

Randomise /dev/sda2 according to Dm-crypt/Drive preparation#dm-crypt wipe before installation[broken link: invalid section].

Preparing the logical volumes

# lvm pvcreate /dev/sda2
# lvm vgcreate lvm /dev/sda2
# lvm lvcreate -L 10G -n lvroot 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-plain64 -s 512 /dev/lvm/lvroot
# cryptsetup open --type luks /dev/lvm/lvroot root
# mkfs -t ext4 /dev/mapper/root
# mount /dev/mapper/root /mnt

More information about the encryption options can be found in Dm-crypt/Device encryption#Encryption options for LUKS mode. Note that /home will be encrypted in #Encrypting logical volume /home. Further, note that if you ever have to access the encrypted root from the Arch-ISO, the above open action will allow you to after the LVM shows up.

Preparing the boot partition

# dd if=/dev/zero of=/dev/sda1 bs=1M
# mkfs -t ext4 /dev/sda1
# mkdir /mnt/boot
# mount /dev/sda1 /mnt/boot

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

Configuring mkinitcpio

Add the lvm2 and encrypt hooks to mkinitcpio.conf:

etc/mkinitcpio.conf
HOOKS="... block ''encrypt lvm2 ... filesystems ..."

See dm-crypt/System configuration#mkinitcpio for details and other hooks that you may need.

Configuring the boot loader

In order to unlock the encrypted root partition at boot, the following kernel parameters need to be set by the boot loader:

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

See Dm-crypt/System configuration#Boot loader for details.

Configuring fstab and crypttab

/etc/fstab
 /dev/mapper/root        /       ext4            defaults        0       1
 /dev/sda1               /boot   ext4            defaults        0       2
 /dev/mapper/tmp         /tmp    tmpfs           defaults        0       0
 /dev/mapper/swap        none    swap            sw              0       0

The following crypttab options will re-encrypt the temporary filesystems each reboot:

/etc/crypttab
 swap	/dev/lvm/swap	/dev/urandom	swap,cipher=aes-xts-plain64,size=256
 tmp	/dev/lvm/tmp	/dev/urandom	tmp,cipher=aes-xts-plain64,size=256

Encrypting logical volume /home

Since this scenario uses LVM as the primary and dm-crypt as secondary mapper, each encrypted logical volume requires its own encryption. Yet, unlike the temporary filesystems configured with volatile encryption above, the logical volume for /home should be persistent, of course. The following assumes you have rebooted into the installed system, otherwise you have to adjust paths. To safe on entering a second passphrase at boot for it, a keyfile is created:

mkdir -m 700 /etc/luks-keys
dd if=/dev/random of=/etc/luks-keys/home bs=1 count=256

The logical volume is encrypted with it:

cryptsetup luksFormat -v -s 512 /dev/lvm/home /etc/luks-keys/home
cryptsetup -d /etc/luks-keys/home open --type luks /dev/lvm/home home
mkfs -t ext4 /dev/mapper/home
mount /dev/mapper/home /home

The encrypted mount is configured in crypttab:

/etc/crypttab
home	/dev/lvm/home   /etc/luks-keys/home
/etc/fstab
/dev/mapper/home        /home   ext4        defaults        0       2

and setup is done.

If you want to expand the logical volume for /home (or any other volume) at a later point, it is important to note that the LUKS encrypted part has to be resized as well. For a procedure see Dm-crypt/Specialties#Expanding LVM on multiple disks.

LUKS on software RAID

Tango-view-fullscreen.pngThis article or section needs expansion.Tango-view-fullscreen.png

Reason: Some references: RAID, Software RAID and LVM, http://wiki.drewhess.com/wiki/Creating_an_encrypted_filesystem_on_a_partition , http://jasonwryan.com/blog/2012/02/11/lvm/ . Note that full-disk encryption is not deniable with this configuration (consider RAID on LUKS instead?). (Discuss in Talk:Dm-crypt/Encrypting an entire system#)

Plain dm-crypt

Contrary to LUKS, dm-crypt plain mode does not require a header on the encrypted device: this scenario exploits this feature to set up a system on an unpartitioned, encrypted disk that will be indistinguishable from a disk filled with random data, which could allow deniable encryption. See also wikipedia:Disk encryption#Full disk encryption.

Note that if full-disk encryption is not required, the methods using LUKS described in the sections above are better options for both system encryption and encrypted partitions. LUKS features like key management with multiple passphrases/key-files or re-encrypting a device in-place are unavailable with plain mode.

Plain dm-crypt encryption can be more resilient to damage than LUKS, 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. Using plain mode could also be considered if concerned with the problems explained in Dm-crypt/Specialties#Discard/TRIM support for solid state drives (SSD).

Tip: If headerless encryption is your goal but you are unsure about the lack of key-derivation with plain mode, then two alternatives are:
  • tcplay which offers headerless encryption but with the PBKDF2 function, or
  • dm-crypt LUKS mode by using the cryptsetup --header option. It cannot be used with the standard encrypt hook, but the hook may be modified.

The scenario uses two USB sticks:

  • one for the boot device, which also allows storing the options required to open/unlock the plain encrypted device in the boot loader configuration, since typing them on each boot would be error prone;
  • another for the encryption key file, assuming it stored as raw bits so that to the eyes of an unaware attacker who might get the usbkey the encryption key will appear as random data instead of being visible as a normal file. See also Wikipedia:Security through obscurity, follow Dm-crypt/Device encryption#Keyfiles to prepare the keyfile.

The disk layout is:

+--------------------+------------------+--------------------+ +---------------+ +---------------+
|Volume 1:           |Volume 2:         |Volume 3:           | |Boot device    | |Encryption key |
|                    |                  |                    | |               | |file storage   |
|root                |swap              |home                | |/boot          | |(unpartitioned |
|                    |                  |                    | |               | |in example)    |
|/dev/store/root     |/dev/store/swap   |/dev/store/home     | |/dev/sdY1      | |/dev/sdZ       |
|--------------------+------------------+--------------------| |---------------| |---------------|
|disk drive /dev/sdaX encrypted using plain mode and LVM     | |USB stick 1    | |USB stick 2    |
+------------------------------------------------------------+ +---------------+ +---------------+
Tip:
  • It is also possible to use a single usb key by copying the keyfile to the initram directly. An example keyfile /etc/keyfile gets copied to the initram image by setting FILES="/etc/keyfile" in /etc/mkinitcpio.conf. The way to instruct the encrypt hook to read the keyfile in the initram image is using rootfs: prefix before the filename, e.g. cryptkey=rootfs:/etc/keyfile.
  • Another option is using a passphrase with good entropy.

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.

See Dm-crypt/Drive preparation and Dm-crypt/Drive preparation#dm-crypt specific methods

Preparing the non-boot partitions

See Dm-crypt/Device encryption#Encryption options for plain mode for details.

Using the device /dev/sdX, with the twofish-xts cipher with a 512 bit key size and using a keyfile we have the following options for this scenario:

# cryptsetup --hash=sha512 --cipher=twofish-xts-plain64 --offset=0 --key-file=/dev/sdZ --key-size=512 open --type=plain /dev/sdX enc

Unlike encrypting with LUKS, the above command must be executed in full whenever the mapping needs to be re-established, so it is important to remember the cipher, hash and key file details.

We can now check a mapping entry has been made for /dev/mapper/enc:

# fdisk -l

Next, we setup LVM logical volumes on the mapped device, see LVM#Installing Arch Linux on LVM for further details:

# pvcreate /dev/mapper/enc
# vgcreate store /dev/mapper/enc
# lvcreate -L 20G store -n root
# lvcreate -L 10G store -n swap
# lvcreate -l 100%FREE store -n home

We format and mount them and activate swap, see File systems#Format a device[broken link: invalid section] for further details:

# mkfs.ext4 /dev/store/root
# mkfs.ext4 /dev/store/home
# mount /dev/store/root /mnt
# mkdir /mnt/home
# mount /dev/store/home /mnt/home
# mkswap /dev/store/swap
# swapon /dev/store/swap

Preparing the boot partition

The /boot partition can be installed on the standard vfat partition of a USB stick, if required. But if manual partitioning is needed, then a small 200MB partition is all that is required. Create the partition using a partitioning tool of your choice.

We choose a non-journalling file system to preserve the flash memory of the /boot partition, if not already formatted as vfat:

# mkfs.ext2 /dev/sdY1
# mkdir /mnt/boot
# mount /dev/sdY1 /mnt/boot

Configuring mkinitcpio

Add the encrypt and lvm2 hooks to mkinitcpio.conf:

etc/mkinitcpio.conf
HOOKS="... encrypt lvm2 ... filesystems ..."

See dm-crypt/System configuration#mkinitcpio for details and other hooks that you may need.

Configuring the boot loader

In order to boot the encrypted root partition, the following kernel parameters need to be set by the boot loader:

cryptdevice=/dev/sdX:enc cryptkey=/dev/sdZ:0:512 crypto=sha512:twofish-xts-plain64:512:0:
Note: If using sd-encrypt instead of encrypt, use luks.uuid instead of cryptdevice, see systemd-cryptsetup-generator(8).

See Dm-crypt/System configuration#Boot loader for details and other parameters that you may need.

Tip: If using GRUB, you can install it on the same USB as the /boot partition with:
# grub-install --recheck /dev/sdY

Post-installation

You may wish to remove the USB sticks after booting. Since the /boot partition is not usually needed, the noauto option can be added to the relevant line in /etc/fstab:

/etc/fstab
# /dev/sdYn
/dev/sdYn /boot ext2 noauto,rw,noatime 0 2

However, when an update to the kernel or bootloader is required, the /boot partition must be present and mounted. As the entry in fstab already exists, it can be mounted simply with:

# mount /boot

Encrypted boot partition (GRUB)

This setup utilizes the same partition layout and configuration for the system's root partition as the previous #LVM on LUKS section, with two distinct differences:

  1. The setup is performed for an UEFI system and
  2. A special feature of the GRUB bootloader is used to additionally encrypt the boot partition /boot. See also GRUB#Boot partition.

The disk layout in this example is:

+---------------+----------------+----------------+----------------+----------------+
|ESP partition: |Boot partition: |Volume 1:       |Volume 2:       |Volume 3:       |
|               |                |                |                |                |
|/boot/efi      |/boot           |root            |swap            |home            |
|               |                |                |                |                |
|               |                |/dev/store/root |/dev/store/swap |/dev/store/home |
|/dev/sdaX      |/dev/sdaY       +----------------+----------------+----------------+
|unencrypted    |LUKS encrypted  |/dev/sdaZ encrypted using LVM on LUKS             |
+---------------+----------------+--------------------------------------------------+
Tip: All scenarios are intended as examples. It is, of course, possible to apply both of the two above distinct installation steps with the other scenarios as well. See also the variants linked in #LVM on LUKS.

Preparing the disk

Prior to creating any partitions, you should inform yourself about the importance and methods to securely erase the disk, described in Dm-crypt/Drive preparation.

Create an EFI System Partition with an appropriate size, it will later be mounted at /boot/efi.

Create a partition to be mounted at /boot of type 8300 with a size of 100 MB or more.

Tip: When using the GRUB bootloader together with a BIOS/GPT, create a BIOS Boot Partition as explained in GRUB#BIOS systems instead of the ESP.

Create a partition of type 8E00, which will later contain the encrypted container.

Create the LUKS encrypted container at the "system" partition.

# cryptsetup luksFormat /dev/sdaZ

For more information about the available cryptsetup options see the LUKS encryption options prior to above command.

Your partition layout should look similar to this:

 gdisk /dev/sda 
Number  Start (sector)    End (sector)  Size       Code  Name
   1            2048         1050623   512.0 MiB   EF00  EFI System
   2         1050624         1460223   200.0 MiB   8300  Linux filesystem
   3         1460224        41943006   19.3 GiB    8E00  Linux LVM

Open the container:

# cryptsetup open --type luks /dev/sdaZ lvm

The decrypted container is now available at /dev/mapper/lvm.

Preparing the logical volumes

The LVM logical volumes of this example follow the exact layout as the previous scenario. Therefore, please follow Preparing the logical volumes above or adjust as required.

Preparing the boot partition

The bootloader loads the kernel, initramfs, and its own configuration files from the /boot directory.

First, create the LUKS container where the files will be located and installed into:

# cryptsetup luksFormat /dev/sdaY 

Next, open it:

# cryptsetup open /dev/sdaY cryptboot 

Create a filesystem on the partition intended for /boot. Any filesystem that can be read by the bootloader is eligible:

# mkfs.ext2 /dev/mapper/cryptboot

Create the directory /mnt/boot:

# mkdir /mnt/boot

Mount the partition to /mnt/boot:

# mount /dev/mapper/cryptboot /mnt/boot

Create a mountpoint for the EFI System Partition at /boot/efi for compatibility with grub-install and mount it:

# mkdir /mnt/boot/efi
# mount /dev/sdaX /mnt/boot/efi

At this point, you should have the following partitions and logical volumes inside of /mnt:

lsblk
NAME              	  MAJ:MIN RM   SIZE RO TYPE  MOUNTPOINT
sda                       8:0      0   200G  0 disk  
├─sda1                    8:1      0   512M  0 part  /boot/efi
├─sda2                    8:2      0   200M  0 part  
│ └─boot		  254:0    0   198M  0 crypt /boot
└─sda3                    8:3      0   100G  0 part  
  └─lvm                   254:1    0   100G  0 crypt 
    ├─MyStorage-swapvol   254:2    0     8G  0 lvm   [SWAP]
    ├─MyStorage-rootvol   254:3    0    15G  0 lvm   /
    └─MyStorage-homevol   254:4    0    77G  0 lvm   /home

Afterwards continue with the installation procedure up to the mkinitcpio step.

Configuring mkinitcpio

Add the encrypt and lvm2 hooks to mkinitcpio.conf:

/etc/mkinitcpio.conf
HOOKS="... encrypt lvm2 ... filesystems ..."

See dm-crypt/System configuration#mkinitcpio for details and other hooks that you may need.

Configuring the boot loader

Configure GRUB to recognize the LUKS encrypted /boot partition and unlock the encrypted root partition at boot:

/etc/default/grub
GRUB_CMDLINE_LINUX="... cryptdevice=UUID=<device-UUID>:lvm root=/dev/mapper/MyStorage-rootvol ..."
GRUB_ENABLE_CRYPTODISK=y

See Dm-crypt/System configuration#Boot loader and GRUB#Boot partition for details. The <device-UUID> refers to the UUID of /dev/sdaZ (the partition which holds the lvm containing the root filesystem), see Persistent block device naming.

Generate GRUB's configuration file and install to the mounted ESP:

# grub-mkconfig -o /boot/grub/grub.cfg
# grub-install --target=x86_64-efi --efi-directory=/boot/efi --bootloader-id=grub --recheck

If this finished without errors, GRUB should prompt for the passphrase to unlock the /boot partition after the next reboot.

Configuring fstab and crypttab

This section deals with extra configuration to let the system mount the encrypted /boot.

While GRUB asks for a passphrase to unlock the encrypted /boot after above instructions, the partition unlock is not passed on to the initramfs. Hence, /boot will not be available after the system has re-/booted, because the encrypt hook only unlocks the system's root.

If you used the genfstab script during installation, it will have generated /etc/fstab entries for the /boot and /boot/efi mount points already, but the system will fail to find the generated device mapper for the boot partition. To make it available, add it to crypttab. For example:

/etc/crypttab
cryptboot  /dev/sdaY      none        luks

will make the system ask for the passphrase again (i.e. you have to enter it twice at boot: once for GRUB and once for systemd init). To avoid the double entry for unlocking /boot, follow the instructions at Dm-crypt/Device encryption#Keyfiles to:

  1. Create a randomtext keyfile,
  2. Add the keyfile to the (/dev/sdaY) boot partition's LUKS header and
  3. Check the /etc/fstab entry and add the /etc/crypttab line to unlock it automatically at boot.

If for some reason the keyfile fails to unlock the boot partition, systemd will fallback to ask for a passphrase to unlock and, in case that is correct, continue booting.

Tip: Optional post-installation steps:
  • It may be worth considering to add the GRUB bootloader to the ignore list of /etc/pacman.conf in order to take particular control of when the bootloader (which includes its own encryption modules) is updated.
  • If you want to encrypt the /boot partition to protect against offline tampering threats, the mkinitcpio-chkcryptoboot hook has been contributed to help.

Btrfs subvolumes with swap

The following example creates a full system encryption with LUKS using Btrfs subvolumes to simulate partitions.

If using UEFI, an EFI System Partition (ESP) is required. /boot itself may reside on / and be encrypted; however, the ESP itself cannot be encrypted. In this example layout, the ESP is /dev/sdaY and is mounted at /boot/efi. /boot itself is located on the system partition, /dev/sdaX.

Since /boot resides on the encrypted /, GRUB must be used as the bootloader because only GRUB can load modules necessary to decrypt /boot (e.g., crypto.mod, cryptodisk.mod and luks.mod) [1].

Additionally an optional plain-encrypted swap partition is shown.

Warning: Do not use a swap file instead of a separate partition, because this may result in data loss. See Btrfs#Swap file.
+--------------------------+--------------------------+--------------------------+
|ESP                       |System partition          |Swap partition            |
|unencrypted               |LUKS-encrypted            |plain-encrypted           |
|                          |                          |                          |
|/boot/efi                 |/                         |                          |
|/dev/sdaY                 |/dev/sdaX                 |/dev/sdaZ                 |
|--------------------------+--------------------------+--------------------------+

Preparing the disk

Note: It is not possible to use btrfs partitioning as described in Btrfs#Partitionless Btrfs disk when using LUKS. Traditional partitioning must be used, even if it is just to create one partition.

Prior to creating any partitions, you should inform yourself about the importance and methods to securely erase the disk, described in Dm-crypt/Drive preparation. If you are using UEFI create an EFI System Partition with an appropriate size. It will later be mounted at /boot/efi. If you are going to create an encrypted swap partition, create the partition for it, but do not mark it as swap, since plain dm-crypt will be used with the partition.

Create the needed partitions, at least one for / (e.g. /dev/sdaX). See the Partitioning article.

Preparing the system partition

Create LUKS container

Follow dm-crypt/Device encryption#Encrypting devices with LUKS mode to setup /dev/sdaX for LUKS. See the Dm-crypt/Device encryption#Encryption options for LUKS mode before doing so for a list of encryption options.

Unlock LUKS container

Now follow Dm-crypt/Device encryption#Unlocking/Mapping LUKS partitions with the device mapper to unlock the LUKS container and map it.

Format mapped device

Proceed to format the mapped device as described in Btrfs#File system on a single device, where /dev/partition is the name of the mapped device (i.e., cryptroot) and not /dev/sdaX.

Mount mapped device

Finally, mount the now-formatted mapped device (i.e., /dev/mapper/cryptroot) to /mnt.

Tip: You may want to use the compress=lzo mount option. See Btrfs#Compression for more information.

Creating btrfs subvolumes

Layout

Subvolumes will be used to simulate partitions, but other (nested) subvolumes will also be created. Here is a partial representation of what the following example will generate:

subvolid=5 (/dev/sdaX)
   |
   ├── @ (mounted as /)
   |       |
   |       ├── /bin (directory)
   |       |
   |       ├── /home (mounted @home subvolume)
   |       |
   |       ├── /usr (directory)
   |       |
   |       ├── /.snapshots (mounted @snapshots subvolume)
   |       |
   |       ├── /var/cache/pacman/pkg (nested subvolume)
   |       |
   |       ├── ... (other directories and nested subvolumes)
   |
   ├── @snapshots (mounted as /.snapshots)
   |
   ├── @home (mounted as /home)
   |
   └── @... (additional subvolumes you wish to use as mount points)

This section follows the Snapper#Suggested filesystem layout, which is most useful when used with Snapper. You should also consult Btrfs Wiki SysadminGuide#Layout.

Create top-level subvolumes

Here we are using the convention of prefixing @ to subvolume names that will be used as mount points, and @ will be the subvolume that is mounted as /.

Following the Btrfs#Creating a subvolume article, create subvolumes at /mnt/@, /mnt/@snapshots, and /mnt/@home.

Create any additional subvolumes you wish to use as mount points now.

Mount top-level subvolumes

Unmount the system partition at /mnt.

Now mount the newly created @ subvolume which will serve as / to /mnt using the subvol= mount option. Assuming the mapped device is named cryptroot, the command would look like:

# mount -o compress=lzo,subvol=@ /dev/mapper/cryptroot /mnt

See Btrfs#Mounting subvolumes for more details.

Also mount the other subvolumes to their respective mount points: @home to /mnt/home and @snapshots to /mnt/.snapshots.

Create nested subvolumes

Create any subvolumes you do not want to have snapshots of when taking a snapshot of /. For example, you probably do not want to take snapshots of /var/cache/pacman/pkg. These subvolumes will be nested under the @ subvolume, but just as easily could have been created earlier at the same level as @ according to your preference.

Since the @ subvolume is mounted at /mnt you will need to create a subvolume at /mnt/var/cache/pacman/pkg for this example. You may have to create any parent directories first.

Other directories you may wish to do this with are /var/abs, /var/tmp, and /srv.

Mount ESP

If you prepared an EFI system partition earlier, create its mount point and mount it now.

Note: Btrfs snapshots will exclude /boot/efi, since it is not a btrfs file system.

At the pacstrap installation step, the btrfs-progs must be installed in addition to the base group.

Configuring mkinitcpio

Create keyfile

In order for GRUB to open the LUKS partition without having the user enter his passphrase twice, we will use a keyfile embedded in the initramfs. Follow Dm-crypt/Device encryption#With a keyfile embedded in the initramfs making sure to add the key to /dev/sdaX at the luksAddKey step.

Edit mkinitcpio.conf

After creating, adding, and embedding the key as described above, add the encrypt hook to mkinitcpio.conf as well as any other hooks you require. See Dm-crypt/System configuration#mkinitcpio for detailed information. Be sure to regenerate the initial ramdisk when finished.

Tip: You may want to add BINARIES="/usr/bin/btrfs" to your mkinitcpio.conf. See the Btrfs#Corruption recovery article.

Configuring the boot loader

Install GRUB to /dev/sda. Then, edit /etc/default/grub as instructed in the GRUB#Encryption article, following both the instructions for an encrypted root and boot partition. Finally, generate the GRUB configuration file.

Configuring swap

If you created a partition to be used for encrypted swap, now is the time to configure it. Follow the instructions at Dm-crypt/Swap encryption.

After completing this step, continue configuring your system as normal according to the installation guide.