Full Disk Encryption From Scratch Simplified
Full disk encryption can be used to help protect data integrity and privacy. dm-crypt can be used to configure drives to be encrypted with LUKS or other formats. This article is a guide which covers the process of configuring a drive to be encrypted using LUKS and btrfs. This process can be done as part of a fresh install, or could be performed on a new drive to migrate an existing install.
Installation
Emerge
root #emerge --ask sys-fs/cryptsetupAdditional software
If using GPG to further secure key files:
root #emerge --ask app-crypt/gnupgSystem preparation
The kernel must be configured according to: Dm-crypt: Kernel Configuration.
If this is being followed as part of a fresh Gentoo install, the install procedure can be followed until the following step: AMD64 Handbook: Designing a partition scheme
If converting an existing system to an encrypted setup, either new storage must be added, or this procedure could be used to create new partitions using free space, where the data can then be copied after creation.
Depending on the type of drive, it can be difficult or impossible to truly overwrite portions of the drive where unencrypted, but de-referenced data exists. It is best to do a Secure wipe using the drive's firmware before re-using it.
If migrating an existing install to an encrypted root filesystem, the existing bootloader partition itself does not need to be modified (unless desired), but the bootloader configuration will need modification to boot from the new encrypted partitions.
Disk preparation
Partitioning typically does not involve modification of any of the data in partitions. If a drive is re-partitioned then encrypted, old data may remain in an unencrypted form until it is overwritten.
Modern storage devices may not be securely erased with something like dd if=/dev/urandom of=/dev/sdX.
For more information, see: Secure wipe.
This example will use GPT as disk partition schema and GRUB as boot loader. fdisk will be used as the partitioning tool though any partitioning utility will work.
For more information about GPT and EFI, see Disks (AMD64 Handbook).
For proper full disk encryption, using a separate boot drive:
/dev/sda
└── /dev/sda1 [EFI] /boot 1 GB fat32 Bootloader, bootloader support files, kernel and initramfs
/dev/nvme0n1
└── /dev/nvme0n1p1 [LUKS] (crypt) ->END luks encrypted partition
└── / ->END btrfs root filesystem
├── @home /home subvolume Subvolume created for the home directory
├── @var /var subvolume Subvolume created for the var directory
└── @etc /etc subvolume Subvolume created for the etc directory
Any filesystem type can be used for the root filesystem, but btrfs is used here. In most cases, FAT32 must be used for the EFI/boot partitions.
Using an external storage device, such as a USB drive, may make sense to use as a boot drive, since it can be easily removed once the system is booted, debugged more easily than an internal drive.
The size of the EFI partition is somewhat important, some devices will not boot using partitions which are too small (typically due to sector sizes[1]) , 512MB+ typically works.
Root device formatting
To create a partition layout using fdisk, start by creating a fresh partition table on the root disk, /dev/nvme0n1:
root #fdisk /dev/nvme0n1Welcome to fdisk (util-linux 2.38.1). Changes will remain in memory only, until you decide to write them. Be careful before using the write command. Device does not contain a recognized partition table. Created a new DOS disklabel with disk identifier 0x81391dbc. Command (m for help): g Created a new GPT disklabel (GUID: 8D91A3C1-8661-2940-9076-65B815B36906).
With a partition table crated, a new partition spanning the drive can be created by using n and then accepting the defaults:
Command (m for help):nPartition number (1-128, default 1):
First sector (2048-1953525134, default 2048):
Last sector, +/-sectors or +/-size{K,M,G,T,P} (2048-1953525134, default 1953523711):
Created a new partition 1 of type 'Linux filesystem' and of size 931.5 GiB.Finally, the changes can be written with w:
Command (m for help):wThe partition table has been altered. Calling ioctl() to re-read partition table. Syncing disks.
Boot device formatting
The boot disk can be setup using a similar process, the main difference is the boot flags will be set as a final step:
root #fdisk /dev/sda1Welcome to fdisk (util-linux 2.38.1). Changes will remain in memory only, until you decide to write them. Be careful before using the write command. Device does not contain a recognized partition table. Created a new DOS disklabel with disk identifier 0x81391dbc. Command (m for help): g Created a new GPT disklabel (GUID: 3E57DFCE-CDD9-6F42-8418-F0B6B4A08294).
With a fresh partition table, a 1GB partition can be created using:
Command (m for help):nPartition number (1-128, default 1):
First sector (2048-121008094, default 2048):
Last sector, +/-sectors or +/-size{K,M,G,T,P} (2048-121008094, default 121006079): +1G
Created a new partition 1 of type 'Linux filesystem' and of size 1 GiB.This partition could be created to span the entire device.
Finally, the ESP properties can be set using t:
Command (m for help):tSelected partition 1 Partition type or alias (type L to list all): 1 Changed type of partition 'Linux filesystem' to 'EFI System'.
Changes can be written with w:
Command (m for help):wThe partition table has been altered. Calling ioctl() to re-read partition table. Syncing disks.
LUKS Preparation
To prepare the encrypted filesystem, dm-crypt's cryptsetup can be used. Passwords and keys added to a partition are used to unlock the header, which contains the master key that actually encrypts the partition data.
To ensure the dm-crypt module is loaded, the following command can be used:
root #modprobe dm-cryptThe status of the module can be checked with:
user $lsmod | grep dm_cryptMore advanced usage information is available in man cryptsetup-luksFormat.
dm-crypt can do far more than LUKS configuration, more usage information is available on the wiki page.
Only specify arguments like --cipher if certain that it improves security beyond the sane defaults.
Passphrase secured LUKS Header
The most basic way to configure an encrypted volume is to use:
root #cryptsetup luksFormat --key-size 512 /dev/nvme0n1p1WARNING! ======== This will overwrite data on /dev/nvme0n1p1 irrevocably. Are you sure? (Type 'yes' in capital letters): YES Enter passphrase for /dev/sda2:
For a bit of additional security, the key size can be increased to 512 bits with --key-size 512.
A keyfile is typically considered to be more secure than a password, but should be password protected. An attacker must have the keyfile and know the password to break the drive's encryption.
Luks can allow multiple keys/passwords to be used to decrypt a partition. This can potentially decrease security, if password is wanted to recovery purposes, consider using a long passphrase and writing it down, or storing it offline.
Adding a Passphrase to Volume Using GPG Secured Key Files
To add a passphrase to a volume which is already secured using key files, a named pipe must be used for the key file contents:
root #mkfifo key_pipeThen the key can be decrypted to this pipe:
root #gpg --decrypt key_file > key_pipe &A passphrase can be added with:
root #cryptsetup luksAddKey --key-file key_pipe /dev/nvme0n1p1The named pipe can be cleaned up with:
root #rm key_pipeKey File Secured Header
Instead of securing the LUKS keyslots with a passphrase, keyfiles can be used.
Key files should be stored some place other than the devices they encrypt. A key file is a possession security factor, while passwords or passphrases are knowledge factors. What good is a lock if the keys are attached to it?
Take great care of this key file, if it is lost, the entire encrypted partition will be inaccessible, if it is stolen, the data is no longer safe. If it is ever written to unencrypted storage, or transmitted over a malicious network, it cannot be considered safe.
Using GnuPG to encrypt the key file can help keep it safe, adding a knowledge factor to it.
Key File Creation
Keyfiles can be created and stored in a variety of ways. It is recommended to encrypt keyfiles, so they cannot just be stolen and used.
Basic key file creation
A basic key file can be created using dd and /dev/urandom:
/tmp/ #dd bs=8388608 count=1 if=/dev/urandom of=crypt_key.luks1+0 records in 1+0 records out 8388608 bytes (8.4 MB, 8.0 MiB) copied, 0.014407 s, 582 MB/s
cryptsetup --help reveals the builtin key size and character size limit. The default is 8388608, or 8192 * 1024 (2^23).
GPG Symmetrically Encrypted Key File
For increased security, the key file can be immediately encrypted with GnuPG.
Symmetric encryption, using a password, is a simple method that works on most systems, but is vulnerable to keylogging, similarly to simple password/passphrase based protection.
If using the Gentoo install ISO, it may be necessary to run
root #export GPG_TTY=$(tty)/media/sda1/ #dd bs=8388608 count=1 if=/dev/urandom | gpg --symmetric --cipher-algo AES256 --output crypt_key.luks.gpg1+0 records in 1+0 records out 8388608 bytes (8.4 MB, 8.0 MiB) copied, 7.50139 s, 1.1 MB/s
GPG Asymmetrically Encrypted Key File
A key file can be protected using public key cryptography using a smartcard such as a YubiKey. This YubiKey GPG guide can be used to generate GPG keys on a YubiKey. With the public keys loaded, keys can be encrypted with they key holder as the recipient:
/media/sda1/ #dd bs=8388608 count=1 if=/dev/urandom | gpg --recipient larry@gentoo.org --output crypt_key.luks.gpg --encrypt1+0 records in 1+0 records out 8388608 bytes (8.4 MB, 8.0 MiB) copied, 7.50139 s, 1.1 MB/s
Dracut must be configured to use the corresponding public key, this is covered in the Dracut section.
When booting, ensure the smartcard is inserted. Dracut will prompt for the PIN, and depending on the configuration, the device may need to be tapped to complete presence detection.
Key File Usage
luksFormat Using a Key File
To secure the partition using a plain key file:
/media/sda1/ #cryptsetup --key-size 512 luksFormat /dev/nvme0n1p1 crypt_key.luksWARNING! ======== This will overwrite data on /dev/nvme0n1p1 irrevocably. Are you sure? (Type 'yes' in capital letters): YES
To add this keyfile to an already encrypted partition:
/media/sda1/ #cryptsetup luksAddKey /dev/nvme0n1p1 crypt_key.luksEnter any existing passphrase:
luksFormat Using a GPG protected keyfile
To secure the partition using a GPG protected key file:
/media/sda1/ #gpg --decrypt crypt_key.luks.gpg | cryptsetup luksFormat --key-size 512 /dev/nvme0n1p1 -gpg: AES256.CFB encrypted data WARNING! ======== This will overwrite data on /dev/nvme0n1p1 irrevocably. Are you sure? (Type 'yes' in capital letters): YES
To add the GPG encrypted keyfile to an already encrypted partition, named pipes must be used to avoid decrypting the key to disk, as both gpg and cryptsetup and expecting input from stdin:
/media/sda1/ #mkfifo crypt_key/media/sda1/ #mkfifo cryptsetup_passOnce the files are created, the key must be decrypted to crypt_key, and the recovery passhprase must be passed to cryptsetup_pass:
/media/sda1/ #gpg --decrypt crypt_key.luks.gpg > crypt_key &/media/sda1/ #read -s -r -p 'LUKS passphrase: ' CRYPT_PASS; echo "$CRYPT_PASS" > cryptsetup_pass &Finally, cat can be used to pass this information to cryptsetup:
/media/sda1/ #cat cryptsetup_pass crypt_key | cryptsetup luksAddKey /dev/nvme0n1p1 -gpg: AES256.CFB encrypted data gpg: encrypted with 1 passphrase [1]- Done read -s -r -p 'LUKS passphrase: ' CRYPT_PASS; echo "$CRYPT_PASS" > cryptsetup_pass [2]+ Done gpg -d crypt_key.luks.gpg > crypt_key
LUKS key status can be checked with cryptsetup luksDump {device}, ex. cryptsetup luksDump /dev/nvme0n1p1.
The named pipes can now be deleted.
LUKS Header Backup
Do not forget this step, keys/passwords are used to decrypt the LUKS header, if it is destroyed for some reason, the remaining data will only be recoverable with the header file.
The headers can be backed up with:
root #cryptsetup luksHeaderBackup /dev/nvme0n1p1 --header-backup-file crypt_headers.imgFilesystem Preparation
With the LUKS volume created, it must be mapped so the underlying filesystems can be created.
Open the LUKS volume
The encrypted device must be opened and mapped before it can be used, this can be done with:
root #cryptsetup luksOpen /dev/nvme0n1p1 cryptIf using a key file:
/media/sda1/ #cryptsetup --key-file=crypt_key.luks open /dev/nvme0n1p1 cryptIf using a GPG encrypted key file:
/media/sda1/ #gpg --decrypt crypt_key.luks.gpg | cryptsetup --key-file=- open /dev/nvme0n1p1 cryptThis command opens /dev/nvme0n1p1 and maps it under /dev/mapper/ with the name crypt.
Format the Filesystems
Create a filesystem for /dev/sda1, the boot partition which will contain GRUB and kernel files. This partition is read by UEFI. Most motherboards can read only a FAT32 filesystem:
root #mkfs.vfat -F32 /dev/sda1To create the btrfs root filesystem on the LUKS parittion:
root #mkfs.btrfs -L rootfs /dev/mapper/cryptThe labels are optional, but helpful. They allow for easy mounting without a UUID.
Create optional btrfs subvolumes
To create subvolumes for /etc, /home, and /var, the filesystem must first be mounted:
root #mount LABEL=rootfs /mnt/gentooThen each subvolume can be created:
root #btrfs subvolume create /mnt/gentoo/etc
root #btrfs subvolume create /mnt/gentoo/home
root #btrfs subvolume create /mnt/gentoo/varInitramfs configuration
An initramfs must be used to decrypt and mount the root partition. This can be accomplished using a minimal custom one, using a few commands, or using a tool like dracut to decrypt using parameters passed in the kernel command line.
Dracut
This configuration should be done while chrooted, or on a live system.
The following modules must be added to the add_dracutmodules directive in /etc/dracut.conf:
/etc/dracut.confMinimum required components to decrypt LUKS volumes using dracutadd_dracutmodules+=" crypt dm rootfs-block "
The spacing for Dracut configuration directives is very important. Ensure there are no spaces between add_dracutmodules and +=", parameters in add_dracutmodules must be padded with spaces.
If GPG keys are being used, the following module must also be added: crypt-gpg
/etc/dracut.confMinimum required components to decrypt LUKS volumes using dracutadd_dracutmodules+=" crypt crypt-gpg dm rootfs-block "
If a smartcard is used to store the private keys for a GPG encrypted key file, /etc/dracut.conf.d/crypt-public-key.gpg must be configured to contain the corresponding public key.
Dracut can be configured to build with configuration for LUKS hardcoded, first disk information must be obtained:
root #lsblk -o name,uuidNAME UUID sda └─sda1 BDF2-0139 nvme0n1 └─nvme0n1p1 4bb45bd6-9ed9-44b3-b547-b411079f043b └─crypt cb070f9e-da0e-4bc5-825c-b01bb2707704
/etc/dracut.confEmbed cmdline parameters for rootfs decryptionkernel_cmdline+=" root=LABEL=crypt rd.luks.uuid=4bb45bd6-9ed9-44b3-b547-b411079f043b rd.luks.key=/crypt_key.luks.gpg:UUID=BDF2-0139 "
The UUID of the volume containing the keyfiles is specified after the : with the
rd.luks.key argument.If using systemd for your init, you must also add the cryptsetup use flag:
/etc/portage/package.use/systemdsys-apps/systemd cryptsetup
And rebuild:
root #emerge --ask --newuse sys-apps/systemdOnce Dracut is configured, a new initramfs can be generated by running:
root #dracutDracut writes the file to /boot by default, this must be mounted.
If the initramfs is being generated for a kernel other than the currently active one, --kver must be used:
root #dracut --kver 6.1.28-gentoo
This can happen in a situation when the kernel version in the Gentoo Live CD differs from the emerged sys-kernel/gentoo-sources in the kernel compilation process.
Possible kernel versions can be found by using ls /lib/modules.
Dracut has now generated an initramfs, but configuration is not complete. Command line parameters must be set, either by manually adding them to the kernel, or by configuring them into the bootloader.
Most dracut configuration is described in man dracut.cmdline.
Extracting the initramfs
It's possible to use dracut to generate an initramfs image, then extract this to be built into the kernel.
/usr/src/initramfs #/usr/lib/dracut/skipcpio /boot/initramfs-6.1.28-gentoo-initramfs.img | zcat | cpio -ivdEmbedding the initramfs
With the initramfs extracted to /usr/src/initramfs, the kernel can be configured to embed it:
General Setup --->
[*] Initial RAM filesystem and RAM disk (initramfs/initrd) support
(/usr/src/initramfs) Initramfs source file(s)
[*] Support initial ramdisk/ramfs compressed using gzip
.config equivalent:
CONFIG_INITRAMFS_SOURCE="/usr/src/initramfs"
CONFIG_INITRAMFS_ROOT_UID=0
CONFIG_INITRAMFS_ROOT_GID=0
CONFIG_RD_GZIP=y
CONFIG_INITRAMFS_COMPRESSION_GZIP=y
With this configuration, the kernel will automatically embed whatever exists under /usr/src/initramfs into the kernel when it is built, and attempt to use it on boot. This is especially useful when Secure Booting.
If using a kernel which requires modules to boot, the initramfs must be recreated after the kernel is built once, extracted, then the kernel must be rebuilt to embed the latest initramfs. The rebuild should be very quick unless using make clean.
If using this method with GRUB, be sure to delete or move the dracut generate initramfs img if using GRUB so grub-mkconfig does not get confused.
Gentoo installation
If this procedure is being followed during a Gentoo install (in place of Handbook:AMD64/Full/Installation#Designing_a_partition_scheme through Handbook:AMD64/Full/Installation#Mounting_the_root_partition), the following steps can be used to mount the created partition, to continue with the install.
Mount the root partition
The logical volume for the root file system can be mounted at this created location with:
root #mount LABEL=rootfs /mnt/gentoofstab configuration
The correct fstab file must be edited, if this is being done before chrooting, ensure the correct path is being used. More information exists in the filesystem portion of the install guide.
For consistent volume mounting, labels and UUIDs must be used.
Block devices and their associated partition IDs can be viewed with:
root #lsblk -o name,uuidNAME UUID sda └─sda1 BDF2-0139 nvme0n1 └─nvme0n1p1 4bb45bd6-9ed9-44b3-b547-b411079f043b └─crypt cb070f9e-da0e-4bc5-825c-b01bb2707704
With the partition UUIDs and labels identified, /etc/fstab can be edited to add relevant mounts:
/mnt/gentoo/etc/fstab# <fs> <mountpoint> <type> <opts> <dump/pass>
UUID=BDF2-0139 /boot vfat noauto,noatime 1 2
LABEL=rootfs / btrfs defaults 0 1
Because the subvolumes are created where they would be mounted, they do not need fstab entries.
Finalizing the Gentoo install
The general install guide should apply. A few considerations must be made, the initial RAM filesystem must be built with support for decrypting the root partition, and the kernel commandline must be configured to pass parameters to the initamfs if required.
At this point, the Gentoo install can be continued normally: Installing a stage tarball
Additional information
SSD tricks
Using SSDs and also hybrid drives sacrifices some cryptographic security for speed-improvement and lower power consumption. See FAQs of cryptsetup for the details. Plan with drive's degradation and loss of space over time. With or without trim physical destruction of the drive is necessary. There are no guarantees that overwriting really changes bits in the drive's memory chips. This is not a problem of cryptsetup, LUKS or the kernel but caused by the firmware/ hardware/ vendor- and model-specific algorithms.
SSD trim allows an operating system to inform a solid-state drive (SSD) which blocks of data are no longer considered in use and can be wiped internally. Because low-level operation of SSDs differs significantly from hard drives, the typical way in which operating systems handle operations like deletes and formats resulted in unanticipated progressive performance degradation of write operations on SSDs. Trimming enables the SSD to more efficiently handle garbage collection, which would otherwise slow future write operations to the involved blocks. To enable SSD trim of encrypted root filesystem on LVM, edit the /etc/default/grub file if using genkernel:
/etc/default/grubGRUB_CMDLINE_LINUX="...root_trim=yes"
If using dracut to generate the intiramfs the use:
/etc/default/grubGRUB_CMDLINE_LINUX="...rd.luks.allow-discards"
If using systemd-based initramfs the use:
/etc/default/grubGRUB_CMDLINE_LINUX="...rd.luks.options=discard"
This will notify the kernel to enable trim on roots.
Edit the /etc/lvm/lvm.conf configuration file:
/etc/lvm/lvm.confissue_discards = 1
This will notify LVM layer to enable SSD trim.
When using SSDs and UEFI-boot the boot sequence might be too fast. When entering the correct passphrase, the kernel will complain about missing modules or no root device. Try to add rootdelay=3 to GRUB_CMDLINE_LINUX_DEFAULT in /etc/default/grub, or directly append it in edit mode of the GRUB menu when booting.