1 Einführung

1.1 Vertrauen in Daten

Die Digitalisierung von industriellen Prozessen hat bereits im Rahmen der dritten industriellen Revolution mit dem Einzug von Computern in die Fabrik- und Fertigungshallen eingesetzt (s. Kap. 3). Durch die computergestützte Steuerung von Maschinen und Prozessen hat sich der Grad der Automatisierung erhöht. Durch den technologischen Fortschritt auf Gebieten der Künstliche Intelligenz (KI), Kommunikation, Information und Vernetzung sowie der Sensorentwicklung wird die Automatisierung aktuell noch weiter vorangetrieben. Prozesse werden zunehmend intelligent, das heißt Entscheidungen werden direkt im laufenden Prozess situationsabhängig von Maschinen und Computerprogrammen getroffen und in Form von entsprechenden Aktionen beziehungsweise Reaktionen ausgeführt. Vorgänge lassen sich aus der Ferne überwachen, da ihr realer, physischer Zustand über die Messwerte der vielen unterschiedlichen Sensoren virtuell und in Echtzeit abgebildet werden kann. Dieses durch Aggregation der Daten geschaffene virtuelle Abbild kann von Steuerprogrammen genutzt werden, um zielgerichteter in den zu steuernden Prozess einzugreifen. Durch Aufnahme, Aggregation und Verarbeitung des kontinuierlich fließenden Datenstroms wird darüber hinaus eine Datengrundlage geschaffen, auf deren Basis weitere Systemkomponenten neue Dienste und Funktionen bereitstellen können, wie zum Beispiel eine intelligente Wartungsplanung (engl. condition monitoring). Mit der Digitalisierung wird die Produktion einerseits schlanker, effizienter und flexibler, andererseits geht sie aber auch mit zunehmend dezentralen, datenbasierten Entscheidungsstrukturen einher.

Eine zentrale Herausforderung ist es, Vertrauen für diese Strukturen zu schaffen. Dieser Beitrag stellt drei technische Maßnahmen vor, die dazu beitragen können – im Zentrum stehen dabei Sicherheitsaspekte. Die Maßnahmen setzen an unterschiedlichen Punkten der Datenverarbeitungskette an: Von der Erfassung der Rohdaten (zum Beispiel über Sensoren) über ihre Weiterverarbeitung und Übertragung bis zu ihrer Speicherung beziehungsweise Archivierung.

Als anschauliches Beispiel für die Anforderungen an eine Datenverarbeitungskette im industriellen Kontext dient zum Beispiel die Qualitätssicherung für die Fertigung eines Werkstücks. Bei der Vermessung eines produzierten Werkstücks kommt ein Koordinatenmessgerät zum Einsatz, welches Messpunkte an dem Werkstück aufnimmt. Aus den aufgenommenen Messpunkten kann die Geometrie des Werkstücks rekonstruiert und diese im Rahmen der Qualitätssicherung mit einer vorgegebenen Geometrie verglichen werden. Dies ermöglicht eine automatische Bestimmung der Abweichungen von dem Soll-Zustand. Um eine hohe Messgenauigkeit zu erreichen, müssen während der Vermessung Umgebungsparameter wie beispielswiese Temperatur, Temperaturgradienten, Luftfeuchtigkeit, etc. in vorgegebenen Bereichen eingehalten werden. Sowohl die Umgebungsparameter als auch die Koordinaten selbst werden durch kalibrierte Sensoren unterschiedlichster Art erfasst. Die Daten werden über sichere Kommunikationskanäle zwischen Systemkomponenten ausgetauscht, wobei sichergestellt werden muss, dass die Integrität der Daten nicht durch Dritte unerkannt verletzt werden kann. Nachdem die Daten vollständig verarbeitet wurden, müssen sie sicher gespeichert werden. In dem genannten Beispiel kann die Qualitätssicherung also auf Basis der erhobenen Daten feststellen, dass das Werkstück den Anforderungen entspricht. Die erhobenen Daten müssen nun über einen definierten Zeitraum sicher gespeichert werden, sodass sowohl der Prozess der Datenerhebung als auch die Beteiligung der Akteure im Nachhinein nachvollzogen werden kann. Es darf nicht möglich sein, dass eine Systemkomponente im Nachhinein ihre Beteiligung an dem Prozess abstreiten kann. Der Auftraggeber, der das Werkstück im Anschluss weiterverarbeitet, kann aufgrund der Art und Weise, in der die Daten erhoben und gespeichert werden, Vertrauen in die Korrektheit der Daten fassen. Durch geeignete Maßnahmen wie beispielsweise dem Einsatz von Distributed-Ledger-Technologien kann er sogar selbst an dem Prozess der manipulationsgeschützten Datenverarbeitung beteiligt werden.

Die im Beitrag vorgestellten technischen Maßnahmen umfassen Instrumente wie digitale Kalibrierscheine und Verfahren/Architekturen für die sichere Datenorchestrierung, die aktuell im Rahmen des durch das Bundesministerium für Wirtschaft und Energie (BMWK) geförderten strategischen Einzelprojektes GEMIMEG-II entwickelt beziehungsweise evaluiert werden. Im Rahmen des Vorhabens soll eine sichere, durchgängige, rechtsgemäße und rechtsverträgliche Ende-zu-Ende-Verfügbarkeit von Daten/Informationen für die Umsetzung von zuverlässigen, vernetzten Messsystemen entwickelt werden. Die angestrebten Lösungen sollen prototypisch in anwendungsnahe Demonstratoren (Real Beds) implementiert werden, um ihre Leistungsfähigkeit in realistischen Szenarien zu testen, beziehungsweise nachzuweisen (zum Beispiel vernetzte Kalibriereinrichtungen, Industrie 4.0-Anwendungen, Pharma-/Prozessindustrie, autonomes Fahren).

1.2 Systemarchitekturen

Zur Beschreibung der Gesamtsysteme unterschiedlicher Anwendungsgebiete und Branchen wurden verschiedene Referenzmodelle entwickelt, welche die jeweiligen Besonderheiten der Systeme, die beteiligten Akteure und ihre Interaktionen untereinander darstellen. Bei den Akteuren kann es sich um Menschen, Maschinen und Prozesse handeln. Einige Referenzmodelle wie zum Beispiel die Automatisierungspyramide geben konkrete Hierarchiestufen vor und benennen konkrete Systemkomponenten auf einzelnen Hierarchieebenen. Andere Referenzmodelle wie zum Beispiel das OpenFog-Referenzmodell fokussieren sich nicht auf ein konkretes Anwendungsgebiet (zum Beispiel industrielle Automatisierung) und erlauben ein erhöhtes Maß an Freiheitsgraden bei der Implementierung. In der industriellen Automatisierung hat sich die die Automatisierungspyramide (siehe Abb. 18.1) nach dem Standard IEC 62264 (Integration von Unternehmens-EDV und Leitsystemen) etabliert. IEC 62264-1 (2013) führt die gezeigten Ebenen ein, Siepmann und Graef (2016) stellen die Ebenen als Pyramide dar und benennen Systeme der einzelnen Ebenen. Die Automatisierungspyramide gibt dabei eine hierarchische Struktur des Gesamtsystems vor, bei der auf der untersten Ebene die physischen Prozesse mit einzelnen Komponenten wie Sensoren und Aktoren zu finden sind. Auf weiteren höheren Ebenen bis hin zur Unternehmensleitebene werden die generierten Daten weiterverarbeitet, Prozesse gesteuert und es können weitere Dienste bereitgestellt werden, die auf den aggregierten Daten operieren. Zu den Systemen, die auf den höheren Ebenen angesiedelt sind, gehören üblicherweise Supervisory Control and Data Acquisition (SCADA), Manufacturing Execution Systems (MES) und Enterprise Resource Planning (ERP). Global betrachtet werden Daten von unten nach oben erfasst und aggregiert. Die Prozesse hingegen werden von oben nach unten geplant und gesteuert. Abhängig von der Hierarchieebene gibt es unterschiedliche Anforderungen an die Kommunikation, so sind nahe am Prozess geringe Latenzzeiten und verlässlicher Datenaustausch besonders wichtig, während diese Anforderungen auf höheren Ebenen zugunsten anderer Anforderungen gelockert werden. Einen Überblick über typische Anforderungen auf den einzelnen Ebenen gibt IEC 62264-1 (IEC 2013).

Abb. 18.1
figure 1

Die Automatisierungspyramide nach IEC 62264 (Eigene Darstellung; vgl. Siepmann und Graef 2016, S. 49)

Full size image

Verschiedene Initiativen und Konsortien haben weitere komplexe domänenspezifische Referenzmodelle entwickelt, die unterschiedliche Aspekte beziehungsweise Dimensionen eines Gesamtsystems der jeweiligen Domäne darstellen. So wurde im Bereich der Energieversorgung das Smart Grid Architecture Model (SGAM) und im Bereich der Industrie 4.0 das Reference Architecture Model Industry 4.0 (RAMI4.0) erarbeitet. Die Alliance for Internet of Things Innovation (AIOTI) hat mit einem ähnlichen Ansatz ein Modell für IoT-Anwendungen entwickelt. Details zu den Referenzarchitekturen werden von Willner und Gowtham (2020, S. 42–48) beschrieben.

Ein weiterer und etwas neuerer Ansatz ist das Fog Computing. Bei diesem Ansatz gibt es eine vergleichbare Hierarchie mit der Cloud an der Spitze. Im Gegensatz zur zentralen Datenverarbeitung in der Cloud findet die Datenverarbeitung und -speicherung beim Fog Computing jedoch auch dezentral in den Netzwerken, in denen die Daten anfallen, statt. Dies hat den Vorteil, dass große Datenmengen lokal schnell verarbeitet werden können und ausgewählte Ergebnisse oder verarbeitete Daten durch entsprechende Dienste in der Cloud bereitgestellt werden. Im Bereich des Fog Computing werden ebenfalls Referenzmodelle entwickelt, beispielsweise von dem OpenFog-Konsortium (OpenFog Consortium Architecture Working Group 2017). Das OpenFog-Konsortium definiert das Fog-Computing folgendermaßen: „A horizontal, system-level architecture that distributes computing, storage, control and networking functions closer to the users along a cloud-to-thing continuum“ (OpenFog Consortium Architecture Working Group 2017, S. 3). Die definierte Architektur ist also für Szenarien geeignet, bei denen die Datenverarbeitung ganzheitlich von der Datenerfassung bis in die Cloud abgedeckt wird. Als Anwendungsbereiche werden unter anderem Smart Cities, Transportation/Smart Traffic Control bis hin zu intelligenten Fahrzeugen und Smart Buildings/Gebäudeautomatisierung genannt. Im Rahmen des Projekts GEMIMEG-II werden unter anderem Datenverarbeitungsketten betrachtet, die von den Sensoren bis in die Cloud reichen. Daher werden insbesondere auch Ansätze aus der OpenFog-Referenzarchitektur evaluiert.

Alle genannten Referenzarchitekturen ähneln sich insofern, dass das Gesamtsystem in mehrere Hierarchieebenen unterteilt werden kann. Auf den unteren Ebenen direkt am Prozess werden Daten beispielweise in Form von Sensorwerten erhoben, welche anschließend durch Systeme der höheren Hierarchieebenen aggregiert werden, wobei weitere Dienste auf Basis der aggregierten Daten bereitgestellt werden. Bei der OpenFog-Referenzarchitektur ist dabei die Rede von einer Intelligenzschöpfung, welche anhand des eingangs erwähnten Beispiels der Qualitätssicherung veranschaulicht werden kann: Die rohen Sensordaten werden durch aggregierende Systeme durch Kalibrierinformationen ergänzt, sodass nun eine Beurteilung der Messungenauigkeit möglich wird. Eine Reihe von gemessenen Temperaturwerten erlaubt beispielsweise eine Darstellung des Temperaturverlaufs während einer Koordinatenmessung. Aus den gemessenen Koordinaten kann nun sowohl ein Modell des Werkstücks berechnet, als auch die maximale Messungenauigkeit bestimmt werden.

Am Beispiel der OpenFog-Referenzarchitektur kann ein weiterer Effekt der digitalen Transformation veranschaulicht werden (Abb. 18.2): Während die Geräte untereinander zunehmend vernetzt sind, weichen die Grenzen zwischen den Hierarchieebenen gleichzeitig auf. Die vormals klare Trennung zwischen Netzen zur Steuerung von Prozessen (Operational Technology, OT) und solchen der klassischen Informationsverarbeitung im Unternehmen (Informational Technology, IT) wird zu einem gewissen Grad aufgeweicht. Geräte können durchaus auch über mehrere Hierarchieebenen hinweg miteinander kommunizieren.

Abb. 18.2
figure 2

Beispielszenario Fog Computing nach der OpenFog-Architecture (Eigene Darstellung; vgl. OpenFog Consortium Architecture Working Group 2017, 5.2.2.1)

Full size image

Bei Betrachtung des Prozesses der Intelligenzschöpfung, wie die Verarbeitung der Daten und das Bereitstellen von neuen Diensten auf Basis aggregierter Daten in Abb. 18.2 genannt wird, wird schnell klar, dass die Qualität der bereitgestellten Dienste maßgeblich von der Qualität der erfassten/aggregierten Daten abhängig ist. Im Beispiel der Qualitätskontrolle können beispielsweise nur dann verlässliche Aussagen über die Qualität des produzierten Werkstücks getroffen werden, wenn die erhobenen Daten den Qualitätsanforderungen (maximale Messungenauigkeit, Integrität, Authentizität) entsprechen.

1.3 Daten- und Informationsqualität

Unter dem Begriff Datenqualität können verschiedene Aspekte der Daten- und Informationsverarbeitung verstanden werden. Bereits im Jahre 1996 haben Wang und Strong (1996) auf empirische Weise verschiedene Dimensionen des Begriffs Quality of Data aus Sicht der Datenkonsumenten (Data Consumers) untersucht und ermittelt, welche Qualitätsmerkmale bei Daten, die fit for use by consumers sind, aus Sicht der Endbenutzer relevant sind. Dabei konnten insgesamt 15 Aspekte der Datenqualität in die vier Kategorien Accuracy, Relevancy, Representation und Accessibility eingeteilt werden. Neben den Endbenutzern können auch Datenproduzenten, verarbeitende Dienste, Standards oder gesetzliche Vorgaben weitere Anforderungen an die Datenqualität definieren.

1.4 Motivation und Ziele

In diesem Beitrag liegt der Fokus auf dem Aspekt des Vertrauens in Daten, dabei ist sowohl die Korrektheit, als auch die die Verifizierbarkeit der Korrektheit der Daten besonders wichtig. Konkret werden dabei drei Ziele betrachtet, die mit unterschiedlichen technischen Maßnahmen erreicht werden können.

  • Korrektheit der erhobenen Daten: Dieser Aspekt bezieht sich auf den Anfang der Wertschöpfungskette, konkret auf die Schnittstelle, an der Sensorwerte ermittelt und anschließend weiterverarbeitet werden. Die Akkuratheit der Daten eines Sensors kann durch einen Kalibrierschein, der von einem akkreditierten Kalibrierlabor ausgestellt wird, bestätigt werden. Mit der Weiterentwicklung des bestehenden (papierbasierten) Kalibrierscheins hin zu einem digitalen und maschinenlesbaren Kalibrierscheins kann der Prozess der Sensordatenverarbeitung und des Qualitätsmanagements vereinfacht und automatisiert werden.

  • Sicherer Datenaustausch: Ab dem Punkt, an dem Daten zwischen den Teilnehmern in einem System ausgetauscht werden, müssen Maßnahmen getroffen werden, die es ermöglichen, den Ursprung von Daten zu verifizieren und sicherzustellen, dass Daten auf dem Übertragungsweg nicht unbemerkt durch Angreifer manipuliert werden. Hier kommen Maßnahmen der Kommunikationssicherheit zum Einsatz, wobei der Fokus weniger auf der Vertraulichkeit der Daten, sondern vielmehr auf der Integrität und der Authentizität der Daten liegt.

  • Nachweisbarkeit: Über die gesamte Datenwertschöpfungskette vom Sensor bis zu bereitgestellten Diensten (zum Beispiel in der Cloud) sollte die Datenverarbeitung nachvollziehbar beziehungsweise nachweisbar sein. Diese Anforderung ist insbesondere für Anbieter von Diensten interessant, da diese hier nachweisen können, wie die Daten zustande gekommen sind. In Szenarien, in denen verschiedene Teilnehmer mit unterschiedlichen Interessen interagieren, bieten sich Distributed-Ledger-Technologien (DLT) zur Schaffung von Vertrauen an.

2 Digitale Kalibrierzertifikate

2.1 Entwicklung des Digitalen Kalibrierscheins

Am Anfang der Datenwertschöpfungskette werden Rohdaten in Form von Sensorwerten erfasst. Genauigkeit/Richtigkeit (Accuracy) ist ein wichtiges Datenqualitätsmerkmal: Instanzen, welche Daten weiterverarbeiten, müssen die Gewissheit haben, dass die erfassten Daten einen realen Prozess beziehungsweise die Wirklichkeit ausreichend genau darstellen. Die Anforderungen an die Genauigkeit werden dabei durch das jeweilige Anwendungsszenario vorgegeben. Computerprogramme, die Prozesse steuern, können nur dann richtig funktionieren, wenn sie auf einer akkuraten Datengrundlage operieren. Bereitgestellte Dienste benötigen ebenfalls eine akkurate Datengrundlage, um eine hohe Qualität liefern zu können.

Im Rahmen einer Kalibrierung von Sensoren wird ihre Güte, das heißt ihre Abweichung gegenüber einem Normal, ermittelt. Die Abweichung wird in Form eines Kalibrierzertifikats, das von einem akkreditiertem Kalibrierlabor ausgestellt wird, festgehalten. Die Kalibrierzertifikate werden in Papierform ausgestellt. Dieser Prozess soll mit der Entwicklung des digitalen Kalibrierscheins digitalisiert werden.

Ein Ansatz für einen digitalen Kalibrierschein wird von Hackel et al. (2017) beschrieben. Das Ziel des Ansatzes ist es, den bisherigen analogen Kalibrierschein durch ein international anerkanntes Format, mit dem ein (rechtsgültig) digital signiertes, maschinenlesbares Dokument dargestellt werden kann, zu ersetzen. Im Rahmen des Projekts GEMIMEG-II wird der digitale Kalibrierschein von der Physikalisch-Technischen-Bundesanstalt (PTB) weiterentwickelt.

2.2 Aufbau und Inhalt des digitalen Kalibrierscheins

Bestimmte Inhalte des Kalibrierscheins werden durch verschiedene Normen vorgeschrieben. So gibt es administrative Daten, die das kalibrierte Objekt/Gerät, das Kalibrierlabor und den Auftraggeber der Kalibrierung identifizieren. Neben den administrativen Daten enthält ein Digitaler Kalibrierschein die Messergebnisse der Kalibrierung in einem maschinenlesbaren und -interpretierbaren Format. Neben diesen beiden reglementierten Bestandteilen eines digitalen Kalibrierscheins können weitere Inhalte, zum Beispiel eine menschenlesbare Version des Kalibrierscheins im PDF-Format, aufgenommen werden. Werden qualifizierte digitale Signaturen und qualifizierte Zeitstempel nach dem Signaturgesetz und der Signaturverordnung eingesetzt, können die signierten Dokumente rechtlich als Urkunden betrachtet werden (vgl. Hackel et al. 2017, s. auch Abschn. 18.2.3).

Der Digitale Kalibrierschein besteht aus einem XML-Dokument und kann dadurch mit standardisierten Verfahren (XML-Signaturen) digital signiert werden. Die Struktur des digitalen Kalibrierzertifikats wird durch ein XML-Schema vorgegeben. Aktuell (11/2021) ist die dritte Version des XML-Schemas auf der Webseite der PTB unter der Internetadresse https://www.ptb.de/dcc/v3.0.0 verfügbar.

2.3 Anwendung des digitalen Kalibrierscheins

Digitale Kalibrierscheine werden in der Lage sein, wesentlich zur Digitalisierung von Prozessen innerhalb der Datenwertschöpfungskette beizutragen.

Anhand des in der Einleitung vorgestellten Fallbeispiels (Qualitätssicherung für die Fertigung eines Werkstücks) kann die Einbindung des digitalen Kalibrierzertifikats folgendermaßen veranschaulicht werden:

Die beteiligten Sensoren (Temperatursensor, Feuchtigkeitssensor, Sensoren des Koordinatenmessgeräts) werden im Rahmen eines Kalibrierauftrags an ein akkreditiertes Kalibrierlabor übergeben. Sowohl der Betrieb als auch die Herstellung können beim auftraggebenden Unternehmen angesiedelt sein. Im letzteren Fall würden die kalibrierten Sensoren zusammen mit den Kalibrierzertifikaten an ein Betreiberunternehmen verkauft. Die Sensoren können nun eingebaut und die dazugehörigen digitalen Kalibrierzertifikate in dem System bereitgestellt werden.

Sobald ein Gerät in der Lage ist, den angeschlossenen Sensor zu identifizieren, kann der zugehörige digitale Kalibrierschein bezogen und validiert werden. Ein System, das die erfassten Sensordaten aggregiert, kann die entsprechenden Kalibrierzertifikate verarbeiten und benötigte Parameter wie zum Beispiel die Messungenauigkeit aus dem Kalibrierzertifikat extrahieren und mit den erfassten Daten in Bezug setzen. Durch die digitale Signatur des Kalibrierlabors ist das Vertrauen in die Daten, die von dem Sensor geliefert werden, hergestellt.

2.4 Weitere Entwicklungen

Die Definition des digitalen Kalibrierzertifikats allein ist noch nicht ausreichend, um eine vollständige Digitalisierung des Kalibrierwesens zu erreichen. Neben der Struktur des digitalen Kalibrierscheins muss eine Infrastruktur geschaffen werden, die eine Verteilung, Speicherung und Abfrage der digitalen Kalibrierscheine erlaubt. Es müssen darüber hinaus Mechanismen einer Public-Key-Infrastruktur (PKI) implementiert werden, die eine Verifikation der Signatur eines Kalibrierscheins erlauben, allerdings können die existierenden Mechanismen, die sich bereits bei der sicheren Kommunikation im Internet etabliert haben, nicht ohne Anpassungen auf digitale Kalibrierscheine übertragen werden: Im Gegensatz zu Public-Key-Zertifikaten ist bei digitalen Kalibrierscheinen kein Ablaufdatum vorgesehen. Im Fall von Aufbewahrungsfristen über einen langen Zeitraum müssen Maßnahmen getroffen werden, welche die Datenintegrität auch dann erhalten, wenn die zur Signaturberechnung eingesetzten Verfahren in der Zwischenzeit kompromittiert wurden.

Es kann wie bei Public-Key-Zertifikaten zu Situationen kommen, in denen ausgestellte und gültig signierte Kalibrierzertifikate zurückgerufen (das heißt nachträglich als ungültig erklärt) werden müssen. Dies kann beispielsweise dann der Fall sein, wenn im Nachhinein bekannt wird, dass an der Kalibrierung beteiligte Komponenten zum Zeitpunkt der Kalibrierung fehlerhaft waren. In diesem Fall müssen Nutzer der möglicherweise fehlerhaft kalibrierten Geräte über den Rückruf der Kalibrierzertifikate informiert werden. Dieser Mechanismus kann ähnlich funktionieren wie der Rückruf von Public-Key-Zertifikaten. Zu diesem Zweck stellt eine PKI standardisierte Mechanismen bereit. Für die Übertragung dieser Mechanismen auf Digitale Kalibrierscheine müssen an dieser Stelle Erweiterungen bestehender Verfahren oder gänzlich neue Verfahren entwickelt werden. So sind Zertifikatsperrlisten für Public-Key-Zertifikate nur zum Zweck des Rückrufs von Public-Key-Zertifikaten spezifiziert und geeignet, zum Zweck des Rückrufs digitaler Kalibrierscheine müssen neue, auf digitale Kalibrierscheine angepasste Datenstrukturen entworfen werden. Das Projekt GEMIMEG-II (2020) beschäftigt sich aktuell mit der Entwicklung solcher Erweiterungen.

3 Sichere Kommunikation

3.1 Zero-Trust-Sicherheitsmodell

Ein vergleichsweise neues Sicherheitsmodell für (verteilte) IT-Systeme ist das sogenannte Zero-Trust-Modell. Im Jahre 2018 wurde eine entsprechende Special Publication vom amerikanischen National Institute of Standards and Technology (NIST) veröffentlicht. In der NIST Special Publication (SP) 800-207: Zero Trust Architecture (Stafford 2020) wird das Konzept im Detail erläutert und eine entsprechende Zero-Trust-Architektur vorgestellt.

Ein Grundgedanke des Zero-Trust-Modells ist, dass Geräten und Diensten innerhalb des Netzwerks nicht grundsätzlich vertraut wird. Dies ist ein Gegensatz zu früheren Ansätzen, bei denen Sicherheit zum Beispiel dadurch erreicht werden sollte, dass alle Geräte in einem System zum Beispiel durch ein virtuelles privates Netz (VPN) zusammengeschlossen wurden. Auf diese Weise sollten Angreifer aus dem Netz ausgeschlossen werden, sodass sich nur vertrauenswürdige Teilnehmer innerhalb des Netzes befinden.

In verteilten Systemen, wie sie durch die digitale Transformation entstehen, kann dieser traditionelle Ansatz keine ausreichende Sicherheit mehr bieten. Die Systeme sind nicht mehr geschlossen und es können weitere Teilnehmer, die nicht unter der Kontrolle einer einzigen Organisation stehen, in dem System agieren. Beispiele für solche Teilnehmer sind beauftragte Dienstleister, die einen beschränkten Zugang zu Diensten und Ressourcen benötigen.

Eine notwendige Voraussetzung für Zero-Trust-Architekturen sind sichere Identitäten für alle Teilnehmer (Personen, Geräte und Dienste), die sich in dem Netzwerk befinden.

3.2 Sichere Identitäten

Die Notwendigkeit sicherer Identitäten im Kontext der Industrie 4.0 wird in einer Veröffentlichung der Plattform Industrie 4.0 (BMWi 2016) hervorgehoben: Die Sicherheit aller Kommunikationsbeziehungen zwischen Teilnehmern hängt unmittelbar von der Sicherheit der Identitäten ab. Hinsichtlich der Identität wird nach verschiedenen Sicherheitslevels unterschieden. So gibt es neben einer einfachen Identität eine eindeutige Identität (Unique Identity) und eine sichere Identität (Secure Identity).

Damit eine Identität als sicher bezeichnet und für Anwendungen wie eine gegenseitige Authentifizierung oder Urhebernachweise genutzt werden kann, müssen bestimmte Anforderungen erfüllt sein. Die Identität darf nicht fälschbar sein, privates Schlüsselmaterial darf ein Gerät nicht verlassen können und öffentliches Schlüsselmaterial muss durch eine autorisierte und vertrauenswürdige Zertifizierungsinstanz bestätigt sein. Die Anforderungen an sichere Identitäten werden zum Beispiel durch Standards wie den internationalen Standard IEC 62443 (Industrielle Kommunikationsnetze – IT-Sicherheit für Netze und Systeme) vorgegeben. Eine Zusammenfassung dieser Anforderungen wird vom der Plattform Industrie 4.0 in dem technischen Überblick zu sicheren Identitäten (BMWi 2016) gegeben. Weitere Anforderungen an sichere Identitäten werden durch die eIDAS-Verordnung gegeben.

Ein Schutz von Schlüsseln kann durch Hardware Security Module oder Trusted Platform Module erreicht werden, bei denen geheimes Schlüsselmaterial durch Mechanismen auf Hardwareebene gesichert werden. IEC 62443-3-3 fordert für hohe Sicherheitslevel eine Unterstützung von Public-Key-Infrastrukturen und die Verwendung von asymmetrischen kryptografischen Verfahren zur Realisierung von sicheren Identitäten und zusätzlich Hardwarespeicher für geheime Schlüssel (BMWi 2016).

Eine digitale Identität hat einen Lebenszyklus, der mit der Erstellung einer Identität beginnt und mit dem Löschen/Archivieren einer Identität endet. Es gibt standardisierte Protokolle, mit denen zum Beispiel ein Gerät bei der Integration in ein System automatisch eine neue Identität der entsprechenden Organisation zugewiesen wird. Dieser Prozess der Zuweisung einer Identität wird als Enrollment bezeichnet. Ein Gerät hat dabei schon bei der ersten Auslieferung durch das Herstellerunternehmen eine temporäre Identität.

3.3 Ende-zu-Ende Security

Bei der Kommunikation mit anderen Kommunikationsteilnehmern muss eine gegenseitige Authentifikation stattfinden. Zu diesem Zweck eignet sich für TCP/IP-basierte Verbindungen das Transport Layer Security (TLS)-Protokoll, welches bereits im Internet als etabliertes Security-Protokoll eingesetzt wird. In Machine-to-Machine-Kommunikationsszenarien ermöglicht das TLS-Protokoll eine gegenseitige Authentifizierung unter Verwendung von Public-Key-Zertifikaten. Für verbindungslose Kommunikationsbeziehungen (UDP/IP) ist eine Abwandlung des Protokolls unter dem Namen Datagram Transport Layer Security (DTLS) verfügbar.

Eine Sicherung der Daten auf dem Transportweg durch Protokolle wie TLS oder DTLS ist jedoch nicht in allen Szenarien ausreichend, denn Kommunikationsbeziehungen zwischen Teilnehmern in dem System sind nicht zwingend bilateral (mit einer einzigen Datenquelle und einer einzigen Datensenke): Ein im industriellen Umfeld verbreitetes Kommunikationsmodell ist das Publish-Subscribe-Modell, bei dem eine Datenquelle Daten veröffentlicht und diese Daten von mehreren Instanzen abonniert werden. In diesem Fall ist die Kommunikation eine One-to-many-Beziehung.

Abb. 18.3 zeigt eine solche Kommunikationsbeziehung, bei der ein sogenannter Broker die Verteilung der veröffentlichten Daten an mehrere Abonnenten übernimmt. Sicherheitsprotokolle wie das verbreitete TLS-Protokoll sind hier nur in der Lage, die einzelnen Kommunikationsbeziehungen zu schützen, nicht aber die Daten selbst. Dies hat zur Folge, dass die Daten, während sie zum Beispiel auf dem Broker zwischengespeichert sind, nicht vor Manipulationen geschützt sind. Ein kompromittierter Broker wäre hier also in der Lage, unbemerkt Manipulationen an Daten vorzunehmen. Ein Publisher ist nicht in der Lage, die Sicherheit der Daten auf der Transportverbindung zwischen Broker und Subscribern zu gewährleisten: Er muss darauf vertrauen, dass Broker und Subscriber ausreichende Sicherheitsmaßnahmen ergreifen.

Abb. 18.3
figure 3

Ende-zu-Ende Security schützt die Daten selbst, anstatt nur die Kommunikation. (Eigene Darstellung)

Full size image

Abb. 18.3 veranschaulicht einen weiteren Effekt, der durch die gezeigte Kommunikationsstruktur mit Zwischenstationen entsteht: TLS ermöglicht lediglich eine Authentifizierung der jeweiligen Endpunkte der Kommunikationsbeziehungen, in dem Beispiel also Publisher/Broker beziehungsweise Broker/Subscriber. Diese Endpunkte sind jedoch nicht die eigentlichen Endpunkte, zwischen denen die Daten ausgetauscht werden, diese sind nämlich Publisher und Subscriber. Der Broker „versteckt“ also die tatsächlich kommunizierenden Instanzen voreinander.

Die Lösung der vorgestellten Problematik besteht in der Implementierung von Ende-zu-Ende-Sicherheitsmechanismen, die die Daten selbst schützen. Hier können Urhebernachweise an die Daten gekoppelt werden, mit denen Empfänger von Daten ihren Urheber verifizieren können. Gleichzeitig können geeignete Urhebernachweise dazu eingesetzt werden, Urhebern einer Nachricht das Abstreiten einer Urheberschaft unmöglich zu machen.

Für das etablierte XML-basierte XMPP-Protokoll, das ebenfalls eine Broker-basierte Kommunikationsarchitektur verwendet und zum Beispiel für Instant-Messaging eingesetzt wird, existiert ein Standard, der die Anwendung von Ende-zu-Ende-Sicherheitsmechanismen beschreibt. Hier werden die ausgetauschten Nachrichten durch digitale Signaturen erweitert und bestimmte Teile von Nachrichten können verschlüsselt übertragen werden. Details werden im Standard RFC 3923 (Saint-Andre 2004) beschrieben. Eine konkrete Implementierung von Ende-zu-Ende-Sicherheitsmechanismen kann von Anwendungsszenario zu Anwendungsszenario unterschiedlich aussehen und hängt auch von den ausgetauschten Daten ab. Für das weit verbreitete JSON-Datenaustauschformat kommen zum Beispiel JSON Web Signatures (JWS) und JSON Web Encryption (JWE) infrage, um Ende-zu-Ende-Sicherheit mit standardisierten Mitteln zu erreichen. Die genannten Aspekte der Kommunikationssicherheit (Sichere Identitäten, Enrollment, Vertraulichkeit und Nachweisbarkeit der Kommunikation) werden im Projekt GEMIMEG-II intensiv untersucht, um eine sichere und einheitliche Datenorchestrierung von den Sensoren bis zur Cloud zu realisieren.

4 Nachweisbarkeit mit Distributed-Ledger-Technologie

4.1 Anwendung einer DLT zur Unterstützung der Nachweisbarkeit

Distributed-Ledger-Technologien und Blockchains im Speziellen haben spätestens seit den Erfolgen der bekannten Kryptowährungen wie Bitcoin, Ethereum und Co ein besonderes Interesse von ganz unterschiedlichen Branchen erfahren. Neben der populären Möglichkeit, diese als Währung zu nutzen, kann eine DLT zur dezentralen Datenspeicherung mit Manipulationsschutz genutzt werden, bei der die einzelnen Transaktionen nachverfolgbar sind, wie es im Folgenden kurz anhand der eine Blockchain-basierten Lösung erläutert wird.

Bei einer Blockchain werden mithilfe kryptografischer Methoden (sogenanntem Hashing) Informationsblöcke derartig miteinander verknüpft, dass sich eine Kette von Blöcken ergibt, deren Integrität in ihrer Gesamtheit geprüft werden kann, um beispielsweise Manipulationen nachzuweisen. Als Distributed-Ledger-Technologie wird eine Blockchain dezentral gespeichert.

In einem solchen System können lokal bei einem Teilnehmer des Blockchain-Netzwerkes abgelegte Blöcke mit denen der anderen Teilnehmer verglichen werden. Änderungen, wie zum Beispiel das Ergänzen weiterer Blöcke ist nur möglich, wenn in dem Blockchain Netzwerk zwischen allen Teilnehmern eine gemeinsame Entscheidung – ein sogenannter Konsens – darüber erreicht wird.

Durch diese Funktionsweise sind die einzelnen Transaktionen in der Historie einer Blockchain nachweisbar. Allerdings sollte vor der Entscheidung, eine Blockchain-Lösung einzusetzen, sorgfältig abgewogen werden, ob die Verwendung einer Blockchain tatsächlich sinnvoll ist.

Der Einsatz von einer Blockchain eignet sich insbesondere dann, wenn Vertrauen zwischen unterschiedlichen Akteuren mit unterschiedlichen (und unter Umständen gegensätzlichen) Interessen hergestellt werden soll. Zentrale Vorteile der Blockchain bestehen darin, dass Teilnehmer, die sich gegenseitig nicht trauen, ihre Beteiligungen an Transaktionen in dem Gesamtsystem zu späteren Zeitpunkten nicht abstreiten können und dass eine nachträgliche Manipulation der Transaktionsinhalte nicht oder zumindest nur mit enorm hohem Aufwand möglich ist. Bei diesen Transaktionen kann es sich beispielsweise um Messdaten handeln, welche im Rahmen des Qualitätsmanagements erhoben werden und über einen langen Zeitraum gespeichert werden müssen. Dabei kann die Speicherung der Messdaten in einer Datenbank erfolgen, während ein Fingerabdruck der Daten in Form eines Hashwertes auf der Blockchain abgelegt werden. Somit ist es möglich, die auf der Datenbank abgelegten Messdaten auf Manipulationen zu prüfen.

4.2 Unterschiedliche Blockchain-Typen

Es gibt unterschiedliche Ansätze bei Blockchain-Implementierungen. Die Hauptunterscheidungsmerkmale sind dabei die Realisierungen des Lesezugriffs und des Schreibzugriffs. Die verschiedenen Blockchain-Typen werden von Baumann et al. (2017) und Klebsch et al. (2019) detailliert erläutert.

Eine Blockchain-Lösung, bei der es keine Lesebeschränkungen gibt, wird public genannt, wohingegen solche Lösungen, bei denen der Lesezugriff nur ausgewählten Teilnehmern gestattet wird, als private bezeichnet werden.

Bezüglich des Schreibzugriffs bei einer Blockchain werden solche Lösungen, bei denen prinzipiell jeder Teilnehmer neue Daten in Form von Blöcken generieren und nach einem definierten Konsensmechanismus die Blockchain anhängen darf, permissionless genannt, während bei permissioned Blockchains die Menge der Teilnehmer, die Blöcke validieren und auf die Blockchain schreiben, begrenzt ist.

Basierend auf den zwei Dimensionen permissionless/permissioned und public/private lassen sich Blockchains in vier unterschiedliche Klassen einteilen.

Abb. 18.4 zeigt eine Einordnung verschiedener Blockchain-Lösungen in die zuvor genannten zwei Dimensionen. Blockchain-basierte Kryptowährungen sind dabei meist Public Permissionless Blockchains, was bedeutet, dass sich alle Teilnehmer an dem System beteiligen können und es keine zentralen (regulierenden) Instanzen gibt. Neben den permissionless-Systemen gibt es auch solche, bei denen die Blockchain selbst von einem Komitee von autorisierten Instanzen verwaltet wird, jedoch keine Beschränkungen beim lesenden Zugriff gemacht werden. Das in Abb. 18.4 aufgeführte Corda/R3 ist beispielsweise ein Konsortium aus etwa 40 Großbanken, welches eine gemeinsame Blockchain verwaltet. Private Permissionless Blockchains werden nicht weiter betrachtet, da diese Kombination von Lese- und Schreibberechtigungen widersprüchlich ist.

Abb. 18.4
figure 4

Einordnung unterschiedlicher Blockchain-Lösungen (Eigene Darstellung nach Baumann et al. 2017)

Full size image

Private Permissioned Blockchains sind eine geeignete Lösung für die Herstellung von Vertrauen zwischen Teilnehmern entlang einer Datenwertschöpfungskette, wie sie im industriellen Kontext vorkommen kann, hier kann durch eine Regulierung des Lesezugriffs zusätzlich kontrolliert werden, welche Teilnehmer Zugriff auf die gespeicherten Daten bekommt.

4.3 Ziele und Systemarchitektur

Entlang einer Datenwertschöpfungskette kann es unterschiedliche Teilnehmer geben, die Daten erfassen, Daten weiterverarbeiten und zusätzliche Dienste anbieten. Dabei können die Teilnehmer zu unterschiedlichen Organisationen gehören und unterschiedliche Interessen/Ziele verfolgen. Mit dieser Grundannahme ist eine Voraussetzung für die Anwendbarkeit einer Blockchain gegeben.

In dieser permissioned Blockchain wird die Blockchain von einem Konsortium verwaltet, in dem die beteiligten Organisationen vertreten sind. Da es sich um eine private Blockchain handelt, dürfen nur berechtigte Teilnehmer auf der Blockchain lesen. Dieses Berechtigungsmanagement erlaubt es, schützenswerte Daten vor unbefugtem Zugriff zu schützen.

Laabs und Đukanović (2018, S. 143–153) beschreiben Möglichkeiten, die eine Blockchain in einem Machine-to-Machine-Kommunikationsszenario aus der Industrie 4.0 bieten kann: Maschinen können Dienste anderer Maschinen entdecken und diese nutzen. Die Nutzung der Dienste (was in diesem Fall eine Interaktion zwischen Teilnehmern unterschiedlicher Organisationen bedeutet) kann schließlich auf der Blockchain dokumentiert und gegebenenfalls abgerechnet werden, zum Beispiel in Form von Tokens, die im Zuge der Nutzung eines Dienstes ihren Besitzer wechseln, was ebenfalls auf der Blockchain gespeichert wird. Nutzungsbedingungen der Services werden transparent definiert und sind von allen Teilnehmern vor der Nutzung von Diensten einsehbar.

Nicht nur Interaktionen zwischen Teilnehmern unterschiedlicher Organisationszugehörigkeiten können auf der Blockchain gespeichert werden. Auch die Erzeugung von Datenobjekten durch einzelne Teilnehmer kann auf der Blockchain festgehalten werden. Somit kann beispielsweise die Erzeugung von Messdaten oder Dokumenten, welche eine juristische Relevanz haben können, nicht abstreitbar dokumentiert werden. Dies kann folglich in verschiedenen Branchen wichtig sein. Ein Beispiel mit Medizindaten wird von Alladi et al. (2019) beschrieben.

Wie kann eine Blockchain nun eingesetzt werden, um Vertrauen zwischen Teilnehmern, die an der Datenwertschöpfungskette beteiligt sind, zu etablieren? In diesem Beitrag soll der Einsatz einer Blockchain am Beispiel des Frameworks Hyperledger Fabric veranschaulicht werden.

Mit dem Einsatz der Blockchain soll erreicht werden, dass alle Organisationen (beziehungsweise ihre Vertreter in dem Konsortium, im Folgenden Peers genannt) das gleiche Bild des Gesamtsystems haben. Dies umfasst sowohl den aktuellen Zustand des Systems (im Folgenden Weltzustand genannt), als auch alle Aktionen/Transaktionen, die zu diesem aktuellen Zustand geführt haben. Alle Peers starten mit dem gleichen Urzustand.

Abb. 18.5 zeigt eine beispielhafte Architektur des Blockchain-Systems. Die Clients sind Akteure in der Datenwertschöpfungskette und können über eine bereitgestellte API definierte Aktionen (zum Beispiel Generieren von Daten, Nutzen von bereitgestellten Services, etc.) auf der Blockchain ausführen. Ein detaillierter Überblick über Hyperledger Fabric wird von Kakei et al. (2020) gegeben.

Abb. 18.5
figure 5

Eine Reihe von Transaktionen bildet den aktuellen Weltzustand aus dem Urzustand (Eigene Darstellung)

Full size image

Welche Aktionen genau ausgeführt werden können, hängt von dem sogenannten Chaincode ab, welcher in allen Peers gleich definiert ist. Der Chaincode stellt vereinfacht gesagt eine Art Regelwerk dar, welches die möglichen Funktionen innerhalb des Blockchain-Systems festlegt.

Der Chaincode muss individuell implementiert werden, um ein gegebenes System geeignet darzustellen. Im Falle des Beispiels der Datenwertschöpfungskette muss der Chaincode in einer Art und Weise definiert werden, sodass alle infrage kommenden Aktionen in der Datenverarbeitung abgedeckt werden. Dies betrifft insbesondere das Erfassen von Daten, die Weiterverarbeitung der Daten und letztendlich die Bereitstellung und Nutzung von Diensten.

4.4 Schaffen von Vertrauen

Eine Transaktion auf der Blockchain überführt einen Weltzustand in einen neuen Weltzustand. Dies wird in Abb. 18.5 illustriert. Was dabei genau geschieht, hängt von dem Chaincode und der Transaktion ab. Es können Daten aus dem Weltzustand erzeugt, geändert, oder gelöscht werden. Bei den Operationen gehen jedoch auch gelöschte Daten nicht verloren, vielmehr kann jeder historische Weltzustand durch den Urzustand und die auf der Blockchain unveränderbar gespeicherte Transaktionskette rekonstruiert werden.

Damit sichergestellt ist, dass der Weltzustand von allen Peer-Knoten zu jeder Zeit konsistent ist, muss bei der Aufnahme neuer Transaktionen eine Konsensfindung zwischen den Peer-Knoten erfolgen. Im Falle von Hyperledger Fabric läuft das Verfahren folgendermaßen ab (Vergleiche Kakei et al. 2020, Abschnitt II-B):

  1. 1.

    Ein Client, der eine Transaktion durchführen möchte, muss diese als Vorschlag bei einer bestimmten Anzahl von Peer-Knoten einreichen. Diese speziellen Knoten werden Endorser genannt. Der Vorschlag ist dabei digital signiert.

  2. 2.

    Jeder Endorser simuliert die Durchführung der Transaktion auf seinem aktuellen Weltzustand und liefert das Ergebnis (die Auswirkungen der Transaktion auf den Weltzustand) digital signiert zu dem Client zurück.

  3. 3.

    Der Client besitzt nun von jedem Endorser ein digital signiertes Ergebnis des Transaktionsvorschlags. Unter der Annahme, dass die Weltzustände aller Endorser gleich sind, sind auch die Ergebnisse alle gleich.

  4. 4.

    Der Client übergibt die signierten Ergebnisse an einen speziellen Orderer-Knoten, welcher die Transaktionen zur tatsächlichen Durchführung nochmals digital signiert an alle Peer-Knoten übergibt. Dabei werden die Transaktionen tatsächlich in die Blockchain übernommen und der Weltzustand eines jeden Peers wird in einen neuen Zustand überführt.

Der Client kann anhand der digitalen Signaturen verifizieren, dass die Peers unterschiedlicher Organisationen die Transaktion gesehen und auf gleiche Weise verarbeitet haben. Die Peers, die die Transaktion in ihren Weltzustand übernehmen, können anhand der digitalen Signaturen der anderen Endorser verifizieren, dass die anderen beteiligten Organisationen des Komitees die Transaktion auf die gleiche Weise verarbeitet haben. Nach Abschluss der Transaktion haben nun alle Peers und damit alle Organisationen den Ablauf der Transaktion in der Blockchain gespeichert.

Mit diesem Mechanismus wird sichergestellt, dass der Zustand der Blockchain bei den Teilnehmern konsistent gehalten wird und somit eine Prüfung der einzelnen Transaktionen im Nachhinein ermöglicht wird, was die Nachweisbarkeit gewährleistet.

Die Abfrage von Daten der Blockchain ist ebenfalls über entsprechende Funktionen, die im Chaincode definiert werden, möglich.

5 Zusammenfassung

Durch die im Rahmen der Industrie 4.0 vorangetriebenen Digitalisierung von traditionellen Systemen entstehen intelligente Systeme, die die gesamte Datenverarbeitungskette von einzelnen Sensoren bis hin zu Diensten in der Cloud abdecken. Die drei in diesem Beitrag vorgestellten technischen Maßnahmen, sind dazu geeignet, Vertrauen in Daten herzustellen, indem sie Informationen über die Datenqualität bereitstellen und darüber hinaus die Integrität und Authentizität von ausgetauschten Daten sicherstellen:

  1. 1.

    Kommunikationssicherheit: Ende-zu-Ende-Sicherheit spielt in der Datenorchestrierung zwischen der Sensorebene und der Cloud eine wichtige Rolle. Existierende kryptografische Maßnahmen und Protokolle decken alle wichtigen Punkte wie Identitätsmanagement, Public-Key-Infrastrukturen und Kommunikationssicherheit ab. Daten müssen sowohl während der Übertragung als auch während der Speicherung in ihrer Integrität und vor unbefugtem Zugriff geschützt sein.

  2. 2.

    Digitale Kalibrierzertifikate: Die Digitalisierung des Kalibrierwesens kann einen wesentlichen Mehrwert in der Digitalisierung von Prozessen darstellen. Anwendungsszenarien wie das Qualitätsmanagement können durch die Anwendung von digitalen Kalibrierscheinen und der zugehörigen Infrastruktur in wichtigen Punkten automatisiert und damit letztendlich kosteneffizienter umgesetzt werden.

  3. 3.

    Nichtabstreitbarkeit durch Distributed-Ledger-Technologie. Distributed-Ledger-Technologien und Blockchains im Speziellen existieren in vielen unterschiedlichen Varianten und Ausprägungen. Grundsätzlich sind geeignete Einsatzgebiete einer DLT/Blockchain all jene Szenarien, in denen Vertrauen zwischen unterschiedlichen Partnern/Organisationen etabliert werden soll, die einzelnen Akteure jedoch unterschiedliche Interessen verfolgen und sich daher einander nicht grundsätzlich vertrauen. Interaktionen zwischen Akteuren (zum Beispiel in Form von Verträgen) können über ein Blockchain-System oder ein vergleichbares DLT-System nachweisbar und vor Manipulationen geschützt gespeichert werden. Distributed-Ledger-Technologien können jedoch nur in bestimmten Anwendungsszenarien einen Vorteil bieten. Vor dem Einsatz einer Technologie wie zum Beispiel einer Blockchain muss geprüft werden, ob dies in dem vorliegenden Anwendungsszenario sinnvoll ist.

Durch eine so erzielte Nachweisbarkeit der Vorgänge in dem System kann das Verhalten des Systems und einzelner Teilnehmer auch im Nachhinein objektiv nachvollzogen werden.

Danksagung

Die Autoren bedanken sich für die Förderung des Projektes GEMIMEG-II (Förderkennzeichen: 01 MT20001A) durch das Bundesministerium für Wirtschaft und Klimaschutz als strategisches Einzelprojekt.