[go: up one dir, main page]

DE202012003716U1 - Vorrichtung für ein skalierbares und sicheres Transportprotokoll zur Sensordatenerfassung - Google Patents

Vorrichtung für ein skalierbares und sicheres Transportprotokoll zur Sensordatenerfassung Download PDF

Info

Publication number
DE202012003716U1
DE202012003716U1 DE202012003716U DE202012003716U DE202012003716U1 DE 202012003716 U1 DE202012003716 U1 DE 202012003716U1 DE 202012003716 U DE202012003716 U DE 202012003716U DE 202012003716 U DE202012003716 U DE 202012003716U DE 202012003716 U1 DE202012003716 U1 DE 202012003716U1
Authority
DE
Germany
Prior art keywords
server
client
state
message
data
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.)
Expired - Lifetime
Application number
DE202012003716U
Other languages
English (en)
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.)
Thales DIS France SA
Original Assignee
Alcatel Lucent SAS
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 Alcatel Lucent SAS filed Critical Alcatel Lucent SAS
Publication of DE202012003716U1 publication Critical patent/DE202012003716U1/de
Anticipated expiration legal-status Critical
Expired - Lifetime legal-status Critical Current

Links

Images

Classifications

    • 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/0838—Key agreement, i.e. key establishment technique in which a shared key is derived by parties as a function of information contributed by, or associated with, each of these
    • 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/0807—Network architectures or network communication protocols for network security for authentication of entities using tickets, e.g. Kerberos
    • 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)
    • 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/0838—Key agreement, i.e. key establishment technique in which a shared key is derived by parties as a function of information contributed by, or associated with, each of these
    • H04L9/0841—Key agreement, i.e. key establishment technique in which a shared key is derived by parties as a function of information contributed by, or associated with, each of these involving Diffie-Hellman or related key agreement protocols
    • H04L9/0844—Key agreement, i.e. key establishment technique in which a shared key is derived by parties as a function of information contributed by, or associated with, each of these involving Diffie-Hellman or related key agreement protocols with user authentication or key authentication, e.g. ElGamal, MTI, MQV-Menezes-Qu-Vanstone protocol or Diffie-Hellman protocols using implicitly-certified keys
    • 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/0861—Generation of secret information including derivation or calculation of cryptographic keys or passwords
    • H04L9/0866—Generation of secret information including derivation or calculation of cryptographic keys or passwords involving user or device identifiers, e.g. serial number, physical or biometrical information, DNA, hand-signature or measurable physical characteristics
    • 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/3297—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 time stamps, e.g. generation of time stamps
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W4/00—Services specially adapted for wireless communication networks; Facilities therefor
    • H04W4/70—Services for machine-to-machine communication [M2M] or machine type communication [MTC]
    • 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
    • Y—GENERAL TAGGING OF NEW TECHNOLOGICAL DEVELOPMENTS; GENERAL TAGGING OF CROSS-SECTIONAL TECHNOLOGIES SPANNING OVER SEVERAL SECTIONS OF THE IPC; TECHNICAL SUBJECTS COVERED BY FORMER USPC CROSS-REFERENCE ART COLLECTIONS [XRACs] AND DIGESTS
    • Y04—INFORMATION OR COMMUNICATION TECHNOLOGIES HAVING AN IMPACT ON OTHER TECHNOLOGY AREAS
    • Y04S—SYSTEMS INTEGRATING TECHNOLOGIES RELATED TO POWER NETWORK OPERATION, COMMUNICATION OR INFORMATION TECHNOLOGIES FOR IMPROVING THE ELECTRICAL POWER GENERATION, TRANSMISSION, DISTRIBUTION, MANAGEMENT OR USAGE, i.e. SMART GRIDS
    • Y04S40/00—Systems for electrical power generation, transmission, distribution or end-user application management characterised by the use of communication or information technologies, or communication or information technology specific aspects supporting them
    • Y04S40/20—Information technology specific aspects, e.g. CAD, simulation, modelling, system security

Landscapes

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

Abstract

Sensorvorrichtung zum Bereitstellen einer sicheren Kommunikation mit einem Server in einem Kommunikationsnetzwerk, wobei die besagte Vorrichtung umfasst:
Eine Kommunikationsschnittstelle, um es der besagten Sensorvorrichtung zu ermöglichen, über ein Kommunikationsnetzwerk zu kommunizieren; und
einen Prozessor, der, wenn er mit einem ausführbaren Programmcode programmiert ist, betreibbar ist, um:
Eine Verbindungsanforderung an den besagten Server zu senden;
von dem besagten Server eine Bestätigungsnachricht zu empfangen, wobei die besagte Bestätigungsnachricht ein Zustands-Token enthält, welches einen Assoziationszustand zwischen dem besagten Client und dem besagten Server darstellt;
von dem besagten Client an den besagten Server unter Verwendung des besagten Zustands-Token zu kommunizieren, wobei der besagte Assoziationszustand zwischen dem besagten Client und dem besagten Server vorübergehend bei dem besagten Client gespeichert und nicht an dem besagten Server behalten wird, wobei der besagte Zustands-Token in Kommunikationen von dem besagten Client an den besagten Server benutzt wird, um es dem besagten Server zu...

Description

  • TECHNISCHER ANWENDUNGSBEREICH
  • Die Erfindung betrifft allgemein Kommunikationssysteme, und insbesondere Datenerfassungssysteme für Maschine-zu-Maschine-Kommunikationen, wie beispielsweise ein intelligentes Stromnetz (smart electrical grid).
  • HINTERGRUND DER ERFINDUNG
  • Die beschränkte Kommunikations- und Sicherheitsfähigkeit von nicht IP-basierten Netzwerken, die gegenwärtig in Versorgungsnetzen eingesetzt werden, sind entscheidende Hindernisse für den zukünftigen Einsatz von Smart Grids, welche auf eine Verbesserung der Energieeffizienz, der Systemstabilität gegenüber Stromversorgungsunterbrechungen und auf die Reduzierung von Kohlendioxidemissionen durch Einbeziehen von erneuerbaren Energiequellen abzielen. Daher sieht sich die Energieindustrie durch die Konzeption eines neuen IP-basierten Smart-Grid-Kommunikationsnetzwerks mit erhöhter Sicherheit und Zuverlässigkeit mit einer bedeutenden Netzwerkumrüstung konfrontiert.
  • Kennzeichnend für das Smart-Grid-Kommunikationsnetzwerk ist der großskalige Einsatz von Sensoren und intelligenten Messgeräten, welche periodische Aktualisierungen an das Stromversorgungskontrollzentrum senden; so müssen beispielsweise in Manhattan, New York, mehrere Millionen Messgeräte eingesetzt werden, um alle Kundenhaushalte abzudecken. Von dem derzeit eingesetzten IP-Netzwerk wird erwartet, dass es Sensordaten auf verlässliche (sichere und zuverlässige) Weise bis hin zu den Stromversorgungskontrollzentren transportieren, wo die Daten benutzt werden, um den Netzzustand und den momentanen Stromverbrauch zu bewerten. Die Sensoren, die die Daten erzeugen, sind jedoch typischerweise hinsichtlich ihrer Rechenleistung begrenzte Entitäten.
  • Die Erfassung von Sensordaten ist Bestandteil der Smart-Grid-Kommunikation. Es wird erwartet, dass der von Sensoren oder Messgeräten, welche typischerweise außerhalb des Sicherheitsbereichs der Stromversorgung angeordnet sind, erzeugte Datenverkehr über ein für den speziellen Zweck errichtetes Versorgungsnetz transportiert wird. Das für diesen Zweck errichtete Versorgungsnetz ist von dem äußerst kritischen SCADA-basierten Kommunikationsnetzwerk isoliert. Angesichts der erheblichen Sicherheits- und Verfügbarkeitsprobleme, die auftreten, wenn Nutzdatenverkehr mit Internet-Datenverkehr gemultiplext wird, ist es ebenfalls vom öffentlichen Internet isoliert.
  • Die allgemeinen Merkmale von Smart-Grid-Sensordaten können wie folgt beschrieben werden. Erstens werden die Daten über semi-permanente Sicherheits- und Transportassoziationen zwischen Sensoren und versorgungsseitigen Servern transportiert. Zweitens werden auf dem zu diesem Zweck errichteten Versorgungsnetz Daten in Richtung des Energieversorgers (Northbound-Daten), wie beispielsweise die Zählerstände, periodisch erfasst; im Gegensatz dazu sind von dem Energieversorger (Southbound-Daten) stammende Daten, wie beispielsweise Verwaltungsinformationen, verhältnismäßig selten. Dies bedeutet, dass Northbound-Daten den Verbrauch von Netzwerkressourcen im Vergleich zu Southbound-Daten dominieren würden. Drittens müssen Northbound-Daten zuverlässig und zeitgerecht für eine präzise Bewertung von instabilitätsbedingten Verhältnissen, wie beispielsweise ein bedeutendes Missverhältnis zwischen einem momentanen Stromverbrauch und der Stromversorgung auf der Basis einer Day-Ahead-Prognose der Nachfrage, geliefert werden. Im Vergleich hierzu sind Southbound-Daten an Sensoren und Messgeräte für eine zuverlässige und zeitgerechte Lieferung unkritisch, da diese Informationen leicht von neuen Daten überschrieben werden können. Viertens ist eine sichere Kommunikation, welche die Datenglaubwürdigkeit gewährleistet, für einen sicheren Versorgungsnetzbetrieb erforderlich. Wir weisen darauf hin, dass Sicherheitsanforderungen nicht unbedingt symmetrisch sein müssen. So ist die Authentifizierung beispielsweise für die Lieferung der Southbound-Elektrizitätspreisinformationen obligatorisch, jedoch ist keine Vertraulichkeit erforderlich. Im Gegensatz hierzu sind sowohl die Authentifizierung als auch die Vertraulichkeit für die Northbound-Messdaten kritisch. Zuletzt ist es unwahrscheinlich, dass Feldsensoren aufgrund von begrenzten Rechenressourcen über einen kompletten Satz von Betriebssystemen und Protokollstapeln verfügen, während versorgungsseitige Server reichlich vorhandene Rechenressourcen aufweisen, um die bedeutende Menge von von der großen Anzahl von eingesetzten Sensoren empfangenen Daten zu verarbeiten. Zum Beispiel bieten die in zahlreichen Sensor-Hardware-Plattformen eingesetzten TI MSP 430-Mikrocontroller-Serien 2–18 KB RAM, 1–256 KB EPROM und 8–16 MHz CPU:. eine Teilmenge von Betriebssystem- und Protokolleigenschaften kann für die Plattformen installiert werden; allerdings müssen die Daten aufgrund des Mangels an Speicherplatz an Server in einem Versorgungsnetz geliefert werden. Nach bestem Wissen des Erfinders gibt es kein veröffentlichtes Protokoll, welches die vorstehenden Datentransportanforderungen in einer skalierbaren und leichtgewichtigen Weise erfüllt.
  • ZUSAMMENFASSENDE BESCHREIBUNG DER ERFINDUNG
  • Ein Fortschritt gegenüber dem Stand der Technik liegt gemäß den Grundsätzen der vorliegenden Erfindung in einem neuen Konzept für ein Transportprotokoll zur Sensordatenerfassung, wie beispielsweise ein Smart Grid. In einer Ausführungsart der Erfindung wird durch den Begriff eines sicheren „Zustands-Token” vermieden, dass jeder Server den Sicherheits- und Kommunikationszustand pro Client behält. Der Zustands-Token wird mit jeder Server-Nachricht ausgegeben und anschließend den entsprechenden an den Server gelieferten Clientnnachrichten beigefügt. In einer Implementierung verschlüsselt und authentifiziert der Server den zugehörigen Sitzungszustand und stellt die sich ergebende Verschlüsselung anschließend für den Client bereit, um sie vorübergehend zu speichern und in einer nächsten Nachricht an den Server zurückzusenden. Auf diese Weise behält der Server den Sitzungszustand nicht, nachdem die Verschlüsselung an einen Client zurückgesendet wurde, und kann den Sitzungszustand schnell wiederherstellen, wenn die nächste Nachricht vom Client eintrifft.
  • In bestimmten Ausführungsformen der Erfindung werden ein Verfahren und ein System zur sicheren Kommunikation zwischen einem Client und einem Server in einem Kommunikationsnetzwerk beschrieben. Das Verfahren umfasst das Senden einer Verbindungsanforderung von dem Client an den Server und das Empfangen, von dem Server, einer Bestätigungsnachricht, wobei die Bestätigungsnachricht einen Zustands-Token enthält, welcher einen Assoziationszustand zwischen dem Client und dem Server darstellt. Die Kommunikation vom Client zum Server erfolgt unter Verwendung des Zustands-Tokens, wobei der Assoziationszustand zwischen dem Client und dem Server vorübergehend beim Client gespeichert und nicht am Server behalten wird. Der Zustands-Token wird in Kommunikationen vom Client zum Server benutzt, um es dem Server zu ermöglichen, den Sitzungszustand zwischen dem Client zu überprüfen und wiederherzustellen, um dadurch Nachrichten vom Client zu verarbeiten.
  • KURZBESCHREIBUNG DER ZEICHNUNG
  • Die Lehren der vorliegenden Erfindung sind anhand der nachfolgenden detaillierten Beschreibung in Verbindung mit den beigefügten Zeichnungen leicht verständlich, wobei:
  • 1 eine beispielhafte Ausführungsform eines Verbindungsaufbauverfahrens für das Transportprotokoll der vorliegenden Erfindung darstellt;
  • 2 eine beispielhafte Ausführungsform eines Datentransferverfahrens für das Transportprotokoll der vorliegenden Erfindung darstellt;
  • 3 Vergleiche der durchschnittlichen Ende-zu-Ende-Verzögerung für das Transportprotokoll der vorliegenden Erfindung im Vergleich zu anderen Protokollen darstellt; und
  • 4 eine beispielhafte Ausführungsform eines High-Level-Blockdiagramms eines Sensors und eines Servers für die Verwendung gemäß dem Verfahren der vorliegenden Erfindung darstellt.
  • DETAILLIERTE BESCHREIBUNG
  • Ausführungsformen der vorliegenden Erfindung beziehen sich auf ein skalierbares und sicheres Transportprotokoll SSTP für die Erfassung von Smart-Grid-Daten. In bestimmten Ausführungsformen besteht ein wichtiger Aspekt des SSTP darin, dass es nicht erforderlich ist, dass ein Server Zustände (für Sicherheit und Kommunikation) auf einer Pro-Client-Basis behält. Es wird ein inhärentes und leichtgewichtiges Sicherheitsschema für das SSTP-Protokoll bereitgestellt, wodurch die kostspielige Abhängigkeit von der Unterstützung für TLS oder IPSec. entfällt. Zusätzlich wird ein Zustands-Token-Konzept offengelegt, welches den Einsatz von skalierbaren zustandslosen Servern für die Erfassung der Daten ermöglicht. Ein bedeutender Sicherheits- und Transportvorteil des Einsatzes eines zustandslosen Servers liegt darin, dass SYN-Flooding (Synchronisationsnachricht, die Verbindungsanforderung in TCP) von einer großen Anzahl von Client, welches von einem Neustart oder Ausfall des Servers verursacht wird, vermieden werden kann. In der Tabelle 1, werden einige der Merkmale von derzeitigen Transport- und Sicherheitsprotokollen dargestellt und die Notwendigkeit für die Entwicklung eines neuen skalierbaren Transportprotokolls für die Erfassung von Smart-Grid-Daten hervorgehoben. Basierend auf dieser Darstellung lässt sich zeigen, dass derzeitige Transportprotokolle nicht die Sicherheits- und Zuverlässigkeitsmerkmale des Smart-Grid-Sensordatennetzwerks in einer skalierbaren und leichtgewichtigen Weise erfüllen. TABLE I: FEATURES OF TRANSPORT PROTOCOLS
    Feautures TCP SCTP SSTP
    Secutity Schemes TLS or IPSec TLS or IPSec Inherent built-in
    Flooding Attacks Coockie [5-6] Coockie [7] Coockie [6]
    Connection Establishment Three-way handshake Four-way handshake Four-way handshake
    Duples. Comm. Yes Yes Mostly simplex
    Reliable Delivery ACK with SACK ACK with SACK ACK
    In-ordered delivery Mandatory Optional None
    Sender-side delay Congestion Control Congestion Control None
    Receiver-side delay Delayed ACK Delayed ACK None
    Flow Control Receiving window Receiving window Sending window
    Transmission or Reception Buffer 128 KB per connection 128 KB per connection Chosen by applications
    Multi-homing/stream No Yes No
  • In Bezug auf die Sicherheit und Skalierbarkeit wird aus der Tabelle 1 ersichtlich, dass keines der allgemein bekannten Protokolle über inhärente Datenauthentifizierungs- und Vertraulichkeitserweiterungen verfügen, um Lauschangriffe, Manipulation oder Nachrichtenverfälschungen zu verhindern. Stattdessen werden typischerweise externe Mechanismen, wie beispielsweise TLS oder IPSec zur Gewährleistung der Datensicherheit eingesetzt. Dies ist in sich nicht problematisch; allerdings führt es zu einem erheblichen Aufwand in Bezug auf Verhandlungsverfahren, um Endgeräte mit geringer Rechenfähigkeit zu bedienen. Außerdem bestehen Bedenken, ob TCP und SCTP eine Ende-zu-Ende-Sicherheit für großskalierte und langlebige Kommunikationsumgebungen in skalierbarer Weise adressieren können. Ziehen wir einmal das stundenweise Ablesen von Zählern in der Stadt New York in Betracht. Aus der Perspektive der Vernetzung gesehen senden Messgeräte gemessene Daten entweder an ein entfernt gelegenes Stromversorgungskontrollzentrum (UCC) oder an nahegelegene Aggregatoren, ab welchen die Daten an das Stromversorgungs-UCC (geteilte Aggregation) weitergeleitet werden. Im ersten Fall muss ein UCC für eine gegebene Anzahl N von Messgeräten entweder permanent O(N)-Zustände (Sicherheitsinfo, tx/rx-Puffer, Konnektivitätsinfo) behalten oder O(N)-Anforderungen pro Stunde für sichere Verbindungen für das Ablesen von Zählerständen verarbeiten. Keine dieser Vorgehensweisen kann Skalierbarkeitsbedenken und Single Points of Bottlenecks/Failure in dem UCC verhindern. Andererseits mag das Konzept der geteilten Aggregation in Bezug auf Leistung und Skalierbarkeit vorteilhafter sein. Leider gefährdet dieses Konzept die Ende-zu-Ende-Vertraulichkeit, da es keine TLS(oder IPSec)-Sitzung, welche von Messgeräten zum UCC reichen, behalten. Demzufolge müssen Daten an den Aggregatoren entschlüsselt und anschließend wieder verschlüsselt werden. Zusätzlich ist der für das Ausführen von TLS in Verbindung mit entweder TCP oder SCTP erforderliche Aufwand (Speicherbedarf und CPU-Belastung) für Endgeräte mit begrenzten Ressourcen kostspielig.
  • In Bezug auf die Verfügbarkeit und Skalierbarkeit kann es mit den bestehenden, altbekannten verbindungsorientierten Transportprotokollen zu SYN-Flooding kommen, wenn ein mit einer großen Anzahl von Sensoren und Messgeräten assoziierter versorgungsseitiger Server abrupt neugestartet wird oder ausfällt. Alle mit diesem Server assoziierten Sensoren werden darin gleichzeitig Tausende von Verbindungsanforderungen an den Server senden, um deren Sicherheitsassoziationen mit dem Energieversorger so schnell wie möglich wiederherzustellen. Dies würde unmittelbar nach einem Neustart oder einem Stromausfall erfolgen, unabhängig von der Notwendigkeit, irgendwelche Daten an das UCC zu senden. Demzufolge müssen Transportprotokolle für die Erfassung von Smart-Grid-Daten dem SYN-Flooding-Problem Rechnung tragen und ebenfalls fähig sein, langlebige Assoziationen skalierbar zu verwalten.
  • In Bezug auf TCP-Latenz & Zuverlässigkeit kann eine Reihenfolge-Lieferung von TCP die Letenz durch häufiges Paktverwerfen in Routern oder Paketverlust über drahtlose Verbindungen erheblich erhöhen. TCP-Empfänger Puffern diese empfangenen Segmente, welcher höher als die erwartete Sequenznummer sind. Dadurch wird vermieden, dass Daten an eine entsprechende Anwendung geliefert werden, bis ein Segment mit der erwarteten Sequenznummer eintrifft. Diese Re-Sequenzierungsverzögerung im Empfänger führt zu einer erhöhten Ende-zu-Ende-Latenz. Allerdings ist für den Transport von Smart-Grid-Daten keine Reihenfolge-Lieferung erforderlich, da die Daten senderseitig immer mit einem Zeitstempel versehen werden. Es wird darauf hingewiesen, dass die Reihenfolge-Lieferung in SCTP, wie in Tabelle I dargestellt, deaktiviert werden kann. Die typischerweise in TCP Reno oder späteren Versionen standardmäßig deaktivierte verzögerte Bestätigung reduziert die Anzahl der an Absender zurückzusendenden ACKs; dementsprechend werden der Durchsatz und die Ressourcennutzung erheblich verbessert. Allerdings kann die Latenz trotzdem um bis zu 40 ms bei periodischen Datenlieferungen für Datengrößen, die kleiner als die maximale Segmentgröße (MSS) sind, erhöht werden. Typischerweise beträgt die Größe von Sensordaten nicht mehr als 1 KB. Um dieses empfängerseitig verursachte Latenzproblem zu vermeiden, kann das Zeitlimit der verzögerten Bestätigung (in Linux, /proc/sys/net/ipv4/tcp_delack_min) von Administratoren reduziert werden, jedoch ist dies nicht zu empfehlen, da ein Manipulieren dieser Option zu einem Leistungsverlust führen kann.
  • TCP ermöglicht eine zuverlässige Lieferung unter Verwendung des kumulativen Bestätigungsschemas. Es folgt daraus, dass die durchschnittliche TCP-Ende-zu-Ende-Verzögerung mehr als eine RTT (Roundtrip-Zeit) beträgt, selbst unter idealen Netzwerkbedingungen, wenn kein Paket verworfen wird oder verloren geht, und es wird keine Verzögerung durch Datenflusskontrolle aufgrund der bedeutenden Größe des Empfangsfensters verursacht. TCP-Überlastungssteuerungsschemen können die Lieferlatenz angesichts von Paketverwürfen oder -verlusten verlängern. Senderseitig werden verlorene Segmente erneut übertragen, nachdem entweder drei duplizierte Bestätigungen empfangen wurden (schnelle Widerherstellung) oder ein Zeitlimit abgelaufen ist (langsamer Start). Diese Schemen wurden entwickelt, um unnötige Übertragungswiederholungen durch Unterscheiden zwischen verlorenen Segmenten und verspätet eintreffenden Segmenten, welche einen längeren Pfad benutzt haben (dies kann aufgrund von IP-Routingprotokollen wie beispielsweise OSPF oder BGP vorkommen), zu vermeiden.
  • Demzufolge wird die Verzögerung der Übertragungswiederholung vom Konzept her senderseitig erhöht. Der TCP-Überlastungssteuerungsalgorithmus begrenzt die Dateneinspeisungsgeschwindigkeit, bis sich das Netzwerk von dem Überlastungsereignis erholt hat. Selektive Bestätigungsschemen, in Verbindung mit den kumulativen Bestätigungsschemen, handhaben die Latenzprobleme durch das schnelle Wiederherstellen mehrfacher verlorener Segmente. Allerdings erfolgt bei dem ersten unter den wiederhergestellten Segmenten keine Leistungssteigerung, da eine Lieferung erst nach dem Empfang von drei duplizierten Bestätigungen versucht wird.
  • In Bezug auf Latenz, Schwergewichtigkeit & NAT-Unfreundlichkeit von SCTP wurde SCTP dafür entwickelt, aggregierte Telefonnachrichten zwischen Hochleistungs-Telekommunikationssystemen mit mehreren Leitungskarten zu liefern. Um Leitungsblockierungen in einer Multistream-Verbindung zu vermeiden, wird die Reihenfolge-Lieferung in SCTP deaktiviert, wodurch die Pufferungsverzögerung an der Empfängerseite reduziert wird. Allerdings ist SCTP nicht vollständig frei von Latenzproblemen von TCP aufgrund der von TCP stammenden eingesetzten Überlastungssteuerung und verspäteten Bestätigung. Es ist daher unwahrscheinlich, dass SCTP auf Sensoren oder Messgeräten mit begrenzten Rechenressourcen (z. B. 10 KB RAM) laufen kann, da selbst die leichtgewichtige SCTP-Version in Bezug auf Speichernutzung und CPU-Belastung für die Nachrichtenverarbeitung verhältnismäßig schwer ist. Überdies zeigt ein kürzlich erschienener Bericht, dass die Wahl von SCTP bei Umgebungen mit NAT(Network Address Translation)-Traversal mit Vorsicht getroffen werden muss. Die meisten derzeit eingesetzten NAT-Boxen sind nicht SCTP-freundlich. Aufgrund seiner hohen Sicherheitsmerkmale kann SCTP jedoch einen guten Transportkandidaten für bestimmte Smart-Grid-Anwendungen darstellen, wie beispielsweise die Automatisierung von Unterstationen, welche Multi-Homed-Kommunikationen zwischen dem UCC und den Unterstationen erfordern.
  • Auf der Basis dieses Überblicks kommen wir zu dem Schluss, dass bestehende Transportprotokolle nicht ausreichend geeignet sind, den Transportmerkmalen des Smart-Grid-Sensornetzes Rechnung zu tragen.
  • SSTP
  • Das Smart-Grid-Sensornetz besteht typischerweise aus Messdaten, deren Größe derart ist, dass sie in einer Protokollnachricht enthalten sein können, ohne in mehrere Blöcke aufgeteilt zu werden. Dies bedeutet, dass die in den meisten bekannten Transportprotokollen verwendete verkehrsflussbasierte Semantik ungeeignet ist. Außerdem gehen aufgrund dessen, dass die Daten über ein zu diesem Zweck errichtetes Versorgungsnetz transportiert werden, Pakete selten aus Überlastungsgründen verloren.
  • Dies bedeutet, dass auch kein Überlastungssteuerungsschema für die Datenerfassung erforderlich ist.
  • Ein Ziel von SSTP ist die Skalierbarkeit, sowohl in Bezug auf Sicherheit als auch auf Kommunikationen. Aufgrund der speziellen Kommunikationsmuster für die Datenerfassung – eine große Anzahl von Client kommunizieren nur selten mit den Servern, identifizieren wir die folgenden Wege, um maßgebliche Optimierungen zu erzielen.
  • Als erstes befassen wir uns mit auf symmetrischen Achlüssel basierten Protokollen. Bei der Datenerfassung kommunizieren Client nur mit dem Server, und ein Pre-Shared-Schlüssel (PSK) pro Client reicht aus. Vor diesem Hintergrund bringt der Einsatz von kostspieligen Public-Key-Credentials nicht den Vorteil einer systemweiten Reduzierung der Anzahl von Schlüsseln. Da Operationen mit symmetrischen Schlüsseln hunderte Male schneller als Public-Key-Operationen sind, verwendet SSTP nur Operationen mit symmetrischen Schlüsseln für Sicherheitserweiterungen. In einer Ausführungsform der Erfindung binden wir das authentifizierte Diffie-Hellman(DH)-Schlüsselabkommen, E. Rescorla, „Diffie-Hellman Key Agreement Method", IETF RFC 2631, Juni 1999, ein, um eine Folgenlosigkeit(Perfect Forward Secrecy, PFS)-Widerstandsfähigkeit von durchgeführten Schlüsselaustauschsitzungen gegen eine eventuelle zukünftige PSK-Kompromitierung zu erreichen. Es wird darauf hingewiesen, dass Public-Key-Operationen von DH vermieden werden können, jedoch auf Kosten der Sicherheit wegen Nichterreichens der PFS.
  • Als nächstes befassen wir uns mit dem Zustand eines Servers, unabhängig von der Anzahl von Clients. Bei der Erfassung von Daten, beispielsweise von Zählerstandwerten, muss der Server fortwährend Assoziationen mit einer sehr großen Anzahl von Clients, die periodisch, aber selten kommunizieren, pflegen. Das Pflegen dieser Assoziationen nimmt zahlreiche Betriebsressourcen in Anspruch, wenn, wie es in der Praxis und bei Forschungsprotokollen standardmäßig üblich ist, der Server tatsächlich mit der Sitzung assoziierte Sicherheits- und Transportinformationen (Schlüssel, Zähler usw.) aufbewahrt. In einer Ausführungsform bieten wir eine leichtgewichtige (sowohl für den Client als auch für den Server) Umsetzung an, wobei der assoziierte Sitzungszustand verschlüsselt und authentifiziert und die sich daraus ergebende Verschlüsselung anschließend an den Client bereitgestellt wird, damit dieser die Verschlüsselung vorübergehend speichert und mit der nächsten Nachricht an den Server zurücksendet. Auf diese Weise bewahrt ein Server den Sitzungszustand nicht auf, nachdem die Verschlüsselung an einen Client zurückgesendet wurde, und er kann ihn schnell wiederherstellen, wenn die nächste Nachricht vom Client eintrifft. Dabei wird darauf hingewiesen, dass durch unser Konzept eine extreme Überlastung im Fall eines Neustarts oder Ausfalls des Servers vermieden werden kann. Wie implizit in Tabelle I dargestellt besteht das Gestaltungsprinzip des SSTP in der Durchführung einer leichtgewichtigen und sicheren Transportprotokoll-Umsetzung, um erschwingliche Ende-zu-Ende-Lösungen für ressourcenbegrenzte Vorrichtungen bereitzustellen, für welche es schwierig ist, bekannten, jedoch schwergewichtigen Sicherheits- und Transportschemen Rechnung zu tragen.
  • Auf Pre-Shared-Schlüssel basierender authentifizierter Schlüsselaustausch (AKE) Wie es in sicheren Kommunikationen üblich ist, arbeiten bestimmte Ausführungsformen der vorliegenden Erfindung mit Langzeitschlüsseln und Sitzungsschlüsseln. Langzeitschlüssel sind langlebige Credentials; in unserem Fall sind sie Pre-Shared-Schlüssel (PSK), die zwischen jedem Client und Server vereinbart werden, bevor sie dem System beitreten. PSKs werden nicht für den sicheren Datentransport benutzt (da der Ersatz bei deren Kompromittierung aufwändig ist); stattdessen werden sie als Eingabe für einen AKE (authentifizierter Schlüsselaustausch) benutzt, einem Zwei-Parteien-Protokoll, welches es den Teilnehmern ermöglicht, nach der gegenseitigen Authentifizierung sicher und privat einen Sitzungsschlüssel zu bestimmen. Die Ausgabe des AKE, der Sitzungsschlüssel, wird dann zur Sicherung des Datentransports zwischen den Teilnehmern verwendet.
  • Es ist zu bemerken, dass Stromverbraucher heutzutage ihr Stromversorgungsunternehmen nur auf einer langlebigen Vertragsbasis wählen und daher ein PSK-basierter AKE für die Sicherheit ausreicht. Allerdings wäre in der nahen Zukunft ein häufiges und dynamisches Wechseln zwischen Stromversorgungsunternehmen möglich: z. B. die tägliche Auswahl des Stromversorgungsunternehmens. Vor diesem Hintergrund kann SSTP einen zertifikatsbasierten AKE verwenden, um es jedem Kundengerät zu ermöglichen, sicher mit einer Mehrzahl von Stromversorgern zu kommunizieren.
  • In Bezug auf die Pre-Shared-Schlüsselzuweisung und gemäß unserem Ziel, eine von der Anzahl von Clients unabhängige Serverspeicherung zu erreichen, beschreiben wir, wie ein Server eine große Anzahl von Langzeitschlüsseln von Client effizient speichern kann. Ein Aspekt ist dabei, dass diese Schlüssel nicht wirklich zufällig, sondern eher pseudozufällig aus dem Master-Schlüssel k des Servers erzeugt werden. Das bedeutet, dass wir bei einem Master-Schlüssel k des Servers für einen Client mit der Identität id dessen Langzeitschlüssel auf kid = AESk (id) einstellen, wobei die vorstehend genannte (AES) Advanced-Encryption-Standard-Funktion durch einen beliebigen geeigneten Pseudozufallsfunktionsgenerator (PRFG) ersetzt werden kann. Jedem Client mit der Identität id wird dann, z. B. zum Zeitpunkt der Herstellung, der Schlüssel kid zugeteilt. Der Server braucht diesen Schlüssel nicht zu speichern, da er diesen ohne weiteres anhand des Master-Schlüssels des Servers und der Identität des Client erzeugen kann. Sicherheitseigenschaften des PRFG gewährleisten, dass keiner der Client-Schlüssel von einer zufälligen Zeichenfolge unterschieden werden kann, selbst wenn der Angreifer Schlüssel von allen anderen Client erhält. Es wird also davon ausgegangen, dass diese Schlüssel für die vorgesehene Verwendung zweckentsprechende Sicherheitsmerkmale aufweisen.
  • Als nächstes beschäftigen wir uns mit dem Thema Verbindungsaufbau mit Diffie-Hellman(DH)-Austausch. Für ein Client-Server-Paar wird eine sichere Transportverbindung über die in 1 gezeigte Vierwege-Handshake-Prozedur aufgebaut. Es wird für einen Client B eine Verbindungsaufbauprozedur mit Server A dargestellt. Alle Nachrichten zwischen Clients und Servern werden während der Verbindungsaufbauphase mittels eines Nachrichtenauthentifizierungscodes (MAC), welcher mit dem PSK kB auf der entsprechenden Nachricht (bezeichnet mit MACkB) berechnet wird, geschützt. Ebenfalls wird von dem DH-Schlüsselaustausch ein symmetrischer Sitzungsschlüssel zwischen einem Client-Server-Paar berechnet, welcher Schutz gegen manche Wörterbuchangriffe bietet und eine Folgenlosigkeit gewährleistet.
  • 1 zeigt, dass Client B beabsichtigt, eine sichere Transportverbindung mit Server A aufzubauen. B sendet eine SYN-Nachricht (die Verbindungsanforderung im TCP). Wenn Server A die SYN-Nachricht empfängt, in welcher der Zustands-Token fehlt (Einzelheiten zum Zustands-Token werden nachfolgend behandelt), erzeugt er einen neuen Zustands-Token τ1 und sendet eine ACK-Nachricht mit dem Zustands-Token τ1 zurück. Wenn Client B die ACK-Nachricht erhält, werden die Primzahl p, Generator g und der geheime Exponent y nach dem Zufallsprinzip erzeugt, wobei bestimmte Einschränkungen Anwendung finden können. Zum Beispiel besteht in Bezug auf p eine Primzahleinschränkung für die Primzahl p. In diesem Zusammenhang kann jeder Client-Sensor beispielsweise eine(n) softwarebasierte(n) Zufallszahlgenerator oder -Funktion beinhalten, welche(r) geeignet ist, auf dem Client-Prozessor zu laufen. Es wird davon ausgegangen, dass der Fachmann die erforderlichen Bitgrößen der Zahlen für eine ausreichende Sicherheit in unterschiedlichen Anwendungsbereichen in diesem Kontext verstehen wird. Client B sendet eine neue SYN-Nachricht mit einem Zustands-Token τ1 und einem Satz von Zahlen (p, g, und Exponentialzahl gx), verschlüsselt mit PSK kB. Wenn Server B die SYN-Nachricht erhält, kann er die Zahlen unter Verwendung des PSK kB entschlüsseln und einen symmetrischen Sitzungsschlüssel β = gyx mod p aus gy, p und dessen eigenen geheimen Zufallsexponenten x berechnen. (Dabei wird β als ein Hash des DH-Gruppenelements gyx gesetzt, jedoch lassen wir dieses Detail aus Klarheitsgründen aus). Umgekehrt, wenn Client B eine ACK-Nachricht mit einem neuen Zustands-Token τ2 und der verschlüsselten Exponentialzahl ENCkB (gx) seines Servers erhält, kann er denselben Sitzungsschlüssel β aus gx, p, und y (der geheime Zufallsexponent von B) berechnen.
  • Tatsächlich wird das SSTP-Handschake-Verfahren weitgehend von dem TLS DHE_PSK-Schlüsselaustausch, P. Eronen und H. Tschofenig, „Pre-Shared Key Cipher suites for Transport Layer Security (TLS),", IETF RFC4279, Dez., 2005, und TCP cookie transaction, P. Metzger, W. Simpson, und P. Vixie, „Improving TCP Security With Robust Cookies," USENIX Magazine, Vol. 34, Nr. 6, Dez., 2009, beeinflusst. Der wesentliche Unterschied besteht darin, dass die Server weder den Transport- noch den Sicherheitszustand für Clients durch die Verwendung eines Zustands-Tokens, welcher nachfolgend behandelt wird, aufbewahrt. Weiterhin, im Vergleich zu Alternativen, führt das SSTP das Verbindungsaufbauverfahren in Verbindung mit einem AKE aus, sodass der Overhead reduziert werden kann.
  • Zustands-Token und sichere Kommunikation
  • In bestimmten Ausführungsformen wird eine Technik angewendet, um den mit dem Clients assoziierten Zustand effektiv an den Clients selbst abzuladen. Auf einem hohen Niveau besteht das Ziel darin, den Zustand zu verschlüsseln und zu authentifizieren und diesen beim Client zu speichern. Wir setzen dies wie in den Abbildungen 1 und 2 dargestellt um. Zuerst bewahrt der Server einen Satz von separaten symmetrischen Schlüsseln tkid, welche sicher von der id eines jeden Clients (z. B. tkid = AESk (”tokenkey”, id)) abgeleitet wurden, zum Zweck dieser Verschlüsselung/Authentifizierung auf. Weiterhin, wenn er im Begriff ist, eine ACK-Nachricht an einen Client zu senden, verschlüsselt und authentifiziert der Server mit tkid den Zustand (Sitzungsschlüssel, Zeitstempel, id des Clients, und Zähler) der Assoziation unseres Protokolls und erhält daraufhin einen Zustands-Token. Dieser Zustands-Token wird anschließend an den Client gesendet und danach zusammen mit dem Sitzungszustand aus dem Server gelöscht. Wenn der Client den Token empfängt, speichert er diesen und fügt ihn wortgetreu in die nächste Nachricht des Clients an den Server ein. Dabei ist zu berücksichtigen, dass der zuletzt aufbewahrte Zustands-Token nur neuen Nachrichten beigefügt werden kann, jedoch nicht wiederholt übertragenen Nachrichten, welche die alten Zustands-Token, die ursprünglich darin enthalten waren, beinhalten müssen. Es wird ausdrücklich betont, dass der (verschlüsselte) Zustands-Token nicht weiter verschlüsselt wird, im Gegensatz zum Rest der Nachricht des Clients, sodass der Server den Zustands-Token entschlüsseln und den Sitzungszustand wiederherstellen kann. Bei Empfang der Nachricht des Clients wird der Zustands-Token vom Server zuerst extrahiert, entschlüsselt und auf dessen Integrität geprüft. Nach der erfolgreichen Überprüfung oder Authentifizierung stellt der Server den Sitzungszustand, der auf oder in dem Token gespeichert ist, wieder her und verarbeitet die Nachricht des Clients wie üblich. Wenn die Verarbeitung der Nachricht beendet ist, wiederholt der Server die vorstehend beschriebene Prozedur.
  • Clientseitig werden die Nachrichten unter Verwendung eines vom AKE berechneten Sitzungsschlüssels β verschlüsselt und authentifiziert. Serverseitig können wir, wenn die Überprüfung des Zustands-Tokens erfolgreich abgeschlossen ist, folgendes unter Verwendung eines Schlüssels tkid aus dem Zustands-Token extrahieren: Sitzungsschlüssel β, Token-Ausgabezeit TSi, id des Client, und Zähler, Ni. Anschließend kann die Nachricht weiter verarbeitet werden, wenn die folgenden Bedingungen erfüllt sind: (1) die Quelle der Nachricht entspricht der id, (2) die, Sequenznummer der Nachricht ist höher als oder gleich Ni, und (3) TSi liegt unter der gegenwärtigen Zeit und nicht außerhalb einer Altersgrenze.
  • Zuverlässigkeit und Latenz
  • In einer Ausführungsform der Erfindung hat der Server zum Zweck der Skalierbarkeit einen Empfangspuffer für alle Clients, und außerdem keinen Sendepuffer. Es wird nochmals darauf hingewiesen, dass Sensordaten von Clients kontinuierlich an einen Server gesendet werden, während Management-Befehle nur selten vom Server an den Client gesendet werden. Ein Client kann eine neue Nachricht senden, sobald die mit der aktuellen Zeit abgestempelte Nachricht in den Sendepuffer des Clients eingeschrieben wurde. Im Sendepuffer werden bestätigte Nachrichten entfernt, während unbestätigte Nachrichten innerhalb eines gegebenen Zeitraums erneut gesendet werden, wobei Backoff-Zufalls-Timer verwendet werden, um ein Übertragungswiederholungs-Flooding zu vermeiden. Folglich können verlorene Nachrichten an den Server vom Konzept her im SSTP wiederhergestellt werden, während verlorene Nachrichten an Client nicht wiederhergestellt werden können. Eine zuverlässige Lieferung von Nachrichten an Client kann auf der Anwendungsebene implementiert werden, wie dies für den Fachmann verständlich ist. Bei anhaltenden Serverausfällen können Client mit einem alternativen Server neue sichere Verbindungen aufbauen. Für den Fachmann ist es ebenfalls verständlich, dass andere Pufferanordnungen für den Client und den Server möglich sind.
  • In Bezug auf die Latenz kann ein Client sofort und ohne Verzögerung Nachrichten senden, es sei denn, sein Sendefenster ist voll. Im Gegensatz hierzu werden Nachrichten an Clients verzögert, um eine Huckepack-Beförderung (piggy backing) auf Bestätigungen an Clients zu ermöglichen. Die Größe des Sendefensters eines jeden Clients wird anhand der Anzahl der Clients pro Server bestimmt, wobei der Server erwartet, dass seine Clients die Größe ihres Fensters gleichmäßig reduzieren, wenn er mehr als eine erwartete Anzahl von Clients bedienen muss.
  • Sicherheit und Aufwand
  • Nachfolgend fassen wir die Sicherheit von SSTP zusammen, wobei ein großer Teil der Sicherheitsargumentation im Rahmen der Diskussion in Bezug auf das Protokolldesign behandelt wird. Als erstes ist die Erzeugung des Langzeitschlüssels aufgrund der Eigenschaften des PRFG sicher. Der Folge-AKE, für welchen einige Ausführungsformen aus der Fachliteratur und Standards gewählt wurden, ist ebenfalls sicher. Schließlich ist auch die Erstellung des sicheren Post-AKE-Sitzungsprotokolls mit Entlastung des Servers sicher, wenn Replay-Angriffe ausgeschlossen werden.
  • Vom Standpunkt des Rechen- und Speicheraufwands vergleichen wir SSTP mit TLS über TCP (nachstehend TLS genannt). Nehmen wir einmal zwei Arten von TLS-Client-Server-Assoziationen in Betracht: die eine langlebig, die andere kurzlebig. Für die erste bewahrt jeder Client eine Assoziation mit seinem Server während der Lebensdauer einer sicheren Transportverbindung auf. Für die letztere baut er eine Verbindung zu seinem Server auf, um eine Nachricht zuzustellen, und beendet die Verbindung, wenn die Nachricht geliefert wurde. Für den einfachen Vergleich betrachten wir einmal ein großes Netzwerk mit N Messgeräten, in welchem jedes Messgerät (Client) erfasste Daten innerhalb eines bestimmten Zeitintervalls an seinen Datensammler (Server) sendet, und nehmen wir an, dass der Sicherheits- und Transportzustand pro Client L Speicherplatz in einem Server verbraucht.
  • Die kurzlebige TLS hat einen hohen Rechenaufwand für die Steuerung, da sie wiederholt alle λ eine neue Verbindung pro Daten aufbaut, einen Datensatz verarbeitet und die Verbindung löscht. Es sind siebzehn Steuernachrichten erforderlich, um die Daten zu liefern (12 für den vom Client authentifizierten TLS-Aufbau und 5 für den TCP-Aufbau und die Beendigung). Dies bedeutet, dass kurzlebige TLS-Server die CPU, den Speicher und Netzwerkressourcen für die alleinige Verarbeitung von Steuernachrichten stark beanspruchen, wenn λ . niedrig ist. Andererseits benötigen langlebige TLS-Server O(NL) Speicherplatz, um den Sicherheits-/Transportzustand für Clients aufzubewahren, und einen zusätzlichen Rechenaufwand, um einen entsprechenden Zustand unter O(N) Zuständen einzusehen. Dies bedeutet, dass langlebige TLS-Server den Speicher übermäßig nutzen und ebenfalls CPU-Ressourcen für das Einsehen des Zustands verbrauchen, wenn λ hoch ist. Vergleichsweise haben SSTP-Server keinen Rechen- oder Speichernutzungsaufwand, wie in Alternativen beobachtet wurde, ungeachtet von λ und N, aufgrund des zustandslosen Konzepts. Der in SSTP gezeigte Aufwand betrifft die Verarbeitung von Zustands-Token je empfangene Daten, welcher nicht höher ist als das für das Einsehen des Zustands bei langlebigen TLS. Unter dem Aspekt der Kommunikation überbietet SSTP eindeutig den Austausch von Steuernachrichten, alle λ, von kurzlebigen TLS und ist langlebigen TLS ähnlich, da die Header-Größe des SSTP mit der von TLS vergleichbar ist. Wir weisen darauf hin, dass Clients bei der Verwendung von SSTP vom Konzept her keine Verbindungsanforderungen im Fall eines zeitlichen Serverausfalls senden, im Vergleich zu Alternativen, in welchen Clients durch das Senden von Anforderungen innerhalb einer Zeitgrenze ein SYN-Flooding verursachen.
  • Netzwerkverzögerung
  • Wir gehen von einem für die Erfassung von Smart-Grid-Daten erwarteten überlastungsfreien Netzwerk aus. Allerdings ist diese Annahme für SSTP ungünstiger; in einem überlasteten Netzwerk erwarten wie, dass die Leistung von SSTP in Bezug auf TLS weiter verbessert wird. In der Zukunft beabsichtigen wir, die Leistung von SSTP bei Netzwerküberlastung zu testen.
  • Für eine Simulationseinstellung messen wir die Ende-zu-Ende-Verzögerung von TCP Reno und SSTP bei ns-2 Simulationseinstellungen, wie in Tabelle II dargestellt. Eine Datenquelle, welche einen Erfassungsknoten darstellt, speist kontinuierlich 512-Byte-Pakete in einem periodischen Intervall in das Netzwerk ein. Da erwartet wird, dass HSPA oder WiMAX für die Smart-Grid-Zugangsnetzwerktechnologie verwendet werden, werden die Ergebnisse des im Oktober 2010 in Chicago durchgeführten Geschwindigkeitstests für diese Simulationseinstellung verwendet: Topologie 1 stellt ATT HSPA dar, und Topologie 2 stellt Clearwire WiMAX dar. TCP Reno wird mit SSTP verglichen, da bewiesen wurde, dass TCP Cubic (die „bessere” TCP-Variante) hinsichtlich der Verzögerung von TCP Reno übertroffen wird. Es ist zu bemerken, dass diese Bewertung auf der Annahme beruht, dass kein Verlust, Verwerfen oder Reihenfolgeänderung von Nachrichten besteht. Folglich ist diese Simulation auf die Auswirkung einer Netzwerkverzögerung, gezielt und frei von den negativen Folgen von Überlastungssteuerungsschemen und In-Order-Sequenz-Service. Table II: NS-2 SIMULATION SETTINGS.
    Network settings TCP Renp vs SSTP
    – Uplink Speed – Uplink Delay – Downlink Speed – Downlink Delay 278 kbps [topology = 1] 240 m 28 Mbps 160 ms 1 Mbps [topology = 2] 120 m 6 Mbps 80 ms
    TCP Specific settings 536B MSS, 64KB RX Buffer and 40 ms Delayed Ack.
    Sensing Data Size 512 Byte Data over uplinks, ACK over downlinks
    Data Injection Speed 10 ms~250 ms (441,3 kbps~1.76 kbps)
    Simulation Duration 3 minutes after steady state
  • Die Ergebnisse der Simulation sind wie folgt: Wie erwartet übertrifft das SSTP-Protokoll das TCP-Protokoll in den in der Tabelle II beschriebenen Topologien. Die Abbildung 3 stellt durchschnittliche Ende-zu-Ende-Verzögerungen von SSTP und TCP als eine Funktion von Arbeitslasten mit konstanter Bitrate dar. SSTP hält Schritt mit der Geschwindigkeit des physischen Links bei allen Einstellungen, mit Ausnahme eines Dateneinspeisungsintervalls von 10 ms und einer Bandbreite von 278 kbps. Im Gegensatz hierzu weist TCP immer eine größere Ende-zu-Ende-Verzögerung als RTT auf, wenn das Dateneinspeisungsintervall kleiner als RTT ist. In dieser Bewertung stellen wir zwei Eigenschaften von TCP fest. Erstens ist die Ende-zu-Ende-Verzögerung von TCP extrem hoch, d. h. etwa 46 Sek., wenn die Bandbreite des Netzwerks für die Übertragung nicht ausreicht, wie in 3 dargestellt. Zweitens wird bei ausreichender Bandbreite die Ende-zu-Ende-Verzögerung von TCP von der Netzwerkverzögerung dominiert.
  • Interessanterweise zeigt das Ergebnis der Simulation auf Topologie 2, dass TCP bei großen Dateneinspeisungsintervallen mit SSTP vergleichbar ist.
  • Auf der Basis unserer Beobachtungen sehen wir, dass TCP unter den folgenden Bedingungen gut funktioniert: Bevor die Größe des unbestätigten Sendefensters eine Überlastfenstergrenze (congestion window limit) erreicht, wird die ACK immer an den Absender zurückgesendet, und anschließend werden Daten von einer Anwendung geschoben. Das heißt, wenn das Dateneinspeisungsintervall größer als RTT ist und in einer TCP MSS Daten enthalten sind, entspricht die Ende-zu-Ende-Verzögerung von TCP in etwa einer Ein-Weg-Zeit von einem Absender an einen Empfänger aufgrund des immer geöffneten Überlastungsfensters (congestion window). Ansonsten ist TCP sowohl gegenüber dem Dateneinspeisungsintervall als auch RTT (variiert in Abhängigkeit von Medien und vom Routing sowie von den miteinander kommunizierenden Paaren) empfindlich. Wenn zum Beispiel das Dateneinspeisungsintervall größer als ein Round-Trip-Zeitlimit(RTO)-Wert (Minutenskala) ist, entspricht die Ende-zu-Ende-Verzögerung von TCP mindestens RTT ohne Paketabwurf, wenn die Paketgröße größer als eine TCP MSS ist, und mindestens dem RTO-Wert, selbst bei einem einzigen Paketverwurf, ungeachtet der Größe des Pakets. Im Gegensatz hierzu funktioniert SSTP in Bezug auf Verzögerung gut und ist unabhängig von dem Dateneinspeisungsintervall und den Netzwerkeinstellungen.
  • Nachfolgend erklären wir, wie wir den Server gegen Replay-Angriffe schützen, da der SSTP-Server im Wesentlichen zustandslos ist. Zuerst stellen wir fest, dass die geheimschlüsselbasierten Authentifizierungen von Zustands-Token durch den Server fälschungssicher sind, und dass man bei geeigneter Formatierung und Sorgfalt den Angreifer daran hindern kann, einen für einen Client id1 erzeugten Zustands-Token als einen Zustands-Token für einen Client id2 zu präsentieren. Weiterhin verwenden wir eine deterministische Verschlüsselung, wie beispielsweise AES, sodass eine Wiederverschlüsselung eines Zustands-Token, ohne einen Geheimschlüssel zu kennen, ebenfalls nicht möglich ist. Infolgedessen ist die einzige Möglichkeit des Replay-Angriffs die wortwörtliche Wiedergabe eines zuvor erzeugten Zustands-Tokens mit einer möglicherweise unterschiedlichen Sitzungsnachricht. Wir beobachten, dass die Sitzungsnachricht implizit an den Zustands-Token gebunden ist, da die Sitzungsnachricht (aufgrund des erforderlichen Wiedergabeschutzes in sicheren Sitzungsprotokollen) kryptografisch an den Zustand des Clients und des Servers und somit an den Zustands-Token gebunden ist. Folglich ist der einzige Replay-Angriff, der noch berücksichtigt werden muss, die wortwörtliche Wiedergabe der kompletten Nachricht des Clients. Ein System, wie es vorstehend beschrieben wurde, ist möglicherweise für einen solchen Angriff anfällig. Nachfolgend erklären wir unsere Schutztechnik. Erstens verwirft ein Server „offensichtlich alte” Nachrichten, indem er die in einem Zustands-Token enthaltene Ausstellungszeit des Tokens überprüft. Trotzdem müssen wir uns noch effizient mit der Möglichkeit der Wiedergabe von „nicht offensichtlich zu alten” Nachrichten befassen, die bis zu mehreren Vielfachen von zehn Sekunden alt sein können (um ein Abweichen von Uhren zu berücksichtigen). Nach unseren Beobachtungen ist die Anzahl der Nachrichten, die innerhalb dieser Zeitspanne von Vielfachen von zehn Sekunden eintreffen können, nicht sehr groß, und wir können es uns also erlauben, den Verlauf der Hashes aufzubewahren. Bei jeder neuen Nachricht vergleichen wir sie mit einem kleinen letzten Verlauf von Hashes und verwerfen sie, wenn sie in dem Verlauf gefunden werden; wenn sie nicht gefunden wird, gehen wir wie vorstehend beschrieben vor. Eine Optimierung, die umgesetzt werden kann, ist die Verwendung von Bloom-Filtern, um die Größe der Hash-Tabelle in bedeutendem Maße zu reduzieren und die Hash-Prüfungen zu beschleunigen.
  • Unter Bezugnahme auf die Abbildung 4 wird eine beispielhafte Ausführungsform eines Sensors 400 und eines Servers 420 dargestellt, wie sie in Verbindung mit bestimmten Ausführungsformen der vorliegenden Erfindung eingesetzt werden können. Wie dargestellt umfasst der Sensor 400 einen Prozessor 406 und einen Speicher 408 (zum Beispiel eine angemessene Größe von Nur-Lese-Speicher (ROM) und Speicher mit wahlfreiem Zugriff (RAM)). Wie vorstehend beschrieben können der Prozessor und der Speicher in der Form eines Microcontrollers ausgestaltet sein, wie beispielsweise einer der Microcontroller der Serie MSP 430 von TI (Texas Instruments). Wie zu verstehen ist, kann der Sensorspeicher 408 mit einem ausführbaren Code programmiert werden, um das Verfahren der vorliegenden Erfindung wie beschrieben durchzuführen. Der Prozessor 406 ist an eine Zählerschnittstelle 404 gekoppelt, welche Schaltungen zur Verknüpfung mit vorhandenen Messgeräten umfassen kann. Zudem kann der Prozessor ebenfalls an eine Kommunikationsschnittstelle gekoppelt werden, welche ihrerseits an ein Kommunikationsnetzwerk 412 gekoppelt wird. Auf diese Weise können Messdaten von einem Messgerät 402 erhalten und über das Kommunikationsnetzwerk an einen entsprechenden Server 420 des jeweiligen Energieversorgers übertragen werden. Wie es für den Fachmann verständlich ist, kann der Sensor, wie gezeigt, separat an das Messgerät gekoppelt oder in das Messgerät selbst integriert werden. Zudem können weitere verschiedene Ausführungsformen von Sensor-Design und Sensor-Funktionen eingesetzt werden, wie es leicht nachvollziehbar ist.
  • Wie dargestellt umfasst der Server 420 ebenfalls einen Prozessor 422 und einen zugehörigen Speicher 424. Der Speicher ist mit einem ausführbaren Code programmiert, sodass der Server das Verfahren der vorliegenden Erfindung sowie weitere gut verständliche Serveraufgaben für einen Server dieser Art durchführen kann. Außerdem umfasst der Server 420 eine Kommunikationsschnittstelle 426 zum Kommunikationsnetzwerk 412. Die Kommunikationsschnittstelle kann mehrfache Ports und angemessene Pufferkapazitäten umfassen, wie es für den Fachmann leicht verständlich ist.
  • VERWANDTE ARBEITEN
  • Relevant für unsere Arbeit ist der Gegenstand der neuesten Forschungsarbeiten, die sich mit Ende-zu-Ende-Transportlösungen über Stromleitungskommunikationssysteme befasst haben: M. Bauer, W. Plappert, C. Wang, und K. Dostert, „Packet-Oriented Communication Protocols for Smart Grid Services over Low-Speed PLC," IEEE PLC and Its Applications, März 2009, und RF mesh networks, J. Paek und R. Govindan, „Rate-Controlled Reliable Transport Protocol for Wireless Sensor Networks," ACM SENSYS, Nov. 2007. Aus dieser Fachliteratur können wir schließen, dass bestehende Lösungen nicht für die Erfassung von Smart-Grid-Sensordaten geeignet sind, welche auf Millisekunden- bis Minutenskala-Messungen beruhen: die durchschnittliche Verzögerung zwischen PLC-Slaves (Zähler) und einem PLC-Master beträgt etwa 10 Minuten, selbst in einem 100-Knoten-Netzwerk. In einem vermaschten Funknetz wurde eine Verzögerung von bis zu einer Stunde beobachtet. Noch wichtiger ist, dass sich diese bisherigen Lösungen nicht auf skalierbare Ende-zu-Ende-Sicherheitserweiterungen beziehen. Alternativen hierzu sind Konzepte mit geteilter Aggregation, in welchen Hochleistungs-Zwischenknoten Daten aggregieren und in wirksamer Weise mit einem Hop-by-Hop-Auslieferungsschema auf Überlastungen reagieren, sodass Übertragungswiederholungen reduziert werden. Unter der Voraussetzung, dass eine Überlastung selten ist, ist die Auswirkung dieser Alternativen auf die RTT-Reduzierung beschränkt. Das Hauptproblem dieses Ansatzes liegt jedoch darin, dass die Ende-zu-Ende-Sicherheit verletzt werden kann, da eine geteilte Aggregation TLS- oder IPSec-Sitzungen erfordert, die an Zwischenknoten beendet werden. Wir heben hervor, dass SSTP nach geringfügigen Änderungen direkt auf das Geteilte-Aggregations-Modell angewendet werden kann.
  • SCHLUSSFOLGERUNG
  • Es wird erwartet, dass in den neu entstehenden Smart-Grid-Netzen kontinuierlich erhebliche Datenmengen von den verschiedenen Messgeräten (intelligente Sensoren, hoch entwickelte Zähler, Ladestationen für Elektrofahrzeuge), welche in das Stromnetz eingebunden sind, erzeugt werden. Die von diesen Messgeräten erzeugten Daten müssen sicher und zuverlässig an Stromversorgungskontrollzentren geliefert werden, um eine großflächige Überwachung und Kontrolle zu ermöglichen und den allgemeinen Netzzustand zeitgerecht und präzise zu berechnen. Die erfassten Daten werden ebenfalls verwendet, um Verbraucher anzureizen, sich an der Verbesserung der Leistungsstabilität zu beteiligen. Transportprotokollanforderungen für solche periodischen Netzmessdaten werden als lebenslängliche, sichere und zuverlässige Lieferung von kurzen Flüssen (üblicherweise weniger als 1,5 KB) über Energieversorger-weite Netze (WANs) gekennzeichnet. Unsere Untersuchung zeigt jedoch, dass es kein bekanntes Transportprotokoll gibt, welches die vorstehenden Eigenschaften in einer skalierbaren und leichtgewichtigen Weise unterstützen kann.
  • Unter dieser Motivation entwickeln wir ein skalierbares und sicheres Transportprotokoll, SSTP, indem wir den Begriff eines „Zustands-Token” nutzen, welcher mit jeder Servernachricht ausgegeben und anschließend einer jeden an den Server gesendeten entsprechenden Client-Nachricht beigefügt wird. Im Vergleich zu bestehenden, gut bekannten Transport- und Sicherheitsschemen ermöglicht SSTP skalierbare Servereinsatzmöglichkeiten, da Server keine Zustände (für Sicherheit und Kommunikation) pro Client aufbewahren und der Rechen-/Speicheraufwand dadurch wesentlich reduziert wird.
  • Die vorhergehende Beschreibung illustriert lediglich die Grundlagen der Erfindung. Es lässt sich leicht nachvollziehen, dass es dem Fachmann möglich ist, unterschiedliche Anordnungen auszuarbeiten, welche, auch wenn sie hierin nicht ausdrücklich beschrieben oder dargestellt sind, die Grundlagen der Erfindung verkörpern und sinn- und anwendungsgemäß darin begriffen sind. Des Weiteren sind alle hierin angegebenen Beispiele und verwendeten konditionalen Formulieren hauptsächlich ausdrücklich nur für Informationszwecke bestimmt, um es dem Leser zu erleichtern, die Grundlagen der Erfindung und die vom Erfinder zur Weiterentwicklung des Stands der Technik beigetragenen Konzepte zu verstehen, und dahingehend auszulegen, dass sie keine Beschränkung auf die spezifischen vorgetragenen Beispiele und Bedingungen darstellen. Darüber hinaus sind alle hierin enthaltenen Angaben in Bezug auf Grundsätze, Aspekte und Ausführungsformen der Erfindung, sowie spezifische Beispiele davon, dazu bestimmt, sowohl strukturelle als auch funktionelle Entsprechungen davon zu umfassen. In Ergänzung dazu ist es die Absicht, dass derartige Entsprechungen sowohl derzeit bekannte als auch zukünftig entwickelte Entsprechungen umfassen, d. h. alle entwickelten Elemente, die dieselbe Funktion ausüben, ungeachtet der Struktur. Zahlreiche weitere Änderungen und Anwendungen der Grundlagen der Erfindung werden dem Fachmann erkenntlich sein und gehen aus den Lehren hierin hervor. Dementsprechend ist der Anwendungsbereich der Erfindung nur durch die Schutzansprüche begrenzt.
  • 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
    • E. Rescorla, „Diffie-Hellman Key Agreement Method”, IETF RFC 2631, Juni 1999 [0024]
    • P. Eronen und H. Tschofenig, „Pre-Shared Key Cipher suites for Transport Layer Security (TLS),”, IETF RFC4279, Dez., 2005 [0031]
    • P. Metzger, W. Simpson, und P. Vixie, „Improving TCP Security With Robust Cookies,” USENIX Magazine, Vol. 34, Nr. 6, Dez., 2009 [0031]
    • M. Bauer, W. Plappert, C. Wang, und K. Dostert, „Packet-Oriented Communication Protocols for Smart Grid Services over Low-Speed PLC,” IEEE PLC and Its Applications, März 2009 [0047]
    • J. Paek und R. Govindan, „Rate-Controlled Reliable Transport Protocol for Wireless Sensor Networks,” ACM SENSYS, Nov. 2007 [0047]

Claims (8)

  1. Sensorvorrichtung zum Bereitstellen einer sicheren Kommunikation mit einem Server in einem Kommunikationsnetzwerk, wobei die besagte Vorrichtung umfasst: Eine Kommunikationsschnittstelle, um es der besagten Sensorvorrichtung zu ermöglichen, über ein Kommunikationsnetzwerk zu kommunizieren; und einen Prozessor, der, wenn er mit einem ausführbaren Programmcode programmiert ist, betreibbar ist, um: Eine Verbindungsanforderung an den besagten Server zu senden; von dem besagten Server eine Bestätigungsnachricht zu empfangen, wobei die besagte Bestätigungsnachricht ein Zustands-Token enthält, welches einen Assoziationszustand zwischen dem besagten Client und dem besagten Server darstellt; von dem besagten Client an den besagten Server unter Verwendung des besagten Zustands-Token zu kommunizieren, wobei der besagte Assoziationszustand zwischen dem besagten Client und dem besagten Server vorübergehend bei dem besagten Client gespeichert und nicht an dem besagten Server behalten wird, wobei der besagte Zustands-Token in Kommunikationen von dem besagten Client an den besagten Server benutzt wird, um es dem besagten Server zu ermöglichen, den Sitzungszustand zwischen dem besagten Client zu überprüfen und wiederherzustellen, um dadurch Nachrichten von dem besagten Client zu verarbeiten.
  2. Vorrichtung nach Anspruch 1, wobei bei Empfang der besagten Bestätigungsnachricht an der besagten Vorrichtung ein Satz von Zahlen p, g, und eine Exponentialzahl gx erzeugt wird, wobei die Zahlen des besagten Satzes mit PSK kB verschlüsselt und mit dem besagten Zustands-Token während des besagten Schritts des Kommunizierens an den besagten Server zurückgesendet werden.
  3. Vorrichtung nach Anspruch 2, wobei bei Empfang der besagten Bestätigungsnachricht an der besagten Vorrichtung mit einem neuen Zustands-Token τ2 und einer verschlüsselten Exponentialzahl ENCkB (gx) des besagten Servers ein Sitzungsschlüssel β aus gx, p und y berechnet wird.
  4. Vorrichtung nach Anspruch 3, wobei die Nachrichten zwischen der besagten Vorrichtung und dem besagten Server während einer Verbindungsaufbauphase durch einen Nachrichtenauthentifizierungscode (MAC), berechnet mit dem PSK kB auf der entsprechenden Nachricht, geschützt werden.
  5. The Vorrichtung nach Anspruch 4, wobei die Pre-Shared-Schlüssel (PSK) pseudo-zufällig aus einem Master-Schlüssel k des besagten Servers erzeugt werden, wobei bei einem Master-Schlüssel k des Servers für eine Sensorvorrichtung mit der Identität id ein Langzeitschlüssel kid = ENCk (id) ist.
  6. Servervorrichtung zum Bereitstellen einer sicheren Kommunikation mit einem Client in einem Kommunikationsnetzwerk, wobei die besagte Vorrichtung umfasst: Eine Kommunikationsschnittstelle, um die besagte Sensorvorrichtung zu befähigen, über ein Kommunikationsnetzwerk zu kommunizieren; und einen Prozessor, der, wenn er mit einem ausführbaren Programmcode programmiert ist, betreibbar ist, um: Eine Verbindungsanforderung von dem besagten Client zu empfangen; eine Bestätigungsnachricht zu senden, wobei die besagte Bestätigungsnachricht einen Zustands-Token enthält, welcher einen Assoziationszustand zwischen dem besagten Client und dem besagten Server darstellt; eine Kommunikation von dem besagten Client an den besagten Server unter Verwendung des besagten Zustands-Token zu empfangen, wobei der besagte Assoziationszustand zwischen dem besagten Client und dem besagten Server vorübergehend bei dem besagten Client gespeichert und nicht an dem besagten Server behalten wird, wobei der besagte Zustands-Token in Kommunikationen von dem besagten Client an den besagten Server benutzt wird, um es dem besagten Server zu ermöglichen, den Sitzungszustand zwischen dem besagten Client zu überprüfen und wiederherzustellen, um Nachrichten von dem besagten Client zu verarbeiten.
  7. Vorrichtung nach Anspruch 6, wobei bei Empfang einer Verbindungsanforderungsnachricht an der besagten Servervorrichtung die besagte Servervorrichtung betreibbar ist, um den besagten Satz von Zahlen unter Verwendung des PSK kB zu entschlüsseln und weiterhin einen symmetrischen Sitzungsschlüssel β = g mod p aus gy, p und dessen eigenen Zufallsexponenten x zu berechnen.
  8. Vorrichtung nach Anspruch 7, wobei Pre-Shared-Schlüssel (PSK) pseudo-zufällig aus einem Master-Schlüssel k der besagten Servervorrichtung erzeugt werden, wobei bei einem Master-Schlüssel k des Servers für einen Client mit der Identität id ein Langzeitschlüssel kid = ENCk (id) ist.
DE202012003716U 2011-12-20 2012-04-13 Vorrichtung für ein skalierbares und sicheres Transportprotokoll zur Sensordatenerfassung Expired - Lifetime DE202012003716U1 (de)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
US13/331,102 US8935533B2 (en) 2011-12-20 2011-12-20 Method and apparatus for a scalable and secure transport protocol for sensor data collection
US13/331,102 2011-12-20

Publications (1)

Publication Number Publication Date
DE202012003716U1 true DE202012003716U1 (de) 2012-07-24

Family

ID=46705703

Family Applications (1)

Application Number Title Priority Date Filing Date
DE202012003716U Expired - Lifetime DE202012003716U1 (de) 2011-12-20 2012-04-13 Vorrichtung für ein skalierbares und sicheres Transportprotokoll zur Sensordatenerfassung

Country Status (2)

Country Link
US (1) US8935533B2 (de)
DE (1) DE202012003716U1 (de)

Families Citing this family (21)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN101699891B (zh) * 2009-10-21 2012-07-25 西安西电捷通无线网络通信股份有限公司 一种传感器网络密钥管理和节点鉴别方法
WO2014007981A1 (en) 2012-07-03 2014-01-09 Smartlabs, Inc. Simulcast mesh dimmable illumination source
US9300484B1 (en) * 2013-07-12 2016-03-29 Smartlabs, Inc. Acknowledgement as a propagation of messages in a simulcast mesh network
US9251700B2 (en) 2013-10-28 2016-02-02 Smartlabs, Inc. Methods and systems for powerline and radio frequency communications
US9864864B2 (en) * 2014-09-23 2018-01-09 Accenture Global Services Limited Industrial security agent platform
US9985796B2 (en) 2014-12-19 2018-05-29 Smartlabs, Inc. Smart sensor adaptive configuration systems and methods using cloud data
US11489690B2 (en) 2014-12-19 2022-11-01 Smartlabs, Inc. System communication utilizing path between neighboring networks
WO2016144223A1 (en) * 2015-03-11 2016-09-15 Telefonaktiebolaget Lm Ericsson (Publ) Multipoint data flow control
US10198325B2 (en) * 2016-05-24 2019-02-05 Mastercard International Incorporated Method and system for desynchronization recovery for permissioned blockchains using bloom filters
US10204341B2 (en) 2016-05-24 2019-02-12 Mastercard International Incorporated Method and system for an efficient consensus mechanism for permissioned blockchains using bloom filters and audit guarantees
DE102017208735A1 (de) 2017-05-23 2018-11-29 Siemens Aktiengesellschaft Verfahren und Vorrichtung zum Schutz einer Kommunikation zwischen mindestens einer ersten Kommunikationseinrichtung und wenigstens einer zweiten Kommunikationseinrichtung insbesondere innerhalb eines Kommunikationsnetzwerkes einer industriellen Fertigung und/oder Automatisierung
US10728368B2 (en) * 2018-08-30 2020-07-28 Cisco Technology, Inc. Maintaining latency in TCP loss-insensitive congestion control mechanisms
CN110392898A (zh) 2018-12-28 2019-10-29 阿里巴巴集团控股有限公司 使用加速节点加速区块链网络中的交易交付
WO2019072306A2 (en) * 2018-12-28 2019-04-18 Alibaba Group Holding Limited ACCELERATION OF TRANSACTION DELIVERIES IN BLOCK CHAIN NETWORKS USING A TRANSACTION RETURN
EP3571808A4 (de) 2018-12-28 2020-03-04 Alibaba Group Holding Limited Verbesserung der geschwindigkeit von blockchain-transaktionen unter verwendung von globalen beschleunigungsknoten
US11563644B2 (en) 2019-01-04 2023-01-24 GoTenna, Inc. Method and apparatus for modeling mobility and dynamic connectivity on a stationary wireless testbed
US11546769B1 (en) * 2021-06-30 2023-01-03 Fortinet, Inc. NGFW (next generation firewall) security inspection over multiple sessions of message session relay protocol (MSRP) on a data communication network
US11627063B1 (en) * 2021-12-02 2023-04-11 Verizon Patent And Licensing Inc. Systems and methods for measuring unidirectional latency of applications over asymmetric links
EP4344206A1 (de) * 2022-09-22 2024-03-27 MK Systems USA Inc. Systeme und verfahren für streaming mit reduzierter latenz
US11968302B1 (en) 2023-03-24 2024-04-23 Srinivas Kumar Method and system for pre-shared key (PSK) based secure communications with domain name system (DNS) authenticator
US12476793B2 (en) 2023-03-24 2025-11-18 Symmera Inc. System and method to securely distribute authenticated and trusted data streams to AI systems

Family Cites Families (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US7434050B2 (en) * 2003-12-11 2008-10-07 International Business Machines Corporation Efficient method for providing secure remote access
EP1849119B1 (de) * 2005-02-18 2019-07-10 EMC Corporation Derivative samen
US20080195740A1 (en) * 2007-02-12 2008-08-14 Mobitv, Inc. Maintaining session state information in a client server system
US8422687B2 (en) * 2008-05-30 2013-04-16 Lantiq Deutschland Gmbh Key management for communication networks

Non-Patent Citations (5)

* Cited by examiner, † Cited by third party
Title
E. Rescorla, "Diffie-Hellman Key Agreement Method", IETF RFC 2631, Juni 1999
J. Paek und R. Govindan, "Rate-Controlled Reliable Transport Protocol for Wireless Sensor Networks," ACM SENSYS, Nov. 2007
M. Bauer, W. Plappert, C. Wang, und K. Dostert, "Packet-Oriented Communication Protocols for Smart Grid Services over Low-Speed PLC," IEEE PLC and Its Applications, März 2009
P. Eronen und H. Tschofenig, "Pre-Shared Key Cipher suites for Transport Layer Security (TLS),", IETF RFC4279, Dez., 2005
P. Metzger, W. Simpson, und P. Vixie, "Improving TCP Security With Robust Cookies," USENIX Magazine, Vol. 34, Nr. 6, Dez., 2009

Also Published As

Publication number Publication date
US20130159724A1 (en) 2013-06-20
US8935533B2 (en) 2015-01-13

Similar Documents

Publication Publication Date Title
DE202012003716U1 (de) Vorrichtung für ein skalierbares und sicheres Transportprotokoll zur Sensordatenerfassung
DE60302276T2 (de) Verfahren zur ferngesteuerten Änderung eines Kommunikationspasswortes
DE60209475T2 (de) Datensicherungs-kommunikationsvorrichtung und -verfahren
EP2494759B1 (de) Verfahren und vorrichtung zum sicheren übertragen von daten
CH705283B1 (de) Verfahren und Anordnung zum Verwalten gemeinsamer Informationen.
Kim et al. SSTP: a scalable and secure transport protocol for smart grid data collection
EP1793525B1 (de) Verfahren zum Ändern eines Gruppenschlüssels in einer Gruppe von Netzelementen in einem Netz
DE102008046563A1 (de) Verfahren zur Datenübertragung zwischen Netzwerkknoten
EP3506144A1 (de) Verfahren und system zum überprüfen einer integrität einer kommunikation
EP3059895A1 (de) Einmalverschlüsselung von zählerdaten
DE60034009T2 (de) Verfahren zur Aktualisierung von Geheimschlüsseln in einem Datenkommunikationssystem
EP2685696A1 (de) Verfahren zum sicheren Betrieb von Verbundnetzen, insbesondere von Windpark- oder anderen ausgedehnten Netzen
EP1721235B1 (de) Kommunikationssystem und verfahren zur bereitstellung eines mobilen kommunikationsdienstes
EP4109810A1 (de) Einbeziehung mobilfunknetzbasierter kommunikationseinrichtungen in eine quantensichere schlüssel bereitstellende infrastruktur
DE102016218758B4 (de) Vorrichtung und verfahren zur durchgängigen und medienübergreifenden übertragung von kommunikationsprotokollen ohne protokollumsetzung
EP3934160B1 (de) Verfahren und system für verbesserte leistung von dll-netzwerken
EP4503502A1 (de) Verfahren zur lokalen erzeugung quantensicherer schlüssel in einem netzwerk
EP3955511B1 (de) Gesicherte datenübertragung innerhalb eines qkd-netzwerkknotens
CN103118017B (zh) 维护IKE SA的本端发送消息的MessageID的方法及装置
EP4254853B1 (de) Ende-zu-ende verschlüsselte datenübertragung und absicherung der letzten meile
DE102023131881A1 (de) Encryptor, decryptor, kommunikationssystem, verfahren, kommunikationsverfahren
DE102009023414B4 (de) Schlüsselverwaltung für Kommunikationsnetze
DE102024102662A1 (de) System zur sicheren leitweglenkung in einem quantenschlüsselverteilungsnetz
CN119135355A (zh) 一种基于hmac和改进ecc的智能网关数据实时传输的方法
Kim et al. FASiRec: A Fast Session Recovery Scheme for Large-scale VPNs Using IPSec.

Legal Events

Date Code Title Description
R207 Utility model specification

Effective date: 20120913

R150 Utility model maintained after payment of first maintenance fee after three years
R150 Utility model maintained after payment of first maintenance fee after three years

Effective date: 20150504

R082 Change of representative

Representative=s name: PRINZ & PARTNER MBB PATENTANWAELTE RECHTSANWAE, DE

R081 Change of applicant/patentee

Owner name: GEMALTO SA, FR

Free format text: FORMER OWNER: ALCATEL LUCENT, PARIS, FR

R082 Change of representative

Representative=s name: PRINZ & PARTNER MBB PATENTANWAELTE RECHTSANWAE, DE

R151 Utility model maintained after payment of second maintenance fee after six years
R152 Utility model maintained after payment of third maintenance fee after eight years
R071 Expiry of right