LUKS: Vollständige Festplattenverschlüsselung unter Linux — Komplettanleitung (2026)
LUKS (Linux Unified Key Setup) ist das Standardformat für die Festplattenverschlüsselung unter Linux und baut auf dem Kernelmodul dm-crypt auf. Es ist die Verschlüsselungsschicht, die standardmäßig verwendet wird, wenn man bei der Installation von Fedora, Ubuntu, Debian und den meisten anderen großen Distributionen „Festplatte verschlüsseln” auswählt. Wenn du Linux nutzt und dir Datenschutz wichtig ist, verwendest du mit ziemlicher Sicherheit bereits LUKS — oder du solltest es tun.
Diese Anleitung behandelt LUKS2, die aktuelle Formatversion (eingeführt in cryptsetup 2.0.0, 2018). LUKS1 wird aus Kompatibilitätsgründen weiterhin unterstützt, bietet aber nicht die Argon2id-Schlüsselableitung, die größere Header-Flexibilität und die verbesserte Robustheit von LUKS2. Neuinstallationen sollten immer LUKS2 verwenden.
Wie LUKS funktioniert
LUKS erstellt eine Struktur auf der Festplatte, die aus Folgendem besteht:
- Einem Header mit Metadaten: dem Verschlüsselungsalgorithmus, der Konfiguration der Schlüsselableitungsfunktion (KDF) und bis zu 32 Schlüsselslots. Der Header belegt die ersten paar Megabyte der LUKS-Partition.
- Schlüsselslots: jeder Slot enthält eine unabhängig verschlüsselte Kopie des Hauptschlüssels, verschlüsselt mit einem abgeleiteten Schlüssel aus einer Benutzer-Passphrase (oder einer Schlüsseldatei). Dies erlaubt es, mehrere Passphrasen oder Schlüssel zu verwenden, um dasselbe Volume zu entsperren — nützlich für einen Wiederherstellungsschlüssel neben einer täglichen Passphrase.
- Dem Massendatenbereich: die eigentlichen verschlüsselten Daten, die den Hauptschlüssel über die Blockgeräteschicht
dm-cryptnutzen.
Die entscheidende Folge: der LUKS-Header ist der einzelne Ausfallpunkt für die Datenwiederherstellung. Wenn der Header beschädigt oder überschrieben wird, sind die verschlüsselten Daten unwiederbringlich — unabhängig davon, ob du die Passphrase kennst. Eine Header-Sicherung ist nicht optional.
Erstellen eines LUKS2-Containers
Eine Partition oder ein Blockgerät verschlüsseln
# Eine Partition als LUKS2 mit AES-XTS-512 und Argon2id-KDF formatieren
sudo cryptsetup luksFormat --type luks2 \
--cipher aes-xts-plain64 \
--key-size 512 \
--hash sha256 \
--pbkdf argon2id \
--pbkdf-memory 1048576 \
--pbkdf-time 5000 \
/dev/sdX2
Du wirst zur Eingabe einer Passphrase aufgefordert. Die Option --pbkdf-memory 1048576 reserviert 1 GB Speicher für die Argon2id-Ableitung, was Brute-Force-Angriffe deutlich erschwert. Die Option --pbkdf-time 5000 zielt auf 5 Sekunden Entsperrzeit ab und erhöht die Kosten von Brute-Force-Angriffen weiter. Passe diese Parameter an den Speicher an, den deine Entsperrumgebung (initramfs) bereitstellen kann.
Den Container öffnen (entschlüsseln) und nutzen
# Den LUKS-Container öffnen und ein /dev/mapper/cryptdata-Gerät erstellen
sudo cryptsetup open /dev/sdX2 cryptdata
# Ein Dateisystem erstellen
sudo mkfs.ext4 /dev/mapper/cryptdata
# oder btrfs: sudo mkfs.btrfs /dev/mapper/cryptdata
# Einhängen
sudo mount /dev/mapper/cryptdata /mnt/data
Den Container schließen
sudo umount /mnt/data
sudo cryptsetup close cryptdata
Kritisch: Header-Sicherung und -Wiederherstellung
Die Sicherung des LUKS-Headers ist der wichtigste betriebliche Schritt in dieser Anleitung. Ohne sie bedeutet eine Beschädigung der ersten paar Megabyte deiner verschlüsselten Partition den dauerhaften Datenverlust.
Eine Header-Sicherung erstellen
sudo cryptsetup luksHeaderBackup /dev/sdX2 \
--header-backup-file luks-header-backup-$(date +%Y%m%d).bin
Speichere diese Sicherungsdatei an mindestens zwei Orten: eine Offline-Kopie (USB-Laufwerk an einem physisch getrennten Ort) und eine Cloud-Kopie mit unabhängiger Verschlüsselung. Eine gute Option ist die Speicherung in einem VeraCrypt-Container oder auf Proton Drive — die Sicherung selbst enthält nicht die Daten, aber jeder mit der Sicherung und deiner Passphrase kann auf das Volume zugreifen.
Einen beschädigten Header wiederherstellen
sudo cryptsetup luksHeaderRestore /dev/sdX2 \
--header-backup-file luks-header-backup-20260612.bin
Dies überschreibt den aktuellen Header mit der Sicherung. Wenn die Sicherung aus der Zeit vor dem Hinzufügen eines Schlüsselslots stammt, ist dieser Schlüsselslot nach der Wiederherstellung verschwunden.
Schlüsselslots verwalten
LUKS2 unterstützt bis zu 32 Schlüsselslots pro Header. Nutze dies, um eine starke primäre Passphrase und einen separaten, offline gespeicherten Wiederherstellungsschlüssel zu pflegen.
Einen Schlüsselslot hinzufügen
# Eine neue Passphrase hinzufügen (fragt zuerst nach der bestehenden Passphrase)
sudo cryptsetup luksAddKey /dev/sdX2
# Eine Schlüsseldatei hinzufügen
sudo cryptsetup luksAddKey /dev/sdX2 /path/to/keyfile.bin
Einen Schlüsselslot entfernen
# Per Passphrase entfernen (fragt, welcher entfernt werden soll)
sudo cryptsetup luksRemoveKey /dev/sdX2
# Per Slot-Nummer entfernen (in diesem Beispiel Slot 1)
sudo cryptsetup luksKillSlot /dev/sdX2 1
Aktive Schlüsselslots anzeigen
sudo cryptsetup luksDump /dev/sdX2 | grep -A3 "Keyslot"
TPM-basierte Auto-Entsperrung
Moderne Installationen auf Systemen mit einem TPM2-Chip können eine automatische Entsperrung ohne Passphrase beim Booten konfigurieren und gleichzeitig den Schlüssel gegen das Entfernen der Festplatte schützen. Dies eignet sich für Desktops und Server, bei denen die Eingabe der Passphrase beim Booten betrieblich unpraktisch ist.
Unter Fedora und Ubuntu mit systemd-cryptenroll:
# Das TPM2 für Slot 0 registrieren (erfordert bestehende Passphrase)
sudo systemd-cryptenroll --tpm2-device=auto /dev/sdX2
# Optional an PCR-Werte binden (fügt Measured-Boot-Durchsetzung hinzu)
sudo systemd-cryptenroll --tpm2-device=auto \
--tpm2-pcrs=0+7 \
/dev/sdX2
PCR 0 deckt die Firmware-Messungen ab; PCR 7 deckt den Secure-Boot-Zustand ab. Die Bindung an diese PCRs bedeutet, dass das TPM den Schlüssel nur freigibt, wenn der Firmware- und Secure-Boot-Zustand gegenüber dem Zeitpunkt der Registrierung unverändert sind — ein Schutz gegen einen modifizierten Bootloader.
Einschränkung: Die TPM-Auto-Entsperrung schützt gegen das Entfernen der Festplatte, aber nicht gegen einen Angreifer, der das System normal startet (er müsste die Passphrase für einen separaten Schlüsselslot kennen oder den Bootloader kompromittieren, ohne die PCR-Werte zu ändern). Für einen Laptop mit einem Hochrisiko-Bedrohungsmodell kann ein PIN-geschütztes TPM oder ein reiner Passphrase-Ansatz angemessener sein. Siehe den Leitfaden zur Linux-Härtung für die umfassendere Einordnung des Bedrohungsmodells.
Performance-Benchmarks
Auf einer modernen NVMe-SSD mit einer CPU, die AES-NI-Hardwarebefehle unterstützt (alle x86-64-Prozessoren seit etwa 2010), verursacht AES-XTS-512 über dm-crypt ungefähr 2–8 % Mehraufwand bei sequenziellen Arbeitslasten. Der Mehraufwand bei zufälligen 4K-I/O kann höher sein — bis zu 10–15 % bei manchen Arbeitslasten.
Teste deine spezifische Hardware:
sudo cryptsetup benchmark
Dies führt Zeitmessungen für alle verfügbaren Verschlüsselungskombinationen durch. Auf den meisten modernen Geräten erreicht AES-XTS-512 mit 512-Bit-Schlüssel (256 Bit pro XTS-Schlüssel) einen sequenziellen Durchsatz von 3–8 GB/s — weit über der Leistungsfähigkeit der meisten Speichergeräte.
Praktische Folge: auf einem modernen Laptop mit einem NVMe-Laufwerk wirst du den LUKS-Mehraufwand bei normaler Desktop-Nutzung nicht bemerken. Bei Arbeitslasten, die Hunderte Gigabyte an Daten sequenziell verschieben (große Dateikopien, Videobearbeitung), könntest du ihn bemerken.
LUKS2 vs. VeraCrypt vs. BitLocker
| Funktion | LUKS2 | VeraCrypt | BitLocker |
|---|---|---|---|
| Plattform | Nur Linux | Linux/Win/macOS | Nur Windows |
| Versteckte Volumes | Nein | Ja | Nein |
| TPM-Integration | Ja (systemd-cryptenroll) | Nein | Ja (nativ) |
| Mehrere Schlüsselslots | 32 | 512 | Begrenzt |
| Unabhängiges Audit | Ja | Ja | Teilweise (Microsoft) |
| KDF | Argon2id / PBKDF2 | PBKDF2 / Argon2 | PBKDF2 |
Für einen detaillierten Vergleich von VeraCrypt und LUKS siehe den VeraCrypt-Leitfaden. Für die umfassendere Verschlüsselungslandschaft einschließlich des Ansatzes von Tails zur Festplattenverschlüsselung siehe den Vergleich Qubes vs. Tails vs. Whonix.
FAQ
F: Wenn ich meine LUKS-Passphrase vergesse, sind die Daten unwiederbringlich? A: Ja — das ist beabsichtigt. Wenn kein Schlüsselslot eine gültige Passphrase hat und keine Schlüsseldatei existiert, ist der Hauptschlüssel unzugänglich und die Daten können nicht entschlüsselt werden. Deshalb ist die Pflege eines Wiederherstellungs-Schlüsselslots (mit einer starken, offline gespeicherten zweiten Passphrase) unverzichtbar. Schreibe die Wiederherstellungs-Passphrase auf Papier und bewahre sie an einem physisch sicheren Ort auf.
F: Wie füge ich einer bestehenden unverschlüsselten Partition LUKS-Verschlüsselung ohne Datenverlust hinzu?
A: Das Werkzeug cryptsetup-reencrypt unterstützt die direkte Verschlüsselung bestehender Daten. Es ist seit cryptsetup 2.4.0 stabil, erfordert aber sorgfältige Vorbereitung: eine vollständige Sicherung vor dem Start, eine unterbrechungsfreie Stromversorgung während des Vorgangs und freien Speicherplatz am Ende der Partition für den Header. Teste zuerst mit unkritischen Daten.
F: Schützt die LUKS-Verschlüsselung ein in den Ruhezustand versetztes Linux-System? A: Teilweise. Wenn die Swap-Partition ebenfalls LUKS-verschlüsselt ist (was sie sein muss, separat oder als logisches Volume innerhalb des LUKS-Containers), dann ist das Ruhezustand-Abbild auf der Festplatte verschlüsselt. Allerdings muss der Entschlüsselungsschlüssel beim Fortsetzen geladen werden, was typischerweise die Passphrase erfordert. Wenn dein System automatisch aus einem TPM ohne Passphrase fortsetzt, ist das Ruhezustand-Abbild gegen Offline-Zugriff auf die Festplatte geschützt, aber nicht gegen einen Angriff auf das laufende System. Siehe den Leitfaden zur Linux-Härtung für die Konfiguration der Swap-Verschlüsselung.