Datenkommunikation

Die vorliegende Erfindung betrifft Vorrichtungen, Verfah- ren und Computerprogrammprodukte zur sicheren Datenkommunikation nach einem Netzwerkprotokoll, das mehrere zu einem Protokoll-Stack geschichtete Kommunikationsschichten hat.

Eine der bekanntesten und ältesten Schichtenarchitekturen für Netzwerkprotokolle ist das OSI -Referenzmodell der ITU ( In- ternational Telecommunication Union) bzw. ISO (International Organisation for Standardization) mit den sieben Schichten Bitübertragungsschicht (Schicht 1), Sicherungsschicht (Schicht 2), Vermittlungsschicht (Schicht 3), Transportschicht (Schicht 4), Sitzungsschicht (Schicht 5), Darstellungsschicht (Schicht 6) und Anwendungsschicht (Schicht 7) . Auch das TCP/IP- Referenzmodell , auf dem die meisten der heutigen Internetprotokolle basieren, ist ein geschichtetes Netzwerkprotokoll. Beim TCP/lP-Referenzmodell werden nur vier Schichten verwendet, indem die Bitübertragungs- und Sicherungsschichten zu einer Netz- zugangsschicht und die Sitzungs-, Darstellungs- und Anwendungsschichten zu einer Anwendungsschicht vereinigt werden. Geschichtete Netzwerkprotokolle werden aber auch in elektronischen Steuerungen (Electronic Control Units, ECUs) verwendet, welche über Bussysteme miteinander sicher kommunizieren sollen, beispielsweise nach der Norm IEC 61508 oder auf dem Fahrzeugsektor nach der daraus abgeleiteten Norm ISO 26262 in verschiedensten ASIL-Stufen (Automotive Safety Integrity Levels) , oder in Kommunikationsgeräten zur Vernetzung von Fahrzeugen, Stichwort „car-to-car" (Car2Car) oder „car-to-infrastructure" (Car2X) .

Zur Implementierung solcher geschichteter Netzwerkprotokolle in Endgeräten werden die einzelnen Schichten häufig in autarken Softwaremodulen bzw. -tasks verkapselt, welche über genau definierte Schnittstellen bzw. Kommunikationskanäle mit- einander in Verbindung stehen. Die gleichsam „vertikale" Stape- lung bzw. Übereinanderanordnung der die einzelnen Protokoll - schichten abbildenden Softwaremodule wird dabei auch als „Protokoll-Stack" bezeichnet.

Protokoll-Stacks haben verschiedenste teilweise gegensätz- liehe Anforderung zu erfüllen. Zum einen sollen sie zunehmend höheren Sicherheitsanforderungen genügen, was durch immer komplexere kryptografische Verschlüsselungsverfahren auf Ebene der einzelnen Protokollschichten bewerkstelligt wird. Die Softwaremodule im Protokoll-Stack benötigen dazu auch jeweils entspre- chende kryptografische Schlüssel zum Ver- und Entschlüsseln des Datenverkehrs auf Ebene ihrer Schicht. Zum anderen sollen Protokoll-Stacks auf möglichst sparsamen und kostengünstigen Prozessorsystemen laufen. Meist handelt es sich dabei um eingebettete (embedded) Single-Chip-Prozessorsysteme, z.B. für Endbe- nutzermodems („Residential Gateways") oder internetfähige Endgeräte (Stichwort: „Internet of Things"), in denen der Protokoll-Stack als sog. Middleware fungiert. Gleichzeitig soll auch der Portieraufwand des Protokoll-Stacks von einem spezifischen Prozessor- oder Betriebssystem auf ein anderes möglichst gering sein, was eine entsprechende Abkapselung der Softwaremodule ü- ber Hard- oder Software-Abstraktionsschichten erfordert.

Die Bedeutung von Protokoll-Stacks als Middleware gerade in der heterogenen Umgebung des „Internet of Things" ist in Bandyopadhyay S. et al . , „Role of Middleware for Internet of Things: A Study", International Journal of Computer Science & Engineering Survey (IJCSES) , Bd. 2, Nr. 3, August 2011, beschrieben. Einen guten Überblick über die Sicherheitsanforderungen in derartigen Umgebungen geben Kocher, P., et. al . , im „Security as a New Dimension in Embedded System Design", DAC 2004, 7 - 11 Juni 2004, San Diego, Kalifornien, USA.

Die Erfindung setzt sich zum Ziel, Vorrichtungen und Verfahren der einleitend genannten Art zu schaffen, welche die vorgenannten gegensätzlichen Anforderungen besser zur Deckung bringen als die bekannten Lösungen. Dieses Ziel wird in einem ersten Aspekt der Erfindung mit einer Vorrichtung zur sicheren Datenkommunikation gemäß einem Netwerkprotokoll mit mehreren zu einem Protokoll-Stack geschichteten Kommunikationsschichten erreicht, die ein Prozes- sorsystem hat, in dem ein Prozessor, von einem Task-Scheduler gesteuert, mehrere autarke Softwaremodule abarbeitet, die jeweils eine Kommunikationsschicht des Protokoll-Stacks ausführen,

wobei die Softwaremodule über Kommunikationskanäle zum Protokoll-Stack verkettet sind und der Protokoll-Stack mit einem Schnittstellen-Framework zur Datenkommunikation mit einem externen Netzwerk in Verbindung steht, und

wobei zumindest ein Softwaremodul einen zugeordneten kryp- tographischen Schlüssel zur sicheren Dankenkommunikation in seiner Kommunikationsschicht verwendet,

welche Vorrichtung sich dadurch auszeichnet,

dass der Task-Scheduler dafür ausgebildet ist, einen über das Schnittstellen-Framework aus dem externen Netzwerk erhaltenen Schlüssel an das zugeordnete Softwaremodul zu verteilen.

In einem zweiten Aspekt schafft die Erfindung dazu ein

Verfahren zur sicheren Datenkommunikation gemäß einem Netzwerkprotokoll mit mehreren zu einem Protokoll-Stack geschichteten Kommunikationsschichten,

wobei in einem Prozessorsystem ein Prozessor, von einem Task-Scheduler gesteuert, mehrere autarke Softwaremodule abarbeitet, die jeweils eine Kommunikationsschicht des Protokoll- Stacks ausführen,

wobei die Softwaremodule über Kommunikationskanäle zum Protokoll-Stack verkettet sind und der Protokoll-Stack mit ei- nem Schnittstellen-Framework zur Datenkommunikation mit einem externen Netzwerk in Verbindung steht, und

wobei zumindest ein Softwaremodul einen zugeordneten kryp- tographischen Schlüssel zur sicheren Datenkommunikation in seiner Kommunikationsschicht verwendet,

welches Verfahren sich dadurch auszeichnet, dass der zumindest eine Schlüssel über das Schnittstellen- Framework aus dem externen Netzwerk erhalten und vom Task- Scheduler an das zugeordnete Softwaremodul verteilt wird.

Gemäß der Erfindung wird somit der Task-Scheduler, der in einem Single-Prozessorsystem, z.B. in einem Residental Gateway, einem Securitygateway oder einer Steuerelektronik, für das Task-Switching zwischen autarken, die einzelnen Protokollschichten abbildenden Softwaremodulen zuständig ist, für die Verteilung von kryptografischen Sicherheitsschlüsseln, die bei- spielsweise von einem Kommunikationspartner oder einer zentralen Schlüsselerzeugungsinstanz im Netzwerk kommen, an die jeweiligen Softwaremodule eingesetzt. Dies erlaubt eine besonders einfache Implementierung von beliebigen Sicherheitsmaßnahmen auf Ebene der verschiedenen Protokollschichten, ohne die Ver- kapselung und Abstraktion der einzelnen Softwaremodule gegenüber der Hardware, dem Betriebssystem, Peripherietreibern od.dgl. zu beeinträchtigen und ohne besondere Ressourcen für die Schlüsselverteilung zu benötigen: Der bereits vorhandene Task-Scheduler wird zu diesem Zweck einfach mitverwendet.

Die erfindungsgemäße Lösung eignet sich für jede Art von

Netzwerkprotokoll, beispielsweise nach dem TCP/IP-Referenz - modell im Falle eines Internetmodems oder geschichteten Protokollen zur Realisierung sicherheitskritischer Anforderungen entsprechend den in der ISO 26262 definierten Automotive In- tegrity Safety Levels (ASIL) im Falle von elektrischen Fahrzeugkomponenten. Nach einer anderen Ausführungsform der Erfindung ist das Netzwerkprotokoll nach dem OSI -Referenzmodell aufgebaut und jedes Softwaremodul führt eine Schicht des OSI- Referenzmodells aus, beispielsweise für ein ISDN-Modem oder ei- nen ISDN/lP-Schnittstellenadapter, auch „ALL- IP-Modem" genannt.

Die Softwaremodule können jeweils einen Eingang für mindestens einen Nachrichtenkanal haben, welcher mit dem Task- Scheduler verbunden ist, um so den jeweiligen Schlüssel zu erhalten . Der (zumindest eine) Nachrichtenkanal des Softwaremoduls kann auch dazu verwendet werden, das Softwaremodul in einen De- bugging-Modus zu versetzen und es z.B. mittels Debugging- Nachrichten, die über den Nachrichtenkanal ausgetauscht werden, zu debuggen und/oder insbesondere zu solchen Debugging-Zwecken ein- und auszuschalten.

Ein vom Task-Scheduler erhaltener weiterer Schlüssel kann insbesondere auch dazu verwendet werden, den Nachrichtenverkehr auf dem Nachrichtenkanal zu ver- bzw. entschlüsseln, um auch hier eine sichere Kommunikation zu gewährleisten. Beispielsweise kann dieser weitere Schlüssel vom Softwaremodul für eine verschlüsselte Übertragung jenes Schlüssels, den es in seiner Protokollschicht verwendet, genutzt werden.

In einer vorteilhaften Ausführungsform der Erfindung kann der Task-Scheduler auch Teil eines vom Prozessor ausgeführten Hardware-Abstraktionsmoduls für die Softwaremodule sein, das den Softwaremodulen jeweils eine hardwareabstrahierte Betriebssystemumgebung zur Verfügung stellt und zu diesem Zweck bereits zumindest einen Nachrichtenkanal zu diesen hat.

Die Erfindung eignet sich grundsätzlich für alle Arten von

Datenkommunikations-Endgeräten, seien diese auch lediglich Kommunikationsschnittstellen in Steuergeräten, beispielsweise E- CUs, die über Datenbusse miteinander sicher kommunizieren. Bevorzugt ist die Vorrichtung ein Modem oder eine ECU und das Prozessorsystem ein Einzelprozessorsystem, in dem der Protokoll-Stack als „Embedded Security Middleware" fungiert. Alternativ kann diese „Embedded Security Middleware" auch in einem Multiprozessorsystem eingebettet sein.

In einem dritten Aspekt schafft die Erfindung ferner ein Computerprogrammprodukt, verkörpert auf einem maschinenlesbaren Datenträger, das dafür ausgebildet ist, das hier vorgestellte Verfahren zu implementieren.

Die Erfindung wird nachstehend anhand eines in den beigeschlossenen Zeichnungen dargestellten Ausführungsbeispiels nä- her erläutert. In den Zeichnungen zeigt: Fig. 1 die Systemarchitektur der Vorrichtung der Erfindung in einem Blockdiagramm;

Fig. 2 eines der Softwaremodule der Vorrichtung von Fig. 1 im Detail; und

Fig. 3 ein Datenflussdiagramm des Verfahrens der Erfindung bei der Datenkommunikation zweier Vorrichtungen nach Fig. 1 ü- ber ein Netzwerk.

In Fig. 1 ist eine Vorrichtung 1 zur Datenkommunikation gemäß einem geschichteten Netwerkprotokoll dargestellt, bei- spielsweise dem OSI- oder TCP/IP-Referenzmodell . Fig. 3 zeigt zwei derartige Vorrichtungen 1, die über ein Netzwerk 2 miteinander und (optional) mit einer Schlüsselerzeugungszentrale 3 kommunizieren, wie später noch ausführlicher erläutert. Das Netzwerk 2 kann beispielsweise das Internet, ein WAN (Wide Area Network), LAN (Local Area Network), Mobilfunknetz und/oder ein kabelgebundenes Telefonnetz sein, und die Vorrichtung 1 kann darin einen Netzwerk-Switch oder -Router, ein Modem, ein Gateway oder ein Endgerät bilden. Im Falle eines Telefonnetzes ist das Netzwerkprotokoll in der Regel nach dem OSI -Referenzmodell aufgebaut und die Vorrichtung 1 ist z.B. ein ISDN- oder ALL-IP- Endgerät; im Falle des Internets, eines WANs oder LANs ist das Netzwerkprotokoll in der Regel nach dem TCP/IP-Referenzmodell aufgebaut und die Vorrichtung 1 ist z.B. ein ADSL- oder Powerline-Modem. Das Netzwerk 2 kann aber auch ein geräteinternes Bussystem sein, über das elektronische Komponenten über ein geschichtetes Netzwerkprotokoll („Busprotokoll") miteinander sicher kommunizieren, beispielsweise elektronische Fahrzeugkomponenten an einem Onboard-Fahrzeugbussystem. Die Vorrichtung 1 kann in diesem Fall z.B. eine elektronische Steuerung (Electro- nie Control Unit, ECU) sein, die über das Onboard-Bussystem des Fahrzeugs mit anderen elektronischen Komponenten kommuniziert.

Die in Fig. 1 gezeigte Vorrichtung 1 wird in der Regel in Softwaretechnik auf einem Hardware-Prozessorsystem implementiert, das dazu - wie in der Technik bekannt - Stromversorgun- gen PWR, Speicher MEM, Schnittstellen I/F und zumindest einen Prozessor MP umfasst, welcher entsprechende Softwarekomponenten abarbeitet. Die in Fig. 1 dargestellten Komponenten der Vorrichtung 1 sind daher Softwarekomponenten, welche zur Laufzeit der Software im Speicher MEM der Vorrichtung 1 vorliegen und vom Prozessor MP entsprechend abgearbeitet werden, wie in der Technik bekannt .

Das Prozessorsystem, auf dem die Vorrichtung 1 implementiert ist, ist in der Regel ein kostengünstiges Single-Chip- Prozessor-System mit nur einem Hauptprozessor MP, der die in Fig. 1 gezeigten (Software) -Komponenten der Vorrichtung 1 sequentiell in Form von Tasks abarbeitet. Dazu ist ein Tasks- Scheduler 4 vorgesehen, der die Programmsteuerung des Prozessors MP periodisch sequentiell an einzelne Softwaremodule Li, L ₂ , allgemein Li, sowie ein Schnittstellen-Frameworkmodul 5 übergibt, siehe Programmablaufsteuerungsschleife 6. Der Task- Scheduler 4 ist seinerseits eine Softwarekomponente und kann Teil eines vom Prozessor MP ausgeführten Hardware- und/oder Betriebssystem- bzw. Software-Abstraktionsmoduls (Operating System Abstraction Module, OSAM) 7 sein, das ebenfalls im Zuge der Schleife 6 vom Prozessor MP regelmäßig bedient bzw. abgearbeitet wird.

Das Abstraktionsmodul 7 stellt gleichsam eine Betriebssystemumgebung für die Softwaremodule Li zur Verfügung, z.B. zur Bereitstellung von Zeitgebern, zur Verwaltung von dynamischen Speicheranforderungen etc. sowie zur Errichtung von Kommunikationskanälen 8, 9, über welche sie untereinander bzw. mit dem Schnittstellen-Frameworkmodul 5 in Verbindung stehen, und für Nachrichtenkanäle 10, über welche sie Steuerungsnachrichten vom Abstraktionsmodul 7 bzw. dessen Task-Scheduler 4 empfangen kön- nen.

Der Prozessor MP der Vorrichtung 1 kann auch Teil eines Multiprozessorsystems sein, das einen Verbund einzelner Vorrichtungen 1 bildet. Dabei können sich mehrere Vorrichtungen 1 einen Prozessor MP teilen, oder eine Vorrichtung 1 kann mehrere Prozessoren MP haben. In einem solchen Multiprozessorsystem kann der Datenaustausch zwischen den Vorrichtungen 1 insbesondere auch über die Kommunikationskanäle 8, 9 eines oder mehrerer der Softwaremodule Li realisiert sein.

Jedes Softwaremodul Li kann dabei einen Eingang für mehr als einen Nachrichtenkanal 10 haben. Der bzw. die Nachrichtenkanäle 10 eines Softwaremoduls Li können zusätzlich auch dazu verwendet werden, das jeweilige Softwaremodul Li - lokal oder von einem anderen, angeschlossenen Netzwerk her - zu debuggen oder zu diesen Zwecken ein- und auszuschalten.

Fig. 2 zeigt den internen Aufbau eines der Softwaremodule

Li im Detail. Jedes Softwaremodul Li ist für eine der Kommunikationsschichten des geschichteten Netwerkprotokolls zuständig, welches die Vorrichtung 1 bzw. das von dieser ausgeführte Verfahren abwickelt. Im Falle des OSI -Referenzmodells sind sieben Softwaremodule Li (i = 1 ... 7) vorhanden, welche jeweils eine der sieben OSI -Schichten ausführen. Die Softwaremodule Li sind dazu gegeneinander „verkapselt" bzw. „autark", indem sie lediglich über die Nachrichtenkanäle 8, 9 zu einem „Stapel" verkettet sind; die Gesamtheit der übereinander gestapelten Software- module Li wird als Protokoll-Stack 11 bezeichnet.

Es versteht sich, dass im Falle von anderen Netzwerkprotokollen, beispielsweise dem vierschichtigen TCP/IP-Referenz - modell, nur vier Softwaremodule Li (i = 1 ... 4) erforderlich sind, von denen jedes für die Funktionalität einer Kommunikati- onsschicht zuständig ist.

Gemäß Fig. 2 besitzt jedes Softwaremodul Li dazu ein entsprechendes Steuerungsprogramm 12 und zu dessen Ausführung (vom Abstraktionsmodul 7 bereitgestellte) Ressourcen, insbesondere eine interne Nachrichten-Warteschlange 13, welche über die Kom- munikationskanäle 8, 9 einlangende Kommunikationsnachrichten sowie über den Nachrichtenkanal 10 einlangende Steuerungsnachrichten zur Abarbeitung durch das Steuerungsprogramm 12 aufnimmt .

Das in der Schichtenhirarchie am untesten stehende Soft- waremodul Li des Protokoll-Stacks 11, hier das Softwaremodul Li für die Bitübertragungsschicht des OSI -Referenzmodells oder die Netzzugangsschicht des TCP/IP-Referenzmodells , ist über seine Kommunikationskanäle 8, 9 mit dem Schnittstellen-Frameworkmodul 5 verbunden, über welches der physische Datenverkehr mit dem Netzwerk 2 abgewickelt wird. Die dazu erforderlichen physischen Schnittstellen I/F werden vom Schnittstellen-Frameworkmodul 5 dem Protocol-Stack 11 bzw. dessen Software-Modulen Li abstrahiert von der Hardware- bzw. Softwarebetriebsumgebung dargeboten .

Der Quellcode eines Software-Moduls Li kann dadurch sowohl in einer Embedded- Zielumgebung als auch als Kernelmode-Treiber eines PC-Betriebssystems verwendet werden, ohne den Quellcode des Software-Modules Li portieren zu müssen. Dies hat den weiteren Vorteil, dass Quellcode für Embedded- Systeme zunächst un- ter PC-Betriebssystemen entwickelt, getestet und erst danach für ein beliebiges Embedded-Zielsystem kompiliert werden kann, ohne dass der Quellcode für die Softwaremodule Li portiert werden muss („ Portability without Porting") . Durch den hohen Grad an Wiederverwendung von Code der Softwaremodule Li wird auch eine ständige Verbesserung der Qualität des Codes durch „De- sign-Re-Use" -Optimierung erzielt. Daraus ergibt sich auch der weitere Vorteil, Leistungsanforderungen an ein Embedded- Zielsystem, wie Prozessorleistungen und Anforderungen an den Speicher, bereits vor der Entwicklung des Embedded-Zielsystems bzw. der ECU abschätzen zu können. Dadurch, dass die Schnittstellen und Kommunikationskanäle der Softwaremodule Li spezifiziert sind, können diese auch in verteilten Teams großer Entwicklungsorganisationen auf einfache Weise wiederverwendet werden .

Zur Implementierung von kryptografischen Sicherheitsmechanismen in der von der Vorrichtung 1 abgewickelten Netzwerkprotokoll werden in einer oder mehreren Kommunikationsschichten, d.h. in einem oder mehreren der Softwaremodule Li , jeweils ein oder mehrere kryptografische Schlüssel 14 verwendet, beispiels- weise öffentliche bzw. private Schlüssel von Public/Private- Key-Verschlüsselungsverfahren, welche zwei Kommunikationspartner über das Netzwerk 2 austauschen, oder gemeinsame Schlüssel von Shared-Key-Verschlüsselungsverfahren, die beispielsweise von der Schlüsselerzeugungszentrale 3 erzeugt und über das Netzwerk 2 verteilt werden, od.dgl.

Das für die jeweilige Kommunikationsschicht zuständige Softwaremodul Li benötigt daher die Kenntnis des/der jeweiligen Schlüssel (s) 14, der/die in seiner Kommunikationsschicht für die jeweiligen Ver- bzw. Entschlüsselung erforderlich ist/sind.

Zu diesem Zweck ist der Task-Scheduler 4 dazu ausgebildet, solche über das Netzwerk 2 und das Schnittstellen- Frameworkmodul 5 aus dem externen Netzwerk 2 erhaltene Schlüssel 14 an das jeweilige Softwaremodul Li zu verteilen, und zwar über dessen Nachrichtenkanal 10. Bei diesen Schlüsseln 14 kann es sich auch lediglich um Bestandteile eines größeren, zusammengesetzten bzw. „kompletten" Schlüssels handeln, der für die Ver- bzw. Entschlüsselung in der Protokollschicht des Softwaremoduls Li erforderlich ist. In diesem Fall werden mehrere im Softwaremodul Li vom Task-Scheduler 4 auf diese Weise erhaltene Schlüssel 14 zu dem erforderlichen kompletten Schlüssel zusammengesetzt .

Die Schlüssel 14 können z.B. vom Abstraktionsmodul 7 über das Schnittstellen-Frameworkmodul 5 vom Kommunikationspartner im Netzwerk 2, beispielsweise einer anderen Vorrichtung 1 oder der Schlüsselerzeugungszentrale 3, angefordert („pull") oder erhalten („push") werden und der Task-Scheduler 4 wird lediglich zur entsprechenden Verteilung bzw. Zustellung des/der so erhaltenen Schlüssel (s) 14 an das jeweilige richtige Softwaremodul Li im Zuge des Programmablaufs 6 verwendet. Alternativ fordert der Task-Scheduler 4 selbst an bzw. empfängt selbst den bzw. die Schlüssel 14 aus dem Netzwerk 2 und sendet diese (n) an das jeweilige Softwaremodul Li. Eine weitere Möglichkeit ist, dass eines der höherrangigen Softwaremodule Li, insbesondere ein Softwaremodul Li einer höheren anwendungsorientierten Schicht im Zuge einer Anwendung, einen oder mehrere Schlüssel für ein niederrangigeres Softwaremodul Li empfängt und über den Task-Scheduler 4 bzw. das Abstraktionsmodul 7 an das entsprechende niederrangigere Softwaremodul Li weiterreicht. Auch dabei fungiert der Task-Scheduler 4 wieder - im Zuge der Abarbei- tung der Steuerschleife 6 - als Zusteller des jeweiligen Schlüssels 14 an das entsprechende Softwaremodul Li über dessen Nachrichtenkanal 10. Ein vom Task-Scheduler 4 erhaltener Schlüssel 14 kann in einem Softwaremodul Li auch dazu verwendet werden, die Kommunikation auf dessen (zumindest einem) Nach- richtenkanal 10 zu ver- bzw. entschlüsseln, z.B. zur sicheren Übertragung eines folgenden Schlüssels 14.

Die Erfindung ist nicht auf die dargestellten Ausführungsformen beschränkt, sondern umfasst alle Varianten, Kombinationen und Modifikationen derselben, die in den Rahmen der ange- schlossenen Ansprüche fallen. Beispielsweise kann der Nachrichtenkanal 10 der vorstehend beschriebenen Vorrichtung auch dazu verwendet werden, um ein Softwaremodule Li - lokal oder über ein anderes Netzwerk - zu debuggen oder ein- und auszuschalten, wobei der Informationsaustausch über diesen Kanal 10 entspre- chend den vorstehend beschriebenen Verfahren ebenso verschlüsselt werden kann.