Disk Encryption with LUKS: Fully Securing Server Storage

1. Why LUKS and what it protects against

LUKS (Linux Unified Key Setup) is the standard for disk encryption on Linux and protects data whenever a disk is physically lost, stolen, or decommissioned without having been reliably wiped beforehand. Without encryption, the contents of a disk can simply be mounted in a different system and read out completely, with LUKS the same physical storage medium is just random noise without the right passphrase or keyfile.

Important for context: LUKS protects against physical access to powered off or removed storage media, not against attacks on a running, already unlocked system. If the server is up and the LUKS container unlocked, the data sits in plaintext in memory and on the mounted filesystem, an attacker with root access on the running system sees the same data as without encryption. For compliance requirements like GDPR or PCI-DSS, disk encryption is nonetheless often a mandatory building block for sensitive customer data.

2. LUKS, dm-crypt and the header: how encryption works

Technically, the kernel building block dm-crypt provides the actual encryption and decryption at the block level, LUKS is the management layer on top that standardizes key handling and supports multiple passphrases or keyfiles at the same time. Every LUKS container starts with a header that contains the cryptographic metadata: the cipher in use, key size, and up to eight (LUKS1) or considerably more (LUKS2) independent key slots.

The actual master key used to encrypt the data is itself never directly derivable from a passphrase, instead it sits encrypted in one of the key slots. Every passphrase or keyfile only decrypts this master key, not the data directly. This allows a passphrase to be changed or removed without having to re-encrypt the entire disk, only the affected key slot gets rewritten.

3. Creating a LUKS container

Creating a container with cryptsetup luksFormat irreversibly overwrites the beginning of the partition with the LUKS header, any data present before is no longer accessible afterward. If a previously used disk is being reused, it should first be overwritten with shred or at least random data, otherwise conclusions can be drawn about the size of changed data regions, even though the content itself is encrypted.

# Wipe existing data first (recommended on reused disks)
sudo shred -n 1 -v /dev/sdb1

# Initialize the partition as a LUKS2 container (AES-XTS by default)
sudo cryptsetup luksFormat --type luks2 /dev/sdb1

# Inspect the resulting header: cipher, key size, key slots
sudo cryptsetup luksDump /dev/sdb1

LUKS2 has been the standard mode (--type luks2) for several years now and brings, among other things, online re-encryption, more flexible metadata, and Argon2 as the default key derivation function, which is considerably more resistant to brute force attacks with specialized hardware than the older PBKDF2 function. For new containers there is practically no reason left to use LUKS1.

4. Unlocking, formatting and mounting the container

After creation, the container is initially just an encrypted shell without a filesystem. cryptsetup luksOpen asks for the passphrase and, on success, creates a new, decrypted block device under /dev/mapper/, which can then be formatted and mounted like any other block device.

# Unlock the container and expose it as a mapped device
sudo cryptsetup luksOpen /dev/sdb1 secure_data
# Device is now available at /dev/mapper/secure_data

# Create a filesystem inside the decrypted mapping
sudo mkfs.ext4 /dev/mapper/secure_data

# Mount it like any other block device
sudo mkdir -p /mnt/secure
sudo mount /dev/mapper/secure_data /mnt/secure

# Unmount and lock the container again
sudo umount /mnt/secure
sudo cryptsetup luksClose secure_data

Important: the mapped device at /dev/mapper/secure_data only exists while the container is unlocked. After luksClose it disappears again, and without a new luksOpen with the correct passphrase the data can no longer be accessed. This behavior is intentional and is the central security mechanism of LUKS.

5. Automatic unlocking at boot with a keyfile

A server that waits for a manually entered passphrase on every reboot is impractical in a data center, especially when nobody is physically on site. The common solution is a keyfile, a file with random binary data that is added to the container as an additional key and then referenced in /etc/crypttab, so the container is unlocked automatically at boot.

# Generate a random 4 KiB keyfile for unattended unlocking
sudo dd if=/dev/urandom of=/etc/luks/data.key bs=1024 count=4
sudo chmod 400 /etc/luks/data.key

# Register the keyfile as an additional key slot (up to 8 slots total)
sudo cryptsetup luksAddKey /dev/sdb1 /etc/luks/data.key

# /etc/crypttab entry: unlock automatically at boot using the keyfile
secure_data  UUID=6c3f9e21-0a4b-4f7e-9c31-2d8e5f0a1b23  /etc/luks/data.key  luks

# /etc/fstab entry for the resulting mapped device
/dev/mapper/secure_data  /mnt/secure  ext4  defaults,noatime  0  2

The keyfile itself must be carefully protected, if it sits unencrypted on the root filesystem, the security problem simply moves from the storage medium to the access rights of this file. Permissions of 400 with root as the owner are the absolute minimum, for higher security requirements the keyfile ideally belongs on a separate, itself encrypted root filesystem, or in a TPM backed unlock scheme (systemd-cryptenroll --tpm2-device) that binds the key to the hardware.

6. Rotating passphrases and managing key slots

Because every passphrase only decrypts the master key and not the data itself, passphrases can be changed at any time without re-encrypting the entire disk. This is especially relevant when an employee who had access to a passphrase leaves the company, or when there is suspicion that a passphrase has been compromised.

# List all currently occupied key slots
sudo cryptsetup luksDump /dev/sdb1 | grep -A1 "Keyslot"

# Add a new passphrase in an unused slot before removing the old one
sudo cryptsetup luksAddKey /dev/sdb1

# Remove a specific, now-retired passphrase (never the last remaining slot)
sudo cryptsetup luksRemoveKey /dev/sdb1

# Full header backup, store this offline, away from the encrypted disk
sudo cryptsetup luksHeaderBackup /dev/sdb1 --header-backup-file /root/luks-header.img

A LUKS2 container supports up to 32 independent key slots by default, LUKS1 is limited to eight. This capacity is excellent for cleanly separating different access paths, for example a passphrase for the administrator, a keyfile for the automatic boot process, and an emergency passphrase kept in a secure location. Important: luksRemoveKey refuses to remove the last remaining slot, a container without any valid key would be irrecoverably lost.

7. Header backup: the single most important safeguard

The LUKS header is a single point of failure: if it is damaged by a faulty write, an error in the partition table, or accidental overwriting, all encrypted data is irrecoverably lost, even if the passphrase is correct and the actual data on disk is completely intact. A header backup is therefore not optional but mandatory for any production LUKS deployment.

# Benchmark available ciphers on this CPU (AES-NI vs. software fallback)
sudo cryptsetup benchmark

# Check whether AES-NI hardware acceleration is active
grep -o aes /proc/cpuinfo | head -1

# Re-encrypt an existing LUKS2 container in place (online, LUKS2 only)
sudo cryptsetup reencrypt /dev/sdb1

A header backup should never sit on the same physical disk as the encrypted container, but in a separate, equally secured location. Important: the header backup itself contains no user data, but the encrypted master key copies from the key slots, anyone with access to the backup and a valid passphrase can fully unlock the container, so the backup deserves the same protection as the passphrases themselves.

8. Performance: AES-NI, cipher choice and benchmarking

Modern CPUs come with AES-NI, dedicated hardware acceleration for AES encryption, which reduces the performance overhead of LUKS to a few percent on practically any current server processor. Without AES-NI, for example on very old or heavily constrained hardware, cryptsetup falls back to a pure software implementation, which is noticeably slower.

The default cipher aes-xts-plain64 is the right choice for the vast majority of use cases and is by now practically standard everywhere. LUKS2 has also supported online re-encryption via cryptsetup reencrypt for several versions, which lets a container switch to a new cipher or key while running, without having to fully back up and rewrite the data beforehand.

9. Encryption approaches in direct comparison

LUKS is not the only way to encrypt data on Linux. The following overview classifies the approaches by scope of protection.

For complete server storage devices, especially with compliance requirements, LUKS at the block level remains the standard. For individual files or directories without a dedicated block device, lighter weight alternatives exist, but they offer less protection against metadata analysis than a full LUKS partition.

10. Summary

LUKS is the established standard for disk encryption on Linux and reliably protects data against physical access to powered off or removed storage media. dm-crypt handles the actual encryption and decryption, LUKS on top manages passphrases and keyfiles through independent key slots.

For production use, three things are indispensable: a keyfile for automated unlocking at boot, clean key rotation across multiple key slots, and, most importantly, a securely stored header backup, without which a damaged header leads to complete and permanent data loss.

11. FAQ: Disk Encryption with LUKS