Disk Encryption

Disk encryption at rest scrambles the bytes on a block device so a powered-off disk reveals nothing without a key. On Linux the standard is LUKS — the Linux Unified Key Setup — an on-disk header format and key-management scheme layered on dm-crypt, the kernel's device-mapper crypto target. LUKS encrypts a whole disk or a whole partition below the filesystem, so every file, every directory entry, and the free space between them is ciphertext. The userspace tool that drives it is cryptsetup, and it ships identically on Debian, Ubuntu, and the Red Hat family — the kernel does the work, cryptsetup manages the header.

The operational consequence is narrow and worth stating plainly: encryption protects against physical theft of the disk, not against a running compromised host. Once the volume is unlocked and mounted, the master key lives in kernel memory and the data is plaintext to anyone with root. A stolen laptop or a decommissioned drive pulled from a rack is protected; a server someone has logged into as root is not. The cryptography is the easy part — AES-XTS has been solid for years and rides hardware AES-NI on any modern CPU. Key management is where deployments fail: where the key lives, who can produce it at boot, and whether you can still recover the volume after the header is damaged.

Block-Level Encryption

LUKS splits the problem into two layers. dm-crypt is the kernel device-mapper target that does the actual work: it maps an encrypted block device to a cleartext virtual device under /dev/mapper/, encrypting each sector on write and decrypting on read, with no notion of passphrases. LUKS sits on top as a header that stores a randomly generated master key, wrapped (encrypted) by one or more passphrase-derived keys. The master key never changes for the life of the volume; passphrases only unwrap it. Because the encryption sits below the filesystem, it is filesystem-agnostic — ext4, XFS, or Btrfs all live unmodified inside the mapped device.

What LUKS protects and what it does not follows directly from this layering. At rest, the whole device is opaque: filenames, sizes, directory structure, and free space all encrypt together, leaking no metadata. In use, after cryptsetup open, the data is ordinary plaintext to the running kernel and to root. LUKS is an at-rest control, full stop. It does nothing against malware on a booted host, a leaked SSH key, or a memory-scraping attacker — those are problems for other layers.

Setup and Unlocking

Formatting a device with luksFormat writes the LUKS header and a fresh random master key, destroying any existing data on the target. After that, open prompts for a passphrase, unwraps the master key, and creates the cleartext device. You then put a filesystem on the mapped device, never on the raw partition — writing to the raw device would bypass encryption entirely. LUKS2 has been the cryptsetup default since version 2.1 in 2019 and uses the Argon2id key-derivation function, a memory-hard KDF that resists GPU and ASIC brute-forcing far better than the PBKDF2 of the older LUKS1 format.

# Format the partition as a LUKS2 volume (DESTROYS existing data)
cryptsetup luksFormat --type luks2 /dev/sdb1

# Open it: unwraps the master key, creates /dev/mapper/secure
cryptsetup open /dev/sdb1 secure

# Make a filesystem on the MAPPED device, not /dev/sdb1
mkfs.ext4 /dev/mapper/secure
mount /dev/mapper/secure /mnt/data

# Inspect slots, KDF, and cipher
cryptsetup luksDump /dev/sdb1

Closing reverses it: unmount the filesystem, then cryptsetup close secure tears down the mapping and evicts the master key from kernel memory. Persistent unlock at boot is driven by /etc/crypttab, which names each encrypted device and its key source, paired with /etc/fstab, which mounts the resulting /dev/mapper device. On Debian and Ubuntu, systemd reads crypttab and generates the unlock units; RHEL uses the same mechanism.

Key Management

Because passphrases wrap the master key rather than being the key, you can add and remove them without re-encrypting a single byte. A LUKS2 header holds up to 32 independent key slots (LUKS1 held 8), each carrying its own wrapped copy of the master key; any one passphrase or keyfile that fills a slot can unlock the volume. luksAddKey fills a free slot and luksRemoveKey empties one. This is how you rotate credentials, provision a per-host keyfile, and keep a printed recovery passphrase in a slot of its own.

# Add a second passphrase / recovery key into a free slot
cryptsetup luksAddKey /dev/sdb1

# Revoke a compromised passphrase
cryptsetup luksRemoveKey /dev/sdb1

# Back up the header — without this, header damage = total data loss
cryptsetup luksHeaderBackup /dev/sdb1 \
  --header-backup-file /root/secure-header.img

The header is the single point of failure. It holds the only copies of the wrapped master key; if the first sectors of the disk are overwritten or corrupted, the data is gone even when you know every passphrase, because there is nothing left to unwrap. Run luksHeaderBackup after every format and every key change, and store the image off the encrypted volume. Changing a passphrase only re-wraps the master key — it does not re-encrypt the data — so a leaked master key stays valid; to truly replace it, cryptsetup reencrypt rewrites the data online with a new master key.

Unattended Boot

A headless server has a chicken-and-egg problem: it must unlock the root volume before any human can reach it, but the key cannot simply sit in plaintext on the same disk or the encryption is pointless. There are three real answers. Bind the key to the TPM with systemd-cryptenroll --tpm2-device=auto, so the chip releases it only when the boot measurements (PCRs) match a known-good state. Use network-bound disk encryption with Clevis and a Tang server, where the client fetches a decryption shard over the LAN and self-unlocks only on a trusted network. Or install dropbear-initramfs, a minimal SSH server inside the initramfs you connect to at boot to type the passphrase by hand.

Each option trades a different risk. TPM-only unlock means a thief who steals the whole powered-off chassis still boots straight past the encryption, so pair it with a TPM PIN. Clevis/Tang depends on the keyserver being reachable and trusted — useful inside a datacenter, useless for a stolen laptop. The wrong move is the lazy one: a none entry in crypttab that prompts on a console no one watches, or a keyfile on an unencrypted partition beside the encrypted volume, which hands the key to anyone who takes the disk.