Security TPM 2.0 und zertifikatsbasierte IoT-Geräteauthentifizierung

Anbieter zum Thema

NetModule AG

TXOne Networks

GMO GlobalSign Ltd.

Um die Sicherheit in IoT-Umgebungen zu erhöhen, kommen zertifikatsbasierte Geräteauthentifizierungsprozesse zum Einsatz. Schwachstelle hier sind jedoch öffentliche Schlüssel. Das TPM 2.0-Protokoll soll diese Lücke schließen.

Digitale Signaturen bilden, sofern sie ordnungsgemäß verwendet werden, eine solide Basis dafür, dass eine Nachricht von einem bekannten Absender gesendet und während der Übertragung nicht verändert wurde. Dieses Vertrauen kann man allerdings nur dann haben, wenn man sicher ist, dass der öffentliche Schlüssel in unserem Besitz wirklich diesem bestimmten Absender gehört. Dies wird allerdings zu einem nicht zu unterschätzenden Problem, wenn der Absender eines der geschätzt 30 Milliarden Geräte im Internet der Dinge ist. Viele dieser Geräte befinden sich inzwischen in privaten Häusern und Fahrzeugen, aber auch in kritischen zivilen und sogar militärischen Infrastrukturen. Tendenz steigend.

Das TPM 2.0-Protokoll schafft für Hersteller von IoT-Geräten und die verwendeten Dienste mehr Vertrauen in zertifikatsbasierte Geräteauthentifizierungsprozesse. Das Protokoll wahrt die Privatsphäre und verteilt Berechtigungsnachweise für Schlüssel auf einem TPM.

Was ist ein TPM?

Ein Trusted Platform Module (TPM) ist eine sichere Systemkomponente, die es in Verbindung mit anderen Systemkomponenten einer unabhängigen Entität erlaubt, festzustellen, ob die vertrauenswürdige Computerbasis eines Geräts kompromittiert worden ist. TPMs werden auf modernen PCs und Notebooks häufig für Anwendungen wie Secure Boot, vollständige Festplattenverschlüsselung und hardwarebasierten Kennwortschutz verwendet.

Hier konzentrieren wir uns auf den zentralen Faktor, dass ein TPM als kostengünstiger, kryptografischer Co-Prozessor fungieren kann, der für eine manipulationssichere, hardwarebasierte Schlüsselgenerierung sowie verschlüsselte Schlüsselspeicherung sorgt. Jedes TPM verfügt über einen eindeutigen und geheimen Endorsement Key (EK), der üblicherweise von einer vertrauenswürdigen Zertifizierungsstelle (CA - Certificate Authority oder Certification Authority) zertifiziert wird. Auf dieser Basis lassen sich praktische Authentifizierungslösungen entwickeln, die sicherstellen, dass ein Kommunikationsgerät ein legitimes und identifizierbares TPM enthält. Insbesondere in Kombination mit anderen TPM-Funktionen wie Secure Boot und Hardware- beziehungsweise Softwaretestaten lässt sich die Sicherheit im Internet of Things so erheblich verbessern.

#experte

Identity & Access Management

Die Zukunft von sicherem Identitätsmanagement

Gerätezertifizierung

Der EK ist für jedes TPM einzigartig. Er wird im TPM generiert oder vom Hersteller in das TPM eingebrannt. Die private Komponente wird durch die TPM-Hardware vor einem Auslesen oder Exportieren aus dem TPM geschützt. Nachdem die öffentliche EK-Komponente mit ihrem Zertifikat überprüft wurde (Im weiteren Verlauf dieses Artikels gehen wir davon aus, dass wir mit einem TPM mit EK-Zertifikat von einer vertrauenswürdigen Zertifizierungsstelle arbeiten.), ist das TPM dann positiv identifiziert, wenn wir nachweisen können, dass ein IoT-Gerät die private EK-Komponente besitzt. Die Verwendung des EK durch das TPM ist allerdings auf einen begrenzten Satz von Entschlüsselungsoperationen beschränkt. Das Gerät kann das TPM deshalb nicht zum Erstellen einer digitalen Signatur verwenden, um dadurch den Besitz der privaten EK-Komponente nachzuweisen (zum Beispiel durch TLS-Clientauthentifizierung).

Die Lösung: Das Gerät generiert mithilfe des TPM einen zweiten hardwaregeschützten Schlüssel, der für digitale Signaturen verwendet werden kann. Dieser neue Schlüssel wird von einer CA zertifiziert. Die Zertifizierungsstelle überprüft den EK und stellt dem Gerät bei Erfolg ein Zertifikat für diesen neuen Schlüssel aus, den es wiederum für die TLS-Clientauthentifizierung verwenden kann.

Diese Vorgehensweise hat einige Datenschutzvorteile. Da der EK das Gerät eindeutig identifiziert, lassen sich die Aktivitäten eines Geräts über mehrere Dienste hinweg verfolgen und korrelieren (was möglicherweise nicht erwünscht ist), vorausgesetzt ein EK-Zertifikat lässt sich zur Authentifizierung verwenden. Durch die Verwendung von Sekundärzertifikaten ist es möglich, für jeden Dienst, auf den das Gerät zugreift, ein separates Zertifikat ausstellen. Es lässt sich sogar ein separates Zertifikat für jeden einzelnen Zugriff auf denselben Dienst ausstellen. So bleibt die Privatsphäre gewahrt.

Dies verlagert natürlich den Aufwand der Identifizierung des TPM auf die Zertifizierungsstelle. Aber was passiert, wenn man den EK nicht für digitale Signaturen verwenden kann? Wie überprüft die Zertifizierungsstelle, ob das Gerät die private Komponente besitzt?

Mehr Cyber-Sicherheit für industrielle Kontrollsysteme

Bessere Sicherheit und Integrität Ihrer Betriebstechnologie

Das Protokoll

Das TPM-Protokoll ist konzeptionell einfach. Anstatt das Gerät vor der Ausstellung eines Zertifikats aufzufordern, den Besitz der privaten EK-Komponente nachzuweisen, stellt die Zertifizierungsstelle im Wesentlichen ein mit der öffentlichen EK-Komponente verschlüsseltes Zertifikat aus. Dieses kann nur von einem Gerät entschlüsselt werden, das die private EK-Komponente besitzt. Darüber hinaus kann das Gerät das Zertifikat nur entschlüsseln, wenn der zu zertifizierende neue Schlüssel auch in das TPM geladen ist.

Die Benutzer des Zertifikats können daher 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. Daher besteht ein geringeres Risiko für eine Kompromittierung.

Öffentliche und private Bereiche

Um das Protokoll zu verstehen, muss man zunächst wissen, dass jeder Schlüssel in einem TPM einen „öffentlichen“ und einen „privaten“ Bereich hat. Bei asymmetrischen Schlüsseln enthält der private Bereich den privaten Schlüssel selbst und kann entweder nie gelesen, aus dem TPM exportiert (im Fall eines EK) oder nur zur Speicherung in verschlüsselter Form exportiert werden. Eine Verschlüsselung, die dann nur wieder mit dem gleichen TPM entschlüsselt werden kann. (Obwohl der private Bereich eines Schlüssels niemals direkt gelesen werden kann, können TPM-Schlüssel erstellt werden, die auf ein anderes TPM migriert oder dupliziert werden können. Wie wir sehen werden, kann eine Zertifizierungsstelle sicherstellen, dass keine Zertifikate für Schlüssel ausgestellt werden, die auf diese Weise dupliziert werden können.) Der öffentliche Bereich muss dagegen nicht vertraulich sein. (Wenngleich das immer noch die Privatsphäre gefährden kann, wenn die Verknüpfung mit einem bestimmten Benutzer oder Gerät möglich ist.)

Normalerweise kann jeder, der physischen Zugang zum TPM hat, darauf zugreifen. Der öffentliche Bereich umfasst unter anderem: die öffentliche Komponente des Schlüssels, den zur Berechnung seines „Namens“ verwendeten Hash-Algorithmus und verschiedene Attribute, zum Beispiel ob er zum Signieren oder Entschlüsseln oder für beides verwendet werden kann.

Der „Name“ eines Schlüssels ist eigentlich überhaupt kein Name, sondern ein Hash seines gesamten öffentlichen Bereichs. Wenn sich also ein Teil eines öffentlichen Bereichs verändert, ändert sich auch sein „Name“. Warum das so wichtig ist, erläutere ich in Kürze.

Sicherheit in IIoT-Umgebungen

Identitäten für Maschinen und Steuerungen

Aufgaben einer Zertifizierungsstelle

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

• vom Endorsement Key – für den Namens-Hash-Algorithmus und den symmetrischen Verschlüsselungsalgorithmus

• vom zu zertifizierenden Schlüssel – für den öffentlichen Schlüssel zum Einfügen des ausgestellten Zertifikats, und um den „Namen“ zu berechnen

Wenn die Zertifizierungsstelle beschließt, ein Zertifikat auszustellen, gibt sie einen „Berechtigungsnachweis-Blob“ zurück. Dieser besteht aus zwei Teilen:

• einem HMAC zur Authentifizierung

• dem „Berechtigungsnachweis“ an sich, verschlüsselt mit dem symmetrischen Algorithmus, der im öffentlichen Bereich des EK angegeben ist

Im Idealfall reicht das aus. Es gibt allerdings zwei Probleme. Erstens ist der „Berechtigungsnachweis“ in seiner Größe auf die Größe des Digests beschränkt, der vom Namensalgorithmus des Endorsement Keys erzeugt wird. Bei SHA256 wären dies beispielsweise 32 Byte. Viel zu klein, um ein Zertifikat zu enthalten. Daher verschlüsselt die Zertifizierungsstelle das Zertifikat separat mit einem zufällig generierten symmetrischen Schlüssel und verwendet diesen Schlüssel als Berechtigungsnachweis.

Zweitens benötigen sowohl der HMAC als auch der verschlüsselte Berechtigungsnachweis einen geheimen Schlüssel zum erneuten Berechnen/Entschlüsseln. Das TPM hat keinen von beiden. Die Lösung besteht darin, beide Schlüssel aus einer Standard-Schlüsselableitungsfunktion (KDF) zu berechnen, die verschiedene Inputs hat. Alle Inputs sind öffentlich und stehen dem TPM bereits zur Verfügung. Mit Ausnahme einer Zufallszahl, dem sogenannten Seed, der von der CA generiert wird. Um diesen sicher an das TPM zu übermitteln, verschlüsselt die Zertifizierungsstelle ihn mit der öffentlichen EK-Komponente. Das TPM kann den Seed entschlüsseln und mit dem Standard-KDF verwenden, um dieselben HMAC- und Entschlüsselungsschlüssel zu berechnen, die die Zertifizierungsstelle zum Erstellen des Blobs für den Berechtigungsnachweis verwendet hat.

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

• 1. einen zufälligen Seed, der mit der öffentlichen EK-Komponente verschlüsselt ist,

• 2. einen Berechtigungsnachweis-Blob, der einen HMAC und einen symmetrisch verschlüsselten Berechtigungsnachweis enthält sowie

• 3. ein Zertifikat, das mit diesem Berechtigungsnachweis symmetrisch verschlüsselt ist.

#experte

Smart City

Digitale Identitäten helfen das Potenzial von Smart Cities auszuschöpfen

Aufgaben des TPM

Sobald die Zertifizierungsstelle diese Informationen bekommen hat, entschlüsselt das TPM den Seed zunächst mithilfe der privaten EK-Komponente. Es verwendet dann diesen Seed zusammen mit der KDF, um denselben HMAC-Schlüssel und Schlüssel zur Entschlüsselung abzuleiten, mit dem die Zertifizierungsstelle den Berechtigungsnachweis-Blob erstellt hat. Mit diesen Schlüsseln wird der Berechtigungsnachweis selbst authentifiziert und entschlüsselt (oder "aktiviert"), und schließlich wird der Berechtigungsnachweis verwendet, um das Zertifikat zu entschlüsseln, abzurufen und verfügbar zu machen.

Ein KDF-Input ist der „Name“ des zu zertifizierenden Schlüssels, den das TPM direkt von einem aktuell geladenen Schlüssel erhält. Da die Zertifizierungsstelle diesen Namen auch zum Ableiten des Verschlüsselungsschlüssels verwendet hat, schlägt die Aktivierung des Berechtigungsnachweises fehl, wenn der öffentliche Bereich des Schlüssels im TPM nicht genau die Eigenschaften aufweist, von denen die Zertifizierungsstelle angenommen hat, dass sie vorhanden sind. Stellt das Gerät der Zertifizierungsstelle 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, den Berechtigungsnachweis für einen TPM-Schlüssel zu aktivieren, der tatsächlich so dupliziert werden kann, schlägt die Aktivierung fehl. Das Gerät kann das Zertifikat nicht entschlüsseln und abrufen. Die Aktivierung schlägt ebenfalls fehl, wenn das Gerät ein Zertifikat für einen Schlüssel anfordert, der nicht durch die TPM-Hardware geschützt ist.

Der EK ist in der TPM-Terminologie ein eingeschränkter Entschlüsselungsschlüssel und kann nur für bestimmte, vom TPM definierte Zwecke verwendet werden. Insbesondere kann ein Gerät die Überprüfungen des zu zertifizierenden Schlüssels nicht umgehen, indem er den Seed nur manuell mit dem EK entschlüsselt und damit die HMAC- und Berechtigungsnachweisschlüssel mit der Standard-KDF unabhängig berechnet. Das TPM behält die Integrität, 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 stellen Dienstanbieter eine starke, hardwarebasierte IoT-Geräteauthentifizierung sicher. Hersteller von IoT-Geräten verschaffen sich und ihren Produkten dank der TPM 2.0-Funktionen einen potenziellen Wettbewerbsvorteil. Vorausgesetzt, sie arbeiten mit einer verlässlichen Zertifizierungsstelle, die das Protokoll implementiert und sie verwenden TPM-fähige Geräte.

* Paul Griffiths arbeitet als Softwareentwickler bei Global Sign.

(ID:47054357)