Plattformsicherheit per Kontrollchip

Trusted Platform Module
Kommentare

Der erste Teil dieser zweiteiligen Artikelserie beschäftigt sich mit der Funktionsweise und den Einsatzmöglichkeiten eines „Trusted Platform Module“(TPM). Eine Einführung in die Anwendungsgebiete und das Management eines TPM sowie die Darstellung der Pros und Kontras dieser Technologie sollen ein besseres Verständnis vermitteln und damit eine individuelle Einschätzung der Technologie ermöglichen. Darüber hinaus werden die für ein rudimentäres Verständnis erforderlichen kryptografischen Grundlagen erörtert.

Ein Trusted Platform Module (TPM) ist eine Hardwarekomponente in Form eines diskreten Schaltkreises oder eines voll in die Hauptplatine integrierten Bausteins. Generell betrachtet ist ein TPM ein sicherer lokaler Speicher für digitale Schlüssel und eignet sich darüber hinaus zur internen Ausführung kryptografischer Operationen. Somit ist ein TPM in der Lage, eine auf digitalen Schlüsseln und Zertifikaten basierende vertrauenswürdige IT-Plattform zu realisieren. Mittlerweile sind beinahe alle neueren Computer und Tablets mit einem TPM-Chip ausgestattet, sodass die Vorteile einer vertrauenswürdigen Plattform verwirklicht werden können. Doch es gibt auch kritische Stimmen, da ein TPM beispielsweise den Status eines Systems speichern und unter bestimmten Umständen für Dritte abrufbar machen kann (Remote-Attestation).

Standards und Ziele des TPM

Das TPM realisiert die durch ein Konsortium namens TCG (Trusted Computing Group) spezifizierte Anforderungen an eine vertrauenswürdige IT-Plattform. Nach eigenen Angaben handelt es sich bei TCG um eine nicht auf Gewinn ausgerichtete Organisation, die sich als Herausgeber internationaler, offener Standards versteht. Derzeit untergliedert sich die gesamte TPM-Spezifikation in drei Teile: „Design-Principles“, „TPMStructures“ und „Commands“.

Diese offenen Standards und Spezifikationen sollen es ermöglichen, sichere IT-Plattformen zu realisieren, die sich unter anderem durch Sicherheitsmechanismen wie einer sicheren Authentifizierung, einer starken Absicherung von Benutzeridentitäten und dem Schutz von kritischen Geschäftsdaten auszeichnen. Ein weiteres Ziel ist die Sicherstellung der Integrität eines Computersystems, sowohl im Online-, als auch im Offlinemodus. Hierbei kann es sich nicht nur um einen klassischen PC, ein Notebook, ein Tablet oder um ein unternehmensweites Netzwerk handeln, sondern ebenso um Systeme mit Cloud-Anbindung.

Architektur und Sicherheit

Im Prinzip ist ein TPM eine auf Hardware basierende Funktionseinheit für das sichere Speichern von digitalen Artefakten, also beispielsweise Schlüsseln, Passwörtern oder Zertifikaten. Darüber hinaus ist ein TPM dafür ausgelegt, kryptografische Operationen intern sicher auszuführen (Crypto Processor). Das bedeutet, für die Abarbeitung der erforderlichen Algorithmen finden weder externe Systemspeicher, noch externe Bibliotheken, die über das Betriebssystem verfügbar sind, Verwendung. Damit ist sichergestellt, dass das TPM nicht durch Tools oder Schadsoftware manipuliert werden kann.

Auf den ersten Blick ist ein TPM direkt mit einer Chipkarte [1] vergleichbar. Der signifikante Unterschied besteht jedoch darin, dass ein TPM an eine Plattform bzw. ein System gebunden ist, wogegen eine Chipkarte in aller Regel einen einzigen Besitzer hat.

Abb. 1: Komponenten eines TPM

Abb. 1: Komponenten eines TPM

Abbildung 1 zeigt die typischen Komponenten eines TPM, wobei der klassische Aufbau eines Mikrocontrollers an Prozessor (CPU), Speicher sowie Ein- und Ausgabeeinheit (I/O) zu erkennen ist. Der Speicher ist als Secure Storage ausgelegt, sodass von außen nicht direkt darauf zugegriffen werden kann. Weiterhin wird zwischen einem flüchtigen und einem nicht flüchtigen Speicher unterschieden. Der nicht flüchtige Speicher (Non-volatile Memory) ist für das persistente Speichern der beiden wichtigsten Schlüssel vorgesehen: „Endorsement Key“ und „Storage Root Key“. Die Konfigurationsdaten für die Plattform (Platform Configuration Registers) sowie via System generierte Schlüssel (Loaded Keys) werden im „Volatile Memory“ abgelegt. Die kryptografische Einheit stellt folgende Funktionalitäten bereit: Generieren von Hash-Werten und asymmetrischen RSA-Schlüsseln, Signier- und Verschlüsselungsfunktionen, sowie Generieren von Zufallszahlen.

Abb. 2: TPM-Chip von Infineon

Abb. 2: TPM-Chip von Infineon

Eine Zertifizierung gemäß internationaler Standards (EAL, NIST etc.) gilt als allgemeiner Nachweis für die Erfüllung und Einhaltung der von der Trusted Computing Group vorgeschriebenen restriktiven Sicherheitsanforderungen für ein TPM. Hierbei ist insbesondere der Nachweis zu erbringen, dass das Modul nicht nur gegen Softwareattacken geschützt, sondern auch in hohem Maße gegen mechanische Angriffe resistent ist. So ist beispielweise der Nachweis zu erbringen, dass der Speicherinhalt eines diskreten TPM-Schaltkreises sofort zerstört wird, sollte der Versuch unternommen werden, diesen mechanisch zu öffnen und so den Chip freizulegen. Obwohl der in Abbildung 2 gezeigte TPM-Schaltkreis äußerlich nicht von einem Standardbaustein zu unterscheiden ist, erfüllt der interne Aufbau die strengen Kriterien, die für die Klassifizierung „Tamper Resistant“, also Manipulationssicherheit, spezifiziert sind.

Anwendungsspektrum

Auf ein TPM kann immer dann zurückgegriffen werden, wenn es gilt, sichere kryptografische Operationen durchzuführen und/oder ein sicheres Speichermedium bereitzustellen. Aufgrund des geringen Stückpreises kann man einem TPM gegenüber teurer Zusatzhardware den Vorzug geben, sofern keine Einschränkungen durch andere Randbedingungen bestehen. Falls beispielsweise ein hoher Durchsatz bezüglich kryptografischer Funktionen gefordert ist, oder sehr große Datenmengen hochsicher zu speichern sind, kommt man um ein HSM (Hardware Security Module) nicht herum. Ein HSM liegt entweder als PCI-Erweiterungssteckkarte für einen PC-Slot vor, oder ist als Netzwerkkomponente im 19″-Format erhältlich.

Das Anwendungsspektrum eines mit einem aktiven TPM ausgestatteten Systems erstreckt sich derzeit im Wesentlichen auf nachstehend aufgeführte Technologien.

Schutz elektronischer Daten (Data Protection): Realisierung durch symmetrische, asymmetrische oder hybride kryptografische Verfahren. Hierzu werden primär digitale Schlüssel benötigt, die sicher generiert und sicher gespeichert werden müssen. Dies setzt ein probates Schlüsselmanagement voraus, das beispielsweise auf einem TPM basieren kann. Neben dem klassischen Verschlüsseln und Signieren elektronischer Daten bzw. Dateien, sind in diesem Kontext so genannte selbstverschlüsselnde Speichermedien (Self-Encrypting Drive/SED), sowie proprietäre Verschlüsselungslösungen wie „BitLocker“ von Microsoft zu nennen.

Benutzer und Systemauthentifizierung: Die für die Verifikation einer digitalen Identität erforderlichen Schlüssel und Zertifikate können ebenfalls sicher in einem TPM gespeichert werden. Allgemein betrachtet können die für die Authentifizierung von Benutzern und Systemen benötigten Berechtigungen („Credentials“) durch ein TPM geschützt werden und stehen unter anderem für den sicheren Kommunikationsaufbau von VPN, Drahtlosnetzwerken oder Cloud-Computing zur Verfügung. Auch wenn sich hier erneut der Vergleich mit einer Smartcard anbietet, muss man sich sofort ins Gedächtnis zurückrufen, dass ein TPM an eine Plattform, bzw. ein System gebunden ist, und nicht an einen Benutzer („Card-Holder“).

Plattformbescheinigung (Remote-Attestation): Dieses Feature wird bereits zu Beginn des Boot-Prozesses aktiv. Schon in diesem frühen Stadium wird hierbei überprüft, ob die Systemintegrität gewahrt ist. Das Ergebnis wird sicher gespeichert und kann von autorisierten Dritten online abgefragt werden. Weiterhin kann kontrolliert werden, welche Softwarekomponenten innerhalb der Plattform zugelassen sind und ausgeführt werden können.

Der Fokus liegt eindeutig auf Analyse und Protokollierung des Status einer Plattform, d. h. das aktive Verhindern von Manipulationen und schädlichen Eingriffen durch Malware ist nicht Sache des TPM. Hierfür können andere Mechanismen eingesetzt werden, die auf das Ergebnis der Plattformüberprüfung zurückgreifen.

Kritikpunkte und Privatsphäre

Wie bereits erwähnt, haben TPMs Einzug in nahezu alle neueren Computer, Tablets und sogar Smartphones erhalten. Auf den ersten Blick erscheint das mit einem TPM angestrebte Ziel, eine vertrauenswürdige Plattform und restriktive Sicherheitsrichtlinien (Security Policies) realisieren zu können, äußerst erstrebenswert. Kritiker melden sich allerdings dahingehend zu Wort, dass der Einsatz der TPM-Technologie an einige rudimentäre Bedingungen geknüpft sein müsste. Die nachstehende Aufstellung gibt diesbezüglich einen minimalen Anforderungskatalog mit den wichtigsten Kriterien wieder.

  • TPM ist nicht aktiviert im Auslieferungszustand eines Systems
  • Aktivierung ist freiwillig und nicht verpflichtend
  • Ohne Aktivierung ergeben sich keine funktionellen Einschränkungen
  • Deaktivierung muss jederzeit uneingeschränkt möglich sein
  • Intuitive Managementsoftware zur Verwaltung des TPM
  • Automatische Analysen im Hintergrund müssen für den Anwender transparent sein
  • Gespeicherte Informationen müssen im Klartext einsehbar sein
  • Durch Dritte abgerufene Informationen (Remote-Attestation) müssen protokolliert werden

Die beiden erstgenannten Kardinalforderungen, dass ein TPM im Auslieferungszustand nicht aktiviert ist und ein System mit integriertem TPM auch weiterhin ohne Aktivierung keinen Einschränkungen unterworfen sein darf, erfüllt die aktuelle „TPM-Spezifikation-1.2“. Dies sieht allerdings mit der Version 2.0 etwas anders aus, hier soll nämlich alleinig das Betriebssystem die Aktivierung und die Kontrolle über das TPM übernehmen.

Zudem ist es ein grundsätzliches Ziel von Softwareherstellern sowie Anbietern von Apps und Medien (wie Musikdateien), auf die in einem internen Speicher des TPM erfassten Daten im Rahmen einer Remote-Kommunikation zyklisch zuzugreifen und diese auszuwerten. Hiermit ließen sich Raubkopien erkennen und es wäre kein aufwändiger Schutz in Form eines Dongle oder ähnlicher Hardware notwendig. Der wesentliche Unterschied besteht allerdings darin, dass ein Dongle und die korrespondierende Software gemeinsam auf ein anderes System übertragen werden können, ohne dass eine neue Lizenz beschafft werden müsste. Ein TPM kann jedoch im Gegensatz zu einem Dongle nicht einfach von einem System abgezogen und in ein anderes System eingesteckt werden. Das hat zur Konsequenz, dass die Lizenzierung bzw. Aktivierung beispielsweise nach einem Systemcrash erneut durchlaufen werden müsste.

Nachfolgend sind die mit einem aktivierten TPM realisierbaren Anwendungs- und Einsatzszenarien auszugsweise zusammengestellt (ohne Wertung und Anspruch auf Vollständigkeit):

  • Pre-Boot Systemintegritätstests und Schutz vor Schadsoftware
  • Plattformbescheinigung (Remote-Attestation)
  • Kontrolle des Computers durch Dritte aus der Ferne
  • Unbemerkter Zugriff auf das TPM und dessen Daten durch Dritte möglich
  • Bindung einer aktivierten bzw. freigeschalteten Software an eine Plattform (System)
  • Aufzeichnung von Benutzeraktivitäten
  • Kontrolle (durch Dritte) darüber, welche Software auf einer Plattform ausgeführt werden darf, Einschränkung auf bestimmte Applikationen, also beispielsweise Blockierung von Open Source-Software
  • Bestimmte Anwendungen haben nur mit einem TPM den vollen Funktionsumfang (BitLocker etc.)
  • Kopierschutz für Software und digitale Medien
  • Musikdateien, oder anderes digitales Eigentum nicht ohne Weiteres auf andere Plattform übertragbar, obwohl rechtmäßig erworben
  • Authentifizierung einer Plattform und nicht eines Benutzers
  • Zugriff auf TPM-Schlüssel via Hintertürchen (OS-Hersteller, NSA etc.); Gefahr von Backdoor-Attacken demzufolge nicht auszuschließen
  • Nichtübertragbarkeit geschützter Datenobjekte (Schlüssel), daher sehr problematische Backup- und Recovery-Strategien
  • Letztendlich könnte der Wechsel auf ein anderes System erschwert oder nahezu unmöglich gemacht werden, oder aufgrund zu hoher Kosten unzumutbar sein

Obwohl die einzelnen Aspekte von den diversen Lagern naturgemäß völlig konträr gesehen und bewertet werden, sollte sich doch dahingehend ein gemeinsamer Konsens herbeiführen lassen, dass die Aktivierung des TPM auf freiwilliger Basis ausschließlich durch den Systemeigentümer (Benutzer) vorgenommen werden kann und der Einzelne somit sein Maß an Privatsphäre selbst definieren kann.

Dass die Realität etwas anders aussehen kann, stellt Microsoft unter Beweis, indem es das aktuelle Windows Phone 8.1 bereits mit einem aktivierten TPM ausstattet; und zwar schon bevor es der Käufer das erste Mal in seinen Händen hält. Gemäß einer Publikation von Microsoft [2] ist das TPM ein wichtiges Securityfeature der aktuellen Windows-Betriebssysteme. Ein Standardtool zur Deaktivierung ist auf einem Windows Phone 8.1 derzeit nicht installiert und steht für diese Plattform auch nicht im Online-Store zum Download bereit.

Zustände und Zustandsänderungen

Bevor ein TPM verwendet werden kann, muss es zunächst initialisiert werden. Im Anschluss daran kann das TMP in einen bestimmten Zustand versetzt werden. Grundsätzlich handelt es sich dabei um einen der folgenden primären Zustände:

  • Das TPM ist nicht einsatzbereit.
  • Das TPM ist deaktiviert, und der Besitz des TPM wurde nicht übernommen.
  • Das TPM ist einsatzbereit.

Weist das TPM den Status „einsatzbereit“ auf, ist eine Reihe von weiteren Aktionen verfügbar (Tabelle 1).

Tabelle 1: Verfügbare Aktionen eines einsatzbereiten TPM

Tabelle 1: Verfügbare Aktionen eines einsatzbereiten TPM

Unter den Windows-Betriebssystemen ist für die Administration eines TPM ein Plug-in für eine Microsoft-Management-Konsole (MMC) verfügbar. Zunächst ist die MMC mit mmc.exe zu starten, anschließend unter Datei | Snap-in hinzuzufügen. Das Snap-in kann über „TPM-Verwaltung“ ausgewählt werden. Abbildung 3 zeigt neben den verfügbaren Aktionen den TPM-Status sowie die TPM-Herstellerinformationen eines einsatzbereiten TPM. Optional kann durch das Starten von tpm.msc direkt eine Administrationskonsole mit TPM-Snap-in geöffnet werden.

Abb. 3: TPM-Verwaltung

Abb. 3: TPM-Verwaltung

Systemintegration (OS)

Grundsätzlich fungiert das Betriebssystem als Interface zwischen einem TPM und der Applikation, die auf das TPM zugreift. Genauer gesagt liegt ein proprietärer Treiber zwischen dem Betriebssystem und der TPM-Hardware. Welche Befehle für eine Applikation zugelassen oder blockiert sind, kann mit der in Abbildung 4 gezeigten TPM-Befehlsverwaltung festgelegt werden. Zur Änderung des Status ist zunächst der Befehl zu selektieren. Anschließend kann entweder über den Hauptmenüpunkt „Aktion“ oder via rechte Maustaste und Kontextmenü der Status des Befehls zugelassen oder blockiert werden. Hierfür stehen kontextsensitiv die Optionen „Ausgewählten Befehl zulassen“ oder „Ausgewählten Befehl blockieren“ zur Auswahl.

Abb. 4: TPM-Befehlsverwaltung

Abb. 4: TPM-Befehlsverwaltung

Ein Befehl wird einer bestimmten Kategorie zugeordnet und trägt einen Namen in Form einer Mnemonik. Weiterhin ist jeder Befehl durch einen Status gekennzeichnet, der einen der beiden Werte „Zugelassen“ oder „Blockiert“ annehmen kann. In Tabelle 2 sind exemplarisch einige Befehle und deren Status für diverse Windows-Betriebssysteme zusammengestellt. Bei den hier aufgeführten Status handelt es sich um Default-Werte, wie sie nach der Betriebssysteminstallation vorliegen, d. h. es wurde keine Veränderung durch einen Anwender oder eine Softwarekomponente vorgenommen.

Tabelle 2: Default-Status unterschiedlicher Windows-Betriebssysteme

Tabelle 2: Default-Status unterschiedlicher Windows-Betriebssysteme

Interessant ist hierbei die Tatsache, dass Windows 7 und Server 2008R2 Befehle mit den Status „Zugelassen“ aufweisen, während sich die äquivalenten Befehle der neueren Betriebssysteme Windows 8 und Server 2012 jeweils im Status „Blockiert“ befinden. Beispielsweise konnte der Befehl „TPM_Init“ unter Windows 7 ausgeführt werden, da sein Status auf „Zugelassen“ stand, während derselbe Befehl unter Windows 8 blockiert wird.

Je nach Bedarf können die Status der einzelnen TPM-Befehle mit dem Tool tpm.msc modifiziert werden, also beispielsweise von „Zugelassen“ auf „Blockiert“ gesetzt werden. Obwohl eine derartige Modifikation leicht vonstattengeht, sollte man sich dennoch darüber im Klaren sein, dass durch das Blockieren eines Befehls eine das TPM verwendende Anwendung nicht mehr korrekt arbeiten wird.

Neben den mit dem Tool tmp.msc möglichen Veränderungen der einzelnen Status können diverse Einstellungen des TPM mit den lokalen Gruppenrichtlinien modifiziert werden, indem das entsprechende Snap-in durch die Eingabe von gpedit.msc geöffnet und die Konsolenstruktur wie folgt erweitert wird: Computerkonfiguration | Administrative Vorlagen | System| TPM-Dienste.

Zudem lassen sich die TPM-Einstellungen über das Gruppenrichtlinienmanagement für Domänen verwalten, indem auf einem Domain-Controller das Snap-in gpmc.msc gestartet und auf die zuvor beschriebene Konsolenstruktur erweitert wird. Hierbei sollte man allerdings sehr vorsichtig zu Werke gehen, da aufgrund der Mächtigkeit von auf Domänen bezogenen Group Policy Objects eine komplette Domäne bis hin zu einem Forrest lahmgelegt werden kann.

Abb. 5: Registrierungs-Editor regedit.exe

Abb. 5: Registrierungs-Editor regedit.exe

Lokal sind die TPM-Parameter in der Registry von Windows gespeichert, und zwar unter dem Schlüssel HKEY_LOCAL_MACHINESoftwareMicrosoftTpm. Unterhalb dieses Schlüssels existieren genau vier Subschlüssel (Abb. 5).

Kryptografie

Grundsätzlich unterscheidet man zwischen symmetrischen und asymmetrischen kryptografischen Verfahren. Bei den symmetrischen Verfahren wird für das Ver- und Entschlüsseln von Daten ein und derselbe Schlüssel verwendet. Dieser so genannte „geheime“ Schlüssel muss entsprechend geschützt, d. h. in einer sicheren Umgebung generiert und gespeichert werden. Falls das Ver- und Entschlüsseln von verschiedenen Personen oder von unterschiedlichen Orten aus vorgenommen werden soll, muss der hierfür erforderliche Schlüsselaustausch bzw. Schlüsseltransport unbedingt unter Einhaltung strenger Sicherheitsvorgaben abgewickelt werden. Aktuell finden die in Tabelle 3 aufgeführten symmetrischen Algorithmen Anwendung, wobei AES der neueste Standard ist.

Tabelle 3: Kryptografische Standardalgorithmen

Tabelle 3: Kryptografische Standardalgorithmen

Asymmetrische Verfahren basieren auf einem „privaten“ Schlüssel (Private Key) und einem „öffentlichen“ Schlüssel (Public Key), wobei beide Schlüssel mathematisch korreliert sind. Zusätzlich zu den verfügbaren Verschlüsselungsfunktion eignen sich asymmetrische Verfahren auch zum Generieren und Verifizieren von digitalen Signaturen. Der private Schlüssel wird zum Generieren einer Signatur und zum Entschlüsseln von verschlüsselten Daten verwendet. Der öffentliche Schlüssel hingegen zum Verifizieren einer Signatur und zum Verschlüsseln von Daten. Die derzeit aktuellen Standards sind in Tabelle 5 zusammengestellt. Der traditionelle RSA-Algorithmus ist noch immer am weitesten verbreitet und wird von nahezu allen Systemen unterstützt. Der neuere auf elliptischen Kurven basierende EC-Algorithmus bietet einige Vorteile gegenüber RSA, unter anderem eine signifikant kleinere Schlüssellänge, bei gleichem Security-Level. In Tabelle 4 sind symmetrische und asymmetrische Algorithmen und die zugehörigen Security-Level gegenübergestellt.

Tabelle 4: Security-Level

Tabelle 4: Security-Level

Hash-Algorithmen erzeugen aus einer beliebig langen Eingangssequenz (Bytes) eine Ausgangssequenz mit genau festgelegter Länge. Weiterhin muss jede unterschiedliche Eingangssequenz eine unterschiedliche Ausgangssequenz, den so genannten Hash-Wert, erzeugen. Ist diese Forderung erfüllt, wird der Hash-Algorithmus als kollisionsfrei bezeichnet. Hash-Algorithmen werden zum Beispiel vor jedem Signaturvorgang angewendet, da die Eingangssequenz der einzelnen Signaturalgorithmen genau definierte Längen aufweisen muss. In Abbildung 6 ist eine Verschlüsselungssignatursequenz veranschaulicht. Die Eingangssequenz in Form einer Klartextdatei wird im oberen Zweig mit einem symmetrischen Schlüssel verschlüsselt. Hierfür kann beispielsweise ein

Tripple-DES-Algorithmus verwendet werden. Im unteren Zweig wird zunächst der Hashwert der Eingangssequenz berechnet und im Anschluss daran erfolgt die Generierung einer Signatur. Der Geheimtext und die Signatur werden im letzten Schritt konkateniert, sodass letztendlich ein verschlüsseltes, signiertes Dokument vorliegt.

Abb. 6: Verschlüsseln und Signieren eines Klartextes

Abb. 6: Verschlüsseln und Signieren eines Klartextes

Ein digitales Zertifikat enthält primär einen Aussteller (Issuer) und einen Antragsteller (Subject), sowie einen Gültigkeitszeitraum und einen öffentlichen Schüssel. Somit kapselt ein digitales Zertifikat einen öffentlichen Schlüssel und ordnet diesen einem Aussteller und einem Antragssteller genau zu. Der ansonsten völlig anonyme öffentliche Schlüssel in Form einer Bytesequenz wird somit greifbar, und es kann entschieden werden, ob er für eine Verifikation benutzt werden soll. Ob der Aussteller des Zertifikats vertrauenswürdig ist, kann nachweislich nur mit der PKI (Public Key Intrastructure), von der das Zertifikat ausgegeben wurde, validiert werden. Genauer betrachtet handelt es sich bei dem Aussteller um eine Zertifizierungsstelle (Certificate Authority) als zentrales Element jeder PKI [3]. Ein digitales Zertifikat, das internationalen Standards genügt, ist gemäß RFC 5280 strukturiert und kodiert, sodass die Interoperabilität zwischen verschiedenen Systemen gewährleistet ist. Als Kodierung kommt entweder Base64 oder ASN.1 in Frage.

Kryptografische Artefakte eines TPM

Nachstehend sind die wichtigsten kryptografischen Artefakte eines TPM wie Schlüssel, Zertifikate und Passphrasen kurz beschrieben. Eine detaillierte Beschreibung ist in [4] gegeben.

Endorsement Key (EK): Die wohl wichtigste Komponente eines TPM ist der Endorsement Key (EK), der bereits während der Fertigung generiert und in das TPM eingebrannt wird und somit nicht verändert werden kann. Genauer betrachtet handelt es sich um ein asymmetrisches RSA-Schlüsselpaar (2 048 Bit), wobei der private Schlüssel mit „PRIVEK“ und der öffentliche mit PUBEK bezeichnet werden. Auf diesen privaten Schlüssel kann zu keinem Zeitpunkt von außen zugegriffen werden, weder von einer anderen Hardwarekomponente, noch von einem Tool oder einer Applikation. Beispielsweise wird der private Schlüssel „PRIVEK“ bei der Generierung von Signaturen verwendet. Das Generieren erfolgt allerdings intern in der Cryptographic Unit des TPM (vgl. Abb. 1), sodass gemäß Forderung der Schlüssel PRIVEK niemals das TPM verlässt. Eine generierte Signatur kann mithilfe des korrespondierenden öffentlichen Schlüssels verifiziert werden.

Storage Root Key (SRK): Der Storage Root Key ist im TPM eingebettet, und auf die private Schlüsselkomponente kann ebenfalls nicht von außen zugegriffen werden. Die Aufgabe des Storage Root Key ist der Schutz (Verschlüsselung) von TPM-Schlüsseln, die von Applikationen generiert wurden und im TPM gespeichert sind. Im Gegensatz zum Endorsement Key wird der Storage Root Key nicht bereits bei der Herstellung generiert, sondern erst dann, wenn das TPM zum ersten Mal initialisiert, oder einem neuen Benutzer zugewiesen wird.

Endorsement Certificate: Das Endorsement Certificate wird vom Hersteller generiert und enthält den zu dem privaten Endorsement Key PRIVEK korrespondierenden öffentlichen Schlüssel PUBEK. Weiterhin enthält dieses Zertifikat den Herausgeber (Issuer) und den Antragsteller (Subject), sowie eine Seriennummer und eine Gültigkeitsangabe (not before und not after). Der im Endorsement Certificate enthaltene öffentliche Schlüssel ermöglicht somit die Verifikation von mit dem privaten Schlüssel signierten Daten. Somit kann beispielsweise eine Attestation auf Echtheit verifiziert werden.

Abb. 7: TPM-Zertifikatsdaten

Abb. 7: TPM-Zertifikatsdaten

Das PowerShell Commandlet „Get-TpmEndorsementKeyInfo“ liefert die Zertifikatsdaten eines aktivierten TPM (Abb. 7). Optional wurde hier der Parameter HashAlgorithm sha256 angegeben, sodass zusätzlich der Hash-Wert des öffentlichen Schlüssels mit ausgegeben wird.

Platform Configuration Register (PCR): Ein Platform Configuration Register ist ein Speicherbereich, in dem die Momentaufnahmen der Zustände von Konfigurationen von Hard- und Software einer Trusted-Plattform gespeichert werden können. Genauer betrachtet werden Hash-Werte von Systemzuständen und Softwarekomponenten, wie beispielsweise der des Betriebssystemkernels, gespeichert. Die gespeicherten Daten können zur Validierung der Systemintegrität verwendet werden. Im Gegensatz zu einem externen Crypto Token (Smart Card etc.) garantiert ein fest eigebautes TPM, dass es in jedem Fall bereits während des Boot-Vorgangs präsent ist und diesen mitverfolgen kann.

TPM Owner Password: Per Definition gilt derjenige als Besitzer (Owner) des TPM, der das Owner Password kennt. Pro TPM existiert nur ein einziges Owner Password. Der Besitzer kann von der vollen TPM-Funktionalität Gebrauch machen. Es bleibt ausschließlich dem Besitzer vorbehalten, ein TPM-Remote zu manipulieren, also freizugeben, zu sperren oder zu löschen. Das TPM Owner Password kann während der Initialisierung in einer Datei gespeichert oder gedruckt werden.

Fazit

Solange es einem Besitzer eines Computersystems bzw. einer Plattform möglich ist, ein fest integriertes TPM abzuschalten, ohne dass das Gesamtsystem oder Teilsysteme unbenutzbar werden, kann jeder individuell entscheiden, ob das TPM aktiviert werden soll oder nicht. Nichtsdestotrotz mutiert ein TPM zu einem nicht ganz unumstrittenen Begleiter in fast allen neueren Computern und Tablets und löst im Rahmen von Remote-Attestation von Zeit zu Zeit Diskussionen bezüglich des Datenschutzes aus. Inwieweit sich die Unterhaltungsbranche ein aktiviertes TPM zunutze macht, um illegale Raubkopien oder Downloads zu blockieren, wird erst die Zukunft zeigen. Außerdem bleibt abzuwarten, ob die Version 2.0 der TPM-Spezifikation weiterhin eine gewisse Wahlfreiheit zulässt oder ob drastische Restriktionen umgesetzt werden.

Links & Literatur

[1] „Grundlagen und Standards von Chipkarten“, in Windows Developer 07.2012 [2] Windows Phone 8.1 Security Overview, Microsoft April 2014 [3] „Microsoft Certificate Authority“, dot.NET Magazin 06.2010 [4] TPM Main-Part 1 Design Principles, Trusted Computing Group

 

Unsere Redaktion empfiehlt:

Relevante Beiträge

Meinungen zu diesem Beitrag

X
- Gib Deinen Standort ein -
- or -