DE102019204951A1 - Verfahren zum sicheren austauschen von nachrichten zwischen endgeräten in einem netzwerk - Google Patents

Verfahren zum sicheren austauschen von nachrichten zwischen endgeräten in einem netzwerk Download PDF

Info

Publication number
DE102019204951A1
DE102019204951A1 DE102019204951.6A DE102019204951A DE102019204951A1 DE 102019204951 A1 DE102019204951 A1 DE 102019204951A1 DE 102019204951 A DE102019204951 A DE 102019204951A DE 102019204951 A1 DE102019204951 A1 DE 102019204951A1
Authority
DE
Germany
Prior art keywords
message
terminal
event
messages
digitally signed
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.)
Withdrawn
Application number
DE102019204951.6A
Other languages
English (en)
Inventor
Jiye Park
Markus Jung
Prajosh Premdas
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.)
Osram GmbH
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
Priority to DE102019204951.6A priority Critical patent/DE102019204951A1/de
Priority to US16/843,038 priority patent/US20200322166A1/en
Publication of DE102019204951A1 publication Critical patent/DE102019204951A1/de
Withdrawn 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/12—Applying verification of the received information
    • H04L63/123—Applying verification of the received information received data contents, e.g. message integrity
    • 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/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/0471—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 applying encryption by an intermediary, e.g. receiving clear information at the intermediary and encrypting the received information at the intermediary before forwarding
    • 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
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/01—Protocols
    • H04L67/12—Protocols specially adapted for proprietary or special-purpose networking environments, e.g. medical networks, sensor networks, networks in vehicles or remote metering networks
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/08—Key distribution or management, e.g. generation, sharing or updating, of cryptographic keys or passwords
    • H04L9/0816—Key establishment, i.e. cryptographic processes or cryptographic protocols whereby a shared secret becomes available to two or more parties, for subsequent use
    • H04L9/0819—Key transport or distribution, i.e. key establishment techniques where one party creates or otherwise obtains a secret value, and securely transfers it to the other(s)
    • H04L9/0825—Key transport or distribution, i.e. key establishment techniques where one party creates or otherwise obtains a secret value, and securely transfers it to the other(s) using asymmetric-key encryption or public key infrastructure [PKI], e.g. key signature or public key certificates
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/32—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials
    • H04L9/3247—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials involving digital signatures
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/32—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials
    • H04L9/3263—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials involving certificates, e.g. public key certificate [PKC] or attribute certificate [AC]; Public key infrastructure [PKI] arrangements
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L2209/00—Additional information or applications relating to cryptographic mechanisms or cryptographic arrangements for secret or secure communication H04L9/00
    • H04L2209/80—Wireless
    • H04L2209/805—Lightweight hardware, e.g. radio-frequency identification [RFID] or sensor

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Security & Cryptography (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Computing Systems (AREA)
  • Computer Hardware Design (AREA)
  • General Engineering & Computer Science (AREA)
  • Health & Medical Sciences (AREA)
  • General Health & Medical Sciences (AREA)
  • Medical Informatics (AREA)
  • Computer And Data Communications (AREA)
  • Small-Scale Networks (AREA)

Abstract

Ein Verfahren zum sicheren Austauchen einer oder mehrerer Nachrichten (14, 16) zwischen Endgeräten (12a, 12b-12e) in einem diese verbindenden Netzwerk (10) umfasst die Schritte: Erstellen einer Nachricht (44) durch ein erstes Endgerät (12a), Digitales Signieren (46, 56) der Nachricht (14, 16) mit einem privaten Schlüssel des ersten Endgeräts (12a), und Senden (48) der signierten Nachricht (14, 16) an wenigstens ein zweites Endgerät (12b-12e). Weiter ist vorgesehen, dass die Schritte des Erstellens der zu sendenden Nachricht und des digitalen Signierens vom ersten Endgerät durchgeführt werden, bevor ein in Zusammenhang mit dem bestimmungsgemäßen Zusammenwirken der Endgeräte (12a, 12b-12e) stehendes Ereignis (18) das Senden der signierten Nachricht (14, 16) auslöst, wobei ein vom zweiten Endgerät (12b-12e) auszuwertender Inhalt der erstellten Nachricht auf das Ereignis (18) bezogen ist

Description

  • Technisches Gebiet
  • Die vorliegende Erfindung betrifft ein Verfahren zum sicheren Austauschen von Nachrichten zwischen Endgeräten mit insbesondere geringer Rechenkapazität in einem Netzwerk. Die Erfindung betrifft insbesondere auch entsprechende Endgeräte, wie sie in der Gebäudeautomation und/oder bei intelligenten Beleuchtungssystemen zum Einsatz kommen.
  • Stand der Technik
  • Das Internet der Dinge (IoT) ermöglicht die Vernetzung von physischen und virtuellen Dingen oder Gegenständen untereinander und mit dem Internet. Solche Gegenstände können dazu neben den entsprechenden Kommunikationsbausteinen auch Sensoren oder Aktoren umfassen. Dies betrifft insbesondere auch das Gebiet der Gebäudeautomation und hier beispielsweise auch intelligente Beleuchtungssysteme („smart lighting“). Die einzelnen Gegenstände (im Folgenden auch als Endgeräte bezeichnet) treten dabei über Machine-to-Machine (M2M) Kommunikation miteinander in Nachrichtenaustausch, um den Betrieb des Systems zu gewährleisten. Im Allgemeinen sind solche verteilten Systeme in einer sogenannten REST-Architektur (Representational State Transfer) wie z.B. dem World Wide Web mit dem HTTP-Protokoll realisiert, demzufolge beispielsweise Client-Server-Grundprinzipien vorhanden sind, bei der ein Server eine Dienst oder Ressource bereitstellt, der oder die vom Client angefordert bzw. angefragt werden kann.
  • In vielen Bereichen des Internets der Dinge und insbesondere im Bereich der Gebäudeautomation und/oder intelligenter Beleuchtungssysteme sind allerdings sowohl die Verarbeitungs- und Speicherkapazitäten der Endgeräte als auch die zugrundeliegenden Netzwerke zum Teil erheblichen Einschränkungen unterworfen.
  • Diese Einschränkungen können durch Kosten oder aber auch Platzbedarf oder Energieverbrauch etc. verursacht sein. Die Kommunikationsbausteine können beispielsweise vergleichsweise rudimentäre 8-Bit-Mikrocontroller mit begrenztem RAM- und/oder ROM-Speicher aufweisen.
  • Bei solchen Netzwerken kann es sich beispielsweise um solche auf dem 6LowPAN-Protokoll (IPv6 over Low power Wireless Personal Area Networks) basierende Netze handeln, die speziell für den hier erforderlichen energiesparenden Einsatz konzipiert sind. Das 6LowPAN-Protokoll stellt eine Anpassungsschicht (adaption layer) auf der Ebene der Vermittlungsschicht im OSI-Referenzmodell (3. Schicht) bereit, die z.B. die Vorteile eines beim IPv6-Nachrichtenaustausch vorgesehenen Multicastings anbietet, die aber gleichzeitig mit den Einschränkungen der darunterliegenden, z.B. gemäß dem IEEE-Standard 802.15.4 für Funkübertragungsnetze festgelegten Bitübertragungs- und Sicherungsschichten (link layer) umgehen kann, d.h., den ersten und zweiten Schichten des OSI-Referenzmodells, und diese damit an die höheren Anwendungsschichten adaptiert.
  • In den genannten Systemen mit eingeschränkter Umgebung findet üblich desweiteren auf Ebene der Transportschicht (d.h., der 4. Schicht des OSI-Referenzmodells) das UDP-Protokoll (User Datagram Protocol) Anwendung. Dieses einfache Protokoll ist per se verbindungslos, nicht-zuverlässig, ungesichert und ungeschützt. Bei diesem Protokoll ist nicht sichergestellt, ob ein bestimmtes Datenpaket beim Empfänger überhaupt, nur genau einmal, und/oder wenigstens in der richtigen Reihenfolge mit anderen Datenpaketen ankommt, und ob die Daten verfälscht wurden oder Dritte Zugriff auf die Daten des Pakets hatten. Diese Übertragung bietet andererseits den Vorteil, dass keine Verzögerung der Datenübertragung eintritt etwa durch Neuanforderung verloren gegangener Pakete wie es bei dem alternativen TCP-Protokoll der Fall ist. Die Netzwerklast wird dadurch gering gehalten. Insbesondere bei geringen Mengen der über das Netzwerk auszutauschenden Daten, wie es insbesondere in der Gebäudeautomation oder bei intelligenten Beleuchtungssystemen der Fall ist, wird der Datendurchsatz dabei erhöht.
  • Auf Ebene der Anwendungsschichten (5. Schicht im OSI-Referenzmodell) wurde daher von der IETF Constrained RESTfuI environments (CoRE) working group angesichts dieser Einschränkungen, d.h. ressourcenbeschränkter Geräte wie 8-Bit-Mikrocontroller mit geringen ROM- und/oder RAM-Speicher sowie verlustbehafteter Netzwerke mit niedriger Übertragungsrate ein Anwendungsprotokoll festgelegt, das als Constrained Application Protocol (CoAP) bezeichnet wird und den beschriebenen Anforderungen Rechnung trägt (Request for Comments 7252; Shelby, Z. et al.; ISSN: 2070-1721; Entwurf vom Juni 2014 herunterladbar unter https://tools.ietf.org/html/rfc7252). Dieses Protokoll wurde für die Anwendung mit UDP entwickelt, kann aber auch mit TCP oder ähnlichen Protokollen verwendet werden. Im Fall von UDP belegt eine CoAP-Nachricht das Nutzdatenfeld des UDP-Datagramms. Eine CoAP-Nachricht selbst umfasst wiederum einen 4 Byte langen Header, einen Token, Optionen und letztendlich die eigentlichen Nutzdaten (engl. payload) der Anwendung.
  • Die Funktionsweise des CoAP-Protokolls ist ähnlich derjenigen des weithin bekannten HTTP-Protokolls (Hypertext Transfer Protocol) - insbesondere im Hinblick auf das unterliegende Client/Server-Modell. Eine CoAP-Anfrage (Request) wird beispielsweise vom Client gesendet, um unter Verwendung eines Verfahrenscodes (engl. method code) in der entsprechenden Nachricht eine Aktion auf Basis einer durch eine sogenannte URI (Universal Resource Identifier) identifizierten Ressource anzufordern, die im Aktionsbereich des Servers liegt. Der Server sendet dann eine Nachricht mit einer Antwort, die durch einen Antwortcode (response code) identifiziert wird.
  • Da das CoAP-Protokoll anders als z.B. HTTP über den Austausch von UDP-Datagrammen lediglich eine asynchrone und damit gegebenenfalls unzuverlässige Kommunikation zwischen Client und Server vorsieht, ist innerhalb der CoAP-Anwendungsschicht als eine Art von Unterteilung eine Nachrichtenschicht (messages layer) eingezogen, die vier Nachrichtentypen festlegt: „confirmable“, „non-confirmable“, „acknowledgement“ und „reset“. Mit diesen kann z.B. fallabhängig optional anhand des Typs „confirmable“ durch Anfordern einer Bestätigungsnachricht mit dem Typ „acknowledgement“ (oder alternativ bei Problemen: mit dem Typ „reset“) die Zuverlässigkeit des Nachrichtenaustauschs auf höherer Schichtebene wieder hergestellt werden. Hierbei kann auch ein Stauauflösungsmechanismus (bei Ausbleiben einer Bestätigung) anhand des sog. Binary Exponential Backoff mit jeweils vordefiniertem Neusenden nach jeweils sich z.B. verdoppelnder Verzögerungszeit vorgesehen sein.
  • Neben der Nachrichtenschicht ist als Unterteilung der CoAP-Anwendungsschicht auch eine Anfrage- und Antwortschicht (request/response layer) eingezogen. Hier besteht eine nahe Verwandtschaft zum HTTP-Protokoll, so dass eine Übertragung von Applikationen aus dem HTTP in das CoAP leicht möglich ist. Ob die betreffende Nachricht eine Anfrage (request) oder eine Antwort (response) ist, ist jeweils im Header der CoAP-Nachricht in einem 1 Byte langen Code-Feld hinterlegt. Im gleichen Feld ist zudem hinterlegt, ob z.B. die Anfragemethode ein GET, ein POST, ein PUT oder ein DELETE ist. Diese Methoden werden z.B. analog auch im HTTP verwendet. Für Antworten sind ebenfalls Codes vorgesehen, die jeweils einer der Klassen: „Success“, „Client-Error“ oder „Server-Error“ zugeordnet werden.
  • Um die im Fall von eingeschränkten Netzwerken eingangs beschriebenen Probleme im Hinblick auf eine reduzierte Sicherheit und nicht-zuverlässige Datenübertragung zu lösen, kann im Fall von CoAP das Verschlüsselungsprotokoll DTLS (Datagram Transport Layer Security) verwendet werden. Im Gegensatz zum TLS-Protokoll, das im Fall des zuverlässigeren HTTP-over-TCP Einsatz findet, werden bei DTLS die ausgetauschten Nachrichten beispielweise explizit nummeriert und ausbleibende Nachrichten automatisch nach einem Timeout erneut gesendet. Dadurch wird die korrekte Reihenfolge und der Handschlag zwischen Client und Server bei der jeweiligen Kommunikation gesichert.
  • Allerdings können weder TLS noch DTLS im Rahmen eines Multicasts eingesetzt werden. Auch enden TLS- oder DTLS-Verschlüsselungen protokollgemäß immer an den jeweiligen Proxies, so dass die jeweiligen Proxies selbst Zugriff auf die betreffenden geschützten Inhalte haben und diese ggf. verändern können. Multicasts sind jedoch gerade im Fall einer Gruppenkommunikation, wie sie insbesondere in den Netzwerken der Gebäudeautomation und hier insbesondere in intelligenten Beleuchtungssystemen Einsatz findet, dringend erforderlich.
  • Die oben genannte CoRE Working Group arbeitet daher derzeit an einem Entwurf für ein neues Verfahren zum Schutz der unter dem CoAP-Protokoll betriebenen Anwendungsschicht, das mit dem Akronym OSCORE (Object Security for Constrained RESTful Environments, Internet-Draft vom 31. August 2018, Selander, G., et al. https://tools.ietf.org/pdf/draft-ietf-core-object-security-15.pdf) bezeichnet wird. Das OSCORE-Sicherheitsprotokoll basiert auf einer Verschlüsselung ausgetauschter CoAP-Nachrichten, wobei u.a. die Nutzdaten, bestimmte Optionen und die Felder des Headers der originalen CoAP-Nachricht in ein verschlüsseltes Objekt (COSE-Objekt; CBOR Object Signing and Encryption) gepackt werden und nun selbst wieder als Nutzdaten der OSCORE-Nachricht angehängt werden, die grundsätzlich wieder das Format einer CoAP-Nachricht besitzt, wobei „OSCORE“ als eine der Optionen dieser Nachricht eingetragen wird.
  • Darauf aufbauend wird von der CoRE Working Group auch an einem Entwurf zum Schutz der Gruppenkommunikation unter Verwendung des OSCORE-Sicherheitsprotokolls gearbeitet. Dieser Betriebsmodus wird als „Group OSCORE“ bezeichnet (Internet-Draft vom 22. Oktober 2018; Tiloca, M. et al.; https://tools.ietf.org/html/draft-ietf-core-oscore-groupcomm-03). Darin ist beschrieben, wie ähnlich zu der bloßen Unicast-Kommunikation zwischen zwei bestimmten Endgeräten gemäß OSCORE nunmehr auch die Sicherheit und Integrität im Nachrichtenaustausch zwischen einem sendenden Endgerät und einer Gruppe von empfangenden Endgeräten und auch umgekehrt hergestellt werden kann. Insbesondere wird eine Senderauthentifikation aller in der Gruppe von mehr als zwei Endgeräten ausgetauschten CoAP-Nachrichten anhand digitaler Signaturen ermöglicht. Dies ermöglicht z.B. nunmehr eine Unterscheidung, von welchem Endgerät aus einer Vielzahl von Endgeräten in der Gruppe die Antwort auf eine vorher an alle übermittelte Nachricht erfolgte. Durch diese Senderauthentifikation wird folglich die Gruppenkommunikation in geschützter Weise überhaupt erst möglich.
  • Allerdings ist beispielsweise dem Internet-Draft zu Group OSCORE zufolge der spezielle Signaturalgorithmus Ed25519 aus der EdDSA-Familie vorgeschrieben. Dieser ist zwar besonders effizient und schnell und darüberhinaus patentfrei, jedoch liegt dieser bisher nur als Softwareimplementation vor. Hardwarebausteine stehen bisher nicht zur Verfügung. Nun entsteht ein Problem dadurch, dass, wenn ein Endgerät veranlasst ist, eine mit Signatur versehene Nachricht an die Gruppe zu versenden, in genau diesem Moment erst der Signaturalgorithmus zur Verschlüsselung von dem Prozessor des Kommunikationsbausteins ausgeführt werden muss, bevor z.B. die oben genannte OSCORE-Nachricht abgesendet werden kann. Gerade aber in der oben beschriebenen, eingeschränkten Umgebung (constrained devices, constrained network) mit z.B. 8-Bit-Mikrocontrollern kann diese zusätzliche Phase der Signaturberechnung zu besonders unerwünschten Latenzzeiten führen. Einem Vergleichsbeispiel mit solch einem typischen Controller zufolge (z.B. TI CC2538DK mit ARM Cortex-M3, 512 kB Flash- und 32 kB RAM-Speicher) kann die Schlüsselerzeugung 4 s, das Signieren 5 s und die Verifikation beim Empfänger 12 s in Anspruch nehmen. Gerade im Bereich der Gebäudeautomation und/oder in intelligenten Beleuchtungssystemen sind aber entsprechende Latenzzeiten unannehmbar. Bei Beleuchtungssystemen können beispielsweise Latenzzeiten von 200 ms oder weniger gerade noch akzeptabel sein.
  • Ein Ausweg wäre es, leistungsfähigere Controller und Kommunikationsbausteine vorzusehen. Dies würde aber den Energieverbrauch und insbesondere die Kosten aufgrund der Vielzahl anzupassender Bausteine in nicht mehr akzeptabler Weise in die Höhe treiben. Ferner sieht der vorliegende Entwurf zu Group OCSCORE vor, dass diejenigen Endgeräte, die nicht in der Lage sind, die Verifikation der Signatur vorzunehmen, eben jene Verifikation einfach auszulassen. In diesem Fall kann/sollte das sendende Endgerät die CoAP-Nachrichten als „non confirmable“ kennzeichnen, welches das empfangende Endgerät dann aber in eine passive Rolle („pure listener“) versetzt. Dies kennzeichnet aber auch wieder nur einen weniger gewünschten Zustand und verringert zudem die Sicherheit und die Zuverlässigkeit des Nachrichtenaustauschs .
  • Darstellung der Erfindung
  • Es ist daher eine Aufgabe der Erfindung, ein Verfahren und/oder ein entsprechend eingerichtetes Endgerät bereitzustellen, mit dem auch in Netzwerken mit Endgeräten geringer Rechenkapazität ein besonders sicherer Nachrichtenaustausch gewährleistet werden kann, und bei dem die Kosten und der Aufwand zur Bereitstellung des Nachrichtenaustauschs gering gehalten werden können.
  • Die Aufgabe wird gelöst durch ein Verfahren sicheren Austauchen einer oder mehrerer Nachrichten zwischen Endgeräten in einem diese verbindenden Netzwerk mit den Merkmalen des Anspruch 1 sowie durch ein entsprechend eingerichtetes Endgerät mit den Merkmalen des Anspruchs 15. Vorteilhafte Weiterbildungen, Ausgestaltungen und Aspekte sind in den abhängigen Ansprüchen angegeben.
  • Ausgangspukt ist ein Verfahren zum sicheren Austauchen einer oder mehrerer Nachrichten zwischen Endgeräten in einem diese verbindenden Netzwerk, das die Schritte: Erstellen einer Nachricht durch ein erstes Endgerät, digitales Signieren der Nachricht mit einem privaten Schlüssel des ersten Endgeräts, und Senden der signierten Nachricht an wenigstens ein zweites Endgerät umfasst. Es kann sich hierbei um eine gewöhnliche Client/Server-Kommunikation handeln, beispielsweise stellt das erste Endgerät einen Client dar, der in der Nachricht eine Anfrage (request) einbindet, die dann vom zweiten Endgerät als Server zu beantworten (response) werden könnte, beispielsweise durch bereitstellen einer Ressource etc. oder auch nur durch eine einfache Bestätigung des Erhalts der Nachricht. Es kann sich bei dem ersten Endgerät beispielsweise aber auch um einen Server handeln, der mit der signierten Nachricht die Ressource bereitstellt, oder die Bestätigung zu einer vorgehenden Anfrage übermittelt, etc.
  • Die Nachricht ist nicht auf bestimmte Protokolle eingeschränkt. Sie ist vorzugsweise auf Ebene der Anwendungsschicht (application layer) implementiert. Sie kann einen Nachrichtenkopf (message header) und einen Nachrichtenrumpf (message body) umfassen. Der Nachrichtenkopf kann Informationen über den Typ der Nachricht, Versionen des unterliegenden Protokolls, Feldlängen im Nachrichtenrumpf und/oder Identifikationsnummern betreffend diese Nachricht etc. enthalten. Der Nachrichtenrumpf kann die eigentlichen Nutzdaten (payload), Optionen und Hinweise zu den Nutzdaten und/oder Identifikationsnummern betreffend den speziellen Nachrichtenaustausch beinhalten, dessen Teil die aktuelle Nachricht ist, etc.
  • Die Endgeräte können jeweils einen an das Netzwerk anschließbaren Kommunikationsbaustein bzw. Controller sowie eine funktionale Einheit aufweisen, die dem bestimmungsgemäßen Gebrauch dient, im Fall eines intelligenten Beleuchtungssystems beispielsweise eine Leuchte, eine Sensor, eine Steuervorrichtung, ein Aktor, etc. Der Kommunikationsbaustein wird nachfolgend auch als Teil der funktionalen Einheit betrachtet.
  • Das Netzwerk kann kabelgebunden und/oder drahtlos sein. Auch sind keine Einschränkungen im Hinblick auf den Aufbau bzw. Architektur/Topologie festgelegt. Ein Netzwerk im hier verwendeten Sinn kann ein LAN, WPAN oder WLAN sein, oder weiter ein durch Router, Switches und/oder Repeater erweitertes Gebäude- oder Firmennetz, ein Intranet oder das Internet insgesamt, etc.
  • Ausführungsformen der Erfindung zufolge ist nun vorgesehen, die Schritte des Erstellens der zu sendenden Nachricht und des digitalen Signierens vom ersten Endgerät durchzuführen, bevor ein in Zusammenhang mit dem bestimmungsgemäßen Zusammenwirken der Endgeräte stehendes Ereignis das Senden der signierten Nachricht auslöst. Dabei ist ein vom zweiten Endgerät auszuwertender Inhalt der erstellten Nachricht gerade auf dieses Ereignis bezogen.
  • Es wird hierbei also von einem ereignisbezogenen Nachrichtenaustausch ausgegangen. Ein Ereignis ist hier als Änderung eines (beliebig gearteten) Zustands zu einem bestimmten Zeitpunkt zu verstehen. Da es logisch betrachtet das Absenden der Nachricht auslöst, kann es hierbei neben der Änderung des Zustands selbst auch die Umsetzung in einen Impuls oder ein Signal beinhalten, das vom Kommunikationsbaustein als auslösender Mechanismus verarbeitet werden kann. Das Ereignis kann eine von einem Sensor oder einem Messgerät erfasste Änderung eines physischen Zustands sein, die entsprechend in ein Signal umgesetzt wird. Das Ereignis kann dabei als Über- oder Unterschreitung eines vorgegebenen Grenzwerts für eine physikalische, chemische oder mathematische Größe, etc. betrachtet werden. Bei dem Ereignis kann es sich auch um ein Alarmsignal handeln, d.h. einer Änderung von einem ordnungsgemäßen Betriebszustand in einen nicht ordnungsgemäßen Betriebszustand. Das Ereignis kann auch in einer Anfrage bestehen, die mit einer Nachricht empfangen wird, wobei sich ein Zustand von „alle Anfragen beantwortet“ in „Anfragen offen“ ändert. Das Ereignis tritt hier mit dem Nachrichteneingang ein.
  • Folglich stehen das Ereignis und das Absenden der Nachricht in kausalem Zusammenhang. Der Inhalt der Nachricht nimmt auf das Ereignis Bezug, beispielsweise wird eine mit einer früheren Nachricht gesendete Anfrage mit einer Bestätigung in der aktuellen Nachricht beantwortet, oder es wird im Nutzdatenteil der Nachricht ein Wert einer physikalischen Größe übermittelt, deren Zustand sich geändert hat, oder es wird mit der Nachricht eine Anfrage gesendet, die eine aus der Zustandsänderung folgende Aktion beim empfangenden zweiten Endgerät anfordert, etc.
  • Allerdings sieht die Erfindung vor, das Erstellen und insbesondere das aufwändige Signieren der Nachricht vor dem Eintritt des Ereignisses, d.h. der Zustandsänderung mit entsprechendem Signalempfang im ersten Endgerät selbst durchzuführen. Dies kann implizieren, dass das erste Endgerät eine gewisse Vorhersage treffen kann, dass als nächstes ein bestimmtes Ereignis eintreffen wird. Ohne eigentliche Vorhersage ist es aber auch möglich, z.B. bei einer nur sehr begrenzten Anzahl von Möglichkeiten von Ereignissen, insbesondere bei Schaltvorgängen („EIN“ oder „AUS“) etc., einfach alle möglichen Nachrichten vorab zu erstellen und insbesondere digital zu signieren, und dann bis zum Absenden vorzuhalten, wobei abschließend die richtige auszuwählen ist.
  • In jedem Fall entsteht ein besonderer Vorteil diesen Ausgestaltungen zufolge dadurch, dass die zum Signieren erforderliche Rechenzeit im Kommunikationsbaustein bzw. dem Controller des Endgeräts nicht erst dann anfällt, wenn das Ereignis eintritt, sondern beispielweise in eine vorherige Leerlaufphase des ersten Endgeräts bzw. dessen Controllers vorgezogen werden kann. Die Reaktion des Endgeräts auf das Ereignis in Form einer Nachrichtenmitteilung ist dadurch deutlich schneller, die Latenzzeit des Systems wird kürzer. Dieser Vorteil macht sich besonders dann bemerkbar, wenn - wie üblich in der Gebäudeautomation und/oder bei intelligenten Beleuchtungssystemen - Mikro-Controller mit geringen Rechen- und/oder Speicherkapazitäten eingesetzt werden. Durch das vorgeschlagene Vorgehen wird es in vielen Systemen überhaupt erst möglich, durch einen Nachrichtenaustausch mit digitalem Signieren zur Authentifikation durchzuführen.
  • Einer vorteilhaften Weiterbildung der Erfindung zufolge umfasst bei dem vorgeschlagenen Verfahren das erste Endgerät einen Sensor. Das Ereignis entspricht dabei einer von dem Sensor erfassten Änderung eines Zustands in einer Umgebung des Sensors. Meldungen von Sensoren sollten insbesondere in der Gebäudeautomation oder bei intelligenten Beleuchtungssystemen besonders schnell erfolgen, beispielsweise wenn eine Beleuchtung an die Anwesenheit und gegebenenfalls auch die Verteilung von Personen in einem Raum angepasst werden soll. Zu lange Latenzzeiten könnten sonst zu Beeinträchtigungen bei einer angemessenen Ausleuchtung für die Personen führen.
  • Einer Weiterbildung der Erfindung zufolge ist das erste Endgerät ausgelegt, das nachfolgend eintretende Ereignis und/oder die auf das Ereignis bezogene Nachricht vorauszuberechnen. Beispielsweise kann das erste Endgerät die Vorausberechnung durchführen, indem eine Liste grundsätzlich möglicher Ereignisse oder Nachrichten erstellt wird und daraus im Vergleich mit dem zuletzt eingetretenen Ereignis oder der zuletzt abgesendeten Nachricht das als nächstes sicher oder zumindest mit einer Mindestwahrscheinlichkeit auftretende Ereignis beziehungsweise die darauf bezogene Nachricht ausgewählt wird. Im Prinzip liegt hier dem Verfahren ein Schritt zugrunde, in welchem geprüft wird, ob überhaupt eine Vorhersage getroffen werden kann, welches Ereignis als nächste eintreten wird. Dies setzt im allgemeinen eine abschließende Liste bzw. eine begrenzte Anzahl von Möglichkeiten für Ereignisse in Bezug auf das betreffende erste Endgerät bzw. auf diese bezogene Nachrichten voraus (wie auch die Tatsache, dass für ein bestimmtes Ereignis auch nur eineindeutig eine bestimmte Nachricht erstellt werden darf). In einem einfach gelagerten Fall, in welchem nur zwei Zustände vorliegen können, wie bei einem Schalter, beinhaltet die Vorausberechnung beispielsweise die Bestimmung der beiden mögliche Ereignisse, die Bestimmung des derzeitigen Zustands bzw. des letzten Ereignisses und die konsequente Auswahl des einzig möglichen anderen Ereignisses mit einer anschließenden Berechnung bzw. Zusammenstellung der Nachricht.
  • Die Vorausberechnung kann aber auch komplizierter ausgestaltet sein, wenn mehr als zwei mögliche Ereignisse eintreten können und ausgehend vom derzeitigen Zustand bzw. dem letzten Ereignis oder sogar den letzten Ereignissen in einer Reihenfolge eine Plausibilitäts- oder Wahrscheinlichkeitsberechnung für die Ereignisse durchgeführt wird, wobei hier noch ein Vergleich mit abschließender Auswahl hinzutreten kann. Beispielsweise kann aus der Reihe letzter Ereignisse durch entsprechende Berechnung auf ein nächstes Ereignis geschlossen werden. Tritt dieses dann jedoch nicht ein, sondern ein anderes, dann kann die im Voraus erstellte und digital signierte Nachricht verworfen werden, und es wird nach Ereigniseintritt doch noch eine neue Nachricht erstellt, digital signiert und abgesendet wie im konventionellen Fall. Es entsteht dann doch wieder eine Latenzzeit, aber durch die vorab durchgeführte Vorhersage und Wahrscheinlichkeitsberechnung kann selbst in diesem Fall zumindest der größte Teil der Fälle immer noch erfindungsgemäß verarbeitet werden. Mit anderen Worten, selbst der fall mehrerer Auswahlmöglichkeiten ist von der Erfindung umfasst.
  • Einer weiteren vorteilhaften Weiterbildung zufolge kann das erste Endgerät die auf das Ereignis bezogene, signierte Nachricht bis zum Eintritt des Ereignisses speichern. Es ruft dann die Nachricht ab und sendet sie an das zweite Endgerät, wenn das Ereignis eintritt. Dieser Aspekt ist vorteilhaft, wenn insbesondere längere Leerlaufzeiten vorliegen, oder wenn für z.B. nur 2 oder wenig mehr mögliche Zustandsänderungen oder Ereignisse die entsprechenden Nachrichten bereits beim Systemstart vorausberechnet werden, so dass auf die jeweilige wiederholte Neuberechnung verzichtet werden kann.
  • Einer weiteren vorteilhaften Weiterbildung zufolge führt das erste Endgerät die Schritte des Erstellens und Signierens der Nachricht durch, unmittelbar nachdem vorher eine weitere, auf ein vorhergehendes Ereignis bezogene Nachricht abgesendet wurde. Die Vorausberechnung bzw. das vorab Erstellen und Signieren der vorherigen Nachricht kann einen regulären Anstoß oder Triggerpunkt erfordern, wobei hier das Absenden der vorherigen Nachricht als Auslöser gewählt wird. Alternativ erfolgt dies innerhalb einer Leerlaufphase zwischen dem Absenden zweier Nachrichten. Da der Zeitpunkt des nachfolgenden Ereignisses nicht bekannt ist, ist ein frühzeitiger Triggerpunkt innerhalb der Leerlaufphase folgerichtig mit Vorteilen verbunden.
  • Einer weiteren vorteilhaften Weiterbildung zufolge sind die Endgeräte einschließlich des ersten und des zweiten Endgeräts und das diese verbindende Netzwerk Teil eines intelligenten Gebäudeautomations- und/oder Beleuchtungssystems, und bilden eine Gruppe für sichere Kommunikation aus. Die digital signierte Nachricht wird dabei von dem ersten Endgerät in einem Multicast an alle weiteren Endgeräte einschließlich des zweiten Endgeräts gesendet. Wie beschrieben ist eine Multicast-Kommunikation eine besonders in intelligenten Gebäudeautomations- und/oder Beleuchtungssystemen bestehende Anforderung, die gleichzeitig aber auch erhöhte Anforderungen an Sicherheit und Zuverlässigkeit der Netzwerkkommunikation stellen. Die für Controller mit geringer Rechenkapazität aufwändige digitale Signatur (und Verifikation) kann daher mit Vorteil anhand der durch die Erfindung vorgeschlagenen Lösung gleichwohl umgesetzt werden.
  • Einer weiteren vorteilhaften speziellen Weiterbildung zufolge umfasst der Sensor einen Präsenzmelder zum Melden einer Anwesenheit von Personen in einer Umgebung des Präsenzmelders. Das zweite Endgerät umfasst dabei beispielsweise eine Leuchte, die abhängig von Nachrichten des Präsenzmelders betrieben wird. Dabei entspricht das Ereignis der Erfassung des Auftretens oder Verlassens einer oder mehrerer Personen in der Umgebung des Präsenzmelders. Das erste Endgerät wählt dann in dem Fall, in welchem das zuletzt eingetretene Ereignis der Erfassung des Auftretens der einen oder mehreren Personen entspricht, als nächstes einzutretendes Ereignis, für das die Nachricht zu erstellen ist, bevor es eintritt, das entsprechend komplementäre Ereignis aus, welches der Erfassung des Verlassens der einen oder mehreren Personen in der Umgebung entspricht, und umgekehrt. Die Präsenz- oder Personenerfassung stellt einen Fall mit besonderen Anforderungen an geringe Latenzzeiten dar, so dass der erfindungsgemäße Vorschlag hier besondere Vorteile bietet.
  • Einer weiteren vorteilhaften speziellen Weiterbildung zufolge umfasst der Sensor einen Temperatursensor zum Melden einer Temperatur. Das zweite Endgerät umfasst dabei ferner eine Klimaanlage, die abhängig von den Inhalten der betreffenden Nachrichten vom Temperatursensor betrieben wird. Das Ereignis entspricht hier einer Erfassung des Über- oder Unterschreitens eines vorgegebenen Temperaturgrenzwerts. Das erste Endgerät berechnet aus zumindest einem zuletzt eingetretenen Ereignis der Erfassung des Über- oder Unterschreitens eines weiteren, niedrigeren oder höheren vorgegebenen Temperaturgrenzwerts durch Extrapolation das nächste einzutretende Ereignis voraus, für das die Nachricht zu erstellen ist, bevor es eintritt. Dies entspricht einem vorteilhaften Ausführungsbeispiel, bei dem mehrere verschiedene Ereignisse eintreten können (die Temperatur z.B. steigt weiter oder auch nicht).
  • Einer weiteren vorteilhaften Weiterbildung zufolge werden entsprechend dem Verfahren Nachrichten im Netzwerk auf der Anwendungsschicht gemäß dem in RFC7252 festgelegten Constrained Application Protocol, CoAP, basierend auf der Transportschicht gemäß dem in RFC768 festgelegten User Datagram Protocol, UDP, ausgetauscht. Wie eingangs beschrieben stellt dieses Protokoll eine besonders angemessene Plattform für den Nachrichtenaustausch in Systemen mit Endgeräten bereit, die nur über eine begrenzte Rechen- und/oder Speicherkapaziät verfügen, wie es bei der Gebäudeautomation oder in intelligenten Beleuchtungssystemen der Fall ist.
  • Einer weiteren vorteilhaften Weiterbildung zufolge wird die Nachricht mit einem Signaturalgorithmus basierend auf elliptischen Kurven digital signiert, insbesondere ECDSA oder Ed25519. Diese Verfahren bieten ein besonders hohes Maß an Sicherheit gegenüber angriffsweisen Entschlüsselungen, benötigen aber auch gewisse Rechenkapazitäten, die aber durch das vorgeschlagene Verfahren intelligent in Anspruch genommen werden können.
  • Einer weiteren vorteilhaften Weiterbildung zufolge wird die digital signierte Nachricht zusätzlich mit einem für alle Endgeräte der Gruppe zugänglichen öffentlichen Schlüssel verschlüsselt. Dies erhöht weiter die Sicherheit des Nachrichtenaustauschs. Die entsprechende Berechnung kann mit den gleichen Vorteilen wie beschrieben ebenfalls vor dem Eintritt des Ereignisses bzw. der Zustandsänderung erfolgen.
  • Einer weiteren vorteilhaften Weiterbildung zufolge empfängt das zweite Endgerät die digital signierte Nachricht und verifiziert in einem weiteren Schritt die digitale Signatur des ersten Endgeräts, wobei das zweite Endgerät entsprechend vor bzw. nach dem Empfang der digital signierten Nachricht des ersten Endgeräts die gleichen Schritte ausführt wie das erste Endgerät mit der Maßgabe, dass das betreffende Ereignis der Empfang der digital signierten Nachricht des ersten Endgeräts selbst ist. Mit anderen Worten, das zweite Endgerät eine erstellt weitere, die Antwort auf die digital signierte Nachricht des ersten Endgeräts betreffende Nachricht signiert diese digital, noch bevor es die digital signierte Nachricht des ersten Endgeräts empfängt. Das zweite Endgerät sendet dann diese weitere digital signierte Nachricht abhängig vom Empfang der digital signierten Nachricht des ersten Endgeräts an das erste Endgerät zurück.
  • Durch diesen Ansatz wird das vorgeschlagene Vorgehen auf die gesamte Kommunikation zwischen den Endgeräten, d.h. Anfrage (request) und Antwort (response) ausgedehnt, so dass Latenzzeiten noch stärker vermieden und Kosten für sonst erforderliche leistungsfähigere Controller weiter vermieden werden.
  • Einer weiteren vorteilhaften Weiterbildung dieses Aspekts zufolge ist die weitere digital signierte Nachricht eine bloße Bestätigung über den Empfang der digital signierten Nachricht des ersten Endgeräts ohne Nutzdaten. Das Erfordernis, eine solche Nachricht abzusenden, besteht gerade auch dem in RFC7252 festgelegten Constrained Application Protocol, CoAP, häufig, wenn Anfragen vom Typ „confirmable“ sind, so dass ein Vorhalten der entsprechenden bereits digital signierten weitere Vorteile mit sich bringt.
  • Erfindungsgemäß ist auch ein Endgerät zum sicheren Austauchen einer oder mehrerer Nachrichten mit weiteren Endgeräten in einem diese verbindenden Netzwerk vorgesehen, wobei das Endgerät ausgelegt ist, eine Nachricht zu erstellen, diese Nachricht digital zu signieren mit einem privaten Schlüssel, und die digital signierte Nachricht an wenigstens ein zweites Endgerät zu senden. Das Endgerät ist nun ausgelegt, die sendende Nachricht zu erstellen und digital zu signieren, bevor ein in Zusammenhang mit dem bestimmungsgemäßen Zusammenwirken der Endgeräte stehendes Ereignis das Senden der signierten Nachricht auslöst, wobei ein vom zweiten Endgerät auszuwertender Inhalt der erstellten Nachricht auf das Ereignis bezogen ist. Es ergeben sich dieselben Vorteile, wie sie mit Bezug auf das Verfahren und dessen Weiterbildungen beschrieben wurden.
  • Beispielsweise ist das erste Endgerät ausgelegt, das nachfolgende eintretende Ereignis und/oder die auf das Ereignis bezogene Nachricht vorauszuberechnen.
  • Ferner kann das erste Endgerät ausgelegt sein, die Vorausberechnung, das Erstellen und das digitale Signieren der Nachricht in einer Leerlaufphase des Endgeräts durchzuführen.
  • Weitere Vorteile, Merkmale und Einzelheiten der Erfindung ergeben sich aus den Ansprüchen, der nachfolgenden Beschreibung bevorzugter Ausführungsformen sowie anhand der Zeichnungen. In den Figuren bezeichnen gleiche Bezugszeichen gleiche Merkmale und Funktionen.
  • Figurenliste
  • Es zeigen:
    • 1A in schematischer Darstellung einen Überblick über ein beispielhaftes Netzwerk, in welchem ein erstes Endgerät eine Multicast-Nachricht an weitere Endgeräte derselben Gruppe sendet;
    • 1B wie 1A, wobei die weiteren Endgeräte eine Bestätigung an das erste Endgerät zurücksenden;
    • 2 in einem Flussdiagram den Ablauf eines Austauschs signierter Nachrichten zwischen Endgeräten der Gruppe gemäß einem konventionellen Ansatz;
    • 3 in einem Flussdiagram den Ablauf eines Austauschs digital signierter Nachrichten zwischen Endgeräten der Gruppe gemäß einem Ausführungsbeispiel der Erfindung;
    • 4 ein Flussdiagramm mit dem Block 40/50 aus 3 im Detail;
    • 5 ein schematisches Diagramm mit erfassten Messwerten zur Präsenz P von Personen in einem Raum eines Präsenzmelders aufgetragen gegen die Zeit t;
    • 6 ein schematisches Diagramm mit erfassten Messwerten der Temperatur T durch einen Temperatursensor aufgetragen gegen die Zeit t,
    • 7 in einer schematischen Darstellung den Aufbau einer CoAP-Nachricht.
  • Bevorzugte Ausführungsform(en) der Erfindung
  • In den 1A und 1B ist zunächst rein beispielhaft eine einem Ausführungsbeispiel der Erfindung zugrundeliegende Situation in einem hier drahtlosen oder kabelgebundenen (Leitungen nicht gezeigt) Funk-Netzwerk 10 schematisch dargestellt, das eine Gruppe von Endgeräten 12a, 12b, 12c, 12d und 12e verbindet. Es kann sich hierbei ohne Beschränkung der Allgemeinheit um ein Netzwerk 10 eines intelligenten Beleuchtungssystems oder eines Gebäudeautomationssystem handeln. Die Endgeräte können die für das bestimmungsgemäße Zusammenwirken im Beleuchtungs- oder Gebäudeautomationssystem jeweils erforderliche funktionale Einheit (z.B. Leuchten, Sensoren, Steuervorrichtungen, Aktoren für Jalousien etc.) sowie Kommunikationsbausteine mit Controllern und Antennen, jeweils ggf. einschl. Leistungsversorgung etc., umfassen (nicht gezeigt), durch welche die Endgeräte miteinander kommunizieren können.
  • Die Endgeräte bzw. deren Kommunikationsbausteine beinhalten jeweils 8-Bit-Mikrocontroller mit z.B. 512 kB Flash und 32 kB RAM oder ähnlich. Nach derzeitigen Maßstäben werden diese Endgeräte im Hinblick auf ihre vergleichsweise geringe Rechen- und Speicherkapazität zur Ausführung der Kommunikationsaufgaben als „Constrained Devices“ bezeichnet, wobei die angegebene Dimensionierung als derzeit aber auch durchaus üblich bezeichnet werden kann. Die Kommunikation im Netzwerk erfolgt dementsprechend rein beispielhaft auf Grundlage des darauf angepassten Anwendungsschichtprotokolls Constrained Application Protocol (abgekürzt CoAP), das im Dokument RFC7252 festgelegt ist. CoAP baut in der Transportschicht auf dem ebenfalls auf diese Situation angepassten User Datagram Protocol (abgekürzt UDP) gemäß dem in Dokument RFC768 festgelegten Standard auf.
  • In 1A ist gezeigt, dass ein erstes Endgerät 12a in einer als Multicast an alle vier anderen Endgeräte 12b - 12e gesendeten, folglich gleichlautenden CoAP-Nachricht 14 eine Anfrage (request) übermittelt. Die CoAP-Nachricht umfasst einen Nachrichtenkopf (message header) und einen Nachrichtenrumpf (message body), der auch die Nutzdaten enthält und den eigentlichen (semantischen oder Bedeutungs-) Inhalt trägt. In dem Beispiel beinhalten die Nachricht und insbesondere die Nutzdaten etwa eine vom ersten Endgerät 12a als Sensor erfasste Zustandsänderung, beispielsweise eine Information, dass ein vom Beleuchtungssystem erfasster Raum von einer Person betreten wurde, so dass die Endgeräte 12b - 12e als Leuchten infolge der Nachricht aktiviert werden müssten. Hierbei ist es gleichbedeutend, ob das erste Endgerät nur die Information über das entsprechende Ereignis („Person betritt Raum“) als solches oder bereits die inhaltlich konkrete Anfrage („Licht EIN“) sendet. Die Interpretation des Ereignisses kann beim Sender oder beim Empfänger vorgenommen werden.
  • Die CoAP-Nachricht 14 wird als „confirmable“ versendet, welches durch einen entsprechenden Eintrag in das den Typ der Nachricht kennzeichnende Feld T (vgl. 7) des Nachrichtenkopfs festgelegt werden kann. Die Empfänger, d.h., die Endgeräte 12b - 12e werden dadurch veranlasst, eine Antwort (response) mit dem Inhalt einer bloßen Bestätigung (über den Erhalt der Nachricht 14) zu senden, um die Zuverlässigkeit der Nachrichtenübertragung sicherzustellen. Die Übermittlung der vier CoAP-Antwort-Nachrichten 16 von den weiteren Endgeräten 12b - 12e an das erste Endgerät 12a ist in 1B gezeigt.
  • Die 1A und 1B verdeutlichen, dass in einem Fall, in welchem nicht alle der Endgeräte 12b - 12e sondern nur eine Untergruppe aus hier 1, 2 oder 3 Endgeräten vom der ersten Nachricht 14 angesprochen war, ein Problem dahingehend entstehen kann, dass das erste Endgerät nicht unterscheiden kann, von welchem der Endgeräte 12b - 12e welche CoAP-Antwort-Nachricht kam, d.h., die Zuordnung der Antworten zu den Endgeräten ist gegebenenfalls nicht ohne weiteres möglich. Im Fall der bloßen Bestätigung mit Antworte von nur 3 Endgeräten im Beispiel der 1B kann dann ggf. offen bleiben, welches Endgerät nicht zu antworten in der Lage ist. Um in solchen Fällen eine eindeutige Identifikation und zudem fälschungssichere Zuordnung zu ermöglichen, wird der Nachrichtenaustausch daher mit Authentifikation und digitaler Signatur durchgeführt.
  • Ein zeitlicher Ablauf des Nachrichtenaustauschs mit digitaler Signatur gemäß einem konventionellen Vorgehen ist in dem Flussdiagram der 2 gezeigt. Links ist der Ablauf auf Seite des ersten Endgeräts 12a, rechts der Ablauf auf Seite der weiteren Endgeräte 12b - 12e dargestellt. Im Beispiel des als Sensor (z.B. Präsenzmelder) ausgebildeten ersten Endgeräts 12a tritt z.B. ein Ereignis 18 dahingehend ein, dass der vom intelligenten Beleuchtungssystem erfasste Raum von einer Person betreten wird. Das Ereignis 18 bezeichnet die Zustandsänderung von „keine Person anwesend“ auf „Person anwesend“. Der Sensor erfasst diese Zustandsänderung und veranlasst den Kommunikationsbaustein bzw. Controller (z.B. anhand eines Signals) die oben gezeigte CoAP-Nachricht 14 bitweise zu erstellen (Schritt 20), wobei im Feld PL mit den Nutzdaten (siehe 7) der entsprechende Bedeutungsinhalt eingearbeitet ist, beispielsweise „Licht EIN“ in kodierter Form.
  • Im nachfolgenden Schritt 22 wird zu der erstellten CoAP-Nachricht vom ersten Endgerät 12a anhand eines nur diesem zugeordneten privaten Schlüssels eine digitale Signatur berechnet und diese dem Feld PL als weiteres Feld SIG angefügt (siehe 7).
  • Im Schritt 24 wird die somit digital signierte CoAP-Nachricht 14 vom ersten Endgerät 12a versendet, wie es in 1A dargestellt ist.
  • Im Schritt 26 empfangen die weiteren Endgeräte 12b - 12e die signierte Nachricht 14 und im Schritt 28 verifizieren diese Endgeräte 12b - 12e jeweils die Signatur bzw. authentifizieren die Nachricht als tatsächlich vom ersten Endgerät 12a originär abgesendete Nachricht. Im Schritt 30 erstellen die Endgeräte 12b - 12e jeweils ihre CoAP-Antwort-Nachricht 16 und berechnen ihrerseits im Schritt 32 anhand eines nur diesen jeweils zugeordneten privaten Schlüssels eine digitale Signatur und fügen diese der Nachricht an. Im Schritt 34 werden diese aufgrund der verschiedenen Signaturen unterschiedlichen CoAP-Nachrichten 16 zurückgesendet. Die Rücksendung erfolgt nicht als Multicast.
  • In den Schritten 36 und 38 empfängt das erste Endgerät 12a die CoAP-Antwort-Nachrichten 16 und verifiziert die Signatur bzw. authentifiziert die Nachrichten als von den betreffenden weiteren Endgeräten herrührend.
  • In den 3 und 4 ist ein entsprechender Ablauf des Austauschs digital signierter Nachrichten gemäß einem speziellen Ausführungsbeispiel der Erfindung gezeigt. Das Ausführungsbeispiel baut auf dem in den 1A, 1 B und 2 gezeigten Sachverhalt auf, so dass nur die zusätzlichen Schritte oder die Abwandlungen beschrieben werden. 3 zeigt, dass z.B. die Schritte 20, 22 und 24 des Erstellens, Signierens und Absendens der CoAP-Nachricht 14 in einem Multicast durch einen modifizierten Block 40 ersetzt werden, in welchem vom ersten Endgerät 12a eine nunmehr „vorab“ vorbereitete CoAP-Nachricht 14 versendet wird. Der Block 40 ist in genauerem Detail in 4 gezeigt. Auch auf der Seite der die CoAP-Nachricht 14 empfangenden weiteren Endgeräte 12b - 12e werden die Schritte 30, 32 und 34 des Erstellens, Signierens und Absendens der CoAP-Nachricht 14 jeweils in einem Unicast durch einen entsprechend modifizierten Block 50 ersetzt (vgl. ebf. 4).
  • Mit Bezug auf 4 wird in einem Schritt 42 vom ersten Endgerät 12a bzw. von einem zweiten Endgerät der weiteren Endgeräte 12b - 12e geprüft, ob ein als nächstes eintretendes Ereignis, eine entsprechende Zustandsänderung oder eine zugehörige Nachricht vorhersagbar ist. Im genannten Fall des Präsenzmelders als Sensor im ersten Endgerät kann dies mit einiger Sicherheit bejaht werden (Y/J), da es nur zwei zueinander komplementäre Zustände mit entsprechenden Ereignissen gibt (Person anwesend oder keine Person anwesend bzw. Nachricht „Licht EIN“ oder „Licht AUS“). Im Fall eines anderen Sensors, dessen aktuell wiedergegebener Zustand keine Rückschlüsse auf eine nächste Nachricht zulässt, würde die Prüfung zu einem „NEIN“ Schritt 42: N) führen, so dass hier zu einer konventionellen Nachrichtenerzeugung gemäß 2 übergegangen würde. Der Block 40 (bzw. 50) würde hier verlassen werden (nicht gezeigt).
  • Ist die Vorhersage der nächsten CoAP-Nachricht 14 möglich (Y/J), so wird diese im folgenden Schritt 44 vorausberechnet, ob wohl das gemäß in Zusammenhang mit dem bestimmungsgemäßen Zusammenwirken der Endgeräte stehende Ereignis 18 (d.h. hier die Meldung der Zustandsänderung zur Lichtsteuerung) noch gar nicht eingetreten ist. Im nächsten Schritt 46 wird zu der CoAP-Nachricht 14 eine digitale Signatur SIG berechnet und dieser am Ende des Nutzdatenteils PL hinzugefügt (vgl. 7. Die digital signierte CoAP-Nachricht 14 wird nun im RAM abgespeichert (nicht in 4 gezeigt).
  • Im Schritt 48 wird rekursiv geprüft, ob das der vorausberechneten, signierten CoAP-Nachricht unterliegende Ereignis 18 eingetreten ist („is triggered“). Tritt nun das Ereignis 18 ein (Ergebnis Y/J), so wird zum nächsten Schritt 24 fortgeschritten, in welchem die abgespeicherte, digital signierte CoAP-Nachricht 14 aus dem Speicher abgerufen wird, und dann wie konventionell die digital signierte CoAP-Nachricht 14 abgesendet wird. Im Schritt 54 endet der Block 40 (bzw. 50).
  • Analog wird auf Empfängerseite (Endgeräte 12b - 12e) nach dem Empfang (Schritt 26 wie oben) der digital signierten CoAP-Nachricht 14 im Schritt 28 wie konventionell zunächst die Verifikation der digitalen Signatur SIG vorgenommen. Anschließend werden die Schritte des modifizierten Blocks 50 durchlaufen (siehe 4), wobei auch die Antwort vorab verschlüsselt (Schritt 56) werden kann. Nicht gezeigt in 4 ist hier, dass auch die bloße Bestätigung des Erhalts der Nachricht 14 eine als solche vorhersagbare CoAP-Antwort-Nachricht 16 beinhaltet, die bereits vor dem Erhalt der CoAP-Nachricht 14 generiert, signiert und auf Abruf speichert werden kann, d.h., der Erhalt der CoAP-Nachricht 14 stellt selbst das auslösende Ereignis 18 dar. In 4 ist dagegen im Block 50 eine Nachrichtenerstellung gezeigt, die auf einem erst später (nämlich nach Erhalt der Nachricht 14) eintretenden Ereignis 18 beruht, das in der Antwort zurückzumelden ist.
  • Anhand der 5 wird erläutert, wie der in 4 gezeigte Block 40 (bzw. 50) angestoßen wird. Klar ist, dass die Schritte 42, 44 und 46 (bzw. 56) mit dem Vorhersagen/Vorausberechnen, Erstellen und Signieren der CoAP-Nachricht vor dem Eintritt des Ereignisses 18 ausgeführt werden. Im vorliegenden Fall des Präsenzmelders als Sensor im ersten Endgerät 12a kann es wie beschrieben nur zwei Zustände geben, welches in 5 binär durch „0“ und „1“ auf der die Personenpräsenz P wiedergebenden Ordinatenachse kenntlich gemacht ist. Auf der Abszissenachse bezeichnen die Zeitpunkte T1, T2. T3, ... Ereignisse 18, d.h. Zustandsänderungen, zu denen Personen den betreffenden Raum betreten oder verlassen haben.
  • Zum Zeitpunkt T1 wird vom ersten Endgerät 12a eine („vorherige“) CoAP-Nachricht 14 an die weiteren Endgeräte 12b - 12e versendet, die das Betreten des Raums meldet (Inhalt: „Licht EIN“). Nach dem Absenden der vorherigen CoAP-Nachricht 14 (Schritt 24 in 4) werden unmittelbar danach anstatt der sich für das erste Endgerät 12a anschließenden Leerlaufzeit, in welcher es auf Antworten wartet, die Schritte 42, 44 und 46 ausgeführt. Im vorliegenden Fall führt dabei der Schritt 42 mit dem Prüfergebnis Y/J zur Erzeugung einer nächsten CoAP-Nachricht 14, deren komplementärer Inhalt „Licht aus“ bedeutet. Diese wird anschließend sofort digital signiert und für die restliche Leerlauf- oder Wartezeit bis zum Abruf nach Eintritt des Ereignisses 18 gespeichert. Das Ereignis T2 entspricht hierbei dem vorhersagbaren nächsten Ereignis 18. Das Vorgehen setzt sich nach dem erneuten Absenden mit den Ereigniszeitpunkten T3, T4, usw. fort.
  • In 6 ist ein alternatives Ausführungsbeispiel gezeigt. Bei dem Sensor des ersten Endgeräts 12a handelt es sich hierbei um einen Temperatursensor, der in einem Gebäudeautomationssystem zur Steuerung einer Klimaanlage (als weiteres oder zweites Endgerät) beitragen soll. Der Temperatursensor meldet über CoAP-Nachrichten 14 das Erreichen oder Überschreiten von Temperaturgrenzwerten. Im Ausführungsbeispiel erfasst der Temperatursensor einen Temperaturanstieg. Das bestimmungsgemäße Zusammenwirken der Endgeräte sieht vor, dass ab 28°C die Klimaanlage durch eine Meldung „Klimaanlage EIN“ zu aktivieren ist. Das erste Endgerät 12a erfasst als Auslöser für die Schritte 42, 44, und 46 hierbei nicht das Absenden einer vorherigen Nachricht wie obigen Ausführungsbeispiel sondern einen niedrigeren Vor-Grenzwert, der hier auf 27°C gesetzt ist. Das Überschreiten dieses Grenzwertes dient hier also zum Anstoßen der vorab durchzuführenden Vorausberechnung, Erstellung und digitalen Signierung der CoAP-Nachricht 14. Die Vorausberechnung bzw. Vorhersage beinhaltet hierbei auch schon eine ggf. nicht mehr 100%-ige Wahrscheinlichkeit des Ereigniseintritts, da die Temperatur nach Überschreiten des Grenzwertes von 27°C auch wieder sinken kann. Ist dagegen der eigentliche Temperaturgrenzwert 28°C die einzig vorgegebene Schwelle für das Ein- oder Ausschalten der Klimaanlage, d.h. gibt es keine weiteren Stufen, so kann es auch nur zwei Ereignisse geben, nämlich dessen Über- oder Unterschreitung, so dass die Vorhersage des nächsten Ereignisses dann eindeutig ist.
  • Ein Beispiel für den Aufbau der erstellten und signierten CoAP-Nachricht 14 ist in 7 gezeigt. Der Nachrichtenkopf bzw. Message Header besteht aus der in 7 obersten Zeile mit: einer Protokollversion V (2 Bit), dem Nachrichtentyp TY (2 Bit), einer Token-Länge TL (4 Bit), einem Code C (8 Bit) und einer Message-ID MID (16 Bit), insgesamt also 32 Bit. Die Protokollversion V ist derzeit binär „01“, der Nachrichtentyp TY gibt - wie oben beschrieben - an, ob die Nachricht z.B. „confirmable“ (binär „00“) oder „non-confirmable“ (binär „01“) ist. Die Token-Länge TL kann variabel sein und bis zu 8 Bytes betragen, während die möglichen Werte von 9 bis 15 als Formatfehler betrachtet werden. Der Code C gibt an, ob die Nachricht eine Anfrage (request) oder eine Antwort (response) ist, wobei die 3 höherwertigen Bits die Klasse (z.B. request: binär „000“) und die restlichen 5 Bits das Detail, z.B. Anfragemethoden wie „GET“ (binär „00001 “) oder „POST“ (binär „00010“), beinhalten. Die Message-ID MID gibt die eindeutige Identifikationsnummer innerhalb eines Austauschvorgangs an.
  • Der Nachrichtenrumpf oder Message Body umfasst den Token TK mit der im Header angegebenen Token-Länge TL. Der Token TK ist eine den jeweiligen Nachrichtenaustausch als solche kennzeichnende Identifikationsnummer. Es folgen die Options OP, in denen Bündel von Anfrage- oder Antwortparametern hinterlegt sind. Es folgt ein festgelegter Payloadmarker PM (8 Bit), der das Ende der Options kennzeichnet und den Beginn der Nutzdaten (payload PL) markiert. Daran schließen sich gemäß Group OSCORE die Daten der digitalen Signatur SIG - genau genommen als Teil der Nutzdaten PL - an.
  • Es ist anzumerken, dass die oben beschriebenen Ausführungsbeispiele spezielle Ausführungsformen darstellen und den durch die beigefügten Ansprüche definierten Schutzumfang nicht eingrenzen. Insbesondere können auch einzelne Merkmale der einzelnen Ausführungsbeispiele in jeweils andere Ausführungsbeispiele oder Modifikationen kombiniert werden.
  • Bezugszeichenliste
    • 10
    Netzwerk
    12a
    erstes Endgerät
    12b - 12e
    zweites Endgerät, weitere Endgeräte
    14
    Nachricht, digital signierte CoAP-Nachricht (Request)
    16
    Nachricht, digital signierte CoAP-Nachricht (Response)
    18
    Ereignis
    20
    Erstellen der Nachricht
    22
    Signieren der Nachricht
    24
    Absenden der Nachricht
    26
    Empfangen der Nachricht
    28
    Verifizieren, Authentifikation
    30
    Erstellen der Nachricht (2. Endgerät)
    32
    Signieren der Nachricht (2. Endgerät)
    34
    Absenden der Nachricht (2. Endgerät)
    36
    Empfangen der Nachricht (1. Endgerät)
    38
    Verifizieren, Authentifikation (1. Endgerät)
    40
    Block mit Schritten zur Nachrichtenerstellung vorab
    42
    Vorhersage, Vorausberechnung
    44
    Erstellen der Nachricht vorab
    46
    Signieren der Nachricht vorab
    48
    Prüfen auf Ereigniseintritt
    50
    Block mit Schritten zur Nachrichtenerstellung vorab
    56
    Signieren der Nachricht vorab
    C
    Message Code
    MID
    Message ID
    OP
    Options
    PM
    Payloadmarker
    PL
    Payload
    SIG
    Digitale Signatur
    TK
    Token
    TL
    Token-Länge
    TY
    Nachrichtentyp
    V
    Version
  • 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 Nicht-Patentliteratur
    • Request for Comments 7252; Shelby, Z. et al.; ISSN: 2070-1721; Entwurf vom Juni 2014 [0007]
    • G., et al. https://tools.ietf.org/pdf/draft-ietf-core-object-security-15.pdf [0013]
    • Internet-Draft vom 22. Oktober 2018; Tiloca, M. et al.; https://tools.ietf.org/html/draft-ietf-core-oscore-groupcomm-03 [0014]

Claims (17)

  1. Verfahren zum sicheren Austauschen einer oder mehrerer Nachrichten (14, 16) zwischen Endgeräten (12a-12e) in einem diese verbindenden Netzwerk, umfassend die Schritte: Erstellen (44) einer Nachricht (14, 16) durch ein erstes Endgerät (12a); Digitales Signieren (46, 56) der Nachricht mit einem privaten Schlüssel des ersten Endgeräts; Senden der signierten Nachricht (14, 16) an wenigstens ein zweites Endgerät (12b-12e); dadurch gekennzeichnet, dass die Schritte des Erstellens (44) der zu sendenden Nachricht und des digitalen Signierens (46, 56) vom ersten Endgerät (12a) durchgeführt werden, bevor ein in Zusammenhang mit dem bestimmungsgemäßen Zusammenwirken der Endgeräte stehendes Ereignis (18) das Senden (48) der signierten Nachricht (14, 16) auslöst, wobei ein vom zweiten Endgerät (12b-12e) auszuwertender Inhalt der erstellten Nachricht (14, 16) auf das Ereignis (18) bezogen ist.
  2. Verfahren gemäß Anspruch 1, wobei das erste Endgerät (12a) einen Sensor umfasst und das Ereignis (18) einer von dem Sensor erfassten Änderung eines Zustands in einer Umgebung des Sensors entspricht.
  3. Verfahren gemäß Anspruch 1 oder 2, wobei das erste Endgerät (12a) das nachfolgende eintretende Ereignis (18) und/oder die auf das Ereignis (18) bezogene Nachricht (14, 16) vorausberechnet.
  4. Verfahren gemäß Anspruch 3, wobei das erste Endgerät (12a) die Vorausberechnung durchführt, indem eine Liste grundsätzlicher möglicher Ereignisse (18) oder Nachrichten (14, 16) erstellt wird und daraus im Vergleich mit dem zuletzt eingetretenen Ereignis oder der zuletzt abgesendeten Nachricht das als nächstes sicher oder zumindest mit einer Mindestwahrscheinlichkeit auftretende Ereignis beziehungsweise die darauf bezogene Nachricht ausgewählt wird.
  5. Verfahren gemäß einem der Ansprüche 1 bis 4, wobei das erste Endgerät (12a) die auf das Ereignis (18) bezogene, signierte Nachricht (14, 16) bis zum Eintritt des Ereignisses (18) speichert, und die Nachricht abruft und an das zweite Endgerät (12b-12e) sendet, wenn das Ereignis (18) eintritt.
  6. Verfahren gemäß einem der Ansprüche 1 bis 5, wobei das erste Endgerät (12a) die Schritte des Erstellens (44) und Signierens (46, 56) der Nachricht (14, 16) durchführt, - unmittelbar nachdem vorher eine weitere, auf ein vorhergehendes Ereignis (18) bezogene Nachricht abgesendet wurde, oder - während einer Leerlaufphase zwischen dem Absenden zweier Nachrichten.
  7. Verfahren gemäß einem der vorhergehenden Ansprüche, wobei die Endgeräte einschließlich des ersten (12a) und des zweiten Endgeräts (12b-12e) und das diese verbindende Netzwerk (10) Teil eines intelligenten Gebäudeautomations- und/oder Beleuchtungssystems sind und eine Gruppe für sichere Kommunikation ausbilden, wobei die digital signierte Nachricht (14, 16) von dem ersten Endgerät (12a) in einem Multicast an alle weiteren Endgeräte (12b-12e) einschließlich des zweiten Endgeräts gesendet wird.
  8. Verfahren gemäß Anspruch 7, soweit direkt oder mittelbar rückbezogen auf Anspruch 2, wobei der Sensor ein Präsenzmelder zum Melden einer Anwesenheit von Personen in einer Umgebung des Präsenzmelders ist, und wobei das zweite Endgerät (12a) eine Leuchte umfasst, die abhängig von Nachrichten des Präsenzmelders betrieben wird, wobei das Ereignis (18) der Erfassung des Auftretens oder Verlassens einer oder mehrerer Personen in der Umgebung des Präsenzmelders entspricht, wobei das erste Endgerät in dem Fall, in welchem das zuletzt eingetretene Ereignis der Erfassung des Auftretens der einen oder mehreren Personen entspricht, als nächstes einzutretendes Ereignis (18), für das die Nachricht (14, 16) zu erstellen ist, bevor es eintritt, das entsprechend komplementäre Ereignis (18) auswählt, welches der Erfassung des Verlassens der einen oder mehreren Personen in der Umgebung entspricht, und umgekehrt.
  9. Verfahren gemäß Anspruch 7, soweit direkt oder mittelbar rückbezogen auf Anspruch 2, wobei der Sensor einen Temperatursensor zum Melden einer Temperatur umfasst, und wobei das zweite Endgerät (12b-12e) eine Klimaanlage umfasst, die abhängig von Nachrichten des Temperatursensors betrieben wird, wobei das Ereignis (18) einer Erfassung des Über- oder Unterschreitens eines vorgegebenen Temperaturgrenzwerts entspricht, wobei das erste Endgerät (12a) aus zumindest einem zuletzt eingetretenen Ereignis der Erfassung des Über- oder Unterschreitens eines weiteren, niedrigeren oder höheren vorgegebenen Temperaturgrenzwerts durch Extrapolation das nächste einzutretende Ereignis vorausberechnet, für das die Nachricht (14, 16) zu erstellen ist, bevor es eintritt.
  10. Verfahren gemäß einem der vorhergehenden Ansprüche, wobei Nachrichten im Netzwerk auf der Anwendungsschicht gemäß dem in RFC7252 festgelegten Constrained Application Protocol, CoAP, basierend auf der Transportschicht gemäß dem in RFC768 festgelegten User Datagram Protocol, UDP, ausgetauscht werden.
  11. Verfahren gemäß Anspruch 10, wobei die Nachricht (14, 16) digital signiert wird (46, 56) mit einem Signaturalgorithmus basierend auf elliptischen Kurven, insbesondere ECDSA oder Ed25519.
  12. Verfahren gemäß Anspruch 10 oder 11, wobei die digital signierte Nachricht (14, 16) zusätzlich mit einem für alle Endgeräte der Gruppe zugänglichen öffentlichen Schlüssel verschlüsselt wird.
  13. Verfahren gemäß einem der vorhergehenden Ansprüche, wobei das zweite Endgerät (12b-12e) die digital signierte Nachricht (14) empfängt und in einem weiteren Schritt (28, 38) die digitale Signatur des ersten Endgeräts (12a) verifiziert, wobei das zweite Endgerät (12b-12e) entsprechend vor und nach dem Empfang der digital signierten Nachricht (14) des ersten Endgeräts (12a) die gleichen Schritte (44, 56, 48) ausführt wie das erste Endgerät (12a), vorzugsweise mit der Maßgabe, dass das betreffende Ereignis (18) der Empfang der digital signierten Nachricht (14) des ersten Endgeräts (12a) selbst ist, so dass das zweite Endgerät (12b-12e) eine weitere, die Antwort auf die digital signierte Nachricht des ersten Endgeräts (12a) betreffende Nachricht (16) erstellt (44) und digital signiert (56), bevor es die digital signierte Nachricht (14) des ersten Endgeräts (12a) empfängt, und diese weitere digital signierte Nachricht abhängig vom Empfang der digital signierten Nachricht (14) des ersten Endgeräts (12a) an das erste Endgerät (12a) zurücksendet.
  14. Verfahren gemäß Anspruch 13, wobei die weitere digital signierte Nachricht (16) eine bloße Bestätigung über den Empfang der digital signierten Nachricht des ersten Endgeräts (12a) ohne Nutzdaten (PL) ist.
  15. Endgerät (12a, 12b-12e) zum sicheren Austauchen einer oder mehrerer Nachrichten mit weiteren Endgeräten in einem diese verbindenden Netzwerk, wobei das Endgerät (12a, 12b-12e) ausgelegt ist, eine Nachricht (14, 16) zu erstellen (44); diese Nachricht digital zu signieren (46, 56) mit einem privaten Schlüssel; die digital signierte Nachricht an wenigstens ein zweites Endgerät (12a, 12b-12e) zu senden (48); dadurch gekennzeichnet, dass das Endgerät (12a, 12b-12e) ausgelegt, die zu sendende Nachricht (14, 16) zu erstellen und digital zu signieren, bevor ein in Zusammenhang mit dem bestimmungsgemäßen Zusammenwirken der Endgeräte stehendes Ereignis (18) das Senden der signierten Nachricht auslöst, wobei ein vom zweiten Endgerät auszuwertender Inhalt der erstellten Nachricht auf das Ereignis bezogen ist.
  16. Endgerät (12a, 12b-12e) gemäß Anspruch 15, wobei das erste Endgerät ausgelegt ist, das nachfolgende eintretende Ereignis und/oder die auf das Ereignis (18) bezogene Nachricht (14, 16) vorauszuberechnen.
  17. Endgerät (12a, 12b-12e) gemäß Anspruch 16, wobei das erste Endgerät ausgelegt ist, die Vorausberechnung (42), das Erstellen (44) und das digitale Signieren (46) der Nachricht (14, 16) in einer Leerlaufphase des ersten Endgeräts (12a, 12b-12e) durchzuführen.
DE102019204951.6A 2019-04-08 2019-04-08 Verfahren zum sicheren austauschen von nachrichten zwischen endgeräten in einem netzwerk Withdrawn DE102019204951A1 (de)

Priority Applications (2)

Application Number Priority Date Filing Date Title
DE102019204951.6A DE102019204951A1 (de) 2019-04-08 2019-04-08 Verfahren zum sicheren austauschen von nachrichten zwischen endgeräten in einem netzwerk
US16/843,038 US20200322166A1 (en) 2019-04-08 2020-04-08 Method for the secure exchange of messages between terminal devices in a network

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
DE102019204951.6A DE102019204951A1 (de) 2019-04-08 2019-04-08 Verfahren zum sicheren austauschen von nachrichten zwischen endgeräten in einem netzwerk

Publications (1)

Publication Number Publication Date
DE102019204951A1 true DE102019204951A1 (de) 2020-10-08

Family

ID=72518836

Family Applications (1)

Application Number Title Priority Date Filing Date
DE102019204951.6A Withdrawn DE102019204951A1 (de) 2019-04-08 2019-04-08 Verfahren zum sicheren austauschen von nachrichten zwischen endgeräten in einem netzwerk

Country Status (2)

Country Link
US (1) US20200322166A1 (de)
DE (1) DE102019204951A1 (de)

Citations (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
DE102007031738A1 (de) * 2007-07-06 2009-01-08 Audi Ag Verfahren und System zur Sicherung der Datenübertragung zwischen mindestens zwei Bordelektronikkomponenten eines Kraftfahrzeugs
US20140365026A1 (en) * 2013-06-11 2014-12-11 Kabushiki Kaisha Toshiba Signature generating apparatus, signature generating method, computer program product, and electrical power consumption calculation system

Family Cites Families (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
DE102007016538A1 (de) * 2007-04-05 2008-10-09 Infineon Technologies Ag Kommunikationsendgerät, Kommunikationseinrichtung, elektronische Karte, Verfahren für ein Kommunikationsendgerät und Verfahren für eine Kommunikationseinrichtung zum Bereitstellen eines Nachweises
US9734697B1 (en) * 2016-04-01 2017-08-15 Google Inc. Automatic notify mode for security system
CN107809411B (zh) * 2016-09-09 2021-12-03 华为技术有限公司 移动网络的认证方法、终端设备、服务器和网络认证实体

Patent Citations (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
DE102007031738A1 (de) * 2007-07-06 2009-01-08 Audi Ag Verfahren und System zur Sicherung der Datenübertragung zwischen mindestens zwei Bordelektronikkomponenten eines Kraftfahrzeugs
US20140365026A1 (en) * 2013-06-11 2014-12-11 Kabushiki Kaisha Toshiba Signature generating apparatus, signature generating method, computer program product, and electrical power consumption calculation system

Also Published As

Publication number Publication date
US20200322166A1 (en) 2020-10-08

Similar Documents

Publication Publication Date Title
EP2471243B1 (de) Verfahren zum übertragen von daten in einem sensornetzwerk, sensorknoten und zentral-rechner
EP2324595B1 (de) Verfahren zur datenübertragung zwischen netzwerkknoten
DE102004016580B4 (de) Verfahren zur Übertragung von Daten in einem Ad Hoc Netzwerk oder einem Sensornetzwerk
DE102012223124A1 (de) Fahrzeugkommunikationssteuervorrichtung
EP3718265A1 (de) Anbindungsvorrichtung für einen datenaustausch zwischen einem feldbusnetzwerk und einer cloud
DE102012206529A1 (de) Drahtloses Echtzeitübertragungssystem
DE102021202075A1 (de) Verfahren zur Validierung von Nachrichten
EP2695324B1 (de) Verfahren zum aussenden von nachrichten mit integritätsschutz
EP2989743B1 (de) Verfahren und system zur geschützten gruppenkommunikation mit sender-authentisierung
WO2021122362A1 (de) Kommunikation zwischen netzwerken eines kraftfahrzeugs
DE102017125371A1 (de) Verfahren zum Übertragen von Daten und Datensammler
DE102019204951A1 (de) Verfahren zum sicheren austauschen von nachrichten zwischen endgeräten in einem netzwerk
WO2013174578A1 (de) Verfahren und vorrichtung zur erzeugung kryptographisch geschützter redundanter datenpakete
DE102016208451A1 (de) Verfahren zur Erzeugung eines Geheimnisses oder eines Schlüssels in einem Netzwerk
WO2022189561A1 (de) Kommunikationsverfahren und kommunikationsteilnehmer
DE102008009691A1 (de) Verfahren für die Gebäudeautomatisierung
DE102012210816A1 (de) Datenpaket für eine bidirektionale Übertragung von Datenpaketen bei einer Datenübertragung zwischen einem ersten und einem zweiten Kommunikationsgerät sowie Verfahren zum Übertragen eines solchen Datenpaketes
AT14014U1 (de) Verfahren zum sicheren Betrieb von Verbundnetzen, insbesondere von Windpark- oder anderen ausgedehnten Netzen
AT506274B1 (de) Verfahren zum erstellen und versenden wenigstens eines datenpakets sowie verwendung hiefür
EP1500249B1 (de) Verfahren und vorrichtung zum übertragen von datenpaketen in einem kommunikationssystem bei verwendung pep und eines ran
DE102010011656A1 (de) Verfahren und Vorrichtung zum kryptographischen Sichern einer Datenübertragung zwischen Netzwerkknoten
EP2751972B1 (de) Verfahren zur daten uebertragung
DE10218811B4 (de) Verfahren und Vorrichtung zum Übertragen von Datenpaketen in einem funkgestützten Kommunikationssystem bei Verwendung eines PEP
DE102018008721A1 (de) Anbindung eines Endgeräts an einen Datendienst
WO2017064010A1 (de) Verfahren zur generierung eines geheimnisses in einem netzwerk

Legal Events

Date Code Title Description
R163 Identified publications notified
R119 Application deemed withdrawn, or ip right lapsed, due to non-payment of renewal fee