Sichere Maschinenidentitäten für Industrie 4.0
Den Ausweis bitte!
Veröffentlicht in Ausgabe 07/2024 - SCHWERPUNKT
Ähnlich wie bei der Identifikation und Authentifizierung von menschlichen Nutzern sorgen Maschinenidentitäten dafür, dass sich Geräte gegenseitig eindeutig kennen und einander vertrauen können. Um sichere Maschinenidentitäten abzubilden, finden meist X509-Zertifikate Anwendung. Eine mögliche Grundlage bietet beispielsweise die Industrienorm IEEE 802.1AR, die Secure Device Identities beschreibt.
Mit Normen für mehr Sicherheit
IEEE 802.1AR definiert einen Secure Device Identifier (DevID), der sich aus einem Schlüsselpaar mit Zertifikat und Zertifikatkette zusammensetzt. Das Zertifikat soll dabei zum Beispiel im Subject Informationen enthalten, die das Gerät eindeutig identifizieren können, etwa die Geräteseriennummer. Zusätzlich werden ein oder mehrere CA-Zertifikate auf dem Gerät gespeichert. Diese dienen als Vertrauensanker, damit das Gerät bei einer Kommunikation sein Gegenüber ebenfalls sicher erkennt.
Die Norm unterscheidet grundsätzlich zwischen zwei verschiedenen Device Identifiern: Der Initial Device Identifier (IDevID) gibt einem Gerät initial eine ID. Diese wird in der Regel vom Hersteller aufgebracht. Ein Gerät kann darüber hinaus mehrere Local Device Identifiers (LDevIDs) aufweisen. Diese bringt der Endnutzer auf. Sie dienen dazu, das Gerät im laufenden Betrieb zu identifizieren. Dies ermöglicht es, einen Eigentümerwechsel abzubilden, ohne dass der Initial Device Identifier zu ändern ist und auch ohne den Hersteller zu involvieren.
Ähnlich wie bei der Identifikation und Authentifizierung von menschlichen Nutzern sorgen Maschinenidentitäten dafür, dass sich Geräte gegenseitig eindeutig kennen und einander vertrauen können. Um sichere Maschinenidentitäten abzubilden, finden meist X509-Zertifikate Anwendung. Eine mögliche Grundlage bietet beispielsweise die Industrienorm IEEE 802.1AR, die Secure Device Identities beschreibt.
Mit Normen für mehr Sicherheit
IEEE 802.1AR definiert einen Secure Device Identifier (DevID), der sich aus einem Schlüsselpaar mit Zertifikat und Zertifikatkette zusammensetzt. Das Zertifikat soll dabei zum Beispiel im Subject Informationen enthalten, die das Gerät eindeutig identifizieren können, etwa die Geräteseriennummer. Zusätzlich werden ein oder mehrere CA-Zertifikate auf dem Gerät gespeichert. Diese dienen als Vertrauensanker, damit das Gerät bei einer Kommunikation sein Gegenüber ebenfalls sicher erkennt.
Die Norm unterscheidet grundsätzlich zwischen zwei verschiedenen Device Identifiern: Der Initial Device Identifier (IDevID) gibt einem Gerät initial eine ID. Diese wird in der Regel vom Hersteller aufgebracht. Ein Gerät kann darüber hinaus mehrere Local Device Identifiers (LDevIDs) aufweisen. Diese bringt der Endnutzer auf. Sie dienen dazu, das Gerät im laufenden Betrieb zu identifizieren. Dies ermöglicht es, einen Eigentümerwechsel abzubilden, ohne dass der Initial Device Identifier zu ändern ist und auch ohne den Hersteller zu involvieren.
Der Endkunde vertraut der CA des Herstellers und bestätigt die IDevID des Geräts. Anschließend spielt er seinen Local Device Identifier auf, der für seinen Anwendungsfall spezifisch ist. Für die Speicherung sieht die Norm ein DevID-Modul vor. Dabei handelt es sich typischerweise um eine Hardware, die die DevIDs speichert, verwaltet und kryptografische Funktionen bereitstellt. Bei besonders einfachen Geräten lässt sich dies bauartbedingt allerdings nicht immer hardwareseitig lösen.
Per Bootstrapping Identitäten zuweisen
Soweit die Rahmenbedingungen. Wie aber kommen die Maschinenidentitäten in Form der Device Identifiers nun auf die Geräte? Beim sogenannten Bootstrapping ist hier grundsätzlich zwischen dem Factory Bootstrap und dem User Bootstrap zu unterscheiden.
Von einen Factory Bootstrap ist dann die Rede, wenn bereits der Hersteller die Maschinenidentität im Produktionsprozess aufbringt. Je nach Gerätetyp stehen dabei verschiedene Möglichkeiten zur Verfügung. Bei Devices, die selbst über ausreichend Rechen- beziehungsweise Batterieleistung verfügen, kann dies eine Device-ID mit Zertifikat und Schlüssel sein. Bei anderen Geräten lässt sich die Maschinenidentität über ein "Shared Secret" realisieren. Dabei wird ein eindeutiger Wert in das Gerät programmiert und geteilt, wobei einer sicheren, geschützten Übermittlung besondere Bedeutung zukommt.
Dies ist beim Einsatz von Zertifikaten in der Praxis deutlich einfacher. Die Veröffentlichung des öffentlichen Schlüssels der Certificate Authority, der zum Prüfen der Geräteidentität benötigt wird, ist unproblematisch, denn der private Schlüssel des Zertifikats verbleibt sicher und ausschließlich auf dem jeweiligen Gerät. Standardprotokolle wie SCEP, EST, CMP oder ACME erleichtern das Ausrollen des Zertifikats. Im IoT-/OT-Umfeld sind diese aber oft nicht vorhanden und es ist nötig, eine alternative Lösung zu implementieren, zum Beispiel unter Zuhilfenahme einer REST-API.
Sicherheitskritisch ist der initiale Vertrauensanker (Trust Anchor). Denn beispielsweise ein industrieller Sensor, der eine initiale Identität von der Produktionsanlage erhält, hat zunächst keine Möglichkeit, zu verifizieren, ob diese Anlage tatsächlich vertrauenswürdig ist. Es gilt also, diesen Vorgang speziell abzusichern, bis ein entsprechender Trust Anchor auf dem Gerät vorhanden ist (etwa in Form eines CA-Zertifikats). Die TrustManagementAppliance von ECOS beispielsweise bietet mit PKI- und Key-Management hierzu unterschiedliche Standardschnittstellen sowie eine REST-API für individuelle Anpassungen.
Unterschiede gibt es auch beim Erzeugen der Schlüssel. Können diese bauartbedingt auf dem Gerät selbst erstellt werden, bieten sich Lösungen wie TPM-Chips (Trusted Platform Module) oder Smartcards für das sichere Erzeugen und Verwahren der Schlüssel an. Ist dies nicht der Fall, bedarf es in der Regel eines zentralen Zertifikatsmanagement-Systems.
Beim User Bootstrap erfolgt die Vergabe der sicheren Maschinenidentität nicht beim Hersteller, sondern beim tatsächlichen Anwender. Wichtige Voraussetzungen hierfür sind ein Trust Anchor – hierbei handelt es sich in der Regel um ein CA-Zertifikat – und zumeist ein Registrar, bei dem sich das jeweilige Gerät registrieren kann, um eine sichere Identifizierung zu ermöglichen.
Offline-Bootstrap per Medium
Je nach Vorgehensweise wird zwischen Medium Bootstrap (Offline) und Remote Bootstrap (Online) unterschieden. Ein Medium Bootstrap kann zum Einsatz kommen, wenn für das Gerät keine Internetverbindung zur Verfügung steht. Über ein Medium, beispielsweise einen USB-Stick, werden lokale Device Identifier auf das Gerät gespielt und dort verifiziert. Administratoren können einen Medium Bootstrap auch nutzen, um ein Gerät online zu schalten, also die nötigen Informationen zu Servern, Identifikationsmerkmalen und Vertrauensankern zur Verfügung zu stellen.
Noch einfacher ist die Vorgehensweise natürlich, wenn das Gerät bereits über eine Internetverbindung verfügt. Administratoren stehen hier unter anderem zwei Standards zur Verfügung, das Secure Zero Touch Provisioning (SZTP – RFC8572) sowie das Bootstrapping-Remote-Secure-Key-Infrastructure-Protokoll (BRSKI – RFC8995).
Bootstrapping Remote Secure Key Infrastructure
Das Protokoll "Bootstrapping Remote Secure Key Infrastructure" (BRSKI – RFC 8995) ist ein weiterer Standard für den Remote Bootstrap. Das Gerät (im dazugehörigen RFC als Pledge bezeichnet) hat eine initiale Device-ID und kontaktiert über einen Join-Proxy einen sogenannten Domain Registrar, um eine Netzwerkverbindung aufzubauen. Der Domain Registrar fragt bei der sogenannten Manufacturer Authorized Signing Authority (MASA) nach einem Voucher für das Gerät.
Der MASA-Server wird entweder vom Hersteller betrieben oder ist von ihm autorisiert und kennt die Geräte des Herstellers und deren IDevIDs. Daher kann er den Voucher für das anfragende Gerät ausstellen, der über den Domain Registrar und den Join-Proxy wieder an das Gerät zurückübermittelt wird. In dem Voucher enthalten sind Authentifizierungsdaten, mit denen sich eine sichere Verbindung aufbauen lässt, um Daten, Zertifikate und Schlüssel auszutauschen. Auch bei dieser Vorgehensweise wird jeder einzelne Schritt mithilfe von Vertrauensankern, die wie bei SZTP vorhanden sein müssen, authentisiert.
Provisioning per Zero Touch
Beim Secure Zero Touch Provisioning (SZTP – RFC8572) erhält das Gerät über die Netzwerkverbindung Informationen zu einem Bootstrap-Server per DHCP oder DNS. Bootstrap-Server und Gerät authentifizieren sich gegenseitig mit den vorhandenen Vertrauensankern, das heißt den CA-Zertifikaten. Dafür benötigt der Bootstrap-Server das CA-Zertifikat, das die Device-ID signiert hat, und das Gerät benötigt ein CA-Zertifikat, um den Bootstrap-Server zu verifizieren.
Nach der Authentifizierung erhält das Gerät die Adresse eines Deployment-Servers, der weitere Konfigurationen für das Gerät liefert, zum Beispiel Firmwareupdates, zusätzliche Zertifikate, initiale Konfiguration oder lokale Device-IDs. Nicht zu verschweigen ist ein Nachteil des SZTP-Verfahrens: Der Endkunde muss in diesem Fall die Server-Infrastruktur betreiben und vom Hersteller entsprechende Zertifikate zur Verfügung gestellt bekommen.
Typische Herausforderungen bei Maschinenidentitäten
Im Lebenszyklus von Geräten gibt es einige typische Herausforderungen, die den Umgang mit Maschinenidentitäten erschweren und auf die IT-Administratoren besonders achten sollten. So kann beispielsweise der Eigentümer des Geräts wechseln. Im Falle eines Remote Bootstraps mit den vorgestellten Standardprotokollen lässt sich ein solcher Wechsel relativ leicht durch das Zurücksetzen in die Werkseinstellungen umsetzen. Ist ein Gerät jedoch vom Hersteller durch einen Factory Bootstrap auf einen spezifischen Kunden zugeschnitten, ist ein Eigentümerwechsel nicht einfach zu bewerkstelligen.
Das Verlängern von Zertifikaten ist ein weiteres wichtiges Thema. Bei der Vergabe initialer Device-IDs sollten Administratoren berücksichtigen, dass Geräte unter Umständen sehr lange im Einsatz sein können. Zertifikate für die IDevID sollten daher eine lange Gültigkeit haben, die die prognostizierte Lebensdauer des Geräts überschreitet. Andernfalls lässt sich das Gerät nach Ablauf des Zertifikats nicht mehr identifizieren.
Zu beachten ist außerdem, dass Algorithmen, die heute noch sicher sind, durch die fortschreitende Steigerung von Rechenleistung, neue wissenschaftliche Erkenntnisse oder auch neue Technologien (Stichwort Quantencomputer) in Zukunft eventuell nicht mehr sicher sein werden. Um dem zu begegnen, ist Kryptoagilität entscheidend. Kryptoagilität bedeutet, dass man Kryptographie von Anfang an so konzipiert, dass sie sich an neue Entwicklungen anpassen lässt, etwa durch neue bessere Schlüssel oder durch Softwareupdates zur Unterstützung neuer Algorithmen. Deshalb sollten die LDevIDs, die für den täglichen Betrieb Verwendung finden, keine zu langen Gültigkeiten haben und regelmäßig erneuert werden.
Fazit
Sichere Maschinenidentitäten bilden eine grundlegende Voraussetzung für den Aufbau und Betrieb sicherer industrieller wie auch IT-Infrastrukturen. Administratoren stehen verschiedene Bootstrapping-Methoden zur Verfügung, mit denen sich eindeutige Device-IDs vergeben lassen. Sinnvoll ist, dabei von Beginn an das Lifecycle-Management von Zertifikaten und Schlüsseln in den Fokus zu nehmen. Neben dem Erstellen, Speichern und Verteilen umfasst dies auch das Verlängern und Zurückziehen. Wichtig ist dabei, alle Schritte rund um das Management der erforderlichen Zertifikate und Schlüssel zu automatisieren, um einen zuverlässigen Betrieb sicherzustellen.
(ln)
Gerald Richter ist Geschäftsführer bei ECOS Technology.