Security

LUKS Full-Disk Encryption

·2 min read

LUKS is the Linux disk-encryption standard. The drive is encrypted with a master key; up to eight "key slots" hold copies of that key, each wrapped with a different passphrase or keyfile. Lose the laptop on a train and the data is unreadable. The setup is straightforward; the recovery story is what trips people up.

The threat model, honestly

Full-disk encryption protects against theft of a powered-off device. It does not protect against: a running machine with the disk unlocked (the keys are in RAM), an attacker with physical access willing to wait for you to log in, or compromise via software once you're booted. Know what you're buying.

Encrypting a new disk

# Make sure you're targeting the right device. This is destructive.
cryptsetup luksFormat /dev/sdX

# Open it (decrypts in-memory)
cryptsetup luksOpen /dev/sdX vault

# Now /dev/mapper/vault is a regular block device — format and mount
mkfs.ext4 /dev/mapper/vault
mount /dev/mapper/vault /mnt/vault

# Done. To detach:
umount /mnt/vault
cryptsetup luksClose vault

Key slots

LUKS supports up to eight slots. The first one holds your passphrase. Add a second for an emergency recovery key, or a keyfile for unattended boot:

cryptsetup luksAddKey /dev/sdX                       # adds another passphrase
cryptsetup luksAddKey /dev/sdX /etc/cryptkeys/backup.key  # adds a keyfile
cryptsetup luksDump /dev/sdX                          # see used slots
cryptsetup luksRemoveKey /dev/sdX --key-slot 1

Auto-unlock at boot

On servers, you don't want a passphrase prompt blocking boot. Three options:

  • Keyfile on an unencrypted partition on the same machine. Trivial — but the keyfile defeats the encryption against device-level theft. Useful only when the threat is e.g. RMA-ing a failed disk.
  • Remote unlock via dropbear-initramfs: SSH into the initramfs at boot, type the passphrase. Strong protection at the cost of some operational complexity.
  • TPM-backed unlock via systemd-cryptenroll --tpm2-device=auto: the TPM unseals the key only if the boot chain hasn't been tampered with. Modern, secure, sensitive to BIOS updates.

/etc/crypttab and /etc/fstab

# /etc/crypttab
#                
vault     /dev/sdX     none              luks,discard
# 'discard' enables TRIM passthrough on SSDs

# /etc/fstab
/dev/mapper/vault  /srv/data  ext4  defaults  0 2

Resize / move

# Grow the underlying partition first (parted, fdisk)
cryptsetup resize vault                  # resize the LUKS mapping
resize2fs /dev/mapper/vault              # then the filesystem

Backup the header

If the first ~16 MB of the disk gets damaged, you lose the LUKS header — and with it, every key slot. The data is now unrecoverable. Back up the header.

cryptsetup luksHeaderBackup /dev/sdX --header-backup-file vault-header.bin
# Store this offline. Treat it like the keys themselves —
# anyone with the header + your passphrase can decrypt the disk.

Performance

Modern CPUs do AES-NI in hardware; LUKS overhead is typically a few percent for sequential I/O and small for random. On older or low-end CPUs without AES instructions, the cost can be 20-40%. cryptsetup benchmark tells you what your CPU can do.

Related