Was bin ich? : Zertifikatsbasierte IoT-Geräte-Authentifizierung mit TPM 2.0

Eine vertrauensvolle Authentifizierung mithilfe asymmetrischer Kryptografie erfordert immer die Verifikation des Schlüsselinhabers. Wo das ein Mensch ist, der uns persönlich eine Kopie seines öffentlichen Schlüssels übergibt, ist alles klar und einfach. Ganz anders sieht es jedoch bei den geschätzt 30 Milliarden Geräten im Internet der Dinge (IoT) aus: Viele solche Systeme befinden sich inzwischen in Privathäusern und Fahrzeugen, aber auch in bedeutenden oder kritischen zivilen und sogar militärischen Infrastrukturen – Tendenz steigend. Kompromittierte Geräte oder geheime Schlüssel (Private Keys) stellen ein schwerwiegendes Sicherheitsrisiko dar. Und Dienste für IoT-Geräte müssen sicherstellen, dass sie mit echten, autorisierten und sicheren Geräten kommunizieren.

Das TPM-Protokoll ist in der Lage, das Vertrauen in zertifikatsbasierte Authentifizierungsprozesse von IoT-Geräten und die damit verwendeten Dienste zu verbessern, wenn ein Trusted-Platform-Module (TPM) auf den Geräten zum Einsatz kommt. Ein TPM ermöglicht als eine sichere Systemkomponente (in Verbindung mit anderen Systemkomponenten) einem unabhängigen Dritten festzustellen, ob die vertrauenswürdige Basis eines Geräts kompromittiert worden ist. TPMs werden auf heutigen PCs und Notebooks häufig für Anwendungen wie Secure Boot, vollständige Festplattenverschlüsselung oder hardwarebasierten Kennwortschutz verwendet. Die TPM-Spezifikationen und -Protokolle (derzeit in Version 2.0) werden von der Trusted Computing Group (TCG) entwickelt (https://trustedcomputinggroup.org).

In Bezug auf IoT-Geräte ist die Eigenschaft eines TPM entscheidend, als kostengünstiger kryptografischer Co-Prozessor fungieren zu können, der für eine sichere, manipulationsgeschützte und hardwarebasierte Schlüsselgenerierung sowie chiffrierte Schlüsselspeicherung sorgt. Jedes TPM verfügt über einen eindeutigen und geheimen sogenannten Endorsement-Key (EK), der normalerweise von einer vertrauenswürdigen Zertifizierungsstelle (CA) zertifiziert wird. Auf dieser Basis kann man Authentifizierungslösungen entwickeln, die sicherstellen, dass ein Kommunikationsgerät ein legitimes und identifizierbares TPM enthält. In Kombination mit anderen TPM-Funktionen wie Secure Boot sowie Hardware-/Software-Testaten lässt sich die Sicherheit einer IoT-Bereitstellung so erheblich verbessern.

Gerätezertifizierung

Der EK ist einzigartig für jedes TPM – er wird entweder direkt im TPM generiert oder vom Hersteller in das TPM eingebrannt und seine geheime Komponente ist durch die TPM-Hardware geschützt und lässt sich weder auslesen noch aus dem TPM exportieren. Mithilfe des öffentlichen EK-Schlüssels nebst Zertifikat, könnte man also ein TPM im Prinzip sicher und eindeutig als solches und als Teil eines IoT-Geräts identifizieren, wenn sich anschließend per digitaler Signatur nachweisen ließe, dass dieses Gerät die geheime EK-Komponente besitzt beziehungsweise nutzen kann.

Wenn sich ein Gerät bei einem Onlinedienst authentifizieren möchte, ist die zertifikatsbasierte Clientauthentifizierung per Transport-Layer-Security (TLS) eine gängige Lösung. Während des TLS-Handshakes stellt das Gerät dem Server eine Kopie seines Zertifikats zur Verfügung und signiert einige protokollspezifische Informationen, um zu beweisen, dass es den geheimen Schlüssel besitzt, der dem öffentlichen Schlüssel im Zertifikat entspricht. Der Server überprüft das Zertifikat anhand seiner Datenbank vertrauenswürdiger CAs und checkt zudem kryptografisch die vom Gerät bereitgestellte digitale Signatur. Wenn beide Schritte (und ggf. zusätzliche dienstspezifische Prüfungen) erfolgreich sind, ist das Gerät authentifiziert.

Allerdings ist die Verwendung des EK durch das TPM auf einen begrenzten Satz von Entschlüsselungsoperationen beschränkt. Das Gerät kann ihn daher nicht verwenden, um digitale Signaturen zu erstellen und sein EK-Zertifikat dementsprechend auch nicht auf diese Art und Weise für die TLS-Client-Authentifizierung nutzen.

Die Lösung besteht darin, dass das Gerät mithilfe des TPM einen zweiten hardwaregeschützten Schlüssel generiert, der für digitale Signaturen verwendet werden kann – und dass dieser neue Schlüssel von einer CA zertifiziert wird: Die Zertifizierungsstelle überprüft dabei den EK und stellt dem Gerät bei Erfolg ein Zertifikat für diesen neuen Schlüssel aus. Diese Vorgehensweise bringt gleichzeitig einige Datenschutzvorteile mit sich: Da der EK das Gerät eindeutig identifiziert, ließe sich beim Einsatz des EK-Zertifikats zur Authentifizierung die Aktivität eines Geräts über mehrere Dienste hinweg verfolgen und korrelieren, was möglicherweise nicht erwünscht ist. Durch die Verwendung von Sekundärschlüsseln kann man für jeden Dienst, auf den das Gerät zugreift, ein separates Zertifikat ausstellen. Es lässt sich im Prinzip sogar ein separates Zertifikat für jeden einzelnen Zugriff auf denselben Dienst ausstellen. So bleibt die Privatsphäre gewahrt.

Ein solches Verfahren verlagert aber nun, wie angemerkt, den Aufwand der Identifizierung des TPM auf die Zertifizierungsstelle. Aber wenn der EK nicht für digitale Signaturen verwendet werden kann – wie überprüft eine Zertifizierungsstelle dann, ob das Gerät den zugehörigen geheimen Schlüssel besitzt?

Speicher-Architektur

Die TCG-Lösung ist konzeptionell einfach: Anstatt das Gerät vor der Ausstellung eines Zertifikats dazu aufzufordern, nachzuweisen, dass es die geheime EK-Komponente besitzt, stellt die Zertifizierungsstelle im Wesentlichen ein mit der öffentlichen EK-Komponente verschlüsseltes Zertifikat aus. Dieses kann nur ein Gerät entschlüsseln, das die geheime Komponente des EK besitzt – darüber hinaus kann das Gerät das Zertifikat nur entschlüsseln, wenn der zu zertifizierende Schlüssel auch in das TPM geladen ist. Die Benutzer des Zertifikats können so also sicher sein, dass das Gerät nicht nur ein gültiges TPM enthält, sondern dass der Schlüssel, mit dem es sich authentifiziert, auch durch das TPM geschützt ist und daher ein geringeres Risiko für eine Kompromittierung besteht.

Um das Protokoll zu verstehen, ist ein Rückblick auf die Nutzung asymmetrischer Schlüssel im TPM hilfreich: Dort gibt es für jedes Schlüsselpaar einen „öffentlichen Bereich“ und einen „geheimen Bereich“. Letzterer enthält den geheimen Schlüssel und kann entweder (wie beim EK) nie ausgelesen und aus dem TPM exportiert oder nur zur Speicherung in verschlüsselter Form exportiert werden, die sich dann nur mit demselben TPM wieder entschlüsseln lässt. Obwohl der geheime Bereich eines Schlüssels niemals direkt ausgelesen werden kann, lassen sich dennoch TPM-Schlüssel erstellen, die auf ein anderes TPM migriert oder dupliziert werden können. Eine Zertifizierungsstelle kann jedoch sicherstellen, dass keine Zertifikate für Schlüssel ausgestellt werden, die sich auf diese Weise duplizieren ließen.

Der öffentliche Bereich muss dagegen nicht vertraulich sein – auch wenn die Möglichkeit von Verknüpfungen seiner Inhalte mit einem bestimmten Benutzer oder Gerät die Privatsphäre oder andere schutzwürdige Interessen gefährden kann. Normalerweise kann jeder, der physischen Zugang zum TPM hat, darauf zugreifen. Der öffentliche Bereich umfasst unter anderem:

• Informationen zur Art des Schlüssels (z. B. RSA, ECC oder auch symmetrische Verfahren),
• den zur Berechnung seines „Namens“ verwendeten Hash-Algorithmus,
• die öffentliche Komponente des Schlüssels (bei einem asymmetrischen Schlüssel),
• die Angabe des symmetrischen kryptografischen Algorithmus, mit dem untergeordnete Schlüssel verschlüsselt werden, wenn es sich um einen Speicherschlüssel handelt (der EK ist immer ein Speicherschlüssel) sowie
• verschiedene weitere Attribute – zum Beispiel, ob der Schlüssel zum Signieren oder Entschlüsseln oder für beides verwendet oder in ein anderes TPM dupliziert werden darf.

Der angesprochene „Name“ eines Schlüssels ist ein Hash seines gesamten öffentlichen Bereichs, der mit dem angegebenen Algorithmus erstellt wird – wenn sich also ein Teil im öffentlichen Bereich eines Schlüssels verändert, ändert sich auch sein „Name“.

Aufgaben der CA

Zusätzlich zu einer Kopie des EK-Zertifikats muss eine Zertifizierungsstelle in der Regel mindestens die öffentlichen Bereiche der folgenden Komponenten erhalten:

• des Endorsement-Key (EK), da die CA dessen öffentlichen Schlüssel und die Algorithmen für den Namens-Hash sowie die symmetrische Verschlüsselung benötigt
• des zu zertifizierenden Schlüssels, weil die CA den öffentlichen Schlüssel zum Einfügen des ausgestellten Zertifikats benötigt und seinen „Namen“ berechnen muss
  Optional kann sie damit auch die anderen Attribute untersuchen und entscheiden, ob sie ein Zertifikat für diesen Schlüssel ausstellen möchte oder nicht.
  Wenn die Zertifizierungsstelle beschließt, ein Zertifikat auszustellen, gibt sie einen sogenannten CredentialBlob zurück. Dieser besteht aus zwei Teilen:
• einem Keyed-Hash Message-Authentication-Code (HMAC) zur Authentifizierung und
• dem eigentlichen „Beglaubigungsschreiben“ (Credential) – verschlüsselt mit dem symmetrischen Algorithmus, der im öffentlichen Bereich des EK angegeben ist.

Eigentlich würde das genügen – es gibt allerdings zwei Probleme: Erstens ist das Credential in seiner Größe auf die Größe des Digests beschränkt, der vom Namensalgorithmus des Endorsement-Key erzeugt wird. Bei SHA256 wären dies beispielsweise 32 Byte, was viel zu klein ist, um ein Zertifikat zu verpacken. Daher verschlüsselt die Zertifizierungsstelle das eigentliche Zertifikat separat mit einem symmetrischen Schlüssel, den sie zufällig generiert. Dieser symmetrische Schlüssel wird dann zum Credential im Protokoll.

Das zweite Problem besteht darin, dass sowohl der HMAC als auch das verschlüsselte Credential einen geheimen Schlüssel zum erneuten Berechnen/Entschlüsseln benötigen – und das TPM keinen von beiden vorliegen hat. Die Lösung besteht darin, beide Schlüssel über eine Standard-Schlüsselableitungsfunktion (KDF) zu berechnen, die verschiedene Eingabewerte nutzt. Fast alle diese Werte sind öffentlich (z. B. der „Name“ des zu zertifizierenden Schlüssels, bestimmte spezifische Zeichenfolgen, die von der TPM-Bibliotheksspezifikation vorgeschrieben werden usw.) und stehen dem TPM bereits zur Verfügung. Die Ausnahme ist eine Zufallszahl, der sogenannte Seed, der von der CA generiert wird. Um diesen dem TPM sicher mitzuteilen, verschlüsselt ihn die Zertifizierungsstelle wiederum mit dem öffentlichen Teil des EK.

Die Zertifizierungsstelle gibt also tatsächlich drei Dinge zurück:

• einen zufälligen Seed, der mit der öffentlichen EK-Komponente verschlüsselt ist,
• einen Credential-Blob, der einen HMAC und den Schlüssel für das symmetrisch verschlüsselte Zertifikat enthält, sowie
• das eigentliche Zertifikat, das mit ebendiesem Schlüssel chiffriert wurde.

Aufgaben des TPM

Sobald die Informationen von der Zertifizierungsstelle empfangen wurden, entschlüsselt das TPM den Seed zunächst mithilfe der geheimen EK-Komponente. Dieser Seed wird dann zusammen mit der KDF verwendet, um dieselben Schlüssel für HMAC und Credential zu berechnen, welche die Zertifizierungsstelle beim Erstellen des Credential-Blobs verwendet hat.

Dabei ist zu beachten, dass in diesem Fall einer der KDF-Inputs der „Name“ des zu zertifizierenden Schlüssels ist, den das TPM direkt von einem aktuell geladenen Schlüssel erhält. Die Zertifizierungsstelle hat diesen Namen ebenfalls verwendet, um den Verschlüsselungs-Key abzuleiten. Hier zeigt sich, warum er so wichtig ist: Da der Name ein Input in die KDF ist, schlägt die Aktivierung (Entschlüsselung) des Credentials fehl, wenn der öffentliche Bereich des Schlüssels im TPM nicht genau dieselben Eigenschaften aufweist, wie seine Version in der Zertifizierungsstelle.

Stellt das IoT-Gerät der Zertifizierungsstelle also beispielsweise einen öffentlichen Bereich zur Verfügung, in dem angegeben ist, dass der Schlüssel nicht für ein anderes TPM dupliziert werden kann, versucht dann aber, das Credential für einen TPM-Schlüssel zu dechiffrieren, der sich tatsächlich doch so duplizieren ließe, schlägt dessen Aktivierung fehl – das Gerät kann das Zertifikat nicht entschlüsseln und nutzen. Fordert das Gerät ein Zertifikat für einen Schlüssel an, der überhaupt nicht vom TPM geschützt ist, schlägt die Aktivierung ebenfalls fehl.

Unter Verwendung des Seeds und des Namens des zu zertifizierenden Schlüssels wird das TPM also:

• die KDF verwenden, um eigenständig den geheimen Schlüssel für den HMAC zu berechnen,
• den HMAC selbst erneut berechnen, um zu überprüfen, ob der verschlüsselte Berechtigungsnachweis während der Übertragung manipuliert wurde,
• die KDF verwenden, um eigenständig den geheimen Schlüssel zu berechnen, der von der CA für das Credential verwendet wurde, und
• das Credential entschlüsseln („aktivieren“) und an das steuernde Gerät zurückgeben.

Damit ist die Arbeit des TPM erledigt: Das IoT-Gerät verfügt nun über das Credential, also den symmetrischen Schlüssel, den es zum Entschlüsseln des eigentlichen Zertifikats benötigt – Letzteres kann ohne die Unterstützung des TPM erfolgen.

Bei der Bewertung dieses Vorgehens ist zu bedenken, dass der EK des TPM ein stark eingeschränkter Entschlüsselungs-Schlüssel ist und nur für bestimmte vom TPM definierte Zwecke verwendet werden kann. Vor allem kann ein Gerät (oder Nutzer) die Überprüfungen des zu zertifizierenden Schlüssels nicht umgehen, indem er etwa nur den Seed „manuell“ mit dem EK entschlüsselt und damit die HMAC- und Berechtigungsnachweisschlüssel mit der Standard-KDF errechnet. Das TPM wahrt die Integrität des Verfahrens, indem es dem EK nur erlaubt, die Entschlüsselung im Kontext des gesamten Aktivierungsprozesses für den Berechtigungsnachweis durchzuführen.

Fazit

Mit dem TPM-Protokoll können Dienstanbieter eine starke, hardwarebasierte IoT-Geräteauthentifizierung umsetzen – Hersteller von IoT-Geräten verschaffen ihren Produkten dank der Sicherheit eines Trusted-Platform-Modules und der Funktionen von TPM 2.0 einen potenziellen Wettbewerbsvorteil. Voraussetzung ist allerdings, dass sie mit einer verlässlichen Zertifizierungsstelle arbeiten, die das Protokoll korrekt implementiert.

Paul Griffiths ist Softwareentwickler bei GlobalSign.