Die Vernetzung von Geräten und Anwendungen im Bereich der industriellen Automation nimmt zu; der Begriff Industrie 4.0 ist in aller Munde. Schwachstellen ergeben sich insbesondere aus der nicht schnell genug nachgerüsteten IT-Sicherheit. Funktionale Sicherheit und Gerätesicherheit sind notwendig, um Produktionsanlagen vor Angriffen zu schützen. Auf Basis von Open-Source-Software wird im Projekt SecureField eine Plattform entwickelt, die die Definition und Implementierung von skalierbaren Sicherheitslösungen für industrielle Anwendungen ermöglicht und erleichtert. Mit dieser sollen Geräte auf der Feldebene mit Anwendungen im Internet Ende-zu-Ende abgesichert werden können. Die Forschungspartner trafen sich am 08. November 2017 in Frankfurt, um den Arbeitsfortschritt und die Sicherheitsmodelle der Feldbustypen CANopen und PROFINET vorzustellen. Dabei waren auch assoziierte Partner, wie die DECOIT^®, um die Ergebnisse zu analysieren und mit zu diskutieren. Dies soll die Qualität in dem Industrie4.0-Projekt hochhalten und sicherstellen, dass man sich in keine Sackgasse bewegt. Während des gesamten Tages wurden Sicherheitsprobleme besprochen und ein gemeinsames Konzept verabschiedet, so dass alle Teilnehmer zufrieden die Heimreise antreten konnten.

Am Anfang gab es einen kurzen Projektabriss, der den Ist- und Soll-Zustand für alle Anwesenden beschrieb. Aktuell wird ungesicherte Kommunikation über den Feldbus (ein System zur Datenübertragung) vorgenommen und die Verbindung zu unsicheren Netzsegmenten kann zu Sicherheitsproblemen führen. Dies liegt daran, dass Feldbussysteme früher nicht mit anderen Netzen verbunden wurden und heute auf einmal IP-Kommunikation darüber stattfinden soll. Im Soll-Zustand sollte daher eine Absicherung industrieller Feldbus-Kommunikation bis hin zum Feldgerät angestrebt werden. Die Nutzung etablierter Techniken und Protokolle ist dabei vorgesehen – speziell auch bei SecureField. Das Rad soll hier nicht noch einmal neu erfunden werden. Das Projekt legt die Konzentration daher auf die Datensicherung der Kommunikation zwischen Geräten auf der Feldebene sowie zwischen Geräten und mobilen Terminals. Ziel ist es, die TLS-Verschlüsselung über alle Netze hinweg ausnutzen zu können.

Bei der Plattformentwicklung wird daher die Bereitstellung eines Frameworks anhand vorgefertigter Sicherheitslösungen vorgenommen. Die Entwicklung von Software-Komponenten wird zur Integration in Embedded-Umgebungen genutzt. Dabei kommt auch ein Trusted Platform Module (TPM) und Smart-Module zum Einsatz. Da man an der Lösung und nicht an proprietärer Lizenzpolitik interessiert ist, wird die endgültige Lösung quelloffen als Open Source angeboten. Die Integration des (D)TLS-Protokolls (Datagram Transport Layer Security) ermöglicht dabei auch die Nutzung des UDP-Protokolls, die im Gegensatz zur reinen TLS-Nutzung steht. Bestehende und sichere kryptografische Verfahren werden zur Verschlüsselung genutzt und die Nutzung einer lokalen PKI (Private Key Infrastructure) ist vorgesehen. Auch wird man innerhalb des Projekts die langen Lebenszyklen von Endgeräten (Embedded Systems) mit einbeziehen. So lassen sich Betriebssysteme nicht einfach nach einigen Jahren erneuern, sondern müssen weiter pflegbar gehalten werden.

Im nächsten Schritt wurde das Sicherheitsmodell von CANopen vorgestellt. Das CAN-Protokoll arbeitet asynchron und unterschiedliche Hersteller können darüber kommunizieren. Es ist weit verbreitet im industriellen Umfeld. In Automatisierungsnetzen wird es genutzt, um auf ein bestimmtes Gerät zuzugreifen. Aber: Es existiert keine Ende-zu-Ende-Sicherheit! Im Projekt wurde daher ein erster Prototyp entwickelt, der zwei Schnittstellen zur Trennung von Netzsegmenten aufweist. Während eine Verbindung zum Ethernet vorhanden ist, wird eine zweite zum lokalen CANopen-Netzwerk initiiert. Dabei funktioniert der Prototyp als Gateway – ähnlich wie eine Firewall mit Embedded Linux. Daten werden dann nur noch über sichere Kanäle ausgetauscht. CANopenNode wird aktuell als Open Source Software (OSS) verwendet. Es wurden bereits Performance-Messungen des Prototyps vorgenommen. Dessen Messabweichungen betrugen weniger als 1 %, wobei 10 Sekunden Verzögerungen bei TLS-Handshakes erreicht werden konnten. Diese Ergebnisse sind zufriedenstellend. Zukünftig wird Ethernet dem CAN-Feldbus aber immer mehr den Rang ablaufen.

Das PROFINET-Modell ist ein bisschen komplexer als der CAN-Bus. PROFINET ist heute der Industrie-Ethernet-Standard schlechthin, der TCP/IP-Protokolle nutzen kann und echtzeitfähig ist. Außerdem können auch andere Feldbussysteme integriert werden. Er besteht aus verschiedenen Komponenten (Supervisor, Controller, Device) und enthält einen Standard- und einen Echtzeit-Kanal für PROFINET-Anwendungen. Die Koexistenz zwischen gesicherten, bzw. ungesicherten Geräten wird ebenfalls ermöglicht. Die Frame ID definiert das PROFINET-Subprotokoll und muss sich dabei im abgesicherten Bereich befinden. Ein Padding-Mechanismus musste zusätzlich eingeführt werden, da sonst Pakete entstehen, die kleiner als die kleinsten Ethernet-Pakete sind! Ethernet wird daher als unterste Schicht bei PROFINET mitverwendet. Stark diskutiert wurde die parallele Nutzung von DTLS-Kanälen, um verschiedene verschlüsselte Pfade zeitgleich nutzen zu können. Viele Teilnehmer waren der Ansicht, dass so wenig Kanäle wie möglich parallel verwendet werden sollten, da dies nur weitere Schlüsselpaare und damit Ressourcen, bzw. Performance, kosten könnte. Jeder Kanal muss auch immer wieder neue Schlüssel nach einer bestimmten Zeit bekommen, weshalb eine Neuinitiierung erfolgen muss. Von daher würde eine parallele Nutzung sich auch komplexer gestalten.

Im Gegensatz dazu ist SafetyNET p im Wesentlichen ein proprietäres Protokoll. Diese Ethernet-basierte Feldbus-Kommunikation in der Automatisierungstechnik ist ebenfalls echtzeitfähig und enthält ein Network Discovery Protocol (NDP). Auch ein CANopen-basierter Dienst ist vorhanden. Durch die Nutzung von Ethernet-Technologie können normale Switches verwendet werden. Das UDP-Protokoll findet Anwendung. Die Routing-Funktionalität ist ein wichtiger Bestandteil. Schwerpunkt des Einsatzes ist die Kommunikation mit sicherheitsrelevantem Inhalt.

Abschließend wurde festgestellt, dass ein gemeinsames Modell gefunden werden sollte, welches alle Feldbusse miteinander vereint. Dazu wurden drei Anwendungsfälle betrachtet: Ende-zu-Ende-Kommunikation zwischen zwei Endpunkten, DTLS-Kanal zwischen zwei Endpunkten und emulierte Feldbus API über einen DTLS-Kanal. Um alle Anwendungsfälle abbilden zu können, wurde ein abstraktes Modell entwickelt. Das DTLS-Protokoll wird dabei transparent implementiert, so dass standardkonform darüber kommuniziert werden kann. So lassen sich alle Kommunikationswege einheitlich, unabhängig vom eingesetzten Feldbussystem, absichern. Das nächste Treffen ist im Juni 2018 geplant, wo die ersten Realisierungen diskutiert werden sollen.