Im Rahmen der Digitalisierung werden stetig mehr Komponenten miteinander vernetzt. Auf dem Netzwerk kommt intern ebenfalls das Internet-Protocol (IP) zum Einsatz. Durch dessen Nutzung ist es möglich, frei im Netzwerk zu kommunizieren und nicht auf eine bestimmte Reichweite beschränkt zu sein. Gleichzeitig steigt der Bedarf, die Datenübertragung abzusichern. Unter diesen Aspekt fällt unter anderem, dass sich die Gegenstelle sicher ermitteln lässt, bevor der Sender beispielsweise sensible Daten weiterleitet. Eine solche Identifikation muss auch über das Netzwerk, also digital durchführbar sein.
Aktuelle Übertragungsprotokolle – wie https oder OPC UA – unterstützen die sichere Identifikation des Kommunikationspartners mithilfe digitaler Zertifikate. In diesem Zusammenhang lassen sich unterschiedliche Anwendungen umsetzen. Zum einen können Zertifikate verwendet werden, die bereits bei der Herstellung des jeweiligen Geräts aufgebracht wurden, sogenannte Initial Device IDs. Auf der anderen Seite kann der Anwender die Zertifikate selbst vergeben. Diese werden als Local Device IDs bezeichnet. Eine Beschreibung der Zertifikate findet sich im internationalen Standard IEEE 802.1AR.
Erzeugung des privaten Schlüssels
Das elektronische Zertifikat wird typischerweise beim Aufbau der Kommunikationsverbindung vorgelegt. Technisch kommen mehrere Elemente zum Einsatz. Ein elektronischer Schlüssel besteht aus zwei Teilen. Der eine Teil ist privat und nur dem Eigentümer bekannt. Der zweite, öffentlich zugängliche Teil wird in das elektronische Zertifikat eingebettet. Wurde der private Teil des Schlüssels in einem sicheren Element – zum Beispiel einem Trusted Platform Module (TPM) – erzeugt und gespeichert, lässt er sich nicht stehlen oder kopieren. In sicheren Elementen wird außerdem dafür gesorgt, dass die Schlüsselgenerierung hochwertig realisiert ist. Aus diesem Vorgehen resultiert eine sehr große Vertrauenswürdigkeit des elektronischen Schlüssels.
Dokumentation des PKI-Prozesses
Der öffentliche Schlüssel wird in einem elektronischen Zertifikat abgelegt. In diesem Zertifikat sind dann weitere Attribute enthalten, beispielsweise der Herstellername und die Seriennummer des Produkts. Das Zertifikat wird anschließend vom Aussteller (Certification Authority, CA) unterschrieben und damit zum Echtheitsnachweis. Die Vertrauenswürdigkeit des Zertifikats ist vom Gerätehersteller sicherzustellen. Dieser hat seine elektronischen Schlüssel, mit denen er die Gerätezertifikate signiert, vor einer Offenlegung und Missbrauch zu schützen. Zu diesem Zweck werden die Schlüssel ebenfalls in sicheren Elementen (Hardware Security Module, HSM) erzeugt und gespeichert. Die Zugangskontrolle zu den HSM erfolgt derart, dass Gerätezertifikate lediglich von autorisierten Stellen in der Fertigung abrufbar sind. Natürlich müssen auch die Infrastruktur und Produktionsprozesse des Geräteherstellers so gestaltet sein, dass nur Originalgeräte ein solches Gerätezertifikat erhalten können, sodass die Anwender Vertrauen in den Echtheitsnachweis haben.
Aus dem Zusammenspiel der technischen und organisatorischen Elemente dieser Public Key Infrastructure (PKI) ergibt sich das Maß der Vertrauenswürdigkeit in die Geräteidentitäten. Der Standard RFC 3647 erläutert, wie sich die PKI-Prozesse nachvollziehbar in der Vorgabe (Certificate Policy, CP) und der Umsetzungsbeschreibung (Certification Practices Statement, CPS) dokumentieren lassen. Auf diese Weise wird die Vertrauenswürdigkeit der Geräteidentität bewertbar.
Security Level von 3 und mehr
Verschiedene Standards und Normen verlangen den sicheren Umgang mit Geräteidentitäten ausdrücklich, um einen sicheren Betrieb in der Automatisierungslösung zu ermöglichen. Neben der bereits genannten IEEE 802.1AR, die Zertifikate für Geräteidentitäten beschreibt, gibt zum Beispiel die IEC 62443 Security for industrial automation and control systems vor, dass auf sicheren Schlüsseln basierende Identitäten in sicheren Schlüsselspeichern zu verwenden sind, wenn ein Security Level von größer oder gleich 3 erreicht werden soll (Anforderung CR 1.9).
Anforderungen und Konzepte für die sichere Inbetriebnahme und den sicheren Betrieb werden an unterschiedlichen Stellen dargelegt, beispielsweise in den Security Extensions for Profinet oder für OPC UA im Teil Device Provisioning. Die Vorgehensweise folgt dabei stets dem gleichen Muster. Als Voraussetzung für die sichere Identifikation müssen die Komponenten über Herstellerzertifikate verfügen, anhand derer sich die Echtheit des gelieferten Geräts kontrollieren lässt. Danach wird der Komponente eine Identität im Betreibernetzwerk zugeordnet. Dieses Betreiberzertifikat kommt nun für die eigentliche Datenübertragung im Automatisierungssystem zum Einsatz. Das Herstellerzertifikat würde erst dann wieder benötigt, sofern die Komponente zum Beispiel weiterverkauft werden soll.
Prüfung des Gerätezertifikats
Die Realisierung sicherer Geräteidentitäten beginnt bei der Nutzung sicherer Schlüsselspeicher – wie beispielsweise den TPMs – in den relevanten Produkten. Während der Fertigung müssen die Schlüsselpaare sicher generiert werden. Anschließend wird ein Zertifikatsantrag (Certificate Signing Request) an die PKI gesendet, um ein Gerätezertifikat zu bekommen. Da dieser Vorgang lediglich an vorbestimmten Prüfplätzen erfolgen kann, erhalten nur berechtigte Geräte ein x.509-Zertifikat, das sich auf einen Vertrauensanker (Root-Zertifikat) der Device-PKI zurückführen lässt. Das Zertifikat wird jetzt im Gerät abgelegt und kann zur Echtheitsprüfung im Kontext der unterstützten Protokolle herangezogen werden. Der Komponentenhersteller stellt die Vertrauensanker (Root-Zertifikate) zur Verfügung, falls diese nicht schon in die Applikationen integriert sind. Zum Beispiel umfasst die Engineering-Software, mit der eine Steuerung (PLC) programmiert wird, die Vertrauensanker für die jeweiligen Steuerungen bereits, damit der Anwender keine weiteren Schritte unternehmen muss.
Die Prüfung des Gerätezertifikats setzt sich aus zwei Elementen zusammen. Im ersten Schritt muss die Zertifikatskette bis zum Vertrauensanker korrekt sein. Dahinter verbirgt sich, dass jedes Zertifikat ordnungsgemäß von der nächsthöheren Instanz bis hinauf zum Vertrauensanker – dem Root-Zertifikat – unterschrieben wurde. Der Vertrauensanker selbst muss vom Gerätehersteller bezogen worden und im passenden Zertifikatsspeicher hinterlegt sein. In der Regel führen Softwarebibliotheken die Analyse der digitalen Unterschriften durch. Danach ist noch zu kontrollieren, ob das Gerätezertifikat auch zur Komponente passt. Gemäß
IEEE 802.1AR sind zu diesem Zweck die folgenden Eigenschaften gespeichert:
- organizationName (O): Name des Herstellers
- commonName (CN): Gerätetyp
- serialNumber (SN): Seriennummer des Geräts
Darüber hinaus können zusätzliche Einträge deponiert sein. Im Kontext der Entwicklung des digitalen Typenschilds, bei dem über einen auf dem Gerät aufgebrachten QR-Code eine URI angegeben wird, lässt sich diese URI ebenfalls im Zertifikat ablegen.
Phoenix Contact GmbH & Co. KG, Blomberg
Halle 9, Stand 310
Autor: Lutz Jänicke
Corporate Product & Solution Security Officer, Phoenix Contact
