Schlüsselwörter:

1 Einleitung

Industrielle Automatisierungssysteme, die in der Fertigungs- oder Prozessindustrie eingesetzt werden, sollten modularen Anstzen folgen. Dies ermglicht den Aufbau flexibel gestalteter Produktionssysteme, die schnell und mit mglichst geringem Aufwand an neue Produkt- bzw. Produktionsanforderungen angepasst werden knnen oder Aufgaben in einem Verbundsystem erfllen. Der vermehrte Einsatz von Cyber-Physical Systems (CPS), die neben dem Zugang zum zu steuernden Prozess auch mit einem fortschrittlichen Kommunikationssystem ausgestattet sind, ist einer der wichtigen Faktoren, die dies ermglichen. Solche CPS ermglichen auch die Verteilung der Steuerungsaufgaben im Netzwerk sowie die Verlagerung in die Cloud oder in Egde-Cloud-Komponenten [1].

Sowohl fr Machine to Machine (M2M) als auch fr Machine to the Internet/zu Cloud-Verbindungen wird in erster Linie das etablierte Internet-Protokoll (IP) verwendet. Bei der Auswahl der zu verwendenden Protokolle und bertragungsmedien sind jedoch die konkreten Anforderungen an die Informationsbertragung, wie z. B. Echtzeit-Eigenschaften, zu bercksichtigen.

Die zunehmende Vernetzung von Steuerungskomponenten mit dem Internet stellt die Automatisierungstechnik vor neue Herausforderungen. Whrend frher speicherprogrammierbare Steuerungen (SPS) nur ber spezifische Feldbusse mit Peripheriekomponenten wie Ein-/Ausgabebaugruppen, Sensoren und Aktoren verbunden waren, werden SPS zunehmend zu CPS und interagieren mit anderen CPS oder Cloud-Diensten ber ihr bisher lokales und isoliertes Netz hinaus. Diese neuen Vernetzungsmglichkeiten erhhen auch das Risiko von Cyber-Angriffen, da die traditionelle physische Trennung aufgehoben wird.

Im Prinzip sind einige der aufkommenden Bedrohungen bekannt, da sie im Allgemeinen denjenigen hneln, die bereits in der traditionellen Computersicherheit bercksichtigt wurden. Die Folgen erfolgreicher Angriffe betreffen jedoch den physischen Raum, der durchaus Teil der kritischen Infrastruktur [2] sein kann.

Die Anwendung von Sicherheitsbewertungen, wie z. B. die STRIDE-Analyse [3, 4], und die Implementierung von Sicherheitslsungen auf dem neuesten Stand der Technik sind gute Gegenmanahmen, doch mssen praktische Erwgungen bercksichtigt werden. In diesem Beitrag konzentrieren wir uns auf die Beschreibung von Konzepten und ersten Implementierungen von sicheren Kommunikationswegen (a) in der industriellen Maschine-zu-Maschine und (b) zwischen Mensch und Maschine ber Fernsteuerung mittels drahtloser Kommunikation.

Wir planen, unseren Ansatz in einem realen Demonstrator zu testen und zu bewerten, der aus zwei zusammenarbeitenden Kranen, einem fahrerlosen Transportsystem (FTS), einem Gabelstapler und Menschen besteht, die mit den Maschinen interagieren.

Es gibt auch tragbare Modelle dieses Demonstrators, einschlielich der Maschinen mit viel kleineren Abmessungen. Diese Arbeitsmodelle bieten eine sichere Umgebung fr die Entwicklung und Identifizierung von Herausforderungen, die auftreten knnen.

Der Rest dieses Papiers ist wie folgt gegliedert: Der folgende Abschnitt beschreibt die in diesem Papier betrachteten Anwendungsflle und die daraus resultierende Architektur des geplanten flexiblen Produktionssystems. Abschn. 3 stellt kurz Technologien vor, die in aktuellen Produktionssystemen zu finden sind. Abschn. 4 umreit die Sicherheitsanalyse, die durchgefhrt wurde, bevor Abschn. 5 die Lsungen zur Sicherung der industriellen M2M- und IoT-Kommunikation vorstellt. Der letzte Abschnitt fasst die Ergebnisse der vorgestellten Anstze zusammen und gibt einen Ausblick auf weitere Anwendungsbereiche.

2 Betrachtete Use Cases und Architektur

2.1 Use Cases

Die Zusammenarbeit zwischen Maschinen sowie zwischen Mensch und Maschine in Produktionssystemen ist ein Schlsselfaktor zur Effizienzsteigerung und eine der technischen Grundlagen fr Smart Factories. Bei Materialhandhabungssystemen (MHS) ist eine solche Interaktion auf Anforderung herzustellen, (a) wenn eine Maschine den Transport von Gtern anfordert oder (b) wenn ein menschlicher Bediener einen solchen Prozess manuell startet. Temporre Zusammenarbeit zwischen Maschinen, wie z. B. Kranen, verbessert die Mglichkeiten des Materialflusses. Krane knnen z. B. im Tandem arbeiten, um grere Gter zu transportieren, oder sie knnen bei Bedarf an angeforderte Positionen fahren. Die erhhte drahtlose Konnektivitt zwischen den Bedienern, die Existenz verschiedener Maschinensteuerungen und die Datenwolke der Fabrik erfordern besondere Aufmerksamkeit fr Aspekte der Kommunikationssicherheit, siehe Abb. 1.

Abb. 1
figure 1

Use Case M2M- und Mensch-Machine-Interaktion

Full size image

Die Einfhrung erhhter Flexibilitt durch die Integration mobiler Maschinen und mobiler Benutzerschnittstellen in den industriellen Datenaustausch macht den Einsatz drahtloser Kommunikationstechnologien erforderlich. Basierend auf dynamisch erstellten Kommunikationsbeziehungen mssen die Automatisierungsfunktionen in den verschiedenen Steuerungen auch Funktionen in anderen Steuerungen nutzen knnen, ohne die Komplexitt des Engineerings und der daraus resultierenden Steuerungsprogramme wesentlich zu erhhen.

2.2 Architektur

Wie in Abb. 2 dargestellt, ist die Systemarchitektur hierarchisch aufgebaut: auf der Low-Level-Ebene findet die industrielle Kommunikation zwischen dem Maschinen (z. B. Krane und Gabelstaplern) sowie Sensoren und anderen Aktoren statt; auf der High-Level-Ebene sind Enterprise-Lsungen, wie Datenspeichersysteme und Cloud-Systeme, vorhanden. Der Bediener befindet sich praktisch im Zentrum des Systems und kann verschiedene Gerte steuern und ber eine HMI auch spezifische Aufgaben auslsen.

Abb. 2
figure 2

Generelle Architektur

Full size image

Verzgerungen und Informationsverluste whrend der Kommunikation knnen die Systemleistung ernsthaft beeintrchtigen und die Sicherheit gefhrden. Aus diesem Grund werden in der industriellen M2M-Kommunikation Lsungen und Protokolle bevorzugt, die fr verbindungsorientierte Echtzeitkommunikation geeignet sind. Kritische Steuerungsaufgaben und unkritische Aufgaben werden auf dem Gert getrennt. Sie sind jedoch ber das leichtgewichtige Protokoll MQTT [5] miteinander lose gekoppelt. Die Kommunikation fr industrielle Steuerungsaufgaben verwendet ein effizientes Binrprotokoll, das auf verschiedene industrielle Feldbussysteme, z. B. Controller Area Network (CAN), abgebildet werden kann. In dem beschriebenen Szenario wird ein IP-basiertes Protokoll verwendet. Fr die unkritische Industrial Internet of Things (IIoT)-Kommunikation wurde OPC UA [6] als Kandidatenprotokoll ausgewhlt. Insbesondere die Anbindung zwischen externen Systemen wie der 3D-Visualisierung und dem Datenmanagementsystem wird ebenfalls ber OPC UA realisiert.

Um die Legacy-Gerte mit intelligenten Automatisierungsfunktionen auszustatten, wird im OPTIMUM-Projekt [7] das als CPS geltende OPTIMUM-Gert eingefhrt und entwickelt. Abb. 3 stellt den internen Aufbau des OPTIMUM-Gerts dar. Die unterste Schicht eines OPTIMUM-Gerts bietet die E/A-Fhigkeiten mit einem lteren HW-Gert sowie mit neu hinzugefgten (z. B. einer Lokalisierungseinheit) und mglichen lteren Sensoren. Die Hardwareschicht stellt die Rechenfhigkeiten wie Prozessoren, Speicher, Speicher, Kommunikationsschnittstellen, Secure Element usw. zur Verfgung. Ein Secure Element wird verwendet, um die fr die sichere Kommunikation verwendeten Geheimnisse (z. B. Zertifikate) sicher zu speichern. In der Softwareschicht laufen die OPTIMUM-Softwarekomponenten, z. B. Distributed Control Platform (DCP), IIoT, Context Awareness Service (CAS), auf einem Echtzeitbetriebssystem. Die Softwarekomponenten sind containerisiert und kommunizieren ber MQTT miteinander. DCP erleichtert die Maschinensteuerung und Sensorkommunikation. Die Steuerungsanwendung im DCP hat eine objektorientierte Struktur, wobei jedes Objekt (Control Application Object - CAO in Abb. 3) ber definierte Zugangspunkte Dienste anderer Objekte konsumieren oder selbst Dienste anbieten kann. Das resultierende Netzwerk von CAOs kann lokal auf einem Gert organisiert oder verteilt sein. In letzterem Fall kommuniziert DCP mit anderen DCP-Instanzen, die auf anderen Industriegerten laufen, und stellt die fr die verteilte Steuerung erforderliche industrielle M2M-Kommunikation bereit. (siehe Abb. 2).

Abb. 3
figure 3

Interner Aufbau des OPTIMUM-Gerts

Full size image

IoT erleichtert die Nicht-Echtzeit-Kommunikation mit HMIs, anderen industriellen Gerten und fr die vertikale Integration unter Verwendung von OPC UA. CAS bernimmt kontextbezogene Aktivitten, wie z. B. Kontextsensitivitt und Speicherung. Die Architektur erlaubt das Hinzufgen weiterer containerisierter Komponenten, um die Fhigkeiten der industriellen Gerte zu erweitern. Weitere Einzelheiten zum vorgeschlagenen System und zum Design des OPTIMUM-Gerts werden in [8] vorgestellt.

3 Zugehrige Arbeiten

In industriellen Automatisierungssystemen werden sehr hufig speicherprogrammierbare Steuerungen in der Fertigung oder Steuerungssysteme in der Prozessindustrie eingesetzt. Die zentrale Ausfhrung des Steuerungsprogramms auf diesen Komponenten ist beiden Anstzen gemeinsam. Eine weitere Gemeinsamkeit ist die Verwendung von Funktionsblcken (FB) als Strukturierungsmittel fr die Steuerungsprogramme. FB knnen als Objekte mit einer Datenschnittstelle mit ffentlichen Variablen betrachtet werden. Das Objekt hat nur eine implementierte Methode, die automatisch vom Laufzeitsystem aufgerufen wird. In der Prozessautomatisierung beschreibt IEC 61804-2 das FB-Konzept, fr die Fertigung definiert IEC 61131-3 Programmiersprachen, die die FB untersttzen. Letztere untersttzt auch moderne Konzepte wie abstrakte Schnittstellen oder die Definition von mehreren Methoden. Es gibt jedoch keinen Ansatz, die FB auf andere Controller aufzurufen oder das Steuerungsprogramm allgemein zu verteilen. IEC 61499 bietet hierfr einen Ansatz, erfordert aber aufgrund des getrennten Steuerungs- und Datenflusses einen enormen Engineering- und Laufzeitaufwand.

Effizienter ist es, Steuerung und Datenfluss zu kombinieren, wie von der Service Oriented Architecture vorgeschlagen. Ein Konzept einer solchen verteilten Steuerungsplattform wird in [8] und [9] beschrieben. Voraussetzungen dafr sind effiziente Kommunikationssysteme, die Mglichkeit der Nutzung mehrerer Kommunikationsmedien und ein entsprechender Engineeringaufwand fr den Aufbau der Kommunikation.

Die etablierten industriellen Kommunikationssysteme untersttzen in erster Linie den oben beschriebenen Ansatz der zentralen Steuerung. Dafr arbeiten sie sehr effizient. Zum Zeitpunkt der Konzeption dieser Systeme stand jedoch die Forderung nach Datensicherheit noch nicht im Vordergrund. Auf der anderen Seite zeigen Forschungsarbeiten wie [10] Mglichkeiten auf, auch die industrielle Kommunikation sicher zu machen.

Dzung et al. [11] weist auf allgemeine Herausforderungen und Anforderungen in industriellen Kommunikationssystemen hin und wie diese mit kryptographischen Methoden erfllt werden knnen. Tuna et al. [12] analysiert Sicherheitsbedrohungen und entsprechende Lsungen in M2M-Netzwerken. Er zeigt auf, dass die Identifikation und Authentifizierung von Gerten der allererste Schritt in der Sicherheitsarchitektur ist und fr ein sicheres M2M-Netzwerk unerlsslich ist. Verschiedene existierende Lsungen, die auf M2M-Sicherheit abzielen, werden auch in [13] diskutiert. Der Autor erwhnt, dass es derzeit keine Lsung gibt, die alle Funktionen in einem skalierbaren Netzwerk aus heterogenen Gerten erfllt.

4 STRIDE Analyse

4.1 Analyse

Die STRIDE-Analyse wird verwendet, um Security-Schwachstellen in einem industriellen Fertigungs- und Automatisierungssystem zu identifizieren. STRIDE steht fr:

S: Spoofing  

I: Information Disclosure

T: Tampering  

D: Denial of Service

R: Repudiation 

E: Elevation of Privilege

Diese Methode nimmt einen definierten Anwendungsfall als Input, bewertet die Verbindungen und Kommunikationswege im System, identifiziert Gter/Gegenstnde und Bedrohungen und leitet Sicherheitsanforderungen als Output ab, um diese Bedrohungen abzuschwchen. Aufgrund der groen Anzahl und Vielfalt der Anwendungsflle von verschiedenen Partnern wurden zwei von ihnen als Vertreter ausgewhlt. In diesem Papier wird jedoch nur ein Anwendungsfall errtert.

Im Allgemeinen wird der Anwendungsfall als ein grundlegendes Architekturdiagramm entworfen, das alle Akteure des Systems und die Beziehungen zwischen ihnen enthlt. In Abb. 4 ist einer unserer spezifischen Anwendungsflle als grundlegendes Architekturdiagramm dargestellt.

Abb. 4
figure 4

Use Case MUC4: OPTIMUM Demonstrator fr Materialhandhabung

Full size image

Es werden Annahmen ber das System und seine Umgebung getroffen, um ein klar definiertes Szenario fr die Untersuchung zu haben. Einige Annahmen sind in Tab. 1 aufgefhrt.

Tab. 1 Annahmen fr den Anwendungsfall
Full size table

Ausgehend von diesem Punkt werden die zu sichernden Objekte im System identifiziert. In diesem speziellen Anwendungsfall verwendet die horizontale M2M-Kommunikation, die von DCP abgewickelt wird, die 5G-Schnittstelle, whrend die vertikale Kommunikation, die von IIoT abgewickelt wird, ber eine WiFi-Schnittstelle erfolgt (siehe auch Abb. 2 und 3). Das Ergebnis des Identifizierungsprozesses fr diesen Anwendungsfall ist die folgende Liste zu schtzender Dinge:

  • Daten zur IIoT-Schnittstelle ber WiFi

  • Daten zur M2M-Schnittstelle ber 5G

  • Positionsdaten auf UWB-Schnittstelle

  • Befehle von der HMI zur Maschine und umgekehrt

Das Architekturdiagramm des Anwendungsfalles wird dann in ein Bedrohungsmodell umgewandelt (Abb. 5), um ein klareres Bild der Rollen im System zu erhalten. Dieser Anwendungsfall enthlt die folgenden STRIDE-Elemente:

  • DFx – Data flow

  • Ex – External Entity

  • Px – Process

Abb. 5
figure 5

Vereinfachtes OPTIMUM-Bedrohungsmodell-Diagramm

Full size image

Es wird eine Zuordnung vorgenommen, welche Bedrohungen auf welches STRIDE-Element zutreffen, da nicht alle Bedrohungen auf alle Elemente im System angewendet werden knnen (Tab. 2).

Tab. 2 Beispiel fr die Identifizierung von Bedrohungen fr den Datenfluss DF2_DEM
Full size table

Diese Abbildung wird dann auf das Bedrohungsmodelldiagramm angewendet, so dass das Ergebnis die Identifizierung von Bedrohungen pro Systemelement ist. In Abb. 5 wird dies durch die gelben Ellipse dargestellt. Die roten Buchstaben markieren die Bedrohungen, die auf das zugehrige STRIDE-Element zutreffen.

Jede identifizierte Bedrohung wird mit der DREAD-Methode quantifiziert. Dabei wird jede Bedrohung mit den folgenden fnf Attributen bewertet:

D: Damage Potential 

A: Affected users

R: Reproducibility  

D: Discoverability

E: Exploitability  

 

Die Evaluierung wird von einer Gruppe von Experten sowohl fr Sicherheit als auch fr industrielle Systeme vorgenommen, um die beste Sicht aus beiden Perspektiven zu erhalten. Das Ergebnis der Bewertung ist eine Zahl zwischen 1 und 3. Die Zahlen des Ratings wurden in Risikostufen umgewandelt, die wie folgt definiert sind:

  • ≤ 1, 4: Geringes Risiko

  • > 1, 4 ≤ 2, 2: Hohes Risiko

  • > 2, 2: Kritisch

Als Beispiel zeigt Tab. 3 die Bewertung des Datenflusses DF2DEM mit den in Abb. 5 hervorgehobenen Bedrohungen.

Tab. 3 DREAD Bewertungsbeispiel fr Datenfluss DF2_DEM
Full size table

Tab. 4 enthlt die Beschreibung der DREAD-Einstufung fr die Bedrohungsmanipulation.

Tab. 4 Beschreibung der DREAD-Bewertung fr DF2_DEM-T
Full size table

Auf der Grundlage des Risikoniveaus jeder Bedrohung pro STRIDE-Element wird eine Entscheidung darber getroffen, wie mit den identifizierten Sicherheitslcken umgegangen werden soll. Das Ergebnis dieses Prozesses sind die Sicherheitsanforderungen, die sich aus den sich aus den Entscheidungen ergebenden Handlungen ableiten lassen. Diese Anforderungen mssen auf das System angewendet werden, um die identifizierten Risiken in der beschlossenen Weise zu behandeln. Sie sind im Abschn. 4.2 beschrieben.

4.2 Sicherheitsanforderungen

Die Sicherheitsanforderungen als Gesamtergebnis der STRIDE-Analyse mssen in der Lage sein, die Risiken der identifizierten Sicherheitslcken im System zu beseitigen oder zu mindern. Fr den Anwendungsfall MUC4 bedeutet dies

  • Systemzugriff nur auf autorisierte Benutzer und Gerte beschrnken

  • Zugang der Benutzer zu Gerten und Systemfunktionen einschrnken

  • Schutz der innerhalb des Systemnetzwerks bertragenen Daten gegen Manipulation und Aussphen

  • Positionsdaten vor Manipulation schtzen

Daraus ergeben sich folgende Sicherheitsanforderungen an das OPTIMUM-System, nicht nur im Hinblick auf den Anwendungsfall MUC4, sondern auch fr eine Vielzahl anderer Anwendungsflle.

  • Die Datenkommunikation MUSS vor unberechtigtem Zugriff geschtzt werden.

  • Die Integritt der Lokalisierungsdaten MUSS geschtzt werden.

  • Mitarbeiter MSSEN authentifiziert werden.

  • Drahtlose HMI-Gerte fr die Fernsteuerung von Maschinen MSSEN authentifiziert werden.

  • Gerte zur Lokalisierung und Positionierung MSSEN authentifiziert werden.

Gegenwrtig befinden sich die in Abschn. 5 beschriebenen Sicherheitsmanahmen zur Erfllung der oben genannten Anforderungen in der Implementierungsphase, so dass es nicht mglich ist, ihre Wirksamkeit zu validieren. Die STRIDE-Analyse wird nach der Implementierung aller Sicherheitsmanahmen wiederholt, um zu berprfen, ob alle Sicherheitsziele erreicht wurden.

4.3 Klassifikation von Verbindungen

Ein weiteres Ergebnis der STRIDE-Analyse ist die Klassifizierung der Kommunikationskanle. Die folgenden Kategorien wurden anhand des in Abb. 4 dargestellten Anwendungsfalles identifiziert:

  • Mensch zu Maschine

  • Machine-to-Machine (M2M)

Ursprnglich wurde die industrielle M2M-Kommunikation weiter unterteilt in den Datenaustausch mit eher stationren Gerten, z. B. Produktionsmaschinen, und frei beweglichen Maschinen wie Flurfrderfahrzeugen und Kranen. Die STRIDE-Analyse hat jedoch gezeigt, dass diese Verbindungen unter Sicherheitsaspekten gleich behandelt werden knnen.

5 Sicherheitskonzept

Nach der Identifizierung der in Abschn. 4.2 aufgefhrten Sicherheitsanforderungen mit Hilfe der STRIDE-Analyse ist der nchste Schritt die Konzeption und Entwicklung geeigneter Manahmen. In diesem Abschnitt geben wir einen berblick ber die Schritte, die erforderlich sind, um unsere Architektur gegen die mglichen Bedrohungen abzusichern.

Die zur Erreichung dieses Ziels eingesetzten Instrumente und Mechanismen sind folgende:

  • Zertifikatsbasierte Authentifizierung und Autorisierung

  • Verschlsselung, Integrittsschutz

  • Zertifikat-Widerrufsliste

Ein blicher Ansatz zur Aussperrung nicht autorisierter Teilnehmer ist die Sicherung der Kommunikationsflsse. Dazu gehren Authentisierung, Verschlsselung und Integrittsschutz. Authentisierung ist erforderlich, um sicherzustellen, dass der aktuelle Kommunikationspartner vertrauenswrdig und kein bswilliger Angreifer ist. Die Verschlsselung verhindert, dass ein mglicher Angreifer die Nachrichten lesen kann, whrend die Integritt sicherstellt, dass niemand die Daten auf dem Weg vom Sender zum Empfnger verndert.

Die Authentifizierung allein bietet jedoch nicht die erforderliche Granularitt, um feinkrnige Berechtigungen zu ermglichen, die ber die binre Entscheidung hinausgehen, z. B. gewhrt/verweigert. Die Anwendung von Autorisierungsmechanismen wie ein Rechteverwaltungssystem kann verwendet werden, um diesen Detaillierungsgrad zu erreichen.

Die in Abschn. 4.2 genannten Anforderungen lassen sich hauptschlich in zwei Gruppen einteilen:

  1. (a)

    Kommunikationsdaten sollten vor unberechtigtem Zugriff oder Manipulation geschtzt werden.

  2. (b)

    Die Entitten sollten sich gegenseitig authentifizieren, bevor sie einen Kommunikationskanal einrichten.

Es gibt bereits verschiedene Arten von Mechanismen, die zur Erfllung der Anforderungsgruppe 5 eingesetzt werden knnen. Beispielsweise knnen das Protokoll Transport Layer Security (TLS) sowie das industrielle IoT-Protokoll OPC UA Datenverschlsselungs- und Entity-Authentifizierungsfunktionen bereitstellen [14, 15]. Zur Durchfhrung solcher Mechanismen ist jedoch ein Berechtigungsnachweis oder ein Schlssel und inhrent eine Teilnehmerauthentifizierung erforderlich. Das erste Problem, das es zu lsen gilt, ist also das Schlsselmanagement, das die Erzeugung, Speicherung und den Widerruf von Schlsseln umfasst. Darber hinaus muss ein geeigneter Ansatz den Herausforderungen gerecht werden, die das in Abschn. 2 beschriebene industrielle Szenario mit sich bringt.

Im Folgenden werden weithin bekannte und bereits bewhrte Anstze verwendet und kombiniert, um die Anforderungsgruppe 5 zu erfllen. Da diese Anstze insbesondere im wissenschaftlichen und industriellen Bereich bereits gut dokumentiert sind, ist es unser Ziel, hier einen praktischen Einblick in die Umsetzung in einer realen Fabrik unter den Bedingungen zu geben, die unser CPS-Anwendungsfall impliziert.

Da ein OPTIMUM-Gert in der Lage ist, ein Betriebssystem auszufhren und mit einem sicheren Element ausgestattet ist, das sensible Daten, z. B. Zertifikate, Schlssel und IDs, sicher speichern und vor unbefugtem Zugriff schtzen kann, wird ein auf einer Public Key Infrastructure (PKI) [16] basierender Ansatz vorgeschlagen.

In PKI-Systemen verfgt jeder Teilnehmer ber ein Schlsselpaar, das aus einem privaten und einem ffentlichen Schlssel besteht, sowie ber ein Root-Zertifikat (X.509), das von einer Zertifizierungsstelle (CA) ausgestellt wurde und die Teilnehmer-ID und ihren ffentlichen Schlssel enthlt. Die Gerte knnen sich gegenseitig authentifizieren, indem sie die ID und die Signatur auf dem Zertifikat berprfen. Die Signatur sollte von einer rechtmigen CA signiert werden, deren Signatur von einer Zwischen-CA oder Root-CA unterzeichnet wird.

In einem nchsten Schritt kann durch Ausfhren eines Schlsselaustausch-Algorithmus ein Sitzungsschlssel abgeleitet werden. Dieser Sitzungsschlssel kann verwendet werden, um einen durch Verschlsselung und Integrittsschutz gesicherten Datenaustausch zwischen zwei Teilnehmern im Netzwerk herzustellen, z. B. mit Hilfe von TLS.

Ein allgemeiner berblick ber PKI-Strukturen im industriellen Bereich ist in Abb. 6 dargestellt. Eine Root-CA und ein Management-Server befinden sich innerhalb des IT-Netzwerks des Unternehmens, das durch modernste Sicherheitsmechanismen, z. B. eine Firewall, geschtzt ist. In jeder Produktionssttte oder Anlage gibt es eine lokale CA, deren Zertifikat von einer Root-CA ausgestellt wird, die Zertifikate fr Endgerte bereitstellt.

Abb. 6
figure 6

Vertrauenskette

Full size image

5.1 Gerte-Authentifizierung

Die Bereitstellung von Gerte-Berechtigungsnachweisen lsst sich in die folgenden Teile unterteilen:

  1. 1.

    Es wird davon ausgegangen, dass bei der Herstellung eines Gertes eine eindeutige Hardware-Kennung DevID, im besten Fall ein Zertifikat, vom Hersteller vergeben wird.

  2. 2.

    Wenn ein Gert einem Netzwerk neu beitritt, prsentiert es seine DevID zusammen mit einer Certificate Sign Request (CSR) an die lokale CA, die die DevID ber einen Out-of-Band-Kanal verifizieren sollte, z. B. durch manuelle berprfung von DevID ber eine Web-Schnittstelle. Anschlieend stellt die lokale CA ein Zertifikat CertDev aus, das an DevID gebunden ist. Die Zertifikate CertDev, CertLocalCA und CertRootCA werden im Secure Element des Gerts gespeichert, um unbefugte Manipulationen zu verhindern. Die Einzelheiten sind in Abb. 7 dargestellt.

    Abb. 7
    figure 7

    Gertelokales Zertifikat von lokaler CA anfordern

    Full size image
  3. 3.

    Wenn zwei Gerte eine M2M-Kommunikation aufbauen mssen, authentifizieren sie sich gegenseitig, indem sie CertDevice von ihrem Kommunikationspartner anfordern und die enthaltene Signatur prfen. Wenn die Gertezertifikate von verschiedenen lokalen CAs ausgestellt werden, z. B. kann sich ein AGV zwischen den Werksttten bewegen, mssen sie zustzlich CertLocalCA austauschen, um die Vertrauenskette zu vervollstndigen. Wenn die Prfungen auf Vertrauenskette und Signatur bestanden sind, knnen die Gerte damit beginnen, einen sicheren Kanal aufzubauen, z. B. ber TLS, wie in Abb. 8 dargestellt.

    Abb. 8
    figure 8

    Gegenseitige Authentifizierung zwischen Gerten

    Full size image

5.2 Bedienerauthentifizierung

Gerte wie Krane, Gabelstapler und andere Flurfrderfahrzeuge bleiben immer auf dem Gelnde des Unternehmens, und wenn eines von ihnen entfernt werden muss, findet ein genau definiertes Extraktionsverfahren statt. Dazu gehrt die Entfernung von Zertifikaten und anderen Werten auf dem Gert. Im Gegensatz dazu betreten und verlassen die Arbeiter die Anlage in einem eher unvorhersehbaren Rhythmus. Zudem kann nicht immer sichergestellt werden, dass sie einem Extraktionsverfahren folgen, wenn sie das Unternehmen verlassen. Um diesen humanspezifischen Anforderungen gerecht zu werden, werden Identifizierungsausweise und kurzlebige Zertifikate eingefhrt. Wie in Abb. 9 dargestellt, mssen die Arbeiter das folgende Verfahren durchlaufen, um die Gerte in der Einrichtung zu kontrollieren:

Abb. 9
figure 9

Bedienerauthentifizierung

Full size image
  1. 1.

    Ein Bediener muss sich an einer HMI anmelden, z. B. an einem Firmen-Smartphone oder Tablet, das mit dem Firmennetzwerk verbunden ist. Wenn das Anmeldeverfahren gestartet wird, baut die HMI einen sicheren Kanal mit einem Back-End-Server in der Einrichtung auf, indem sie ihr langfristiges Gertezertifikat verwendet. Da dieses Gert leicht aus der Einrichtung entfernt werden kann, siehe auch Abschn. 5.3.

  2. 2.

    HMI fordert den Betreiber auf, dem HMI seinen NFC-Identittsausweis vorzulegen, und lst den Authentifizierungsprozess auf dem Back-End-Server aus.

  3. 3.

    Der Back-End-Server kommuniziert direkt mit dem NFC-Identifizierungsausweis und berprft dessen Authentizitt und Gltigkeit.

  4. 4.

    Nach erfolgreicher Ausweis-Authentifizierung muss der Bediener durch die Prsentation eines zweiten Faktors, z. B. durch ein Passwort, Fingerabdruck-Scan oder neuere Methoden wie Face-Scan und Gang-Erkennung [17], um das Ausziehen von Arbeitshandschuhen zu verhindern, verifizieren, dass er der Besitzer des vorgelegten Ausweises ist.

  5. 5.

    Nach berprfung des zweiten Faktors fordert das HMI ein kurzlebiges Zertifikat an, indem es eine CSR an den Back-End-Server sendet.

  6. 6.

    Ausgelst durch eine CSR-Anforderung fragt der Back-End-Server die Autorisierungsrechte des Betreibers aus einer Datenbank ab. Diese Rechte werden in das kurzlebige Zertifikat Cert_temp eingearbeitet, das schlielich von der lokalen CA unterzeichnet und mit einer kurzen Gltigkeitsdauer, z. B. einer Arbeitsschicht, an das HMI ausgestellt wird. Das HMI wird nun einem bestimmten Benutzer zugewiesen, bis das Zertifikat abluft oder der Bediener sich abmeldet (siehe auch Abschn. 5.3).

  7. 7.

    Das HMI verwendet Cert_temp, um eine sichere Kommunikation zu industriellen Gerten aufzubauen und die Befehle des Bedieners sicher weiterzuleiten.

  8. 8.

    Wenn Cert_temp abgelaufen ist, muss der Benutzer das Authentifizierungsverfahren erneut durchfhren.

5.3 Widerruf von Zertifikaten

Das Widerrufsverfahren soll den Missbrauch von gltigen Zertifikaten verhindern, die von der lokalen CA fr das HMI ausgestellt wurden. Obwohl dieses Verfahren fr die HMI und die ihr innewohnenden Zugangsdaten und Berechtigungen entwickelt wurde, gilt es fr alle von einer lokalen CA ausgestellten Zertifikate.

Da es mehrere Grnde fr eine Certificate Revocation List (CRL) gibt, werden hier nur ausgewhlte Grnde aufgefhrt, die unseren Anwendungsfall betreffen:

  • HMI-Gert kann aus der Einrichtung entfernt werden und potenziell bsartig genutzt werden (Gertezertifikat)

  • benutzer meldet sich ab, bevor das Kurzzeit-Zertifikat abluft

  • Mitarbeiter-Berechtigungen wurden gendert

  • Wiederherstellung von Langzeit-Zertifikaten aus ausgemusterten Gerten

Der Widerrufsmechanismus besteht aus zwei Aktionen. Erstens muss jedes Gert eine lokale Kopie einer zentralisierten Widerrufsliste (CRL) fhren, die auf einem Back-End-Server in der Einrichtung gehostet wird, und diese Liste regelmig aktualisieren. Der Zeitraum fr die Aktualisierung muss je nach Anwendungsfall und Werkskonfiguration festgelegt werden. Er sollte klein genug sein, um potenziellen Missbrauch zu verhindern und gro genug sein, um eine berlastung von Gerten und Netzwerk zu vermeiden.

Zweitens muss bei der Herstellung einer sicheren Verbindung zwischen zwei Teilnehmern jedes Gert das erhaltene Zertifikat gegen die Sperrliste prfen. Nur wenn das Zertifikat nicht auf der Sperrliste steht, kann der Verbindungsversuch fortgesetzt werden. Diese Vorgehensweise kann den dezentralen Aufbau unseres Anwendungsfalles erschweren, da ohne Sperrprfung eine Kommunikation zu einem zentralen Backend-Server nur fr die kurzfristige Zertifikatserstellung, z. B. zu Beginn einer Arbeitsschicht, erforderlich ist. Dieser Nachteil kann jedoch durch den Einsatz redundanter Back-End-Server berwunden werden.

Schlielich erfordert der Widerrufsmechanismus einen zustzlichen Schritt bei der Abmeldung des Bedieners vom HMI. Nach dem Drcken der Abmeldetaste muss das HMI den Back-End-Server ber das deaktivierte Kurzzeitzertifikat Cert_temp informieren. Abb. 10 demonstriert eine abgelehnten Verbindung mit einem widerrufenen Zertifikat. Darber hinaus muss diskutiert werden, welche Manahmen ergriffen werden, wenn ein HMI eine Zeit lang nicht benutzt wurde. Beispielsweise kann das HMI erneut nach dem Bedienerpasswort/Fingerabdruckscan fragen oder eine Nachricht zur kurzfristigen Deaktivierung des Zertifikats an den Back-End-Server senden.

Abb. 10
figure 10

Sequenz des Zertifikatswiderrufs

Full size image

Mit den oben genannten Anstzen kann folgende Sicherheitsanforderung erreicht werden: Industrielle Gerte werden untereinander authentifiziert, indem ihre CertDevice ausgetauscht werden. Die Kommunikationskanle zwischen den Gerten werden durch einen verschlsselten Kanal geschtzt, der auf Schlsselmaterial basiert, das aus dem Authentifizierungsprozess abgeleitet wird. Menschliche Anwender authentifizieren sich ber eine HMI, ihren Identittsausweis und einen zweiten Faktor. Zertifikate und Berechtigungen knnen widerrufen werden, um verschiedene Eckflle blicher Branchenszenarien zu untersttzen.

6 Zusammenfassung

Dieser Beitrag analysiert die Sicherheitsherausforderungen in einer spezifischen industriellen Umgebung mit Hilfe der STRIDE-Analyse und schlgt ein PKI-basiertes Sicherheitskonzept vor, das weithin akzeptierte Sicherheitsmechanismen wie Credential-Management, Entity-Authentifizierung und feingranulare Benutzerberechtigungskontrolle kombiniert. Ziel dieses Beitrags ist es nicht, neue, mglicherweise unsichere Konzepte zu verbreiten, sondern zu zeigen, dass eine moderne industrielle Anwendung mit verschiedenen Gertetypen auf ein berschaubares Ma an Sicherheitsanforderungen reduziert werden kann. Diese Anforderungen lassen sich mit Grundkonzepten erfllen und sichern so ohne groen Aufwand die Fabrik der Zukunft.

In Abschn. 5 beziehen wir uns nicht auf die in OPTIMUM angewandten Kommunikationsprotokolle, da die vorgestellten Anstze allgemeingltig sind und um den Fokus dieses Beitrags auf die Schritte zur praktischen Absicherung einer bestehenden Architektur zu richten.

Da unsere Architektur weitgehend auf industrieller Kommunikation basiert, mssen wir zu dem Schluss kommen, dass das gesamte Design auf der Annahme beruht, dass Feldgerte in der Lage sind, Berechtigungsnachweise sicher zu speichern und kryptografische Berechnungen ohne wesentliche Auswirkungen auf die zeitkritische Kommunikation durchzufhren. Obwohl wir kryptographische Co-Prozessoren verwenden, die die Sicherheitsschicht unserer Kommunikationsprotokolle [18] untersttzen, mssen wir diese Anforderung in Zukunft nach der Implementierungsphase evaluieren.

Die nchsten Schritte betreffen hauptschlich das Engineering der industriellen Anwendung. Es mssen also Mglichkeiten geschaffen werden, die notwendigen Schlssel zu generieren und zu verteilen. Dabei ist darauf zu achten, dass die Komplexitt der Ttigkeiten fr den Entwickler nicht zu hoch wird.

Im Prinzip sollte ein hnlicher Ansatz verfolgt werden, um die IoT-Kommunikation und die Authentifizierung des Benutzers, der gerade ein bestimmtes Betriebsgert benutzt, zu sichern. Hier muss vor allem die Praktikabilitt bewertet werden.