4.4.4 Full disk encryption (LUKS)

Why LUKS and where it fits

Linux Unified Key Setup (LUKS) is the standard way to do block‑device encryption on Linux, usually via dm-crypt. In the context of advanced storage, LUKS gives you:

• Full‑disk or partition‑level encryption (not per‑file)
• Interoperability across distros (standard on-disk format)
• Multiple key slots for different passphrases/keys
• Integration with initramfs and systemd for early‑boot unlocking

Here we focus on how LUKS works, its versions, and how to design, set up, and manage full‑disk encryption on a Linux system.

LUKS1 vs LUKS2

Modern systems should generally use LUKS2, but you will still encounter LUKS1.

On‑disk format

A LUKS container (on a partition or disk) has:

• A header: metadata (cipher, keyslots, PBKDF parameters)
• Keyslots: encrypted copies of the master key, each protected by a passphrase or key file
• Payload area: the encrypted data (filesystem, LVM PV, etc.)

Neither the header nor keyslots contain your actual data, only the master key in wrapped (encrypted) form.

LUKS1 characteristics

• Fixed header structure; limited metadata
• Limited to one key derivation function type per device
• No built‑in redundancy for the header
• Supported by all distros, older initramfs, and bootloaders

You may prefer LUKS1 when:

• You need broad backward compatibility (older rescue media, old BIOS setups)
• You are using software that only knows LUKS1

LUKS2 characteristics

• Flexible, extensible JSON‑based metadata
• Supports multiple PBKDFs (e.g., Argon2id), sector size mapping, and metadata redundancy
• Better resilience: optional header backups and integrity features (via --integrity)
• Supports features like reencryption in place (with cryptsetup-reencrypt)

You generally want:

• LUKS2 for new deployments
• LUKS1 only if you have a concrete compatibility requirement

To check:

cryptsetup luksDump /dev/sdXn

Look for Version: 1 or Version: 2.

LUKS concepts: master key, keyslots, PBKDF

Master key and data encryption

When you create a LUKS volume, cryptsetup generates a random master key. This key directly encrypts the data using a block cipher (commonly AES) in a mode suited for disk encryption (e.g., XTS).

• The master key never changes unless you explicitly reenrypt the device.
• Passphrases do not encrypt the data; they protect the master key.

Keyslots and passphrases

Each keyslot stores a copy of the master key wrapped by a passphrase or key file, derived via a PBKDF (Password‑Based Key Derivation Function).

Properties:

• Up to 8 keyslots typically (slot 0–7) for LUKS1; LUKS2 can be extended
• You can have multiple independent passphrases/keys; any one can unlock the disk
• Deleting a keyslot revokes the corresponding passphrase without touching data

Managing keyslots (examples on an existing LUKS device /dev/sdXn):

• List keyslots:

  cryptsetup luksDump /dev/sdXn

• Add a new passphrase:

  cryptsetup luksAddKey /dev/sdXn

You’ll enter an existing valid passphrase first, then the new one.

• Remove a passphrase:

  cryptsetup luksRemoveKey /dev/sdXn

You’ll type the passphrase you want to revoke.

PBKDF (key stretching)

Passphrases are run through a PBKDF to slow brute‑force attacks. LUKS uses:

• LUKS1: usually PBKDF2 (HMAC‑based, CPU‑bound)
• LUKS2: can use argon2i / argon2id (memory‑hard, more resistant to GPU/ASIC attacks)

Choosing PBKDF parameters is a trade‑off:

• Higher iteration count / memory use → slower unlocks but stronger against guessing
• For desktop/laptop, a 0.5–2 second delay at boot is generally acceptable

When creating a LUKS volume, you can tune this with:

cryptsetup luksFormat --type luks2 \
  --pbkdf argon2id --pbkdf-memory 1048576 --pbkdf-time 2000 \
  /dev/sdXn

(Values are examples; cryptsetup will auto‑tune if you omit them.)

Layout patterns for “full‑disk” encryption

“Full disk” is often implemented with combinations of LUKS, partitions, and LVM. Common layouts:

Encrypted root + swap + home via LVM inside LUKS

Layout (most distros’ “encrypt whole disk” option):

1. Create a small unencrypted /boot partition.
2. Create one large partition for everything else.
3. Put LUKS on that large partition.
4. Inside the unlocked LUKS device, create an LVM PV/VG/LVs for:
• / (root)
• swap
• optionally /home (as a separate LV)

Pros:

• Only one passphrase at boot
• Simple to back up (LUKS device or individual filesystems)
• Easy to extend with more LVs

Cons:

• /boot remains unencrypted (needed for classic GRUB; see below for alternatives)
• Attackers with physical access can modify /boot unless extra protections are used

Separate LUKS for each partition

Example:

• sda1: /boot (plaintext)
• sda2: LUKS → /
• sda3: LUKS → /home
• sda4: LUKS → swap

Pros:

• Fine‑grained control over keys and passphrases per partition
• Possible to give different users different keys for different disks

Cons:

• Multiple prompts at boot (unless you use key files or systemd integration)
• Harder to manage and resize than LVM‑inside‑LUKS

Full‑disk including `/boot` (with modern boot chains)

Modern bootloaders/firmware combinations (e.g., systemd‑boot, GRUB on some setups, Secure Boot + TPM integration) can support:

• Encrypted /boot inside LUKS
• Unified kernel images (UKI) with the initramfs and kernel in one signed artifact

This is more advanced and distro‑specific, but the key idea is: the firmware and bootloader trust chain must be able to unlock the LUKS container or verify a signed image before loading the kernel.

Creating a LUKS encrypted device

Here we create a LUKS2 device on /dev/sdX2 and a filesystem on top. This is the block device side; integrating it with the boot process is covered later.

1. Prepare the partition

Using your preferred partition tool (fdisk, parted, etc.), create a partition (e.g., /dev/sdX2) and mark it as a LUKS/crypto partition type if available (for metadata clarity only).

2. Initialize LUKS

cryptsetup luksFormat --type luks2 /dev/sdX2

You will be prompted to confirm and then set an initial passphrase.

Choosing options

Common useful options:

• Cipher and key size (defaults are usually fine):

  cryptsetup luksFormat \
    --type luks2 \
    --cipher aes-xts-plain64 --key-size 512 \
    /dev/sdX2

• PBKDF tuning (as discussed above)
• Randomness source: for automated scripts you can pass --use-random or --use-urandom (trade‑off between quality and speed).

3. Open (map) the LUKS device

Opening creates a device mapper node under /dev/mapper/:

cryptsetup open /dev/sdX2 cryptdata

This creates /dev/mapper/cryptdata which exposes decrypted blocks.

4. Create a filesystem inside

Now create a filesystem on the mapped device:

mkfs.ext4 /dev/mapper/cryptdata

Then mount it normally:

mkdir /mnt/secure
mount /dev/mapper/cryptdata /mnt/secure

To close later:

umount /mnt/secure
cryptsetup close cryptdata

Integrating LUKS with the boot process

For full‑disk encryption (including the root filesystem), you must unlock LUKS before the real root is mounted. This is handled by:

• An initramfs (early userspace), which:
• Prompts for the passphrase
• Calls cryptsetup open
• Mounts the decrypted device as /
• Configuration in /etc/crypttab and /etc/fstab

`/etc/crypttab` basics

/etc/crypttab defines encrypted devices to open at boot:

Format:

<name>  <source>       <keyfile>  <options>

Examples:

• Root (with passphrase entered at boot):

  cryptroot  UUID=<uuid-of-luks-partition>  none  luks

• Swap with a random ephemeral key (no passphrase):

  cryptswap  /dev/sdX3  /dev/urandom  swap,cipher=aes-xts-plain64,size=256

• Data volume unlocked by a keyfile:

  cryptdata  /dev/sdX4  /root/keys/data.key  luks

After editing /etc/crypttab, rebuild your initramfs (distro‑specific, e.g. update-initramfs -u or dracut -f).

`/etc/fstab` and decrypted devices

Once a LUKS device is opened at boot (e.g., with name cryptroot), the resulting node is /dev/mapper/cryptroot. In /etc/fstab you then mount that:

/dev/mapper/cryptroot  /      ext4  defaults  0  1
/dev/mapper/cryptdata  /data  ext4  defaults  0  2

The main rule: fstab refers to the decrypted mapper devices, not the raw LUKS partitions.

Passphrase strategies and key files

Strong passphrases

Because the attacker can make unlimited offline attempts to guess your passphrase, quality matters:

• Use long passphrases (e.g., 5–7 random words or >16 random characters)
• Avoid reusing passphrases from other services
• Prefer Argon2id (LUKS2) if available

Multiple passphrases for different purposes

Use separate keyslots for:

• Daily interactive passphrase
• Emergency or backup passphrase stored securely offline
• Keyfiles stored on removable media

Add a new keyslot with a keyfile:

# Create keyfile with restricted permissions
dd if=/dev/urandom of=/root/keys/data.key bs=1 count=64
chmod 0400 /root/keys/data.key
# Add keyfile as an additional unlock method
cryptsetup luksAddKey /dev/sdX2 /root/keys/data.key

You will be prompted for an existing passphrase first.

Key files and automation

Key files are often used to:

• Auto‑unlock secondary data disks once the root is unlocked
• Separate user interaction (single passphrase at boot) from internal keys

For example, put a keyfile on the root filesystem (which itself is protected by a boot passphrase), and use it in /etc/crypttab for other volumes:

cryptdata  UUID=<uuid-of-luks-part>  /root/keys/data.key  luks

Security trade‑off: once the system is up and root is compromised, additional disks protected by those keyfiles can be unlocked.

Using LUKS with LVM

Full‑disk setups commonly combine LUKS with LVM:

• LVM inside LUKS (most common for desktops/laptops)
• Single LUKS → mapped device → LVM PV → VG → LVs for /, swap, /home, etc.
• Pros: one passphrase, easy LV management, filesystem‑level separation
• Cons: LVM metadata is encrypted; you must unlock the device before LVM tools can see volumes

Workflow:

  # After unlock:
  cryptsetup open /dev/sdX2 cryptroot
  # Now activate LVM:
  vgchange -ay
  mount /dev/vg0/root /mnt

• LUKS on top of LVs (less common)
• LUKS directly on each LV
• More complex and rarely useful for general full‑disk encryption

For most cases, prefer one LUKS container per physical disk or partition, LVM inside.

Performance considerations

LUKS adds overhead, but on modern hardware it is usually acceptable.

CPU and AES acceleration

Most CPUs have AES acceleration (AES‑NI on x86_64). Check:

grep aes /proc/cpuinfo

If present, you should see near‑native performance. Without AES‑NI, encryption can still be fine for many workloads but heavy I/O may be slower.

Cipher and key size

Common default:

• AES‑XTS with 512‑bit key (effectively 256‑bit data key + 256‑bit tweak key)

You can reduce to 256‑bit key (AES‑XTS-plain64 with --key-size 256) if you need to squeeze out some performance at the cost of generous but slightly smaller security margin.

Impact is usually small compared to disk speed and other bottlenecks.

I/O patterns

Encryption works at the block layer:

• Sequential reads/writes are fast and cached well
• Random I/O may notice more CPU overhead but usually limited by disk seek time (especially on HDDs)
• On SSDs, very high I/O workloads may see more impact; benchmark if needed

Use tools from the storage chapter (e.g. fio, iostat, blktrace) to measure.

Backup, recovery, and header safety

Backing up data vs backing up headers

Traditional file‑level backups work the same on an encrypted filesystem (after it is unlocked). These do not capture LUKS metadata or headers.

You should also consider:

• Backing up the LUKS header, so that corruption of the on‑disk header doesn’t render the data irretrievable.
• Protecting your passphrases and keyfiles with at least the same care as the data.

Backing up the header

For LUKS1 or LUKS2:

cryptsetup luksHeaderBackup /dev/sdX2 --header-backup-file /root/luksheader-sdX2.bin

Store this backup offline, encrypted or in a physically secure place.

To restore (use only if current header is damaged):

cryptsetup luksHeaderRestore /dev/sdX2 --header-backup-file luksheader-sdX2.bin

Warning: restoring a header overwrites the current header and keyslots. Make sure the backup corresponds to the current master key (i.e., made after your final keyslot setup or you understand the history).

Handling forgotten passphrases

LUKS is designed to be secure against guessing; without:

• At least one working passphrase/keyfile
• Or a valid header backup containing valid keyslots

you cannot recover the data. There is no built‑in backdoor.

Mitigations:

• Use multiple keyslots; store at least one passphrase in a sealed envelope or password manager.
• Use header backups; if the header becomes corrupted (e.g., disk failure at the start of the partition), you can restore it.

Reencrypting and migrating LUKS volumes

Sometimes you need to change encryption parameters (cipher, key size) or fully rotate the master key.

Changing passphrases only (no data reencryption)

When you:

• Add/remove passphrases
• Change PBKDF parameters for keyslots

…the data stays encrypted with the same master key. Only the wrapping of the master key changes.

Example: change PBKDF for a slot (LUKS2):

cryptsetup luksConvertKey --pbkdf argon2id --pbkdf-force-iterations 4 /dev/sdX2

(Consult man cryptsetup for current options; they evolve.)

Reencryption (changing the master key or cipher)

LUKS2 supports in‑place reencryption with cryptsetup-reencrypt. This is advanced and potentially risky; always back up your data first.

Example (conceptual):

cryptsetup-reencrypt --encrypt --type luks2 /dev/sdX2

This can change:

• The master key
• The cipher parameters
• The LUKS version (e.g., LUKS1 → LUKS2 in some workflows)

You should consult your distro’s current documentation before using it; options and behavior can differ by version.

TPM and hardware integration (overview only)

For advanced setups you can integrate LUKS with:

• TPM (Trusted Platform Module) to seal keys to system state
• Network‑based unlocking (e.g., Tang/Clevis)
• Smartcards or HSMs

Conceptually:

• A keyslot is filled with a key that is stored or unwrapped by a TPM or network service.
• The initramfs invokes the integration tool to retrieve/unseal the key at boot instead of asking for a passphrase (or as a fallback).

These setups aim to balance security with unattended boot for servers, but they introduce new trust chains and failure modes (e.g., network required to unlock).

Practical checklists

Designing a new full‑disk LUKS setup

1. Decide on layout:
• Single LUKS + LVM inside for /, swap, /home
• Separate data partitions if needed
2. Choose LUKS2 unless you need LUKS1.
3. Check CPU AES support (grep aes /proc/cpuinfo).
4. Plan passphrase/key strategy:
• Strong interactive passphrase
• Optional backup passphrase
• Optional keyfiles for secondary disks
5. Partition disk (/boot unencrypted or advanced encrypted‑boot chain).
6. Create LUKS container(s) with appropriate cipher/PBKDF.
7. Create LVM or filesystems on top.
8. Configure /etc/crypttab and /etc/fstab; rebuild initramfs.
9. Test boot, encryption unlock, and recovery path.

Ongoing management

• Periodically:
• Verify that cryptsetup luksDump still shows expected keyslots.
• Confirm your header backup is readable and stored securely.
• Consider updating PBKDF parameters as hardware gets faster.
• Before major changes:
• Back up data and LUKS headers.
• If reencryption is needed, test on non‑critical systems first.

With careful design and routine checks, LUKS provides strong, practical full‑disk encryption integrated into advanced Linux storage setups.