Sichere Maschinenkommunikation im Internet of Things

Sichere Kommunikation zwischen Maschinen

Eine sicherer verschlüsselter Kanal wird auch für Machine-to- Machine (M2M) Datentransfer benötigt. Aus diesem Grund verwenden die meisten der Identitäten, die M2M-Prozesse ermöglichen, Secure Shell (SSH ) für die Authentifizierung und Autorisierung. Zum Beispiel kann ein automatisierter Prozess, der Server-Log-Daten abruft eine  authentifizierten und autorisierte Verbindung  sowie einen sicheren Kanal  zu jedem Server erforderlich machen, um etwa Log-Daten zentral verarbeiten und verfügbar machen zu können. Secure Shell ist ideal für diese Funktionen , weil :

1. Der PKI-basierte Authentifizierungsprozess der bei Secure Shell verwendet wird, sichert die Anmeldeinformationen. Der private Secure Shell Benutzerschlüssel wird nie über das Netzwerk gesendet.
2. Die von  Secure Shell unterstützte (PKI) basierende Authentifizierung ermöglicht es Prozessen, ihre Anmeldeinformationen mitzuteilen, ohne dass eine interaktive Sitzung notwendig wird in der Benutzer sich mit Benutzernamen und Kennwort anmelden müssen - oder über einen anderen interaktive Authentifizierungsprozess.
3. Secure Shell ermöglicht die vertrauliche Übermittlung von Daten. Die Kommunikation  erfolgt verschlüsselt über eine sichere Verbindung.
4. Secure Shell ermöglicht es Einrichtungen, die Funktionalität, deren Ausführung via SSH sie genehmigen möchten, zu definieren und zu begrenzen, welche Funktionen ein Prozess unter einer Secure Shell Genehmigung durchzuführen kann. Dies betrifft " wissen müssen , tun müssen, " Kriterien der IAM –Governance.

Obwohl diese Vorteile auf der Hand liegen wird klar, dass in der  IAM –Verwaltung von Identitäten, die Secure Shell verwenden, leicht Lücken entstehen können. Typischerweise erfolgt die Bereitstellung dieser Identitäten dezentralisiert. Identitäten können etwa von Anwendungsentwicklern, Anwendungseigentümern und Prozessverantwortlichen zugeordnet werden. Dies führt häufig zu einem Mangel an geeigneter und lückenloser  Kontrolle und Aufsicht über die Erstellung von Identitäten und deren Berechtigungen.

Ohne zentrale Verwaltung und Sichtbarkeit der vergebenen Zugänge können Unternehmen nicht sicher sein, wie viele Secure Shell Identitäten erstellt wurden, zu welchen Aktionen diese Identitäten berechtigt sind, und welche dieser Berechtigungen zu einem gegebenen Zeitpunkt tatsächlich benötigt werden.

Der Umfang und die Natur dieses Problems sind nicht nur theoretischer Natur. Ein typischer Enterprise Server verfügt über acht bis 100 Secure Shell Zugänge(das heißt öffentliche Secure Shell Benutzerschlüssel). Dies summiert sich. Ein großes Unternehmen kann mehr als eine Million Schlüssel im Einsatz haben.

Trusted Computing in der Smart Factory

Industrie 4.0: Trusted Computing in M2M Umgebungen

Entwürfe für moderne  Standards schlagen teilweise eine hierarchische 3-Schichten-Architektur bestehend aus M2M Gateways, M2M Devices und M2M Servern für Geräte, die das IP Protokoll unterstützen, vor.

In der Realität existieren jedoch eine Vielzahl von kleinen Geräten wie Sensoren,  deren Leistungskapazität in dieser Hinsicht den Anforderungen des IP Protocols nicht genügt.
Um für diesem Problem Abhilfe zu schaffen könnte man einerseits prüfen, ob vorhandene Optimierungsansätze,  die IP für bestimmte Klassen von Sensoren ermöglichen, wie beispielsweise mit IPv6 über Low-Power Wireless Personal Area Networks (6LoWPAN) als Basis für Weiterentwicklungen für  den Einsatz in der vorgesehenen Umgebung dienen könnten.

Außerdem basieren viele Anwendungen in verteilten Systemen auf flachen, meist Peer-to- Peer-Architekturen zwischen Geräten, die unter Verwendung unterschiedlicher Kommunikationstechnologien kommunizieren können (etwa Sensornetze , Ad- hoc -Netzwerke).

Es gibt zwei mögliche Richtungen, wie dieses Problem gelöst werden könnte. Eine mögliche Lösung ist, die Kommunikation zwischen Geräten ohne ein M2M -Gateway, unabhängig von der eingesetzten Kommunikationstechnologie zu erreichen, und eine weitere wäre die derzeitigen Anwendungen so zu modifizieren, dass sie auch dann funktionieren, wenn Geräte  nicht auf direktem Weg miteinander kommunizieren, sondern durch ein M2M -Gateway. Beide Ansätze haben ihre Vor- und Nachteile.

Trust Mechanismen in M2M-Umgebungen

Verteilte und autonome Trust-Mechanismen für M2M-Umgebungen

Da verteilte und autonome Trust Mechanismen für die M2M Umgebungen in Smart Factories erforderlich sein sollten, muss Trust auf einem M2M -Gerät von Anfang an vorhanden sein. Eine Lokale Zustandskontrolle über einen sicheren Bootvorgang (lokale Trust Validierung ) muss für M2M-Geräte in jedem Fall erfolgen. Dieser sichere Boot kann die Etablierung  einer vertrauenswürdigen Umgebung über  einen Hardware-Sicherheits Anker sicherstellen und ein grundlegendes Trust-Level in Industrie 4.0-Umgebungen herstellen.

In diesem Zusammenhang hat die Trusted Computing Group (TCG) autonome und Remote-Validierungs-Modelle vorgeschlagen. Bei der Autonomen  Validierung (zum Beispiel unter Verwendung von Smartcards, auf denen Authentifizierungs-Informationen gespeichert sind ) stellt sich allerdings das Problem, der kostspieligen OnSite- Ersetzungen möglicherweise kompromittierter oder defekter Geräte. Bei Remote- Validierung treten in der Praxis oft Probleme mit der Skalierbarkeit und der Komplexität im Zusammenhang mit den Beschränkungen des Industrie 4.0 M2M-Geräts auf.

Halbautonome Validierung im M2M-Bereich

Ein vielversprechender Weg für die Forschung im Bereich IT-Sicherheit in der Industrie 4.0 Ära und dem Zeitalter der Smart Factories könnte das Prinzip der halbautonomen Validierung sein. Halbautonome Validierung kombiniert lokale Validierung mit Fernvalidierung, was bedeutet , dass ein Gerät in der Lage ist , die Vertrauenswürdigkeit ein anderes Gerät zu validieren und  in Situationen, in denen sich dies schlecht vermeiden lässt, mit einem vertrauenswürdigen Dritten zu kommunizieren (in vielen Umgebungen ist diese Möglichkeit der Kommunikation mit  Drittparteien allerdings jedoch überhaupt nicht vorhanden) .

Für M2M -Umgebungen sind daher verteilte halbautonome Trust Verification Mechanismen erforderlich. Die zuvor beschriebene M2M -Architektur von ETSI umfasst auch die Verwendung von gesicherten und vertrauenswürdigen, von einem M2M -Service kontrollierten, Umgebungs-Domänen  als Grundstein für den (sicheren)  Einsatz von Anmeldeinformationen auf M2M-Geräten und Gateways.