Festplattenverschlüsselung mit LUKS: Server-Storage vollständig absichern

1. Warum LUKS und wofür es Schutz bietet

LUKS (Linux Unified Key Setup) ist der Standard für Festplattenverschlüsselung unter Linux und schützt Daten, sobald eine Festplatte physisch abhandenkommt, gestohlen wird oder ausgemustert werden soll, ohne dass sie vorher zuverlässig gelöscht wurde. Ohne Verschlüsselung lässt sich der Inhalt einer Festplatte einfach in einem anderen System einbinden und komplett auslesen, mit LUKS ist derselbe physische Datenträger ohne die passende Passphrase oder das passende Keyfile nur zufälliges Rauschen.

Wichtig für die Einordnung: LUKS schützt vor physischem Zugriff auf ausgeschaltete oder ausgebaute Datenträger, nicht vor Angriffen auf ein laufendes, bereits entsperrtes System. Ist der Server hochgefahren und der LUKS-Container entsperrt, liegen die Daten im Klartext im Arbeitsspeicher und auf dem gemounteten Dateisystem vor, ein Angreifer mit Root-Zugriff auf das laufende System sieht dieselben Daten wie ohne Verschlüsselung. Für Compliance-Anforderungen wie DSGVO oder PCI-DSS ist Festplattenverschlüsselung bei sensiblen Kundendaten trotzdem häufig ein Pflichtbaustein.

2. LUKS, dm-crypt und Header: wie die Verschlüsselung funktioniert

Technisch liefert der Kernel-Baustein dm-crypt die eigentliche Ver- und Entschlüsselung auf Blockebene, LUKS ist die Verwaltungsschicht darüber, die den Umgang mit Schlüsseln standardisiert und dabei mehrere Passphrasen oder Keyfiles gleichzeitig unterstützt. Jeder LUKS-Container beginnt mit einem Header, der die kryptografischen Metadaten enthält: verwendeter Cipher, Schlüsselgröße und bis zu acht (LUKS1) oder deutlich mehr (LUKS2) unabhängige Key-Slots.

Der eigentliche Master-Key, mit dem die Daten verschlüsselt werden, ist selbst nie direkt aus einer Passphrase ableitbar, sondern liegt verschlüsselt in einem der Key-Slots. Jede Passphrase oder jedes Keyfile entschlüsselt lediglich diesen Master-Key, nicht die Daten direkt. Das erlaubt es, eine Passphrase zu ändern oder zu entfernen, ohne die komplette Festplatte neu verschlüsseln zu müssen, nur der betroffene Key-Slot wird neu geschrieben.

3. Einen LUKS-Container anlegen

Das Anlegen eines Containers mit cryptsetup luksFormat überschreibt den Anfang der Partition unwiderruflich mit dem LUKS-Header, alle vorher vorhandenen Daten sind danach nicht mehr zugänglich. Wird eine bereits genutzte Platte wiederverwendet, sollte sie vorher mit shred oder zumindest mit Zufallsdaten überschrieben werden, sonst lassen sich Rückschlüsse auf die Größe geänderter Datenbereiche ziehen, selbst wenn der Inhalt selbst verschlüsselt ist.

# 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 ist seit mehreren Jahren der Standard-Modus (--type luks2) und bringt gegenüber LUKS1 unter anderem Online-Re-Encryption, flexiblere Metadaten und Argon2 als Standard-Schlüsselableitungsfunktion mit, die deutlich resistenter gegen Brute-Force-Angriffe mit spezialisierter Hardware ist als die ältere PBKDF2-Funktion. Für neue Container gibt es praktisch keinen Grund mehr, LUKS1 zu verwenden.

4. Container entsperren, formatieren und einhängen

Nach dem Anlegen ist der Container zunächst nur eine verschlüsselte Hülle ohne Dateisystem. cryptsetup luksOpen fragt die Passphrase ab und legt bei Erfolg ein neues, entschlüsseltes Blockgerät unter /dev/mapper/ an, das sich anschließend wie jedes andere Blockgerät formatieren und mounten lässt.

# 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

Wichtig: Das gemappte Gerät unter /dev/mapper/secure_data existiert nur, solange der Container entsperrt ist. Nach luksClose verschwindet es wieder, und ohne erneutes luksOpen mit der korrekten Passphrase ist auf die Daten nicht mehr zugegriffen werden. Dieses Verhalten ist beabsichtigt und der zentrale Sicherheitsmechanismus von LUKS.

5. Automatisches Entsperren beim Boot mit Keyfile

Ein Server, der bei jedem Neustart auf eine manuell eingegebene Passphrase wartet, ist im Rechenzentrum unpraktisch, insbesondere wenn niemand physisch vor Ort ist. Die gängige Lösung ist ein Keyfile, eine Datei mit zufälligen Binärdaten, die als zusätzlicher Schlüssel zum Container hinzugefügt wird und dann in /etc/crypttab referenziert wird, sodass der Container beim Boot automatisch entsperrt wird.

# 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

Das Keyfile selbst muss sorgfältig geschützt werden, liegt es unverschlüsselt auf dem Root-Dateisystem, verschiebt sich das Sicherheitsproblem lediglich vom Datenträger auf die Zugriffsrechte dieser Datei. Rechte von 400 und root als Eigentümer sind das absolute Minimum, für höhere Sicherheitsanforderungen gehört das Keyfile idealerweise auf ein separates, selbst verschlüsseltes Root-Dateisystem oder in ein TPM-gestütztes Unlock-Verfahren (systemd-cryptenroll --tpm2-device), das den Schlüssel an die Hardware bindet.

6. Passphrasen rotieren und Key-Slots verwalten

Weil jede Passphrase nur den Master-Key entschlüsselt und nicht die Daten selbst, lassen sich Passphrasen jederzeit ändern, ohne die komplette Platte neu zu verschlüsseln. Das ist besonders relevant, wenn ein Mitarbeiter das Unternehmen verlässt, der Zugang zu einer Passphrase hatte, oder wenn der Verdacht besteht, dass eine Passphrase kompromittiert wurde.

# 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

Ein LUKS2-Container bietet standardmäßig bis zu 32 unabhängige Key-Slots, LUKS1 ist auf acht begrenzt. Diese Kapazität eignet sich hervorragend, um verschiedene Zugänge sauber zu trennen, etwa eine Passphrase für den Administrator, ein Keyfile für den automatischen Boot-Vorgang und eine Notfall-Passphrase, die sicher hinterlegt ist. Wichtig: luksRemoveKey verweigert das Entfernen des letzten verbleibenden Slots, ein Container ohne jeden gültigen Schlüssel wäre unwiederbringlich verloren.

7. Header-Backup: die wichtigste Absicherung überhaupt

Der LUKS-Header ist ein Single Point of Failure: Wird er durch einen fehlerhaften Schreibvorgang, einen Fehler in der Partitionstabelle oder versehentliches Überschreiben beschädigt, sind sämtliche verschlüsselten Daten unwiederbringlich verloren, selbst wenn die Passphrase korrekt ist und die eigentlichen Daten auf der Platte vollständig unversehrt sind. Ein Header-Backup ist daher keine Option, sondern Pflicht bei jedem produktiven LUKS-Einsatz.

# 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

Ein Header-Backup gehört niemals auf dieselbe physische Platte wie der verschlüsselte Container, sondern an einen separaten, ebenfalls gesicherten Ort. Wichtig: Das Header-Backup selbst enthält keine Nutzdaten, aber die verschlüsselten Master-Key-Kopien in den Key-Slots, wer Zugriff auf das Backup und eine gültige Passphrase hat, kann den Container vollständig entsperren, das Backup verdient also denselben Schutz wie die Passphrasen selbst.

8. Performance: AES-NI, Cipher-Wahl und Benchmarking

Moderne CPUs bringen mit AES-NI eine dedizierte Hardwarebeschleunigung für AES-Verschlüsselung mit, die den Performance-Overhead von LUKS auf praktisch jedem aktuellen Server-Prozessor auf wenige Prozent reduziert. Ohne AES-NI, etwa auf sehr alter oder stark eingeschränkter Hardware, fällt cryptsetup auf eine reine Software-Implementierung zurück, die spürbar langsamer ist.

Der Standard-Cipher aes-xts-plain64 ist für die allermeisten Anwendungsfälle die richtige Wahl und mittlerweile praktisch überall Standard. LUKS2 unterstützt zudem seit einigen Versionen eine Online-Re-Encryption über cryptsetup reencrypt, mit der sich ein Container im laufenden Betrieb auf einen neuen Cipher oder Schlüssel umstellen lässt, ohne die Daten vorher komplett zu sichern und neu zu schreiben.

9. Verschlüsselungsansätze im direkten Vergleich

LUKS ist nicht die einzige Möglichkeit, Daten unter Linux zu verschlüsseln. Die folgende Übersicht ordnet die Ansätze nach Schutzumfang ein.

Für vollständige Server-Datenträger, insbesondere bei Compliance-Anforderungen, bleibt LUKS auf Blockebene der Standard. Für einzelne Dateien oder Verzeichnisse ohne eigenes Blockgerät gibt es leichtgewichtigere Alternativen, die aber weniger Schutz gegen Metadaten-Analyse bieten als eine vollständige LUKS-Partition.

10. Zusammenfassung

LUKS ist der etablierte Standard für Festplattenverschlüsselung unter Linux und schützt Daten zuverlässig vor physischem Zugriff auf ausgeschaltete oder ausgebaute Datenträger. dm-crypt übernimmt die eigentliche Ver- und Entschlüsselung, LUKS darüber die Verwaltung von Passphrasen und Keyfiles über unabhängige Key-Slots.

Für den produktiven Einsatz sind drei Dinge unverzichtbar: ein Keyfile für automatisiertes Entsperren beim Boot, saubere Schlüsselrotation über mehrere Key-Slots und, am wichtigsten, ein sicher verwahrtes Header-Backup, ohne das ein beschädigter Header zum vollständigen und endgültigen Datenverlust führt.

11. FAQ: Festplattenverschlüsselung mit LUKS