BitLocker ist Microsofts integrierte Festplattenverschlüsselung und gilt in vielen Unternehmen als Standardmaßnahme zum Schutz mobiler Endgeräte gegen Diebstahl oder sonstigen Verlust. Ohne die richtige Authentifizierung bleibt die Festplatte ein unlesbarer Datenblock.
Doch die Schutzwirkung von BitLocker hängt stark von der konkreten Hardware- und BitLocker-Konfiguration ab. Entscheidend ist, welche Schutzkomponenten (Protectors) für die Freigabe des Schlüsselmaterials konfiguriert sind.
Dieser Artikel betrachtet einen Angriff auf den häufig eingesetzten Transparent Mode, bei dem ausschließlich der TPM-Chip (Trusted Platform Module) als Protector dient und keine zusätzliche Pre-Boot-Authentifizierung wie PIN oder USB-Key erforderlich ist. Auf Laptops, die in dieser Konfiguration einen diskreten TPM-Chip über den SPI-Bus anbinden, lässt sich der sogenannte Volume Master Key (VMK) während des Bootvorgangs im Klartext mitlesen, womit sich die Festplatte entschlüsseln lässt. Der Angriff erfordert dabei keine Softwaremanipulation, keine Exploits und kein Passwort. Ein Raspberry Pi Pico H, ein paar Testhaken-Clips, Dupont-Verbindungskabel und ein paar Minuten physischer Zugang genügen.
Dieser Artikel dokumentiert den vollständigen Ablauf, von der Theorie hinter BitLocker über die Hardware-Verkabelung bis zum funktionierenden Proof of Concept auf einem Dell Latitude 7280, das nicht einmal auf der offiziellen Liste getesteter Geräte für diesen Angriff steht.
Die Grundlage bildet das Open-Source-Projekt pico-tpm-spider sowie der Vortrag „Bypassing BitLocker: Full Disk Decryption for less than $5“ von D0zer und V00t (Echte Namen leider unbekannt) auf der CypherCon 9.0.
Diskreter TPM vs. fTPM
Viele moderne Laptops nutzen inzwischen fTPM (Firmware TPM) von AMD oder Intels PTT (Platform Trust Technology), bei denen die TPM-Funktionalität direkt in die CPU integriert ist. Daten werden in diesem Fall innerhalb des Prozessors verarbeitet und nie über einen externen Bus übertragen, wodurch ein passives Mitlesen auf Hardwareebene nicht möglich ist.
Dell Business-Laptops wie die Latitude-Serie setzen hingegen häufig auf diskrete TPM-Chips, also eigenständige Halbleiterbausteine auf dem Mainboard, die über einen externen Bus mit der CPU kommunizieren. Dell bestätigt den Einsatz diskreter TPMs in den Latitude-, OptiPlex- und Precision-Serien in einem Knowledge-Base-Artikel und begründet diese Designentscheidung mit deren FIPS-140-2-Zertifizierung, dem herstellergebundenen Endorsement Key, konsistentem Verhalten über CPU-Generationen hinweg und der Möglichkeit, Firmware-Updates unabhängig von der CPU einzuspielen.
Zudem verweist Dell auf Sicherheitsrisiken bei Firmware TPMs. Forschende der TU Berlin haben mit dem faulTPM-Angriff gezeigt, dass sich AMDs fTPM über Voltage Fault Injection vollständig kompromittieren lässt, einschließlich des gesamten internen TPM-States. Allerdings erfordert dieser Angriff spezialisierte Hardware, 2 bis 3 Stunden physischen Zugang und erhebliche Expertise, während der in diesem Artikel gezeigte SPI-Sniffing-Angriff mit rund 50 Euro und wenigen Minuten auskommt.
Dell stuft das Risiko des SPI-Sniffing-Angriffs im selben Artikel dennoch als begrenzt ein und begründet dies damit, dass der Angriff direkten physischen Zugang zu den Signalleitungen im Gehäuseinneren, einen versierten Angreifer und eine modellspezifische Anpassung der Technik erfordere. Diese Einschätzung steht im Widerspruch zur zentralen Motivation hinter BitLocker, nämlich dem Schutz gegenüber einem Angreifer mit physischem Zugang, beispielsweise nach einem Laptop-Diebstahl.
Microsoft empfiehlt in der offiziellen BitLocker-Countermeasures-Dokumentation für dieses Angriffsszenario die Konfiguration von TPM+PIN als Pre-Boot-Authentifizierung und räumt ein, dass das Umgehen von TPM-only bei manchen Systemen lediglich das Öffnen des Gehäuses und Löten erfordert.
Zunächst jedoch ein Blick auf den Entschlüsselungsmechanismus von BitLocker.
BitLocker, VMK und FVEK
Das in diesem Artikel verwendete Clientsystem nutzt eine BitLocker-Konfiguration, bei der die Festplattenverschlüsselung ausschließlich durch einen im TPM-Chip gespeicherten Schlüssel geschützt wird (TPM-only).
In dieser Konfiguration gibt der TPM-Chip den Volume Master Key (VMK) während des Bootvorgangs automatisch an den Bootloader frei, ohne dass eine zusätzliche Benutzerauthentifizierung in Form einer Pre-Boot-PIN oder eines Passwortes erforderlich ist. Der VMK wird anschließend verwendet, um den Full Volume Encryption Key (FVEK) zu entschlüsseln, mit dem die Daten auf der Festplatte entschlüsselt werden.
Der Ablauf im Detail:
- Der Laptop wird eingeschaltet. UEFI/BIOS misst die Bootkomponenten und schreibt die Hashes in die PCR-Register des TPM.
- Der Windows Bootloader fordert den VMK vom TPM an. Das TPM prüft die PCR-Werte und gibt den VMK frei, sofern die Integrität stimmt. Bei diskreten TPM-Chips wird der VMK dabei im Klartext über den SPI-Bus übertragen.
- Der VMK entschlüsselt den FVEK.
- Der FVEK entschlüsselt die Festplatte.
Die Kryptografie hinter BitLocker ist solide, die Schwachstelle liegt hier im physischen Key Management.
Das zentrale Problem ist, dass in der Standardkonfiguration (TPM-only, ohne PIN oder USB-Key) der VMK automatisch und ohne Benutzerinteraktion vom TPM an die CPU übergeben wird. Diese Übergabe erfolgt im Klartext über den SPI-Bus und ist damit anfällig für passives Mitlesen auf der physischen Leitungsebene.
Wie SPI-Sniffing funktioniert
Ein diskreter TPM-Chip ist ein separater Integrated Circuit (IC), also ein eigenständiger Halbleiterbaustein auf dem Mainboard, der über einen Bus mit der CPU kommuniziert.
In der Praxis kommen dafür zwei Protokolle zum Einsatz:
- SPI (Serial Peripheral Interface): Synchrone Punkt-zu-Punkt-Verbindung mit separaten Sende- und Empfangsleitungen (Vollduplex).
- LPC (Low Pin Count): Von Intel als Nachfolger des ISA-Bus spezifizierter Multiplexed Bus, der Adress- und Datenleitungen teilt (Halbduplex).
Beide sind auf Hardwareebene zugänglich und nicht verschlüsselt.
Im Gegensatz zum fTPM, der innerhalb der CPU läuft und dessen Kommunikation nie das CPU-Package verlässt, liegen beim diskreten TPM alle Signale auf physisch zugänglichen Leiterbahnen. Dieser Artikel konzentriert sich auf den SPI-basierten Angriff.
Wenn BitLocker den VMK anfordert, sendet das TPM die Antwort als SPI-Transaktion zurück. Diese Transaktion enthält den VMK im Klartext. Ein passiver Sniffer auf dem SPI-Bus liest diese Daten einfach mit, ohne die Kommunikation zu stören oder zu verändern.
Für den Sniffing-Angriff sind fünf Leitungen relevant, die vier SPI-Signale sowie eine gemeinsame Masseleitung (Ground):
- GND (Ground): Gemeinsame Masseleitung zwischen CPU und TPM. Ohne ein geteiltes Referenzpotenzial können die Logikpegel nicht korrekt interpretiert werden.
- MOSI (Master Out, Slave In): Datenleitung von der CPU zum TPM. Hierüber sendet die CPU Befehle und Daten an den TPM.
- MISO (Master In, Slave Out): Datenleitung vom TPM zur CPU. Hierüber sendet der TPM die angeforderten Daten zurück, einschließlich des VMKs.
- CLK (Clock): Taktsignal, das die Kommunikation synchronisiert. Beide Seiten lesen Daten auf den Taktflanken.
- CS (Chip Select): Aktivierungsleitung für den TPM. Im Ruhezustand auf High, der TPM ignoriert den Bus. Zieht die CPU die Leitung auf Low, ist der TPM selektiert und reagiert.
Bei einer einzelnen Transaktion setzt die CPU die Spannung auf der CS-Leitung von 3.3V (High) auf 0V (Low), um den TPM zu selektieren. Anschließend sendet sie über MOSI einen Read-Befehl für ein bestimmtes TPM-Register, und der TPM antwortet mit den angeforderten Daten über MISO. Handelt es sich bei diesen Daten um den VMK, ist der Angriff erfolgreich.
Der klassische Angriff und seine Grenzen
TPM-Sniffing ist kein neuer Angriff. Bisherige Durchführungen erforderten jedoch erheblichen Aufwand:
- Einen Logic Analyzer (In der billigen Variante ab ca 30€ oder professionell ab ca. 1000€, z.B. Saleae Logic)
- Mikrolötkenntnisse zum Verbinden feiner Drähte direkt an die TPM-Pins
- Spezielle Software-Plugins für den Logic Analyzer zur Dekodierung der SPI-Transaktionen sowie viel Geduld und ein insgesamt komplexes Setup.
Ein weiteres Problem stellt der TPM-Chip selbst dar, der auf vielen Laptops schwer zugänglich ist. Er wird gerne auf der Rückseite des Boards oder unter sonstigen Abschirmungen verbaut, um einen physischen Zugriff zu erschweren. Eine direkte Interaktion mit dem TPM-Chip ist in einem realistischen physischen Angriffsszenario daher oft nicht praktikabel.
Der BIOS-Flash-Chip als Zugangspunkt
Eine Lösung liegt in der SPI-Bus-Architektur. Mehrere Geräte teilen sich denselben Bus. Der BIOS/UEFI-Flash-Chip, der die Firmware des Laptops speichert, hängt am gleichen SPI-Bus wie der TPM.
Im Gegensatz zum TPM, ist der Flash-Chip des hier getesteten Dell Latitude 7280 leicht zugänglich. Er ist als standardisiertes SOIC-8 Package mit freiliegenden Pins verbaut, an die sich gewöhnliche Testhaken-Clips einzeln klemmen lassen.
Zudem gibt es nur wenige gängige Chip-Größen, wodurch das Setup über verschiedene Laptops hinweg wiederverwendbar ist.
Am BIOS-Chip liegt jedoch kein CS-Signal des TPM an. Jedes Gerät auf dem SPI-Bus hat seine eigene CS-Leitung, aber am BIOS-Chip ist nur dessen eigene CS-Leitung zugänglich, nicht die des TPM. Ohne CS sieht der Sniffer daher den gesamten SPI-Traffic aller Geräte auf dem Bus und muss die TPM-Transaktionen selbst herausfiltern.
Bisherige TPM-Sniffer
Es gibt mehrere Open-Source-Projekte für TPM-Sniffing auf dem Raspberry Pi Pico. Die bekannteste Referenz ist stacksmashing/pico-tpmsniffer, das allerdings für den LPC-Bus ausgelegt ist und nicht für SPI. Weitere SPI-basierte Projekte existieren, scheitern jedoch an der geforderten Geschwindigkeit. Der Trusted Computing Group Standard schreibt vor, dass TPMs mindestens einen 24 MHz SPI-Takt unterstützen müssen. Die getesteten Dell-Laptops laufen tatsächlich auf 24 MHz. Bisherige Pico-basierte SPI-Sniffer erreichen jedoch maximal rund 20 MHz.
Die Limitierung hat zwei Ursachen:
- Andere Projekte nutzen eine einzelne PIO State Machine (Programmable I/O), um MOSI und MISO gleichzeitig abzutasten. PIO ist ein programmierbarer Hardwarebaustein des RP2040, dem Mikrocontroller auf dem Raspberry Pi Pico, der I/O-Operationen unabhängig von der CPU ausführen kann. Durch die gleichzeitige Abtastung beider Kanäle liegen die Daten verschränkt vor und müssen aufwendig getrennt werden, was CPU-Zeit kostet.
- Die Datenverarbeitung findet CPU-basiert statt. Die Daten werden per Software aus den State Machines gelesen, zwischengespeichert und ausgewertet. Bei 24 MHz und kontinuierlichem Datenstrom ist der RP2040-Prozessor damit überfordert, und Overclocking hilft nur begrenzt.
Die pico-tpm-spider-Architektur
pico-tpm-spider löst jedes dieser Probleme durch vier wesentliche Designentscheidungen:
- Zwei separate PIO State Machines: MOSI und MISO werden von je einer eigenen PIO State Machine synchron abgetastet. Die Daten beider Kanäle liegen von Anfang an getrennt vor und müssen nicht nachträglich entflochten werden.
- DMA-Transfer statt CPU-Reads: Die DMA-Controller des RP2040 übertragen die Daten automatisch von den State Machines in den Speicher. Die CPU ist an diesem Vorgang nicht beteiligt.
- Dual-Core-Parsing: Der RP2040 verfügt über zwei ARM Cortex-M0+ Prozessorkerne, die pico-tpm-spider parallel nutzt. Core 0 identifiziert SPI-Transaktionen, die an den TPM gerichtet sind, und extrahiert die relevanten Daten. Core 1 konzentriert sich ausschließlich darauf, den VMK in diesen Daten zu finden und auszugeben.
- Clock-basierte Transaktionserkennung: Ohne CS-Signal erkennt pico-tpm-spider Transaktionsgrenzen anhand des Clock-Signals. Das PIO-Programm (sniffer.pio) überwacht die Taktfrequenz kontinuierlich. Wenn die Clock-Leitung für eine definierte Zeitspanne inaktiv bleibt, wird das als Ende einer Transaktion gewertet und die Auswertung setzt sich zurück. Das repliziert das Verhalten, das normalerweise die CS-Leitung übernimmt und verhindert, dass ein einzelner verlorener Taktimpuls alle nachfolgenden Daten verfälscht.
Das Ergebnis ist eine zuverlässige Abtastung bei SPI-Taktraten zwischen 10 und 50 MHz. Für den oberen Grenzwert konfiguriert pico-tpm-spider den Systemtakt des RP2040 auf 200 MHz. Dieser Wert liegt innerhalb der offiziellen Spezifikation und wird seit Pico SDK 2.1.1 unterstützt, der Standardtakt des RP2040 beträgt 125 MHz. Die PIO State Machine benötigt mindestens vier Zyklen, um eine einzelne SPI-Taktflanke abzutasten. Daraus ergibt sich der folgende theoretische Oberwert: 200 MHz Systemtakt geteilt durch 4 Zyklen pro Flanke ergibt eine maximale SPI-Abtastrate von 50 MHz.
Dell Latitude 7280
Das pico-tpm-spider Repository listet folgende getestete Geräte:
| Gerät | Bus-Spannung |
| Dell Latitude 5320 | 3.3V |
| Dell Latitude 5430 | ? |
| Dell Latitude 5431 | 3.3V |
| Dell Precision 3490 | 1.8V |
| HP EliteBook 645 G10 | 3.3V |
| HP EliteBook 840 G10 | ? |
Das von uns geprüfte Dell Latitude 7280 taucht in dieser Liste nicht auf. Die Vermutung, dass der Angriff funktioniert, lag dennoch nahe. Die 7280-Serie gehört zur gleichen Dell Business-Linie, nutzt einen diskreten TPM 2.0 und hat einen BIOS-Flash-Chip (Winbond W25Q128JVSQ, SOIC-8 Package) auf dem gleichen SPI-Bus. Der Angriff funktioniert somit auf dem Dell Latitude 7280 ohne jede Modifikation an der Firmware. Der SPI-Bus läuft auf 3.3V.
Die Tabelle zeigt jedoch auch, warum eine pauschale Aussage über die Anfälligkeit einzelner Modelle nicht möglich ist. Die Bus-Spannung variiert zwischen 3.3V und 1.8V, was bei niedrigeren Spannungen den Einsatz eines Level Shifters zwischen Pico und SPI-Bus erfordert.
Die Bus-Spannung von Modellen mit diskretem TPM muss daher vor dem Anschluss des Pico grundsätzlich mit einem Multimeter geprüft werden.
Die Chip-Select-Leitung ist bei keinem der gelisteten Geräte direkt zugänglich, weshalb pico-tpm-spider auf die clock-basierte Transaktionserkennung angewiesen ist. Zudem unterscheiden sich das Boardlayout von Modell zu Modell. Ob und wo die SPI-Leitungen physisch abgreifbar sind, lässt sich nur am konkreten Gerät feststellen.
Benötigte Komponenten für einen Angriff
Folgende Komponenten werden benötigt:
- Raspberry Pi Pico H (vorgelötete Pin Header vereinfachen das Setup nochmals)
- Testhaken-Clips (z.B. IC Hook Clips, 5-6 Stück)
- Dupont-Kabel (Female-to-Female, 5 Stück)
- USB-Kabel (Micro-USB auf USB-A)
- NVMe/NGFF-zu-USB-Adapter
- Linux-System für Build, Flashing und Capturing
Die Gesamtkosten für das Setup liegen je nach Bezugsquellen bei rund 50 Euro. Der Raspberry Pi Pico H kostet etwa 10 Euro, die restlichen Komponenten wie Testhaken-Clips, Dupont-Kabel und ein Micro-USB-Kabel bewegen sich in einer ähnlichen Größenordnung. Der zum Zugriff auf die Festplatte benötigte NVMe/NGFF-zu-USB-Adapter kann zwischen 15-20€ kosten.
Zum Vergleich: Ein Saleae Logic Analyzer, wie er klassisch für diesen Angriff eingesetzt wird, kostet neu und je nach Modell zwischen 500€ und 1620€.
Hinweis zur Bus-Spannung: Der Raspberry Pi Pico arbeitet mit 3.3V-Logikpegeln. Beim Dell Latitude 7280 läuft der SPI-Bus ebenfalls auf 3.3V, ein Level Shifter ist daher nicht erforderlich. Bei anderen Laptops (z.B. Dell Precision 3490 mit 1.8V SPI-Bus) wird ein Level Shifter wie der TXS0108E benötigt.
Bauen und flashen der pico-tpm-spider Firmware
Im Folgenden wird der vollständige Angriffsablauf dokumentiert, von der Vorbereitung der Sniffer-Firmware über die physische Verkabelung bis zum Auslesen des VMK. Im ersten Schritt wird die pico-tpm-spider Firmware aus dem Quellcode kompiliert und als UF2-Image (USB Flashing Format), ein speziell für Mikrocontroller entwickeltes Firmware-Dateiformat, auf den Raspberry Pi Pico übertragen. Voraussetzung ist ein Linux-System mit installierter ARM-Toolchain und dem Raspberry Pi Pico SDK.
Build-Umgebung vorbereiten
Zunächst werden die benötigten Build-Abhängigkeiten und das Pico SDK installiert:
# Abhängigkeiten installieren (Debian/Kali)
sudo apt update
sudo apt install -y cmake gcc-arm-none-eabi libnewlib-arm-none-eabi build-essential libstdc++-arm-none-eabi-newlib git
# Pico SDK klonen
git clone https://github.com/raspberrypi/pico-sdk.git
cd pico-sdk
git submodule update --init
export PICO_SDK_PATH=$(pwd)
cd ..Firmware kompilieren
Anschließend wird das pico-tpm-spider Repository geklont und die Firmware kompiliert:
# Repository klonen
git clone https://github.com/decrazyo/pico-tpm-spider.git
cd pico-tpm-spider
# Build-Verzeichnis erstellen und kompilieren
mkdir build && cd build
cmake ..
makeNach erfolgreichem Build liegt die Datei pico-tpm-spider.uf2 im build-Verzeichnis.
Der fertige Build kann ebenfalls von unsererem Github Repository „pentestfactory/pico-tpm-spider“ heruntergeladen werden.
Flashen der Firmware
Der Raspberry Pi Pico wird im USB-Bootloader-Modus angeschlossen. In diesem Modus erscheint der Pico als USB-Massenspeicher und akzeptiert UF2-Firmware-Images per Drag-and-Drop oder Kopierbefehl:
- Den BOOTSEL-Button auf dem Pico gedrückt halten.
- Während BOOTSEL gedrückt ist, den Pico per USB anschließen.
- Der Pico erscheint als USB-Massenspeicher (z.B. RPI-RP2).
- Die .uf2-Datei auf das Laufwerk kopieren:
cp build/pico-tpm-spider.uf2 /media/$USER/RPI-RP2/Verkabelung: Pico H zu BIOS-Flash-Chip
Die Testhaken-Clips werden einzeln an die relevanten Pins des BIOS-Flash-Chips (Winbond W25Q128JVSQ) angeklemmt.
Die Verbindungen zum Pico H sind:
| Pico Pin | SPI-Signal | Flash Pin | Kabelfarbe |
| Pin 1 (GP0) | MOSI | Pin 5 – DI (Data In) | Blau |
| Pin 2 (GP1) | MISO | Pin 2 – DO (Data Out) | Grün |
| Pin 3 (GND) | GND | Pin 4 – GND | Grau |
| Pin 4 (GP2) | CLK | Pin 6 – CLK | Gelb |
| Pin 5 (GP3) | (Bridge auf Pin 8) | – | Orange |
| Pin 8 (GND) | (Bridge auf Pin 5) | – | Orange |
Pin 1 des BIOS-Flash-Chips ist durch einen kleinen Punkt auf dem Chip markiert (hier oben links). Bei SOIC-8 Packages zählen die Pins gegen den Uhrzeigersinn von Pin 1 aus.
Pico Pin 5 (GP3) auf Pico Pin 8 (GND) gebrückt: Da das CS-Signal des TPM auf dem Dell Latitude 7280 nicht separat zugänglich ist, wird GPIO 3 (Kabelfarbe Orange) direkt mit einem GND-Pin des Pico verbunden. Das signalisiert der Firmware ohne CS zu arbeiten und stattdessen die Clock-basierte Transaktionserkennung zu nutzen.
Proof of Concept: VMK Recovery und Festplattenentschlüsselung
Schritt 1: Testhaken-Clips anschließen
Die Testhaken-Clips werden einzeln an die relevanten Pins des Winbond W25Q128JVSQ Flash-Chips auf dem Mainboard des Dell Latitude 7280 angeklemmt. Pin 1 des Chips ist durch die Punkt-Markierung auf dem IC identifizierbar. Dabei ist darauf zu achten, dass die Clips sauber auf den jeweiligen Pins sitzen und die Kabel nicht unter mechanischer Spannung stehen. Ein schlechter Kontakt führt zu fehlerhaften Lesevorgängen.
Schritt 2: Seriellen Monitor starten
Nachdem die Testhaken-Clips mit dem SPI-Bus verbunden sind, wird der Pico per USB an das Angreifer-System angeschlossen. Der Sniffer startet automatisch, sobald er mit Strom versorgt wird, und gibt die abgetasteten SPI-Daten als serielle Ausgabe aus:
picocom -q /dev/ttyACM0 -b 115200
Der Pico meldet sich als ttyACM-Gerät.
Schritt 3: Laptop booten und VMK abfangen
Den Dell Latitude 7280 einschalten. Sobald BitLocker den VMK vom TPM anfordert und dieser über den SPI-Bus gesendet wird, parst pico-tpm-spider die Transaktion und gibt den VMK aus:
Schritt 4: VMK in Binärdatei umwandeln
Den ausgegebenen Hex-String in eine Binärdatei konvertieren:
echo "818F89...637" | xxd -r -p > vmk.bin
Schritt 5: Festplatte ausbauen
Um die Daten der verschlüsselten Festplatte zu entschlüsseln, wird der Ziel-Laptop zunächst sauber heruntergefahren und die Festplatte ausgebaut. Über einen NVMe/NGFF-zu-USB-Adapter kann die Laptop-Festplatte an das Angreifer-System angeschlossen werden.
Wird das Angreifer-System als virtuelle Maschine betrieben, muss der USB-Controller in VMware auf USB 3.1 (xHCI) konfiguriert sein, da NVMe-zu-USB-Adapter über USB 2.0 manchmal nicht korrekt erkannt werden.
Schritt 6: BitLocker-Volume entschlüsseln
Nachdem die Festplatte des Ziel-Laptops über den USB-Adapter am Angreifer-System erkannt wurde, erfolgt die Entschlüsselung in zwei Schritten. Zunächst entschlüsselt dislocker das BitLocker-Volume mit dem extrahierten VMK und legt eine virtuelle Datei an, die das entschlüsselte Volume repräsentiert. Anschließend wird diese Datei als NTFS-Dateisystem gemountet, um auf die Windows-Daten zugreifen zu können.
# dislocker installieren (falls nötig)
sudo apt install -y dislocker
# Partition identifizieren
lsblk
# Mountpoints anlegen
sudo mkdir -p /mnt/bitlocker /mnt/windows
# BitLocker-Volume mit dem extrahierten VMK entschlüsseln
sudo dislocker -K vmk.bin /dev/sdc3 /mnt/bitlocker
Die Partition „/dev/sdc3 bildet“ hier die verschlüsselte Windowspartition ab und muss entsprechen abgeändert werden. Nach der Entschlüsselung liegt im Verzeichnis /mnt/bitlocker eine Datei namens dislocker-file.
Schritt 7: Entschlüsseltes Volume mounten
Die von dislocker erzeugte dislocker-file ist ein virtuelles Block Device, dass die entschlüsselten Daten repräsentiert, aber noch kein zugängliches Dateisystem darstellt. Im nächsten Schritt wird diese Datei als NTFS-Dateisystem gemountet, um die enthaltenen Daten navigierbar zu machen:
# Entschlüsseltes Volume als NTFS-Dateisystem mounten
sudo mount -t ntfs-3g -o remove_hiberfile,recover /mnt/bitlocker/dislocker-file /mnt/windows
Das NTFS-Dateisystem ist jetzt unter /mnt/windows verfügbar. Der Angreifer hat nun vollen Lese- und Schreibzugriff auf alle Dateien der Windows-Installation.
Von hier aus können Daten extrahiert, Malware platziert oder beliebige Änderungen am System vorgenommen werden. Die Festplatte verhält sich wie ein normaler, unverschlüsselter Datenträger.
Gegenmaßnahmen
Microsoft ist sich des Problems bewusst. Die TPM-2.0-Spezifikation sieht mit Parameter Encryption eine Lösung vor.
Damit würden alle schützenswerten Daten auf dem SPI-Bus verschlüsselt übertragen, und der VMK wäre auch beim Mitlesen unbrauchbar. Der Linux-Kernel nahm TPM2 Parameter Encryption mit Version 6.10 (2024) in den Mainline-Kernel auf und nutzt HMAC-Sessions mit verschlüsselten Parametern, um die Bus-Kommunikation abzusichern. Die ersten Patches dafür wurden bereits 2018 eingereicht, brauchten jedoch sechs Jahre bis zur Aufnahme. Mit Kernel 6.18 wurde das Feature aufgrund von Stabilitätsproblemen allerdings wieder standardmäßig deaktiviert und muss seitdem manuell über die Kernel-Konfiguration aktiviert werden. Die technische Lösung existiert also auf Spezifikationsebene, erweist sich in der Praxis aber selbst unter Linux als noch nicht ausgereift. Microsoft hat Parameter Encryption in BitLocker bislang nicht implementiert, obwohl das Unternehmen selbst an der TPM-Referenzspezifikation beteiligt ist.
Bis Parameter Encryption in BitLocker implementiert wird, bleiben folgende Gegenmaßnahmen:
- Pre-Boot-Authentifizierung aktivieren: Eine BitLocker-PIN (TPM + PIN) oder ein USB-Startup-Key (TPM + USB) verhindert, dass der VMK allein durch den TPM-Bootprozess freigegeben wird. Ohne die korrekte PIN wird der VMK nie über den SPI-Bus übertragen. Das ist die effektivste und einfachste Maßnahme, die sich per Gruppenrichtlinie unternehmensweit ausrollen lässt.
- fTPM / Intel PTT verwenden: Wird im BIOS von diskretem TPM auf fTPM/PTT umgestellt, findet die gesamte TPM-Kommunikation innerhalb der CPU statt. Der VMK wird nie über einen externen Bus übertragen und ist damit nicht durch passives Mitlesen abgreifbar. Diese Umstellung erfordert in der Regel jedoch eine Neuverschlüsselung des Volumes und kann in Unternehmensumgebungen problematisch sein, die auf eine FIPS-140-Zertifizierung des TPM angewiesen sind, da Firmware TPMs diese Zertifizierung in der Regel nicht besitzen.
Fazit
BitLocker in der TPM-only-Konfiguration bietet auf Systemen mit diskretem TPM keinen wirksamen Schutz gegen einen physischen Angreifer mit minimalem Budget. Das hier gezeigte Setup kostet unter 50 Euro (Stand 2026), erfordert keine professionellen Elektronikkenntnisse und liefert innerhalb weniger Minuten vollständigen Zugriff auf eine verschlüsselte Festplatte.
Das Dell Latitude 7280 steht exemplarisch für eine ganze Klasse von Business-Laptops, die diskrete TPM-Chips über den SPI-Bus anbinden. Die Tatsache, dass das Gerät nicht auf der offiziell getesteten Liste von pico-tpm-spider steht, unterstreicht, dass jeder Laptop mit diskretem SPI-TPM potenziell betroffen ist. Es gibt keinen Grund anzunehmen, dass andere Hersteller eine Ausnahme bilden.
Die technische Lösung existiert auf Spezifikationsebene seit Jahren: TPM Parameter Encryption. Selbst der Linux-Kernel kämpft jedoch noch mit einer stabilen Implementierung. Microsoft hat das Feature in BitLocker bislang nicht implementiert.
Bis sich das ändert, bleibt die Pre-Boot-PIN die einfachste und effektivste Gegenmaßnahme. Sie kostet nichts, lässt sich in Minuten konfigurieren und macht den gesamten Angriff wirkungslos. In Unternehmensumgebungen lässt sich die TPM+PIN-Konfiguration über die Gruppenrichtlinie Require additional authentication at startup zentral erzwingen. Die Einrichtung des PINs auf den Endgeräten erfolgt dann je nach Infrastruktur über manage-bde, PowerShell, Microsoft Intune oder SCCM mit MBAM (Microsoft BitLocker Administration and Monitoring).
Referenzen
- pico-tpm-spider (GitHub): VMK Recovery Tool für SPI-basierte TPM 2.0 Chips
- pentestfactory/pico-tpm-spider (GitHub): Kompilierte pico-tpm-spider Firmware
- Bypassing BitLocker: Full Disk Decryption for less than $5, D0zer & V00t, CypherCon 9.0
- stacksmashing/pico-tpmsniffer (GitHub): TPM-Sniffing für LPC-Bus
- dislocker (GitHub): BitLocker-Entschlüsselung unter Linux
- Dell Response to TPM Interposer BitLocker Research: Dells offizielle Stellungnahme zum SPI-Sniffing-Angriff
- BitLocker Countermeasures (Microsoft): Microsofts Dokumentation zu BitLocker-Gegenmaßnahmen
- Require additional authentication at startup (Microsoft): GPO-Konfiguration für TPM+PIN
- faulTPM: Exposing AMD fTPMs’ Deepest Secrets: Voltage Fault Injection gegen AMDs fTPM, TU Berlin (2023)
- Linux Default Disable TPM2 HMAC (Phoronix): Deaktivierung der TPM2 Parameter Encryption im Linux-Kernel 6.18
- FIPS 140-3 Development (NIST): Aktueller NIST-Standard für kryptografische Module