DE102021125836A1 - Computernetzwerk für sichere ip-zu-nicht-ip-kommunikation und backend-gerät, gateway, frontend-gerät dafür und verfahren zu dessen betrieb - Google Patents

Computernetzwerk für sichere ip-zu-nicht-ip-kommunikation und backend-gerät, gateway, frontend-gerät dafür und verfahren zu dessen betrieb Download PDF

Info

Publication number
DE102021125836A1
DE102021125836A1 DE102021125836.7A DE102021125836A DE102021125836A1 DE 102021125836 A1 DE102021125836 A1 DE 102021125836A1 DE 102021125836 A DE102021125836 A DE 102021125836A DE 102021125836 A1 DE102021125836 A1 DE 102021125836A1
Authority
DE
Germany
Prior art keywords
gateway
handshaking
communication
backend
subnet
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Pending
Application number
DE102021125836.7A
Other languages
English (en)
Inventor
Jiye Park
Prajosh Premdas
Markus Jung
Bernhard Siessegger
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
OPTOTRONIC GMBH, DE
Original Assignee
Osram GmbH
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Osram GmbH filed Critical Osram GmbH
Publication of DE102021125836A1 publication Critical patent/DE102021125836A1/de
Pending legal-status Critical Current

Links

Images

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/04—Network architectures or network communication protocols for network security for providing a confidential data exchange among entities communicating through data packet networks
    • H04L63/0428—Network architectures or network communication protocols for network security for providing a confidential data exchange among entities communicating through data packet networks wherein the data content is protected, e.g. by encrypting or encapsulating the payload
    • H04L63/0435—Network architectures or network communication protocols for network security for providing a confidential data exchange among entities communicating through data packet networks wherein the data content is protected, e.g. by encrypting or encapsulating the payload wherein the sending and receiving network entities apply symmetric encryption, i.e. same key used for encryption and decryption
    • H—ELECTRICITY
    • H05—ELECTRIC TECHNIQUES NOT OTHERWISE PROVIDED FOR
    • H05B—ELECTRIC HEATING; ELECTRIC LIGHT SOURCES NOT OTHERWISE PROVIDED FOR; CIRCUIT ARRANGEMENTS FOR ELECTRIC LIGHT SOURCES, IN GENERAL
    • H05B47/00—Circuit arrangements for operating light sources in general, i.e. where the type of light source is not relevant
    • H05B47/10—Controlling the light source
    • H05B47/175—Controlling the light source by remote control
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/02—Network architectures or network communication protocols for network security for separating internal from external traffic, e.g. firewalls
    • H04L63/029—Firewall traversal, e.g. tunnelling or, creating pinholes
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/04—Network architectures or network communication protocols for network security for providing a confidential data exchange among entities communicating through data packet networks
    • H04L63/0428—Network architectures or network communication protocols for network security for providing a confidential data exchange among entities communicating through data packet networks wherein the data content is protected, e.g. by encrypting or encapsulating the payload
    • H04L63/0442—Network architectures or network communication protocols for network security for providing a confidential data exchange among entities communicating through data packet networks wherein the data content is protected, e.g. by encrypting or encapsulating the payload wherein the sending and receiving network entities apply asymmetric encryption, i.e. different keys for encryption and decryption
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/08—Network architectures or network communication protocols for network security for authentication of entities
    • H04L63/0823—Network architectures or network communication protocols for network security for authentication of entities using certificates
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/16—Implementing security features at a particular protocol layer
    • H04L63/166—Implementing security features at a particular protocol layer at the transport layer
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/20—Network architectures or network communication protocols for network security for managing network security; network security policies in general
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L12/00—Data switching networks
    • H04L12/28—Data switching networks characterised by path configuration, e.g. LAN [Local Area Networks] or WAN [Wide Area Networks]
    • H04L12/46—Interconnection of networks
    • H04L12/4633—Interconnection of networks using encapsulation techniques, e.g. tunneling

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Security & Cryptography (AREA)
  • Computer Hardware Design (AREA)
  • Computing Systems (AREA)
  • General Engineering & Computer Science (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Data Exchanges In Wide-Area Networks (AREA)
  • Small-Scale Networks (AREA)

Abstract

Die Erfindung betrifft ein Computernetzwerk, umfassend:ein Nicht-IP-Teilnetz mit mindestens einem Frontend-Gerät; undein IP-Teilnetz mit mindestens einem Backend-Gerät; und ein Gateway, das das Nicht-IP-Teilnetz mit dem IP-Teilnetz verbindet und die Kommunikation dazwischen übersetzt, wobei die Kommunikation zwischen dem Backend-Gerät und dem Gateway eine IP-Kommunikation ist, die auf einem IP-Sicherheitsprotokoll basiert und 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. wobei das Gateway so konfiguriert ist, dass es Handshaking zum Aufbau eines sicheren Tunnels für eine sichere Ende-zu-Ende-Kommunikation zwischen dem Backend-Gerät und dem Frontend-Gerät vermittelt, wobei der sichere Tunnel so eingestellt ist, dass er einen Sitzungsschlüssel anwendet; und wobei das Gateway und das Backend-Gerät so konfiguriert sind, dass sie Datagramme mit Handshaking-Parametern austauschen; wobei das Gateway und das Frontend-Gerät so konfiguriert sind, dass sie Non-IP-Nachrichten mit einer Teilmenge der Handshaking-Parameter austauschen; undwobei das Backend-Gerät so konfiguriert ist, dass es den Sitzungsschlüssel erzeugt und das Handshaking unter Einbeziehung der Handshaking-Parameter authentifiziert;wobei das Frontend-Gerät so konfiguriert ist, dass es den Sitzungsschlüssel erzeugt und das Handshaking authentifiziert,das die Teilmenge der Handshaking-Parameter enthält;wobei das Gateway so konfiguriert ist, dass es nicht in der Lage ist, den Sitzungsschlüssel aus den Handshaking-Parametern zu erzeugen.

Description

  • Die vorliegende Patentanmeldung nimmt die Priorität der Dänischen Anmeldung 202070676 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.
  • 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.
  • Eine Möglichkeit, die Vertrauenswürdigkeit eines Nicht-IP-Teilnetzes zu erhöhen, ist die Hop-by-Hop-Authentifizierung und die Verschlüsselung der zwischen dem Frontend-Gerät und dem Gateway ausgetauschten Nachrichten mit Hilfe 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, es ermöglichen würde, den neuen Sitzungsschlüssel aus den bekannten Informationen der vorherigen Sitzung zu rekonstruieren.
  • 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 über einen Tunnel 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 das Gateway so konfiguriert sein sollte, dass es ein Handshaking vermittelt zum Aufbau eines Tunnels für eine sichere Ende-zu-Ende-Kommunikation zwischen dem Backend-Gerät und dem Frontend-Gerät. Der sichere Tunnel verwendet einen Sitzungsschlüssel, der vom Frontend-Gerät und dem Backend-Gerät während des Handshakens generiert wird, wobei das Gateway selbst nicht in den Besitz des Sitzungsschlüssels gelangt.
  • Zu diesem Zweck sind das Gateway und das Backend-Gerät so konfiguriert, dass sie Datagramme mit Handshaking-Parametern unter Verwendung von IP-Kommunikation austauschen, und wobei das Gateway und das Frontend-Gerät so konfiguriert sind, dass sie Non-IP-Nachrichten mit einer Teilmenge der Handshaking-Parameter austauschen. Vorzugsweise umfasst die Teilmenge der Handshaking-Parameter eine erste, vom Gateway generierte Zufallszahl und eine zweite, vom Backend-Gerät generierte Zufallszahl, die in Kombination mit einer geheimen Verschlüsselungsinformation verwendet werden, um den Sitzungsschlüssel auf der Seite des Frontend-Geräts und auf der Seite des Backend-Geräts zu generieren.
  • Für das Backend-Gerät tritt das Gateway als vollwertiger Handshaking-Partner auf, der IP-basierte Datagramme für die gewählte sichere Ende-zu-Ende-Kommunikation und das verwendete Verschlüsselungsverfahren bereitstellt. Insbesondere überträgt das Gateway verifizierte Zufallszahlen und/oder öffentliche Zertifikate an das Backend-Gerät anstelle des Frontend-Geräts und übersetzt die vom Backend empfangenen obligatorischen Handshaking-Daten in die Non-IP-Kommunikation, um die obligatorischen Informationen an das Frontend-Gerät weiterzuleiten.
  • Darüber hinaus ist das Frontend-Gerät als der eigentliche End-to-End-Sicherheits-Peer des Backend-Geräts vom vollständigen Handshaking-Verfahren abgeschirmt, und das Gateway stellt ihm nur die obligatorische Teilmenge der Handshaking-Parameter zur Verfügung, die erforderlich ist, damit das Frontend-Gerät seinen Anteil an den obligatorischen Handshaking-Informationen generieren kann.
  • Die Handshaking-Vermittlung des Gateways ermöglicht es dem Backend-Gerät, den Sitzungsschlüssel zu erzeugen und das Handshaking unter Einbeziehung der Handshaking-Parameter zu authentifizieren.
  • Darüber hinaus ist das Frontend-Gerät so konfiguriert, dass es den Sitzungsschlüssel generiert und das Handshaking authentifiziert, das die vom Gateway bereitgestellte Teilmenge der Handshaking-Parameter enthält.
  • Obwohl das Gateway alle Handshaking-Nachrichten verarbeitet, ist es nicht in der Lage, daraus einen Sitzungsschlüssel zu generieren. Dem Gateway fehlen die geheimen Verschlüsselungsinformationen, die erforderlich sind, um den Dateninhalt der Teilmenge der Handshaking-Parameter korrekt zu interpretieren. In einer beispielhaften Ausführungsform wird die sichere Ende-zu-Ende-Kommunikation zwischen dem Backend-Gerät und dem Frontend-Gerät mit symmetrischer Verschlüsselung aufgebaut, die Pre-Shared Keys als geheime Verschlüsselungsinformationen erfordert. Deren Austausch zwischen dem Frontend-Gerät und dem Backend-Gerät könnte zum Zeitpunkt der Herstellung des Frontend-Geräts erfolgen, wobei das Gateway vom Schlüsselaustausch ausgeschlossen ist. 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 jedes Mal geändert wird, wenn eine neue sichere Sitzung aufgebaut wird. Dies bietet zusätzliche Sicherheit im Falle einer unterbrochenen Sitzung, da nicht alle zukünftigen Sitzungen gefährdet sind.
  • Als mögliche Alternative wird für die sichere Ende-zu-Ende-Kommunikation zwischen dem Backend-Gerät und dem Frontend-Gerät eine asymmetrische Verschlüsselung eingesetzt, die zertifikatsbasiert ist. Dabei ist das Gateway nicht im Besitz der geheimen Verschlüsselungsinformationen, nämlich der privaten Schlüssel der Kommunikationspartner (Frontend-Gerät und Backend-Gerät). Es ist jedoch vorteilhaft, das Gateway so zu konfigurieren, dass es in der Lage ist, ein Zertifikat oder einen anderen öffentlichen Schlüssel des Frontend-Geräts im Verlauf des Handshaking-Verfahrens zu handhaben, um den Dateninhalt der Teilmenge der Handshaking-Parameter, die zwischen dem Frontend-Gerät und dem Gateway ausgetauscht werden muss, zu begrenzen.
  • Im Folgenden wird davon ausgegangen, dass das Frontend-Gerät das Handshaking einleitet, indem es eine Non-IP-Request-Nachricht an das Gateway sendet. Dies ist jedoch nicht zwingend erforderlich und soll die Erfindung nicht einschränken, da das Handshaking auch durch das Backend-Gerät ausgelöst werden könnte. Außerdem hängt das spezifische Handshaking-Verfahren von dem gewählten IP-Sicherheitsprotokoll ab. Was die bevorzugte Wahl von TLS und DTLS als IP-Sicherheitsprotokoll betrifft, so werden diesbezüglich weitere Einzelheiten weiter unten offengelegt. 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 Non-IP-Kommunikation ein. Gemäß einigen Aspekten basiert die Non-IP-Kommunikation auf der Digital Addressable Lighting Interface (DALI). 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 anwendet. Darüber hinaus könnte ein Frontend-Gerät eine benutzerdefinierte Anwendungsschicht aufweisen, die einen Satz von Befehlen für seinen Betrieb bereitstellt.
  • Ein erfindungsgemäßes Frontend-Gerät erfordert nicht notwendigerweise eine Hardware-Modifikation, was insbesondere für einfache Frontend-Geräte von Vorteil ist. Bei einigen Ausführungsformen muss lediglich die Firmware so modifiziert werden, dass das Frontend-Gerät eine begrenzte Implementierung des IP-Sicherheitsprotokolls ausführen kann, die zumindest in der Lage ist, die Teilmenge der Handshaking-Parameter zu verarbeiten, insbesondere im Hinblick auf die obligatorischen Verifizierungsschritte auf Seiten des Frontend-Geräts. Die begrenzte Implementierung des IP-Sicherheitsprotokolls deckt auch die Fähigkeit des Frontend-Geräts ab, seinen Anteil an den obligatorischen Handshaking-Informationen zu generieren, die vom Gateway unter Verwendung der vollständigen Implementierung des IP-Sicherheitsprotokolls und der IP-Kommunikation übersetzt, verarbeitet und an das Backend-Gerät weitergeleitet werden.
  • Bei einigen weiteren Aspekten werden Maßnahmen ergriffen, um die Rechenlast auf der Seite des Frontend-Geräts zu verringern. Dies könnte durch eine Ausführungsform erreicht werden, bei der das Frontend-Gerät nicht selbst eine begrenzte Implementierung des IP-Sicherheitsprotokolls ausführt. Stattdessen wird die Interpretation und Handhabung der Teilmenge der vom Gateway bereitgestellten Handshaking-Parameter vom Backend-Gerät gesteuert. Zu diesem Zweck ist das Backend-Gerät so konfiguriert, dass es direkt ausführbare Befehle der Anwendungsschicht des Frontend-Geräts, z. B. DALI-Befehle, bereitstellt, um Aktionen des Frontend-Geräts zu steuern. Auf diese Weise kann ein einfaches Frontend-Gerät ohne zusätzliche Anforderungen an den permanenten Speicher gehalten werden.
  • Sobald die sichere Ende-zu-Ende-Kommunikation zwischen dem Backend-Gerät und dem Frontend-Gerät hergestellt ist, kann das Gateway die Kommunikation nicht abhören oder deren Inhalt verändern, da es nicht im Besitz des erforderlichen Sitzungsschlüssels ist. Außerdem ist ein Man-in-the-Middle-Angriff (MITM) nicht möglich. Vorzugsweise werden weitere Maßnahmen ergriffen, um einen Replay-Angriff zu verhindern. Dies wird erreicht, indem das Frontend-Gerät und das Backend-Gerät so konfiguriert werden, dass sie Zeitstempel für über den sicheren Tunnel gesendete Nachrichten bereitstellen und die Zeitstempel von aus dem sicheren Tunnel empfangenen Nachrichten kontrollieren. Dadurch kann eine doppelte Nachricht mit demselben Zeitstempel und demselben Dateninhalt wie eine frühere Nachricht erkannt und verworfen werden. Um den Speicherbedarf zu verringern, ist es außerdem vorzuziehen, ein gleitendes Zeitfenster für die Annahme einer Nachricht zu verwenden.
  • Ein weiterer Vorteil der vorliegenden Erfindung ergibt sich aus dem Umstand, dass bei einigen Ausführungsformen keine Notwendigkeit besteht, Hardwarekomponenten des Frontend-Geräts, des Gateways und/oder des Backend-Geräts zu ändern. Eine bevorzugte Ausführungsform wird durch eine einfache Modifikation der Firmware erreicht.
  • Bevorzugte Ausführungsformen werden aus der folgenden Beschreibung ersichtlich, die sich auf die beigefügten Zeichnungen bezieht.
    • 1 ist ein Schema einer bevorzugten Ausführungsform des erfindungsgemäßen Computernetzwerks.
    • 2 zeigt eine Ausführungsform des erfindungsgemäßen Verfahrens unter Anwendung symmetrischer Verschlüsselung.
    • 3 zeigt eine Ausführungsform des erfindungsgemäßen Verfahrens, bei der eine asymmetrische Verschlüsselung angewendet wird.
  • 1 zeigt schematisch eine Ausführungsform des erfindungsgemäßen Computernetzwerks 1, das ein Non-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 Non-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 dem Digital Addressable Lighting Interface (DALI) basieren. In diesem Fall ist das Gateway 6 ein DALI-Controller. Ein IP-Sicherheitsprotokoll 9, das Mittel zur Authentifizierung und/oder Verschlüsselung bereitstellt, wird angewendet, um die Sicherheit der IP-Kommunikation 7 innerhalb des IP-Teilnetzes 3 zu gewährleisten, wobei Transport Layer Security (TLS) oder Datagram Transport Layer Security (DTLS) die bevorzugte Wahl für das IP-Sicherheitsprotokoll 9 sind.
  • Erfindungsgemäß ist das Gateway 6 so konfiguriert, dass es ein Handshaking zum Aufbau eines sicheren Tunnels 10 für eine sichere Ende-zu-Ende-Kommunikation 11 zwischen dem Backend-Gerät 5 und dem Frontend-Gerät 4.1, 4.2, 4.3 vermittelt. Die Kommunikationspartner Frontend-Gerät 4.1, 4.2, 4.3 und Backend-Gerät 5 stützen sich auf einen während des Handshaking generierten Sitzungsschlüssel 12, der dem Gateway 6 unbekannt bleibt.
  • Sobald das Handshaking ausgelöst wird, möglicherweise von Seiten des Frontend-Geräts 4.1, 4.2, 4.3, tauscht das Gateway 6 Datagramme, die Dateninhalte mit Handshaking-Parametern 13 enthalten, mit dem Backend-Gerät 5 aus. Zusätzlich sind das Gateway 6 und das Frontend-Gerät 4.1, 4.2, 4.3 so konfiguriert, dass sie Non-IP-Nachrichten mit einer Teilmenge der Handshaking-Parameter 14 austauschen.
  • Im Verlauf des Handshaking sind die Non-IP-Nachrichten vom Gateway 6 an das Frontend-Gerät 4.1, 4.2, 4.3 auf die Informationen beschränkt, die notwendig sind, um dem Frontend-Gerät 4.1, 4.2, 4.3 zu ermöglichen, obligatorische Sitzungsaufbaunachrichten auf der Grundlage von Berechnungen zu generieren, die Informationen einbeziehen, die vom Gateway 6 in einem der vorherigen Schritte des Handshaking empfangen wurden, und die außerdem gespeicherte geheime Verschlüsselungsinformationen einbeziehen, die dem Frontend-Gerät 4.1, 4.2, 4.3 bzw. dem Backend-Gerät 5 gehören. Diese Nachrichten zum Sitzungsaufbau werden vom Gateway 6 in den nachfolgenden Schritten des Handshaking mit den bereits vorhandenen Handshaking-Parametern der vorangegangenen Schritte konsolidiert. Auf dieser Grundlage wird der gesamte Satz von Handshaking-Nachrichten, der für das gewählte IP-Sicherheitsprotokoll 9, vorzugsweise TLS oder DTLS, zum Aufbau des sicheren Tunnels 10 erforderlich ist, zwischen dem Gateway 6 und dem Backend-Gerät 5 ausgetauscht. Daher fungiert das Gateway während des Handshakens als Kommunikationspartner des Backend-Geräts 5, ohne der eigentliche End-to-End-Sicherheitspartner zu sein, der das Frontend-Gerät 4.1, 4.2, 4.3 ist.
  • Das Frontend-Gerät 4.1, 4.2, 4.3 ist so konfiguriert, dass es den Sitzungsschlüssel generiert und das Handshaking authentifiziert, wobei es die Teilmenge der Handshaking-Parameter einbezieht, die über die Nicht-IP-Kommunikation 8.1 vom Gateway 6 empfangen wurde. Das Backend-Gerät 5 ist so konfiguriert, dass es den Sitzungsschlüssel generiert und das Handshaking authentifiziert, indem es die Handshaking-Parameter aus den über die IP-Kommunikation 7 mit dem Gateway 6 ausgetauschten Handshaking-Nachrichten übernimmt. Das Gateway 6 ist jedoch so konfiguriert, dass es nicht in der Lage ist, den Sitzungsschlüssel aus den Handshaking-Parametern zu erzeugen, da ihm die geheimen Verschlüsselungsinformationen fehlen, die erforderlich sind, um den Dateninhalt zumindest der Teilmenge der Handshaking-Parameter korrekt zu interpretieren.
  • In der vorliegenden beispielhaften Ausführungsform wird die sichere Ende-zu-Ende-Kommunikation 11 zwischen dem Backend-Gerät 5 und dem Frontend-Gerät 4.1, 4.2, 4.3 mit symmetrischer Verschlüsselung aufgebaut, die Pre-Shared Keys 17, 18 als geheime Verschlüsselungsinformationen benötigt. Eine mögliche Methode zur Durchführung des darauf basierenden Handshaking unter Verwendung von DTLS als IP-Sicherheitsprotokoll 9 ist in dargestellt.
    Während der Handshake-Initiation 21 sendet das Frontend-Gerät 4.1 eine Anforderungsnachricht mit Informationen über den Cloud-Domain-Namen oder die IP-Adresse des Backend-Geräts 5.
    Die von der Nicht-IP-Kommunikation 8.1 gesendete Anforderungsnachricht kann eine Cipher-Suit-Liste enthalten, wenn das Gerät nur bestimmte Cipher-Suits für das Key-Sharing unterstützt. Die Handshake-Einleitung wird vom Gateway 6 bestätigt.
  • Als nächster Schritt beginnt das Handshaking zwischen den Kommunikationspartnern Gateway 6 und Backend-Gerät 5 mit einer Client-Hello-Nachricht 22 vom Gateway 6, die vom Backend-Gerät 5 mit einer Verifizierungsnachricht beantwortet wird, die ein Cookie enthält. Anschließend generiert das Gateway 6 eine erste Zufallszahl und sendet sie an das Backend-Gerät 5, das mit einer zweiten Zufallszahl antwortet, um den Zufallszahlenaustausch 23 zu beenden, zusammen mit der Statusinformation, dass es auf die Folgemeldung des Gateways 6 wartet.
  • Die erste Zufallszahl und die zweite Zufallszahl gehören zur Teilmenge der Handshaking-Parameter 14, da sie für die Generierung des Sitzungsschlüssels erforderlich sind. Daher wird eine Non-IP-Nachricht mit den Informationen über die Zufallszahlen 24 vom Gateway 6 an das Frontend-Gerät 4.1 weitergeleitet. Nach deren Empfang sendet die begrenzte Implementierung 15 des IP-Sicherheitsprotokolls 9 im Frontend-Gerät 4.1 eine Kennung für die Pre-Shared Keys 17, 18 als Schlüsselidentifikationsschritt 25, damit das Backend-Gerät 5 in der Lage ist, den richtigen Pre-Shared Key 18 zu finden. Basierend auf diesen Informationen führt das Gateway 6 einen Schlüsselidentitätsschritt 26 durch, der bei DTLS als Senden einer ClientKeyExchange / ChangeCipherSpec-Nachricht an das Backend-Gerät 5 adressiert ist. Zusätzlich sendet das Gateway 6 eine Hash-Handshake-Nachricht 27 an das Frontend-Gerät 4.1, in der die Teilmenge der Handshaking-Parameter 14 zusammengefasst ist, die für die Sitzungsschlüsselgenerierung auf beiden Seiten des Tunnels 10 verwendet wird. Damit kann das Frontend-Gerät 4.1 die Integrität des gesamten vom Gateway 6 vermittelten Handshake-Prozesses überprüfen. Als positive Antwort sendet das Frontend-Gerät 4.1 eine Bestätigungsnachricht 28 mit „verify -data“ als Inhalt, die einer entsprechenden Client-Nachricht vom Gateway 6 an das Backend-Gerät 5 hinzugefügt wird. Als Handshake-Erfüllungsschritt 29 sendet das Backend-Gerät 5 eine „ChangeCipherSpec Finished“ mit dem Inhalt „verity_data(server)“, die in eine entsprechende Non-IP-Nachricht an das Frontend-Gerät 4.1 übersetzt wird. Nun sind sowohl das Frontend-Gerät 4.1 als auch das Backend-Gerät 5 in der Lage, den Sitzungsschlüssel für die sichere Ende-zu-Ende-Kommunikation 11 zu erzeugen, während das Gateway 6 nicht im Besitz des Sitzungsschlüssels ist.
  • Der Austausch der Initialschlüssel 17, 18 für die symmetrische Verschlüsselung zwischen dem Frontend-Gerät 4.1 und dem Backend-Gerät 5 könnte bereits bei der Herstellung des Frontend-Geräts 4.1 erfolgen, wobei das Gateway 6 vom Schlüsselaustausch ausgeschlossen ist. Auch wenn 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 jeder 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.
  • Bei einer alternativen Ausführungsform wird für die sichere Ende-zu-Ende-Kommunikation 11 zwischen dem Backend-Gerät 5 und dem Frontend-Gerät 4.1 eine asymmetrische Verschlüsselung verwendet, die auf einem Zertifikat basiert. zeigt eine Illustration davon, wobei die gleichen Referenznummern für Verfahrensschritte wie bei der oben beschriebenen Ausführungsform verwendet werden.
  • Es wird ein Zufallszahlen- und Zertifikatsaustausch 30 durchgeführt, wobei das Zertifikat dem Backend-Gerät 5 zugeordnet wird und eine erste Zufallszahl vom Gateway 6 und eine zweite Zufallszahl vom Backend-Gerät 5 erzeugt wird.
  • Diese Informationen, die zur obligatorischen Teilmenge der Handshaking-Parameter 14 gehören, werden mit dem Verfahrensschritt 31 an das Frontend-Gerät 4.1 übermittelt. Dies ermöglicht es dem Frontend-Gerät 4.1, ein Pre-Master-Geheimnis zu generieren und mit dem öffentlichen Schlüssel des Backend-Geräts 5 zu verschlüsseln, wie die Pre-Master-Geheimnachricht 32 zeigt. Daraufhin sendet das Gateway 6 eine ClientKeyExchange-Nachricht 33, die das Pre-Master-Secret und das Zertifikat des Frontend-Geräts 4.1 enthält. Die folgenden Nachrichten ähneln den oben erläuterten Schritten zur Verifizierung und Quittierung, abgesehen von der hinzugefügten zweiten Hash-Nachricht 34. Ihr Zweck ist es, eine Verifizierung und Authentifizierung der oben erwähnten Schritte zu ermöglichen, bevor sowohl das Frontend-Gerät 4.1 als auch das Backend-Gerät 5 den Sitzungsschlüssel für die sichere Ende-zu-Ende-Kommunikation 11 zwischen ihnen anwenden.
  • Das Gateway 6, das nicht im Besitz der geheimen Verschlüsselungsinformationen ist, nämlich der privaten Schlüssel, die ausschließlich den Kommunikationspartnern gehören, ist nicht in der Lage, den Sitzungsschlüssel abzuleiten, der jedes Mal geändert wird, wenn eine neue sichere Sitzung erzeugt wird.
  • 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
    sicherer Tunnel
    11
    sichere Ende-zu-Ende-Kommunikation
    12
    Sitzungsschlüssel
    13
    Handshaking-Parameter
    14
    Teilmenge der Handshaking-Parameter
    15
    begrenzte Implementierung
    16
    Anwendungsschicht
    17
    Pre-Shared Key
    18
    gemeinsamer Vorab-Schlüssel
    21
    Handshake-Einleitung
    22
    Client-Hallo-Nachricht
    23
    Austausch von Zufallszahlen
    24
    Informationen über Zufallszahlen
    25
    Schritt der Schlüsselidentifikation
    26
    Schritt der Schlüsselidentität
    27
    Hash-Handshake-Nachricht
    28
    Bestätigungsnachricht
    29
    Schritt der Handshake-Erfüllung
    30
    Austausch von Zufallszahlen und Zertifikaten
  • 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
    • DK 202070676 [0001]
    • US 8837485 B2 [0005]

Claims (15)

  1. Computernetz für sichere IP-zu-Nicht-IP-Kommunikation, bestehend aus: ein Non-IP-Teilnetz (2) mit mindestens einem Frontend-Gerät (4.1, 4.2, 4.3); und ein IP-Teilnetz (3) mit mindestens einem Backend-Gerät (5); und ein Gateway (6), das das Nicht-IP-Teilnetz (2) mit dem IP-Teilnetz (3) verbindet und die Kommunikation dazwischen überträgt, wobei die Kommunikation zwischen dem Backend-Gerät (5) und dem Gateway (6) eine IP-Kommunikation (7) ist, die auf einem IP-Sicherheitsprotokoll (9) basiert, das Mittel zur Authentifizierung und/oder Verschlüsselung bereitstellt; und wobei die Kommunikation zwischen dem Gateway (6) und dem Frontend-Gerät (4.1, 4.2, 4.3) eine Nicht-IP-Kommunikation (8.1, 8.2, 8.3) ist; dadurch gekennzeichnet, dass das Gateway (6) so konfiguriert ist, dass es ein Handshaking vermittelt zum Aufbau eines sicheren Tunnels (10) für eine sichere Ende-zu-Ende-Kommunikation (11) zwischen dem Backend-Gerät (5) und dem Frontend-Gerät (4.1, 4.2, 4.3), wobei der sichere Tunnel (10) so eingestellt ist, dass er einen Sitzungsschlüssel anwendet; und wobei das Gateway (6) und das Backend-Gerät (5) so konfiguriert sind, dass sie Datagramme mit Handshaking-Parametern austauschen; und und wobei das Gateway (6) und das Frontend-Gerät (4.1, 4.2, 4.3) so konfiguriert sind, dass sie Non-IP-Nachrichten mit einer Teilmenge der Handshaking-Parameter (14) austauschen; und wobei das Backend-Gerät (5) so konfiguriert ist, dass es den Sitzungsschlüssel erzeugt und das Handshaking unter Einbeziehung der Handshaking-Parameter (13) authentifiziert; und wobei das Frontend-Gerät (4.1, 4.2, 4.3) so konfiguriert ist, dass sie den Sitzungsschlüssel erzeugt und das Handshaking authentifiziert, das die Teilmenge der Handshaking-Parameter (14) enthält; und wobei das Gateway (6) so konfiguriert ist, dass es nicht in der Lage ist, den Sitzungsschlüssel aus den Handshaking-Parametern (13) zu erzeugen.
  2. Computernetzwerk nach Anspruch 1, dadurch gekennzeichnet, dass die Teilmenge der Handshaking-Parameter (14) eine erste Zufallszahl, die von dem Gateway (6) erzeugt wird, und eine zweite Zufallszahl, die von dem Backend-Gerät (5) erzeugt wird, umfasst.
  3. Computernetzwerk nach einem der vorhergehenden Ansprüche, dadurch gekennzeichnet, dass das IP-Sicherheitsprotokoll (9) so eingestellt ist, dass es eine symmetrische Verschlüsselung auf der Grundlage von Schlüsseln (17, 18) anwendet, die zwischen dem Frontend-Gerät (4.1, 4.2, 4.3) und dem Backend-Gerät (5) vorab ausgetauscht werden.
  4. Computernetzwerk nach einem der vorhergehenden Ansprüche, dadurch gekennzeichnet, dass das IP-Sicherheitsprotokoll (9) so eingestellt ist, dass es eine asymmetrische Verschlüsselung anwendet, wobei das Gateway (6) so konfiguriert ist, dass es ein Zertifikat des Frontend-Geräts (4.1, 4.2, 4.3) verarbeitet.
  5. Computernetzwerk nach einem der vorhergehenden Ansprüche, dadurch gekennzeichnet, dass das IP-Sicherheitsprotokoll (9) Transport Layer Security (TLS) oder Datagram Transport Layer Security (DTLS) oder Secure Sockets Layer (SSL) oder Internet Protocol Security (IPsec) ist.
  6. Computernetzwerk nach einem der vorhergehenden Ansprüche, dadurch gekennzeichnet, dass die Nicht-IP-Kommunikation (8.1, 8.2, 8.3) auf Digital Addressable Lighting Interface (DALI) basiert.
  7. Computernetzwerk nach einem der vorhergehenden Ansprüche, dadurch gekennzeichnet, dass das Frontend-Gerät (4.1, 4.2, 4.3) und das Backend-Gerät (5) so konfiguriert sind, dass sie Zeitstempel für über den sicheren Tunnel (10) gesendete Nachrichten bereitstellen und die Zeitstempel von aus dem sicheren Tunnel (10) empfangenen Nachrichten kontrollieren.
  8. Computernetzwerk nach einem der vorhergehenden Ansprüche, dadurch gekennzeichnet, dass das Gateway (6) so konfiguriert ist, dass es eine vollständige Implementierung des IP-Sicherheitsprotokolls (9) bereitstellt, und das Frontend-Gerät (4.1, 4.2, 4.3) so konfiguriert ist, dass sie eine begrenzte Implementierung (15) des IP-Sicherheitsprotokolls (9) bereitstellt.
  9. Computernetzwerk nach einem der Ansprüche 1 bis 7, dadurch gekennzeichnet, dass das Backend-Gerät (5) so konfiguriert ist, dass sie gekapselte Befehle einer Anwendungsschicht (16) des Frontend-Geräts (4.1, 4.2, 4.3) bereitstellt, um das Frontend-Gerät (4.1, 4.2, 4.3) im Zuge des Handshaking zu steuern.
  10. Gateway für ein Computernetzwerk; wobei das Gateway (6) so konfiguriert ist, dass es mit einem Backend-Gerät (5) innerhalb eines IP-Subnetzes (2) kommuniziert, indem es eine IP-Kommunikation (7) anwendet, die auf einem IP-Sicherheitsprotokoll (9) basiert, das Mittel zur Authentifizierung und/oder Verschlüsselung bereitstellt; und wobei das Gateway (6) so konfiguriert ist, dass es mit einem Frontend-Gerät (4.1, 4.2, 4.3) innerhalb eines Nicht-IP-Teilnetzes (2) kommuniziert, indem es eine Nicht-IP-Kommunikation (8.1, 8.2, 8.3) anwendet; dadurch gekennzeichnet, dass das Gateway (6) so konfiguriert ist, dass es ein Handshaking vermittelt zum Aufbau eines Tunnels (10) für eine sichere Ende-zu-Ende-Kommunikation (11) zwischen dem Backend-Gerät (5) und dem Frontend-Gerät (4.1, 4.2, 4.3), wobei der sichere Tunnel (10) so eingestellt ist, dass er einen Sitzungsschlüssel anwendet; und und wobei das Gateway (6) so konfiguriert ist, dass es Datagramme mit Handshaking-Parametern (13) an das Backend-Gerät (5) liefert, die von dem Backend-Gerät (5) aufgenommen werden, um den Sitzungsschlüssel zu erzeugen; und und wobei das Gateway (6) so konfiguriert ist, dass es Nicht-IP-Nachrichten mit einer Teilmenge der Handshaking-Parameter (14) an das Frontend-Gerät (4.1, 4.2, 4.3) liefert, die von dem Frontend-Gerät (4.1, 4.2, 4.3) zur Erzeugung des Sitzungsschlüssels aufgenommen werden; und wobei das Gateway (6) so konfiguriert ist, dass es nicht in der Lage ist, den Sitzungsschlüssel aus den Handshaking-Parametern (13) zu erzeugen.
  11. Frontend-Gerät für ein Computernetzwerk; wobei das Frontend-Gerät (4.1, 4.2, 4.3) so konfiguriert ist, dass es mit einem Gateway (6) innerhalb eines Nicht-IP-Teilnetzes (2) durch Anwendung einer Nicht-IP-Kommunikation (8.1, 8.2, 8.3) kommuniziert; und wobei das Gateway (6) so konfiguriert ist, dass es mit einem Backend-Gerät (5) innerhalb eines IP-Subnetzes (3) kommuniziert, indem es eine IP-Kommunikation (7) anwendet, die auf einem IP-Sicherheitsprotokoll (9) basiert, das Mittel zur Authentifizierung und/oder Verschlüsselung bereitstellt; und dadurch gekennzeichnet, dass das Frontend-Gerät (4.1, 4.2, 4.3) so eingestellt ist, dass sie Daten mit dem Backend-Gerät (5) über einen sicheren Tunnel (10) für eine sichere Ende-zu-Ende-Kommunikation (11) austauscht, wobei der sichere Tunnel (10) so eingestellt ist, dass er einen Sitzungsschlüssel anwendet; und wobei das Frontend-Gerät (4.1, 4.2, 4.3) so konfiguriert ist, dass sie eine begrenzte Implementierung (15) des IP-Sicherheitsprotokolls (9) ausführt, so dass das Frontend-Gerät (4.1, 4.2, 4.3) in der Lage ist, Nicht-IP-Nachrichten mit einer Teilmenge der Handshaking-Parameter (14) zu interpretieren, die von dem Gateway (6) bereitgestellt werden, das das Handshaking zum Aufbau des sicheren Tunnels (10) vermittelt, um den Sitzungsschlüssel zu erzeugen.
  12. Backend-Gerät für ein Computernetzwerk; wobei das Backend-Gerät (5) so konfiguriert ist, dass es mit einem Gateway (6) innerhalb eines IP-Subnetzes (3) kommuniziert, indem es eine IP-Kommunikation (7) anwendet, die auf einem IP-Sicherheitsprotokoll (9) basiert, das Mittel zur Authentifizierung und/oder Verschlüsselung bereitstellt; wobei das Gateway (6) so konfiguriert ist, dass es mit einem Frontend-Gerät (4.1, 4.2, 4.3) innerhalb eines Nicht-IP-Teilnetzes (2) kommuniziert, indem es eine Nicht-IP-Kommunikation (8.1, 8.2, 8.3) anwendet; dadurch gekennzeichnet, dass das Backend-Gerät (5) so eingestellt ist, dass sie Daten mit dem Frontend-Gerät (4.1, 4.2, 4.3) über einen sicheren Tunnel (10) für eine sichere End-zu-End-Kommunikation (11) austauscht, wobei der sichere Tunnel (10) so eingestellt ist, dass er einen Sitzungsschlüssel anwendet; und wobei das Backend-Gerät (5) so konfiguriert ist, dass sie eingekapselte Befehle einer Anwendungsschicht (16) des Frontend-Geräts (4.1, 4.2, 4.3) bereitstellt, um das Frontend-Gerät (4.1, 4.2, 4.3) im Verlauf des Handshaking zu steuern, vermittelt durch das Gateway (6), um den sicheren Tunnel (10) aufzubauen.
  13. Verfahren zum Betreiben eines Computernetzes, umfassend: ein Non-IP-Subnetz (2) mit mindestens einem Frontend-Gerät (4.1, 4.2, 4.3); und ein IP-Teilnetz (3) mit mindestens einem Backend-Gerät (5); und ein Gateway (6), das das Nicht-IP-Teilnetz (2) mit dem IP-Teilnetz (3) verbindet und die Kommunikation dazwischen überträgt, wobei die Kommunikation zwischen dem Backend-Gerät (5) und dem Gateway (6) eine IP-Kommunikation (7) ist, die auf einem IP-Sicherheitsprotokoll (9) basiert, das Mittel zur Authentifizierung und/oder Verschlüsselung bereitstellt; und wobei die Kommunikation zwischen dem Gateway (6) und dem Frontend-Gerät (4.1, 4.2, 4.3) eine Nicht-IP-Kommunikation (8.1, 8.2, 8.3) ist; gekennzeichnet durch die Verfahrensschritte Durchführen eines Handshaking zum Aufbau eines sicheren Tunnels (10) für eine sichere Ende-zu-Ende-Kommunikation (11) zwischen dem Backend-Gerät (5) und dem Frontend-Gerät (4.1, 4.2, 4.3), wobei der sichere Tunnel (10) so eingestellt ist, dass er einen Sitzungsschlüssel anwendet; und wobei das Gateway (6) das Handshaking vermittelt, ohne in den Besitz des Sitzungsschlüssels zu gelangen, indem es Datagramme mit Handshaking-Parametern (13) an das Backend-Gerät (5) liefert und Nicht-IP-Nachrichten mit einer Teilmenge der Handshaking-Parameter (14) an das Frontend-Gerät (4.1, 4.2, 4.3) liefert; und wobei das Frontend-Gerät (4.1, 4.2, 4.3) den Sitzungsschlüssel unter Einbeziehung der Handshaking-Parameter (13) erzeugt; und wobei das Backend-Gerät (5) den Sitzungsschlüssel erzeugt, der die Teilmenge der Handshaking-Parameter (14) enthält.
  14. Verfahren zum Betreiben eines Computernetzes nach Anspruch 13, dadurch gekennzeichnet, dass das IP-Sicherheitsprotokoll (9) eine symmetrische Verschlüsselung auf der Grundlage von Schlüsseln (17, 18) anwendet, die zwischen dem Frontend-Gerät (4.1, 4.2, 4.3) und dem Backend-Gerät (5) vorab ausgetauscht werden.
  15. Verfahren zum Betreiben eines Computernetzwerks nach Anspruch 13, dadurch gekennzeichnet, dass das IP-Sicherheitsprotokoll (9) eine asymmetrische Verschlüsselung anwendet, wobei das Gateway (6) ein Zertifikat des Frontend-Geräts (4.1, 4.2, 4.3) verarbeitet.
DE102021125836.7A 2020-10-05 2021-10-05 Computernetzwerk für sichere ip-zu-nicht-ip-kommunikation und backend-gerät, gateway, frontend-gerät dafür und verfahren zu dessen betrieb Pending DE102021125836A1 (de)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
DKPA202070676A DK202070676A1 (en) 2020-10-05 2020-10-05 Computer network for secure ip to non-ip communication and backend device, gateway, frontend device therefore and procedure for operation thereof
DK202070676 2020-10-05

Publications (1)

Publication Number Publication Date
DE102021125836A1 true DE102021125836A1 (de) 2022-04-07

Family

ID=80738217

Family Applications (1)

Application Number Title Priority Date Filing Date
DE102021125836.7A Pending DE102021125836A1 (de) 2020-10-05 2021-10-05 Computernetzwerk für sichere ip-zu-nicht-ip-kommunikation und backend-gerät, gateway, frontend-gerät dafür und verfahren zu dessen betrieb

Country Status (3)

Country Link
US (1) US11916889B2 (de)
DE (1) DE102021125836A1 (de)
DK (1) DK202070676A1 (de)

Citations (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US8837485B2 (en) 2012-06-26 2014-09-16 Cisco Technology, Inc. Enabling communication of non-IP device in an IP-based infrastructure

Family Cites Families (7)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US8107397B1 (en) * 2006-06-05 2012-01-31 Purdue Research Foundation Protocol for secure and energy-efficient reprogramming of wireless multi-hop sensor networks
US10506678B2 (en) 2012-07-01 2019-12-10 Ideal Industries Lighting Llc Modular lighting control
US9954956B2 (en) * 2015-08-26 2018-04-24 Intel IP Corporation Secure discovery and connection to internet of things devices in a wireless local-area network
US10097517B2 (en) * 2016-09-01 2018-10-09 Cybersight, Inc. Secure tunnels for the internet of things
FR3064857B1 (fr) * 2017-04-04 2020-07-03 Commissariat A L'energie Atomique Et Aux Energies Alternatives Communication securisee de bout en bout pour capteur mobile dans un reseau iot
EP3767909A1 (de) * 2019-07-17 2021-01-20 Siemens Mobility GmbH Verfahren und kommunikationseinheit zur kryptographisch geschützten unidirektionalen datenübertragung von nutzdaten zwischen zwei netzwerken
CN211180606U (zh) 2020-01-14 2020-08-04 深圳市风云实业有限公司 一种提供ip网络和非ip网络安全互通的网关设备

Patent Citations (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US8837485B2 (en) 2012-06-26 2014-09-16 Cisco Technology, Inc. Enabling communication of non-IP device in an IP-based infrastructure

Also Published As

Publication number Publication date
US11916889B2 (en) 2024-02-27
US20220109658A1 (en) 2022-04-07
DK202070676A1 (en) 2022-09-07

Similar Documents

Publication Publication Date Title
DE602004007301T2 (de) Adressierungs-verfahren und -vorrichtung zum aufbau von hip-verbindungen zwischen gewöhnlichen und hip-fähigen netzknoten
EP2494759B1 (de) Verfahren und vorrichtung zum sicheren übertragen von daten
DE60026838T2 (de) Dynamische verbindung zu mehreren quellen-servern in einem transcodierungs-proxy
DE60121393T2 (de) Schlüsselverwaltungsverfahren für drahtlose lokale Netze
DE60116610T2 (de) Netzwerkadressenübersetzungsgateway für lokale netzwerke unter verwendung lokaler ip-adressen und nicht übersetzbarer portadressen
DE69831974T2 (de) Verfahren zur paketauthentifizierung in gegenwart von netzwerkadressübersetzungen und protokollumwandlungen
EP3210358B1 (de) Telekommunikationsanordnung und verfahren zum traversieren einer application-layer-gateway-firewall beim aufbau einer rtc-kommunikationsverbindung zwischen einem rtc-client und einem rtc-server
DE602006000489T2 (de) Konnektivität über stateful firewalls
DE60201522T2 (de) Ermöglichen legales abfangen von ip-verbindungen
EP1289227B1 (de) Verfahren, System und Rechner zum Aushandeln einer Sicherheitsbeziehung auf der Anwendungsschicht
EP1308017B1 (de) Verfahren zur schlüsselvereinbarung für eine kryptographisch gesicherte punkt-zu-multipunkt verbindung
DE112006000618T5 (de) System und Verfahren zur Verteilung von Schlüsseln in einem drahtlosen Netzwerk
DE60203277T2 (de) Verfahren und system zur authentifizierung eines personal security device gegenüber mindestens einem fernrechnersystem
DE102022208744A1 (de) Sicherer fernzugriff auf geräte in sich überlappenden subnetzen
DE102017210721A1 (de) Verfahren und Kommunikationssystem zum effizienten Aufbau einer sicheren Datenverbindung zwischen einem Client-Rechner und einem Server-Rechner
EP1593253B1 (de) Verfahren und anordnung zur transparenten vermittlung des datenverkehrs zwischen datenverarbeitungseinrichtungen sowie ein entsprechendes computerprogamm-erzeugnis und ein entsprechendes computerlesbares speichermedium
EP1634425A1 (de) Verfahren und einrichtung zum bilden und entschlüsseln einer verschlüsselten nachricht mit kommunikations-konfigurationsdaten
EP3613193A1 (de) Verfahren, vorrichtungen und computerprogrammprodukt zur überprüfung von verbindungsparametern einer kryptographisch geschützten kommunikationsverbindung während des verbindungsaufbaus
DE102023203519A1 (de) Sitzungsbasierter direkter Fernarbeitsspeicherzugriff
DE102021125836A1 (de) Computernetzwerk für sichere ip-zu-nicht-ip-kommunikation und backend-gerät, gateway, frontend-gerät dafür und verfahren zu dessen betrieb
DE102021125835A1 (de) Rechnernetzwerk mit einem ip-subnetz und einem nicht-ipsubnetz und backend-gerät, gateway, frontend-gerät dafür und verfahren zu dessen betrieb
EP3526949B1 (de) Verfahren und einrichtungen zum bereitstellen von mindestens einem dienst, insbesondere im automotive-umfeld
DE102006038599B3 (de) Verfahren zur Wiederaktivierung einer sicheren Kommunikationsverbindung
DE102021109193B4 (de) Verfahren und systeme zur netzwerkadressen-übersetzung ( nat) unter verwendung eines meet-in-the-middle-proxys
EP2773081A1 (de) Kommunikationsgerät für ein industrielles Kommunikationsnetz und ein Verfahren zur Bereitstellung von Daten, insbesondere Dateien, in einem industriellen Kommunikationsnetz mittels File Transfer Protocol

Legal Events

Date Code Title Description
R081 Change of applicant/patentee

Owner name: OPTOTRONIC GMBH, DE

Free format text: FORMER OWNER: OSRAM GMBH, 80807 MUENCHEN, DE

R082 Change of representative