© shaffandi, 123RF

Das einst geschmähte Trusted Platform Module könnte künftig zu einem sicheren Anker für die Chain of Trust auf Rechnern werden. Warum das so ist, wie es aktuell um TPM unter Linux steht und wohin die Reise gehen könnte, erklärt Security-Experte Matthew Garrett in diesem Artikel.

Die Sicherheit jeder Schicht eines Betriebssystems hängt von der Sicherheit der jeweiligen Schicht darunter ab. Das heißt: Kann der Anwender der CPU nicht vertrauen, den Code korrekt auszuführen, gibt es keine Möglichkeit, sichere Software auf dieser CPU zu betreiben. Manipuliert ein Angreifer den Bootloader, kann der Anwender auch dem Kernel nicht trauen, den dieser Bootloader lädt. Steckt in der Firmware selbst eine Backdoor, gibt es keine Möglichkeit, die korrekte Funktion von Secure Boot zu überprüfen. In diesem Fall hilft es auch nicht, dass Secure Boot es der Firmware erlaubt, einen Bootloader vor dem Ausführen zu validieren.

Das führt zu einem Henne-Ei-Problem: Der Anwender muss dem Betriebssystem vertrauen, das validiert, ob die Firmware nicht manipuliert wurde. Das aber klappt nur, wenn die Firmware nicht manipuliert wurde. Wie lässt sich also der Zustand eines Systems validieren, ohne ihm von Anfang an vertrauen zu müssen?

TPM als Lösung

Die Antwort liefert eine Reihe von Technologien, die der Begriff Trusted Computing zusammenfasst. Das Herzstück von Trusted Computing ist eine kleine Hardwarekomponente, das Trusted Platform Module (TPM). Dabei handelt es sich um einen per einfachem Bus verbundenen Chip auf der Hauptplatine des Systems, mitunter lässt es sich als Modul nachrüsten (Abbildung 1).

Abbildung 1: Für den Raspberry Pi liefert etwa Letstrust ein aufsteckbares TPM-2.0-Modul.

TPMs sind weder schnell noch leistungsfähig – fast alles, was ein TPM ermöglicht, schafft die CPU viel schneller. Das TPM sieht auch nicht, was der Rest des Systems tut, es weiß nur das, was der Computer ihm mitteilt. Was TPMs aber so mächtig macht, ist die Art, wie sie die Informationen nutzen, die ihnen der Computer liefert.

TPMs bringen eine Sammlung von Registern mit, die Platform Configuration Registers (PCRs, siehe Kasten “PCRs im Detail”). Bei einem Reset setzt das TPM auch diese auf 0. Beim Bootvorgang erzeugt das System kryptographische Hashes der Bootkomponenten und übergibt sie an das TPM. Jede Änderung an den Bootkomponenten modifiziert auch die Werte dieser Hashes und damit auch die vom TPM aufgezeichneten. Diesen Vorgang bezeichnen Experten als “Messen”, und ein Bootvorgang, der diese Möglichkeit nutzt, ist ein “gemessener Bootvorgang” (Measured Boot).

SHA1(c72bf7f5a487b1e75819b5b5b1d1644ded 23c10967 || SHA1("Hallo Welt")

Die Messungen verschiedener Komponenten landen auch in verschiedenen PCRs, wie Abbildung 2 zeigt. TPM misst dabei jede Komponente vor dem Ausführen, die wiederum misst die nächste Komponente, bevor sie diese ausführt. Hat jemand die Firmware manipuliert, weicht PCR0 ab. Selbst wenn die Firmware über die Messungen aller weiteren Komponenten lügt, weicht der Wert von PCR0 noch immer ab. Indem das System also auf die PCR-Werte schaut und sie mit den erwarteten Werten vergleicht, kann es feststellen, ob ein Teil des Bootprozesses kompromittiert ist.

Abbildung 2: Die Werte der gemessenen Komponenten landen in verschiedenen Platform Configuration Registers (PCRs).

Aber wie betrachtet ein Nutzer diese Werte? Ist das Betriebssystem kompromittiert, kann er sich nicht darauf verlassen, dass es die tatsächlichen Werte im TPM anzeigt. Tatsächlich braucht er dazu weitere Hilfe vom TPM selbst.

Schlüssel sichern

Damit kommt der Artikel zum nächsten wichtigen Teil der Funktionalität, die TPMs anbieten: die Fähigkeit, Verschlüsselungsschlüssel zu generieren und zu speichern. Initialisiert das System ein TPM, generiert dies einen Schlüssel, den Storage Root Key (SRK). Der verlässt das TPM niemals und das Betriebssystem hat keinen Zugriff darauf.

Fordert eine Anwendung das TPM auf einen Schlüssel zu generieren, tut das TPM dies und gibt anschließend die öffentlichen und privaten Teile an die Anwendung zurück. Bevor es aber die private Hälfte retourniert, verschlüsselt es diese mit dem SRK. Dadurch lässt sich der private Schlüssel nur verwenden, wenn die Anwendung ihn an das TPM zurückgibt, das ihn dann entschlüsselt und im internen TPM-RAM ablegt (siehe Kasten “Nicht-flüchtige Alternative”). Alles Material, das die öffentliche Hälfte des Schlüsselpaars chiffriert, lässt sich am Ende nur vom TPM entschlüsseln, weil dies den privaten Schlüssel kennt. Nutzt jemand ein TPM-basiertes Schlüsselpaar und ein Dieb stiehlt die Festplatte, gelangt er ohne das Originalsystem mit TPM nicht an die Daten.

Fragt eine Anwendung nach einer Verschlüsselung mit diesem Schlüssel, gibt sie bei Bedarf zugleich einen Satz von PCR-Werten an und ordnet diese dem verschlüsselten Material zu. Stimmen diese PCR-Werte beim Entschlüsseln nicht überein, weigert sich das TPM, das Material offenzulegen.

Verwendet jemand das TPM, um seine Schlüssel zur Festplattenverschlüsselung zu chiffrieren, weigert sich die Maschine zu booten, sobald sich Komponenten ändern, die am Bootvorgang beteiligt sind. Wie sich derartige Systeme konfigurieren lassen, zeigt [1]. Wer UEFI nutzt, sollte anstelle von Trusted Grub2 aber besser den »verifier_tpm_module«-Branch unter [2] verwenden.

Auch wenn ein auf diese Weise konfiguriertes System sich bei Manipulationen weigert zu booten, hindert dies einen Angreifer mit physischem Zugriff nicht daran, an die Passwörter zu gelangen. Er kann einfach die Festplatte ausbauen und durch eine andere ersetzen, die trotz modifizierten Bootvorgangs bootet. Loggt sich der Nutzer dann ein, speichert das System einfach sein Passwort und schickt es an den Angreifer.

Einen Ansatz, das zu vermeiden, liefert [3]. Diese Software nutzt das Time-based One Time Password Protocol (TOTP), das Websites für eine Zwei-Faktoren-Authentifizierung heranziehen. Das TPM verschlüsselt ein Geheimnis und lässt es erst wieder frei, wenn die PCR-Werte übereinstimmen. Das Geheimnis erscheint dann als QR-Code, der sich in eine reguläre 2FA-Anwendung eintragen lässt. Beim Booten entschlüsselt das System zugleich das Geheimnis und verknüpft es mit der aktuellen Tageszeit, um einen sechsstelligen Wert anzuzeigen. Der Benutzer vergleicht diesen mit dem Wert, den sein Handy präsentiert. Stimmen beide überein, kann er dem System vertrauen und sein Passwort sicher eingeben.

Doch selbst legitime Updates der Bootkomponenten verändern die Werte der PCRs, das Aktualisieren von Grub modifiziert etwa das PCR4. Das erzeugt eine hohe Anfälligkeit des Systems – regelmäßige Sicherheitsupdates machen es womöglich Boot-unfähig. Eine Option, dies zu umgehen, ist es, TPM in Verbindung mit Secure Boot zu nutzen. Dabei verwendet das System nur PCR7.

Erkennt die Firmware, dass Secure Boot für PCR7 aktiviert ist, misst sie jeden Secure-Boot-Schlüssel, der beim Booten zum Einsatz kommt. Um den Bootloader oder Kernel zu modifizieren, müsste der Angreifer Secure Boot deaktivieren oder neue Signierschlüssel ergänzen, was aber den Wert von PCR7 beeinflusst. Legitime Updates würden hingegen mit den legitimen Schlüsseln signiert, ändern also den PCR7-Wert nicht. Dies gibt den Nutzern deutlich mehr Vertrauen, ihr TPM sicher verwenden zu können, ohne Furcht vor einem Systemzusammenbruch.

Die TPM-Verschlüsselungsschlüssel beschränken sich allerdings nicht auf den Bootvorgang. Admins binden wahlweise auch SSH-Schlüssel an das TPM, was deren Sicherheit erhöht. Denn gelingt es jemandem, den privaten SSH-Schlüssel zu stehlen, kann er sich dennoch nicht auf dem Zielsystem anmelden. Ihm fehlt der Zugriff auf das TPM, um den privaten Schlüssel zu dechiffrieren. Wie sich SSH auf diese Weise konfigurieren lässt, beschreibt ein Blogpost unter [4].

TPMs und DRM

Als Trusted Computing Mitte der 2000er Jahre zuerst auftauchte, löste es bei vielen Beobachtern Besorgnis aus, es könne den Zugriff auf Websites oder Dienste einschränken. Führe der Benutzer die falsche Version von Windows aus, würde ein Prozess namens Remote Attestation den Start des Rechners verhindern.

Tatsächlich bringt jedes TPM einen Schlüssel mit, den so genannten Endorsement Key oder EK. Eine entfernte Website kann das Betriebssystem auffordern Remote Attestation auszuführen. Dann fragt das Betriebssystem das TPM nach den aktuellen PCR-Werten und verschlüsselt sie mit dem EK. Die Remote-Site entschlüsselt sie, prüft die PCR-Werte und entscheidet, ob sie auf Basis dieser Werte den Zugriff gewähren will.

Doch verhindern zwei große Hürden, dass Remote Attestation ein echtes Problem wird. Die erste ist, dass der entfernte Standort wissen muss, ob der EK wirklich vom TPM stammt. Modernere TPMs enthalten ein EK-Zertifikat, das eine Vertrauenskette vom TPM zum TPM-Hersteller darstellt.

Die entfernte Stelle kann so überprüfen, ob die PCR-Werte von einem TPM stammen. Sie erfährt aber nicht, um welches es sich handelt, es sei denn, der Benutzer hat seine Verbindung mit dem Hersteller in irgendeiner Form registriert. Das hängt mit der zweiten Hürde zusammen, die darin besteht, dass nichts einen Benutzer daran hindert, ein zweites TPM in seinem System zu ergänzen. Darüber füttert er die PCRs mit “guten” Werten, um dann Remote Attestation mit dem zweiten TPM zu erlauben.

Infolge dieser Hürden (sowie weiterer Datenschutzbelange) wurde Remote Attestation noch nie außerhalb bestimmter Unternehmens- oder Spezialfälle eingesetzt, und das wird sich wohl auch in Zukunft nicht ändern. Wer sein TPM aktiviert, läuft also nicht Gefahr, die eigene Freiheit einzuschränken.

TPM benutzen

Das TPM zu verwenden setzt ein paar Dinge voraus. Das TPM muss aktiviert sein und der Anwender einen geeigneten Bootloader nutzen, zudem benötigt er die nötigen Userland-Tools.

Das TPM lässt sich im Firmware-Menü des Systems einschalten – wie das im Detail klappt, verrät die Systemdokumentation. Aktuell müssen Bootloader eine modifizierte Version von Grub 2 verwenden, die es unter [5] gibt. Zugleich muss der TPM-Nutzer noch Trousers installieren (TPM-Daemon und Bibliothek) sowie das Paket »tpm-tools«.

Um das TPM in Besitz zu nehmen, gibt der Admin folgenden Befehl ein:

sudo tpm_takeownership -z

Taucht dabei die Fehlermeldung “The TPM target command has been disabled” auf, heißt dies, dass das TPM bereits aktiv ist. Andernfalls lässt sich das TPM zurücksetzen, indem der Admin den folgenden Befehl mit Rootrechten ausführt

echo 14 > /sys/class/tpm/tpm0/ppi/request

und den Rechner neu startet. Die Firmware fragt den Nutzer dann, ob er das TPM leeren will. Es genügt, den Instruktionen zu folgen und später erneut zu versuchen, das TPM zu belegen.

Aktuelle Systeme bringen häufig ein TPM nach Version 2 der Spezifikation mit. Diese gilt nicht nur wegen der moderneren Hashalgorithmen als Verbesserung zum Vorgänger. Leider steckt der Linux-Support für TPM-2-Geräte noch in den Kinderschuhen. Die meiste hier beschriebene Software ist daher nur zur Version 1.2 kompatibel (Abbildung 3).

Abbildung 3: Linux unterstützt nur TPM 1.2 richtig.

Einige Systeme bringen ein TPM der Version 1.2 auf dem Motherboard mit, implementieren aber zugleich ein TPM der Version 2 in Form eines emulierten TPM. Das läuft auf der in die CPU integrierten Management Engine. Hier gilt es, in den Systemeinstellungen nach einem Verweis auf »Intel PTT«, »Intel Platform Trust Technology« oder »Firmware TPM« zu suchen und diese zu deaktivieren.

Einige Hersteller liefern auch ein Hardware-TPM auf dem Motherboard aus, das der Nutzer wahlweise mit den Versionen 1.2 und 2.0 flashen kann – Dell macht dies etwa auf dem XPS 13. Wer ein neues Gerät kauft, erkundigt sich am besten, ob es auch TPM 1.2 beherrscht.

Fazit

Um TPM unter Linux sinnvoll zu nutzen, muss der Admin noch immer viel Handarbeit investieren. Allerdings könnte sich der Aufwand durchaus lohnen. Es gibt zahlreiche Projekte, die momentan daran arbeiten, diese Funktionen in die Distributionen zu integrieren. Ziel ist, dass die Benutzer künftig von diesen Sicherheitsfunktionen profitieren, ohne Experten sein zu müssen.