TPM-Sniffing-Angriffe gegen Nicht-Bitlocker-Ziele

Letztes Jahr, als die Medienaufmerksamkeit für die Sicherheit von Trusted Platform Modules (TPM) zunahm, ausgelöst durch einen Blogbeitrag der Dolos Group, in dem ein Sniffing-Angriff auf Windows Bitlocker beschrieben wurde, der sich auf ein TPM stützt, bat uns ein Kunde, seine TPM-basierte Full Disk Encryption (FDE) im Hinblick auf diese Art von Angriff zu untersuchen. Die darauf folgenden Untersuchungen und Kommentare, wie der Beitrag der Dolos Group, scheinen sich auf TPMs zu konzentrieren, wie sie von Windows Bitlocker verwendet werden [1], [2], [3], [4]. Wir hielten es daher für interessant, dieses Szenario auf andere TPM-Anwendungsfälle auszudehnen.

In diesem Blogbeitrag erfahren Sie mehr über:

1. Der Hintergrund des Trusted Platform Module (TPM)
2. Unser Bedrohungsmodell
3. Untersuchung
4. IoT und TPMs
5. Überlegungen für Red Teaming
6. Defensive Empfehlungen

Hintergrund

Ein Trusted Platform Module (TPM) ist in der Regel ein spezieller sicherer Kryptoprozessor, der dem ISO/IEC 11889-Standard der Trusted Computing Group (TCG) entspricht. TPMs können für verschiedene Zwecke eingesetzt werden, von der Plattformintegrität und FDE-Unterstützung bis hin zur Speicherung von Schlüsselmaterial und Anmeldedaten (z.B. für die SSH-Authentifizierung). TPMs können in verschiedenen Plattformen eingesetzt werden, von Servern und Laptops bis hin zu mit der Cloud verbundenen IoT-Geräten.

Es gibt zwei Hauptversionen des Standards, TPM 1.2 und TPM 2.0, wobei die letztere nicht abwärtskompatibel mit der ersteren ist. TPMs können auf unterschiedliche Weise implementiert werden (wobei dTPMs und fTPMs die gängigsten sind):

• Diskrete TPMs (dTPM): Diese werden in Form eines speziellen, manipulationssicheren Chips geliefert.
• Integrierte TPMs: Diese sind als Hardware-Subsystem in einem anderen Chip implementiert.
• Firmware-TPMs (fTPMs): Sie sind Firmware-basiert und laufen normalerweise in der vertrauenswürdigen Ausführungsumgebung (TEE) einer CPU.
• Hypervisor-TPMs (vTPMs): Diese sind von einer virtuellen Maschine getrennt, indem sie auf einem Hypervisor laufen.
• Software-TPMs: Sie sind rein softwarebasiert und die am wenigsten sichere Implementierung.

Für die Integrität der Plattform bieten TPMs Mechanismen zur Unterstützung von Measured Boot. Ausgehend von einem Core Root of Trust for Measurement (CRTM) (z.B. dem Boot-ROM eines SoC) werden Hashes von verschiedenen Plattformkomponenten (z.B. BIOS/UEFI, Bootloader, eingebettete Controller-Firmware usw.) berechnet und in den Slots des Platform Configuration Register (PCR) gespeichert. Diese Informationen können in den sicheren Boot-Prozess integriert werden (möglicherweise als Teil von FDE), um sicherzustellen, dass diese verschiedenen Komponenten nicht manipuliert wurden.

TPMs bieten auch Mechanismen zur Unterstützung von Verschlüsselungslösungen, um die Vertraulichkeit und Integrität der Authentifizierung zu gewährleisten. Zu diesen Mechanismen gehören die Schlüsselgenerierung, die Möglichkeit, Schlüsselmaterial mit einem TPM-spezifischen Schlüssel zu verschlüsseln, und manipulationssichere Funktionen, die das TPM zu einem sicheren Speicher für Geheimnisse machen. Die Verwendung eines TPM-geschützten Schlüssels an sich wird in der Regel als Bindung bezeichnet, während das Hinzufügen von gemessenen Boot-PCR-Werten in den kryptografischen Mix in der Regel als Versiegelung bezeichnet wird.

In Verschlüsselungsszenarien können TPMs in der Regel in einem von mehreren Modi konfiguriert werden:

• Nur TPM: In diesem Fall liefert das TPM der Verschlüsselungslösung auf Anfrage (z.B. beim Booten) automatisch den Schlüssel.
• TPM + PIN: In diesem Fall benötigt das TPM ein vom System bereitgestelltes Geheimnis (in der Regel eine vom Benutzer eingegebene PIN), bevor es den Schlüssel entsperren kann.
• TPM + PIN + MFA: Hier ist ein zusätzlicher Faktor erforderlich, wie z.B. ein USB-Schlüssel mit einem Geheimnis oder TOTP.

Im Falle von FDE müssen zusätzliche Geheimnisse vor dem Start bereitgestellt werden. Manipulationssichere Funktionen auf dem TPM (sollten) das Erzwingen von PINs, das Extrahieren privater Schlüssel und die Umgehung dieser Funktionen durch Störung verhindern.

Während es in der Vergangenheit invasive Sondierungen, verschiedene Seitenkanal-, Interposer- sowie Design- und Implementierungsangriffe auf TPMs gegeben hat, werden wir uns in diesem Beitrag nur auf Sniffing-Angriffe gegen dTPMs in FDE-Unterstützungsszenarien konzentrieren, da diese Arten von Angriffen mit dem Design von dTPMs verbunden sind.

Da es sich bei dTPMs um dedizierte Chips handelt, die von der Haupt-CPU und anderen Controllern auf einem Gerät getrennt sind, benötigen sie eine Möglichkeit, mit diesen zu kommunizieren. Der Standard spezifiziert zu diesem Zweck die LPC-, I2C- und SPI-Busse. Das dTPM muss zusammen mit allen Geräten, die mit ihm kommunizieren müssen, an einen Bus angeschlossen werden (je nachdem, ob es eine Single- oder Multi-Master-Rolle gibt).

Etwas vereinfacht ausgedrückt, übernimmt die CPU bei der Einrichtung der Verschlüsselung das Eigentum am TPM, konfiguriert es und sendet einen Schlüssel an das TPM zur Bindung oder Versiegelung. Das TPM verschlüsselt diesen Schlüssel mit Authentifizierungsdaten, seinem eigenen geheimen Schlüssel und optionalen PCR-Messungen und sendet den verschlüsselten Schlüsselblob zurück. Dieser Blob wird dann irgendwo gespeichert (normalerweise als Teil eines verschlüsselten Volume Headers). Bei der Entschlüsselung sendet die CPU den verschlüsselten Schlüsselblob an das TPM. Die Authentifizierungsdaten und optionalen Messungen werden vom TPM abgerufen und zusammen mit seinem geheimen Schlüssel zur Entschlüsselung des Blob verwendet. Der Klartextschlüssel wird zur Verwendung an die CPU zurückgeschickt.

Daher kann der Klartextschlüssel irgendwann während des Entschlüsselungsprozesses im Klartext über den Bus an die CPU gesendet werden. Der TPM 2.0-Standard erlaubt zwar die so genannte"Parameterverschlüsselung", aber diese Funktion wird nur selten von Verschlüsselungslösungen implementiert und bringt, wie Trammell Hudson betont, das Henne-Ei-Problem des Vertrauensaufbaus ohne die Möglichkeit, Geheimnisse auf der Haupt-CPU zu speichern, mit sich.

Bedrohungsmodellierung

Unser Bedrohungsmodell ging von der Annahme aus, dass ein Angreifer für eine begrenzte Zeit physischen Zugang zu einem Gerät hat, das eine dTPM-unterstützte FDE-Lösung verwendet. Dabei wurde davon ausgegangen, dass die Bereitstellung/Inbetriebnahme erfolgt ist und die fraglichen Daten verschlüsselt wurden. Während eine ganze Reihe anderer Bedrohungen in diesen Bereich fallen, haben wir uns speziell auf das Schnüffeln des TPM-Busses konzentriert, da PCR-Messungen für dieses Szenario irrelevant sind.

Untersuchung

Während unserer Untersuchung haben wir Windows 10 Bitlocker mit TPM mit verschiedenen Linux-basierten FDE-Implementierungen verglichen, nämlich: systemd-cryptsetup, clevis, luks-tpm2, safeboot und coreboot. Bei dem fraglichen TPM handelte es sich um ein Infineon OPTIGA SLB 9670 TPM 2.0 Modul mit einer SPI-Schnittstelle (obwohl dieses Szenario natürlich auch mit I2C und LPC funktioniert, wie wir bereits gezeigt haben).

Wie wir sehen können, wird die Parameterverschlüsselung in der Praxis einfach nicht verwendet, und mit Ausnahme von safeboot erzwingt keine der Lösungen standardmäßig PIN/MFA. Wir haben uns pureboot, U-Boot, tboot und TrustedGRUB2 zwar nicht im Detail angesehen, aber wir vermuten, dass hier ähnliche Ergebnisse vorliegen.

Um anderen dabei zu helfen, die Durchführbarkeit von TPM-Sniffing-Angriffen gegen Linux-basierte FDE-Implementierungen zu bewerten und zu demonstrieren, habe ich zwei Saleae Logic 2 Plugins entwickelt, wie unten gezeigt. Sie sind auf Github verfügbar.

Alle Lösungen, die wir untersucht haben, basieren auf dem Linux Unified Key Setup (LUKS). LUKS2-Volumes haben einen Header mit einem Keyslot-Bereich, der verschiedene Keyslots für verschiedene Passwörter oder Schlüsseldateien enthält, die zur Entschlüsselung des Volumes verwendet werden können. Diese Keyslot-Einträge enthalten Informationen zur Schlüsselableitung wie Priorität, Schlüsselableitungsfunktion, Parameter, Salt und Verschlüsselungsalgorithmus. Ein verschlüsselter Hauptschlüssel (MK), der in Anti-Forensik-Stripes (AF) gespeichert ist, wird dann mit Hilfe des abgeleiteten Schlüssels entschlüsselt.

Um LUKS zusammen mit einem TPM zu verwenden, nutzen die meisten Lösungen (system-cryptsetup, safeboot, luks_tpm2) die tpm2-tools, eine Art BusyBox-ähnliches Toolkit für die Interaktion mit dem TPM2 Software Stack (TSS) der Trusted Computing Group (TCG).

In systemd-cryptsetup wird ein TPM-Token registriert und mit einem LUKS2-Schlüsselslot verknüpft. Mit dem Befehl `cryptsetup luksDump /dev/sda1 --debug-json` können wir sehen, dass der Token einen base64-kodierten tpm2-blob-Eintrag enthält, der zum Entsiegeln an das TPM gesendet wird. Der Entsiegelungsverkehr ist auf einem SPI-Bus ziemlich leicht zu erkennen und besteht aus einer TPM_READ-Operation auf TPM_DATA_FIFO_0 (d40024) mit einer Datenstruktur, die aus einem DWORD mit dem Wert 00000022 besteht, gefolgt von einem Längenfeld in der Größe eines WORD (typischerweise der Wert 0020) und dem anschließenden 256-Bit-Schlüssel.

Mein Saleae Logic-Plugin formatiert den Schlüssel für die Ausgabe von LUKS-Schlüsseldateien:

Das Einbinden eines Datenträgers kann mit `cryptsetup open ./sda1-luks myvolumename --key-slot 1 --key-file ./mykey --keyfile-size 44` durchgeführt werden.

luks-tpm2 funktioniert zwar etwas anders, kann aber Schlüssel in einer versiegelten Datei auf der Festplatte oder im TPM-NVRAM speichern und unterstützt Passphrasen zum Entsiegeln. Der Entsiegelungsvorgang sieht über den SPI-Bus genauso aus, und das Plugin funktioniert auch hier. Safeboot scheint von den untersuchten Lösungen die robusteste zu sein, da es den Benutzer standardmäßig zur Verwendung der PIN zwingt, und funktioniert unter der Haube etwas anders, aber das tpm2-tools-Plugin funktioniert auch hier.

Clevis ist ein pluggbares automatisches Entschlüsselungs-Framework mit einer Reihe von 'Pins' (nicht zu verwechseln mit einer PIN), wobei jeder Pin die Kryptounterstützung über ein anderes Backend implementiert. Zur Verschlüsselung nimmt Clevis einige Daten und eine JSON-Konfiguration, um ein JSON Web Encryption (JWE)-Objekt zu erzeugen, das Daten enthält, die mit einem JSON Web KEY (JWK) und einigen Metadaten verschlüsselt wurden. Bei der Entschlüsselung holt sich Clevis den Schlüssel aus dem JWK und den Metadaten und entschlüsselt den Chiffriertext aus dem JWE.

Der Clevis tpm2 'pin' erzeugt einen JWK, erstellt ein Objekt im TPM mit dem JWK als geheime Daten und bindet oder versiegelt es an das TPM. Der resultierende JWE (der mit einem LUKS2-Schlüsselsteckplatz verbunden ist) enthält sowohl die öffentlichen und versiegelten sensiblen Teile des erstellten Objekts als auch entsiegelungsbezogene Metadaten. Bei der Entschlüsselung nimmt der tpm2 'Pin' das JWE, lädt es in das TPM, entsiegelt den JWK und entschlüsselt den Chiffriertext im JWE.

Aufgrund dieses Ansatzes sieht der TPM-SPI-Verkehr ein wenig anders aus. Was wir suchen, ist eine TPM_READ-Operation auf TPM_DATA_FIFO_0 (d40024) mit einer Datenstruktur, die aus einem DWORD mit dem Wert 00000072 besteht, gefolgt von einem variablen Längenfeld der Größe WORD, gefolgt von einem Haufen JSON-Daten.

Mein Saleae Logic Plugin validiert das JSON und extrahiert den Schlüssel und die relevanten Metadaten:

IoT und TPMs

IoT-Geräte fallen häufig unter das typische Bedrohungsmodell des "physischen Zugriffs durch einen Angreifer", insbesondere bei Geräten, die an öffentlichen Orten eingesetzt werden oder bei denen der Benutzer ein potenzieller Angreifer ist. Verschiedene damit zusammenhängende Anwendungsfälle erfordern eine Art von vertrauenswürdigen Sicherheits-Subsystemfunktionen wie Geräteauthentifizierung, Identifizierung, sichere Wartung, Fernbescheinigung und Schutz von Daten im Ruhezustand und bei der Übertragung.

Während viele IoT-Geräte sichere Koprozessoren verwenden, die nicht dem TPM-Standard entsprechen, können sowohl AWS- als auch Azure-Plattformen für die sichere Gerätebereitstellung und den Schutz von Token/Credentials verwendet werden.

Wie unten dargestellt, ist der Azure-Ansatz für Windows 10 IoT Core ziemlich typisch für diesen Anwendungsfall. Hier wird während des Bereitstellungsprozesses ein gemeinsamer Zugriffsschlüssel (SAK) zwischen dem IoT-Gerät und der Cloud eingerichtet, indem der Cloud die öffentlichen Teile des Endorsement Key (EK) und des Storage Root Key (SRK) des TPMs zur Verfügung gestellt werden. Der SAK wird auf der Geräteseite in das TPM eingeprägt, während auf der Cloud-Seite das physische Gerät mit einer Geräte-ID im Cloud Device Hub verknüpft wird. Weiter wird ein SAS-Token (Shared Access Signature) generiert, der eine mit bestimmten Richtlinien verbundene Zugriffsanforderung angibt. Dieses Token wird vom TPM unter Verwendung eines mit dem SAK verschlüsselten HMAC signiert.

Die Windows 10 IoT Core TPM-Implementierung verwendet ebenfalls keine Parameterverschlüsselung. Daher könnte der SAK während der Bereitstellung abgefangen werden (was kein besonders beunruhigendes Szenario ist) und SAS-Tokens könnten während des Betriebs abgefangen werden. Je nach dem Bedrohungsmodell des Geräts könnte letzteres ein Problem darstellen. Darüber hinaus könnte ein Angreifer mit physischem Zugriff auf das IoT-Gerät das TPM einfach dazu auffordern, beliebige Daten zu signieren, indem er sich in den Bus einschaltet oder das TPM ganz entfernt.

Die Verteidigung gegen diese Art von Bedrohungen in IoT-Geräten wird dadurch erschwert, dass die Access Control für das TPM in Form einer PIN kompliziert ist, da in der Regel keine Benutzerinteraktion während des Betriebs erforderlich ist (oder überhaupt nicht vertrauenswürdige Benutzer). Und die einfache Speicherung der PIN zur automatischen Eingabe durch die Haupt-CPU führt zu einem Henne-Ei-Problem. Daher bieten sich für TPM-geschützte IoT-Geräte, bei denen physischer Zugriff ein Problem darstellt, zwei ergänzende Verteidigungslinien an:

• Diversifizierung und Widerrufbarkeit. Um die Auswirkungen kompromittierter Geheimnisse zu begrenzen, sollten sie bei der Bereitstellung für jedes Gerät diversifiziert werden, so dass die Kompromittierung eines einzelnen Geräts nicht auf die gesamte Flotte im Stil von pwn-once, exploit everywhere übergreifen kann. Darüber hinaus sollten Authentifizierungsgeheimnisse widerrufbar sein, so dass defensive Telemetriedaten verwertbar werden.

• Manipulationssicherheit. Da TPMs nicht direkt an externe Manipulationsschalter angeschlossen werden können, sollten sie in ein geschütztes Subsystem integriert werden, bei dem die Aktivierung eines Manipulationsschalters sofort das Löschen des TPM-Geheimnisses auslöst. Im Idealfall löst die Aktivierung des Manipulationsschalters auch Backend-Warnungen aus, so dass Widerrufsprozesse eingeleitet werden können.

Überlegungen für Red Teaming

Die Durchführung eines TPM-Sniffing-Angriffs in der Praxis ist nicht ganz dasselbe wie unter Laborbedingungen. TPM-Sniffing-Angriffe gegen FDE-Lösungen können ein mächtiges Werkzeug im Arsenal eines Red Teams sein und passen in eine breite Palette von Bedrohungsmodellen wie physische Angreifer mit Zugang vor Ort, unbeaufsichtigte/gestohlene Laptops, schurkische Insider und Unterbrechung der Lieferkette. Allen diesen Szenarien ist jedoch gemeinsam, dass das Zeitfenster, in dem Red Teaming-Angreifer ihren Angriff implementieren können, begrenzt ist. Ein gewisses Maß an Heimlichkeit ist erforderlich. Wenn Sie also völlig blind hineingehen und eine halbe Stunde lang herumfummeln, während Sie nur ein paar Minuten geplant haben, und einen eilig zusammengebauten Laptop zurücklassen, ist dies in der Praxis schwieriger zu bewerkstelligen als aus rein technischen Gründen.

Die Abwehr eines zusätzlichen Faktors wird in der Praxis nicht trivial sein. Zwei mögliche Wege sind Bootkit-basierte Manipulations- und Umkehrangriffe und das Hinterlassen eines winzigen Hardware-Implantats mit Bus-Sniffing-Fähigkeiten auf dem Motherboard. Nach der Eingabe des zusätzlichen Faktors und der Entsiegelung des TPM-Geheimnisses könnte das Implantat dieses entweder für einen späteren physischen Abruf speichern oder es möglicherweise über eine integrierte Kommunikationsfunktion (RF, 4G usw.) exfiltrieren, je nach verfügbarem Platz und Miniaturisierungsmöglichkeiten. Trammell Hudson hat auf der 35C3 einen großartigen Vortrag zu diesem Thema für einen ähnlichen Anwendungsfall gehalten.

Defensive Empfehlungen

Zu diesem Thema gibt es eine Menge solider Ratschläge zur Verteidigung, unter anderem von Microsoft[1],[2], aber im Allgemeinen läuft die Absicherung von TPM-basierten FDE-Lösungen auf die folgenden Prinzipien hinaus:

• Setzen Sie einen zusätzlichen Faktor wie eine PIN, ein Passwort oder TOTP ein, um die Entsiegelung des TPMs zu regulieren.
• Verwenden Sie nach Möglichkeit ein fTPM anstelle eines dTPMs.
• Konfigurieren Sie das TPM für eine gemessene Boot-Integration in die FDE-Konfiguration, um sich vor Firmware-Bedrohungen zu schützen.
• Setzen Sie manipulationssichere Sicherheitssiegel auf sensiblen Geräten ein (wobei das Ausmaß, in dem dies hilft, stark variiert).

Was nun?

Möchten Sie nach der Lektüre dieses Blogs mehr über unser Red Teaming oder unsere Security Assessments erfahren? Kontaktieren Sie uns einfach.