LUKS – Ein kleiner Weckruf

Vor einigen Wochen machte die Vermutung die Runde, LUKS sei gebrochen. Auslöser waren Berichte über ein erfolgreiches Knacken einer verschlüsselten Festplatte durch die französische Polizei. Der bekannte Entwickler Matthew Garrett vermutete als Ursache die veraltete Schlüsselableitungsfunktion PBKDF2.

Was ist das Problem?

Wir wissen bis heute nicht, ob das wirklich die Ursache war und die französische Polizei LUKS wirklich knacken konnte oder ob nicht ein zu schwaches Passwort oder ähnliches die Schwachstelle war. LUKS oder bestimmte Konfigurationen von LUKS pauschal für unsicher zu erklären, wäre daher eine Panikmache.

Der Vorfall sollte uns aber daran erinnern nicht nachlässig zu werden. Ich bemängele ja häufiger eine gewisse bräsige Selbstzufriedenheit in der Linux-Gemeinschaft. Die Gewissheit, durch Open Source und eine streckenweise überlegene Architektur ein sicheres System zu nutzen, hat sich tief in das kollektive Bewusstsein eingenistet. Selbstzufriedenheit kann zu falscher Untätigkeit führen.

Konkret geht es um LUKS und die Schlüsselabteilungsfunktion. LUKS wird stetig verbessert. Vor einigen Jahren gab es beispielsweise den Wechsel von LUKS1 auf LUKS2 mit allgemeinen Verbesserungen. Hinzu kommen Entwicklungen bei den Schlüsselabteilungsfunktionen.

Die Schlüsselabteilung generiert in mehreren Iterationen aus dem Passwort den eigentlichen LUKS-Key. Um das nicht unnötig in die Länge zu ziehen, berücksichtigt LUKS die verfügbare Hardware. PBKDF2 hat bekannte Schwächen, deshalb wurde bereits vor einiger Zeit argon2id als Ersatz entwickelt. Dieses Verfahren ist ab 2020 auch die Empfehlung des BSI.

Das denkbar schlechteste Szenario ist daher ein Container, der vor vielen Jahren mit aus heutiger Sicht völlig veralteter Hardware aufgesetzt wurde und mit einer mittelmäßigen Passphrase geschützt wurde. Ein solcher Container könnte aus heutiger Sicht wahrscheinlich geknackt werden. Dies ist kein abwegiges Szenario. Viele Linux-Benutzer – ob mit Rolling-Releases oder stabilen Systemen – sind stolz auf die langen Laufzeiten ihrer Installationen. Externe Festplatten werden wahrscheinlich sogar nur einmal – direkt nach dem Kauf – neu verschlüsselt.

Das Problem liegt hier in meinen Augen durchaus auch bei den Distributionen. Viele Leser werden dieses Lamento vermutlich nicht mehr hören können. Keine Distribution aktualisiert verschlüsselte Partitionen bei Upgrades und kein Kommandozeilentool oder grafisches Programm weist auf veraltete Einstellungen hin. Den meisten Anwendern fehlte oder fehlt vermutlich bis heute jegliches Problembewusstsein.

LUKS aktualisieren

Eine Aktualisierung ist relativ einfach durchzuführen. Es gibt jedoch Einschränkungen. Wer eine verschlüsselte Boot-Partition verwendet und daher auf die GRUB-Implementierung angewiesen ist, muss bei PBKDF2 bleiben. Ein weiterer Grund, warum ich verschlüsselte Bootpartitionen und Passworteingabe in GRUB für überbewertet halte. Für solche Dinge sind Integritätsprüfungen via TPM wesentlich sinnvoller, aber das führt hier zu weit.

Die aktuellen Standardeinstellungen seines Systems kann man wie folgt abfragen:

$ cryptsetup --help

Die Ausgabe bei einem aktuellen Fedora Kinoite ist wie folgt:

Vorgegebenes festeingebautes Metadatenformat ist LUKS2 (für luksFormat-Aktion).

Die Unterstützung des externen Token-Plugins LUKS2 ist integriert.
Pfad des Plugins für externe LUKS2-Token: /usr/lib64/cryptsetup.

Werkseinstellungen für Schlüssel und Passphrasen:
        Maximale Größe der Schlüsseldatei: 8192 kB, Maximale Länge der interaktiven Passphrase: 512 Zeichen
Vorgabe-PBKDF für LUKS1: pbkdf2, Durchlaufzeit: 2000 Millisekunden
Vorgabe-PBKDF für LUKS2: argon2id
        Iterationszeit: 2000, benötigter Speicher: 1048576 kB, parallele Threads: 4

Standard-Verschlüsselungsparameter:
        Loop-AES: aes, Schlüssel 256 Bits
        plain: aes-cbc-essiv:sha256, Schlüssel: 256 Bits, Passphrase-Hashen: ripemd160
        LUKS: aes-xts-plain64, Schlüssel: 256 Bits, LUKS-Header-Hashen: sha256, Zufallszahlengenerator: /dev/urandom
        LUKS: Standard-Schlüsselgröße mit XTS-Modus (zwei interne Schlüssel) wird verdoppelt.

Wie man alte Container aktualisiert habe ich hier schon beschrieben: Verschüsselte Volumes von LUKS1 auf LUKS2 konvertieren

$ sudo cryptsetup convert /dev/<number> --type luks2 

Hiernach die Abfrage bestätigen und das war es auch schon. Bei einer erneuten Abfrage sollte Version 2 in der entsprechenden Zeile stehen.

Zusätzlich muss auch explizit PBKDF auf Argon2 umgestellt werden.

$ sudo cryptsetup luksChangeKey /dev/<number> --pbkdf argon2id

Zur Bestätigung muss das alte und neue Kennwort eingeben werden. Bei Bedarf kann man auch das alte Kennwort als neues Kennwort nutzen.

Zusammengefasst

Es ist nicht klar, ob LUKS wirklich gebrochen wurde, aber LUKS wird glücklicherweise ständig weiterentwickelt und veraltete und potentiell unsichere Elemente werden ersetzt. Der Vorfall sollte zum Anlass genommen werden, einen Blick auf die eigenen LUKS-Container zu werfen, da die Distributionen die Wartung für ihre Anwender nicht übernehmen.