Wann und wie man LUKS-Header aktualisieren sollte

Datenträger verschlüsselt man unter Linux üblicherweise mithilfe von LUKS, dem Linux Unified Key Setup. Obwohl LUKS schon 2004 entstand und obwohl sich zwischenzeitlich sowohl Angriffe als auch der Stand der Technik deutlich weiterentwickelt haben, blieb es durch eine Reihe von Verbesserungen und Änderungen der Standardeinstellungen sicherheitstechnisch auf der Höhe der Zeit. Davon profitieren allerdings nur neue LUKS-Container ohne Weiteres. Die Parameter vorhandener Container werden nicht automatisch angepasst, weshalb alte Container aus heutiger Sicht oft nicht optimal eingestellt sind.

Relevante Verbesserungen gab es in letzter Zeit bei Schlüsselableitungsfunktionen (key-derivation function, KDF). Wie der Name nahelegt, dienen diese Funktionen dazu, aus einem Passwort den eigentlichen Schlüssel zu generieren. Das tun sie möglichst rechen- und speicherintensiv, um Brute-Force- und Wörterbuch-Angriffe zu erschweren: Massenhaft Passwörter auszuprobieren, wird unerträglich langwierig, wenn jede Schlüsselableitung ein, zwei Sekunden dauert. Nutzer, die in der Regel nur ein – korrektes – Passwort eingeben, stört die kurze Wartezeit hingegen kaum.

Ältere LUKS-Container nutzen die Schlüsselableitungsfunktion PBKDF2 (password-based key derivation function 2). Wie bei anderen KDFs kann man einstellen, wie viel Rechenaufwand die Funktion erfordert, indem man festlegt, wie viele Iterationen die Funktion intern durchlaufen muss. Allerdings benötigt PBKDF2 nur wenig RAM, weshalb potenzielle Angreifer ihre Berechnungen gut mit Grafikchips oder spezialisierter Hardware beschleunigen können, was den Nutzen der Ableitungsfunktion verringert.

Ein zweites Problem ist, dass LUKS den Rechenaufwand beim Anlegen eines Containers nach der aktuell genutzten Hardware bemisst, damit die Entschlüsselung nicht zu lange dauert. Nachträglich angepasst wird der Wert nicht mehr. Wer also Container nutzt, die einst auf alter oder recht schwacher Hardware angelegt wurden, dessen LUKS-Verschlüsselung bietet heute nur bedingt Schutz vor Brute-Force-Angriffen mit moderner Hardware.

Beide Probleme beseitigt eine Aktualisierung des LUKS-Headers, sodass der Rechenaufwand zu aktuellen Sicherheitseinstellungen sowie der aktuell genutzten Hardware passt und eine bessere KDF zum Einsatz kommt. Mittlerweile nutzt LUKS nicht mehr PBKDF2 als Standard, sondern „argon2id“, eine KDF, die auch das Bundesamt für Sicherheit in der Informationstechnik (BSI) empfiehlt. Argon2id erlaubt, sowohl den Rechenaufwand als auch den nötigen Speicherbedarf einzustellen, und schützt damit auch vor Angreifern mit sehr leistungsfähiger Hardware.

Upgrade nötig?

Mit dem LUKS-Verwaltungstool cryptsetup finden Sie heraus, welche KDF Ihre LUKS-Container einsetzen:

sudo cryptsetup luksDump /dev/DEVICE

Statt /dev/DEVICE müssen Sie das Speichergerät mit dem Container angeben, zum Beispiel „/dev/sda1“. Im Zweifelsfalle hilft der Befehl lsblk --fs bei der Gerätesuche, er bezeichnet LUKS-Container in der Spalte „FSTYPE“ mit „crypto_LUKS​“.

Relevant in der luksDump-Ausgabe ist zunächst die „Version“-Information ganz oben. Steht dort eine 1, handelt es sich um einen Container mit dem alten LUKS1-Header-Format. LUKS1-Header unterstützen ausschließlich PBKDF2 und müssen daher ins LUKS2-Format konvertiert werden, wenn argon2id zum Einsatz kommen soll. So ein Upgrade ist allerdings nicht immer möglich oder sinnvoll (siehe Kasten).

Falls Sie Version 2 des Header-Formats nutzen, kommt es auf die Ausgabe zu „PBKDF“ bei den einzelnen Keyslots an. Dort sollte idealerweise „argon2id“ stehen. (Die Ausgabe von „pbkdf2“ unter „Digests“ stellt kein Problem dar.) Für jeden benutzten Keyslot listet cryptsetup unterhalb von „PBKDF“ außerdem mit „Time cost“, „Memory“ und „Threads“ auf, wie kostenintensiv die Schlüsselableitungsfunktion eingestellt ist.

Falls Ihr LUKS-Container PBKDF2 einsetzt, fehlen die Angaben für „Memory“ sowie „Threads“ und statt „Time cost“ meldet cryptsetup die Anzahl der PBKDF2-Iterationen. Mindestens 600.000 sollten es auf normaler Hardware schon sein.

Upgrade durchführen

Ein Upgrade ist sinnvoll, falls Ihr Container recht geringe Kosteneinstellungen nutzt oder nicht die KDF argon2id verwendet. (Achten Sie auf das „d“; zwischenzeitlich nutzte LUKS argon2i, was besser als PBKDF2 ist, aber nicht so gut wie die id-Variante.) Falls Sie sich nicht sicher sind, ob die Kosteneinstellungen Ihrer aktuellen Hardware angemessen sind, können Sie auch testweise einen neuen Schlüssel anlegen. Dazu gleich mehr, zuallererst sollten Sie unbedingt ein Header-Backup erstellen:

sudo cryptsetup luksHeaderBackup  /dev/DEVICE --header-backup-file  /PFAD/ZU/DATEI

Geben Sie statt /PFAD/ZU/DATEI an, wohin cryptsetup das Backup schreiben soll. Die Datei muss außerhalb des betroffenen Containers liegen, beispielsweise auf einem USB-Stick. Die nachfolgenden Befehle modifizieren nur den LUKS-Header und nicht die verschlüsselten Daten an sich. Falls irgendetwas katastrophal schiefgeht, können Sie mit dem Backup den alten Header wiederherstellen und bekommen wieder Zugriff auf Ihre Daten. Ersetzen Sie dafür in obigem Befehl luksHeaderBackup durch luksHeaderRestore. Trotz dieser Rettungsmöglichkeit gilt: Wie immer sollten Sie von all Ihren wichtigen Daten ein aktuelles, externes Backup haben.

Anschließend upgraden Sie mit folgendem Befehl einen Keyslot auf argon2id, mit Rechenzeit- und Arbeitsspeicherbedarf, der sich an Ihrer aktuellen Hardware orientiert:

sudo cryptsetup luksConvertKey  /dev/DEVICE --pbkdf argon2id

Der Befehl verlangt ein gültiges Entschlüsselungspasswort von Ihnen; nach dieser Angabe entscheidet sich, welcher Keyslot aktualisiert wird. Wenn Sie mehr als einen Slot nutzen, sollten Sie den Befehl also mehrfach ausführen und nach und nach alle existierenden Passwörter angeben. Um zu prüfen, ob die Konvertierung erfolgreich verlief, lassen Sie sich den aktuellen Header erneut ausgeben:

sudo cryptsetup luksDump /dev/DEVICE

Alternativ zu luksConvertKey können Sie auch luksAddKey schreiben, um einen zusätzlichen Schlüssel anzulegen, statt einen alten zu konvertieren. Das Programm fordert Sie dann auf, erst das Passwort für einen bestehenden Key einzugeben und danach zweimal das neue Passwort. Geben Sie einfach immer dasselbe Passwort an, sofern Sie es nicht wechseln wollen. Anschließend ist in Ihrem Container ein weiterer Keyslot belegt. Mit obigem luksDump-Befehl können Sie dessen Existenz und Kosteneinstellungen prüfen und sie mit dem alten Slot vergleichen.

Wenn Sie fortan den neuen Keyslot nutzen wollen, dann geben Sie im folgenden Befehl die alte Slotnummer (mit den zu geringen Kosten) an, um den Slot zu löschen:

sudo cryptsetup luksKillSlot  /dev/DEVICE SLOTNUMMER

Andernfalls geben Sie die Nummer des neuen Slots an, um ihn zu löschen und alles beim Alten zu lassen. In beiden Fällen fragt cryptsetup zur Sicherheit nach dem Passwort für einen Keyslot, der erhalten bleibt, damit Sie sich nicht versehentlich aussperren.

Prüfen Sie anschließend, ob auch tatsächlich alles funktioniert. Besonders, dass Sie – falls nötig – von dem Container booten können und jede Software, die mit dem Container interagiert, mit der neuen KDF zurechtkommt. Nachdem Sie sich davon überzeugt haben, sollten Sie das Header-Backup löschen. Denn die neuen, guten KDF-Parameter helfen wenig, wenn noch Header-Backups existieren, die nur mit den schlechteren KDFs geschützt sind. (syt@ct.de)