-
Diese Patentanmeldung nimmt die Priorität der Dänischen Anmeldung 202070675 vom 5. Oktober 2020 in Anspruch, deren Offenbarungsgehalt hiermit durch Rückbezug aufgenommen wird.
-
Die Offenbarung bezieht sich allgemein auf ein Computernetz, das ein Nicht-IP-Teilnetz mit mindestens einem Frontend-Gerät und ein IP-Teilnetz mit mindestens einem Backend-Gerät sowie ein Gateway umfasst, das beide Teilnetze miteinander verbindet und die Datenkommunikation zwischen ihnen überträgt, wobei die IP-Kommunikation zwischen dem Backend-Gerät und dem Gateway auf einem IP-Sicherheitsprotokoll basiert, das Mittel zur Authentifizierung und/oder Verschlüsselung bereitstellt, und wobei die Kommunikation zwischen dem Gateway und dem Frontend-Gerät eine Nicht-IP-Kommunikation ist. Darüber hinaus wird ein sicheres Verfahren für den Betrieb eines solchen Computernetzwerks und seiner Komponenten offengelegt.
-
Das Internet der Dinge (IoT) betrifft die Verbindung heterogener Objekte mit einem typischerweise cloudbasierten Backend-Gerät. Bei diesen Objekten kann es sich um intelligente persönliche Geräte, Automatisierungseinrichtungen mit Haushaltsgeräten und Systemen für Unterhaltung, Beleuchtung und Überwachung sowie um Fabrikmaschinen mit Sensoren und Aktoren handeln, um nur einige zu nennen. Das Backend-Gerät stellt dem Objekt (Frontend-Gerät) Daten zur Verfügung oder ermöglicht ihm den Zugriff auf Unternehmensanwendungen, die auf Cloud Computing basieren.
-
Derartige Computernetzwerke, die ein sicheres Zusammenwirken von IP-Netzwerken und Nicht-IP-Netzwerken ermöglichen, sind aus
CN211180606U bekannt. Ein Beleuchtungssystem, das Tunneling und das DALI-Protokoll verwendet, ist aus
US2008/0265799 ,
WO 2016/0075107 und
WO2015/054611 sowie aus
EP3525555 bekannt.
-
Die oben erwähnte Konnektivität von IoT-Systemen birgt entscheidende Sicherheitsrisiken, die innerhalb von IP-Netzen durch die Einrichtung eines sicheren Kommunikationstunnels zwischen entfernten Hosts auf der Grundlage eines IP-Sicherheitsprotokolls wie der stromorientierten Transport Layer Security (TLS), Secure Sockets Layer (SSL), Internet Protocol Security (IPsec) oder Datagram Transport Layer Security (DTLS) gemildert werden, wobei DTLS über das User Datagram Protocol (UDP) transportiert werden könnte und die Semantik des zugrundeliegenden Transports bewahrt.
-
Im Zusammenhang mit der vorliegenden Anwendung steht IP für „Internet Protocol“, das Paketstrukturen zur Verkapselung von Daten definiert, die an einen entfernten Zielhost übermittelt werden sollen, und das nach dem mehrstufigen OSI-Modell betrieben wird. Die Datenkapselung führt zu Paketen mit Headern, die IP-Adressinformationen enthalten, wobei die Pakete Datagramme auf der Ebene L3 (Netzwerkschicht) des OSI-Modells sind. Ohne die vorliegende Anwendung einzuschränken, sind die wichtigsten IP-Versionen derzeit IPv4 und IPv6.
-
Ein IP-Sicherheitsprotokoll könnte das Abhören, Abschwächen oder Fälschen der Kommunikation zwischen Hosts eines IP-Netzes oder verbundener IP-Netze verhindern. Es kann jedoch nicht ohne weitere Maßnahmen angewandt werden, wenn ein Nicht-IP-Teilnetzgerät an der Kommunikation beteiligt ist. Dies ist häufig der Fall, wenn ein einfaches Frontend-Gerät, wie z. B. ein intelligentes Beleuchtungssystem oder ein Sensor einer Werkzeugmaschine, in ein IoT-System eingebunden werden soll. Normalerweise ist ein solches einfaches Frontend-Gerät Teil eines Nicht-IP-Teilnetzes, das eine nicht-IP-basierte Kommunikation ermöglicht. Die Nicht-IP-Kommunikation könnte beispielsweise auf dem Digital Addressable Lighting Interface (DALI) oder einer Kommunikation über Zigbee, Bluetooth oder einen Feldbus, z. B. KNX, basieren. Darüber hinaus wird ein Gateway typischerweise als Brücke zwischen einem Nicht-IP-Teilnetz und einem IP-Teilnetz verwendet, insbesondere durch die Realisierung von Datenübersetzung, wie in
US 8,837,485 B2 offenbart.
-
Ein möglicher Weg, die Vertrauenswürdigkeit eines Nicht-IP-Teilnetzes zu erhöhen, ist die Hop-by-Hop-Authentifizierung und die Verschlüsselung von Nachrichten, die zwischen dem Frontend-Gerät und dem Gateway ausgetauscht werden, durch Anwendung von Pre-Shared Keys. Das Protokoll für die Hop-by-Hop-Authentifizierung in Nicht-IP-Teilnetzen ist jedoch häufig herstellerspezifisch. Darüber hinaus löst der sichere Hop-by-Hop-Datentransport bis zum Gateway nicht das Problem der gebrochenen Ende-zu-Ende-Sicherheit, da Daten, die das Nicht-IP-Teilnetz verlassen, vom Gateway entschlüsselt werden müssen, bevor sie an ein Backend innerhalb eines IP-Teilnetzes gesendet werden. In diesem Szenario ist ein Frontend-Gerät eines Nicht-IP-Teilnetzes nicht in der Lage festzustellen, ob das Gateway kompromittiert wurde oder nicht.
-
Für einen ausgefeilteren Ansatz zur End-to-End-Sicherheit wurde die TLS/DTLS-Sitzungswiederaufnahme vorgeschlagen. Dies erfordert einen anfänglichen TLS/DTLS-Handshake zwischen dem IP-Teilnetz-Backend-Gerät und dem Gateway, woraufhin die Sitzungsinformationen in einem nächsten Schritt an das Non-IP-Teilnetz-Frontend-Gerät übergeben werden. Darauf aufbauend ist ein Nicht-IP-Teilnetz-Frontend-Gerät in der Lage, einen neuen Sitzungsschlüssel zu generieren. Die Vertrauenswürdigkeit des Gateways wäre jedoch immer noch ein Problem, da ein Datenpaket mit einer Wiederaufnahmeanforderung, das über das Gateway übertragen wird, die Rekonstruktion des neuen Sitzungsschlüssels aus den bekannten Informationen der vorherigen Sitzung ermöglichen würde.
-
Da das Gateway ein wesentliches Sicherheitsrisiko in gemischten IP/Nicht-IP-Netzen darstellt, wird häufig nicht standardisierte proprietäre Sicherheitssoftware eingesetzt, was zu einem Interoperabilitätsproblem führt, da ein Frontend-Gerät eines ersten Herstellers möglicherweise nicht als kompatibel mit dem Gateway eines zweiten Herstellers akzeptiert wird.
-
Ziel der vorliegenden Erfindung ist es, die oben genannten Probleme zu entschärfen und ein Computernetzwerk zu beschreiben, das in der Lage ist, eine herstellerunabhängige, sichere Ende-zu-Ende-Kommunikation zwischen einem Frontend-Gerät eines Non-IP-Teilnetzes und einem Backend-Gerät eines IP-Teilnetzes herzustellen. Weiterhin sollen interoperable Komponenten des Computernetzwerks und ein sicheres Betriebsverfahren für das Computernetzwerk offenbart werden.
-
Die Erfindung betrifft ein Computernetzwerk, das ein Non-IP-Teilnetz mit mindestens einem Frontend-Gerät und ein IP-Teilnetz mit mindestens einem Backend-Gerät sowie ein Gateway-Gerät umfasst, das das Non-IP-Teilnetz mit dem IP-Teilnetz verbindet und die Datenkommunikation dazwischen übersetzt, wobei die Kommunikation zwischen dem Backend-Gerät und dem Gateway auf einem IP-Sicherheitsprotokoll basiert, das Mittel zur Authentifizierung und/oder Verschlüsselung bereitstellt, und wobei die Kommunikation zwischen dem Gateway und dem Frontend-Gerät eine Non-IP-Kommunikation ist.
-
Mit diesem Ausgangspunkt haben die Erfinder erkannt, dass zum Aufbau einer sicheren Ende-zu-Ende-Kommunikation zwischen dem Backend-Gerät und dem Frontend-Gerät das Gateway so konfiguriert sein muss, dass es einen Verbindungsaufbau (Handshaking) realisiert, ohne das vom Backend-Gerät empfangene Anfragedatagramm zu übersetzen. Bildlich gesprochen sollte sich das Gateway während des Handshake „transparent“ verhalten. Um diese Funktionalität zu realisieren, wird das Gateway so konfiguriert, dass es einen virtuellen IP-Kommunikationsendpunkt bereitstellt, der für das Frontend-Gerät bestimmt ist. Das Backend-Gerät führt eine Zuordnungstabelle, die einen virtuellen IP-Kommunikationsendpunkt des Gateways mit dem Frontend-Gerät in Beziehung setzt, wobei bei einer bevorzugten Implementierung die Information bezüglich der Zuordnung vom Gateway beim Scannen der verfügbaren Frontend-Geräte des Non-IP-Subnetzes bereitgestellt wird.
-
Im Folgenden wird davon ausgegangen, dass das Backend-Gerät das Handshaking initiiert. Dies ist jedoch nicht zwingend erforderlich und soll die Erfindung nicht einschränken, da das Handshaking auch durch das Frontend-Gerät ausgelöst werden könnte. Darüber hinaus hängt das spezifische Handshaking-Verfahren von dem gewählten IP-Sicherheitsprotokoll ab. Was die bevorzugte Wahl von DTLS als IP-Sicherheitsprotokoll betrifft, so werden weitere Einzelheiten dazu weiter unten offengelegt. Für die vorliegende Erfindung ist es lediglich von Bedeutung, dass das Gateway so konfiguriert ist, dass es ein vom Backend-Gerät stammendes Anfragedatagramm, das an den virtuellen IP-Kommunikationsendpunkt übermittelt wird, transparent an das Frontend-Gerät übergibt. Dies wird erreicht, indem eine Transkription des Anfragedatagramms über die Nicht-IP-Kommunikation an das Frontend-Gerät übertragen wird. Das bedeutet, dass das Gateway keine Übersetzung oder Interpretation des Dateninhalts des Request-Datagramms an das Frontend-Gerät liefert, sondern es huckepack auf der Non-IP-Kommunikation überträgt.
-
Dies schließt die Möglichkeit einer zumindest teilweisen Entkapselung des Anfragedaten-Datagramms vor der Übertragung ein, um eine andere Ebene nach dem OSI-Modell zu erreichen, wofür die vorliegende Anwendung den Begriff der „Transkription des Anfragedaten-Datagramms“ verwendet. Eine Möglichkeit wäre daher, das unveränderte Anfragedatagramm über die Non-IP-Kommunikation zu übergeben, wobei in diesem Fall das Anfragedatagramm und die entsprechende Transkription desselben identisch sind. Eine weitere Möglichkeit besteht darin, dass das Gateway vor der Übergabe der Transkription des Anfragedatagramms an das Frontend-Gerät eine Entkapselung auf dem Stack durchführt. Beispielsweise könnte das Anfragedatagramm als Anforderungsrahmen empfangen werden und die Transkription davon könnte ein Anforderungspaket sein.
-
Gemäß einer Ausführungsform umfasst der virtuelle IP-Kommunikationsendpunkt eine virtuelle IP-Adresse auf der Netzwerkschicht (L3), und das Anfragedatagramm umfasst ein Anfragedatenpaket mit einem Header, der das Backend-Gerät als Quelle und die virtuelle IP-Adresse als Ziel angibt.
-
Eine mögliche Nicht-IP-Kommunikation könnte auf Zigbee, Bluetooth oder einem Feldbus wie KNX basieren, wobei verschiedene Nicht-IP-Kommunikationsprotokolle denkbar sind. Dies schließt herstellerspezifische Nicht-IP-Kommunikation ein. Darüber hinaus könnte das Gateway so konfiguriert werden, dass es unterschiedliche Non-IP-Kommunikationsprotokolle für heterogene Frontend-Geräte innerhalb eines Non-IP-Teilnetzes verwendet. Darüber hinaus könnte ein Frontend-Gerät eine benutzerdefinierte Anwendungsschicht aufweisen, die einen Satz von Befehlen für seinen Betrieb bereitstellt.
-
Eine Ausführungsform sieht vor, dass die Non-IP-Kommunikation auf dem Digital Addressable Lighting Interface (DALI) basiert. In diesem Fall wird erfindungsgemäß der Dateninhalt eines an den virtuellen IP-Kommunikationsendpunkt gerichteten Anfragedatagramms nicht vom Gateway interpretiert und übersetzt, was zu einem Satz von DALI-Befehlen für die Steuerung eines Frontends führen würde, sondern eine bloße Transkription davon wird an ein Frontend-Gerät übertragen, indem der DALI-Schreibbefehl angewendet und ein Speicherbereich des Frontend-Geräts angegeben wird, der für die Speicherung von Handshaking-Datagrammen reserviert ist, die vom Backend-Gerät stammen.
-
Ein erfindungsgemäßes Frontend-Gerät erfordert nicht notwendigerweise eine Hardware-Modifikation, was insbesondere für einfache Frontend-Geräte von Vorteil ist. Die einzige Voraussetzung für eine Ausführungsform ist, dass die Firmware so modifiziert wird, dass das Frontend-Gerät eine grundlegende Implementierung des IP-Sicherheitsprotokolls ausführen kann, die zumindest in der Lage ist, das Handshaking durchzuführen. Zu diesem Zweck ist das Frontend-Gerät gemäß einigen Aspekten so konfiguriert, dass es die Transkription des Anfragedatagramms interpretiert und ein Antwortdatagramm mit einem Header erzeugt, der den virtuellen IP-Kommunikationsendpunkt als Quelle und das Backend-Gerät als Ziel angibt. Darüber hinaus muss das Frontend-Gerät in der Lage sein, eine Transkription des Antwort-Datagramms unter Anwendung der Nicht-IP-Kommunikation an das Gateway zu übertragen. Gemäß alternativen Aspekten, die weiter unten näher erläutert werden, wird das Frontend-Gerät so einfach wie möglich gehalten, wobei das IP-Sicherheitsprotokoll nicht vollständig im Frontend-Gerät selbst implementiert sein muss. Stattdessen wird das Frontend-Gerät durch das Backend-Gerät ferngesteuert.
-
Darüber hinaus ist das Gateway so konfiguriert, dass es in der Lage ist, die Transkription des Antwortdatagramms von dem Frontend-Gerät durch Anwendung der Nicht-IP-Kommunikation zu empfangen und eine zweite Transkription des Antwortdatagramms an das Backend-Gerät durch Anwendung der IP-Kommunikation zu senden. Die zweite Transkription des Antwort-Datagramms könnte dieselbe sein wie die ursprüngliche Transkription des Antwort-Datagramms oder sie könnte eine Verkapselung des empfangenen Originals nach unten im Stapel sein.
-
Darüber hinaus könnte die zweite Transkription des Antwort-Datagramms einen modifizierten oder erweiterten Header zumindest auf einer Ebene gemäß dem OSI-Modell enthalten. Es ist auch möglich, dass es die Aufgabe des Gateways ist, die anfänglichen Header-Informationen mit dem virtuellen IP-Kommunikationsendpunkt als Quelle der zweiten Transkription des Antwort-Datagramms und dem Backend-Gerät als Ziel bereitzustellen.
-
Bei einigen Ausführungsformen wird die sichere Ende-zu-Ende-Kommunikation zwischen dem Backend-Gerät und dem Frontend-Gerät mit einer symmetrischen Verschlüsselung hergestellt, für die vorab gemeinsam genutzte Schlüssel erforderlich sind. Der Austausch dieser Schlüssel könnte bereits bei der Herstellung des Endgeräts erfolgen. Obwohl es nur ein einziges anfängliches Schlüsselpaar für die symmetrische Verschlüsselung gibt, bleibt die Sicherheit erhalten, da der eigentliche Sitzungsschlüssel bei jedem Aufbau einer neuen sicheren Sitzung geändert wird. Dies bietet zusätzliche Sicherheit im Falle einer unterbrochenen Sitzung, da nicht alle zukünftigen Sitzungen gefährdet sind.
-
Als Alternative wird die asymmetrische Verschlüsselung eingesetzt, die auf Zertifikaten basiert. Allerdings ist der Rechenaufwand dafür wesentlich höher, wobei es im Falle einer asymmetrischen Verschlüsselung günstig ist, einen Verschlüsselungschip in das Frontend-Gerät einzubauen.
-
Ist die sichere Ende-zu-Ende-Kommunikation zwischen dem Backend-Gerät und dem Frontend-Gerät erst einmal hergestellt, kann das Gateway die Kommunikation nicht abhören oder deren Inhalt verändern. Außerdem sind ein Man-in-the-Middle-Angriff (MITM) oder ein Replay-Angriff nicht mehr möglich.
-
Ein weiterer Vorteil ergibt sich aus dem Umstand, dass bei einer bevorzugten Ausführungsform keine Änderung von Hardwarekomponenten des Frontend-Gerätes und/oder des Backend-Gerätes erforderlich ist. Eine bevorzugte Ausführungsform wird dadurch erreicht, dass die Firmware insbesondere des Gateways und/oder des Frontend-Gerätes modifiziert wird, um das Huckepack der Transkriptionen der Request- und Response-Datagramme mit Non-IP-Kommunikation zu realisieren und die zusätzliche Funktionalität eines vom Frontend-Gerät implementierten Basis-IP-Sicherheitsprotokolls hinzuzufügen.
-
In einer weiteren Entwicklung werden Maßnahmen ergriffen, um die Rechenlast auf der Seite des Frontends zu verringern. Dies könnte durch eine Ausführungsform erreicht werden, bei der das Frontend-Gerät nicht selbst eine Implementierung des IP-Sicherheitsprotokolls durchführt. Stattdessen wird die Interpretation der Transkription des vom Frontend-Gerät empfangenen Anfragedaten-Datagramms vom Backend-Gerät gesteuert. Zu diesem Zweck ist das Backend-Gerät so konfiguriert, dass es zusätzliche Anfragedatagramme über das Gateway sendet, indem es Huckepack auf die Nicht-IP-Kommunikation aufbaut, die direkt ausführbare Befehle der Anwendungsschicht des Frontend-Geräts, z. B. DALI-Befehle, zur Steuerung von Aktionen des Frontend-Geräts kapselt. Auf diese Weise kann ein einfaches Frontend-Gerät ohne zusätzliche Anforderungen an den permanenten Speicher gehalten werden.
-
Für das IP-Sicherheitsprotokoll stehen Transport Layer Security (TLS), Secure Sockets Layer (SSL), Internet Protocol Security (IPsec) oder Datagram Transport Layer Security (DTLS) zur Auswahl. Von dieser Gruppe wird DTLS aus verschiedenen Gründen bevorzugt. DTLS führt zu einem geringen Netzwerkprotokoll-Overhead und einer relativ bescheidenen Implementierungsgröße. Dadurch sind die Speicheranforderungen für das Backend-Gerät, das Gateway und das Frontend-Gerät gering und der Netzverkehr kann niedrig gehalten werden. Außerdem kann DTLS über das sitzungslose User Datagram Protocol (UDP) transportiert werden. Bei einigen Aspekten stellt das Gateway daher einen virtuellen IP-Kommunikationsendpunkt bereit, der für das Frontend-Gerät bestimmt ist und einen speziellen UDP-Socket für den Empfang eines Anforderungsdatagramms in Form eines Anforderungsrahmens vom Backend-Gerät umfasst.
-
Für den Fall, dass das Nicht-IP-Subnetz eine Vielzahl von Frontend-Geräten umfasst, ist es möglich, das Gateway mit einer entsprechenden Anzahl von dedizierten UDP-Sockets zu konfigurieren und eine Zuordnungstabelle zu erstellen, die jeden dedizierten UDP-Socket mit einem der Frontend-Geräte verknüpft. Bei einer alternativen Ausführungsform wird ein einziger UDP-Socket verwendet und dessen Multiplexing auf der Grundlage eines DTLS-Erweiterungsheaders angewandt, der Adressinformationen für die Durchführung der Non-IP-Kommunikation mit einem ausgewählten der Frontend-Geräte enthält.
-
Bevorzugte Ausführungsformen werden in der folgenden Beschreibung deutlich, die sich auf die beigefügten Zeichnungen bezieht.
- 1 ist ein Schema einer bevorzugten Ausführungsform des erfindungsgemäßen Computernetzwerks;
- 2 veranschaulicht die Schritte zum Aufbau einer gesicherten DTLS-Kommunikation unter Verwendung eines DALI-Sets.
-
1 zeigt schematisch eine Ausführungsform des erfindungsgemäßen Computernetzwerks (1), das ein Nicht-IP-Teilnetzwerk (2) mit Frontend-Geräten (4.1, 4.2, 4.3), die Sensoren und/oder Aktoren eines IoT-Systems sein können, und ein IP-Teilnetzwerk (3) mit einem Backend-Gerät (5), möglicherweise einer Cloud, umfasst. Ein Gateway (6) verbindet das Nicht-IP-Teilnetz (2) mit dem IP-Teilnetz (3) und übersetzt die Kommunikation dazwischen. Die Nicht-IP-Kommunikation (8.1, 8.2, 8.3) innerhalb des Nicht-IP-Teilnetzes (2) könnte auf der Digital Addressable Lighting Interface (DALI) basieren. In diesem Fall ist oder enthält das Gateway (6) einen DALI-Controller.
-
Ein IP-Sicherheitsprotokoll (9), das Mittel zur Authentifizierung und/oder Verschlüsselung bereitstellt, wird angewandt, um die Sicherheit der IP-Kommunikation (7) innerhalb des IP-Teilnetzes (3) zu wahren, wobei für die vorliegende Ausführungsform Datagram Transport Layer Security (DTLS) als IP-Sicherheitsprotokoll (9) gewählt wird. Erfindungsgemäß wird die sichere Kommunikation auf die Frontend-Geräte (4.1, 4.2, 4.3) innerhalb des Nicht-IP-Subnetzes (2) ausgedehnt, indem Datagramme der DTLS-Kommunikation unter Verwendung des Protokolls der Nicht-IP-Kommunikation (8.1, 8.2, 8.3), das bei der gezeigten Ausführungsform auf Standard-DALI-Befehlen basiert, huckepack genommen werden.
-
Für die sichere Ende-zu-Ende-Kommunikation (11) zwischen jedem der Frontend-Geräte (4.1, 4.2, 4.3) und dem Backend-Gerät (5) ist es möglich, eine symmetrische Verschlüsselung auf der Basis eines Paares von Pre-Shared Keys (17, 18) anzuwenden, die innerhalb eines jeweiligen Frontend-Gerätes (4.1, 4.2, 4.3) und des Backend-Gerätes (5) ausgetauscht und gespeichert werden. Die Generierung der Pre-Shared-Keys (17, 18) könnte bei der Herstellung des Frontend-Gerätes (4.1, 4.2, 4.3) erfolgen, wobei hier eine Programmierung mittels DALI oder eine spezifische Einstellung von Nadeladaptern vorgenommen werden kann und konsekutiv das Backend-Gerät (5) bei der Installation eines Frontend-Gerätes (4.1, 4.2, 4.3) innerhalb des Non-IP-Teilnetzes (2) seinen jeweiligen Teil des Schlüsselpaares auf einem separaten Kommunikationsweg, ggf. mittels drahtloser Kommunikation, erhält.
-
Um Sicherheitsrisiken im Zusammenhang mit dem Gateway (6) zu vermeiden, ist es erfindungsgemäß erforderlich, dass das Gateway (6) während des Handshaking-Verfahrens zum Aufbau einer sicheren Ende-zu-Ende-Kommunikation (11) zwischen einem der Frontend-Geräte (4.1, 4.2, 4.3) und dem Backend-Gerät (5) „transparent“ agiert. Das bedeutet, dass das Gateway (6) empfangene Datagramme, die als zum Aufbau einer sicheren Sitzung zwischen dem Backend-Gerät (5) und einem der Frontend-Geräte (4.1, 4.2, 4.3) gehörend identifiziert werden, nicht durch Extraktion des Dateninhalts und Generierung von DALI-Befehlen daraus übersetzt, sondern das jeweilige Datagramm zusätzlich zur DALI Non-IP Kommunikation (8.1, 8.2, 8.3) überträgt. Zu diesem Zweck stellt das Gateway (6) mindestens einen virtuellen IP-Kommunikationsendpunkt (10) zur Verfügung, wobei in der vorliegenden Ausführungsform der virtuelle IP-Kommunikationsendpunkt (10) eine virtuelle IP-Adresse (20) auf der Netzwerkschicht (L3) umfasst, die einem der Frontendgeräte (4.1, 4.2, 4.3) zugeordnet ist.
-
Da als IP-Sicherheitsprotokoll (9) DTLS verwendet wird, umfasst der virtuelle IP-Kommunikationsendpunkt (10) ferner einen dedizierten UDP-Socket (21) auf der Transportschicht (L2). Für die Zuordnung zu den Frontend-Geräten (4.1, 4.2, 4.3) könnte eine entsprechende Anzahl von dedizierten UDP-Sockets (21) (nicht dargestellt) zusammen mit einer Mapping-Tabelle (22), die die DALI-Adressdaten der Frontend-Geräte (4.1, 4.2, 4.3) enthält, verwendet werden. Alternativ wird das Gateway (6) mit einem einzigen dedizierten UDP-Socket (21) konfiguriert und ein Schema für dessen Multiplexing verwendet, das auf einem DTLS-Erweiterungsheader basiert, der Adressinformationen für die Durchführung der Non-IP-Kommunikation (8.1, 8.2, 8.3) mit einem ausgewählten der Frontend-Geräte (4.1, 4.2, 4.3) enthält.
-
Das Handshaking zum Aufbau einer sicheren Ende-zu-Ende-Kommunikation (11) zwischen einem der Frontend-Geräte (4.1, 4.2, 4.3) und dem Backend-Gerät (5) kann den Austausch von mehreren Datagrammen über ein „transparentes“ Gateway (6) umfassen. Im Folgenden wird der Einfachheit halber exemplarisch ein vom Backend-Gerät (5) initiierter Datagramm-Austausch beschrieben.
-
Nach dem Empfang eines Anfragedatagramms mit einem Header, der das Backend-Gerät (5) als Quelle und den virtuellen IP-Kommunikationsendpunkt (10) als Ziel angibt, wird die Non-IP-Kommunikation (8.1, 8.2, 8.3) angewendet, um eine Transkription des Anfragedatagramms an das jeweilige Frontend-Gerät (4.1, 4.2, 4.3) zu übertragen.
-
In der vorliegenden Ausführungsform wird das Anfragedatagramm von einem speziellen UDP-Socket (21) in Form eines Anforderungsrahmens empfangen. Die Transkription des Anfragedatagramms könnte das unveränderte ursprüngliche Anfragedatagramm oder eine Entkapselung desselben auf dem Stapel des OSI-Modells sein, beispielsweise ein Anfragedatenpaket. Erfindungsgemäß verändert das Gateway (6) den Dateninhalt des Request-Datagramms nicht. Insbesondere werden von dem Gateway (6) keine DALI-Befehle daraus abgeleitet. Stattdessen identifiziert das Gateway (6) anhand seiner Mapping-Tabelle (22) das Frontend-Gerät (4.1, 4.2, 4.3), zu dem die sichere Ende-zu-Ende-Kommunikation (11) aufgebaut werden soll, und speichert mit einem DALI-Schreibbefehl eine vollständige Transkription des Request-Datagramms in einem ersten reservierten Speicherbereich (23) des jeweiligen Frontend-Geräts (4.1, 4.2, 4.3).
-
In der vorliegenden Ausführungsform umfasst das Frontend-Gerät (4.1, 4.2, 4.3) eine Basisimplementierung des IP-Sicherheitsprotokolls (15) DTLS für die Interpretation der Transkription des Anfragedatagramms. Daher ist es in der Lage, ein Antwort-Datagramm unter Verwendung seiner eigenen Firmware und Speicherkapazität zu erstellen. Eine Transkription des Antwort-Datagramms könnte in einem zweiten reservierten Speicherbereich (24) des Frontend-Geräts (4.1, 4.2, 4.3) gespeichert werden, und ein dritter Speicherbereich (25) wird zur Darstellung von DTLS-Statusinformationen wie „Warten auf eine DTLS-Anfrage“, „Anfrage in Bearbeitung“ und „Antwort bereit“ verwendet. Letzteres ermöglicht es, eine Abholung der Transkription des Antwort-Datagramms durch das Gateway (6) auszulösen, wobei ein DALI-Lesebefehl verwendet wird, um das Piggy-Backing auf der Grundlage der Non-IP-Kommunikation in Rückwärtsrichtung zu realisieren.
-
Sobald das Gateway (6) die Transkription des Antwort-Datagramms erhält, bereitet es eine zweite Transkription davon vor, die an das Backend-Gerät (5) übertragen wird. Die sich daraus ergebende zweite Transkription des Antwort-Datagramms behält den Datenteil des vom Frontend-Gerät (4.1, 4.2, 4.3) empfangenen Originals unverändert bei. Es ist jedoch möglich, dass die Adressbehandlung vom Gateway zusammen mit einer Verkapselung auf dem Stapel durchgeführt wird. Daher kann das Gateway eine zweite Transkription mit einem modifizierten und/oder erweiterten Header zumindest auf einer Ebene gemäß dem OSI-Modell erzeugen, die den virtuellen IP-Kommunikationsendpunkt (10) als Quelle und das Backend-Gerät (5) als Ziel enthält.
-
2 zeigt die verschiedenen Schritte zum Aufbau einer DTLS-Kommunikation nach dem oben beschriebenen Konzept mit einem Pre-Share-Key für Feldgeräte, die eine DALI-basierte Kommunikation nutzen.
-
Wie erläutert, betrifft der erste Schritt S1 die Implementierung eines Pre-Shared Key PSK-1 im DALI-Gerät. Für die Zwecke dieses Beispiels ist jedes Gerät geeignet, das das DALI-Protokoll implementiert. Typische DALI-fähige Geräte sind z. B. LED-Treiber, intelligente Haushaltsgeräte und dergleichen. Der Pre-Shared Key wird in Schritt S2 auch dem Cloud-Backend zur Verfügung gestellt, mit dem sich das DALI-Gerät verbinden würde, wenn es in einer Installation mit einem Gateway eingesetzt wird. Bei der Bereitstellung wird ein anderer gesicherter Kommunikationskanal verwendet, um eine Kompromittierung des Pre-Shared Key zu vermeiden. Der Pre-Shared Key wird auch mit der Seriennummer des DALI-Geräts in der Cloud registriert.
-
In Schritt S3 erstellt der DALI-Controller eine Zuordnungstabelle, um DALI-Adressen (d. h. die Adressen der an den Controller angeschlossenen DALI-fähigen Geräte) mit zusätzlichen IP-Hostadressen zu verknüpfen. Das Cloud-Backend wird in Schritt S4 über die Geräte informiert. Wie hier beschrieben, ermöglicht dieser Prozess dem Cloud-Backend den Aufbau einer DTLS-Kommunikation (mit jedem DALI-Gerät), die auf IP aufsetzt.
-
In Schritt S5 wird eine sichere DTLS-Sitzung zwischen der Cloud-Backend-Lösung und dem als Gateway fungierenden DALI-Steuergerät aufgebaut. Wie oben beschrieben, wird jede Anforderung zum Aufbau einer solchen Verbindung vom DALI-Steuergerät auf eine DALI-Schreibanforderung abgebildet und an das jeweilige in der Anforderung adressierte DALI-Gerät weitergeleitet. Die Anfrage innerhalb der DALI-Nachricht wird also huckepack auf das DALI-Paket und den Rahmen gepackt.
-
Das DALI-Gerät verarbeitet die DTLS-Anfrage in Schritt S7. Zu diesem Zweck ordnet das DALI-Gerät die DTLS-Anfrage- und - Antwort-Frames auf Speicherbänke innerhalb des Geräts zu, wobei es Standard-DALI-Lese- und -Schreibbefehle verwendet. Jeder empfangene DTLS-Frame wird also in die Speicherbänke geschrieben. Drei Speicherbänke sind reserviert, eine erste für die Speicherung von DTLS-Rahmenanfragen, die eingehende DTLS-Anfragen vom DALI-Controller und -Gateway bearbeiten. Ein zweiter Speicher speichert DTLS-Antworten auf die verarbeiteten Anfragen. Schließlich wird eine dritte Speicherbank verwendet, um eine Statusanzeige mit einem einfachen Ein-Byte-Status zu liefern:
- - Status 0: Warten auf DTLS-Anfrage;
- - Status 1: Anfrage in Bearbeitung; und
- - Status 2: Antwort bereit
-
Während des Handshakes und nach dessen Abschluss, der zu einer sicheren Ende-zu-Ende-Kommunikation zwischen dem Backend-Gerät (5) und einem der Frontend-Geräte (4.1, 4.2, 4.3) führt, kann das Gateway (6) nicht in den Besitz des Sitzungsschlüssels gelangen, der jedes Mal geändert wird, wenn eine neue sichere Sitzung erzeugt wird.
-
Als Alternative, die nicht gezeigt wird, wird die Anforderung, das DTLS-IP-Sicherheitsprotokoll (15) innerhalb des Frontend-Geräts (4.1, 4.2, 4.3) zu implementieren, erleichtert, was insbesondere für sehr einfache Frontend-Geräte (4.1, 4.2, 4.3) mit begrenztem persistenten Speicher von Vorteil ist. Dies wird erreicht, indem dem Backend-Gerät (5) eine zusätzliche Funktionalität hinzugefügt wird, die in diesem Fall DALI-Befehle einer Anwendungsschicht (16) des Frontend-Geräts (4.1, 4.2, 4.3) unterstützen muss. Dies ermöglicht es, die Aktionen des Frontend-Gerätes (4.1, 4.2, 4.3) zur Abwicklung des Handshakes aus der Ferne zu steuern, da das Backend-Gerät (5) in der Lage ist, Steuerdatagramme, die direkt ausführbare DALI-Befehle kapseln, an das Frontend-Gerät (4.1, 4.2, 4.3) zu senden. Das Gateway (6) wiederum ist so konfiguriert, dass es unter Anwendung der Non-IP-Kommunikation (8.1, 8.2, 8.3) eine Transkription des Steuerdatagramms an das Frontendgerät (4.1, 4.2, 4.3) sendet.
-
Außerdem könnte die oben beschriebene symmetrische Verschlüsselung durch eine asymmetrische Verschlüsselung ersetzt werden. Der Rechenaufwand für die Handhabung der vorgeschriebenen Zertifikate führt jedoch zu einer bevorzugten Ausführungsform, bei der ein Verschlüsselungschip (19) hinzugefügt wird, wie für das Frontend-Gerät (4.2) gezeigt.
-
Bezugszeichenliste
-
- 1
- Computernetzwerk
- 2
- Nicht-IP-Teilnetz
- 3
- IP-Teilnetz
- 4.1, 4.2, 4.3
- Frontend-Gerät
- 5
- Backend-Gerät
- 6
- Gateway
- 7
- IP-Kommunikation
- 8.1, 8.2, 8.3
- Nicht-IP-Kommunikation
- 9
- IP-Sicherheitsprotokoll
- 10
- virtueller IP-Kommunikationsendpunkt
- 11
- sichere Ende-zu-Ende-Kommunikation
- 15
- Implementierung des IP-Sicherheitsprotokolls
- 16
- Anwendungsschicht
- 17
- Pre-Shared Key
- 18
- gemeinsamer Vorab-Schlüssel
- 19
- Verschlüsselungschip
- 20
- virtuelle IP-Adresse
- 21
- dedizierter UDP-Socket
- 22
- Mapping-Tabelle
- 23
- erster reservierter Speicherbereich
- 24
- zweiter reservierter Speicherbereich
- 25
- dritter reservierter Speicherbereich
-
ZITATE ENTHALTEN IN DER BESCHREIBUNG
-
Diese Liste der vom Anmelder aufgeführten Dokumente wurde automatisiert erzeugt und ist ausschließlich zur besseren Information des Lesers aufgenommen. Die Liste ist nicht Bestandteil der deutschen Patent- bzw. Gebrauchsmusteranmeldung. Das DPMA übernimmt keinerlei Haftung für etwaige Fehler oder Auslassungen.
-
Zitierte Patentliteratur
-
- CN 211180606 U [0004]
- US 20080265799 A [0004]
- WO 20160075107 A [0004]
- WO 2015/054611 [0004]
- EP 3525555 A [0004]
- US 8837485 B2 [0007]
