LUKS: Alte verschlüsselte Container unsicher? Ein Ratgeber für Updates
Angeblich konnte die französische Polizei einen LUKS-Container knacken. Kein Grund zur Panik, aber ein Anlass, Passwörter und LUKS-Parameter zu hinterfragen.
(Bild: peterschreiber.media/Shutterstock.com)
Der Entwickler Matthew Garrett ruft in seinem Blog LUKS-Nutzer dazu auf, ihre Container upzudaten. Angeblich habe die französische Polizei einen mit LUKS verschlüsselten Container aufbrechen können. Weil ein sehr gutes Passwort zum Einsatz gekommen sein soll (mehr als 20 Zeichen, darunter Buchstaben, Zahlen und Sonderzeichen) hat Garrett hat die Schlüsselableitungsfunktion PBKDF2 im Verdacht und fordert zum Wechsel auf.
Allerdings sind wesentliche Umstände nicht bekannt, es ist durchaus möglich, dass das Passwort nicht so gut wie behauptet war oder die Polizei auf anderen Wegen an das Geheimnis gelangte, beispielsweise durch einen Keylogger.
Die Schwächen von PBKDF2
Nichtsdestotrotz hat PBKDF2 bekannte Schwächen, die vor allem dann gravierend sind, wenn das genutzte Passwort nicht allzu gut ist: PBKDF2, die "Password-Based Key Derivation Function 2", dient wie auch andere Schlüsselableitungsfunktionen (KDF) dazu, aus dem Nutzerpasswort den eigentlichen Schlüssel zu generieren. Um Brute-Force- und Wörterbuch-Angriffe, bei denen massenhaft Passwörter ausprobiert werden, zu erschweren, erfordert PBKDF2 einstellbar viel Rechenaufwand. Dazu wird eine Berechnung in mehreren Iterationen wiederholt.
Ein Problem ist, dass LUKS die nötigen Iterationen beim Anlegen eines Containers nach der aktuell genutzten Hardware bemisst, sodass die Entschlüsselung nicht zu lange dauert. Nachträglich angepasst wird der Wert nicht mehr – auch nicht bei einem Upgrade des Systems. Wer also alte Container nutzt oder sie auf recht schwacher Hardware angelegt hat, dessen LUKS-Verschlüsselung bietet nur bedingt Schutz vor Brute-Force-Angriffen.
Hinzu kommt, dass PBKDF2 nur wenig RAM erfordert. Brute-Force-Attacken mit Grafikchips oder spezialisierter Hardware (ASICs) sind daher vergleichsweise effizient gegen diese Schlüsselableitungsfunktion.
Die KDF argon2id bietet besseren Schutz und ist die aktuell vom BSI empfohlene KDF (siehe hier, im Anhang B.1.2.). Aktuelle Versionen von cryptsetup beherrschen argon2id auch und sollten es standardmäßig nutzen, wenn man neue LUKS-Container anlegt. Allerdings werden bereits angelegte Container mit PBKDF2 nicht automatisch migriert.
Upgrade sinnvoll?
Wer wissen will, welche KDF die eigenen LUKS-Container einsetzen, kann dies mit folgendem Kommando herausfinden:
sudo cryptsetup luksDump /dev/DEVICE
Statt DEVICE muss die Festplatte mit dem Container angegeben werden. Wer ein LUKS-Header-Backup in einer Datei überprüfen will, kann die dev-Pfadangabe durch den Parameter --header=PFAD/ZUR/DATEI überlagern. In unseren Versuchen mit cryptsetup Version 2.6.1 konnte man die Device-Angabe nicht gänzlich weglassen, allerdings genügt es beispielsweise "X" zu schreiben. cryptsetup ignoriert die Angabe und nutzt die im --header-Parameter spezifizierte Datei.
Wichtig ist die Ausgabe zu "PBKDF" bei den einzelnen Keyslots. Dort sollte idealerweise "argon2id" stehen. Die Ausgabe von "pbkdf2" unter "Digests" ist kein Problem. Wer ein Upgrade durchführen will, kann die nötigen Schritte in Garretts Blog nachlesen. Wie dort beschrieben, ist eine vorherige Sicherung des aktuellen Headers Pflicht und auch sonst einiges zu beachten: Container, die noch das LUKS1-Format einsetzen, müssen vorher auf LUKS2 migriert werden und nicht jede Distribution, deren Werkzeuge LUKS-Container mit argon2id unterstützen, kann auch davon booten. Außerdem müssen Nutzer eines Linux-Systems, bei dem /boot verschlüsselt ist, zumindest vom Upgrade dieser Partition absehen: Der Bootloader GRUB entschlüsselt aktuell nur mit PBKDF2.
Wichtiger als die Wahl der KDF sind ohnehin Auswahl und Handhabung des Passworts oder der Passphrase: Ein wirklich gutes Passwort lässt sich unabhängig von der KDF praktisch nicht mit Bruteforce knacken und ein wirklich schlechtes kann auch keine KDF retten. Zudem muss man dieses Geheimnis natürlich gut hüten, darf es nicht zweitverwenden und nicht auf potenziell kompromittierten Systemen eingeben. Auf der sicheren Seite ist aktuell, wer 20 wirklich zufällige Zeichen nutzt, 6 zufällig ausgewählte Wörter oder mehr.
(syt)
