Vor Kurzem saß ich in einer Arztpraxis im Wartezimmer, und weil ich so bin wie ich bin, habe ich statt der Zeitschriften die Rechner am Empfang angeschaut. An jedem hing eine Funkmaus und eine Funktastatur, dazu der kleine Adapter im USB-Port. Von einem Hersteller, den ich nicht kannte, der Eindruck war sehr günstiges No-Name-Gerät. So etwas nenne ich selbst gern etwas abfällig „Chinaprodukt“, was eigentlich unfair ist, denn die können das inzwischen richtig gut.

Im Gespräch mit dem Arzt kam heraus, dass ihm ein Punkt völlig neu war: dass die Tastatureingaben als Funk durch die Luft gehen und dass man Funk mithören kann. An seinem Platz werden Diagnosen, Namen und Medikamente getippt, und die Frage, ob das jemand aus dem Nachbarzimmer mitlesen könnte, hatte sich vorher schlicht nie gestellt. Aus genau dieser Unterhaltung ist dieser Beitrag entstanden, und er wollte ihn selbst lesen. Also, hallo an dieser Stelle, danke für den Anstoß.

Ich will die Praxis dabei nicht an den Pranger stellen. Über die Sicherheit genau dieses No-Name-Geräts kann ich nichts sagen, ich habe es nie in der Hand gehabt. Der Punkt ist ein anderer: fast jeder benutzt so einen Adapter, und kaum jemand hat sich die Frage je gestellt. Bei einer Mausbewegung ist das auch egal. Bei einem Passwort, einer PIN oder einem Login nicht. Also drei Fragen, die den Beitrag tragen. Kann man das wirklich abhören? Kann man sogar eigene Tasten einschleusen? Und wie sieht man, ob das eigene Gerät geschützt ist?

Ich mache das am Beispiel von Logitechs Unifying-Adapter, dem mit dem kleinen orangen Stern, weil ich davon zwei Stück im Rechner habe und weil Logitech einer der Hersteller ist, bei dem man den Unterschied zwischen „kein Krypto“ und „verschlüsselt“ schön sehen kann. Alles, was ich hier auf dem Rechner prüfe, zeige ich mit dem Befehl und der echten Ausgabe. Und wo etwas unklar bleibt, sage ich das auch.

Durch die Luft, und schon sind es zwei Probleme

Bevor es um Logitech geht, muss eine Sache sauber getrennt sein, denn der ganze Beitrag hängt daran. Wer an einem Funkgerät lauscht, will eines von zwei Dingen, und die sind unterschiedlich gefährlich.

• Mitlesen, passiv. Der Angreifer hört den Funk nur mit. Das ist gefährlich bei allem, was die Tastatur sendet, also Passwörter, PINs, Nachrichten. Bei der Maus dagegen gehen nur Bewegungen und Klicks über die Luft, da ist Mitlesen fast folgenlos.
• Einschleusen, aktiv. Der Angreifer sendet selbst und gibt sich als euer Gerät aus. Damit tippt er auf eurem Rechner, öffnet ein Terminal, lädt etwas nach. Das ist der unangenehmere Fall, weil er nicht davon abhängt, dass ihr gerade etwas tippt. Der Rechner steht am Empfang, niemand sitzt davor, und trotzdem passiert etwas.

Daraus ergeben sich drei Schutzstufen, und die Reihenfolge ist wichtig.

1. Kein Schutz. Klartext. Jeder in Funkreichweite liest mit und kann einschleusen.
2. Verschlüsselung. Der Funk ist chiffriert. Wer mithört, bekommt nur Kauderwelsch. Logitech nimmt dafür bei Tastaturen AES-128.
3. Authentisierung. Der Empfänger prüft, ob ein Paket wirklich vom gekoppelten Gerät stammt. Erst das schließt das Einschleusen zuverlässig, denn Verschlüsselung allein sagt nur, dass keiner mitliest, nicht, dass keiner sich einschleicht.

Und hier kommt die Design-Entscheidung, die uns später um die Ohren fliegt. Eine Tastatur braucht zwingend Verschlüsselung, weil sie Geheimes sendet. Eine Maus bekam bei Unifying historisch keine, weil sie ja nichts Geheimes sendet. Das klingt vernünftig, und für sich genommen ist es das auch. Zum Einfallstor wurde es trotzdem, weil ein Empfänger, der offene Maus-Pakete akzeptiert, sich dazu bringen ließ, auch gefälschte Tastatur-Pakete zu schlucken. Genau das war MouseJack. Dazu gleich mehr.

Der Funkweg. Die Tastatur funkt AES-128-verschlüsselt, die Maus im Klartext. Ein Angreifer mit Antenne hört beide Strecken, von der Tastatur bekommt er aber nur Kauderwelsch.

KeySniffer, so sieht es aus, wenn gar nichts da ist

Damit klar wird, wovon wir reden, erst das schlechte Beispiel. 2016 zeigte die Firma Bastille unter dem Namen KeySniffer, dass Funktastaturen von acht Herstellern die Tastenanschläge komplett im Klartext funken, ohne jede Verschlüsselung. Betroffen waren Anker, EagleTec, General Electric, Hewlett-Packard, Insignia, Kensington, Radio Shack und Toshiba. Mitlesbar aus rund 75 Metern, mit Hardware für unter hundert Dollar. Man tippt sein Passwort, und einer im selben Gebäude schreibt es Zeichen für Zeichen mit.

Zwei Dinge daran sind wichtig. Erstens ist das kein „schwaches Krypto“, das ist „kein Krypto“. Diesen Unterschied wirft man gern in einen Topf, aber er ist der ganze Punkt. Zweitens kann man diese Tastaturen nicht per Update retten. Da hilft nur wegwerfen und ersetzen. Und genau das ist der Unterschied zu Logitech, wo ein Empfänger-Update wirklich etwas ändert, wie wir noch sehen werden. Bluetooth-Tastaturen und die höherwertigen Geräte von Logitech, Dell und Lenovo waren von KeySniffer übrigens nicht betroffen. Das ist die Brücke zu Logitech.

Ein Stern, sechs Geräte: wie Unifying funktioniert

Unifying ist der kleine USB-Adapter mit dem orangen Stern, an den sich bis zu sechs Geräte koppeln lassen. Eine Maus, eine Tastatur, vielleicht ein Ziffernblock, alles über einen Stick. Technisch funkt das bei 2,4 GHz auf Nordics nRF24-Technik, nicht Bluetooth. Das ist ein wichtiger Punkt, den ich später beim Abhören noch brauche. Tastaturen werden mit AES-128 verschlüsselt, der Schlüssel wird beim Koppeln festgelegt. Mäuse funken offen.

MouseJack, 2016, und die offene Maus als Hebel

Ebenfalls 2016, wieder Bastille, diesmal Marc Newlin. Über die offene, nicht authentifizierte Maus-Strecke ließen sich gefälschte Tastatur-Pakete in viele Empfänger einschleusen, dazu erzwungenes Koppeln. Betroffen waren Geräte vieler Hersteller, nicht nur Logitech. Der Angreifer musste nicht warten, bis jemand tippt. Er gab sich als neue Tastatur aus und schrieb selbst.

Logitech reagierte mit mehreren Firmware-Ständen für die Empfänger. Nach Logitechs eigenen Release-Notes sind die Kern-MouseJack-Punkte, also erzwungenes Koppeln, Tastatur-Injektion und gefälschte Maus, ab RQR12.05 beziehungsweise RQR24.03 geschlossen. Eine später gefundene Schwäche, die verschlüsselte Injektion (Bastille-Punkt #13, als CVE-2016-10761 geführt), folgte erst ab RQR12.08 und RQR24.06. Diese zwei Generationsnummern solltet ihr euch merken, sie kommen beim Testgerät gleich wieder.

Die vier Lücken von 2019, und die eine, die blieb

2019 nahm sich Marcus Mengs, im Netz MaMe82, Unifying noch einmal vor. Vier CVEs, und der Unterschied zwischen ihnen ist der eigentliche Lehrwert.

CVE

Was

Fix

CVE-2019-13052

Aus dem Mitschnitt der Kopplung den AES-Schlüssel ableiten, danach mitlesen und einschleusen

kein Patch, Logitech lehnte ab

CVE-2019-13053

Einschleusen in die verschlüsselte Strecke, setzt einmaligen physischen Zugriff voraus

kein Patch für die erweiterte Form

CVE-2019-13054

Schlüssel aus R500- und Spotlight-Presentern auslesen, physischer Zugriff

Fix für August 2019 angekündigt

CVE-2019-13055

Alle gekoppelten Schlüssel aus einem Empfänger in unter einer Sekunde, physischer Zugriff

Fix für August 2019 angekündigt

Die spektakuläre Fernübernahme, MouseJack, ist an einem aktuellen Empfänger zu. Was bleibt, ist die erste Zeile: CVE-2019-13052. Wer den Moment der Kopplung mitschneidet, kann daraus den AES-Schlüssel ableiten und danach mitlesen und einschleusen. Diese Lücke wurde nie geschlossen. Logitech hat erklärt, dafür keinen Patch zu liefern, sie steckt im Design.

Das praktische Risiko ist gering, weil man dafür genau dann mithören muss wenn ihr ein Gerät neu koppelt, und weil der Schlüssel danach nicht neu ausgehandelt wird. Koppeln passiert selten und ist schnell vorbei. Aber der Satz „Firmware aktuell, also alles gut“ wäre trotzdem falsch, und genau diese Ehrlichkeit macht für mich den Reiz an der Sache aus. Diese Kopplungs-Lücke ist übrigens auch der Aufhänger für den zweiten Teil.

Die Angriffe über die Zeit. MouseJack wurde per Firmware geschlossen, aus der 2019er-Serie blieb CVE-2019-13052 offen, und Logi Bolt zieht 2021 die Konsequenz.

Logi Bolt, der Nachfolger, der es richtig macht

2021 brachte Logitech mit Logi Bolt einen neuen Empfänger heraus, der Sicherheit von Anfang an mitdenkt. Die Kernpunkte, alle belegt:

• Bolt setzt auf Bluetooth Low Energy im Security Mode 1, Level 4, also Secure Connections Only. Das heißt verschlüsselt und authentifiziert. Genau der Schutz gegen Einschleusen, der Unifying von Haus aus fehlte.
• Es ist ein geschlossenes System, ein Bolt-Empfänger spricht nur mit Bolt-Geräten.
• Pro Kopplung eine andere Bluetooth-Adresse und eigene Schlüssel.
• Koppeln geht nur nach einem ausdrücklichen, langen Knopfdruck von einigen Sekunden. Das schließt das erzwungene Koppeln.
• Firmware ist zentral ausrollbar, mit Schutz gegen das Zurückrollen auf alte Stände.

Ein Missverständnis will ich gleich einfangen. Bolt ist Bluetooth-basiert, aber es ist ein geschlossenes, gehärtetes System, kein normales Bluetooth-Pairing, wie ihr es vom Kopfhörer kennt. Verwechselt das nicht, das eine ist gehärtet, das andere ist ein bunter Haufen.

Zwei Empfänger, eine Maus, eine Tastatur

Genug Geschichte, jetzt der eigene Rechner. Auf dem Testgerät, einem Notebook mit Linux Mint 22.3, stecken zwei Unifying-Empfänger gleichzeitig. Am einen hängt die Maus, eine Logitech Marathon Mouse M705, am anderen die Tastatur, eine MX Keys. Beide Sticks tragen denselben orangen Stern, und wie sich gleich zeigt, tragen sie trotzdem zwei verschiedene Sicherheitsgeschichten mit sich herum.

Die Maus M705 und ein Unifying-Empfänger mit dem orangen Stern.

Der orange Stern ist das Erkennungszeichen von Unifying.

Die Tastatur, eine Logitech MX Keys.

Erst einmal schauen, ganz ohne Spezialwerkzeug

Man muss nicht sofort ein Paket installieren, um zu verstehen, was da steckt. Das Betriebssystem verrät schon eine ganze Menge. Erst schaue ich, welche USB-Geräte hängen. Mit lsusb sehe ich beide Empfänger, und interessant ist, dass sich beide als exakt dieselbe Kennung melden.

$ lsusb | grep -i logitech
Bus 001 Device 011: ID 046d:c52b Logitech, Inc. Unifying Receiver
Bus 001 Device 012: ID 046d:c52b Logitech, Inc. Unifying Receiver

046d ist Logitech, c52b ist der Unifying-Empfänger. Zwei gleiche Kennungen, zwei physische Sticks. Als Nächstes die Kernelmodule, die diese Sticks bedienen.

$ lsmod | grep -i logi
hid_logitech_hidpp     69632  0
hid_logitech_dj        36864  0
usbhid                 77824  2 hid_logitech_dj,hid_logitech_hidpp
hid                   282624 10 usbhid,...,hid_logitech_dj,hid_logitech_hidpp

Zwei Module machen die Arbeit, und die Aufgabenteilung lohnt sich zu verstehen. hid_logitech_dj kümmert sich um das Multiplexing des Unifying-Empfängers, also darum, dass ein einziger Stick mehrere Geräte tragen kann. hid_logitech_hidpp spricht das Feature-Protokoll HID++, über das gleich auch Solaar redet. Und über die Geräteknoten /dev/hidraw* reden die Werkzeuge am Ende mit den Sticks. So versteht man die Schichten, bevor überhaupt ein Zusatzprogramm im Spiel ist.

Solaar, das eine Werkzeug, das man wirklich braucht

Solaar ist die grafische Oberfläche und zugleich ein Kommandozeilen-Werkzeug für Unifying und HID++. Damit koppelt man Geräte, sieht den Akkustand, den Verschlüsselungsstatus und kann Tasten umbelegen. Auf dem Testgerät läuft Version 1.1.11. Der eine Befehl, der alles auf einmal ausgibt, ist solaar show. Für den Empfänger der Maus, gekürzt auf das Wesentliche:

Unifying Receiver
  USB id       : 046d:C52B
  Serial       : 3CE0986A
    Firmware   : 12.11.B0032
  Has 1 paired device(s) out of a maximum of 6.

  1: Marathon Mouse M705 (M-R0073)
     Kind         : mouse
     Protocol     : HID++ 4.5
     Battery: 50%, discharging, next level 20%.

Solaar zeigt den Empfänger der Maus. USB-ID 046d:C52B, Firmware 12.11.B0032, ein gekoppeltes Gerät.

Und für den Empfänger der Tastatur:

Unifying Receiver
  USB id       : 046d:C52B
  Serial       : C31FD0D1
    Firmware   : 24.11.B0036
  Has 1 paired device(s) out of a maximum of 6.

  1: MX Keys Keyboard
     Kind         : keyboard
     Protocol     : HID++ 4.5

Der zweite Empfänger, der für die Tastatur. Dieselbe USB-Kennung, aber Firmware 24.11.B0036.

Hier fällt schon auf, was ich gleich groß mache. Zwei Unifying-Sticks, aber zwei Firmware-Linien: RQR12 für die ältere Maus-Generation, RQR24 für die neuere Tastatur. Beide tragen denselben orangen Stern, dahinter stecken aber zwei Baujahre und zwei Geschichten.

Zwei Sterne, ein Unterschied

Das ist das Herzstück, und es ist ein einziger Blick in Solaar. In der Geräteansicht steht bei jedem gekoppelten Gerät eine Zeile „Drahtlose Verbindung“. Für die Maus M705 meldet Solaar dort „nicht verschlüsselt“, mit einem roten Schild. Für die Tastatur MX Keys meldet dieselbe Zeile „verschlüsselt“, mit einem geschlossenen Schloss.

Solaar meldet für die Maus M705 eine nicht verschlüsselte Funkverbindung, mit rotem Schild.

Für die Tastatur MX Keys meldet Solaar dieselbe Übersicht als verschlüsselt, mit geschlossenem Schloss.

Was das heißt, und was nicht. Die Tastatur ist mit AES-128 verschlüsselt, der Schlüssel wurde beim Koppeln festgelegt. Wer die Funkstrecke mithört, bekommt Kauderwelsch. Die Maus funkt offen, was für Bewegungen und Klicks kein Problem ist. Und dann die ehrliche Einschränkung, die uns direkt zum Angriff führt: dass die Maus offen funkt, war historisch genau der Hebel für das Einschleusen, bis die Firmware das abgestellt hat.

Ein Gedanke, der jetzt naheliegt, führt in die Irre: dann schalte ich die Verschlüsselung der Tastatur eben ab und schaue, was durchgeht. Geht nicht. Die AES-Verschlüsselung der Tastatur hat keinen Ausschalter. Sie steckt fest im Unifying-Protokoll, Solaar hat dafür keinen Schalter, das alte ltunify auch nicht. Wer die Klartext-Eingaben der Tastatur sehen will, muss das AES brechen, nicht abschalten. Und genau das ist der Stoff für den zweiten Teil.

Was man installieren sollte, und was nicht

Für die reine Frage „bin ich sicher“ braucht man erstaunlich wenig. Zwei Pakete reichen, und beide waren auf dem Testgerät sowieso schon da.

Paket

Wofür

solaar

Kopplung, Akku, Verschlüsselungsstatus, Tastenbelegung

fwupd

Firmware-Updates über LVFS

Ein paar Werkzeuge, über die man im Netz stolpert, braucht man hier ausdrücklich nicht, und ich schreibe dazu, warum.

Paket

Warum nicht

ltunify

ältere Unifying-Kommandozeile, von Solaar überholt

libratbag / piper

DPI- und Tastenkonfiguration für Gaming-Mäuse, für die M705 unnötig, Solaar deckt sie ab

jackit, nrfutil, dfu-tool

Angriffs- und Flash-Werkzeuge für nRF-Hardware, hier nicht installiert. jackit gehört zum Crazyradio-am-Laptop-Weg, in diesem Aufbau macht die Funkarbeit stattdessen der Flipper

Bin ich sicher? Zwei Blicke genügen

Der erste Blick ist der Verschlüsselungsstatus, den Solaar meldet. Tastatur verschlüsselt, Maus nicht. Das ist bei Unifying normal und in Ordnung, solange man weiß, dass die Maus offen funkt und dort nichts Geheimes durchgeht.

Der zweite Blick ist die Firmware. fwupd kennt beide Empfänger über LVFS, und fwupdmgr get-updates sagt, ob etwas ansteht.

$ fwupdmgr get-updates --no-unreported-check
Devices with the latest available firmware version:
 • Unifying Receiver
 • Unifying Receiver

Beide sind auf dem neuesten Stand, den LVFS anbietet, das ist RQR12.11 und RQR24.11. Und jetzt die Verbindung zur Geschichte, die den Abschnitt wertvoll macht. Die MouseJack-Fixes stecken in den Firmware-Generationen ab RQR12.05 beziehungsweise RQR24.03 für die Kern-Punkte, und ab RQR12.08 beziehungsweise RQR24.06 für die verschlüsselte Injektion. Beide Empfänger liegen mit 12.11 und 24.11 deutlich darüber. Die Fernübernahme von 2016 ist an diesem Gerät also zu. Das ehrliche Ergebnis dieses Abschnitts ist „hier ist nichts zu tun“, und das darf man auch so hinschreiben.

Trotzdem der Handgriff für den Fall, dass doch einmal ein Update ansteht, als Verfahren, nicht als Messung. Auf dem Testgerät gab es nichts zu aktualisieren, ich habe die letzte Zeile hier also nicht wirklich ausgeführt.

fwupdmgr refresh
fwupdmgr get-updates
fwupdmgr update

Wie würde ein Angreifer das überhaupt abhören?

Jetzt die andere Seite. Unifying funkt bei 2,4 GHz auf nRF24-Technik mit einer eigenen Paketstruktur, Enhanced ShockBurst nennt Nordic das. Normale SDR-Empfänger und die üblichen Sub-Gigahertz-Geräte sehen das schlicht nicht. Man braucht ein nRF24-Radio, das in einen Mithör-Modus versetzt wird. Und genau hier wird es interessant, was ein Flipper Zero kann und was nicht.

Der Flipper Zero, und warum er allein nicht reicht

Das eingebaute Funkteil des Flipper ist ein CC1101. Das arbeitet unter einem Gigahertz, grob 300 bis 928 MHz. Es kommt physikalisch nicht an die 2,4 GHz von Unifying heran. Aus der Schachtel heraus kann der Flipper diesen Angriff also gar nicht, egal welche Firmware drauf ist.

Welches Radio an 2,4 GHz herankommt. Der eingebaute CC1101 des Flippers arbeitet unter einem Gigahertz und sieht die Strecke nicht. Erst ein nRF24-Radio kommt heran.

Auf meinem Aufbau steckt der Flipper mit der Momentum-Firmware und einem Zusatzmodul, einem AIO Board. Auf dem Board steht die Bestückung selbst drauf: RED NRF24, GREEN ESP32, BLUE CC1101, dazu ein EBYTE-Modul und externe Antennen. Das entscheidende Teil für uns ist das nRF24-Radio. Genau das, was dem Flipper von Haus aus fehlt. Damit werden die Apps NRF24: Sniffer und NRF24: Mouse Jacker nutzbar, beide aus dem Projekt von mothball187 und in Momentum enthalten.

Flipper Zero mit aufgestecktem AIO Board V1.4. Das Board liefert das nRF24-Radio für 2,4 GHz, neben ESP32 und CC1101, das dem Flipper allein fehlt.

Der Ablauf ist in zwei Schritten schnell erzählt. Erst sucht der Sniffer die Kanäle ab und findet die Funkadresse des Empfängers. Dann bekommt der Mouse Jacker diese Adresse und ein Tastatur-Skript und versucht, Tasten einzuschleusen. Klingt einfach. Der erste Schritt ist es aber schon nicht.

Der NRF24-Sniffer meldet eine gefundene Adresse auf einem 2,4-GHz-Kanal.

Der nRF24-Treiber der Flipper-App gilt selbst als funktionierend, aber unfertig, und das Sniffen im 2,4-GHz-Band rastet gern auf zufälliges Rauschen ein und meldet Adressen, die es gar nicht gibt. Drei Läufe brachten bei mir drei verschiedene Adressen, einmal sogar mit „Unique 0“, also ohne einen einzigen wiederholten Treffer. Eine echte Logitech-Adresse taucht über mehrere Läufe immer wieder auf, das ist das Erkennungszeichen. Mit etwas Geduld, Maus dabei bewegen und jeden Durchlauf sauber mit OK beenden, damit die App überhaupt speichert, hat sich am Ende die Adresse 086A98E03C als die stabile, echte herauskristallisiert. Das Erkennen klappt also, aber es ist selbst schon eine Hürde und nicht der Sofort-Erfolg, den man sich vorstellt.

Die offene Maus lässt sich mit demselben Radio mitschnüffeln, man sieht rohe Pakete. Passwörter sind da natürlich keine drin, nur Bewegung und Klicks. Genau das ist der greifbare Beleg für „die Maus funkt im Klartext“.

Und jetzt der eigentliche Versuch. Ich habe einen einfachen Texteditor auf dem Notebook geöffnet und ihm den Fokus gegeben. Der Mouse Jacker bekam die ersniffte Adresse 086A98E03C und ein harmloses Skript, das nur den Text MOUSEJACK-TEST-0810 tippen sollte, sonst nichts. Der Flipper zeigte „Running duckyscript“.

Mouse Jacker feuert das Skript gegen die Adresse. Auf dem gepatchten Empfänger landet keine einzige Taste.

Im Editor erschien nichts. Keine einzige Taste kam durch. Das ist kein Misserfolg des Versuchs, sondern das erwartete Verhalten an einem Empfänger, der über dem MouseJack-Fix liegt.

Hier bleibe ich bei der Ursache ehrlich, das ist mir wichtig. „Nichts passiert“ allein trennt nicht sauber, ob die Firmware das Paket abgewiesen hat oder ob die ersniffte Adresse nicht exakt der Empfänger war. Um das isoliert zu beweisen, müsste ein bewusst verwundbarer Vergleichs-Empfänger danebenstehen, an dem derselbe Angriff gelingt, und der stand hier nicht daneben. Sicher ist: die klassische MouseJack-Übernahme aus der Ferne, ohne Anfassen, gelang an diesem aktuellen Setup mit RQR12.11 nicht, und das passt dazu, dass fwupd die Firmware als aktuell und über dem Fix meldet. Mehr behaupte ich an dieser Stelle nicht. Das ist gemessen, die Deutung der Ursache ist plausibel, aber nicht bewiesen.

Nur eine von mehreren Möglichkeiten

Der Flipper ist nur ein Weg, und ehrlich gesagt der bequeme für unterwegs. Damit klar ist, was sonst noch geht:

• Crazyradio PA, ein nRF24-USB-Stick mit der Bastille-Firmware plus jackit. Das klassische MouseJack-Werkzeug, läuft am Laptop und kann mitschreiben.
• nRF52840-Dongle mit Logitacker von Marcus Mengs. Das moderne Werkzeug, das auch die 2019er-Lücken kann, inklusive der Kopplungs-Lücke CVE-2019-13052. Genau dieses Gespann kommt im zweiten Teil zum Einsatz.
• Raspberry Pi mit nRF24-Modul. Möglich, aber deutlich fummeliger, weil das Timing schlechter ist als bei einer dedizierten Crazyradio.

Die Grenze des Flippers ist dabei klar. Er ist gut zum Erkennen und für den MouseJack-Versuch, aber er leitet keine Schlüssel ab und entschlüsselt keine Tastatur. Dafür braucht es Logitacker auf dem nRF52840, und das ist der zweite Teil.

Was ich für sichere Umgebungen empfehle

Kein Wischiwaschi, eine klare Rangfolge.

1. Kabel. Eine USB-Tastatur funkt gar nicht. Für alles, wo wirklich Geheimes getippt wird, ist das die ruhigste Lösung.
2. Logi Bolt oder eine sauber gekoppelte Bluetooth-Verbindung mit Secure Connections. Verschlüsselt und authentifiziert, also auch gegen Einschleusen geschützt.
3. Aktuelles Unifying. Völlig brauchbar, wenn die Empfänger-Firmware gepflegt ist. Die Tastatur ist verschlüsselt, die Fernübernahme ist zu. Das Restrisiko ist die Kopplungs-Lücke.
4. Alles ohne Verschlüsselung, KeySniffer-Klasse, gehört ersetzt. Da hilft kein Update.

Dazu zwei Handgriffe, die jeder machen kann. Die Firmware der Empfänger aktuell halten, mit fwupdmgr, das ist eine Minute Arbeit. Und Geräte nur in vertrauenswürdiger Umgebung koppeln, nicht im Café und nicht im vollen Großraumbüro, wegen genau dieser Kopplungs-Lücke CVE-2019-13052.

Eine kurze Entscheidungshilfe für das eigene Funk-Setup.

Was offen bleibt

• Warum das Einschleusen genau scheiterte. Der Durchlauf ist gemessen, der Sniffer findet 086A98E03C und die Injektion landet nichts, aber ob die Firmware abwies oder die ersniffte Adresse nicht exakt saß, ist ohne einen verwundbaren Vergleichs-Empfänger nicht isoliert nachgewiesen.
• Die Kopplungs-Lücke CVE-2019-13052 ist beschrieben, aber nicht vorgeführt. Das ist der Kern des zweiten Teils.
• Ob sich auf genau diesem nRF24-Modul die Adresse zuverlässig mitschneiden lässt, hängt von Kanal und Timing ab und ist nicht erschöpfend getestet.
• Ob die MX Keys selbst per fwupd ein Firmware-Update bekommen könnte, habe ich nicht geprüft, nur die beiden Empfänger.
• Reichweite und Störumgebung. Alle Aussagen zum Mithören beziehen sich auf die Laborsituation direkt am Gerät.

Wie es weitergeht

Im nächsten Teil wird nicht nur erklärt, sondern gemacht. Mit einem nRF52840-Dongle und Logitacker schneide ich den Kopplungsvorgang einer Unifying-Tastatur mit, leite daraus den Schlüssel ab und lese die Eingaben mit. Das ist die Design-Lücke CVE-2019-13052, und sie betrifft auch die aktuelle Firmware, an der der Flipper heute noch abgeprallt ist. Aus „die Tastatur ist verschlüsselt“ wird dann „und trotzdem lesbar, wenn ich im richtigen Moment dabei war“. Das ist der interessante Teil, und er kommt.

Bezugsquellen

Die folgenden Links sind Affiliate-Links (Werbung). Kaufst du darüber, bekomme ich eine kleine Provision, für dich ändert sich am Preis nichts.

• Flipper Zero: https://amzn.to/4qa8chY
• AIO-Board (nRF24, ESP32, CC1101) für den Flipper Zero: https://s.click.aliexpress.com/e/_c3Ug4MNH

Siehe auch

• TPM 2.0 unter Linux, der Schwester-Beitrag über Hardware, die jeder hat und kaum jemand anschaut.
• BIOS erklärt, Teil 1, ein Serverboard als Workstation und der Weg ins Setup.

Wenn ich irgendwo danebenliege, korrigiert mich gerne, dann lerne ich selbst etwas. Und die Frage an euch zum Schluss: Nutzt ihr Funk oder Kabel, und habt ihr je nachgesehen, ob eure Tastatur überhaupt verschlüsselt funkt? Wie das geht, wisst ihr jetzt. Wenn ihr mögt, dürft ihr mich dazu sehr gerne fragen.

Es gibt Dinge, die unter Linux in der breiten Masse vernachlässigt werden. Secure Boot ist so ein Beispiel, TPM ist ein anderes. Vielleicht ist es an der anfangs bescheidenen Unterstützung gescheitert, vieleicht sind die Themen technisch einfach unangenehm, am ehesten aber liegt es daran, dass der Mehrwert für die meisten überschaubar bleibt. Heute nehme ich mir den TPM vor.

Aufgefallen ist mir der Chip zweimal. Das erste Mal, als er durch die Medien ging, weil die Angst groß wurde, Microsoft mache damit unsere IT kaputt, und weil jemand anfing, sehr viele Patente einzureichen. Das zweite Mal viele Jahre später, als TPM 2.0 zur harten Voraussetzung für Windows 11 wurde. Dazwischen lagen zwanzig Jahre, in denen der Chip in fast jedes Endgerät gewandert ist, ohne dass sich jemand dafür interessiert hat.

In Notebooks und Fertig-PCs ist er heute meist fest verlötet. Bei Server-Mainboards kauft man ihn dagegen als Option dazu, ein kleines Steckmodul auf einem eigenen Header. Der Chip in meinem Testgerät ist ein Infineon OPTIGA SLB 9670, und genau dieselbe Chip-Familie sitzt auf den steckbaren TPM-Modulen für Supermicro-Boards. Damit schließt der Beitrag an die BIOS-Serie an, in der ich mich gerade Menü für Menü durch ein Serverboard arbeite.

Erst die Geschichte, dann die Hände in den Chip. Alle Ausgaben hier sind echt und stammen vom 10. August 2026, gemessen auf einem Fujitsu Celsius H780 mit Linux Mint 22.3, Kernel 7.0.0-28-generic und tpm2-tools 5.6. Wo ich etwas nur aus Dokumentation kenne oder wo ich vermute, steht das dabei.

Angefangen hat alles mit einer Seriennummer in der CPU

Mitte der neunziger Jahre wollte Intel eine Identifizierungsfunktion direkt in den Prozessor bringen. Der erste Schritt war 1999 die Prozessor-Seriennummer im Pentium III, eine eindeutige Kennung, die jede Software auslesen konnte. Der öffentliche Widerstand war so heftig, dass Intel zurückzog. Das Vorhaben verschwand aber nicht, es suchte Deckung in einem Konsortium. Dieses Detail ist wichtig, weil es das Muster für alles setzt, was danach kam.

1999 gründeten Compaq, HP, IBM, Intel und Microsoft die Trusted Computing Platform Alliance, kurz TCPA. Im April 2003 wurde daraus die Trusted Computing Group, TCG, getragen von AMD, HP, IBM, Intel und Microsoft. Aus einer Firmenidee war ein Industriestandard geworden.

Der Chip, der nach einem Senator benannt wurde

In der Debatte bekam der TPM den Spottnamen „Fritz-Chip“. Der Name ging auf den US-Senator Fritz Hollings aus South Carolina zurück, der den CBDTPA vorantrieb, ein Gesetzesvorhaben, das Kopierschutz in aller Consumer-Elektronik verpflichtend machen sollte. Der Spottname war also ein politischer Vorwurf und keine technische Bezeichnung. Er hat trotzdem länger gehalten als das Gesetz, aus dem er kam.

Vertrauen, aber nicht dein Vertrauen

Ross Anderson von der Universität Cambridge schrieb 2002 und 2003 die Trusted Computing FAQ. Dieses Dokument hat die Debatte stärker geprägt als jede Herstellerankündigung, und es liegt bis heute unverändert online. Sein Kernargument in einem Satz: bei „Trust“ geht es nicht darum, dass der Nutzer dem Rechner vertraut, sondern darum, dass der Rechner dem Nutzer nicht vertraut.

Richard Stallman legte 2002 mit „Can you trust your computer?“ nach und prägte den Gegenbegriff treacherous computing, verräterisches Rechnen. Die FSF benutzt ihn heute noch. IBM antwortete mit einer Gegendarstellung von David Safford, „Clarifying Misinformation on TCPA“.

Die EFF ging einen dritten Weg, und der ist der interessanteste. Seth Schoen veröffentlichte im Oktober 2003 Trusted Computing: Promise and Risk und schlug ein konkretes Feature vor, den Owner Override. Der Eigentümer des Rechners sollte die Attestierung überstimmen können, seinem Bank-Server also erzählen dürfen, sein Opera sei ein Internet Explorer. Die Kritik hatte damit einen Reparaturvorschlag und war nicht bloß dagegen. Die TCG hat den Owner Override nie übernommen.

Microsoft nannte sein eigenes Vorhaben Palladium und benannte es am 24. Januar 2003 in Next-Generation Secure Computing Base um, NGSCB. Der Name wurde harmloser, die Architektur blieb dieselbe.

Zwei Patente von 2001, und ein Cypherpunk der zurückschoss

Im Dezember 2001 wurden Microsoft zwei Patente erteilt. Das eine ist US 6,330,670, „Digital rights management operating system“, angemeldet im Januar 1999, erteilt am 11. Dezember 2001, als Erfinder Paul England, John DeTreville und Butler Lampson. Das andere ist US 6,327,652, „Loading and identifying a digital rights management operating system“. Zusammen decken sie viele Grundelemente eines vertrauenswürdigen Betriebssystems ab.

Die Sorge dahinter war handfest und nicht abwegig. Wenn Palladium unter dieses Patent fällt, dann verletzt jeder unabhängige Nachbau das Patent. Also jeder einzelne Entwickler, jedes Open-Source-Projekt, jeder Wettbewerber. Ohne Lizenz von Microsoft kein freies Trusted Computing. Kritiker beschrieben das damals als Kombination aus Patentschutz und faktischem Zwang zur Nutzung, mit deutlich wettbewerbsrechtlichem Geschmack.

Der Gegenzug kam im August 2002 von einem Cypherpunk, der unter dem Namen Lucky Green auftrat. Er meldete selbst ein Patent an, und zwar auf Verfahren, mit denen Software auf einer Palladium- oder TCPA-Plattform gegen Kopieren geschützt werden kann. Der Zweck war offen defensiv: wer die Ansprüche hält, kann verhindern, dass genau diese Anwendungen ausgerollt werden. Auf einem Panel der USENIX Security wurde er gefragt, ob Microsoft nicht einfach Prior Art geltend machen könne. Sein Argument: Prior Art müsste unter Eid erklärt werden, und nach Jahren Arbeit am Projekt und einem ausführlichen eigenen DRM-Patent sei kaum vorstellbar, dem Palladium-Team wäre relevante Prior Art entgangen. Im September 2002 hielt er zusätzlich einen Vortrag mit dem Titel „TCPA: the mother(board) of all Big Brothers“.

Was daraus geworden ist

Die Auflösung ist unbequemer, als es beide Lager damals gedacht haben. NGSCB ist gescheitert, aber nicht an den Patenten. Im Mai 2004 stellte Microsoft die vollständige Architektur zurück, und die Begründung war wirtschaftlich: die Hardware-Landschaft war nicht reif, und vor allem waren die unabhängigen Softwarehersteller nicht bereit, ihre Anwendungen auf die nötigen neuen APIs umzuschreiben. Curtained Memory und der Nexus-Kernel fielen weg, die TPM-Unterstützung blieb übrig.

Der Chip selbst wurde offen. Nach TPM 1.2 kam TPM 2.0, veröffentlicht 2014 und als ISO/IEC 11889 internationaler Standard. Die TCG stellt die Referenz-Implementierung unter eine royalty-free Copyright-Lizenz, das Patentregime zwischen den Mitgliedern ist RAND. Damit war der Nachbau möglich und dem Patenthebel die Grundlage entzogen.

Linux hat es dann einfach implementiert. Der Treiber tpm_tis sitzt im Kernel, IBM brachte TrouSerS für TPM 1.2, für TPM 2.0 entstand mit Beteiligung von Intel und TCG der tpm2-tss-Stack samt tpm2-tools. Seit Linux 4.12 gibt es den Resource Manager im Kernel unter /dev/tpmrm0, wodurch der frühere Userspace-Daemon tpm2-abrmd für die meisten Fälle überflüssig wurde. Nichts davon brauchte eine Lizenz von Microsoft.

Die befürchtete Abriegelung kam trotzdem, nur von woanders. Kein einziger der Horror-Fälle aus der TCPA-FAQ wurde durch den TPM Realität. Wo Nutzer heute tatsächlich ausgesperrt werden, steckt eine andere Technik dahinter: Widevine beim Streaming, Play Integrity und früher SafetyNet bei Android, verriegelte Bootloader bei Telefonen, die Secure Enclave bei Apple, Attestierung bei Spielkonsolen. Der TPM wurde stattdessen ein langweiliger Schlüsselspeicher.

Ein Teil der Angst hat sich dann doch erfüllt, nur in anderer Form. Windows 11 macht TPM 2.0 zur harten Voraussetzung, und damit gilt funktionierende Hardware plötzlich als nicht unterstützt. Das ist keine DRM-Geschichte, sondern eine Elektroschrott- und Lebensdauer-Geschichte. Der Mechanismus ist aber derselbe: eine Hardware-Eigenschaft entscheidet, was auf dem Gerät laufen darf.

Und dann kam der Kreis zurück. 2023 schlugen Chrome-Entwickler bei Google die Web Environment Integrity API vor. Der Browser sollte sich von einer Vertrauensinstanz einen Nachweis über seine Umgebung ausstellen lassen, den Webseiten dann prüfen können. Das ist praktisch Wort für Wort das Szenario, vor dem Anderson zwanzig Jahre früher gewarnt hatte, nur ohne TPM. Nach massivem Widerstand zog Google den Vorschlag im November 2023 für Chromium auf dem Desktop zurück.

Hat die Patentanmeldung von damals also geholfen?

Das ist die Frage, mit der ich in die Recherche gegangen bin, und die Antwort ist zweiteilig. Die defensive Patentanmeldung hat, soweit öffentlich nachvollziehbar, nichts bewirkt. Es gibt kein erteiltes Patent, das man heute als den Grund benennen könnte, warum TCPA-DRM nicht kam. Der Gegenzug war eine wirksame Geste, aber kein wirksames Rechtsmittel. Gewirkt hat etwas anderes: erstens die Wirtschaftlichkeit, weil die Softwarehersteller nicht umschreiben wollten und es damit kein Produkt gab, zweitens die Öffnung der Spezifikation und die ISO-Standardisierung, die den Nachbau erlaubten.

Der zweite Teil verdient Anerkennung. Die Kampagne selbst hat gewirkt, nur nicht juristisch, sondern politisch. Der Lärm um TCPA hat plausibel dazu beigetragen, dass die TCG die Spezifikation öffnete, die aggressivsten Ideen fallen ließ und dass Fernattestierung zwanzig Jahre lang aus dem Consumer-Web draußen blieb. Als der Versuch 2023 mit Web Environment Integrity wiederkam, war das Muster des Widerstands eingeübt und der Vorschlag nach Monaten weg. Wichtig dabei: das ist meine Deutung. Die Kausalkette von der Kampagne 2002 zur offenen Spezifikation 2014 ist nirgends dokumentiert, das ist ein Plausibilitätsargument und keine Messung.

Bleibt der Eindruck: die Angst war berechtigt und falsch adressiert. Berechtigt, weil die Mechanik der Fernattestierung tatsächlich genau das kann, was befürchtet wurde. Falsch adressiert, weil der TPM davon der harmloseste Teil war und am Ende zu dem wurde, was jetzt kommt. Ein langsamer, sturer kleiner Chip, der Schlüssel nicht herausgibt.

Erst suchen, ganz ohne TPM-Werkzeug

Bevor ihr irgendetwas installiert: der Kernel weiß längst, ob da ein Chip sitzt. Er sagt es beim Start.

# dmesg | grep -i tpm
[    0.000000] efi: ACPI=0x7990e000 ACPI 2.0=0x7990e014 TPMFinalLog=0x713bb000 SMBIOS=0x7035e000 SMBIOS 3.0=0x7035b000 ESRT=0x70358c98 MEMATTR=0x5f5c2018 MOKvar=0x70323000 INITRD=0x592eda98 RNG=0x798ce018 TPMEventLog=0x798c0018
[    0.010528] ACPI: SSDT 0x0000000079905000 000554 (v01 INTEL  Tpm2Tabl 00001000 INTL 20160422)
[    0.010531] ACPI: TPM2 0x0000000079904000 000034 (v04 FUJ    PC       01170000 FUJ  00000001)
[    0.010607] ACPI: Reserving TPM2 table memory at [mem 0x79904000-0x79904033]
[    0.569145] tpm_tis MSFT0101:00: 2.0 TPM (device-id 0x1B, rev-id 16)

Drei Dinge stehen da drin. In der ersten Zeile übergibt UEFI die Adresse des Event-Logs, TPMEventLog=0x798c0018, also der Liste aller Messungen aus dem Startvorgang. Dann die ACPI-Tabelle TPM2, über die die Firmware mitteilt, wo und wie der Chip ansprechbar ist. Und in der letzten Zeile das Ergebnis: der Treiber tpm_tis hat unter der ACPI-Kennung MSFT0101 ein TPM der Version 2.0 gefunden.

Danach existieren zwei Gerätedateien, und der Unterschied zwischen ihnen ist wichtig.

# ls -la /dev/tpm*
crw-rw---- 1 tss root  10,   224 Aug 10 09:31 /dev/tpm0
crw-rw---- 1 tss tss  252, 65536 Aug 10 09:31 /dev/tpmrm0

/dev/tpm0 ist der rohe Zugang zum Chip. Daran kann genau ein Prozess gleichzeitig arbeiten, und wer die Ressourcen im Chip verwaltet, ist selbst dafür verantwortlich. /dev/tpmrm0 geht über den Resource Manager im Kernel, der das Ein- und Auslagern der Schlüssel-Kontexte übernimmt und mehrere Nutzer nebeneinander erlaubt. In der Praxis nimmt man immer /dev/tpmrm0, und die tpm2-tools tun das von sich aus.

Die Version steht ebenfalls im sysfs, und die solltet ihr prüfen, bevor ihr weiterlest.

# ls /sys/class/tpm/tpm0/
dev  device  pcr-sha1  pcr-sha256  power  ppi  subsystem  tpm_version_major  uevent

# cat /sys/class/tpm/tpm0/tpm_version_major
2

Eine 2 heißt TPM 2.0 und alles in diesem Beitrag gilt. Eine 1 heißt TPM 1.2, und dann gilt fast nichts davon, weil es ein anderer Standard mit einem anderen Software-Stack ist. Nebenbei verrät das Verzeichnis noch etwas: es gibt eine pcr-sha1– und eine pcr-sha256-Bank, der Chip führt die Messregister also in zwei Hash-Verfahren parallel.

Und weil der Kernel das ohnehin bereitstellt, kommt hier der erste kleine Aha-Moment, noch ganz ohne installiertes Paket. Die Messwerte des Startvorgangs liegen als Dateien herum.

# cat /sys/class/tpm/tpm0/pcr-sha256/0
7DE4ABE4ED8D8291D9B58D71F3B2988F5DA81EBE58D4AE518012E877FA1E04F1
# cat /sys/class/tpm/tpm0/pcr-sha256/1
41CBF90AFF5CEEFAA9E9C52E7A3D5B4C8518EA65861C753AF8DB005C5330F53F
# cat /sys/class/tpm/tpm0/pcr-sha256/7
F5841722D3DCC8886F14E92CA2D7304932CF17E2247A85D3B7BB41FE2C02CB4E

Das sind drei der Platform Configuration Register, kurz PCR. Merkt euch den Wert von PCR 7, der taucht später mehrfach auf.

Die Falle mit lsmod

Das ist eine häufige Fehldiagnose, deshalb steht sie hier als eigener Punkt. Auf meinem Testsystem liefert lsmod | grep tpm nämlich schlicht nichts. Kein Modul, keine Ausgabe. Der Chip arbeitet trotzdem einwandfrei, weil tpm_tis in diesen Kernel fest eingebaut ist und deshalb in der Modulliste gar nicht erscheinen kann. Wer nach lsmod urteilt, hält ein funktionierendes TPM für abwesend. Fragt stattdessen nach der Treiberbindung.

# ls -l /sys/class/tpm/tpm0/device/driver
lrwxrwxrwx 1 root root 0 Aug 10 09:31 /sys/class/tpm/tpm0/device/driver -> ../../../bus/platform/drivers/tpm_tis

# cat /sys/class/tpm/tpm0/device/modalias
acpi:MSFT0101:MSFT0101:

Der Symlink zeigt, welcher Treiber das Gerät tatsächlich bedient. Das ist die Antwort auf die Frage, die lsmod nicht beantworten kann.

Wenn nichts auftaucht

Bleibt dmesg stumm und existiert kein /dev/tpm0, dann gibt es drei realistische Ursachen, in dieser Reihenfolge.

• Im Firmware-Setup abgeschaltet. Die Option heißt je nach Hersteller „Security Device Support“, „TPM State“, „Trusted Computing“, „PTT“ oder „fTPM“. Wo diese Menüs bei einem Serverboard liegen und wie man sich dort zurechtfindet, habe ich in der BIOS-Serie ausführlich aufgeschrieben.
• Physisch nicht vorhanden. Bei Server-Boards ist der TPM oft ein steckbares Modul auf einem eigenen Header, bei Supermicro etwa die AOM-TPM-Module auf dem Anschluss JTPM1. Wer ihn nicht mitbestellt hat, hat einen leeren Steckplatz. Bei Notebooks ist der Chip dagegen fast immer verlötet.
• Vorhanden, aber als fTPM in der CPU statt als eigener Chip. Woran man das unterscheidet, steht weiter unten, und man liest es an einer einzigen Zeile ab.

Zwei Details aus dem Firmware-Setup, die hier gut passen. Erstens sind SHA-1-Bank und SHA-256-Bank oft getrennt schaltbar. Dass mein Testgerät beide Banks führt, ist also keine Selbstverständlichkeit, sondern eine Einstellung. Zweitens steht in demselben Menü meist ein TPM Clear. Finger weg, solange ihr nicht genau wisst, was daran hängt. Ein Clear wirft die Hierarchien im Chip weg, und damit ist alles, was gegen diesen Chip versiegelt war, unwiederbringlich verloren. Auch der BitLocker-Schlüssel eines parallel installierten Windows.

Die Schichten, bevor das erste Paket installiert wird

Es hilft, den Stack einmal von unten nach oben gesehen zu haben. Sonst installiert man ein Paket und wundert sich später, welche der vielen Bibliotheken wofür zuständig ist.

Der Weg eines Kommandos vom Werkzeug bis in den Chip. Über /dev/tpm0 arbeitet genau ein Prozess, über /dev/tpmrm0 mehrere.

Ganz unten der Chip, darüber der Kerneltreiber, darüber die beiden Gerätedateien. Erst dann kommt Userspace: die TCTI-Schicht kümmert sich um den Transport zur Gerätedatei, die ESAPI-Schicht um Kommandos, Sessions und HMAC-Absicherung. Ganz oben die drei Werkzeuge, die man tatsächlich in die Hand nimmt. Für die Pflichtausstattung reichen zwei Pakete.

Paket

Wofür

tpm2-tools

die tpm2_*-Kommandozeile, alles in diesem Beitrag läuft darüber

libtss2-*

der TSS2-Stack darunter, meist schon über systemd installiert

Dazu zwei optionale, die ich beide benutze, weil sie den Chip an Software anschließen, die von TPM nichts wissen muss.

Paket

Wofür

tpm2-openssl

Provider für OpenSSL 3, Schlüssel im Chip über die gewohnten openssl-Aufrufe

libtpm2-pkcs11-1 und libtpm2-pkcs11-tools

PKCS#11-Schnittstelle, damit SSH und Browser den Chip nutzen können

Und zwei, die ich ausdrücklich nicht installiere.

Paket

Warum nicht

tpm2-abrmd

Resource Manager im Userspace mit D-Bus-Schnittstelle. Seit Linux 4.12 macht der Kernel das über /dev/tpmrm0 selbst. Das Projekt ist nicht tot, es wird weiter gepflegt und ist für Simulatoren, Tests und manche Integrationen nach wie vor sinnvoll. Beides parallel zu betreiben führt aber zu Konflikten, deshalb hier bewusst nur der Kernel-Weg.

clevis, clevis-tpm2

binden ausschließlich LUKS2-Header. Ohne LUKS nutzlos, und auf diesem Gerät gibt es kein LUKS.

# apt-get install -y tpm2-tools tpm2-openssl libtpm2-pkcs11-1 libtpm2-pkcs11-tools

Auf meinem Mint 22.3 sind damit tpm2-tools 5.6, tpm2-openssl 1.2.0 und tpm2-pkcs11 1.9.0 gelandet. Der TSS2-Stack war schon da, den bringt systemd mit. Auf Fedora und RHEL heißt das Hauptpaket ebenfalls tpm2-tools, dazu tpm2-tss, unter Arch genauso tpm2-tools mit tpm2-tss als Abhängigkeit.

Eine Kleinigkeit, über die jeder beim ersten Mal stolpert: /dev/tpmrm0 gehört tss:tss. Entweder arbeitet ihr mit sudo, oder ihr nehmt euren Benutzer in die Gruppe tss auf. Die Rechte in der Ausgabe von ls -la /dev/tpm* weiter oben sagen genau das, crw-rw---- und keine Rechte für alle anderen.

Spricht der Chip?

Es gibt drei Stufen, aufsteigend im Aussagewert. Die erste ist der Lebenstest.

# tpm2_getrandom --hex 16

Kommen 16 Bytes zurück, dann funktioniert die ganze Kette von der Bibliothek über die Gerätedatei bis in die Hardware. Der Zufall kommt dabei wirklich aus dem Chip, und er ist gemächlich, dazu unten die Zahlen. Stufe zwei ist tpm2_getcap properties-fixed, da sagt der Chip, wer er ist. Stufe drei ist tpm2_getcap properties-variable, da sagt er, in welchem Zustand er ist. Beide sind gleich interessant, nur aus unterschiedlichen Gründen.

Wer ist dieser Chip

# tpm2_getcap properties-fixed
TPM2_PT_FAMILY_INDICATOR:
  raw: 0x322E3000
  value: "2.0"
TPM2_PT_LEVEL:
  raw: 0
TPM2_PT_REVISION:
  raw: 0x74
  value: 1.16
TPM2_PT_DAY_OF_YEAR:
  raw: 0x109
TPM2_PT_YEAR:
  raw: 0x7E0
TPM2_PT_MANUFACTURER:
  raw: 0x49465800
  value: "IFX"
TPM2_PT_VENDOR_STRING_1:
  raw: 0x534C4239
  value: "SLB9"
TPM2_PT_VENDOR_STRING_2:
  raw: 0x36373000
  value: "670"
TPM2_PT_VENDOR_TPM_TYPE:
  raw: 0x0
TPM2_PT_FIRMWARE_VERSION_1:
  raw: 0x7003F
TPM2_PT_FIRMWARE_VERSION_2:
  raw: 0xD1900
TPM2_PT_INPUT_BUFFER:
  raw: 0x400
TPM2_PT_HR_TRANSIENT_MIN:
  raw: 0x3
TPM2_PT_HR_PERSISTENT_MIN:
  raw: 0x7
TPM2_PT_ACTIVE_SESSIONS_MAX:
  raw: 0x40
TPM2_PT_PCR_COUNT:
  raw: 0x18
TPM2_PT_NV_COUNTERS_MAX:
  raw: 0x8
TPM2_PT_NV_INDEX_MAX:
  raw: 0x680

Rohe Hex-Werte, die plötzlich Sinn ergeben, wenn man sie einmal übersetzt. Das ist einer meiner Lieblingsmomente an dem ganzen Thema.

• TPM2_PT_MANUFACTURER: 0x49465800 ist ASCII IFX, also Infineon.
• VENDOR_STRING_1 und _2 ergeben zusammengesetzt SLB9 und 670, also ein Infineon OPTIGA SLB 9670.
• TPM2_PT_REVISION: 0x74 ist Spezifikations-Revision 1.16, datiert auf Tag 265 des Jahres 2016.
• FIRMWARE_VERSION_1: 0x7003F ist Firmware 7.63.
• TPM2_PT_PCR_COUNT: 0x18 sind 24 PCRs.
• TPM2_PT_HR_PERSISTENT_MIN: 0x7 heißt, dass nur sieben persistente Schlüsselplätze garantiert sind. Diese Zahl wird später richtig wichtig.
• TPM2_PT_NV_COUNTERS_MAX: 0x8 sind genau acht monotone Zähler.

Und dann TPM2_PT_NV_INDEX_MAX: 0x680, also 1664. Hier lauert eine Fehldeutung, die in vielen Texten steht: das ist nicht der gesamte NV-Speicher des Chips, sondern die maximale Größe eines einzelnen NV-Index-Datenbereichs. Wie viel NV insgesamt frei ist, sagt diese Eigenschaft überhaupt nicht. Das steht im Datenblatt des Herstellers und liegt bei diesem Chip im Bereich einiger Kilobyte. Ich habe es nicht ermittelt, also behaupte ich hier auch keine Gesamtgröße.

Diskreter Chip oder fTPM in der CPU

Diese Unterscheidung ist keine Nebensächlichkeit, und man liest sie direkt am Hersteller-String ab.

Hersteller-String

Was es ist

IFX, NTC, STM, IBM

diskreter Chip auf dem Board oder auf einem Steckmodul

INTC

Intel Platform Trust Technology, läuft in der Management Engine

AMD

AMD fTPM, läuft im Platform Security Processor

Ein diskreter Chip hängt an einem physischen Bus, den man anzapfen kann. Ein fTPM hat diesen Bus nicht, dafür hat er andere Probleme. Beides kommt im Angriffs-Abschnitt zurück.

Für mein Testsystem ist die Sache klar: IFX, also ein diskreter Infineon SLB 9670. Aus Linux-Sicht hängt er als memory-mapped TIS an der ACPI-Kennung MSFT0101 und wird von tpm_tis bedient. Ob die physische Leitung dahinter LPC oder SPI ist, lässt sich aus dem Betriebssystem allein nicht entscheiden, weil der PCH einen SPI-TPM auch als MMIO-TIS durchreichen kann. Das ist also plausibel, aber nicht gemessen. Die einzige echte Antwort wäre ein Foto vom offenen Gerät, und dafür müsste das Notebook auseinander.

32 Fehlversuche, und deshalb reicht eine kurze PIN

Jetzt der Zustand, und das ist der wichtigste einzelne Abschnitt des ganzen Beitrags, weil er später alles trägt.

# tpm2_getcap properties-variable
TPM2_PT_PERMANENT:
  ownerAuthSet:              0
  endorsementAuthSet:        0
TPM2_PT_STARTUP_CLEAR:
  phEnable:                  1
  shEnable:                  1
TPM2_PT_LOCKOUT_COUNTER: 0x0
TPM2_PT_MAX_AUTH_FAIL: 0x20
TPM2_PT_LOCKOUT_INTERVAL: 0x1C20
TPM2_PT_LOCKOUT_RECOVERY: 0x15180

Diese drei Werte werden fast immer verwechselt, also einmal sauber.

• MAX_AUTH_FAIL: 0x20 sind 32 fehlgeschlagene Authentifizierungsversuche, danach sperrt der Chip.
• LOCKOUT_INTERVAL: 0x1C20 sind 7200 Sekunden, also 2 Stunden. Nach dieser Zeit wird der Fehlerzähler um genau eins verringert.
• LOCKOUT_RECOVERY: 0x15180 sind 86400 Sekunden, also 24 Stunden. Das ist aber nicht die Erholung des normalen Zählers, sondern die Wartezeit, bevor nach einem fehlgeschlagenen Versuch mit lockoutAuth erneut mit lockoutAuth gearbeitet werden darf.

Einmal vorgerechnet, weil die Zahlen so viel deutlicher sind: ein einzelner Fehlversuch altert nach 2 Stunden aus. Von 32 verbrauchten Versuchen zurück auf null dauert also 64 Stunden und nicht 24.

Und das ist der eigentliche Mehrwert des ganzen Bauteils. Der Chip zählt Fehlversuche und sperrt. Deshalb reicht bei einem TPM eine sechsstellige PIN, wo ein Passwort-Hash auf der Platte eine Passphrase mit hoher Entropie bräuchte. Wer die Platte hat, probiert Millionen Passphrasen pro Sekunde durch. Wer vor dem TPM sitzt, bekommt 32 Versuche und darf dann zwei Stunden warten, um einen einzigen zurückzubekommen. Die Stärke kommt nicht aus dem Geheimnis, sie kommt aus der Hardware, die das Raten unterbindet. Fast jeder Text über TPM lässt diesen Punkt weg, und dann klingt die kurze PIN nach Leichtsinn.

Das Geburtszertifikat des Chips

Jetzt kommt der Teil, den ich in keinem der üblichen TPM-Howtos gesehen habe. In dem Chip liegt ab Werk ein Zertifikat, ausgestellt vom Hersteller auf den Endorsement Key. Erst die Liste der belegten NV-Indizes, dann das Zertifikat selbst.

# tpm2_getcap handles-nv-index
- 0x1410001
- 0x1410002
- 0x1410003
- 0x1800100
- 0x1810008
- 0x1820002
- 0x1880001
- 0x1880011
- 0x1C00002
- 0x1C0000A
- 0x1C10102
- 0x1C10103
- 0x1C10104
- 0x1C10105

# tpm2_nvreadpublic 0x1C00002
0x1c00002:
  name: 000bcfecbb34d24d7356b39b8a0fb0c82c7b052a0335fc8ca2fa602cf1395e5ff804
  hash algorithm:
    friendly: sha256
    value: 0xB
  attributes:
    friendly: ppwrite|writedefine|ppread|ownerread|authread|no_da|written|platformcreate
    value: 0x62072001
  size: 1184

0x1C00002 ist der TCG-Standardindex für das RSA-EK-Zertifikat, 0x1C0000A derselbe für ECC. 1184 Bytes, das passt zu einem X.509-Zertifikat. Also raus damit und mit gewohnten Werkzeugen anschauen.

# tpm2_nvread 0x1C00002 -o ek_rsa.der
WARN: Reading full size of the NV index

# openssl x509 -inform der -in ek_rsa.der -noout -subject -issuer -dates
subject=
issuer=C = DE, O = Infineon Technologies AG, OU = OPTIGA(TM) TPM2.0, CN = Infineon OPTIGA(TM) RSA Manufacturing CA 035
notBefore=Aug 21 14:09:40 2019 GMT
notAfter=Aug 21 14:09:40 2034 GMT

Zwei Dinge fallen sofort auf. Der Aussteller ist eine echte Hersteller-CA, „Infineon OPTIGA(TM) RSA Manufacturing CA 035“, und Infineon hat diesen Chip am 21. August 2019 signiert. Und der Subject ist leer. Ein TPM hat keinen Namen. Die Identität steckt woanders, nämlich in den Erweiterungen.

# openssl x509 -inform der -in ek_rsa.der -noout -text
            X509v3 Key Usage: critical
                Key Encipherment
            X509v3 Subject Alternative Name: critical
                DirName:/2.23.133.2.1=id:49465800/2.23.133.2.2=SLB 9670 TPM2.0/2.23.133.2.3=id:073f
            X509v3 Basic Constraints: critical
                CA:FALSE
            X509v3 CRL Distribution Points:
                Full Name:
                  URI:http://pki.infineon.com/OptigaRsaMfrCA035/OptigaRsaMfrCA035.crl
            X509v3 Certificate Policies:
                Policy: 1.2.276.0.68.1.20.1
            X509v3 Extended Key Usage:
                2.23.133.8.1

Der Subject Alternative Name trägt drei TCG-OIDs, und die decken sich exakt mit dem, was der Chip vorher selbst über sich gesagt hat. 2.23.133.2.1 ist der Hersteller, id:49465800, also wieder IFX. 2.23.133.2.2 ist das Modell, SLB 9670 TPM2.0. 2.23.133.2.3 ist die Firmware, id:073f, was genau die 7.63 von oben bestätigt. Die Extended Key Usage 2.23.133.8.1 ist tcg-kp-EKCertificate, dieses Zertifikat darf also nichts anderes sein als der Nachweis eines Endorsement Keys. Und Infineon veröffentlicht dazu eine Sperrliste.

Was ich hier bewusst weglasse, sind die Zertifikats-Seriennummer und der öffentliche EK-Schlüssel. Beide kennzeichnen dauerhaft und eindeutig genau dieses eine Notebook, und die TCG behandelt den EK aus genau diesem Grund als datenschutzrelevant. Damit erklärt sich beiläufig, warum es überhaupt Attestierungsschlüssel gibt: damit man für eine Attestierung nicht jedes Mal die dauerhafte Chip-Identität vorzeigen muss.

Das hier ist die Wurzel, auf der Fernattestierung aufsetzt. Ein Prüfer kann feststellen, dass in dieser Maschine ein echter, von Infineon signierter TPM sitzt, ohne dem Betriebssystem eine einzige Zeile zu glauben. Genau formuliert beweist das Zertifikat aber nur die Echtheit des Chips. Dass ein bestimmter Attestierungsschlüssel wirklich in diesem Chip liegt, ist ein zusätzlicher Schritt, und den nehme ich mir im Server-Teil vor.

Drei Dinge, alles andere ist Kombination

Bevor irgendein Anwendungsfall kommt: ein TPM bietet im Kern nur drei Dinge an. Alles, was danach als Feature verkauft wird, ist eine Kombination daraus.

• Schlüssel, die nicht herauskommen. Ein Schlüssel mit dem Attribut fixedTPM wird im Chip erzeugt und verlässt ihn nie. Man kann ihn benutzen, man kann ihn nicht kopieren.
• PCRs, Register die nur wachsen. 24 Register, hier mit SHA-1- und SHA-256-Bank. Man kann sie nicht setzen, nur erweitern, und die Rechenvorschrift dafür ist neu = hash(alt || messwert). Bei den Registern, auf die es ankommt, nämlich PCR 0 bis 15 auf einer PC-Client-Plattform, geht es nur über einen Neustart zurück. Deshalb kann man die Boot-Historie nicht nachträglich fälschen. Zwei Ausnahmen gehören dazu, sonst wird es ungenau: PCR 16 und PCR 23 sind zur Laufzeit zurücksetzbar. PCR 16 ist ausdrücklich als Debug-Register vorgesehen, und genau deshalb benutze ich es weiter unten für die Demonstration. Gegen ein zurücksetzbares PCR versiegelt niemand etwas Echtes.
• Sealing, Geheimnisse an einen Zustand binden. Ein Geheimnis wird so verschlüsselt, dass der Chip es nur herausgibt, wenn eine Policy erfüllt ist, typischerweise ein bestimmter PCR-Zustand.

Dazu kommen als Nebenfunktionen die schon erwähnten monotonen Zähler, ein winziger NV-Speicher, ein Zufallszahlengenerator und die Lockout-Logik von oben.

Und weil es das häufigste Missverständnis überhaupt ist, gleich früh und deutlich: ein TPM ist kein Krypto-Beschleuniger, keine Secure Enclave mit eigener Rechenumgebung und kein Schutz gegen einen kompromittierten laufenden Kernel. Er schützt Schlüssel im Ruhezustand und er misst den Startvorgang. Wenn der laufende Kernel übernommen ist, benutzt der Angreifer den TPM einfach mit, ganz höflich über dieselbe Schnittstelle.

Measured Boot in acht Befehlen

Genug Theorie, jetzt der Beweis. Ich baue eine Policy aus dem aktuellen Zustand von PCR 7, erzeuge einen Primary Key im Chip und versiegle damit ein Geheimnis.

# tpm2_startauthsession -S session.ctx
# tpm2_policypcr -S session.ctx -l sha256:7 -L pcr7.policy
76a916a90c7c0906a930cd5cd3e501cb43007331a8b7444222d8aa4c5475f53f
# tpm2_flushcontext session.ctx

Der Hash ist die Policy, und er hängt am Inhalt von PCR 7. Dann der Schlüssel, und ich messe gleich mit, weil die Zahl später noch gebraucht wird.

# time tpm2_createprimary -C o -g sha256 -G ecc256 -c primary.ctx
  value: aes
  raw: 0x6
sym-mode:
  value: cfb
  raw: 0x43
sym-keybits: 128
x: 2be770ed8755bf6f454cb1fea18ba722526d1ee3e9080ab94edda0480b73529d
y: af840b9c69dcac45c9aa3a04085ced5c750bfef5e70c470e4481592ff3026dc7

real	0m0.537s

# echo -n "geheim-nur-bei-diesem-boot" > secret.txt
# tpm2_create -C primary.ctx -g sha256 -u seal.pub -r seal.priv -L pcr7.policy -i secret.txt
keyedhash: ef1dc0bffd0d7529a6d0b44f79bdd14fb8829995c998ffb14d88936f82d3e9f3
authorization policy: 76a916a90c7c0906a930cd5cd3e501cb43007331a8b7444222d8aa4c5475f53f

# tpm2_load -C primary.ctx -u seal.pub -r seal.priv -c seal.ctx
name: 000b50ac9b197a947de6d2ff47d9d80748d4fa1453754bee5f3a8627e307cf8c84fd

# tpm2_startauthsession --policy-session -S s.ctx
# tpm2_policypcr -S s.ctx -l sha256:7
# tpm2_unseal -p session:s.ctx -c seal.ctx
geheim-nur-bei-diesem-boot

Das Geheimnis kommt zurück, weil PCR 7 noch genau den Wert hat, gegen den versiegelt wurde. Schön, beweist aber noch nichts. Interessant wird es erst, wenn sich die Messung ändert.

Dafür wechsle ich auf PCR 16, das Debug-Register. Der Grund ist praktisch: PCR 16 lässt sich ohne Neustart und ohne Firmware-Änderung erweitern, damit ist die Demonstration in einer einzigen Terminal-Sitzung reproduzierbar. Der Mechanismus ist derselbe wie bei PCR 7.

# tpm2_pcrread sha256:16
  sha256:
    16: 0x0000000000000000000000000000000000000000000000000000000000000000

# tpm2_startauthsession -S t.ctx
# tpm2_policypcr -S t.ctx -l sha256:16 -L pcr16.policy
# tpm2_flushcontext t.ctx
# echo -n "unlock-key-material" > s16.txt
# tpm2_create -C primary.ctx -g sha256 -u s16.pub -r s16.priv -L pcr16.policy -i s16.txt
# tpm2_load -C primary.ctx -u s16.pub -r s16.priv -c s16.ctx

# tpm2_startauthsession --policy-session -S p.ctx
# tpm2_policypcr -S p.ctx -l sha256:16
# tpm2_unseal -p session:p.ctx -c s16.ctx
unlock-key-material
# tpm2_flushcontext p.ctx

Und jetzt ändere ich die Messung. Das folgende Kommando ist genau das, was ein ausgetauschter Bootloader auch täte, nur mit einem selbstgewählten Messwert.

# tpm2_pcrextend 16:sha256=$(echo -n "boese-veraenderung" | sha256sum | cut -d" " -f1)
# tpm2_pcrread sha256:16
  sha256:
    16: 0xC6FE6738E4DDC92E1C8E18E290469CCB6B6D305BC1295C4F72B85D0922C25930

Derselbe Unseal-Aufruf wie zwei Blöcke vorher, Zeichen für Zeichen identisch:

# tpm2_startauthsession --policy-session -S p2.ctx
# tpm2_policypcr -S p2.ctx -l sha256:16
# tpm2_unseal -p session:p2.ctx -c s16.ctx
WARNING:esys:src/tss2-esys/api/Esys_Unseal.c:295:Esys_Unseal_Finish() Received TPM Error
ERROR:esys:src/tss2-esys/api/Esys_Unseal.c:98:Esys_Unseal() Esys Finish ErrorCode (0x0000099d)
ERROR: Esys_Unseal(0x99D) - tpm:session(1):a policy check failed
ERROR: Unable to run tpm2_unseal
exit=1

0x99D ist TPM_RC_POLICY_FAIL. Das Geheimnis liegt noch im Blob, es ist nicht gelöscht, es ist nur unerreichbar, solange PCR 16 diesen Wert trägt. Und jetzt der Punkt, auf den es mir ankommt: das ist keine Zugriffskontrolle im Betriebssystem. Da hat kein Dateisystem eine Berechtigung geprüft und kein Dienst eine Regel angewendet. Das ist eine Weigerung der Hardware. Sudo hilft hier nicht, weil root für diese Entscheidung überhaupt nicht zuständig ist.

Wer was misst, und was am Ende über das Entsiegeln entscheidet.

Und wenn ich das Register einfach zurücksetze?

Das ist die Frage, die jeder aufmerksame Leser an dieser Stelle stellt, und sie ist völlig berechtigt. Bei PCR 16 geht das tatsächlich, ohne Neustart.

# tpm2_pcrread sha256:16
  sha256:
    16: 0xC6FE6738E4DDC92E1C8E18E290469CCB6B6D305BC1295C4F72B85D0922C25930
# tpm2_pcrreset 16
# echo $?
0
# tpm2_pcrread sha256:16
  sha256:
    16: 0x0000000000000000000000000000000000000000000000000000000000000000

Dasselbe Kommando gegen PCR 7 lehnt die Hardware ab.

# tpm2_pcrreset 7
ERROR: Esys_PCR_Reset(0x907) - tpm:warn(2.0): bad locality
ERROR: Could not reset PCR index: 7
ERROR: Unable to run tpm2_pcrreset

0x907 ist TPM_RC_LOCALITY. Der Chip unterscheidet, aus welcher Vertrauensstufe ein Kommando kommt, und root auf dem laufenden System hat die Locality, die zum Zurücksetzen eines Boot-Mess-Registers nötig wäre, gar nicht. Das ist der ganze Unterschied zwischen einem Debug-Register und einem Boot-Mess-Register, ausgedrückt in einer Fehlermeldung.

PCR 16 lässt sich zurücksetzen, PCR 7 nicht. Root ändert daran nichts.

Die Platte startet ohne Passphrase, aber nur mit PIN

Der Klassiker am Arbeitsplatz ist LUKS2 zusammen mit systemd-cryptenroll. Der Nutzen ist echt: das Notebook startet ohne Eingabe, und ein ausgebautes Laufwerk bleibt trotzdem verschlüsselt.

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

Ehrlichkeit an dieser Stelle: dieses Kommando habe ich nicht ausgeführt, und ich konnte es auch nicht. Die Maschine hat gar kein LUKS, die Wurzel liegt auf ZFS mit der ZFS-eigenen Verschlüsselung, aes-256-gcm. Der Befehl steht hier also als dokumentiertes Verfahren nach Manpage und nicht als Messung.

Das Wichtigste daran ist das --tpm2-with-pin=yes. Ohne PIN entsperrt sich das Gerät für jeden, der es einschaltet, und die Festplattenverschlüsselung schützt dann nur noch gegen den Ausbau der SSD, nicht gegen den Diebstahl des Rechners. Mit PIN greift die Lockout-Logik von weiter oben, und genau dadurch wird eine kurze PIN sicher.

Bei der Auswahl der PCRs gibt es dann einen echten Zielkonflikt, der meist verschwiegen wird.

• Nur PCR 7 gebunden übersteht Kernel-Updates, misst aber im Kern nur den Secure-Boot-Zustand. Das ist wenig Aussage für viel Bequemlichkeit.
• PCR 7 plus 11 gebunden, zusammen mit einem Unified Kernel Image, erfasst tatsächlich Kernel und initrd. Dafür bricht jedes Kernel-Update die Bindung, wenn man nicht mit signierter Policy arbeitet. Eine wichtige Präzisierung dazu, sonst erklärt man die Folgen falsch: PCR 11 ist kein reines Kernel-Register. systemd-stub misst dort das UKI hinein, danach schreibt systemd-pcrphase im Verlauf des Startvorgangs weitere Phasen-Messungen in dasselbe Register. Der Wert von PCR 11 hängt also davon ab, in welcher Boot-Phase man ihn liest, und genau darauf beruht der Trick, dass ein Geheimnis nur im initrd aufgeht und im laufenden System nicht mehr.
• PCR 0 bis 7 gebunden ist die strengste Variante, und dann sperrt euch jedes BIOS-Update aus. Das ist der Grund, warum es systemd-pcrlock gibt, das die erwarteten Messwerte vorab berechnet und die Policy nachzieht. Dieselbe Manpage bezeichnet sich allerdings selbst noch als experimentell.

Wer welches Register wofür benutzt, hat die UAPI Group in einer PCR-Registry für Linux zusammengetragen. Das ist die Tabelle, die man beim Basteln offen haben will.

Eine Lücke betrifft ziemlich viele Linux-Nutzer, deshalb sage ich sie deutlich: systemd-cryptenroll und clevis luks bind schreiben beide in einen LUKS2-Header. Wer seine Wurzel auf ZFS-Native-Encryption hat, hat keinen. Upstream-ZFS bringt keine TPM-Integration mit. Ein TPM-gestütztes Entsperren bräuchte dort ein eigenes tpm2_unseal, das zfs load-key füttert, gebaut ins initramfs. Das ist eine echte offene Baustelle und kein Rezept, das ich hier nebenbei hinschreibe.

Ein SSH-Schlüssel, der keine Datei hat

Das ist mein Lieblings-Anwendungsfall am Arbeitsplatz, weil der Nutzen in einem Satz erklärt ist. Ein Angreifer mit Lesezugriff auf ~/.ssh bekommt nichts Verwendbares. Der Schlüssel kann die Maschine nicht verlassen. Er ist nicht gestohlen, er ist an das Blech gebunden.

# export TPM2_PKCS11_STORE=/root/tpm-demo/pkcs11store
# mkdir -p $TPM2_PKCS11_STORE
# tpm2_ptool init --path=$TPM2_PKCS11_STORE
action: Created
id: 1

# tpm2_ptool addtoken --pid=1 --label=ssh --sopin=sopin123 --userpin=userpin123 --path=$TPM2_PKCS11_STORE
# tpm2_ptool addkey --algorithm=ecc256 --label=ssh --userpin=userpin123 --path=$TPM2_PKCS11_STORE
public:
  CKA_ID: '63316131396137363763316531666439'

Die CKA_ID wird pro Schlüssel erzeugt, bei euch steht dort etwas anderes. Den öffentlichen Teil holt man sich in einem Format, das sshd versteht, direkt über den PKCS#11-Provider.

# ssh-keygen -D /usr/lib/x86_64-linux-gnu/pkcs11/libtpm2_pkcs11.so
ecdsa-sha2-nistp256 AAAAE2VjZHNhLXNoYTItbmlzdHAyNTYAAAAIbmlzdHAyNTYAAABBBO+enW3ZwHsSq8vHLKliloTMR/fpDgWPfti+UQuad0YA8rIXGE8Q9adJqjO6PmZO1DCavBiJgttOE24qrO6BX/0=

Diese Zeile wandert wie gewohnt in authorized_keys. Und damit der Nachweis auch etwas wert ist, zeige ich ihn als Vorher und Nachher. Auf dieser Maschine liegt in /root/.ssh nämlich kein einziger privater Schlüssel, es gibt also keine zweite Erklärung für einen erfolgreichen Public-Key-Login.

# ls /root/.ssh/id_*
ls: cannot access '/root/.ssh/id_*': No such file or directory

# ssh -o BatchMode=yes root@localhost true
root@localhost: Permission denied (publickey,password).

Derselbe Login, nur mit dem Provider dazu:

# ssh -o PKCS11Provider=/usr/lib/x86_64-linux-gnu/pkcs11/libtpm2_pkcs11.so root@localhost 'echo LOGIN-OK-VIA-TPM; hostname; id -un'
LOGIN-OK-VIA-TPM
ErrorLap
root

Die PIN habe ich für diesen Test über SSH_ASKPASS nicht interaktiv geliefert, im Alltag fragt ssh einfach danach. Richtig sehenswert wird es aber mit -v, denn da erzählt OpenSSH selbst, mit welchem Bauteil es gerade arbeitet.

debug1: provider /usr/lib/x86_64-linux-gnu/pkcs11/libtpm2_pkcs11.so: manufacturerID <tpm2-software.github.io> cryptokiVersion 2.40 libraryDescription <TPM2.0 Cryptoki> libraryVersion 1.9
debug1: provider /usr/lib/x86_64-linux-gnu/pkcs11/libtpm2_pkcs11.so slot 0: label <ssh> manufacturerID <Infineon> model <SLB9670> serial <0000000000000000> flags 0x40d
debug1: Will attempt key:  ECDSA SHA256:otJuTNX5LzFzJKqbTu9UoYROpZSXMMWIWMZUe02v1D4 token
debug1: Will attempt key: /root/.ssh/id_rsa
debug1: Will attempt key: /root/.ssh/id_ecdsa
debug1: Will attempt key: /root/.ssh/id_ed25519
debug1: Will attempt key: /root/.ssh/id_dsa
debug1: Offering public key:  ECDSA SHA256:otJuTNX5LzFzJKqbTu9UoYROpZSXMMWIWMZUe02v1D4 token
debug1: Server accepts key:  ECDSA SHA256:otJuTNX5LzFzJKqbTu9UoYROpZSXMMWIWMZUe02v1D4 token

Drei Sachen daran finde ich stark. Erstens nennt OpenSSH den Chip beim Namen, manufacturerID <Infineon> model <SLB9670>. Der SSH-Client sagt dir, welches Bauteil da gerade unterschreibt. Zweitens steht der TPM-Schlüssel in der Kandidatenliste mit dem Wort token, wo bei allen anderen ein Dateipfad steht, und diese Dateien existieren nicht einmal. Dieser Kontrast in einem Bildschirm ist das ganze Argument: dieser Schlüssel hat keine Datei. Drittens wird der Token-Schlüssel zuerst probiert, noch vor den nicht existierenden Dateien.

OpenSSH nennt Hersteller und Modell des Chips. Der Schlüssel steht als token in der Liste, alle anderen Kandidaten sind Dateien, die es nicht gibt.

Lasst mal kurz etwas heraus zoomen 😀 Meine Frau weist mich grade auf mein RBF hin. Wenn ich so konzentriert am Computer sitze und wie in diesem Fall etwas schreibe, dann schaue ich wohl meinen Monitor an, als wenn ich ihn gleich töten möchte. Tjo, und nun? Nun zoomen wir wieder ins Thema!

Die Zahl, die meine eigene Erwartung widerlegt hat

Meine Annahme vor der Messung war schlicht: eine ECDSA-Signatur kostet im Chip rund 97 Millisekunden, also merkt man beim Login nichts. Gemessen kommt etwas anderes heraus.

Weg

5 Logins

pro Login

Aufschlag

Schlüssel auf der Platte, Referenzwert

1,552 s

etwa 310 ms

Referenz

PKCS11Provider bei jedem Aufruf

8,013 s

etwa 1603 ms

etwa 1293 ms

Token einmal im ssh-agent

2,806 s

etwa 561 ms

etwa 251 ms

Die Ursache ist lehrreich. Bei PKCS11Provider baut ssh bei jedem einzelnen Login die komplette Kette neu auf: Store öffnen, Primary Key im TPM erzeugen, Kindschlüssel laden, signieren. Allein die Erzeugung des Primary Keys habe ich weiter oben mit 0,537 Sekunden gemessen. Die eigentliche Signatur ist damit der kleinste Posten in der Rechnung.

# ssh-add -s /usr/lib/x86_64-linux-gnu/pkcs11/libtpm2_pkcs11.so
Card added: /usr/lib/x86_64-linux-gnu/pkcs11/libtpm2_pkcs11.so
# ssh-add -l
256 SHA256:otJuTNX5LzFzJKqbTu9UoYROpZSXMMWIWMZUe02v1D4 /usr/lib/x86_64-linux-gnu/libtpm2_pkcs11.so.1.9.0 (ECDSA)
# time (for i in 1 2 3 4 5; do ssh root@localhost true; done)
real	0m2.806s

Mit ssh-add -s passiert diese Initialisierung einmal pro Sitzung statt einmal pro Verbindung, und die PIN wird auch nur einmal abgefragt. Zwei Gründe, dieselbe Empfehlung, also ganz klar: nehmt ssh-add -s und nicht PKCS11Provider bei jedem Aufruf.

Zur Messhygiene, wie immer: fünf Logins pro Zeile über Loopback, jeweils mit vollem Verbindungsaufbau und Prozessstart, kleine Stichprobe, keine Streuung berechnet. Das sind Größenordnungen und keine Benchmarks.

Der Nebeneffekt, den niemand erwähnt

Diesen Punkt habe ich selbst erst beim Aufräumen gemerkt, und jeder, der dem SSH-Abschnitt folgt, läuft hinein. tpm2_ptool init legt stillschweigend einen Primary Key an und macht ihn persistent im Chip. Vor der Demo waren drei persistente Handles belegt, danach vier.

# tpm2_getcap handles-persistent
- 0x81000000
- 0x81000001
- 0x81000002
- 0x81010001

Und jetzt zurück zu einer Zahl von weiter oben: TPM2_PT_HR_PERSISTENT_MIN ist auf diesem Chip 0x7. Garantiert sind also nur sieben persistente Plätze, und drei davon waren schon vorher weg. Wer bei jedem Basteln ein Handle liegen lässt, macht den Chip irgendwann voll. Den eigenen Müll findet und räumt man so weg:

# tpm2_evictcontrol -C o -c 0x81000000
persistent-handle: 0x81000000
action: evicted

# tpm2_getcap handles-persistent
- 0x81000001
- 0x81000002
- 0x81010001

Dazu eine Warnung, die ich nicht deutlich genug schreiben kann: räumt niemals Handles weg, die ihr nicht selbst angelegt habt. Die drei anderen lagen auf meinem Gerät schon vorher dort, vermutlich aus der Hersteller-Provisionierung oder aus einem früheren Windows-Leben. Wer einen fremden Primary Key entfernt, vernichtet alles, was darunter versiegelt war. Der sichere Weg führt über den Token-Store, denn dort steht das Handle drin, das zum eigenen Werkzeug gehört. Bei mir war es genau das 0x81000000 aus der Ausgabe oben, und ich habe vor dem Entfernen im Store nachgesehen, statt der Reihenfolge zu vertrauen.

Schlüssel im Chip, benutzt über OpenSSL

Für alles, was kein PKCS#11 spricht, gibt es den OpenSSL-3-Provider. Der schönste Moment daran ist ein PEM-Header.

# openssl list -providers -provider tpm2
Providers:
  tpm2
    name: TPM 2.0 Provider
    version: 1.2.0
    status: active

# openssl genpkey -provider tpm2 -algorithm EC -pkeyopt group:P-256 -out tpmkey.pem
# head -2 tpmkey.pem
-----BEGIN TSS2 PRIVATE KEY-----
MIHPBgZngQUKAQOgAwEBAQIEQAAAAQRYAFYAIwALAAYAcgAAABAAEAADABAAINLL

Diese Datei enthält keinen privaten Schlüssel. Sie enthält einen Blob, den ausschließlich dieser eine Chip auspacken kann. Kopiert die Datei auf eine andere Maschine und sie ist wertlos. Signieren geht im Chip, prüfen geht überall.

# printf "attestiere-mich" > d.bin
# openssl pkeyutl -provider tpm2 -provider default -sign -inkey tpmkey.pem -rawin -digest sha256 -in d.bin -out d.sig
# stat -c%s d.sig
70
# openssl pkey -provider tpm2 -provider default -in tpmkey.pem -pubout -out tpmkey.pub.pem
# openssl pkeyutl -verify -pubin -inkey tpmkey.pub.pem -rawin -digest sha256 -in d.bin -sigfile d.sig
Signature Verified Successfully

Zum Prüfen habe ich nur den Standard-Provider gebraucht. Es ist eine ganz normale ECDSA-Signatur, die Gegenseite muss von einem TPM überhaupt nichts wissen. Deshalb lässt sich das in bestehende PKI einbauen, ohne irgendetwas umzustellen, und damit gehen Client-Zertifikate für VPN, 802.1X, mTLS und auch AWS IAM Roles Anywhere.

Der Zufallsgenerator, ehrlich klein geredet

Auf diesem System ist der TPM tatsächlich der Hardware-Zufallsgenerator, den der Kernel benutzt.

# cat /sys/class/misc/hw_random/rng_available
tpm-rng-0 none
# cat /sys/class/misc/hw_random/rng_current
tpm-rng-0

Der Nutzen davon ist vorhanden, aber klein. Moderne CPUs haben RDRAND, der Kernel hat einen guten Entropiepool, und rund 67 Millisekunden pro tpm2_getrandom-Aufruf sind für nichts geeignet, was Durchsatz braucht. Als zusätzliche, unabhängige Quelle im Pool ist es geschenkt und in Ordnung. Mehr würde ich daraus nicht machen.

Fernattestierung, der eigentliche große Fall

Auf Servern liegt der größere Nutzen, nicht am Arbeitsplatz. Das Problem zuerst: bei einer Kiste im Rechenzentrum oder in der Colo weiß man normalerweise nicht, ob sie noch die Software fährt, die man dort installiert hat. Alles, was man fragen kann, ist der Server selbst. Und wenn er kompromittiert ist, lügt er.

Der TPM löst das, weil er eine Aussage über den Startvorgang signiert, die das Betriebssystem nicht fälschen kann. Zwei Schlüssel braucht es dafür: den Endorsement Key als Chip-Identität und einen Attestierungsschlüssel, mit dem tatsächlich signiert wird.

# tpm2_createek -c ek.ctx -G rsa -u ek.pub
# tpm2_createak -C ek.ctx -c ak.ctx -G rsa -g sha256 -s rsassa -u ak.pub -n ak.name
loaded-key:
  name: 000b76c23ef9e6c736e89085381db5c9303c6aca84dd4b18785cbcd5820666146650
  qualified name: 000bfce15794118492a81739a638c4745d23eeffda268ef1d016f22bc07c7a0b5e65

Der qualified name ist didaktisch schön, weil er die Abstammung des Schlüssels von seinem Elternschlüssel mit einbezieht. Jetzt das Quote, mit einer Nonce, die sich der Prüfer ausdenkt. Ich nehme deadbeef in Hex.

# tpm2_quote -c ak.ctx -l sha256:0,1,4,7 -q 6465616462656566 -m quote.msg -s quote.sig -o pcr.bin -g sha256
quoted: ff54434780180022000bfce15794118492a81739a638c4745d23eeffda268ef1d016f22bc07c7a0b5e650008646561646265656600000002acc0c6460000020500000000010007003f000d190000000001000b0393000000201a782856983a34bde88eb32ea706d6863119ee0309e3e8296f0021d34ec896d5
pcrs:
  sha256:
    0 : 0x7DE4ABE4ED8D8291D9B58D71F3B2988F5DA81EBE58D4AE518012E877FA1E04F1
    1 : 0x41CBF90AFF5CEEFAA9E9C52E7A3D5B4C8518EA65861C753AF8DB005C5330F53F
    4 : 0xCDB9366A1664E6B6AE408E3DF98F2E5FF47BCD6F0EA19ACBABE643DE586853DD
    7 : 0xF5841722D3DCC8886F14E92CA2D7304932CF17E2247A85D3B7BB41FE2C02CB4E
calcDigest: 1a782856983a34bde88eb32ea706d6863119ee0309e3e8296f0021d34ec896d5

Der quoted-Blob sieht wie Rauschen aus, ist aber lesbar, wenn man weiß wo man hinschaut.

• ff544347 ist die Konstante TPM_GENERATED_VALUE und markiert die Struktur als im TPM entstanden. Wichtig für das Verständnis: sie allein verhindert keine Fälschung. Der Schutz entsteht daraus, dass ein Attestierungsschlüssel ein restricted Signaturschlüssel ist, der nur Daten unterschreibt, die der Chip selbst erzeugt hat. Diese Konstante ist das Erkennungsmerkmal dafür und nicht der Mechanismus.
• 8018 ist TPM2_ST_ATTEST_QUOTE, der Strukturtyp.
• 6465616462656566 ist meine Nonce, unverändert zurück. Genau das schlägt einen Replay.
• 07003f000d1900 ist die Firmware-Version, die in jedem Quote mitläuft. Das ist wieder die 7.63 von oben.

Geprüft wird offline, und zwar mit nichts als dem öffentlichen Attestierungsschlüssel.

# tpm2_readpublic -c ak.ctx -o ak.pem -f pem
# tpm2_checkquote -u ak.pem -m quote.msg -s quote.sig -f pcr.bin -g sha256 -q 6465616462656566
pcrs:
  sha256:
    0 : 0x7DE4ABE4ED8D8291D9B58D71F3B2988F5DA81EBE58D4AE518012E877FA1E04F1
    1 : 0x41CBF90AFF5CEEFAA9E9C52E7A3D5B4C8518EA65861C753AF8DB005C5330F53F
    4 : 0xCDB9366A1664E6B6AE408E3DF98F2E5FF47BCD6F0EA19ACBABE643DE586853DD
    7 : 0xF5841722D3DCC8886F14E92CA2D7304932CF17E2247A85D3B7BB41FE2C02CB4E
exit=0

Der Ablauf einer Attestierung. Der Prüfer glaubt dem Knoten nichts, er rechnet nach.

Die Lücke, die fast jedes Howto verschweigt

Und hier muss ich mich selbst bremsen, denn die Versuchung ist groß, die beiden vorherigen Abschnitte einfach nebeneinanderzulegen und „echte Hardware bestätigt echten Bootzustand“ daraus zu machen. Das wäre eine Beweiskette mit einem Loch in der Mitte.

tpm2_checkquote mit dem öffentlichen Attestierungsschlüssel beweist genau eine Sache: irgendjemand, der diesen Schlüssel besitzt, hat dieses Quote signiert. Es beweist nicht, dass dieser Schlüssel in demselben Chip steckt, dessen Infineon-Zertifikat ich weiter oben gezeigt habe.

Die fehlende Verbindung heißt Credential Activation. Der Prüfer verschlüsselt dabei ein Geheimnis so, dass es nur ausgepackt werden kann, wenn Endorsement Key und Attestierungsschlüssel im selben TPM liegen, klassisch über TPM2_MakeCredential auf der Prüferseite und TPM2_ActivateCredential auf der Knotenseite. Erst wenn der Knoten das Geheimnis zurückmelden kann, ist bewiesen, dass der Schlüssel zu diesem zertifizierten Chip gehört. Alternativ stellt eine Attestierungs-CA ein echtes AK-Zertifikat aus, nachdem sie diese Prüfung einmal gemacht hat. Wie das im Detail aussieht, steht in RFC 9683. Diesen Schritt habe ich hier nicht durchgeführt. Gemessen sind Quote und Signaturprüfung, die Bindung ist dokumentiertes Verfahren.

Keylime, vier Rollen und ein Prüfer der nicht aufhört

Genau diesen Schritt macht Keylime, und genau deshalb ist Keylime mehr als ein Skript um tpm2_quote herum. Die Architektur hat vier Rollen: einen Agent auf dem Knoten, einen Registrar, einen Verifier und einen Tenant. Der Agent schickt Event-Log, IMA-Hashes und Measured-Boot-Daten, der lokale TPM bürgt für die Echtheit, und über das EK-Zertifikat lässt sich beweisen, dass es überhaupt ein echter TPM ist. Der Verifier prüft dann fortlaufend und nicht nur einmal beim Start.

Damit das nicht nach Bastelei klingt: Keylime läuft in der IBM Cloud als Teil der Compliance-Anforderungen für FedRAMP und HITRUST, und SUSE dokumentiert es offiziell für SUSE Linux Micro. Das ist kein Laborspielzeug.

IMA und EVM, zwei Dinge die ständig verwechselt werden

Beide gehören zur Laufzeit-Integrität, machen aber Verschiedenes.

• IMA, die Integrity Measurement Architecture, hasht Dateien beim Zugriff. Im Messmodus schreibt sie die Hashes in ein Kernel-Log und erweitert damit PCR 10. Im Appraisal-Modus verweigert sie zusätzlich die Ausführung, wenn Hash oder Signatur nicht passen.
• EVM schützt die zugehörigen erweiterten Attribute, also die Sicherheits-Metadaten der Datei, mit einem HMAC oder einer Signatur. Ohne EVM könnte ein Angreifer mit Schreibrechten die IMA-Attribute einfach mitfälschen.

Der TPM-Bezug liegt bei IMA und bei PCR 10. Eine veränderte Binärdatei erzeugt eine Messung, die im TPM landet und rückwirkend nicht mehr zu entfernen ist, weil PCRs nur wachsen. Zusammen mit Secure Boot und Measured Boot entsteht so eine Kette von der Firmware bis zur einzelnen ausgeführten Datei. Ohne TPM wäre dieses Logbuch fälschbar, mit TPM nicht.

Verschlüsselte Server, die allein neu starten können

Operativ ist das der handfesteste Nutzen im Rechenzentrum. Ein verschlüsselter Server, der nach einem Reboot auf eine Passphrase wartet, ist ein Betriebsproblem, spätestens um drei Uhr nachts. Mit TPM-Bindung startet er durch. Der Zielkonflikt dahinter ist eine echte Architekturentscheidung.

• TPM allein. Der Server startet ohne Menschen. Wer den ganzen Server stiehlt, bekommt einen Server, der sich selbst entsperrt.
• Tang und Clevis, netzgebunden. Entsperrt nur, wenn der Server einen Tang-Server im eigenen Netz erreicht. Aus dem Rack getragen bleibt er zu. Braucht dafür einen erreichbaren Tang-Server, was beim Kaltstart eines ganzen Rechenzentrums ein Henne-Ei-Problem ist.
• Beides kombiniert über Shamir Secret Sharing in Clevis, also zum Beispiel TPM und Tang zusammen.

Meine Empfehlung, und die ist unspektakulär: im eigenen Rack mit eigenem Netz nehmt Tang plus TPM über Clevis, weil dann beide Bedingungen gleichzeitig gelten müssen. Bei einer einzelnen Kiste in fremder Colo nehmt TPM mit PIN und tippt die eben ein, wenn es tatsächlich einen Kaltstart gibt. Ein Server, der sich ohne jede Bedingung selbst entsperrt, ist Verschlüsselung fürs Protokoll und nicht gegen einen Angreifer.

Maschinenidentität, die man nicht in eine VM klonen kann

Ein Schlüssel der die Maschine nicht verlassen kann ist eine Identität, die man nicht mitkopieren kann. Für Zero-Trust-Architekturen ist das der interessante Teil: SPIRE hat dafür einen TPM-Node-Attestor, und für Kubernetes-Knoten, die sich beim Beitritt beweisen sollen, ist das der saubere Weg. Verglichen mit einem Token in einer Cloud-Init-Datei, das jeder mitlesen und in eine beliebige VM kopieren kann, ist das ein anderes Sicherheitsniveau.

Ein TPM für jede VM, und was er nicht leistet

Ein physischer TPM hat genau eine Instanz und lässt sich nicht sinnvoll auf viele Gäste aufteilen. Die Lösung ist ein virtueller TPM pro VM. swtpm stellt dafür eine TPM-2.0-Implementierung im Userspace bereit, QEMU und libvirt binden sie als Gerät in die VM ein. Der Gast sieht ein ganz normales /dev/tpm0 und braucht keine Anpassung. Der Kernel bringt dazu den vTPM-Proxy-Treiber mit, /dev/vtpmx, über den Container und VMs eigene TPM-Instanzen bekommen. Genau so machen es die Cloud-Anbieter, und genau so kommt Windows 11 in einer VM überhaupt an seine TPM-2.0-Voraussetzung.

Die ehrliche Einordnung gehört dazu, weil das in Cloud-Architekturen regelmäßig falsch verstanden wird. Ein vTPM ist Software. Sein Zustand liegt als Datei auf dem Hypervisor. Wer den Hypervisor kontrolliert, kontrolliert den vTPM, und ein Angreifer mit root auf dem Host kann den Schlüsselzustand kopieren. Ein vTPM löst also das Problem „der Gast braucht ein TPM-Interface“, er liefert aber keine Hardware-Vertrauenswurzel für den Gast. Wer echte Attestierung einer VM will, braucht eine Kette, die beim TPM des Hosts beginnt, oder Confidential-Computing-Technik wie AMD SEV-SNP oder Intel TDX.

Zum Schluss noch ein kleiner Anwendungsfall, der technisch nichts Neues ist und praktisch viel bringt: die Datenbank-Zugangsdaten eines Dienstes so versiegeln, dass sie nur auf dieser Maschine und nur in diesem Bootzustand aufgehen. Derselbe Seal-Mechanismus wie oben, nur mit einem anderen Geheimnis. Ein kopiertes Image oder eine in eine VM gehobene Platte bringt die Zugangsdaten dann nicht mit.

Was geht, aber nichts bringt

Dieser Abschnitt ist mir genauso wichtig wie der Nutzen-Teil, also kürze ich ihn nicht ab. Zuerst das Missverständnis, das sich am leichtesten messen lässt.

1. Der TPM als Krypto-Beschleuniger. Gemessen und erledigt.

Operation

Wo

Zeit

RSA-2048-Schlüssel erzeugen

TPM

19,703 s

RSA-2048-Schlüssel erzeugen

CPU, openssl

0,220 s

ECC-P-256-Primary erzeugen

TPM

0,537 s

ECDSA P-256 signieren, 50 mal

TPM

4,862 s

ECDSA P-256 signieren, 50 mal

CPU, openssl

0,286 s

# time tpm2_createprimary -C o -g sha256 -G rsa2048 -c rsa_primary.ctx
real	0m19.703s
user	0m0.039s
sys	0m0.016s

# time openssl genpkey -algorithm RSA -pkeyopt rsa_keygen_bits:2048 -out /dev/null
real	0m0.220s
user	0m0.210s
sys	0m0.010s

Rund 90 mal langsamer bei der RSA-Schlüsselerzeugung. Ein Detail zur Messhygiene ist mir dabei wichtig: während der 19,7 Sekunden liegen user und sys bei 0,039 und 0,016 Sekunden. Die CPU langweilt sich also, die Zeit vergeht wirklich im Chip. Das ist eine Messung des TPM und nicht des Prozess-Overheads.

Die richtige Schlussfolgerung ist nicht, dass der TPM schlecht wäre, sondern dass er kein Beschleuniger ist und nie einer war. Das ist die interessante Kehrseite zu der Krypto-Beschleunigerkarte, die ich neulich gegen dieselbe Klasse moderner CPU gemessen habe. Dort verlor Spezial-Hardware, die schnell sein wollte. Hier verliert sie noch deutlicher, nur ist das kein Befund, sondern die Bauart. Der TPM wollte nie schnell sein, er wollte stur sein.

2. Massendaten im TPM verschlüsseln. Es gibt keinen Datenpfad dafür, und bei den Zahlen von oben erübrigt sich die Diskussion.

3. LUKS nur am TPM, ohne PIN. Technisch drei Minuten Arbeit. Ergebnis ist ein Notebook, das sich für jeden entsperrt, der den Deckel aufmacht. In Kombination mit dem Bus-Sniffing weiter unten ist das nahe an Sicherheitstheater. Wer die Passphrase-Eingabe loswerden will, nimmt die PIN.

4. Der TPM als Passwortspeicher oder Secret Store. Ein einzelner NV-Index kann auf diesem Chip höchstens 1664 Bytes halten, und es gibt genau 8 NV-Zähler. NV im TPM ist Flash mit begrenzten Schreibzyklen und als Ablage für Inhalte nicht gedacht. Der richtige Weg ist immer derselbe: die Geheimnisse liegen verschlüsselt auf der Platte, und nur der Schlüssel dafür wird im TPM versiegelt. Genau das tun systemd-cryptenroll und Clevis auch.

5. Sealing gegen PCR 0 bis 7 auf einem Gerät, das Firmware-Updates bekommt. Jedes BIOS-Update ändert die Messungen und sperrt euch aus. Ein Fall, in dem die Technik funktioniert und die Betriebspraxis daran zerbricht. Der Ausweg heißt signierte Policies und systemd-pcrlock, und im selben Atemzug gehört dazu, dass sich systemd-pcrlock selbst noch als experimentell bezeichnet.

6. Attestierung ohne unabhängigen Prüfer. Ein Quote, das auf derselben Maschine geprüft wird, beweist nichts. Wenn die Maschine übernommen ist, ist die Prüfung übernommen. Attestierung ergibt nur mit einem separaten Verifier und mit bekannten Referenzwerten Sinn. Sehr viele Aussagen der Art „wir nutzen TPM“ sind bei genauem Hinsehen genau das, eine Selbstprüfung.

7. TPM 1.2 im Jahr 2026. SHA-1 und RSA-2048, kein ECC, keine Algorithmen-Agilität, ein völlig anderer Software-Stack, nämlich TrouSerS statt tpm2-tss. Wer noch einen findet, sollte darauf nichts Neues bauen.

8. Die Erwartung, ein TPM schütze ein laufendes System. Das ist das größte Missverständnis, deshalb steht es hier noch einmal als eigener Punkt. Ein TPM schützt Schlüssel im Ruhezustand und misst den Start. Er tut nichts gegen einen Angreifer, der schon im Kernel sitzt, denn der fragt den Chip einfach ganz normal.

Fünf häufige Vorhaben und die kurze Antwort dazu.

Die Grenzen, und die Angriffe die es wirklich gibt

Ohne diesen Abschnitt wäre der Beitrag Werbung. Der Kern des Problems bei diskreten Chips ist unangenehm einfach: nach dem Entsiegeln gibt der TPM das Geheimnis über den Bus heraus, und klassisch liegt es dort im Klartext. Wer LPC oder SPI anzapft, liest den Schlüssel mit. Für BitLocker ist das seit Jahren praktisch demonstriert, und es ist ausdrücklich nicht auf Windows beschränkt. Securitum hat im September 2024 in einem echten Penetrationstest genau das gegen ein Linux-System mit LUKS und Clevis gezeigt.

Das betrifft mein Testsystem direkt, und ich schreibe das lieber offen hin, als es zu verstecken: der SLB 9670 ist ein diskreter Chip auf dem Board. Der Angriff braucht physischen Zugriff und Löterfahrung, aber er ist kein Papier-Szenario.

Die Gegenmaßnahme kann TPM 2.0 von sich aus: Sessions mit HMAC-Absicherung und Parameter-Verschlüsselung, und systemd benutzt das inzwischen. Die Grenze davon wird oft zu großzügig beschrieben, deshalb genau: das ist keine Vollverschlüsselung des Bus-Protokolls. Parameter Encryption schützt gezielt einzelne sensible Parameter in Kommandos und Antworten, also genau die Stelle, an der ein entsiegelter Schlüssel herauskäme. Kommandocodes, Handles und die übrigen Parameter bleiben sichtbar. Gegen das passive Mitlesen des Schlüssels ist es wirksam, gegen Verkehrsanalyse nicht, und gegen einen aktiven Interposer hilft es nur insofern, als die HMAC-Absicherung Manipulationen auffallen lässt. Der Kernel hat zu dieser Interposer-Frage eine eigene Dokumentationsseite. Und noch eine Einschränkung, die systemd selbst dokumentiert: die Art der Einbindung entwickelt sich weiter, alte Enrollments profitieren nicht rückwirkend. Wer vor Jahren enrolliert hat, sollte das neu machen.

Und dann eine Ironie, die zeigt wie dünn das Eis ist: CVE-2023-1017 saß genau in CryptParameterDecryption, also in dem Code, der diese verschlüsselten Parameter auspackt. Die Schutzfunktion war selbst der Angriffsweg.

Wer jetzt denkt, ein fTPM in der CPU sei automatisch besser, hat nur andere Probleme. faulTPM hat gezeigt, dass sich AMDs fTPM über Spannungs-Glitching am Platform Security Processor angreifen lässt. Und TPM-Fail demonstrierte 2019 Timing-Seitenkanäle, mit denen sich private ECDSA-Schlüssel rekonstruieren ließen, und zwar aus Intel PTT (CVE-2019-11090) und aus dem ST33 von STMicroelectronics (CVE-2019-16863). Zwei Details daran tragen den Punkt: der lokale Angriff auf Intels fTPM brauchte je nach Zugriffsrechten 4 bis 20 Minuten, und der ST33 trug eine Common-Criteria-Zertifizierung nach EAL 4+, die Schutz gegen Seitenkanäle ausdrücklich einschließt. Ein Zertifikat ist also kein Beweis.

Auch die Referenz-Implementierung selbst hatte Löcher. CVE-2023-1017 war ein Out-of-bounds-Write, CVE-2023-1018 ein Out-of-bounds-Read, beide in der TPM-2.0-Module-Library, also im Referenzcode der TCG. Betroffen waren dadurch gleichzeitig Software-TPMs wie libtpms und eine Reihe von Hardware-TPMs, deren Firmware auf diesem Code aufbaut. Gefunden hat sie Quarkslab und meldete sie im November 2022. Zwei Bytes über den Puffer hinaus, im ungünstigen Fall Codeausführung im TPM-Kontext, also genau in dem Bauteil, dessen einzige Aufgabe es ist, eine Vertrauensgrenze zu ziehen.

Was bleibt also unterm Strich: ein TPM hebt die Messlatte von „Platte ausbauen und kopieren“ auf „an das Board löten oder den SoC glitchen“. Das ist ein echter Fortschritt und kein magischer Schild. Mit PIN wird es deutlich stärker, weil dann die Lockout-Logik greift und Bus-Sniffing allein nicht mehr reicht.

Der Zustand dieses Testsystems, unbequem und aufschlussreich

Und jetzt der Teil, der mir selbst am meisten zu denken gibt. Der Chip in diesem Notebook arbeitet einwandfrei, wie alles hier oben zeigt. Benutzt wird er von diesem System für praktisch nichts.

Baustein

Zustand

Secure Boot

aus, und als 00 in PCR 7 gemessen

Wurzel-Dateisystem

ZFS-Native-Encryption, aes-256-gcm, nirgends LUKS

systemd-cryptenroll

vorhanden, systemd 255.4, ohne LUKS2 aber nutzlos

clevis

nicht installiert, würde hier auch nicht helfen

Unified Kernel Image

nicht im Einsatz

systemd-pcrextend.socket

übersprungen, ConditionSecurity=measured-uki nicht erfüllt

systemd-pcrmachine.service

übersprungen, dieselbe Bedingung

systemd-tpm2-setup-early.service

übersprungen, dieselbe Bedingung

die elf systemd-pcrlock-*-Units

alle disabled

TPM als /dev/hwrng

aktiv, tpm-rng-0

Die drei übersprungenen Units sind der interessanteste Eintrag in dieser Tabelle. Die Bedingung ConditionSecurity=measured-uki prüft nicht das Dateiformat, sondern den Bootweg. Weil dieses System nicht als gemessenes Unified Kernel Image über systemd-stub gestartet ist, überspringt systemd die halbe TPM-Infrastruktur einfach lautlos, ohne Fehler und ohne Warnung. Das ist genau die These aus der Einleitung, jetzt belegt: der Chip ist da, er funktioniert, und die Distribution benutzt ihn nicht.

Der Event-Log, und die Falle mit ls

Zum Abschluss noch eine Kleinigkeit, über die ich zuerst gestolpert bin. Der Event-Log, dessen Adresse die Firmware ganz oben in der ersten dmesg-Zeile übergeben hat, liegt im securityfs. Und ls behauptet, die Datei sei leer.

# ls -la /sys/kernel/security/tpm0/
total 0
-r--r----- 1 root tss 0 Aug 10 09:30 binary_bios_measurements

# tpm2_eventlog /sys/kernel/security/tpm0/binary_bios_measurements | grep -c EventNum
120

Null Bytes laut ls, und trotzdem 120 Events darin. securityfs gibt für diese Datei einfach keine Größe an. Was in den 120 Einträgen steckt, sortiert sich so:

# tpm2_eventlog /sys/kernel/security/tpm0/binary_bios_measurements | grep EventType | sort | uniq -c | sort -rn
     81   EventType: EV_IPL
     12   EventType: EV_EFI_VARIABLE_BOOT
      8   EventType: EV_SEPARATOR
      5   EventType: EV_EFI_VARIABLE_DRIVER_CONFIG
      3   EventType: EV_EFI_ACTION
      2   EventType: EV_POST_CODE
      2   EventType: EV_EVENT_TAG
      2   EventType: EV_EFI_BOOT_SERVICES_APPLICATION
      1   EventType: EV_S_CRTM_VERSION
      1   EventType: EV_NO_ACTION
      1   EventType: EV_EFI_VARIABLE_AUTHORITY
      1   EventType: EV_EFI_HANDOFF_TABLES
      1   EventType: EV_EFI_GPT_EVENT

Der lehrreichste Eintrag im ganzen Log ist aber die Nummer 2, weil er ein abstraktes Konzept in vier Zeilen greifbar macht.

- EventNum: 2
  PCRIndex: 7
  EventType: EV_EFI_VARIABLE_DRIVER_CONFIG
  DigestCount: 2
  Digests:
  - AlgorithmId: sha1
    Digest: "57cd4dc19442475aa82743484f3b1caa88e142b8"
  - AlgorithmId: sha256
    Digest: "115aa827dbccfb44d216ad9ecfda56bdea620b860a94bed5b7a27bba1c4d02d8"
    UnicodeName: SecureBoot
    VariableData: "00"

Da steht der Secure-Boot-Zustand meiner Maschine als 00 im Log, und gehasht wandert genau dieser Wert in PCR 7. Das ist die Brücke zwischen dem Firmware-Setup und dem Chip: was ihr im BIOS umschaltet, wird gemessen und landet im TPM. Schaltet Secure Boot ein, und PCR 7 ändert sich. Alles, was gegen PCR 7 versiegelt war, geht danach nicht mehr auf. Wer den Zusammenhang einmal so gesehen hat, versteht auch, warum die Wahl der PCRs weiter oben ein Zielkonflikt ist und keine Geschmacksfrage.

Eine Nebenbemerkung, weil sie so schön zeigt, wie Secure-Boot-PKI in der Praxis funktioniert: im Log steckt auch der Platform Key des Boards, ein „Fujitsu ODM Quanta BIOS PK Certificate“, gültig von August 2012 bis August 2022. Es ist also seit Jahren abgelaufen. Die Firmware interessiert sich nicht dafür.

Was offen bleibt

• Ob der SLB 9670 auf diesem Board über LPC oder über SPI angebunden ist. Aus dem Betriebssystem heraus nicht entscheidbar.
• Warum der Login über PKCS11Provider rund 1,3 Sekunden Aufschlag kostet, ist plausibel erklärt, aber nicht einzeln nachgemessen. Ein strace oder ein Trace über tpm2_ptool würde es belegen.
• systemd-cryptenroll mit LUKS2 konnte ich nicht testen, weil hier kein LUKS existiert.
• Keylime habe ich nicht aufgesetzt. Die Beschreibung stützt sich auf Dokumentation von SUSE, Red Hat und dem Keylime-Projekt.
• Die Bindung des Attestierungsschlüssels an den zertifizierten EK, also TPM2_MakeCredential und TPM2_ActivateCredential, habe ich nicht durchgeführt. Gemessen sind nur Quote und Signaturprüfung.
• Wie viel NV-Speicher der SLB 9670 insgesamt hat, habe ich nicht ermittelt. NV_INDEX_MAX beantwortet diese Frage nicht.
• Kein vTPM aufgesetzt. Der Abschnitt dazu ist dokumentiert und nicht gemessen.
• Ob verschlüsselte TPM-Sessions Bus-Sniffing auf diesem konkreten Chip vollständig verhindern, habe ich nicht überprüft. Dafür bräuchte es einen Logic Analyzer.
• Ein TPM-gestütztes Entsperren einer ZFS-Native-Encryption-Wurzel habe ich nicht gebaut.
• Wie sich PCR 7 auf diesem Gerät nach dem Aktivieren von Secure Boot verändert. Das wäre ein naheliegender zweiter Teil.

Siehe auch

• BIOS erklärt, Teil 1: ein Serverboard als Workstation und der Weg ins Setup
• Sieben Einstellungen, kein Setup-Besuch: die BIOS-Konfiguration eines Supermicro-Boards ändern
• Intel QuickAssist 8950-SCCP: Krypto-Beschleuniger von 2013 gegen eine CPU von heute

Wenn ich hier etwas falsch dargestellt habe, oder wenn ihr einen der offenen Punkte schon gelöst habt, dann korrigiert mich gerne. Dann lerne ich selbst etwas. Ihr dürft mich dazu jederzeit fragen.

Und weil mich das wirklich interessiert: setzt ihr den TPM-Chip selbst ein, ignoriert ihr ihn bisher, oder nutzt ihr ihn eher zufällig?