BSI-Studie: TPM-Festplattenverschlüsselung lässt sich umgehen – ohne PIN

Ein Notebook geht verloren oder wird gestohlen – und die Festplattenverschlüsselung soll genau für diesen Fall sorgen, dass niemand an die Daten kommt. Das Bundesamt für Sicherheit in der Informationstechnik (BSI) hat am 11. November 2026 eine Studie veröffentlicht (öffnet in neuem Tab), die genau an dieser Annahme rüttelt: „Active and Passive Attacks against TPM2-based Full Disk Encryption" zeigt mehrere praktisch erprobte Wege, wie sich die TPM2-gestützte Festplattenverschlüsselung unter Windows 11 und Linux umgehen lässt – vorausgesetzt, ein Angreifer hat physischen Zugriff auf das Gerät. Für Unternehmen mit mobilen Geräten im Einsatz – Vertriebs-Notebooks, Außendienst-Tablets, Laptops im Homeoffice – ist das kein theoretisches Thema, sondern eine Frage der aktuellen Konfiguration.

Was die Studie konkret zeigt

Trusted Platform Module Version 2.0 (TPM2) gilt als Standard-Baustein für Festplattenverschlüsselung: Windows 11 setzt laut Microsoft (öffnet in neuem Tab) einen TPM-2.0-Chip ohnehin voraus, und sowohl BitLocker unter Windows als auch LUKS unter Linux können den im Chip gespeicherten Schlüssel automatisch beim Systemstart freigeben. Genau diese bequeme Automatik hat das BSI unter die Lupe genommen.

Die Studie unterscheidet laut BSI-Darstellung der Studie (öffnet in neuem Tab) zwei Angriffsklassen:

• Passive Angriffe: Der Angreifer liest die Kommunikation zwischen TPM-Chip und Prozessor mit – etwa, indem er bei einem separat verbauten TPM-Chip (dTPM) Kontaktnadeln an den Datenleitungen anbringt und so den Schlüssel direkt mitschneidet.
• Aktive Angriffe: Der Angreifer manipuliert eine beteiligte Komponente, etwa durch Eingriffe in die UEFI-Firmware, um eine nachgelagerte Sicherheitsmaßnahme gezielt abzuschalten.

Bemerkenswert ist laut BSI, dass aktive Angriffe nicht auf separate TPM-Chips beschränkt bleiben: Sie funktionieren laut der Studie ebenso gegen in die CPU integrierte Firmware-TPMs (fTPMs), die in vielen aktuellen Prozessoren stecken und als die modernere, vermeintlich robustere Variante gelten. Ein Teil der gezeigten Angriffe war dabei sogar erfolgreich, obwohl die in den TPM2-Spezifikationen vorgesehene Schutzmaßnahme „Parameter Encryption" aktiv war – die also genau für solche Fälle gedacht ist.

Diese Ergebnisse reihen sich laut it-daily.net (öffnet in neuem Tab) in eine länger bekannte Problematik ein: Bereits in der Vergangenheit hatten Sicherheitsforscher gezeigt, dass sich BitLocker-Schlüssel bei Systemen ohne PIN über die Kommunikation mit separaten TPM-Chips abgreifen lassen. Die BSI-Studie liefert dazu nun eine systematische, auf aktuelle Hard- und Software bezogene Untersuchung.

Die eine Gegenmaßnahme, die laut BSI tatsächlich wirkt

Die zentrale Erkenntnis der Studie ist zugleich die beruhigende: Eine zusätzliche PIN-Eingabe beim Systemstart hat in den Testszenarien alle untersuchten Angriffe verhindert. Das BSI empfiehlt entsprechend zwei Maßnahmen, wörtlich aus der Pressemitteilung (öffnet in neuem Tab):

• Ein nach Common Criteria sicherheitszertifiziertes TPM einsetzen.
• Bei der Nutzung eines TPM zur Festplattenverschlüsselung zusätzlich eine PIN-Eingabe verlangen.

Beide Maßnahmen können laut BSI auch Endanwenderinnen und -anwender je nach Betriebssystem selbst vornehmen – es handelt sich also nicht um eine Hardware-Nachrüstung, sondern meist um eine Konfigurationsänderung. Zusätzlich regt das BSI an, die zugrunde liegenden TPM2-Spezifikationen so zu überarbeiten, dass stärkere Schutzmaßnahmen – insbesondere gegen passive Angriffe – künftig standardmäßig aktiv sind, statt sich auf eine nachträgliche Konfiguration durch Anwender zu verlassen.

Für die betriebliche Praxis heißt das: Reine „TPM only"-Verschlüsselung, bei der das Gerät ohne jede weitere Eingabe hochfährt, galt bisher als bequeme Grundsicherung. Nach dieser Studie ist sie gegen einen Angreifer mit physischem Gerätezugriff kein verlässlicher Schutz mehr – genau das Szenario, das bei einem verlorenen oder gestohlenen Notebook eintritt.

So aktivieren Sie die PIN unter Windows mit BitLocker

Ob ein Windows-Gerät mit reiner TPM-Verschlüsselung läuft, lässt sich über die Eingabeaufforderung mit Administratorrechten prüfen:

manage-bde -protectors -get C:

Erscheint hier nur der Protektor-Typ „TPM", ohne PIN-Zusatz, greift die von der Studie beschriebene Schwachstelle. Für den Wechsel auf TPM+PIN gibt es laut Microsoft-Dokumentation (öffnet in neuem Tab) grundsätzlich zwei Wege:

Über die Gruppenrichtlinie (Computerkonfiguration → Administrative Vorlagen → Windows-Komponenten → BitLocker-Laufwerkverschlüsselung → Betriebssystemlaufwerke) ist die Richtlinie „Zusätzliche Authentifizierung beim Start anfordern" zu aktivieren und dort die Option „Startup-PIN mit TPM erforderlich" zu wählen. Diese Richtlinie lässt sich laut Microsoft sowohl per lokalem Gruppenrichtlinien-Editor auf Einzelgeräten als auch zentral per Active Directory oder per CSP über Intune ausrollen – für Unternehmen mit mehreren Geräten ist Letzteres der praktikablere Weg, um die Einstellung flächendeckend durchzusetzen statt sie Gerät für Gerät von Hand zu setzen.

Über die Kommandozeile lässt sich der TPM+PIN-Protektor direkt mit manage-bde nachrüsten, sofern BitLocker bereits aktiv ist:

manage-bde -protectors -add C: -tpmandpin

Der Befehl fragt interaktiv nach einer numerischen PIN zwischen 6 und 20 Ziffern. Nach Abschluss zeigt manage-bde -protectors -get C: den neuen Protektor-Typ „TPMAndPIN" an; ein anschließender Neustart bestätigt, dass die PIN beim Hochfahren tatsächlich abgefragt wird. Wichtig für die Rollout-Planung: Laut Microsofts Befehlsreferenz zu manage-bde-protectors (öffnet in neuem Tab) lässt sich ein nicht mehr benötigter reiner TPM-Protektor anschließend gezielt mit manage-bde -protectors -delete C: -type tpm entfernen, ohne die übrigen Protektoren – etwa den Wiederherstellungsschlüssel – anzutasten.

So aktivieren Sie die PIN unter Linux mit LUKS

Unter Linux ist die TPM-Anbindung an LUKS2-Verschlüsselung nicht automatisch Teil der Standardinstallation, sondern wird meist nachträglich eingerichtet – entweder über systemd-cryptenroll (ab systemd-Version 248 verfügbar) oder über das Framework Clevis. Beide Wege unterstützen eine PIN-Pflicht.

Mit systemd-cryptenroll wird der TPM-Schlüssel direkt an das LUKS2-Volume gebunden. Laut der Manpage von systemd-cryptenroll (öffnet in neuem Tab) genügt dafür ein zusätzlicher Parameter:

systemd-cryptenroll --tpm2-device=auto --tpm2-pcrs=7 --tpm2-with-pin=yes /dev/sdX

Der Parameter --tpm2-with-pin=yes sorgt dafür, dass beim Systemstart zusätzlich zur TPM-Freigabe eine PIN abgefragt wird. Ohne diesen Parameter entsperrt sich das Volume beim Hochfahren automatisch, sobald der TPM-Zustand (über die angegebenen PCR-Werte) als unverändert erkannt wird – exakt die Konfiguration, die laut BSI-Studie angreifbar ist. Ein bereits bestehender PIN-loser TPM2-Eintrag lässt sich vorher mit systemd-cryptenroll /dev/sdX --wipe-slot=tpm2 entfernen, um ihn durch die PIN-geschützte Variante zu ersetzen.

Wer stattdessen Clevis einsetzt – etwa auf Ubuntu-Server-Systemen mit Dracut als Initramfs-Generator –, bindet das Volume laut Ubuntus eigener Anleitung (öffnet in neuem Tab) mit clevis luks bind -d <partition> tpm2 '{"pcr_ids": "7"}' an den TPM. Eine vergleichbar einfache PIN-Option bietet Clevis in der Standardkonfiguration allerdings nicht in gleicher Form wie systemd-cryptenroll – wer eine PIN-Pflicht erzwingen will, ist unter Clevis-gestützten Systemen in der Regel besser mit systemd-cryptenroll bedient, sofern die systemd-Version dies unterstützt.

In beiden Fällen gilt derselbe Hinweis, den auch die Ubuntu-Dokumentation ausdrücklich gibt: Mindestens ein funktionierendes Passwort-Keyslot sollte als Rückfalloption erhalten bleiben, denn TPM-Messwerte können sich nach Firmware-Updates oder Änderungen am Secure-Boot-Status ändern und das automatische Entsperren vorübergehend blockieren.

Was das für die betriebliche Praxis bedeutet

Die Studie betrifft ausdrücklich Szenarien mit physischem Gerätezugriff – also genau die Situation bei einem verlorenen oder gestohlenen Notebook, nicht einen Angriff über das Netzwerk. Für Unternehmen mit mobilen Mitarbeitenden ist das trotzdem keine Randnotiz: Jedes Außendienst-Notebook, jeder dienstliche Laptop im Homeoffice oder auf Reisen ist genau diesem Risiko ausgesetzt, und die PIN-Pflicht ist nach dieser Studie kein optionales Härtungsdetail mehr, sondern die eine Maßnahme, die laut BSI tatsächlich nachweislich schützt.

Drei Schritte lassen sich unabhängig von der Unternehmensgröße zeitnah umsetzen:

1. Bestand prüfen. Auf Windows-Geräten zeigt manage-bde -protectors -get C:, auf Linux-Systemen systemd-cryptenroll <device> den aktuell konfigurierten Entsperrmechanismus. Wer das nicht pro Gerät einzeln abfragen will, prüft über die zentrale Verwaltung (Intune, Active Directory, Konfigurationsmanagement) den Rollout-Status der BitLocker-Richtlinie.
2. PIN-Pflicht zentral durchsetzen, nicht dem Gerät überlassen. Unter Windows per Gruppenrichtlinie oder Intune-CSP, unter Linux im Provisioning-Skript oder Konfigurationsmanagement – eine Einstellung, die jedes Gerät einzeln von Hand bekommt, bleibt erfahrungsgemäß lückenhaft.
3. Wiederherstellungsschlüssel zentral hinterlegen, bevor die PIN-Pflicht aktiv wird. Sowohl BitLocker als auch LUKS benötigen einen Rückfallweg, falls eine PIN vergessen wird oder sich der TPM-Zustand nach einem Update ändert – ohne hinterlegten Wiederherstellungsschlüssel führt das sonst zu einem gesperrten Gerät ohne Zugriff auf die eigenen Daten.

Die BSI-Studie ändert nichts an der grundsätzlichen Empfehlung, Festplatten zu verschlüsseln – im Gegenteil, sie zeigt, dass die Grundidee richtig ist. Sie macht aber deutlich, dass die bequemste Standardkonfiguration gegen einen Angreifer mit Gerät in der Hand eben nicht ausreicht. Der Unterschied zwischen einem geschützten und einem angreifbaren Notebook liegt nach diesen Ergebnissen an einer einzigen, in wenigen Minuten gesetzten Einstellung.