Beispiele für die Kommandozeile in dieser Artikelserie sind als Benutzer „root“ auszuführen; es werden Linux-Kenntnisse vorausgesetzt, Grundkenntnisse im Umgang mit X.509-Zertifikaten und LUKS sind von Vorteil.

Bei einem TPM handelt sich um eine Komponente, die üblicherweise in Computern der x86-Architektur anzutreffen ist; aber auch für andere Architekturen (zum Beispiel Raspberry Pi) stehen TPMs als Erweiterungen zur Verfügung. Auf Mac-Computern von Apple gibt es kein TPM, der „T2 Security Chip“ übernimmt dort vergleichbare Aufgaben und auf mobilen Endgeräten gibt es mit „ARM TrustZone“ und „Apple Secure Enclave“ ähnliche Komponenten, die aber nicht mit TPM kompatibel sind.

• Diskrete TPMs sind als dedizierter Chip ausgeführt, entweder direkt auf dem Mainboard oder über einen speziell dafür vorgesehenen Erweiterungs-Slot, den „TPM-Header“.
• Bei Firmware-TPMs kommen die Funktionen aus der Firmware des Computers und werden in der CPU ausgeführt.
• Software-TPMs laufen als Programm im Betriebssystem (siehe auf Linux zum Beispiel „swtpm“).

In dieser Artikelserie wird, wenn von „TPM“ die Rede ist, immer von TPM Version 2.0 gesprochen; die ältere Version 1.2 wird nicht mehr berücksichtigt. Um konform mit TPM Version 2.0 zu sein, muss eine Komponente eine Schnittstelle implementieren, die von der „TPM Library Specification Version 2.0“ vorgegeben ist. Diese Spezifikation wird vom Industriekonsortium Trusted Computing Group (TCG) erstellt und weiterentwickelt; zu den Mitgliedern gehören Firmen wie Infineon, Microsoft, AMD, Intel, Lenovo, Huawei, Dell und andere. Die Spezifikation ist in einer älteren Fassung auch als internationaler Standard ISO/IEC 11889:2015 übernommen worden.

Was macht ein TPM?

Der Wortwahl der TCG folgend soll ein TPM ein System – von der TCG als „Plattform“ bezeichnet – „vertrauenswürdig“ („trusted“) machen. Dabei ist nicht direkt festgelegt, was die Plattform ist und wer genau wem vertraut - das TPM soll die Mittel zur Etablierung solcher Vertrauensstellungen bereitstellen.

Auf technischer Ebene folgt aus dieser grundsätzlichen Vorstellung folgendes: Ein TPM soll Prozeduren für die Sicherung der Integrität von Daten so bereitstellen, dass es möglich ist, diese Funktionen zu benutzen; gleichzeitig soll es aber unmöglich sein, eben diese Daten und Funktionen aus dem TPM so auszulesen oder so zu manipulieren, dass die Integrität danach nicht mehr gegeben ist. Kürzer gesagt: TPM soll ein System vor unerwünschten Manipulationen schützen.

Dazu folgendes Beispiel: Ein TPM kann den privaten Teil eines kryptografischen Schlüsselpaars speichern, wie es zum Beispiel bei SSH oder TLS zum Einsatz kommt. Das TPM stellt dem Betriebssystem auch die Funktionen zur Verfügung, die bei dem verwendeten kryptografischen Algorithmus für Anwendungen vorgesehen sind, zum Beispiel die Funktion „Entschlüssele mit dem privaten Schlüssel Daten, die mit dem öffentlichen Schlüssel verschlüsselt wurden“. Es ist hingegen über die Funktionen des TPM nicht möglich, den privaten Schlüssel aus dem TPM auszulesen; der private Schlüssel könnte dann ja auf irgendwelche anderen Systeme kopiert werden und dort zum Beispiel zum Entschlüsseln von Daten verwendet werden; der Schlüssel wäre somit nicht mehr privat, und die Integrität der Verschlüsselung wäre nicht gewährleistet.

Aus diesem Grund sind Funktionen für handelsübliche kryptografische Algorithmen (zum Beispiel RSA mit 2048 Bit langen privaten Schlüsseln) Teil der TPM-Spezifikation. Diese Schnittstelle erlaubt es, kryptografische Funktionen zu nutzen, sie bietet aber keine Möglichkeit, Daten oder Funktionen zu manipulieren.

Ein TPM kann Schlüsselpaare erzeugen und bereitstellen, und es können auch benutzerdefinierte Daten im TPM abgespeichert werden. Solche „Objekte“, die in einem TPM gespeichert sind, können vor unbefugtem Zugriff geschützt werden. Die wohl einfachste Möglichkeit des Zugriffsschutzes ist das Definieren eines Passworts, das eine Anwendung kennen muss, um mit einem Objekt zu arbeiten. Es gibt darüber hinaus die Möglichkeit, den Zugriff auf Objekte nur dann zu erlauben, wenn sich an bestimmten Eigenschaften des Computer-Systems nichts geändert hat. Dieses Vorgehen wird „Sealing“ („Versiegeln“ bzw. „mit einem Siegel ausstatten“) genannt. Änderungen kann das TPM dabei anhand von sich ändernen Informationen erkennen, welche „Platform Configuration Registers“, „PCRs“ genannt werden. So ist es möglich, die Verwendung eines kryptografischen Schlüssels nicht zu erlauben, wenn sich an der Firmware des Computers seit Einrichten der Verschlüsselung etwas geändert hat oder wenn UEFI Secure Boot nicht aktiv ist.

In manchen Situationen mag es erwünscht sein, durch externe Prüfung nachweisen zu können, ob ein vorgelegter öffentlicher Schlüssel Teil eines Schlüsselpaares ist, das in einem TPM verwaltet wird (und kein reguläres, dateibasiertes Schlüsselpaar). Diese Prüfung wird „TPM-Schlüsselnachweis“ bzw. „TPM Key Attestation“ genannt.

Ist TPM eine kontroverse Technologie?

TPMs sind, richtig eingesetzt, nützliche Einrichtungen in Computern, die positive Auswirkungen auf die IT-Sicherheit haben können. Betriebssysteme können mit Schutz vor manipulierter Hardware gestartet werden, Festplattenverschlüsselung kann komfortabel, aber mit hohem Sicherheitsniveau implementiert werden, private kryptografische Schlüssel bleiben – vielleicht zum ersten Mal – wirklich privat.

Jedoch kann diese Technologie auch zum Nachteil von Anwenderinnen und Anwendern und zu Ungunsten von Kunden, unabhängigen Dienstleistern und Herstellern von Hard- und Software-Lösungen eingesetzt werden. Der Jargon-Begriff der „Ver-Dongelung“ eines Systems bezeichnet Software, die an bestimmte Hardware gebunden wird, um restriktive Lizenzmodelle des Herstellers der Software durchzusetzen, und auch für solche Bestrebungen kann TPM zum Einsatz kommen. Gerade Organisationen, die sich der freien Lizenzierung von Software verschrieben haben, haben deshalb frühzeitig deutlich vor den Risiken von TPMs gewarnt.

Der Zugriff, den TPM zwecks Sealing und Attestation auf gewisse Eigenschaften des Systems hat, wird mit Blick auf den Schutz persönlicher Daten zuweilen argwöhnisch betrachtet. Dazu ist aber anzumerken, dass die vom TPM aus diesen Informationen erstellten PCRs sich mit Hardware, Firmware und Bootloader des Computers beschäftigen – Speicherorte, an denen persönliche Daten eher selten anzutreffen sind.

Problematischer ist der in jedem TPM vom Hersteller hinterlegte, eindeutige „Endorsement Key“, ein spezieller privater Schlüssel, der nicht ausgelesen oder verändert werden kann. Es handelt sich sozusagen um eine nicht manipulierbare „Device-ID“. Neben den bereits geschilderten Begehrlichkeiten von Software-Herstellern mit restriktiver Lizenzpolitik sind auch Methoden des „Fingerprintings“ denkbar, des Nachverfolgens und Zuordnens von Nutzeraktivitäten anhand der dabei verwendeten (und dank Endorsement Key eindeutig identifizierbaren) Geräte. Wie in vielen anderen Fällen auch gibt es sowohl nützliche, als auch verwerfliche Anwendungsfälle für eine solche Technologie.

Proprietäre, hardwarebasierte TPMs sind „Black Boxes“, ihre internen Funktionen sind nicht einsehbar. Generell gilt das für alle Komponenten, bei denen es sich nicht um „Open Hardware“ handelt; jedoch hinterlässt „Security by Obscurity“ einen faden Beigeschmack; sicherheitsrelevante Komponenten sollten so transparent wie möglich gestaltet sein, um das Erkennen von Sicherheitslücken zu fördern, statt es zu behindern. Dies ist bei TPMs nicht unbedingt der Fall.

Ein Beispiel aus der jüngeren Vergangenheit: CMU SEI Vulnerability Note VU#782720 schildert zwei CVEs, CVE-2023-1017 (Out-of-Bounds-Write) und CVE-2023-1018 (Out-of-Bounds-Read), von denen theoretisch jedes TPM betroffen ist, das die Spezifikation TPM 2.0 implementiert. Es ist aber nicht klar, welche Hersteller und welche Modelle von TPMs von diesen Fehlern betroffen sind, Stellungnahmen sind spärlich, die tatsächlich eingesetzte Software ist proprietär und nur mit großem Aufwand unabhängig prüfbar (immerhin kann mit dem Werkzeug „tpm-vuln-checker“ geprüft werden, ob ein TPM betroffen ist).

TPM ist gemäß seiner offenen Spezifikation durchaus eine herstellerneutrale Technologie. Jedoch nutzen Betriebssystem-Hersteller wie Microsoft die TPM-Funktionen in der Annahme, das ihr Betriebssystem das Einzige auf dem Computer ist. Dualboot-Konfigurationen sind somit problematisch; Versuche im Auftrag des Bundesamts für Sicherheit in der Informationstechnik haben für Windows 10 und Linux ergeben, dass es vermutlich nicht möglich ist, beide abwechselnd dasselbe TPM benutzen zu lassen.

Überwiegen die Vorteile die Nachteile? Die Rechnung ist schwer aufzustellen. Die gleichen Computer, mit denen wir Briefe schreiben und Spiele spielen, können auch bewaffnete Drohnen steuern. Die gleiche Software, mit der wir unsere Computer und Netzwerke schützen, kann auch einen Überwachungsstaat realisieren. Es hängt wohl davon ab, die Mittel der Technik verantwortungsvoll, sicherheitsbewusst und im Rahmen der Gesetze und Vorschriften richtig einzusetzen.

Was gilt es bei TPM noch zu beachten?

Der große Vorteil von TPM, dass kryptografische Daten so gespeichert werden können, dass sie zwar benutzt aber nicht mehr ausgelesen werden können, ist gleichzeitig auch ein Nachteil: Die so gespeicherten Schlüssel sind fest an das spezifische TPM gebunden, mit dem sie generiert wurden. Ist das TPM verloren oder defekt, dann sind auch die Daten weg bzw. nicht mehr funktionstüchtig. Ebenso sind die Daten verloren, wenn das TPM zurückgesetzt wird.

Das „Sealing“ des Zugriffs auf geheime Daten, die vom TPM verschlüsselt wurden, erlaubt es, den Zugriff auf diese Daten nur dann preiszugeben, wenn sich an gewissen geforderten Eigenschaften des Computers oder des Betriebssystems seit dem Abspeichern der Daten nichts geändert hat. So könnte zum Beispiel ein RSA-Schlüssel nur dann zur Verfügung stellen, wenn sich an der Prüfsumme der UEFI-Firmware-Einstellungen nichts geändert hat.

So nützlich diese Zugriffsbeschränkungen sind, können sie unerwartete Folgen haben: Ein UEFI-Firmware-Update kann eine Änderung dieser Prüfsumme herbeiführen, obwohl an den Einstellungen nichts bewusst geändert wurde; der RSA-Schlüssel wäre dann nicht mehr benutzbar. TPMs, die Teil der Hardware eines Computers sind (diskrete oder Firmware-TPMs) stehen dem Betriebssystem des Hosts zur Verfügung, können aber nicht ohne weiteres von virtuellen Maschinen genutzt werden. Generell ist die gemeinsame Nutzung eines TPMs durch mehrere Betriebssysteme problematisch.

Wie funktioniert ein TPM?

Genau betrachtet benötigt ein TPM verschiedene Teile, um die zuvor beschriebenen Funktionen ausführen zu können: Es benötigt ein Rechenwerk, den Steuerungscode, der die TPM-Funktionen realisiert, flüchtigen Speicher (dieser bleibt bis zum nächsten Neustart des Systems erhalten), nicht-volatilen Speicherplatz und eine Schnittstelle zur CPU, von der aus Anwendungen die TPM-Funktionen aufrufen wollen.

Je nach Ausführung (etwa diskreter, Firmware- oder Software-TPM) befindet sich das Rechenwerk auf einem separaten Chip, oder die CPU stellt einen besonders geschützten Modus für die Berechnungen bereit (zum Beispiel Trusted Execution Technology, TXT des CPU-Herstellers Intel), oder – dies wäre die wohl am leichtesten angreifbare bzw. unsicherste Variante – die TPM-Funktionen werden von der CPU wie ganz normale Prozesse berechnet (dies ist der Fall bei TPM-Emulatoren oder „swtpm“).

Analog kann der Steuerungscode auf der TPM-Komponente fest hinterlegt sein, über die Firmware des Computers bezogen werden oder gar (wiederum die unsicherste Variante) wie eine Applikation vom Betriebssystem geladen werden. Ein quasi „fest verdrahteter“ Steuerungscode hat den Vorteil, nicht manipuliert werden zu können, weil das technisch nicht möglich ist. Eine nachträgliche Fehlerbehebung würde aber den Austausch der gesamten Komponente erfordern. Wird hingegen die TPM-Steuersoftware als Teil der Firmware bei Systemstart in das Rechenwerk geladen, dann können Updates und Fehlerbehebungen nachträglich wie normale Firmware-Updates verteilt und eingespielt werden; somit wäre das TPM dann aber auch angreifbar für manipulierte Firmware.

Die privaten Daten des TPM können ebenfalls am besten abgesichert werden, wenn sie auf dem diskreten Chip gespeichert werden; hier können auch physikalische Schutzmechanismen eingesetzt werden, die bei einem direkten Manipulationsversuch den Chip eher zerstören, als die Daten preiszugeben. Wird hingegen das NVRam des Mainboards verwendet, dann muss der TPM seine Arbeitsdaten mindestens so stark verschlüsseln, dass das Auslesen des NVRams durch einen nicht berechtigten Prozess einem Angreifer keine Vorteile bringt. Das Abspeichern der Arbeitsdaten wie ganz normale Anwendungsdaten ist wiederum die unsicherste Variante („swtpm“ speichert zum Beispiel alle seine Daten in einem Unterverzeichnis von /var).

Ein TPM sollte Zugriff auf einen eigenen Zufallszahlen-Generator haben, mit dem er kryptografische Schlüsselpaare erstellen kann, ohne dass sie einer anderen Komponente des Rechners bekannt werden. Für das „Sealing“ hat ein TPM Zugriff auf verschiedene Chipsatz- und Firmware-Informationen; es kann eine Prüfsumme der Firmware-Einstellungen abrufen, kann feststellen, ob ein System mit oder ohne SecureBoot gestartet oder eine unbekannte Hardware angeschlossen wurde.

Das Betriebssystem kommuniziert mit dem TPM über das „TPM Command Transmission Interface“, „TCTI“, eine Transport-API, die unabhängig von der technischen Anbindung des TPM an die CPU ist. Diskrete TPM kommunizieren in der Regel über „Serial Peripheral Interface“, „SPI“. Das TPM regelt zudem die Autorisierung des Zugriffs auf die Objekte; es bietet einen Policy-basierten Schutzmechanismus, mit dem Anforderungen ausgesprochen werden können wie „Zugriff auf Objekt X wird nur erteilt, wenn der anfragende Prozess ein bestimmtes Passwort kennt“ oder „Zugriff auf Objekt Y wird nur erteilt, wenn der Computer mit SecureBoot gestartet wurde“.

Das TPM besitzt die Möglichkeit, sich vor Brute-Force-Angriffen zu schützen, diese werden bei TPM „Dictionary Attacks“, „DAs“ genannt. Wird ein solcher Angriff festgestellt, begibt sich das TPM für eine Weile in den sogenannten „DA Lockout Mode“, in dem es keine Zugriffe zulässt. Bei TPM 2.0 lauten die Standard-Werte für diesen Schutz:

• Nach 10 falschen Eingaben eines Passworts wird ein DA festgestellt.
• Der DA Lockout Mode dauert 24 Stunden.

Wie sind die Daten in einem TPM organisiert?

Die Objekte im Speicher des TPMs sind hierarchisch angeordnet, das heißt, Objekte werden von anderen Objekten abgeleitet. Dabei gibt es mehrere Hierarchien:

1. Endorsement Hierarchy
   • Das oberste Element dieser Hierarchie ist der „Endorsement Key“, „EK“, der vom Hersteller hinterlegt wurde, sich nicht ändern oder entfernen lässt und für jedes TPM unterschiedlich (also weltweit eindeutig) ist. Von diesem Key werden sogenannte „Attestation Keys“ abgeleitet, mit denen durch eine externe (also außerhalb des Computers gelegene) Prozedur geprüft werden kann, ob gewisse Zusagen über das TPM erfüllt sind, ohne den EK offenzulegen.
2. Platform Hierarchy
   • Objekte in dieser Hierarchie werden von den Prozeduren der Computer-Firmware genutzt. Sie dienen für interne Funktionen des Computer-Herstellers, zum Beispiel zur Validierung von Firmware-Updates.
3. Owner Hierarchy
   • In dieser Hierarchie können Betriebssysteme und Anwendungen Objekte unterhalten, um beliebige sicherheitsrelevante Daten zu speichern. Da der Speicherplatz eines TPM begrenzt ist, werden generierte Schlüssel nicht abgespeichert sondern aus einer „Seed“ berechnet, die das Gerät nicht offenlegt. Eine kryptografisch starke „Key Derivation Function“, „KDF“ erzeugt aus derselben Seed stets dieselben Schlüssel.

Somit muss nur die Seed gespeichert werden, alle Schlüssel sind tatsächlich abgeleitete Werte. Ein Ändern der Seed macht alle bisher generierten Schlüssel ungültig, und ab dann neu generierte Schlüssel werden sich von den zuvor Generierten unterscheiden. Für jede der oben aufgeführten Hierarchien wird eine Seed im TPM unterhalten. Der Vorgang des sogenannten „Bindings“ von Schlüsseln ermöglicht trotz des sehr begrenzten Speicherplatzes des TPM die Anlage von sehr vielen Schlüsseln. Dabei werden neue Schlüssel zwar komplett auf externem Speicher abgelegt (zum Beispiel einem regulären Datenträger des Betriebssystems), sie sind jedoch mit einem im TPM hinterlegten Schlüssel verschlüsselt, das heißt, sie sind ohne das TPM nicht nutzbar (diese Form der „äußeren Verschlüsselung“ eines Schlüssels wird in der Dokumentation auch „Wrapping“ genannt). Der Akt der „Übernahme der Eigentümerschaft“ eines TPM („take ownership“) bedeutet konkret das Zurücksetzen der Storage Hierarchy Seed.

Ausblick

Der nächste Teil dieser Artikelserie wendet sich dem praktischen Umgang mit TPMs auf dem Betriebssystem Linux und mit Open-Source-Software zu. Eine Auswahl von verfügbaren Projekten und Repositories wird vorgestellt und erste praktische Übungen im Umgang mit Schlüsseln und Zertifikaten werden gezeigt.