Bei Sicherheitsexperten steht Vollverschlüsselung via TPM hoch im Kurs. Wir unternehmen einen Versuch mit OpenSuse Aeon.

Aktuelle Hardware verfügt häufig über einen TPM-Chip, den die CPU mitbringt und der sich für unterschiedliche Aufgaben eignet. Unter anderem lassen sich damit SSH-Schlüssel generieren und aufbewahren, ein sicherer Bootmodus erstellen oder komplett mit LUKS2 verschlüsselte Installationen automatisch aufsperren. Mit der letztgenannten Aufgabe beschäftigt sich dieser Artikel. Die Methode lässt sich sowohl bei der Erstinstallation als auch nachträglich implementieren und erfordert, je nach Distribution, mehr oder weniger Handarbeit.

TPM steht für Trusted Platform Module (Abbildung 1). Dahinter verbirgt sich ein Mikrocontroller, der PCs, Notebooks oder ähnliche Geräte um grundlegende Sicherheitsfunktionen erweitert. Dazu gehört unter anderem das Erstellen einer Trusted-Computing-Plattform, die Manipulationen während des Bootvorgangs erkennt. In der Praxis geschieht das, indem die CPU an jeder Bootkomponente eine Reihe von Messungen in Form kryptografischer Hashes vornimmt und sie an das TPM sendet. Es zeichnet sie auf und gibt den Verschlüsselungs-Key nur frei, wenn die Messung mit dem bereitgestellten Wert übereinstimmt.

Abbildung 1: Ein TPM besteht aus den Sektionen Krypto-Prozessor und Speicher, wobei sich letzterer in flüchtigen und nichtflüchtigen unterteilt. Quelle: Eusebius, LGPL (https://commons.wikimedia.org/wiki/User:Eusebius)

Der TPM2-Chip lässt sich mit einer fest auf dem Mainboard verlöteten Smartcard vergleichen. Um festzustellen, ob Ihr Gerät über ein TPM verfügt, sehen Sie im Sys-Filesystem in der Datei tpm_version_major nach (Listing 1, erste Zeile). Falls vorhanden, steht dort in der Ausgabe die TPM-Versionsnummer (1.2 oder 2). Existiert der entsprechende Pfad nicht, ist entweder kein TPM verbaut oder es ist im UEFI deaktiviert. Die im vorliegenden Artikel beschriebene Vorgehensweise setzt TPM 2.0 voraus, das wir im Weiteren als TPM2 bezeichnen.

$ cat /sys/class/tpm/tpm*/tpm_version_major
$ zcat Aeon-Installer.x86_64.raw.xz | sudo dd bs=4M of=/dev/sdX iflag=fullblock oflag=direct status=progress; sync

OpenSuse Aeon

Wir nutzen für unseren Test OpenSuse Aeon [1], einen der möglichen Nachfolger von OpenSuse Leap. Möglich deshalb, weil die Zukunft von OpenSuse derzeit im Wandel ist und noch nicht feststeht, in welcher Form es weitergeht. Aeon ist die Gnome-Variante von OpenSuse MicroOS [2], einem atomaren System mit schreibgeschützt eingehängter Root-Partition und transaktionalen Updates unter Verwendung von Btrfs-Snapshots.

Der Grund für die Wahl von OpenSuse Aeon als Testobjekt ist die dort am weitesten fortgeschrittene Integration der Full Disk Encryption (FDE) mit Linux Unified Key Setup (LUKS2), LVM und TPM2. Ursprünglich wollte der Autor wegen der größeren Verbreitung Ubuntu zum Testen heranziehen, doch der Installationsversuch der seit Ubuntu 23.10 angebotenen experimentellen Funktion scheiterte mehrfach. Weitere Informationen zum Stand der Entwicklung liefert das Ubuntu-Blog [3]. Bei Arch Linux war das Aufsetzen von Vollverschlüsselung inklusive TPM2 [4] zwar lehrreich, aber mit extrem hohen Aufwand verbunden.

Alternativ zu TPM2 eignet sich ein FIDO2-Stick wie ein Yubikey oder Nitrokey. Der Einsatz von Secure Boot ist bei Aeon optional; die Entwickler bei OpenSuse empfehlen jedoch, es wegen der insgesamt erhöhten Sicherheit zu nutzen. Hingegen benötigen Sie zwingend Systemd ab Version 251, da dort erstmals Werkzeuge wie Systemd-cryptenroll zur Verfügung stehen.

Die Abhängigkeit von Systemd verwundert kaum: Immerhin stammt ein Grundlagenartikel zum automatischen Aufschließen von vollverschlüsselten Systemen von Systemd-Mastermind Lennart Poettering [5]. Systemd-cryptenroll dient dazu, das Anmelden des TPM2 in einem verschlüsselten Datenträger zu erleichtern. Es funktioniert mit jedem LUKS2-Datenträger und bettet ein winziges Stück Metainformation in den LUKS2-Header ein, die für den automatischen Entsperrvorgang benötigte Parameter enthält.

Installation

Vorbereitend laden Sie im ersten Schritt das Aeon-Image [1] herunter. Es steht noch nicht in stabiler Version bereit, liegt mittlerweile aber als Release Candidate 3 vor. Sie erhalten ein komprimiertes Abbild.

Ändern Sie den Image-Namen auf der Festplatte in Aeon-Installer.x86_64.raw.xz und kopieren Sie das Abbild auf einen USB-Stick. Dazu verwenden Sie den Befehl aus der zweiten Zeile von Listing 1, wobei Sie den Platzhalter X in /dev/sdX durch den korrekten Bezeichner des USB-Sticks ersetzen. Da das Image nach dem Entpacken 12 GByte umfasst, sollte der Stick mindestens 16 GByte Platz bieten. Je nach Hardware dauert der Vorgang bis zu 10 Minuten.

Danach booten Sie Aeon vom USB-Stick und starten den Tik genannten Installer. Er wirkt grafisch noch etwas unausgereift, funktioniert aber fehlerfrei. An die Grundinstallation schließt sich die Verschlüsselung an. Dabei zeigt die Software zunächst den Recovery Encryption Key (Abbildung 2), also einen Wiederherstellungsschlüssel.

Abbildung 2: Bewahren Sie den bei der Installation erstellten Wiederherstellungsschlüssel sorgsam auf. Er dient nach Änderungen an der Hardware oder der Partitionierung dazu, das System aufzuschließen.

Measured Boot

Sobald die Meldung Measured Boot erscheint, bietet der TPM2 volle Kompatibilität. Das heißt, er unterstützt TPM2_PolicyAuthorizeNV, eine Funktion, den TPM2 seit Version 1.38 enthält. Damit können Sie den Default Mode nutzen, also den Standardmodus mit vollem TPM2-Support. Das bedeutet, dass Aeon alle wichtigen Aspekte der Integrität des Systems ermittelt und im TPM speichert. Dazu gehören UEFI-Firmware, Secure-Boot-Status (aktiviert oder deaktiviert), Partitionstabelle, Bootloader und Treiber sowie Kernel und Initrd.

Eine Aktualisierung des Systems berücksichtigt automatisch auch diese. Wenn Ihr System startet, vergleicht es den aktuellen Zustand mit den im TPM2 gespeicherten Messungen. Stimmen die beiden überein, bootet das System. Falls nicht, besteht die Möglichkeit, dass das System manipuliert wurde. Dafür kann ein Angreifer verantwortlich sein, aber genauso Sie selbst, wenn Sie etwa Änderungen bei Secure Boot, dem Bootloader, an Partitionen oder der Initrd vorgenommen oder das UEFI aktualisiert haben.

Hier kommt der erwähnte Recovery Key ins Spiel. Ihn sollten Sie allerdings nur einsetzen, wenn Sie selbst eine der erwähnten Änderungen eingepflegt haben. Ansonsten booten Sie eventuell in ein kompromittiertes System und vergrößern den Schaden. Haben Sie beispielsweise die UEFI-Firmware aktualisiert, verwenden Sie den ersten Befehl aus Listing 2; ansonsten genügt der zweite Aufruf.

$ sudo sdbootutil --ask-pin update-predictions
$ sudo sdbootutil update-predictions

In beiden Fällen müssen Sie anschließend den Recovery Key angeben. Beachten Sie bei der Eingabe bitte, dass zu diesem frühen Zeitpunkt ein US-Tastaturlayout gilt, also zum Beispiel der Bindestrich rechts neben der [0] liegt.

Default und Fallback

Entspricht das TPM2 nicht den Anforderungen oder fehlt dem Rechner der Chip, schaltet der Aeon-Installer automatisch in den Fallback-Modus. Der verlangt, wie bisher üblich, ein Passwort zur Entschlüsselung. Dabei greifen Sie ebenfalls auf einen Recovery Key zurück, sollte das Passwort verloren gehen. Im Gegensatz zum Default Mode müssen Sie hier also weiterhin zwei Passwörter eingeben und sind nicht durch einen Measured Boot abgesichert [6].

Da der Standardmodus eine starke Vertrauenskette mit wichtigen Bootkomponenten herstellt, gilt das Verwenden von Secure Boot in diesem Modus als optional. Im Fallback-Modus gibt es keine derartige Überprüfung, weswegen Sie Secure Boot nach Möglichkeit aktivieren sollten. Steht es im Fallback-Modus auf inaktiv, ist Ihr System anfällig für Manipulationen. Dazu gehören auch Angriffe, die Ihr Passwort bei der Eingabe abfangen können.

Ein aktiviertes Secure Boot berechnet Hashes sämtlicher Komponenten in der Bootkette, darunter UEFI und dessen Konfiguration sowie Bootloader und Kernel. Es verkettet sie so, dass eine Modifikation in einer dieser Komponenten die berechneten und gespeicherten Hashes in allen folgenden PCRs (Platform Configuration Registers) ändert. Dabei handelt es sich um 16 Register, die die Integritätsprüfung beim Booten heranzieht.

Nachdem Sie Ihren Wiederherstellungsschlüssel sicher verwahrt und das bestätigt haben, erreicht die Installation bereits ihr Ende. Aeon führt einen Neustart durch und richtet daraufhin das System ein. Dabei bleibt der Bildschirm schwarz; lediglich eine kleine Zeile am oberen Rand informiert über die Aktivitäten. Nach einigen Minuten zeigt ein Farbverlauf ins Dunkelgrün, dass das System noch arbeitet. Zu guter Letzt erscheint der übliche Einrichtungsdialog von Gnome (Abbildung 3), der in der Installation einiger essenzieller Apps mündet.

Abbildung 3: Nach der Verschlüsselung installiert das System einige essenzielle Apps, bevor der bekannte Einrichtungsdialog von Gnome die Installation abschließt.

Atomares System

Ein Neustart schließt das System für Sie auf. Sie gelangen wie bei einer gewöhnlichen Distribution in die Anmeldemaske für Ihr Benutzerkonto. Schneller als mit Aeon können Sie derzeit kein System mit Verified Boot, schreibgeschützter Root-Partition und atomaren Aktualisierungen mit von Snapper (Abbildung 4) verwalteten Btrfs-Snapshots aufsetzen. Für ein tieferes Verständnis des Vorgangs können Sie zusätzlich die Ärmel hochkrempeln und in Tumbleweed, MicroOS oder Aeon das Aufschließen einer FDE-Installation ohne Passwort manuell einrichten [7]. Falls Sie Snapper noch nicht kennen, erfahren Sie im Snapper-Tutorial bei OpenSuse [8] mehr über das Snapshot-Verwaltungswerkzeug.

Abbildung 4: Mit dem hauseigenen OpenSuse-Tool Snapper verwalten Sie Ihre Snapshots. Bei Bedarf lässt sich eine grafische Darstellung per snapper-gui von Github nachrüsten.

OpenSuse hat Aeon als Minimalsystem ausgelegt (Abbildung 5). Neben Firefox, dem Dateimanager Files und dem App Store Gnome Software bringt es nur wenige Helferlein mit. Für das Nachinstallieren von Software zeichnet in erster Linie Flatpak verantwortlich, in zweiter Reihe steht Distrobox (Abbildung 6). Das Tool ist für OpenSuses Rolling-Release-Distribution Tumbleweed vorbereitet, verwaltet aber genauso gut andere Distributionen. Das Dateisystem von Aeon gleicht dem anderer LVM-Systeme mit Btrfs.

Abbildung 5: Die vorinstallierte Software beschränkt sich auf wenige Anwendungen, die Ausgestaltung mit (vorzugsweise) Flatpaks obliegt dem Anwender.

Abbildung 6: Als alternative Installationsmethode, hauptsächlich für Treiber und Konsolenwerkzeuge, bietet sich Distrobox an. Es stellt Pakete aus verschiedenen Distributionen in Containern bereit.

Sicher sicher?

Als der Autor den Artikel konzipierte, ergab sich eine simple Frage: Wie gut schützt mein voll verschlüsseltes Notebook meine Daten, wenn es frei zugänglich herumsteht oder gar gestohlen wird?

Möchte ein Unbefugter das System booten, benötigt er wie bei einem unverschlüsselten System das Zugangspasswort für ein Benutzerkonto. Der Standardmodus bietet darüber hinaus mit Measured Boot strenge Prüfungen der Integrität des Systems und schützt es vor kennwortbasierten Angriffen. Ansonsten fiele es einem Angreifer nicht besonders schwer, die übliche Authentifizierung mit Benutzername und Passwort zu knacken.

Bei den meisten herkömmlichen Linux-Systemen lässt sich die Authentifizierung beispielsweise umgehen, indem man die Kommandozeile des Kernels so ändert, dass er mit dem Parameter init=/bin/bash bootet. Im Standardmodus würde eine solche Änderung jedoch erkannt und somit die Festplatte nicht automatisch entsperrt. Die Integritätsprüfung des Standardmodus bewahrt auch vor Änderungen an der Initrd, die ein Angreifer dazu nutzen könnte, die vom Fallback-Modus verwendete Passphrase abzufangen.

Selbst wenn jemand die Festplatte ausbaut und in einem anderen System startet, verhindert das Konstrukt einen erfolgreichen Bootvorgang. Tools wie Bruteforce-luks brauchen wesentlich mehr Zeit, das Zertifikat im TPM-Chip zu knacken als ein herkömmliches Passwort. Daher hilft diese Methode einem Dieb nicht weiter. Es ist außerdem unmöglich, einen privaten Schlüssel aus dem TPM2-Modul zu extrahieren. Davon ausgehend, dass es absolute Sicherheit nicht gibt, gewährleistet die Methode des durch TPM2 gehärteten Bootvorgangs die Integrität und Authentizität der Daten auf einem hohen Niveau.

Fazit und Ausblick

Mit keiner anderen Distribution als OpenSuse Aeon gelingt es derzeit so leicht, ein vollverschlüsseltes System aufzusetzen, das mit TPM2 über einen verifizierten Bootvorgang verfügt und das System ohne Passworteingabe aufschließt.

Die Funktionalität passt gut zu einem modernen, atomaren System mit schreibgeschützter Root-Partition und automatischen Aktualisierungen mit Rollback per Btrfs-Snapshots unter der Regie von Snapper. Das einzige, was im Test negativ auffiel: Ohne offensichtlichen Grund fühlt sich das System ein wenig behäbig an. Der Ressourcenverbrauch nach dem Start (Abbildung 7) entspricht jedoch dem vergleichbarer Systeme.

Abbildung 7: Das System fühlte sich insgesamt etwas schwerfällig an. Der Ressourcenverbrauch bietet aber keinen Anhaltspunkt auf die Ursache.

In nächster Zeit bieten vermutlich weitere Distributionen Full Disk Encryption (FDE) mit TPM2 an. OpenSuse Kalpa als KDE-Variante erbt sicherlich die Funktionalität von Aeon. Inzwischen hat OpenSuse die Methodik auch für seine Rolling-Release-Distribution Tumbleweed freigegeben [9].

Canonical bietet dasselbe seit zwei Jahren für Ubuntu Core an, momentan arbeiten die Entwickler zudem an einer Umsetzung für Desktop-Ubuntu. Bootloader und Kernel kommen dabei als Snaps, sodass der Snapd-Agent für die Verwaltung der vollständigen Festplattenverschlüsselung während des gesamten Lebenszyklus verantwortlich zeichnet.

Bei Fedora-Systemen [10] lässt sich das Verfahren ebenfalls anwenden, es erfordert allerdings noch mehr Handarbeit als bei OpenSuse. Anleitungen für weitere Distributionen wie Kali Linux [11] oder LMDE [12] finden Sie im Internet. (tle/csi)