2018 bekam ich einen Anruf von einem Kollegen, dessen Laptop über Nacht aus dem Firmenwagen gestohlen worden war. Der Wagen stand in einer Tiefgarage, das Fenster war eingeschlagen, der Rucksack weg. Was mich bis heute beschäftigt: Seine erste Sorge galt nicht dem Gerät, sondern den drei Kundendatenbanken auf der Platte, die kein Backup-Server kannten. Der Laptop hatte keine Verschlüsselung. Der Dieb bekam ein funktionierendes Gerät mit lesbaren Daten, mein Kollege eine sehr unangenehme Woche. Heute hat jeder Rechner, den ich verwalte, eine verschlüsselte Platte. Dieser Artikel zeigt, wie das im Server-Alltag ohne Drama funktioniert.

Die zweite Geschichte endet glimpflicher, war aber lehrreich. Ein Server mit verschlüsseltem Root musste um drei Uhr nachts neu starten, und ich stand vor der KVM-Konsole, während der Kunde geduldig auf seine Datenbank wartete. Unter Zeitdruck tippt man eine Passphrase erstaunlich oft falsch, und beim dritten Versuch wird man langsam blass. Beide Geschichten gehören zu LUKS, denn LUKS ist kein Werkzeug für Paranoia, sondern für den normalen Betrieb. Wer die Mechanik dahinter versteht, für den ist Verschlüsselung ungefähr so aufregend wie ein Backup-Job.

Der übliche Einwand lautet: Ich habe nichts zu verbergen. Für Server stimmt das selten, denn Server enthalten fast immer fremde Daten, Kundendaten, Zugangsdaten, Backups von anderen Maschinen. Und die Erfahrung zeigt: Es ist nicht die Frage, ob eine Platte in falsche Hände gerät, sondern wann. Hoster wechseln, Garantiefälle passieren, und irgendwann verschwindet ein Gerät. Verschlüsselung ist die einzige Maßnahme, die in dem Moment noch wirkt, in dem du die Kontrolle über die Hardware verlierst.

Was unter LUKS steckt: dm-crypt und ein Header mit Metadaten

LUKS steht für Linux Unified Key Setup und ist streng genommen nur ein Dateiformat für Metadaten. Die eigentliche Verschlüsselung übernimmt dm-crypt, ein Kernel-Modul, das seit Kernel 2.6 (2004) fester Bestandteil von Linux ist. Der Name verrät die Architektur: Device Mapper, also eine Schicht, die blockweise zwischen Dateisystem und Platte sitzt. Jeder Block, der die Schicht passiert, wird verschlüsselt oder entschlüsselt. Das Dateisystem darüber merkt davon nichts.

LUKS2 ist seit 2018 die Standardversion und löst LUKS1 ab. Die wichtigsten Neuerungen: Der Header kann Backups enthalten, die Schlüsselableitung nutzt standardmäßig Argon2id statt PBKDF2, und es gibt Platz für zusätzliche Metadaten wie Tokens, zum Beispiel für FIDO2-Schlüssel oder systemd-cryptenroll. Für den Alltag reicht zu wissen: LUKS2 ist der Stand, den aktuelle Debian-, Ubuntu-, Fedora- und openSUSE-Installer standardmäßig setzen.

Der Blick auf die Schichten hilft, Fehler zu vermeiden. Von oben nach unten: Anwendung, Dateisystem, dm-crypt, Platte. Ein SSH-Dienst schreibt Daten ins Dateisystem, das Dateisystem legt Blöcke in dm-crypt ab, dm-crypt verschlüsselt jeden Block mit einem Master-Key und schreibt ihn auf die Platte. Beim Lesen läuft es rückwärts. Der Master-Key ist ein Zufallswert, der beim Formatieren entsteht und im LUKS-Header liegt, verschlüsselt mit einem Schlüssel, der aus deiner Passphrase abgeleitet wird.

Schichtenmodell von LUKS2: Anwendung, Dateisystem, dm-crypt und Platte, daneben der LUKS2-Header mit acht Keyslots, zwei davon belegt

Das Wichtigste an dieser Kette: Die Passphrase schützt nicht die Daten direkt, sondern den Master-Key. Genau das ermöglicht den Passphrase-Wechsel im laufenden Betrieb, ohne die Platte neu zu verschlüsseln.

Der erste Lauf: luksFormat mit Ansage

So sieht ein frisches Setup aus. Ich nehme eine leere Platte /dev/sdb an, zum Beispiel die zweite SSD in einem Server oder die Austauschplatte in einem NAS. Der Befehl heißt cryptsetup luksFormat, und er fragt nach einer Bestätigung, die man nicht überlesen kann:

# cryptsetup luksFormat /dev/sdb1

WARNING!
========
This will overwrite data on /dev/sdb1 irrevocably.

Are you sure? (Type 'yes' in capital letters): YES
Enter passphrase for /dev/sdb1:
Verify passphrase:

Die Wahl der Passphrase entscheidet über die Sicherheit. Acht Zeichen mit Sonderzeichen klingen sicher, bis man rechnet: Bei einer modernen GPU sind das Sekunden bis Minuten. Zwanzig zufällige Zeichen aus dem bitcalc Passwort-Generator liegen jenseits dessen, was sich praktisch erraten lässt, und lassen sich trotzdem gut abtippen, wenn man sie sich ein paarmal eingeprägt hat. Für den Server kommt die Passphrase in den Passwort-Manager, nicht auf einen Zettel.

Nach dem Formatieren ist die Platte ein LUKS-Container. Sichtbar wird das mit luksDump, das den kompletten Header ausgibt:

# cryptsetup luksDump /dev/sdb1
LUKS header information
Version:        2
Epoch:          3
Metadata area:  16384 [bytes]
Keyslots:
  0: luks2
     Key:        512 bits
     Priority:   normal
     Cipher:     aes-xts-plain64
     Cipher key: 512 bits
     PBKDF:      argon2id
  1: luks2
     Key:        512 bits
     Priority:   normal
     Cipher:     aes-xts-plain64
     Cipher key: 512 bits
     PBKDF:      argon2id

Zwei Dinge fallen sofort auf. Erstens: aes-xts-plain64 mit 512-Bit-Schlüssel ist der Standard. XTS ist ein Blockmodus, der die bekannten Schwächen von ECB umgeht, und die 512 Bit teilen sich in zwei 256-Bit-Hälften. Zweitens: Es existieren bereits zwei Keyslots, obwohl ich nur eine Passphrase eingegeben habe. Der Installer hat einen Recovery-Key als zweiten Schlüssel angelegt, eine 32-stellige Zufallszahl, die in der Konsole des Hosters hinterlegt ist. Eine gute Praxis, auf die ich gleich zurückkomme.

Keyslots: acht Schlösser an einer Tür

Der LUKS-Header hat Platz für acht Keyslots. Jeder Keyslot ist ein eigenes Schloss mit eigener Passphrase, und alle schützen denselben Master-Key. Das Modell: eine Tür mit acht Schlössern und nur einem Raum dahinter. Wer irgendeinen der acht Schlüssel hat, öffnet die Tür. Es gibt also nicht acht verschiedene Verschlüsselungen, sondern eine, mit acht Wegen zum Master-Key.

Übrigens: Nicht überall dieselbe Passphrase verwenden. Ein Schlüssel, der für alles passt, öffnet auch alles. Wer die Passphrase des Backup-Servers kennt, hat damit noch nicht den Zugriff auf die Hauptdatenbank, wenn beide unterschiedliche Schlüssel haben. Die Keyslots sind genau dafür da: verschiedene Personen, verschiedene Schlüssel auf derselben Platte.

In meinem Setup sind zwei von acht belegt: Keyslot 0 mit meiner Passphrase, Keyslot 1 mit dem Recovery-Key. Den Recovery-Key erzeuge ich mit dem bitcalc Passwort-Generator: 32 Zeichen, Groß- und Kleinbuchstaben, Ziffern, Sonderzeichen. Er ist die Rettung, wenn die Passphrase verloren geht oder ein Mitarbeiter geht, ohne den Schlüssel zu übergeben. Sechs Slots bleiben frei für spätere Zwecke: eine zweite Passphrase für den Kollegen, ein Keyfile für das automatische Entsperren beim Boot, ein FIDO2-Token.

Einen neuen Schlüssel legt luksAddKey an. Das Kommando fragt zuerst nach einem vorhandenen Schlüssel und dann nach dem neuen:

# cryptsetup luksAddKey /dev/sdb1
Enter any existing passphrase:
Enter new passphrase for key slot:
Verify passphrase:

Der neue Schlüssel landet im ersten freien Keyslot, hier also in Slot 2. Wichtig: luksAddKey verändert keine Daten auf der Platte, es schreibt nur einen Eintrag in den Header. Deshalb dauert der Vorgang Sekunden statt Stunden und lässt sich gefahrlos auf einem laufenden Server ausführen.

Passphrase-Wechsel auf einem laufenden Server

Der Klassiker im Admin-Alltag: Ein Mitarbeiter verlässt das Team, die Passphrase muss weg. Oder die Richtlinie verlangt vierteljährlich einen Wechsel. Bei LUKS ist das ein Zwei-Befehle-Job, komplett auf einem laufenden System. Die Platte bleibt gemountet, keine Dienste stoppen, kein Reboot nötig.

Der erste Befehl heißt luksChangeKey. Er nimmt den aktuellen Schlüssel des angegebenen Keyslots und ersetzt ihn durch einen neuen:

# cryptsetup luksChangeKey /dev/sdb1
Enter LUKS passphrase to be changed:
Enter new passphrase:
Verify passphrase:

Standardmäßig trifft der Wechsel den ersten passenden Keyslot. Wer einen bestimmten treffen will, hängt --key-slot 2 an. Nach dem Wechsel prüfe ich immer, ob der neue Schlüssel wirklich funktioniert. Dafür gibt es einen Testmodus, der nur die Passphrase gegen den Header prüft, ohne zu entschlüsseln:

# cryptsetup luksOpen --test-passphrase /dev/sdb1
Enter passphrase for /dev/sdb1:

Keine Ausgabe, Exit-Code 0, fertig. Diese eine Zeile spart Nerven, denn ein vertippter neuer Schlüssel fällt sonst erst beim nächsten Reboot auf, und dann steht man vor einer verschlossenen Platte ohne funktionierenden Schlüssel.

LUKS2 kennt übrigens Keyslot-Prioritäten. Per Default steht jeder Slot auf normal, einzelne Slots lassen sich mit --priority high auszeichnen, etwa den Recovery-Key, damit systemd-cryptsetup ihn beim Boot bevorzugt. Wer mehrere Keyslots verwaltet, sollte sich die Prioritäten einmal ansehen, sonst entscheidet der Zufall, welcher Slot beim Entsperren zuerst probiert wird. Für die meisten Setups ist der Default aber völlig in Ordnung.

Der zweite Befehl ist luksKillSlot, die radikale Variante. Er löscht einen Keyslot, ohne dass man dessen Passphrase kennen muss. Man braucht nur irgendeinen anderen gültigen Schlüssel:

# cryptsetup luksKillSlot /dev/sdb1 2
Enter passphrase for /dev/sdb1:

Damit ist Slot 2 Geschichte. Ich nutze das, wenn ich einen Schlüssel entfernen will, dessen Passphrase niemand mehr kennt: Der ausscheidende Mitarbeiter hat sein Passwort nicht verraten, aber ich habe meinen eigenen. Ein Kill, und der Zugang ist weg. Die Reihenfolge ist entscheidend: erst den neuen Schlüssel anlegen, dann den alten löschen. Wer den letzten funktionierenden Slot löscht, verliert die Platte endgültig.

Noch eine Warnung zum Thema Wechsel: luksChangeKey tauscht nur den Schlüssel, der den Master-Key schützt. Der Master-Key selbst bleibt derselbe, und damit liegen alle Daten unverändert auf der Platte. Wer einen kompromittierten Master-Key vermutet, dem hilft kein Schlüsselwechsel, sondern nur ein neues luksFormat mit Daten-Transfer. Das ist der Preis für den bequemen Wechsel ohne Neuverschlüsselung.

Header-Backup: die Versicherung gegen das Vergessen

Der LUKS-Header ist die empfindlichste Datei auf dem System, denn ohne ihn ist die Platte nicht lesbar, selbst mit korrekter Passphrase. Ein defekter Sektor im Header-Bereich kann reichen, um den Zugang zu verlieren. Deshalb gehört ein Header-Backup zu jedem Setup, das länger als einen Tag lebt:

# cryptsetup luksHeaderBackup /dev/sdb1 --header-backup-file \
    /root/backup/luks-header-$(date +%F).bin

Die Datei ist ein paar Megabyte groß und wandert mit den normalen Backups ins Archiv. Wichtig: Das Header-Backup enthält die verschlüsselten Master-Keys, aber keine Passphrasen. Es ist also kein Sicherheitsrisiko, wenn es in einem unverschlüsselten Backup-Archiv liegt. Im Ernstfall stellt man den Header so wieder her:

# cryptsetup luksHeaderRestore /dev/sdb1 --header-backup-file \
    /root/backup/luks-header-2026-10-01.bin

Der Restore überschreibt den aktuellen Header, danach gelten wieder alle Keyslots des Backups, auch Passphrasen, die zwischenzeitlich gelöscht wurden. Das klingt nach einem Feature, ist aber auch eine Falle: Ein altes Backup kann einen Keyslot wiederbeleben, den man bewusst gekillt hat. Wer ein Backup einspielt, sollte wissen, welchen Stand es abbildet. Die Prüfsumme der Datei verifiziere ich übrigens mit dem bitcalc Hash-Generator, SHA-256, bevor sie ins Archiv wandert.

Was LUKS wirklich schützt: die ehrliche Bilanz

Jetzt der Teil, den Verkaufsfolien gern weglassen. Plattenverschlüsselung schützt Daten im Ruhezustand, und sonst nichts. Konkret heißt das: Sie schützt vor allem, was mit der Platte selbst passiert.

Die echten Szenarien: Ein Server wird dem Hoster zurückgegeben, weil der Vertrag ausläuft. Eine defekte Platte geht im Rahmen der Garantie an den Hersteller. Ein Laptop wird gestohlen, wie bei meinem Kollegen. Ein Backup-Laufwerk wandert in den Müll oder auf eBay. In allen Fällen ist die Platte in fremden Händen, und in allen Fällen macht LUKS aus den Daten ein wertloses Rauschen. Ohne Passphrase und ohne Header führt kein Weg an die Daten, und eine 32-stellige Zufallspassphrase aus dem Passwort-Generator lässt sich nicht erraten.

Die ehrliche Kehrseite: LUKS schützt nicht vor einem kompromittierten System. Wer Root-Rechte auf einem laufenden Server hat, liest die Daten, während sie entschlüsselt sind. Der Grund ist simpel: Sobald die Platte entsperrt ist, liegt der Master-Key im Kernel-Speicher, und die Daten sind im Klartext verfügbar. Ein Angreifer mit Root-Rechten muss den Schlüssel nicht einmal suchen, er kopiert die Daten einfach mit. Verschlüsselung ist also keine Firewall. Sie ist ein Schutz für den Moment, in dem die Platte den Besitzer wechselt.

Was kostet das Ganze an Leistung? Auf modernen x86-CPUs fast nichts, denn AES-NI erledigt die Verschlüsselung in der Hardware. Bei meinen Servern messe ich mit LUKS einen Overhead von unter fünf Prozent, bei großen Blöcken oft gar keinen messbaren. Auf ARM-Boards ohne AES-NI, etwa einem Raspberry Pi 3, sieht es anders aus: Da schlägt dm-crypt mit zwanzig bis dreißig Prozent zu Buche, je nach Dateisystem und Blockgröße. Für ein Homelab ist das vertretbar, für eine datenbanklastige Kiste mit schwacher CPU sollte man es einplanen.

Die zweite Grenze: Alles, was vor dem Entsperren läuft, ist ungeschützt. Der Bootloader liegt außerhalb des verschlüsselten Bereichs, solange man nicht mit Secure Boot und signierten Kerneln arbeitet. Ein Angreifer mit physischem Zugriff kann außerdem den RAM auslesen, der klassische Cold-Boot-Angriff, oder ein Tastatur-Gerät zwischen Server und Konsole hängen. Diese Angriffe sind selten und aufwendig, aber wer sein Bedrohungsmodell ernst nimmt, sollte sie kennen.

Daraus folgt eine Faustregel, mit der ich jede Beratung beende: LUKS löst genau ein Problem, Daten im Ruhezustand. Alles andere ist Aufgabe von Updates, Firewalls, SSH-Keys und Backups. Wer diese Grenze kennt, setzt Verschlüsselung dort ein, wo sie wirkt, und spart sich den Rest des Dramas.

Drei Regeln für entspannten LUKS-Betrieb

Aus fünf Jahren LUKS-Betrieb auf Servern, NAS und Laptops sind bei mir drei Regeln übrig geblieben:

  • Zwei Keyslots, immer: Slot 0 für die tägliche Passphrase, Slot 1 für den Recovery-Key. Der Recovery-Key liegt beim Hoster oder im Passwort-Manager, nie neben dem Server. Erzeugt wird er mit dem Passwort-Generator, 32 Zeichen lang.
  • Header sichern, nach jeder Änderung: Nach luksFormat, luksAddKey, luksChangeKey oder luksKillSlot ein frisches luksHeaderBackup. Fünf Sekunden Aufwand, erspart den Totalverlust.
  • Testen, bevor man geht: Nach jedem Schlüsselwechsel luksOpen --test-passphrase laufen lassen. Exit-Code 0 bedeutet: Der Schlüssel funktioniert, der Server kann neu starten.

Fazit

LUKS ist ein Dateiformat mit einem Kernel-Modul dahinter, mehr nicht. Wer die vier Schichten kennt, versteht auch die Grenzen: Verschlüsselung schützt ruhende Daten, nicht laufende Systeme. Die Werkzeuge sind überschaubar: luksFormat zum Anlegen, luksAddKey und luksChangeKey für Schlüssel, luksKillSlot zum Entfernen, luksHeaderBackup als Versicherung. Der Passphrase-Wechsel auf einem laufenden Server ist Routine, wenn man die Reihenfolge einhält: neuen Schlüssel anlegen, testen, alten löschen.

Mein Kollege mit dem gestohlenen Laptop hat seine Daten damals zurückbekommen, weil der Dieb die Platte nicht brauchte und der Rucksack auf einem Parkplatz wieder auftauchte. Das war Glück, kein Konzept. Seitdem gilt in meinen Setups: Jede Platte, die den Rechner verlassen könnte, ist verschlüsselt, bevor sie eingebaut wird. Die Passphrase liegt im Passwort-Manager, der Recovery-Key beim Hoster. Das kostet fünf Minuten pro System und spart genau eine Krise pro Platte.