Linux Unified Key Setup
Standardverfahren für Festplattenverschlüsselung unter Linux, das mit AES und einem Header mit mehreren Key-Slots Pre-Boot-Authentifizierung, TPM-Bindung und unterschiedliche Passphrasen pro Nutzer ermöglicht.
Linux Unified Key Setup (LUKS) ist der De-facto-Standard für die Festplattenverschlüsselung auf Linux-Systemen. Entwickelt von Clemens Fruhwirth, ist LUKS heute Bestandteil praktisch jeder Mainstream-Distribution — von Ubuntu und Debian über Fedora bis zu Enterprise-Linuxen wie RHEL und SLES. Im Kern definiert LUKS ein Header-Format, das auf einem mit dm-crypt verschlüsselten Blockgerät liegt und alle Metadaten zur Schlüsselverwaltung enthält. Anders als das nackte dm-crypt, das nur ver- und entschlüsselt, bringt LUKS eine standardisierte Schlüsselableitung, mehrere Key-Slots und ein dokumentiertes On-Disk-Format mit — Voraussetzungen für robusten Enterprise-Einsatz.
Architektur und Key-Slots
Ein LUKS-Container speichert seinen Header an den Anfang des Blockgeräts und enthält bis zu acht (LUKS1) bzw. 32 (LUKS2) Key-Slots. Jeder Slot kann eine eigene Passphrase oder einen eigenen Schlüssel halten, der wiederum den Master-Key entsiegelt. Erst der Master-Key entschlüsselt die eigentlichen Daten. Diese Indirektion erlaubt es, Passphrasen zu rotieren, mehrere Benutzer mit unterschiedlichen Zugängen einzurichten oder eine TPM-Bindung parallel zu einer Recovery-Passphrase zu führen — ohne das gesamte Volume neu verschlüsseln zu müssen.
Als Verschlüsselungsalgorithmus ist heute AES-XTS mit 256 oder 512 Bit Schlüssel Standard. Die Schlüsselableitung aus Passphrasen erfolgt bei LUKS2 standardmäßig über Argon2id — ein speicherintensives Verfahren, das Brute-Force-Angriffe per GPU erheblich erschwert. LUKS1-Container nutzen noch PBKDF2; eine Migration auf LUKS2 ist mit cryptsetup convert möglich und für aktuelle Systeme empfehlenswert.
Pre-Boot-Authentifizierung im Standard
Anders als bei BitLocker ist Pre-Boot-Authentifizierung bei LUKS die Standardkonfiguration: Beim Systemstart fragt der Initramfs-Prompt nach der Passphrase, bevor das Wurzeldateisystem eingebunden wird. Ein „TPM-only"-Pendant ohne Nutzerinteraktion ist möglich, aber nicht voreingestellt. Damit ist die Klasse von Downgrade-Angriffen, die im Windows-Umfeld aktuell BitLocker plagt, bei einer Standard-LUKS-Installation strukturell schwerer ausnutzbar.
Moderne Distributionen unterstützen zusätzlich die Bindung an das TPM über das Systemd-Tool systemd-cryptenroll oder das ältere clevis. Damit lässt sich ein zusätzlicher Key-Slot anlegen, der nur freigegeben wird, wenn der Secure-Boot-Status und definierte PCR-Werte unverändert sind. Sinnvoll ist das aber nur in Kombination mit einer zusätzlichen Passphrase oder PIN — sonst entsteht dieselbe „transparente" Konfiguration, die im Windows-Umfeld die aktuellen Angriffe ermöglicht hat.
Zusammenspiel mit Secure Boot und Dual-Boot
LUKS arbeitet unabhängig von Secure Boot — die Verschlüsselung selbst kennt das UEFI nicht. Allerdings setzt eine vertrauenswürdige Boot-Kette eines Linux-Systems den signierten Shim-Loader voraus, der wiederum gegen das in UEFI hinterlegte Microsoft-UEFI-CA-Zertifikat geprüft wird. Bei Dual-Boot-Konfigurationen mit Windows ist deshalb darauf zu achten, dass DBX-Updates oder die laufende UEFI-CA-2023-Migration die signierten Linux-Bootloader nicht versehentlich aussperren. Distributionen liefern aktualisierte Shim-Versionen über ihre regulären Update-Kanäle aus — eine Linux-seitige Aktualisierung sollte vor jeder größeren Windows-Migration in Dual-Boot-Umgebungen eingeplant werden.
Praktische Schwächen
LUKS ist robust, aber kein Selbstläufer. Wir finden in Assessments regelmäßig Konstellationen, die die Schutzwirkung schmälern: schwache Passphrasen, weil keine Komplexitätsregel im Setup erzwungen wird; alte LUKS1-Container mit PBKDF2 statt Argon2id; Backup-Strategien, die unverschlüsselte Kopien der Daten enthalten; und Server-Setups, bei denen das Wurzel-Volume zwar verschlüsselt ist, die Boot- oder /var-Partition aber im Klartext liegt und Logs, SSH-Hostkeys oder Konfigurationsmaterial preisgibt.
Für Server-Szenarien ohne Konsolentastatur kommt häufig dropbear-initramfs oder tang (Network-Bound Disk Encryption) zum Einsatz: Der LUKS-Schlüssel wird beim Boot über SSH oder über einen Netzwerkdienst freigegeben, sodass kein Mensch in den Maschinenraum muss. Das ist eine elegante Lösung, verlagert aber das Vertrauensproblem in das Netzwerk — eine sorgfältige Absicherung des Tang-Servers und der Netzwerkpfade ist obligatorisch.
Relevanz für KMUs
In gemischten Umgebungen — Windows-Clients, Linux-Server, einzelne Linux-Workstations für Entwicklung oder Wartung — ist LUKS das Pendant zu BitLocker und gehört in dieselbe Härtungsstrategie. Für Linux-Workstations ist die Standardkonfiguration bereits weitgehend sicher, sofern eine starke Passphrase gewählt wurde. Für Linux-Server bringt LUKS in physischen Rechenzentren echten Mehrwert beim Diebstahl- oder Außerbetriebnahme-Szenario, weniger gegen Online-Angriffe — hier sind weiterhin Härtung, Patch-Management und Zugriffskontrolle die entscheidenden Hebel. Bei Geräten mit Dual-Boot lohnt ein bewusster Blick auf die UEFI-Konfiguration, damit die Windows- und Linux-Seite nicht in Konflikt geraten, wenn Zertifikate ablaufen oder DBX-Updates eingespielt werden.