Die Vollverschlüsselung von Linux ist momentan so sehr in Bewegung wie seit Jahren nicht. Es gibt berechtigte Zweifel an der Sicherheit von LUKS1 mit veralteten Einstellungen und immer mehr Entwickler überlegen, wie sich TPM 2.0 oder FIDO sinnvoll in den Prozess integrieren lassen. Linux holt hier eine Entwicklung nach, die Apple und Microsoft schon lange erledigt haben.
Warum TPM und was ist bislang möglich
Die Angriffsszenarien sind hierbei allerdings unterschiedlich. FIDO2 ist der klassische zweite Faktor, zusätzlich zum Passwort (oder bei Bedarf auch ohne Passwort), der benötigt wird, um das System zu starten. Die Sinnhaftigkeit einer 2FA steht außer Frage. Strittiger in der Linux-Welt ist TPM. Hier kursiert zu viel FUD und insbesondere in Deutschland wird dies weitergetragen.
Dabei kann auch TPM ein sinnvoller Baustein als Teil einer verifizierten Bootkette sein an deren Ende dann die Benutzerdaten per Loginabfrage entschlüsselt werden. TPM ist hier eine Methode, um zwei gängige Bedrohungsszenarien zu adressieren:
- Um eine Vollverschlüsselung zu knacken, besteht immer noch darin, die Festplatte auszubauen und anschließend zu “bearbeiten”. Davor schützen inzwischen die meisten Betriebssysteme ihre Anwender – außer Linux. Zwischen dem Angreifer und den Daten steht meist nur LUKS (im schlimmsten Fall LUKS1 mit veraltetem Algorithmus) und das kann ich in beliebiger Frequenz mit Passworteingaben angreifen.
- Ein weiterer Anwendungsfall sind Systeme, die man zwar verschlüsseln möchte, aber die im Normalfall ohne Passworteingabe bis zum Nutzerlogin starten sollen (solange sich niemand an der Hardware zu schaffen gemacht hat). Hier wird entweder oft auf Verschlüsselung verzichtet oder es gibt fehleranfällige Lösungen, um beim Systemstart ein Passwort remote eingeben zu können.
Ein Ansatz stammt aus der systemd-Entwicklung und erlaubt es, das TPM über systemd-cryptenroll zur LUKS-Entsperrung zu verwenden. Voraussetzung dafür ist eine unverschlüsselte Boot-Partition, was natürlich nicht perfekt ist. Außerdem funktioniert die Bindung an TPM nur zuverlässig mit dem TPM Platform Configuration Register (PCR) 7. Dabei prüft das System im Wesentlichen, ob secure boot unverändert ist. Das würde ich als Minimalprogramm bezeichnen, aber dieses Minimalprogramm funktioniert bei mir schon sehr gut.
TPM mit Grub 2
Das ist ein experimentelles Setup und sollte nur auf einem Testsystem ausprobiert werden.
Eine weitere Methode kann derzeit mit openSUSE getestet werden. Dabei wird nicht die systemd-cryptenroll verwendet, sondern das sogenannte “Sealing” des LUKS-Schlüssels mit einem Satz von PCRs. Auf Deutsch wäre Versiegelung des LUKS-Schlüssels vermutlich die adäquate Übersetzung. Voraussetzung ist ein aktueller Grub 2, das Paket pcr-oracle und die fde-tools. Aufgrund der Einschränkungen von Grub 2 kann LUKS2 nur mit dem PBKDF2-Algorithmus konfiguriert werden. Dieses Thema beschäftigte die Community bereits bei der oben verlinkten LUKS1 Problematik. Weitere spezielle Konfigurationen sind nicht notwendig.
Die Einrichtung erfolgt anschließend mit folgendem Befehl:
# fdectl regenerate-keyCode-Sprache: PHP (php)Danach fragt das Tool das LUKS-Kennwort ab. Anschließend sollte im Verzeichnis /boot/efi/EFI/opensuse eine Datei sealed.tpm liegen. Bei einem Neustart wird dann das System ohne Passwortabfrage gestartet.#
Der Vorteil dieser Methode ist, dass keine unverschlüsselte Bootpartition benötigt wird und somit das heute übliche Partitionsschema mit einer separaten EFI-Systempartition und einer btrfs-Partition mit Subvolumes für System, Home etc. unterstützt wird. Außerdem arbeiten die fde-tools standardmäßig mit deutlich mehr PCRs als systemd-cryptenroll. Die Standardeinstellungen sind 0, 2, 4, 7 und 9, können aber angepasst werden.
Bewertung
Alles in allem wieder eine sehr spannende Entwicklung. Momentan bleibe ich bei der Vorgehensweise mit systemd-cryptenroll, da es sich im Alltag bewährt hat. Im Hinblick auf MicroOS bzw. SUSE ALP, die eine individuelle Partitionierung nicht mehr vorsehen und eine unverschlüsselte Boot-Partition bei aktivierter Systemverschlüsselung verhindern, dürften die fde-tools aber mittelfristig eine spannende Alternative werden.
Eine gängige Methode soll sein, die Festplatte auszubauen und dann zu bearbeiten – ok, kann sein, hab’ keine praktische Erfahrung. Man kann aber auch einfach den Rechner mitnehmen / beschlagnahmen / Diebstahl. Dann schaltet der Tunichtgut ihn einfach ein und schwuppdiwupp – alle Daten liegen entschlüsselt vor? Soll das der Sinn einer Vollverschlüsselung sein? Echt sehr spannend.
Nicht wenn man diese z.B. über systemd-homed oder eCryptFS in verschlüsselten Homeverzeichnissen ablegt oder in verschlüsselten Datenpartitionen, die bei Anmeldung des Benutzers automatisch eingebunden werden. Nur um ein paar Beispiele zu nennen.
Ok – wenn ich dich richtig verstanden habe, braucht man also noch eine richtige Verschlüsselung für die Daten, weil die Vollverschlüsselung mit TPM mehr oder weniger sinnlos weil leicht zu umgehen ist, indem man den Rechner mitnimmt und den Einschaltknopf drückt. Die Daten werden dann bei jedem Lese- und Schreibzugriff zweimal ent- bzw. verschlüsselt – die CPU freut sich – coole Idee. Könnte man aber auch gleich richtig machen mit einer LUKS Verschlüsselung – oder?
Nein, weil es komplementäre und keine gegensätzlichen Ansätze sind. Die TPM-Bindung deiner Systemverschlüsselung in Kombination mit Faktoren wie Secure Boot verhindert, dass sich jemand an deiner Hardware zu schaffen macht. Das ersetzt natürlich nicht die Passworteingabe. Idealerweise dort, wo du es ja eh eingeben musst. Also beim Benutzerlogin, um dann eben noch die Benutzerdaten zu entschlüsseln. Deiner CPU ist das übrigens total egal.
Lesetipp: https://curius.de/2022/02/verifizierter-systemstart-verified-boot-der-stand-bei-linux/
Verschlüsselungseinheiten sind in Desktop-CPUs bereits seit über 1 Jahrzehnt eingebaut.