DE102020204059A1

DE102020204059A1 - Verfahren zur Behandlung einer Anomalie von Daten, insbesondere bei einem Kraftfahrzeug

Info

Publication number: DE102020204059A1
Application number: DE102020204059.1A
Authority: DE
Inventors: Manuel Jauss; Mustafa Kartal; Roland Steffen
Original assignee: Robert Bosch GmbH
Current assignee: Robert Bosch GmbH
Priority date: 2020-03-28
Filing date: 2020-03-28
Publication date: 2021-09-30
Also published as: CN115398427A; WO2021197822A1; JP7467670B2; JP2023519910A

Abstract

Es wird ein Verfahren zur Behandlung einer Anomalie von Daten, insbesondere bei einem Kraftfahrzeug, vorgeschlagen, wobei mindestens ein Sensor (24,26, 28) zur Anomalieerkennung Daten (211) erhält erhält, wobei der Sensor (24,26, 28) die erhaltenen Daten (211) auf Anomalien untersucht und bei einer erkannten Anomalie in Abhängigkeit der zugehörigen Daten (211) ein Ereignis (220, 221) erzeugt und an einen Ereignismanager (30) weiterleitet, wobei eine zumindest eine vertrauenswürdige Zone (Z2) und eine nicht vertrauenswürdige Zone (Z1) vorgesehen werden, wobei zumindest ein Sensor (24,26, 28; 40, 60) und der Ereignismanager (30) der vertrauenswürdigen Zone (Z2) zugeordnet sind.

Description

Technisches Gebiet
Die Erfindung betrifft ein Verfahren zur Behandlung einer Anomalie von Daten, insbesondere bei einem Kraftfahrzeug.
Stand der Technik
Aus der DE 102018209407 A1 sind bereits eine Vorrichtung und ein Verfahren zur Behandlung einer Anomalie in einem Kommunikationsnetzwerk, insbesondere eines Kraftfahrzeugs bekannt. Wenigstens ein Detektor analysiert einen Datenstrom im Kommunikationsnetzwerk, wobei der wenigstens eine Detektor wenigstens eine Anomalie durch ein regelbasiertes Anomalieerkennungsverfahren erkennt, wenn wenigstens ein Parameter für ein Datenpaket des Datenstroms von einem Sollwert abweicht, wobei der wenigstens eine Detektor Information über wenigstens eine erkannte Anomalie über das Kommunikationsnetzwerk sendet.
Die automatische Erstellung eines Protokolls, Historie oder Bericht (Logging) insbesondere bei erkannten Anomalien bzw. Ereignissen soll bei hohen Ereignis-Raten und/oder langanhaltenden Angriffen ohne Überlast und Ablehnung entsprechender Services erfolgen. Die Einträge des Loggings bzw. entsprechender Ereignisberichte sollen authentisch, integer und verfügbar sein. Wenn möglich soll eine für den Angreifer nicht deterministische Historie über einen kompletten (langen andauernden) Angriff erstellt werden. Manipulationen und insbesondere das Löschen durch einen Angreifer soll vermieden werden. Außerhalb eines Steuergeräts sollen die Logging-Einträge vor unberechtigter Analyse geschützt werden. Der Logger soll die Ereignisberichte zuverlässig beispielsweise über eine Schnittstelle zu einem externen Knoten senden. Nach einer erfolgreichen Übertragung an den externen Knoten können die Ereignis-Einträge lokal gelöscht werden, besonders bevorzugt nach einer insbesondere authentifizierten Bestätigung durch die empfangende Instanz. Weiterhin sollte der Logger ein sogenanntes Heartbeat-Signal senden, welches eine Netzverbindung anzeigt. Die Ansammlung von Ereignissen sollte möglich sein, um die Anzahl der zu bearbeitenden Logging-Einträge zu reduzieren.
Unter normalen Betriebsbedingungen werden Ereignisse (Events) nicht oder kaum getriggert, beispielsweise in der Größenordnung von einem Ereigns pro Stunde. Im schlimmsten Fall hat ein Angreifer die volle Kontrolle über eine Schnittstelle, insbesondere Ethernet-Schnittstelle. Bei einer vollen Bandbreite von beispielsweise 100 Mbit könnte ein Angreifer maximal 128.000 UDP (User Datagram Protocol, ein Netzwerkprotokoll)-Frames pro Sekunde senden. Jeder solcher Frames könnte möglicherweise ein Ereignis (erkannte Anomalie in einem Datenstrom) triggern. Solch ein Angriff wird mit einer Häufigkeit von einer Attacke über die Lebensdauer eines Fahrzeugs angenommen. Die erlaubte Anzahl der sogenannten Schreibzyklen eines Speichers, insbesondere eines Flash-Speichers, ist begrenzt und muss berücksichtigt werden. Ebenfalls ist die Anzahl der aktiven Betriebsstunden begrenzt. Ebenfalls ist die Verfügbarkeit des übergeordneten externen Daten-Loggers begrenzt. Deshalb müssen entsprechende Logging-Events bzw. Ereignisberichte zwischengespeichert werden. Sämtliche Logging-Einträge bzw. Ereignisberichte sollten zu dem übergeordneten Daten-Logger transferiert werden können zumindest einmal am Tag.
Für herkömmliche IDS-oder IDPS-Systeme (Intrusion Detection System, Eindringungserkennung, ein System zur automatisierten Erkennung von Angriffen auf Computernetzwerke bzw. Rechnerschnittstellen; bzw. IDPS: Intrusion Detection Prevention System, bei einem erkannten Eindringungsversuch werden entsprechende Daten nicht weitergeleitet und damit der Eindringungsversuch unterbunden) sind oftmals deterministisches Verhalten und die begrenzten Ressourcen der eingebetteten Systeme problematisch.
Wünschenswert ist es demgegenüber ein verbessertes Verfahren zur Anomalieerkennung anzugeben. Diese Aufgabe wird gelöst durch die Merkmale des unabhängigen Anspruchs.
Offenbarung der Erfindung
Dies wird durch das Verfahren nach dem unabhängigen Anspruch erreicht.
Dadurch, dass zumindest eine vertrauenswürdige Zone und eine nicht vertrauenswürdige Zone vorgesehen werden, wobei zumindest ein Sensor und der Ereignismanager der vertrauenswürdigen Zone zugeordnet sind, kann mithilfe eines 2-stufiges Sicherheitskonzepts der Manipulationsschutz weiter erhöht werden. Insbesondere die Anordnung von Sensor und/oder Ereignismanager in der vertrauenswürdigen Zone als vertrauenswürdige Instanz erschwert Zugriffsmöglichkeiten auf sensible Daten und Manipulationsmöglichkeiten.
In einer zweckmäßigen Weiterbildung ist vorgesehen, dass zumindest ein Kommunikationsadapter in derselben Zone angeordnet ist wie der Ereignismanager, wobei der Kommunikationsadapter der Kommunikation eines von dem Ereignismanager zumindest teilweise erstellten Ereignisberichts dient. Damit kann der Kommunikationsadapter die Überprüfung eines Datentransfers in die andere Zone vornehmen, während er innerhalb der sicherheitsrelevanten Zone mit Ereignismanager und/oder Sensor kommunizieren kann.
In einer zweckmäßigen Weiterbildung ist vorgesehen, dass der Kommunikationsadapter auch einer nicht vertrauenswürdigen Zone zugeordnet wird. Über diesen Teil erfolgt die Kommunikation mit der übergeordneten IDS Instanz, die in der Regel nicht vertrauenswürdige Instanzen darstellen.
In einer zweckmäßigen Weiterbildung ist vorgesehen, dass der Sensor in der vertrauenswürdigen Zone zumindest Daten, insbesondere defragmentierte Daten, von einem Sensor enthält, der in der nicht vertrauenswürdigen Zone angeordnet ist, wobei der Sensor in der vertrauenswürdigen Zone die erhaltenen Daten auf Anomalien prüft und bei Vorliegen einer Anomalie ein Ereignis erzeugt und/oder wobei der Sensor in der nicht vertrauenswürdigen Zone die erhaltenen Daten auf Anomalien prüft und bei Vorliegen einer Anomalie ein Ereignis erzeugt. Damit gelangen in die vertrauenswürdige Zone lediglich Daten, die unbedingt für die Weiterverarbeitung im Ereignismanager benötigt werden. Die Manipulationsmöglichkeiten werden dadurch weiter reduziert.
In einer zweckmäßigen Weiterbildung ist vorgesehen, dass ein Versenden des Ereignisberichts erfolgt, indem der Kommunikationsadapter in der vertrauenswürdigen Zone den Ereignisbericht in einen Speicher der nicht vertrauenswürdigen Zone bringt, auf den der Kommunikationsadapter in der nicht vertrauenswürdigen Zone zugreifen und verschicken kann. Auf diese Art und Weise kann ein sicherer Datentransfer von der einen in die andere Zone sichergestellt werden.
In einer zweckmäßigen Weiterbildung ist vorgesehen, dass der Ereignisbericht zumindest eine sich für jeden Ereignisbericht verändernde Größe und/oder zumindest eine Authentifizierungs-Information umfasst und/oder durch eine Verschlüsselung verschlüsselt wird. Dadurch kann die übergeordnete Instanz prüfen, ob es sich um authentische Daten handelt. Besonders zweckmäßig ist hierzu vorgesehen, dass die Authentifizierungs-Information gebildet wird durch weitere im Ereignisbericht enthaltene Informationen.
In einer zweckmäßigen Weiterbildung ist vorgesehen, dass ein der vertrauenswürdigen Zone zugeordnetes Sicherheitsmodul eine sich für jeden Ereignisbericht veränderliche Größe und/oder eine Authentifizierungs-Information und/oder eine Verschlüsselung bereitstellt. Dadurch kann eine sichere, authentische und vertrauliche Verbindung mit einer übergeordneten Instanz hergestellt werden.
In einer zweckmäßigen Weiterbildung ist vorgesehen, dass nach Versenden des Ereignisberichts ein Bestätigungssignal empfangen wird, welches von dem Kommunikationsadapter der nicht vertrauenswürdigen Zone empfangen und an den Kommunikationsadapter der vertrauenswürdigen Zone weitergeleitet wird. Über das Bestätigungssignal kann der ordnungsgemäße Abschluss einer Übersendung des Ereignisberichts überprüft und weitere Maßnahmen wie beispielsweise das Leeren des Speichers veranlasst werden
In einer zweckmäßigen Weiterbildung ist vorgesehen, dass das Bestätigungssignal zumindest eine für jedes Bestätigungssignal veränderliche Größe und/oder zumindest bestimmte Daten bzw. Pattern und/oder zumindest eine Authentifizierungs-Information und/oder zumindest eine konstante Länge umfasst und/oder mit einer Verschlüsselung verschlüsselt wird. Durch die veränderliche Größe sieht das Bestätigungssignal insbesondere nach Verschlüsselung immer signifikant unterschiedlich aus gegenüber dem Angreifer und ist damit nicht interpretierbar. Durch das zusätzliche veränderliche Signal wird die Aktualität sichergestellt, da nicht auf einen Altenereignisbericht zurückgegriffen werden kann. Die Authentifizierungs-Information stellt sicher, dass das Bestätigungssignal von einer echten übergeordneten Instanz stammt, und nicht von einem Angreifer erzeugt wurde. Somit kann der lokale Ereignisbericht vertrauenswürdig gelöscht werden.
In einer zweckmäßigen Weiterbildung ist vorgesehen, dass der Kommunikationsadapter der vertrauenswürdigen Zone das empfangene Bestätigungssignal unter Verwendung eines in der sicherheitsrelevanten Zone angeordneten Sicherheitsmoduls entschlüsselt und/oder authentifiziert. Durch die weitere Überprüfung in der vertrauenswürdigen Zone wird die Sicherheit der Kommunikation weiter verbessert. Besonders zweckmäßig ist hierzu vorgesehen, dass das empfangene Bestätigungssignal entschlüsselt und/oder authentifiziert wird, indem überprüft wird, ob die veränderliche Größe des verschickten Ereignisberichts in dem Bestätigungssignal enthalten ist. Somit muss auch für das Bestätigungssignal keine neue veränderliche Größe generiert werden, sondern es kann besonders zweckmäßigerweise die insbesondere durch ein Sicherheitsmodul in der vertrauenswürdigen Zone generierte veränderliche Größe, die im Rahmen des Ereignisbericht mitgeschickt wurde, auch für das Bestätigungssignal verwendet werden.
In einer zweckmäßigen Weiterbildung ist vorgesehen, dass bei einer Übertragung von Daten von einer Zone in die andere Zone der Sensor die Daten vor einer Benutzung überprüft, insbesondere ob ein Ereignis aufgetreten ist und/oder dass für den Fall, dass kein Ereigniss detektiert wurde, die Daten für die Benutzung in der anderen Zone freigegeben werden. Dadurch werden die Manipulationsmöglichkeiten weiter verringert. Besonders zweckmäßig ist hierzu vorgesehen, dass bei einem Auftreten eines Ereignisses die Daten nicht in die andere Zone transferiert werden und/oder der Sensor das Ereignis an den Ereignismanager weiterleitet.
In einer zweckmäßigen Weiterbildung ist vorgesehen, dass der Ereignismanager und/oder der Kommunikationsadapter der vertrauenswürdigen Zone und/oder der Sensor der vertrauenswürdigen Zone und/oder das Sicherheitsmodul auf einem Rechnerkern implementiert sind. Somit können alle sicherheitsrelevanten Funktionen auf einem Rechnerkern implementiert werden, was die Sicherheit weiter erhöht.
In einer zweckmäßigen Weiterbildung ist vorgesehen, dass zumindest einer Recheneinrichtung bestimmte ausführbaren Anwendungsprogramme zu einer von den wenigstens zwei Zonen zugeordnet werden, wobei die Zonen Ressourcen der Recheneinrichtung charakterisieren, die für eine Ausführung eines betreffenden Anwendungsprogramms nutzbar sind, optional Ausführen wenigstens eines der Anwendungsprogramme in Abhängigkeit der ihm zugeordneten Zone. Durch die genannten Zuordnungen zwischen Zonen und Funktionen kann sichergestellt werden, dass nur sicherheitsrelevante Funktionen in der vertrauenswürdigen Zone ausgeführt werden. Dies kann bevorzugt auch dadurch erfolgen, indem die Verfahrensschritte folgendes aufweisen: Austauschen von ersten Daten zwischen verschiedenen Zonen über einen Pufferspeicher, insbesondere Arbeitsspeicher, wobei insbesondere das Austauschen der ersten Daten zwischen der ersten Zone und der zweiten Zone folgende Schritte aufweist: d1) Kopieren der ersten Daten in einen der ersten Zone zugeordneten ersten Pufferspeicherbereich, d2) Überprüfen der kopierten ersten Daten, und, insbesondere in Abhängigkeit der Überprüfung, d3) Kopieren der ersten Daten aus dem der ersten Zone zugeordneten ersten Pufferspeicherbereich in einen der zweiten Zone zugeordneten zweiten Pufferspeicherbereich. Damit wird sichergestellt, wie ein sicherer Datenaustausch zwischen den Zonen bevorzugt verläuft.
Weitere vorteilhafte Ausgestaltungen ergeben sich aus der folgenden Beschreibung und der Zeichnung. In der Zeichnung zeigt
In der Zeichnung zeigt:

1 schematisch Komponenten einer Eindringungserkennung,
2 einen beispielhaften Aufbau bzw. Wechselwirkung von empfangenen Daten, daraus abgeleitetem Ereignis, Aufbau des zugehörigen selektierten Ereignisses sowie einen Ereignisbericht,
3 schematisch ein vereinfachtes Blockdiagramm von Aspekten gemäß einer weiteren bevorzugten Ausführungsform,
4 schematisch ein vereinfachtes Blockdiagramm von Aspekten gemäß einer weiteren bevorzugten Ausführungsform,
5-10 unterschiedliche Kommunikationsabläufe zwischen Ereignismanager, Kommunikationsadapter, weiterer IDS Instanz sowie Backend.

Im Zusammenhang mit Aspekten der folgenden Ausführungen werden im Folgenden Abweichungen von einem Normalverhalten, die aus verschiedenen Gründen in einem realen Betrieb in Daten 211 (beispielsweise Daten eines Kommunikationssystems oder Systemdaten) eines insbesondere vernetzten Systems können, als Anomalie bezeichnet. Ursachen dafür können beispielsweise folgender Art sein: Defekte oder ganz ausgefallene Sensoren liefern falsche oder gar keine Daten, Bauteile des Systems sind beschädigt, das System wurde durch externe, aber auch lokale bzw. physikalische Angriffe (z. B. einen Hackerangriff) manipuliert.
Die Erkennung von Anomalien in Daten 211 wird mittels eines sogenannten Intrusion Detection Systems, IDS oder IDPS, umgesetzt. Mit IDS wird im Folgenden ein System bezeichnet, das Daten 211 auf Anomalien überwacht. Hierbei kann es sich beispielsweise um Daten 211 bei der Datenverbindung in einem Kommunikationsnetz, über welches das Steuergerät 20 wie beispielsweise ein Gateway auf unterschiedlichen Kommunikationskanälen (beispielsweise über Bussysteme wie 25 oder Internet 27) kommuniziert, handeln. Jedoch sollen auch andere Daten 211, beispielsweise Systemdaten innerhalb eines Steuergeräts (bzw. darin angeordneten Host 29 bzw. Mikrocontroller oder Prozessor oder innerhalb eines Chips) auf Anomalien durch dieses IDS System überprüft werden. Die Detektion von Anomalien der Daten 211 erfolgt durch geeignete Sensoren 24, 26, 28. Die Sensoren 24, 26, 28 sind an die jeweilige Quelle der Daten 211 (im Ausführungsbeispiel Bussysteme 25, 27 oder Host 29) angepasst.
Gemäß 1 ist ein Steuergerät wie beispielsweise ein Gateway 20 in einem Fahrzeug 18 angeordnet. Das Steuergerät bzw. das Gateway 20 umfasst Prozessor(en), Speicher, Arbeitsspeicher (beispielsweise als Bestandteil eines Host-Systems 29) und Schnittstellen für eine Kommunikation über ein Kommunikationsnetzwerk. Das Gateway 20 arbeitet beispielsweise Instruktionen zur Datenverbindung ab. Durch die Kommunikation entstehen Daten 211 in Form von Datenpaketen. Auch bei dem Betrieb des Hosts 29 entstehen Daten 211, beispielsweise Systemdaten. In einem Normalzustand werden Sollwerte beispielsweise bezüglich Empfänger-und Zieladresse, Einhaltung von korrektem Programmablauf (beispielsweise für Host 29), Zeitstempel, Auftretenshäufigkeit oder Frequenz von Daten 211 bestimmter Datenpakete eingehalten. Die Daten 211 der Datenpakete werden zur Erfüllung der spezifischen Aufgaben zwischen weiteren nicht näher gezeigten Steuergeräten oder Komponenten im Fahrzeug 18 ausgetauscht. Das Gateway 20 dient der Kopplung mehrerer Kommunikationssysteme bzw. Schnittstellen wie beispielsweise ein CAN-Bus 25, eine Ethernet-Verbindung 27 sowie eine Datenverbindung zu dem Host-System 29, welches Bestandteil des Steuergeräts 20 bzw. des Gateways ist. Jedoch auch andere Kommunikationssysteme (beispielsweise weitere drahtgebundene Bussysteme wie LIN, CAN-FD etc. bzw. drahtlose Netzwerke (beispielsweise WLAN oder Bluetooth) können durch das Gateway 20 miteinander zum Zwecke des Datenaustauschs gekoppelt werden. Generell dient eine Eindringungserkennung IDS bzw. Anomalieerkennung in einem Steuergerät dazu, sämtliche Daten 211 (durch Kommunikationssystem empfangene Daten 211 ebenso wie innerhalb des Steuergeräts 20 durch den Host 29 generierte Daten 211) auf entsprechende Anomalien zu überwachen. Im Ausführungsbeispiel wird der IDS-Funktionsmechanismus beispielhaft für das Gateway 20 beschrieben. Generell können jedoch die beschriebenen Funktionalitäten der Anomalieerkennung bzw. Eindringungserkennung IDS in jedem beliebigen Steuergerät oder beliebigen elektronischen Komponenten implementiert werden. Insbesondere ist die Verwendung nicht auf ein Fahrzeug 18 beschränkt. Vielmehr können beliebige Kommunikationskomponenten, beispielsweise Kommunikationsmodule im Internet (IOT Internet of Things) oder bei vernetzten Produktionssystemen mit den beschriebenen Funktionalitäten ausgestattet werden.
Eine Kommunikationskomponente wie Steuergerät bzw. das Gateway 20 umfasst zumindest eine Anomalieerkennung 22. Die Anomalieerkennung 22 erstreckt sich über zumindest eine nicht vertrauenswürdige Zone Z1 sowie über zumindest eine vertrauenswürdige Zone Z2. Insbesondere ein Kommunikationsadapter 32 ist sowohl in der vertrauenswürdigen Zone Z2 wie auch in der nicht vertrauenswürdigen Zone Z1 angesiedelt. Zumindest ein Sensor 24,26, 28 befindet sich in der vertrauenswürdigen Zone Z2. Auch der Ereignismanager 30 ist in der vertrauenswürdigen Zone angesiedelt.
Die über die Schnittstellen der jeweiligen Kommunikationssysteme 25, 27, 29 eingehenden Daten 211 werden jeweils über sogenannte Sensoren 24, 26, 28 zur Anomalieerkennung oder Eindringlingserkennung, kurz IDS Sensoren, geführt. So sind in dem Gateway 20 entsprechende Sensoren 24, 26, 28 angeordnet. Solche Sensoren 24, 26, 28 dienen der Erkennung, ob erhaltene Daten 211 eine Anomalie darstellt. Hierzu sind in den Sensoren 24, 26, 28 entsprechende Filteralgorithmen bzw. Regelsätze hinterlegt, die der Detektion und Klassifikation von Anomalien dienen. Wird eine Anomalie durch einen Sensor 24, 26, 28 ermittelt, wird das entsprechende Datenpaket der Daten 211 als Ereignis 220 (eines versuchten Eindringens) klassifiziert. Generell können die Sensoren 24, 26, 28 je nach Quelle 25, 27, 29 unterschiedliche Anomalien als Ereignisse 220 klassifizieren (Zuordnung des jeweiligen Ereignisses 220 zu bestimmten Ereignisarten 218) und erkennen. In Abhängigkeit von der jeweiligen Ereignisart 218 (unterschiedliche Arten von Anomalien in den Daten 211) stellen die Sensoren 24, 26, 28 bestimmte ereignisabhängige Metadaten 216 als zugehöriges Ereignis 220 zusammen. Außerdem können die ereignisabhängigen Metadaten 216 auch Daten oder Datenbestandteile der anomalen Daten 211 enthalten. Das so generierte Ereignis 220 wird an einen Ereignismanager 30 weitergeleitet. Die Sensoren 24, 26, 28 sind in der Regel ausgestaltet, dass bei einer nicht bestehenden Anomalie die zugehörigen Daten 211 eines Kommunikationssystems (beispielsweise Bussysteme 25, 27) an die Bestimmungsadresse weitergeleitet werden. Bei einer erkannten Anomalie könnten die Sensoren 24, 26, 28 so ausgestaltet sein, dass die zugehörigen Daten 211 eines Kommunikationssystems (beispielsweise Bussystem 25, 27) nicht an die Bestimmungsadresse weitergeleitet werden. Alternativ können die Sensoren 24, 26, 28 auch dafür verwendet werden, Ereignisse 220 zu reduzieren (reduziertes Ereignis bzw. vorreduziertes Ereignis 221). Durch diese Reduzierung könnte der Ereignismanager 30 entlastet werden, beispielsweise indem lediglich ein kleiner Teil von Nutzdaten von Anomalien enthaltenden Daten 211 bzw. Datenpaketen weitergeleitet werden. Dies ist insbesondere bei großen Datenmengen wie sie bei Ethernet-Verbindungen auftreten von Vorteil.
So dienen beispielsweise IDS CAN Sensoren 24 der Anomalieerkennung bei einem CAN-Bus 25, IDS Ethernet Sensoren 26 bei einem Ethernet-System 27 sowie IDS Host Sensoren 28 bei einem Host-System 29. Je nach unterschiedlichen Kommunikationswegen und Kommunikationsprotokollen können auch weitere IDS Sensoren vorgesehen werden, die in der Lage sind, Anomalien bei den jeweiligen Quellen bzw. Anomaliequellen zu detektieren und gegebenenfalls zu klassifizieren.
Die IDS CAN Sensoren 24 detektieren relevante Ereignisse 220 von zugehörigen Ereignisarten 218 wie beispielsweise ungültige CAN-ID's, ungültige Nachrichtenhäufigkeiten, ungültige Nachrichtenlängen oder ähnliches. Die IDS Ethernet Sensoren 26 detektieren für das Ethernet 27 relevante Ereignisse 220 von zugehörigen Ereignisarten 218 wie beispielsweise ungültige Adressen bzw. MAC Adressen, ungültige Nachrichtenhäufigkeiten, ungültige Nachrichtenlängen oder ähnliches. Die IDS Host Sensoren 28 detektieren für das Host System 29 relevante Ereignisse 220 von zugehörigen Ereignisarten 218 wie beispielsweise ungültige Codeausführungen, Korrumpierung von Programmen, Stapelzählern oder Ähnliches. Zumindest einen Sensor 24, 26, 28 ist in der vertrauenswürdigen Zone Z2 angeordnet.
Nachfolgende weitere Anomalien können als Ereignisse 220 berücksichtigt werden für weitere Ereignisarten 218. Beispielsweise sind dies Ereignisse 220 bzw. Ereignisarten 218, die der Firewall zuzuordnen sind wie beispielsweise Verlust des Frames aufgrund eines vollen Pufferspeichers, Filterverletzung (stateless/stateful), Begrenzung der Übertragungsrate aktiv bzw. inaktiv, Überwachungsmodus aktiviert bzw. deaktiviert, Kontextwechsel. Auch weitere Anomalien, die das Host System 29 betrifft, können als Ereignisse 220 berücksichtigt werden mit zugehörigen Ereignisarten 218 wie beispielsweise CPU Belastung zu hoch, Speicherzugriffsverletzung, Fehler bei der Code-Ausführung, ECU Rücksetzung detektiert, Log-Einträge im nichtflüchtigen Speicher korrumpiert, Overflow des Logging-Speichers, Zurückweisung eines Ereignisses, MAC Adressport Änderung etc.
Der Ereignismanager 30 dient der Weiterverarbeitung der eingehenden Ereignisse 220 bzw. der in dem jeweiligen Ereignis 220 enthaltenen ereignisabhängigen Metadaten 215. Insbesondere dient der Ereignismanager 30 der Aggregierung, Formatierung bzw. Aufbereitung der Ereignisse 220 und/oder der Priorisierung und/oder Reduzierung/Selektierung der Ereignisse 220 und/oder dem Abspeichern bzw. Persistieren bzw. dauerhaften Abspeichern der ausgewählten und/oder reduzierten Ereignisse 220, 221. Insbesondere entscheidet der Ereignismanager 30, welche eingehenden Ereignisse 220 weiterverarbeitet werden sollen. Die von den eingehenden Ereignissen 220 ausgewählten werden als selektierte Ereignisse 226 bezeichnet. Die entsprechende Auswahl soll möglichst nicht deterministisch erfolgen. Weiterhin versieht der Ereignismanager 30 die eingehenden Ereignisse 220 bzw. die selektierten Ereignisse 226 besonders bevorzugt noch mit weiteren generischen Metadaten 217. Dadurch können die von unterschiedlichen Sensoren 24, 26, 28 übermittelten Ereignisse 220 übergeordnet betrachtet werden, indem beispielsweise die Anzahl der aufgetretenen Ereignisse, der zugehörige Zeitstempel bzw. Zeitsignal 224 oder Ähnliches im Rahmen der generischen Metadaten 217 hinzugefügt werden. Weiterhin wird sichergestellt, dass selbst bei einem sogenannten Ereignis-Burst hinreichend viele und aussagekräftige Ereignisse 220 als selektierte Ereignisse 226 gespeichert werden können. Der Ereignismanager 30 ist in der vertrauenswürdigen Zone Z2 angeordnet.
Der Ereignismanager 30 tauscht Signale aus mit einem Kommunikationsadapter 32 der Eindringungs- bzw. Anomalieerkennung. Der Kommunikationsadapter 32 fungiert als Kommunikationsmittel zum Datenaustausch zwischen dem Ereignismanager 30 und weiteren Komponenten 34, 36 außerhalb der Anomalieerkennung 22 des Steuergeräts bzw. Gateways 20. Konkret dient der Kommunikationsadapter 32 als Schnittstelle zum Datenaustausch zwischen dem Ereignismanager 30 und weiteren IDS Instanzen 34 (vorzugsweise innerhalb des Fahrzeugs 18) und/oder einem Backend 36 (vorzugsweise außerhalb des Fahrzeugs 18). Die weitere IDS Instanz 34 kann lediglich optional vorgesehen werden. Der Kommunikationsadapter 32 ist in beiden Zonen Z1, Z2 angeordnet.
Zur Erhöhung der Sicherheit könnte der Ereignismanager 30 eine zufallsbasierte, für einen Angreifer nicht determininistische und verschleierte Reduzierung und Priorisierung von Ereignissen 220, 221 vornehmen. So könnte zufallsbasiert, für den Angreifer nicht determininistisch und verschleiert ein nicht flüchtiges Speichern selektierter Ereignisse 226 vorgenommen werden. Die zufallsgesteuerte Auswahl könnte beispielsweise auf einer für ein bestimmtes Steuergerät individuellen Zufallszahl 273 basieren. Ebenfalls kann der Ereignismanager 30 eine zufallsbasierte Speicherung der Zählerstände 231 der Ereigniszähler 204 erfolgen. Der Ereignismanager 30 speichert auch zufallsabhängig neben den ereignisabhängigen Metadaten 216 die hinzugefügten generischen Metadaten 217 als selektierte Ereignisse 226 ab.
Der Kommunikationsadapter 32 könnte zur Erhöhung der Sicherheit eine zufallsbasierte, für einen Angreifer nicht determininistisches und verschleiertes Hochladen bzw. Versenden eines Ereignisberichts 242 zu anderen IDS Instanzen 34 vornehmen. Das zufallsgesteuerte Hochladen könnte beispielsweise auf einer für ein bestimmtes Steuergerät (bzw. Gateway 20) individuellen Zufallszahl 273 basieren. So könnten bestimmte Ereignisse 220 im Rahmen des Ereignisberichts 242 zyklisch und verschlüsselt übertragen werden. Doch auch wenn keine neuen Ereignisse 220 vorliegen, könnten sogenannte Dummy-Ereignisse im Format eines Ereignisberichts 242 zyklisch und verschlüsselt übertragen werden. Dies dient der Abhörsicherheit bzw. zufallsbasierten Verschleierung des Datenaustauschs zwischen dem Kommunikationsadapter 32 und weiteren IDS Instanzen 34 bzw. dem Backend 36.
Die bearbeiteten reduzierten Ereignisse 221 werden von dem Sensor 26 an den Ereignismanager 30 weitergeleitet. Damit erhält der Ereignismanager 30 von diesem Sensor 26 nicht komplette Datenströme dieser Net-Frames, sondern lediglich reduzierte Ereignisse 221 mit reduzierter Datengröße. Die Reduzierung der weiterzuleitenden Ereignisse 221 wurde anhand eines IDS Ethernet Sensors 26 beispielhaft beschrieben. Prinzipiell könnte dies jedoch auch in anderen IDS Sensoren 24, 26, 28 realisiert sein. Aufgrund des hohen Informationsgehalts in einem Ethernet-Frame mit hohen Übertragungsraten würden jedoch gerade solche Ereignisse 220 schnell zu einem Überlauf des Pufferspeichers 206 führen. Bei IDS CAN Sensoren 24 treten entsprechende Daten 211 ohnehin mit niedrigerer Datenrate und geringerem Datenvolumen auf, sodass hier tendenziell komplette Ereignisse 220 weitergegeben und abgespeichert werden können.
Beispielhaft wird in Verbindung mit 2 gezeigt, wie Daten 211 vom Sensor 24, 26, 28 im Falle einer erkannten Anomalie weiterverarbeitet und an den Ereignismanager 30 geschickt werden, bis dieser einen Ereignisbericht 242 über den Kommunikationsadapter 32 verschickt.
Beispielhaft ist in 2a ein Datenpaket von Daten 211 gezeigt wie sie beispielsweise bei einem Netzwerk-Frame (beispielsweise CAN, Ethernet) auftreten könnten. Die Daten 211 weisen einen Header 214 auf, der beispielsweise die Quelladresse und die Zieladresse (beispielsweise MACa, MACb) umfasst. Außerdem umfassen die Daten 211 Nutzdaten 213.
Wie nachfolgend näher ausgeführt wird könnte der Sensor 24, 26, 28 optional einen Nutzdatenbereich 219 zufällig auswählen, der an den Ereignismanager 30 weitergeleitet wird. Der Sensor 24, 26, 28 hat ermittelt, dass es sich um eine Anomalie gemäß einer bestimmten Ereignisart 218 (event-ID bzw. Ereignis-ID, ID) handelt. Daher generiert der Sensor 24, 26, 28 ereignisabhängige Metadaten 216 wie in 2b dargestellt. Je nach Ereignisart 218 (bzw. ID) können bei den ereignisabhängigen Metadaten 216 unterschiedliche Informationen der Anomalie hinterlegt sein. Im Ausführungsbeispiel werden als ereignisabhängige Metadaten 216 unter anderem Quell- und Zieladresse (MACa, MACb), die Ereignisart 218 und der ausgewählte Nutzdatenbereich 219 verwendet.
Alternativ könnten auch die ereignisabhängigen Nutzdaten 213 komplett im Rahmen des Ereignisses 220 an den Ereignismanager 30 weitergeleitet werden.
Alternativ könnte auch das Ereignis 220 keine ereignisabhängigen Nutzdaten 213 umfassen, beispielsweise wenn als Quelle der Host 29 verwendet ist. Hierbei kann es sich um Ereignisarten 218 wie beispielsweise Informationen zum Verlust des Datenrahmens aufgrund eines vollen Puffers, Aktivierung bzw. Deaktivierung des Beobachtungsmodus, Belastung der CPU ist zu hoch, Einträge des nichtflüchtigen Speichers 208 sind korrumpiert, Overflow des Logging-Puffers, Ereignisreduzierung aktiv etc oder ähnliches handeln.
Weiterhin können für unterschiedliche Ereignisarten 218 weitere ereignisabhängige Informationen im Rahmen der ereignisabhängigen Metadaten 216 Bestandteil des Ereignisses 220 sein. Bei der Ereignisart 218 „Wechsel des Kontexts“ könnten die ereignisabhängigen Metadaten 216 beispielsweise den Kontext umfassen, beispielsweise in der Größe von 32 Bit. Bei der Ereignisart 218 „Speicherzugriffsverletzung“ oder „Verletzung bei der Ausführung eines Codes“ könnten die ereignisabhängigen Metadaten 216 beispielsweise die zugegriffene Adresse (beispielsweise 32 Bit), den Programmzähler (beispielsweise 32 Bit), die Task-ID (beispielsweise 8 Bit) umfassen. Bei der Ereignisart 218 „detektierter Reset eines Steuergeräts“ könnten die ereignisabhängigen Metadaten 216 beispielsweise den Grund des Resets (beispielsweise 8 Bit), beispielsweise POR (Point of Return), Software Reset, Ausnahmen etc. umfassen.
Nachfolgende Ethernet-bezogene Ereignisse 220 könnten als ereignisabhängige Metadaten 216 geloggt werden wie beispielsweise statische/zustandsabhängige Filterverletzungen (bestimmte Regel-ID bzw. ID für bestimmte Ereignisart 218 (beispielsweise 16 Bit), eine ID der Filter-Regel, die das Ereignis 220 hervorrief falls verfügbar, physikalische Portadresse, physikalische Port-ID, über die der Frame erhalten wurde, Quelladresse (z.B. MAC-Adresse, beispielsweise 48 Bit), Zieladresse (z.B. MAC-Adresse, beispielsweise 48 Bit), eventuell IP-Adresse von Quelle oder Ziel, Bestimmung des UDP/TCP-Ports (beispielsweise 16 Bit) falls im Frame vorhanden, optional). Alternativ könnten statische/zustandsabhängige Filterverletzungen mitprotokolliert werden wie beispielsweise Regel-ID, physikalischer Port, Frame (Anzahl der Bytes) bestimmte Anzahl von Bytes des empfangenen Frames werden gespeichert, ausgewählter Nutzdatenbereich 219 (bestimmte Anzahl von Bytes) ausgewählter Nutzdatenbereich 219 der Bytes des Original-Frames, Nutzdatenbereich 219 - Index (beispielsweise 16 Bit), Startbyte des ausgewählten Nutzdatenbereichs 219 im Original-Frame. Auch weitere Ethernet-bezogene Ereignisse könnten in den an den Ereignismanager 30 übermittelten Ereignissen 220 enthalten sein wie beispielsweise für die Ereignisart 218 „Übertragungsrate begrenzt (aktiv/inaktiv)“ die Regel-ID mit zugehöriger ID der Filterregel, die das Ereignis 220 verursacht hat, für die Ereignisart 218 „Änderung des Kontexts“ der Kontext (beispielsweise 32 Bit), für die Ereignisart 218 „Adress-Hopping“ bzw. „MAC Hopping“ der alte Port (physikalische Port-ID, die der Adresse ursprünglich zugeordnet wurde), der neue Port (physikalische Port-ID, wo die Adresse kürzlich beobachtet wurde), die Adresse, vorzugsweise MAC-Adresse. Es können jedoch auch Ereignisarten 218 ohne Meta-Daten 216 auftreten wie beispielsweise „Verlust des Frames aufgrund vollen Puffers“ etc.
Die Weiterleitung von ereignisabhängigen Nutzdaten 213 hängt somit insbesondere von der Quelle der Daten 211 mit der zugehörigen Ereignisart 218 ab. Die Metadaten 216 werden als Ereignis 220 bzw. reduziertes Ereignis 221 (aufgrund der zufallsabhängigen Auswahl bzw. Reduzierung des zu übertragenden Nutzdatenbereichs 219 im Sensor 24, 26, 28) an den Ereignismanager 30 übertragen.
Sollte der Ereignismanager 30 dieses Ereignis 220, 221 zur Weiterverarbeitung auswählen (selektiertes Ereignis 226) wie nachfolgend näher erläutert, so werden zu den ereignisabhängigen Metadaten 216 noch generische Metadaten 217 hinzugefügt, sodass die in 2c gezeigten Metadaten 215 entstehen. Diese generischen Metadaten 217 werden in der Regel im Ereignismanager 30 generiert. Es handelt sich beispielsweise um Ausgangssignale der Ereigniszähler 204, also aktuelle Zählerstände 231, um das wievielte globale Ereignis 220 bzw. um das wievielte Ereignis einer bestimmten Ereignisart 218 es sich bei dem aktuellen Ereignis 220 handelt. Außerdem können die generischen Metadaten 217 beispielsweise ein Zeitsignal 224 umfassen, wann dieses Ereignis 220 aufgetreten ist. Außerdem könnten die Metadaten 217 umfassen, welche Länge 232 (Größe der Daten) die ereignisabhängigen Metadaten 216 bzw. die kompletten Metadaten 215 aufweisen. Dies ist für das spätere Speichermanagement des Pufferspeichers 206 von Vorteil.
Beispielhaft werden nachfolgende generische Metadaten 217 vorgeschlagen. Dies könnte beispielsweise eine Ereignisart 218 im Rahmen einer Ereignis-ID (beispielsweise 8 Bit) sein. Diese Ereignis-ID der Ereignisart 218 ist eindeutig und kann beispielsweise eine TLV- basierte Kodierung (TLV: Type-Length-Value Typ-Länge-Wert) umfassen. Die generischen Metadaten 217 umfassen die Länge 232, beispielsweise zwischen 8 und 16 Bit groß. Die Größe der Daten (Metadaten 215) folgt nach dem Längenfeld in Bytes, maximal 255 Bytes.
Wiederum könnte eine TLV-basierte Kodierung vorgesehen werden. Weiterhin enthalten ist das Zeitsignal 224, ein Zeitstempel (beispielsweise 64 Bits). Die Zeit 224 ist beispielsweise angegeben in der Form eines absoluten Zeitwerts, der seit einem Bezugszeitpunkt wie dem 1. Januar 1970 verstrichen ist (in Millisekunden) zur Angabe eines eindeutigen Zeitstempels. Weiterhin können die generischen Metadaten 217 Zählerstände 231 bzw. Ausgangswerte 231 der Ereignis-Typ-Zähler 204 (beispielsweise 32 Bit) und/oder den Zählerstand 231 des globalen (Ereignis)Zählers 204 (beispielsweise 32 Bit), eine Summe aller Zählerstände 231 der Ereigniszähler 204 für jede Ereignisart 218, umfassen.
Die ereignisabhängigen Metadaten 216 werden so übernommen, wie sie der jeweilige Sensor 24, 26, 28 gebildet hat. Dieses Ereignis 220 mit den entsprechenden sowohl vom Sensor 24, 26, 28 wie auch vom Ereignismanager 30 gebildeten Metadaten 215 wird in dem Pufferspeicher 206 des Ereignismanagers 30 abgelegt. In ähnlicher Art und Weise werden noch weitere - wie nachfolgend näher erläutert - vom Ereignismanager 30 selektierte bzw. reduzierte Ereignisse 226 (im Ausführungsbeispiel gemäß 2d exemplarisch als 215_1, 215-8, 215_190 bezeichnet) im Pufferspeicher 206 abgelegt.
Aus in dem Pufferspeicher 206 abgelegten selektierten Ereignissen 226 (im Ausführungsbeispiel gemäß 2d exemplarisch als 215_1, 215_8, 215_190 bezeichnet (Metadaten 215 Ereignis Nr. 1, Metadaten 215 Ereignis Nr. 8, Metadaten 215 Ereignis Nr. 190 als Beispiele für selektierte Ereignisse 226) wird nun ein Ereignisbericht 242 generiert. Dieser umfasst die in dem Pufferspeicher 206 abgelegten selektierten Ereignisse 226 (im Beispiel 215_1, 215_8, 215_190). Vorangestellt wird diesen selektierten Ereignissen 226 eine gegenüber jedem Ereignisbericht 242 veränderte Größe 254 (beispielsweise Zufallszahl, Zeit oder Zähler etc.). Außerdem umfasst der Ereignisbericht 242 eine Authentifizierungs-Information 256. Darüber kann die Authentifizierung zwischen Kommunikationsadapter 32 bzw. Ereignismanager 30 und der den Ereignisbericht 242 empfangenden Einheit (IDS Instanz 34, Backend 36 oder Ähnliches) erfolgen. Der Ereignisbericht 242 umfasst eine feste Länge 258. Um diese feste Länge 258 zu erreichen, werden die Daten 254, 215_1, 215_8, 215_190, 256 noch aufgefüllt durch sogenannte Fülldaten 255. Diese Fülldaten 255 beinhalten keine ereignisrelevanten Informationen. Vor einer Übertragung werden die gezeigten Daten des Ereignisberichts 242 mit einer Verschlüsselung 258 versehen wie in der 2d angedeutet. Der so durch die Verschlüsselung 258 verschlüsselte Ereignisbericht 242 wird vom Kommunikationsadapter 32 verschickt, und von der weiteren IDS Instanz 34 oder Backend 36 entschlüsselt und authentifiziert wie beschrieben.
3 zeigt schematisch einen Rechenkern 102a eines Switches SWT 48 gemäß weiteren bevorzugten Ausführungsformen, der ein Betriebssystem BS und/oder Supervisor SV umfasst und der selbst zwei Zonen Z1, Z2 zugeordnet ist.
Die Anomalieerkennung 22 basiert auf einem 2-Zonen-Konzept, bei dem bestimmte Anwendungen einer nicht vertrauenswürdigen Zone Z1 und einer vertrauenswürdigen Zone Z2 zugeordnet werden. Die Anomalieerkennung 22 kann insbesondere z.B. für ein eingebettetes System und/oder ein Steuergerät, insbesondere für ein Fahrzeug, insbesondere Kraftfahrzeug, verwendet werden.
Bevorzugte Ausführungsformen beziehen sich auf ein Verfahren zum Betreiben einer der Anomalieerkennung 22 zugeordneten Recheneinrichtung, das die folgenden Schritte aufweist: Zuordnen von einem oder mehreren durch die Recheneinrichtung ausführbaren Anwendungsprogrammen AP1, AP2 zu einer von wenigstens zwei Zonen Z1, Z2 wobei die Zonen Z1, Z2 Ressourcen der Recheneinrichtung charakterisieren, die für eine Ausführung eines betreffenden Anwendungsprogramms AP1, AP2 nutzbar sind, optional Ausführen wenigstens eines der Anwendungsprogramme AP1, AP2 in Abhängigkeit der ihm zugeordneten Zone Z1, Z2, wobei das Verfahren weiter alternativ aufweist: Verwenden eines Supervisors SV zum Zuweisen von Rechenzeitressourcen für unterschiedliche Anwendungsprogramme und/oder Instanzen von Anwendungsprogrammen, wobei der Supervisor SV und/oder eine dem Supervisor SV entsprechende Funktionalität zumindest teilweise mittels einer Supervisor-Instanz SVI realisiert ist, die von den wenigstens zwei Zonen Z1, Z2 unabhängig ist. Bei weiteren bevorzugten Ausführungsformen können dadurch z.B. Vertrauensgrenzen (englisch: Trust Boundaries) definiert werden, z.B. zwischen vertrauenswürdigen und nicht-vertrauenswürdigen Instanzen/ Einheiten/Domänen. Auf diese Weise können beispielsweise erste Anwendungsprogramme für die Recheneinrichtung einer nicht vertrauenswürdigen ersten Zone Z1 (englisch: non-trustworthy zone, NT) und zweite Anwendungsprogramme für die Recheneinrichtung einer vertrauenswürdigen zweiten Zone Z2 (englisch: trustworthy zone, (T)Z) zugeordnet werden. Bei weiteren bevorzugten Ausführungsformen kann die Supervisor-Instanz SVI z.B. durch einen (dedizierten) Rechenkern und/oder ein Hardware-Sicherheitsmodul HSM und/oder ein Trusted-Platform-Modul TPM gebildet sein bzw. kann die Funktionalität der Supervisor-Instanz SVI mittels wenigstens einem dieser Elemente realisiert werden.
Bei weiteren bevorzugten Ausführungsformen ist vorgesehen, dass das Verfahren zum Betreiben der Recheneinrichtung weiter aufweist: Steuern, insbesondere Begrenzen, von wenigstens einem der folgenden Elemente: a) Leserechte auf der Recheneinrichtung zugeordneten Speicher, b) Schreibrechte auf der Recheneinrichtung zugeordneten Speicher, c) Ausführungsrechte („Exekutionsrechte“) auf der Recheneinrichtung zugeordneten Speicher, in Abhängigkeit wenigstens einer Zone Z1, Z2. Dadurch ist vorteilhaft sichergestellt, dass nur solche Anwendungsprogramme AP Zugriff auf den bzw. die genannten Speicher erhalten, die einer entsprechenden Zone Z1, Z2 zugeordnet sind. Beispielsweise kann damit bei weiteren bevorzugten Ausführungsformen verhindert werden, dass ein Anwendungsprogramm einer nicht vertrauenswürdigen Zone Z1 auf den bzw. die Speicher zugreift (insbesondere z.B. Zugriff auf den der vertrauenswürdigen Zone Z2 zugeordneten Speicherbereich durch die nicht- vertrauenswürdigen Zone Z1), was ggf. ein Risiko bezüglich einer möglichen Manipulation des Speicherinhalts durch das Anwendungsprogramm der nicht vertrauenswürdigen Zone Z1 darstellt.
Bei weiteren bevorzugten Ausführungsformen kann die Recheneinrichtung z.B. das folgende Szenario ausführen: Soll ein erstes Anwendungsprogramm AP1 Daten aus einer, z.B. nicht-vertrauenswürdigen ersten, Zone Z1 empfangen - bspw. Remote Service Requests („Dienstanfragen aus der Ferne“) aus dem Internet - und diese Daten entsprechend innerhalb der vertrauenswürdigen Zone Z2 prozessieren oder weiterleiten - bspw. zur Ausführung des entsprechenden Diensts („Remote Service“) - so erfolgt innerhalb der ersten Zone Z1 durch den Z1-Proxy AP1_I1 des Anwendungsprogramms AP1 das Empfangen der Daten, wobei der korrespondierende Z2-Proxy_12 z.B. folgende Schritte ausführt: eine Daten-Verifikation der von dem Z2-Proxy_l2, insbesondere defaultmäßig, nichtvertrauenswürdig eingestuften Daten sowie - im Falle einer erfolgreichen Daten-Verifikation - die Prozessierung oder Weiterleitung der nun (nach Daten-Verifikation) als vertrauenswürdig eingestuften Daten innerhalb der zweiten Zone Z2. Bei weiteren bevorzugten Ausführungsformen ist vorgesehen, dass das Verfahren weiter aufweis: Austauschen von ersten Daten zwischen verschiedenen Zonen über einen Pufferspeicher, insbesondere Arbeitsspeicher, wobei insbesondere das Austauschen der ersten Daten zwischen der ersten Zone Z1 und der zweiten Zone Z2 folgende Schritte aufweist: Kopieren der ersten Daten in einen der ersten Zone zugeordneten ersten Pufferspeicherbereich, Überprüfen der kopierten ersten Daten, und, insbesondere in Abhängigkeit der Überprüfung, Kopieren der ersten Daten aus dem der ersten Zone Z1 zugeordneten ersten Pufferspeicherbereich in einen der zweiten Zone Z2 zugeordneten zweiten Pufferspeicherbereich. Diese kurz skizzierten Funktionalitäten des 2-Zonen-Konzepts werden nun für die Anomalieerkennung 22 wie nachfolgend beschrieben implementiert.
Der Rechenkern 102a gemäß 3 kann z.B. für einen Netzwerkswitch verwendet werden, z.B. um Ethernet-Datenpakete zu senden und/oder zu empfangen. Entsprechende Instanzen von Anwendungsprogrammen AP sind mit den Bezugszeichen I1 (Empfangen von Ethernetpaketen, Ausführung in der Zone Z1), I2 (Empfangen von Ethernetpaketen, Ausführung in der Zone Z2), I3 (Senden von Ethernetpaketen, Ausführung in der Zone Z1), I4 (Senden von Ethernetpaketen, Ausführung in der Zone Z2) gekennzeichnet. Ein weiteres Anwendungsprogramm AP5, das z.B. Managementaufgaben für den Netzwerkswitch 48 ausführt, läuft nur in der als vertrauenswürdig definierten zweiten Zone Z2, nicht jedoch in der als nicht vertrauenswürdig definierten ersten Zone Z1. Weiterhin sind Ethernet Sensoren 38 in der als nicht vertrauenswürdig definierten ersten Zone Z1 angeordnet. Weitere Ethernet Sensoren 40 sind in der als vertrauenswürdig definierten zweiten Zone Z2 angeordnet. Außerdem sind Host Sensoren 42 in der als nicht vertrauenswürdig definierten ersten Zone Z1 angeordnet. Die Host Sensoren 43 der nicht vertrauenswürdigen Zone Z1 können optional vorgesehen sein. Host Sensoren 45 sind in der als vertrauenswürdig definierten zweiten Zone Z2 angeordnet. Je nach Anwendungsfall können also die Sensoren in der vertrauenswürdigen und/oder nicht vertrauenswürdigen Zone Z1, Z2 angeordnet werden.
Dem Rechenkern 102a ist ein RAM 1030 zugeordnet, das bei weiteren bevorzugten Ausführungsformen aufgeteilt sein kann. Optional ist eine Switching-Engine (z.B. Koppelnetz) vorgesehen und/oder ein TCAM (ternary contentadressable memory)-Modul bzw. ein ACL (Access-Control-List)-Modul. Bei der Switching-Engine SE bzw. dem TCAM/ACL-Modul handelt es sich um Hardwaremodule 42. In dem TCAM/ACL-Modul können entsprechende Filterregeln konfiguriert werden, sodass das TCAM/ACL-Modul als Sensor genutzt wird, um Anomalien zu detektieren. Die entsprechend konfigurierten Filterregeln in diesem Hardware-Modul 42 entsprechen denjenigen der beschriebenen Sensoren 24, 26, 28. Wird durch diese Filterregel eine Anomalie detektiert, kann ein Ereignis 220 generiert werden und/oder die Anomalie geblockt werden. Im Falle der Generierung eines Ereignisses 220 kann ein Interrupt durch das Hardware-Modul 42 ausgelöst werden, damit die Anomalie als Ereignis 220 softwareseitig geloggt werden kann. Gleiches gilt auch für CAN-Hardware-Transceiver auf einem Main-Controller, wo Filterregeln der Sensoren in Hardware konfiguriert werden können.
Weiterhin ist ein Interrupt 44 angedeutet, der beispielsweise softwaremäßig, hardwaremäßig wie beschrieben oder durch einen Timer ausgelöst werden kann. Die genannten Komponenten sind Bestandteil der Elektronikeinheit 48 bzw. des Switches. Außerhalb der Elektronikeinheit 48 bzw. Switch ist eine Recheneinheit 100b (Main Controller) vorgesehen, die über einen Kommunikationskanal 52 Daten austauscht mit der Elektronikeinheit 48 bzw. Switch. Weiterhin ist die Recheneinheit 100b in der Lage, mit anderen IDS Instanzen 34 zu kommunizieren. Die Kommunikation könnte von der Recheneinheit 100 b zu anderen IDS-Instanzen 34 erfolgen, beispielsweise über CAN oder von der Recheneinheit 100b über den Switch 48 zu anderen IDS-Instanzen 34. Die Elektronikeinheit 48 wiederum sendet Ethernet Ereignisse 220 von dem Switch SWT 48 an die Recheneinheit 100 b.
Die Inter-Zonen-Kommunikation von der nicht-vertrauenswürdigen Zone Z1 zu der vertrauenswürdigen Zone Z2 wird über die ETH Sensoren 40 der vertrauenswürdigen Zone Z2 und/oder über die durch Hardware-Filterregeln realisierten Sensoren 42 und/oder durch ETH Sensoren 40 der nicht vertrauenswürdigen Zone Z1 und/oder die Host-Sensoren 45 der vertrauenswürdigen Zone Z2 gesteuert.
Erfolgt die Inter-Zonen-Kommunikation bzw. die Zonen-Transition von Z1 nach Z2 auf dem Switch 48, so wird zwischen den beiden Zonen Z1 und Z2 lediglich das notwendige Minimum an Daten, die in der vertrauenswürdigen Zone Z2 benötigt werden, übertragen.
Deshalb erfolgt bereits in der nicht vertrauenswürdigen Zone Z1 eine Defragmentierung des Protokolls auf das notwendige Minimum, im Rahmen der Defragmentierung werden (zur Detektion von Anomalien) ebenfalls bereits Plausibilisierungen durchgeführt. Dies erfolgt über die Z1-Ethernet-Sensoren 38.
Nach dem Übertragen des notwendigen Minimums an Daten aus der nicht vertrauenswürdigen Zone Z1 an die vertrauenswürdige Zone Z2 wird das notwendige Minimum an Daten durch die Z2-Ethernet-Sensoren 40 plausibilisiert. Vor jedem Kontext-Wechsel/ dem Umschalten der Z1- und Z2-Task wird zusätzlich über die Host-Sensoren 43, 45 des BS bzw. SV überprüft, ob keine invalide Zonen-Transition und/oder Veränderung des Programmablaufs (bspw. durch Überprüfung der Rücksprungadresse auf dem Stack) stattgefunden hat.
Für den Fall, dass keine Anomalitäten detektiert wurden, gibt der ETH Sensor 40 der vertrauenswürdigen Zone Z2 die Nutzung der Daten in der vertrauenswürdigen Zone Z2 frei. Die Daten werden als vertrauenswürdige Daten eingestuft (Trusted Data). Für den Fall, dass Anomalien detektiert wurden, verwirft der ETH Sensor 40 die Daten und/oder erzeugt ein Ereignis 220. Außerdem kommuniziert der ETH Sensor 40 die Anomalitäten bzw. das zugehörige Ereignis 220 an die Recheneinheit 100b der vertrauenswürdigen Zone Z2 bzw. an den zugehörigen Ereignismanager 30 der vertrauenswürdigen Zone Z2. Die Sensorlogik des ETH Sensors 40 liegt in der vertrauenswürdigen Zone Z2, da die Ereignisse durch eine vertrauenswürdige Instanz ausgewertet werden müssen.
Kommunikationen innerhalb der Zonen Z1, Z2 bzw. von der vertrauenswürdigen Zone Z2 zur nicht vertrauenswürdigen Zone Z1 können erfolgen unter optionaler Verwendung von ETH Sensoren 38 für die nicht vertrauenswürdige Zone Z1. Weiterhin sind für die Inter-Zonen-Kommunikation von Z2 nach Z1 sowie die Intra-Zonen-Kommunikation die Sensoren optional, ggf. kann hierfür auch ein reduzierter Sensor-Satz zum Einsatz kommen (bspw. Default-Sensoren mit geringer Implikation auf Performance).
Der Switch 48 SWT leitet die Kommunikation der Recheneinheit 100b der nicht vertrauenswürdigen Zone Z1 über den Kommunikationsadapter 32 zu den weiteren IDS Instanzen 34 weiter. Der Kommunikationsadapter 32 befindet sich in der Recheneinheit 100b. Er fragt zyklisch den Ereignisbericht 242 vom Ereignismanager 30 an und kommunizert diesen an die weiteren IDS Instanzen 34. Wenn die Kommunikation über Ethernet an die weiteren IDS Instanzen 34 erfolgt (was die bevorzugte Variante ist), dann würde diese vom Kommunikationsadapter 32 des Haupt-Mikrocontrollers bzw. Recheneinheit 100b über den Switch 48 an die weiteren IDS-Instanzen 34 erfolgen.
4 zeigt schematisch ein vereinfachtes Blockdiagramm von Aspekten einer Recheneinrichtung 100b gemäß weiteren bevorzugten Ausführungsformen. Die Recheneinrichtung 100b weist vorliegend beispielhaft vier Rechenkerne K1, K2, K3, K4 auf, von denen der erste Rechenkern K1 zur Verarbeitung von Kommunikationsnachrichten, insbesondere CAN-Nachrichten, ausgebildet ist. Daher kann bei weiteren bevorzugten Ausführungsformen der erste Rechenkern K1 auch als „CAN-Core“ bezeichnet werden. Die weiteren Rechenkerne K2, K3 sind zur Ausführung von (gegebenenfalls unterschiedlichen Instanzen von) Anwendungsprogrammen vorgesehen und können bei weiteren bevorzugten Ausführungsformen daher auch als „Anwendungskerne“ bzw. englisch „Application Cores“ K2, K3 bezeichnet werden. Der vierte Rechenkern K4 ist zur Verarbeitung von Ethernet- Kommunikationsnachrichten ausgebildet und kann daher bei weiteren bevorzugten Ausführungsformen auch als Ethernet-Kern bzw. ETH-Kern bzw. englisch als „ETH Core“ K4 bezeichnet werden. Dem ersten Rechenkern K1 ist ein erster Supervisor SV1, insbesondere ein CAN lightweight Supervisor, zugeordnet, und dem vierten Rechenkern K4 ist ein zweiter Supervisor SV2, insbesondere ein ETH (Ethernet) lightweight Supervisor, zugeordnet.
Bei weiteren bevorzugten Ausführungsformen ist der erste Rechenkern K1 zwei Zonen Z1, Z2 zugeordnet. Bei weiteren bevorzugten Ausführungsformen ist auch der vierte Rechenkern K4 zwei Zonen Z1, Z2 zugeordnet.
Bei weiteren bevorzugten Ausführungsformen ist dem ersten Rechenkern K1 ein Anwendungsprogramm AP zum Senden und/oder Empfangen von CAN-Nachrichten zugeordnet, wobei das Bezugszeichen I1 eine erste Instanz dieses Anwendungsprogramms bezeichnet, welche erste Instanz I1 der ersten Zone Z1 zugeordnet und zum Empfangen von CAN-Nachrichten ausgebildet ist. Das Bezugszeichen I2 bezeichnet demgegenüber eine zweite Instanz dieses Anwendungsprogramms, welche der zweiten Zone Z2 zugeordnet und zum Empfangen von CAN-Nachrichten ausgebildet ist. Die Bezugszeichen 13, 14 bezeichnen entsprechende Instanzen zum Senden von CAN-Nachrichten, die jeweils ebenfalls einer der beiden Zonen Z1, Z2 zugeordnet sind. Weiterhin kann der Rechenkern K1 CAN Sensoren 60 umfassen, die in der vertrauenswürdigen Zone Z2 angeordnet sind. Optional können in dem Rechenkernen K1 auch CAN Sensoren 62 in der nicht vertrauenswürdigen Zone Z1 vorgesehen sein.
Bei weiteren bevorzugten Ausführungsformen können die Unterbrechungsanforderungen Rx, Timer, SW durch den ersten Rechenkern K1 bearbeitet werden, beispielsweise durch Ausführen einer entsprechenden Unterbrechungsroutine.
Bei weiteren bevorzugten Ausführungsformen ist dem vierten Rechenkern K4 ein Anwendungsprogramm zum Senden und/oder Empfangen von Ethernet-Nachrichten zugeordnet, wobei das Bezugszeichen I1 eine erste Instanz dieses Anwendungsprogramms bezeichnet, welche erste Instanz I1 der ersten Zone Z1 zugeordnet und zum Empfangen von Ethernet-Nachrichten ausgebildet ist. Das Bezugszeichen I2 bezeichnet demgegenüber eine zweite Instanz dieses Anwendungsprogramms, welche der zweiten Zone Z2 zugeordnet und zum Empfangen von Ethernet-Nachrichten ausgebildet ist. Die Bezugszeichen 13, 14 bezeichnen entsprechende Instanzen zum Senden von Ethernet-Nachrichten, die jeweils ebenfalls einer der beiden Zonen Z1, Z2 zugeordnet sind.
Bei weiteren bevorzugten Ausführungsformen wird eine Trennung der beiden Zonen Z1, Z2 innerhalb der Rechenkerne K1, K4 jeweils unter Verwendung mindestens einer Speicherschutzeinrichtung SSE1, SSE4 bewerkstelligt.
Wie vorstehend bereits erwähnt sind die beiden Anwendungskerne K2, K3 zur Ausführung von Anwendungsprogrammen ausgebildet, die bzw. deren einzelne Instanzen als Rechtecke innerhalb der betreffenden Anwendungskerne K2, K3 angedeutet sind. Bei weiteren bevorzugten Ausführungsformen ist der zweite Rechenkern K2 der zweiten Zone Z2 zugeordnet, und der dritte Rechenkern K3 ist der ersten Zone Z1 zugeordnet. In dem Rechenkern K2 sind beispielhaft DPI Sensoren 64 (Deep Package Inspection für eine tiefergehende Payload-Analyse), Ereignismanager 30, Kommunikationsadapter 32, Proxies 70, BSW Stack 72 (BSW: Basis Software), V-CAN 74 (virtueller CAN) sowie V-ETH 76 (virtueller Ethernet) vorgesehen. In dem Rechenkernen K3 sind beispielhaft DPI Sensoren 84, Kommunikationsadapter 32, Proxies 90, BSW Stack 92, V-CAN 94 sowie V-ETH 96 vorgesehen. Wie bereits beschrieben befindet sich der Kommunikationsadapter 32 sowohl in der vertrauenswürdigen Zone Z2 wie in der nicht vertrauenswürdigen Zone Z1.
Bei weiteren bevorzugten Ausführungsformen weist die Recheneinrichtung 100b einen flüchtigen Speicher, insbesondere einen Arbeitsspeicher (RAM) 1030b auf, der beispielsweise vergleichbar zu der Darstellung gemäß 4, in unterschiedliche Bereiche aufgeteilt ist, welche jeweils unterschiedlichen Rechenkernen K1, K2, K3, K4 bzw. deren Zonen Z1, Z2 zugeordnet sind.
Beispielsweise ist ein erster Bereich B1 des Arbeitsspeichers 1030b der Recheneinrichtung 100b gemäß 13 dem ersten Rechenkern K1 zugeordnet, wobei ein erster Teilbereich B1_1 der ersten Zone Z1 und ein zweiter Teilbereich B1_2 der zweiten Zone Z2 zugeordnet ist. Der erste Teilbereich B1_1 ist wiederum unterteilt in einen vertrauenswürdigen Bereich und in einen nicht vertrauenswürdigen Bereich, getrennt durch eine Speicherschutzeinrichtung SSE. Der zweite Teilbereich B 1_2 ist wiederum unterteilt in zumindest einen vertrauenswürdigen Bereich und in einen nicht vertrauenswürdigen Bereich, wiederum getrennt durch eine Speicherschutzeinrichtung SSE. Eine vergleichbare Aufteilung in entsprechende Bereiche bzw. Teilbereiche B4, B4_1, B4_2 ist bei weiteren bevorzugten Ausführungsformen auch für den vierten Rechenkern K4 möglich. Der erste Teilbereich B4_1 ist wiederum unterteilt in einen vertrauenswürdigen Bereich Tb1b und in einen nicht vertrauenswürdigen Bereich Tb1a, getrennt durch eine Speicherschutzeinrichtung SSE. Der zweite Teilbereich B4_2 ist wiederum unterteilt in zumindest einen vertrauenswürdigen Bereich Tb2a und in einen nicht vertrauenswürdigen Bereich Tb2b, wiederum getrennt durch eine Speicherschutzeinrichtung SSE.
Weitere Bereiche B2, B3 des Arbeitsspeichers 1030b sind bei weiteren bevorzugten Ausführungsformen beispielsweise den Anwendungskernen K2, K3 zuordenbar. Bei weiteren bevorzugten Ausführungsformen ist beispielsweise der Bereich B2 weiter aufteilbar in einen vertrauenswürdigen Bereich T und in einen nicht-vertrauenswürdigen Bereich NT. Vergleichbares kann bei weiteren bevorzugten Ausführungsformen auch für den dritten Anwendungskern K3 gelten.
Bei weiteren bevorzugten Ausführungsformen können ein oder mehrere weitere Speicherschutzeinrichtungen, die kollektiv mit dem Bezugszeichen SSE' bezeichnet sind, vorgesehen sein, um eine jeweilige Trennung gemäß bevorzugten Ausführungsformen hinsichtlich beispielsweise Leserechten und/oder Schreibrechte und/oder Ausführungsrechte zu realisieren.
Bei weiteren bevorzugten Ausführungsformen kann die Recheneinrichtung 100b beispielsweise die Funktionalität eines Gateway bereitstellen, also eines Netz-Kopplungselements, das beispielsweise einen CAN-Bus (vgl. den CAN Core K1) mit einem Ethernet-Netzwerk (vgl. den ETH Core K4) koppeln kann. Bei weiteren bevorzugten Ausführungsformen kann beispielsweise der erste Rechenkern K1 die Funktion einer sogenannten highspeed routing engine für CAN-Nachrichten übernehmen, und/oder der vierte Rechenkern K4 die Funktion einer sogenannten highspeed engine für Ethernet-Nachrichten.
Der Switch SWT 48, insbesondere ein Ethernet-Switch, übermittelt Ethernet-Ereignisse an den Rechenkern K4, der für das Handling der Ethernet-Kommunikation zuständig ist. Außerdem kommuniziert der Rechenkern K4 zu anderen IDS Instanzen 32.
Bei einer Kommunikation zwischen den Zonen, nämlich von der nicht vertrauenswürdigen Zone Z1 zu der vertrauenswürdigen Zone Z2, können die Daten von dem Proxy 90 der nicht vertrauenswürdigen Zone Z1 zu einem isolierten Pufferspeicher im nicht vertrauenswürdigen Bereich der Zone Z1 geschoben werden. Der der vertrauenswürdigen Zone Z2 zugeordnete Sensor 60 validiert diese Daten vor der Benutzung in der vertrauenswürdigen Zone Z2. Sofern keine Anomalien detektiert werden, gibt der Sensor 60 der vertrauenswürdigen Zone Z2 die Nutzung dieser Daten für die vertrauenswürdige Zone Z2 frei (Trusted Data). Sofern Anomalien bzw. unerwartete Ereignisse detektiert werden, verwirft der Sensor 60, der der vertrauenswürdigen Zone Z2 zugeordnet ist, die Daten. Außerdem kommuniziert der Sensor 60, der der vertrauenswürdigen Zone Z2 zugeordnet ist, die detektierten Anomalien als Ereignis 220 an den Ereignismanager der vertrauenswürdigen Zone Z2. Die Logik des Sensors 60 ist in der vertrauenswürdigen Zone Z2 angeordnet, weil die entsprechenden Ereignisse durch eine vertrauenswürdige Instanz evaluiert werden müssen. Weiterhin kann eine Kommunikation zwischen vertrauenswürdiger Zone Z2 und nicht vertrauenswürdiger Zone Z1 stattfinden. Außerdem kann eine Kommunikation von der vertrauenswürdigen Zone Z2 zu der nicht vertrauenswürdigen Zone Z1 ohne weiteres erfolgen. Weitere Sensoren 62 können optional vorgesehen werden.
Eine Kommunikation von der nicht vertrauenswürdigen Zone Z1 in die vertrauenswürdige Zone Z2 kann - wie bereits ausgeführt - auch durch Sensoren in der nicht vertrauenswürdigen Zone Z1 und der vertrauenswürdigen Zone Z2 überwacht werden. Daten, die nach der Defragmentierung nicht mehr vorhanden bzw. in der vertrauenswürdigen Zone Z2 nicht benötigt werden, werden durch in der nicht vertrauenswürdigen Zone Z1 angeordneten Sensoren 38, 62 überwacht. Die in der vertrauenswürdigen Zone Z2 angeordneten Sensoren 40, 60 überwachen dann die Daten, die nach der Defragmentierung (das notwendige Minimum an Daten) von der nicht vertrauenswürdigen Zone Z1 in die vertrauenswürdige Zone Z2 übertragen wird. Wird bereits durch die Sensoren 38, 62 der nicht vertrauenswürdigen Zone Z1 etwas detektiert, muss ebenfalls eine Kommunikation von den in der nicht vertrauenswürdigen Zone Z1 angeordneten Sensoren 38, 62 and den in der vertrauenswürdigen Zone Z2 angeordneten Ereignismanager 30 beispielsweise im Rahmen generierte Ereignisse 220 möglich sein.
Der Ereignismanager 30 der vertrauenswürdigen Zone Z2 aggregiert, reduziert oder priorisiert, formatiert oder persistiert eingehende Ereignisse 220. Der Ereignismanager 66 ist in der vertrauenswürdigen Zone Z2 angeordnet, da die Ereignisse durch eine Vertrauensinstanz (Trusted Instanz) verarbeitet, priorisiert und gespeichert werden müssen.
Der Kommunikationsadapter 32 ist zum Teil in der vertrauenswürdigen Zone Z2 angeordnet. Der Kommunikationsadapter 32 steuert die Kommunikation mit dem Ereignismanager 30, der ebenfalls in der vertrauenswürdigen Zone Z2 angeordnet ist. Außerdem übernimmt der Kommunikationsadapter 32 die Kommunikation zu einem HSM (Hardware Security Modul, das der Authntifizierung und/oder der Verschlüsselung dienen kann), um einen sicheren, authentifizierten und vertraulichen Kanal zu der übergeordneten IDS Instanz 34 sicherzustellen. Der Kommunikationsadapter 32 ist zum Teil in der vertrauenswürdigen Zone Z2 angeordnet, weil er ebenfalls mit vertrauenswürdigen Instanzen wie beispielsweise dem Ereignismanager 30 der vertrauenswürdigen Zone Z2 oder dem HSM kommunizieren muss.
Der Kommunikationsadapter 32 soll die Kommunikation zu anderen IDS Instanzen 34 wie beispielsweise Infotainment über den Switch SWT 48 übernehmen. Da er mit nicht vertrauenswürdigen Instanzen (Infotainment, CCU) kommuniziert, ist er teilweise in der nicht vertrauenswürdigen Zone Z1 angeordnet.
Beispielhaft wird ein Kommunikationsablauf beschieden, in dem der Ereignisbericht 242 zyklisch an die übergeordnete Instanz 34 gesendet wird. Hierzu frägt der Kommunikationsadapter 32 aus der vertrauenswürdigen Zone Z2 bei dem Ereignismanager 30 in der vertrauenswürdigen Zone Z2 an, in dem Pufferspeicher 206 selektierte Ereignisse 226 wie in Verbindung mit 2 beispielhaft beschrieben zur Verfügung zu stellen. In dem Ereignisbericht 242 sind bestimmte besonders vertrauenswürdige Informationen hinsichtlich Verschlüsselung und/oder Authentifizierung, insbesondere die veränderliche Größe 254 und/oder die Authentifizierungs-Information 256 und/oder die Verschlüsselung 258 enthalten. Diese Größen können von dem Sicherheitsmodul 73, welches oben bereits als HSM (Hardware Security Modul) beschrieben wurde, bereitgestellt werden. Das Sicherheitsmodul 73, beispielhaft im sogenannten BSW Stack 72 untergebracht, liefert beispielsweise eine entsprechende Zufallszahl 273 bzw. Abschnitt einer solchen Zufallszahl als veränderliche Größe 254. Der Ereignismanager 30 und/oder der Kommunikationsadapter 32 der vertrauenswürdigen Zone 22 übernimmt diese veränderliche Größe 254 im Rahmen des Ereignisberichts 242. Der Ereignisbericht 242 gelangt im Klartext wieder an das Sicherheitsmodul 73, welches die Verschlüsselung durch den Schlüssel 258 vornimmt und dem Kommunikationsadapter 32 der vertrauenswürdigen Zone Z2 zur Verfügung stellt. Der so verschlüsselte Ereignisbericht 242 gelangt nun über den Kommunikationsadapter 32 in den nicht mehr vertrauenswürdigen Bereich Z1, also an den Kern K3. Entsprechend wird der Ereignisbericht 242 in den Puffer der Zone B3 geschrieben. Beispielhaft könnte der Ereignisbericht 242 wie bereits ausgeführt über den Ethernet-Core K4 an die übergeordnete Instanz 32 kommuniziert werden wie der entsprechende Pfeil angedeutet. Hierzu wird der Ereignisbericht 242 aus dem Speicher im Bereich B3 an den Speicherbereich B4_1 transferiert, ist also nun im Ethernet-Core K4. Die weitere Kommunikation erfolgt von K4 über den Sendevorgang I3 beispielsweise über den Ethernet-Switch 48 etc. an die über Ethernet angebundene übergeordnete Instanz 32.
Der nachfolgende Kommunikationsablauf beschreibt den Empfang eines Bestätigungssignals 408, 416, das von der übergeordneten Instanz 34 generiert wurde (wie nachfolgend in Verbindung mit den 5-10 näher beschrieben). Das entsprechende Bestätigungssignal 408, 416 gelangt über den Ethernet Switch 48 an den Ehernet-Core K4 und dort in die nicht vertrauenswürdige Zone Z1. Über den in dem nicht vertrauenswürdigen Bereich Z1 angesiedelten Teil des Kommunikationsadapters 32 werden die Daten zunächst in den Bereich B3, dort in den nicht vertrauenswürdigen Bereich NT, gepuffert. Auf die dort isolierten Daten hat der Kommunikationsadapter 32 der vertrauenswürdigen Zone Z2 Zugriff. Der Kommunikationsadapter 32 der vertrauenswürdigen Zone Z2 erkennt, dass es sich um verschlüsselte Daten handelt. Die Entschlüsselung erfolgt nun, indem der Kommunikationsadapter 32 der vertrauenswürdigen Zone Z2 die Daten zur Entschlüsselung an das Sicherheitsmodul 73 sendet bzw. dem entsprechenden Sicherheitsmodul 73 Zugriff auf die Daten zuweist. Anschließend gelangt das von dem Sicherheitsmodul 73 entschlüsselte Signal im Klartext wieder zurück an den Kommunikationsadapter 32 der vertrauenswürdigen Zone Z2. Dann erkennt der Kommunikationsadapter 32, dass weitere sicherheitsrelevante Informationen wie beispielsweise die veränderliche Größe 254' und/oder eine Authentifizierungs-Information 256' Bestandteil des Bestätigungssignals 408, 416 sind (vergleiche 5). In einer besonders bevorzugten Variante wurde die veränderliche Größe 254' des Bestätigungssignals 408, 416 durch die übergeordnete Instanz 34 so gebildet, dass die veränderliche Größe 254 wie durch den letzten Ereignisbericht 242 übermittelt (und ebenfalls durch das Sicherheitsmodul 73 generiert) als veränderliche Größe 254' für das Bestätigungssignal 408, 416 verwendet wurde. Somit führt das Sicherheitsmodul 73 eine entsprechende Überprüfung durch, ob die veränderliche Größe 254' des Bestätigungssignals 408, 416 mit der veränderlichen Größe 254 insbesondere des letzten Ereignisberichts 242 übereinstimmt. Ist dies der Fall, so kann eine entsprechende Freigabeinformation für das Bestätigungssignal 408, 416 generiert werden. Der Kommunikationsadapter 32 der vertrauenswürdigen Zone Z2 sendet in diesem Zusammenhang beispielsweise ein Signal 410 an den Ereignismanager 30, die im Rahmen des letzten Ereignisberichts 242 übertragenen Ereignisse 226 im Pufferspeicher 206 zu löschen. Weiterhin könnte zusätzlich auch die entsprechende Authentifizierungs-Information 256' für eine Verifizierung bzw. Authentifizierung des empfangenen Bestätigungssignals 408,416 wie beschrieben verwendet werden.
Nachfolgend werden die Kommunikationsabläufe zwischen Ereignismanager 30 und Kommunikationsadapter 32 innerhalb des Steuergeräts bzw. Gateways 20, sowie zwischen Kommunikationsadapter 32 und zumindest einer weiteren IDS Instanz 34 innerhalb des Fahrzeugs 18 sowie zwischen der weiteren IDS Instanz 34 und dem Backend 36 anhand der 5-10 beispielhaft beschrieben.
Die Kommunikation vom Steuergerät wie beispielsweise das Gateway 20 zu weitere(n) IDS Instanz(en) 34 (beispielsweise ein zentraler Ereignis-Logger innerhalb des Fahrzeugs 18) sollte sicherstellen, dass die weitere IDS Instanz 34 oder der Ereigniss-Logger über nicht ausgelesene Einträge bzw. im Speicher 206 gespeicherte Ereignisse 236 bzw. selektierte Ereignisse 226 informiert wird. Das Steuergerät bzw. das Gateway 20 soll einen Ereignisbericht 242 auf regulärer Basis zu der weiteren IDS Instanz 34 schicken, bevorzugt über ein sogenannten Heartbeat-Signal (zyklisches Signal, welches zur Überprüfung einer ordnungsgemäßen Verbindung der Kommunikationsteilnehmer verwendet werden kann). Das Heartbeat-Signal (inklusive des Ereignisberichts 242) soll verschlüsselt und authentisch sein. Vorzugsweise sollen die übermittelten Informationen authentisch (gegebenenfalls unter Verwendung der Authentifizierungsinformation 256) und verschlüsselt, vorzugsweise zufällig bzw. unter Verwendung einer Zufallszahl 273 zwischen Steuergerät bzw. Gateway 20 und der weiteren IDS Instanz 34 ausgetauscht werden. Vorzugsweise sollte der Ereignisbericht 242 eine feste Länge 257 aufweisen, sollte verschlüsselt und authentifiziert werden. Jeder verschlüsselte Ereignisbericht 242 sollte sich von den vorhergehenden Ereignisberichten 242 unterscheiden, selbst wenn der übermittelte Status sich nicht verändert hat.
Die Kommunikation von der weiteren IDS Instanz 34 zum Steuergerät bzw. Gateway 20 bzw. dem zugehörigen Kommunikationsadapter 32 sollte sich außerdem durch nachfolgende Funktionalitäten auszeichnen. Der Daten-Logger bzw. die IDS Instanz 34 sollte die Ereignisse 236 bzw. zugehörige Ereignisberichte 242 so schnell wie möglich einlesen, um ein Überlaufen insbesondere des Speichers bzw. Pufferspeichers 206 zu verhindern. Die Ereignisberichte 242 sollten über ein Diagnoseinterface ausgelesen werden können, beispielsweise auf Anforderung. Alternativ könnte der Ereignisbericht 242 komplett zyklisch verschickt werden. Die Ereignisberichte 242 sollten auf regulärer Basis, vorzugsweise authentisch und verschlüsselt bzw. getarnt kommuniziert bzw. ausgelesen werden, selbst wenn keine neuen selektierten Ereignisse 226 im Rahmen eines neuen Ereignisberichts 242 verfügbar sind. Das Steuergerät bzw. Gateway 20 sollte auf eine Ausleseanforderung 240 mit einer Antwort bzw. einem Ereignisbericht 242 mit einer fixen Länge, verschlüsselt und authentifiziert antworten. Jede verschlüsselte Antwort bzw. Ereignisbericht 242 soll sich von den vorhergehenden Antworten bzw. Ereignisberichten 242 unterscheiden, selbst wenn sich der Inhalt nicht geändert hat. Beispielhaft erfolgt dies durch die stets veränderte Größe 254 wie bereits beschrieben.
Gemäß 5 selektiert der in der vertrauenswürdigen Zone Z2 angeordnete Ereignismanager 30 zunächst ein erstes selektiertes Ereignis 226.1 sowie anschließend ein zweites selektiertes Ereignis 226.2. Diese werden vom Ereignismanager 30 wie beschrieben verarbeitet. Die selektierten Ereignisse 226.1, 226.2 sind also im Speicher 206 abgelegt. Der in der vertrauenswürdigen Zone Z2 angesiedelte Teil des Kommunikationsadapters 32 enthält ein Signal 400, ein zeitabhängiges Interruptsignal (Timer IRQ). Vorzugsweise ist das zeitabhängige Signal 400 zyklisch gebildet, sodass dadurch zyklisch die Übersendung eines Ereignisberichts 242 von dem Kommunikationsadapter 32 an weitere IDS Instanzen 34 im Fahrzeug 18 eingeleitet wird. Doch selbst bei keinen neuen Ereignissen 226.1, 226.2 wird wie nachfolgend beschrieben ein Signal (in Form eines „normalen“ Ereignisberichts 242) von dem Kommunikationsadapter 32 an die weitere IDS Instanz 34 geschickt (vergleiche Signal 406). Besonders bevorzugt wird jedoch die Übersendung eines Ereignisberichts 242 nicht in Abhängigkeit von dem Erhalt eines Ereignisses 220 bzw. selektierten Ereignisses 226 getriggert, sondern zyklisch (durch Zeitablauf der Zykluszeit). Dies ist besonders vorteilhaft, da auch später die Übertragung an weitere IDS Instanzen 34 und/oder das Backend 36 immer zyklisch, also nach Ablauf einer bestimmten Zeit erfolgt. Damit ist für einen Angreifer das Verhalten des Ereignismanagers 30 bzw. Anomalieerkennung undurchsichtig. Der Angreifer weiß nie, ob sein Angriff detektiert wurde, was detektiert wurde und wie das System zur Anomalieerkennung arbeitet.
Nachdem der Kommunikationsadapter 32 das Signal 400 (Timer Interrupt) empfangen hat, fordert der in der vertrauenswürdigen Zone Z2 angesiedelte Teil des Kommunikationsadapter 32 einen Ereignisbericht 242 von dem Ereignismanager 30 an, Signal 402. Der Ereignismanager 30 erstellt den entsprechenden Ereignisbericht 242, der die zuvor selektierten Ereignisse 226.1 und/oder 226.2 (mit jeweiligen generischen Metadaten 217 und ereignisabhängigen Metadaten 216) sowie eine veränderte Größe 254 umfasst. Weiterhin werden entsprechende Fülldaten 255 hinzugefügt, sodass die feste Länge 257 des Ereignisberichts 242 erreicht wird (in Kenntnis der Länge der noch zu bildenden Authentifizierungs-Information 256). Weiterhin generiert beispielsweise der Ereignismanager 30 aus der veränderten Information 254, den selektierten Ereignissen 226.1,226.2 sowie den Fülldaten 255 eine Authentifizierungs-Information 256 unter Verwendung eines bestimmten Algorithmus. Die so gebildete Authentifizierungs-Information 256 komplettiert den Ereignisbericht 242. Anschließend erfolgt die Verschlüsselung des kompletten Ereignisberichts 242 mit dem Schlüssel 258. Der verschlüsselte Ereignisbericht 242 gelangt als Signal 404 an den in der vertrauenswürdigen Zone Z2 angesiedelten Teil des Kommunikationsadapters 32. Verschlüsselung (unter Verwendung der veränderten Information 254 und/oder des Schlüssels 258) und Authentifizierung (Bildung der Authentifizierung-Information 256) könnten im Ereignismanager 30 und/oder im Kommunikationsadapter 32 bzw. unter Verwendung des Sicherheitsmoduls 73 (ebenfalls in der vertrauenswürdigen Zone Z2 angeordnet) wie bereits beschrieben erfolgen, wenn die entsprechenden Sicherheitserfordernisse erfüllt sind.
Alternativ könnte der Kommunikationsadapter 32 und/oder das Sicherheitsmodul 73 den Ereignisbericht 242 verschlüsseln beispielsweise in Abhängigkeit von einer Zufallszahl 273. Besonders bevorzugt wird zur Verschlüsselung immer eine neue Zufallszahl 273 gebildet, beispielsweise durch Hashing. Dies erschwert weiter die Entschlüsselung einer übertragenen Nachricht bzw. des verschlüsselten Ereignisberichts 242. Gegebenenfalls übernimmt der Kommunikationsadapter 33 die Authentifizierung unter Verwendung der Authentifizierungsinformation 256 und/oder das Hinzufügen der veränderlichen Größe 254 und/oder das abschließende Verschlüsseln des gesamten Ereignisberichts 242 mit der Verschlüsselung 258.
Ein entsprechendes Signal 406 wird auf den Timer Interrupt (Signal 400) selbst dann geschickt, wenn kein neuer Ereignisbericht 242 durch Auftreten neuer selektierter Ereignisse 226 vom Ereignismanager 30 zur Verfügung gestellt wird. Dann wird eine Dummy-Nachricht mit dem Datenformat eines Ereignisberichts 242 verwendet und durch eine Zufallszahl bzw. die stets veränderte Größe 254 verschlüsselt (unter Verwendung des Schlüssels 258) an die weitere IDS Instanz 34 übertragen. Auch Dummy-Nachrichten werden immer durch stets veränderte Größen 254 bzw. neue Zufallszahlen verschlüsselt, sodass auch bei Nicht-Auftreten von neuen selektierten Ereignissen 226 immer zyklisch andere bzw. verschlüsselte Nachrichten (Signal 406) übertragen werden. Durch das zyklische Übertragen kann das Funktionieren einer ordnungsgemäßen Kommunikationsverbindung zwischen dem Kommunikationsadapter 32 und der weiteren IDS Instanz 34 überprüft werden. Wie bereits beschrieben erfolgt das versenden des Ereignisbericht 242 über den in der nicht vertrauensvollen Zone Z1 angeordneten Teil des Kommunikationsadapter 32.
Nach dem Erhalt der von dem Kommunikationsadapter 32 versendeten Nachricht (Signal 406) durch die weitere IDS Instanz 34 sendet die weitere IDS Instanz 34 ein Bestätigungssignal (408) an den Kommunikationsadapter 32, insbesondere an den in der nicht vertrauenswürdigen Zone Z1 angeordneten Teil des Kommunikationsadapter 32. Das weitere Vorgehen wurde bereits in Verbindung mit 4 näher ausgeführt. Nach Erhalt des Bestätigungssignals 408 generiert der in der vertrauenswürdigen Zone Z2 angeordnete Teil des Kommunikationsadapters 32 eine Anforderung an den Ereignismanager 30, die zwischengespeicherten gegebenenfalls reduzierten selektierten Ereignisse 226 bzw. zugehörigen Ereignisberichte 242 zu löschen bzw. wieder zu überschreiben (Signal 410).
In einem alternativen Ausführungsbeispiel überprüft die übergeordnete Instanz 34 und/oder das Backend 36 die Authentizität des empfangenen verschlüsselten Ereignisberichts 242. Hierzu entschlüsselt die übergeordnete Instanz 34 und/oder das Backend 36 die empfangene Nachricht, nämlich den verschlüsselten Ereignisbericht 242, unter Verwendung des bekannten Schlüssels 258. Dann steht der Ereignisbericht 242 im Klartext zur Verfügung. Unter Verwendung des entsprechenden Algorithmus (der auch durch Ereignismanager 30 oder Kommunikationsadapter 32 zur Erstellung der Authentifizierungs-Information 256 verwendet wurde) zur Bildung der Authentifizierung-Information 256 wird der Ereignisbericht 242 authentifiziert. Hierzu werden wieder sämtliche Daten des empfangenen und entschlüsselten Ereignisberichts 242 (mit Ausnahme der Authentifizierungs-Information 256) herangezogen und daraus eine entsprechende Authentifizierungs-Information 256' gebildet. Anschließend erfolgt der Vergleich der gebildeten Authentifizierungs-Information 256' mit der im Rahmen des Ereignisberichts 242 empfangenen Authentifizierungslnformation 256. Bei einer Übereinstimmung gilt der empfangene Ereignisbericht 246 als authentisch. Erst nach erfolgter Authentifizierung kann in dieser Variante die weitere Datenkommunikation mit der Instanz der höheren Ebene oder niedrigeren Ebene erfolgen. Erst bei einer erfolgreichen Authentifizierung wird in dieser Ausführung das Signal 408 (Bestätigungssignal) an den Kommunikationsadapter 32 verschickt, der daraufhin das Signal 410 zur Freigabe zum Überschreiben der selektierten Ereignisse 226.1,226.2 an den Ereignismanager 30 versendet.
Vorzugsweise soll auch die Antwort bzw. das Bestätigungssignal 408, 416 eine feste Länge 257' aufweisen. Vorzugsweise soll das Bestätigungssignal 408 authentifiziert und verschlüsselt sein. Jede Antwort bzw. Bestätigungssignal 408 durch die übergeordnete Instanz 34 und/oder das Backend 36 soll sich unterscheiden, selbst wenn sich der Inhalt nicht verändert hat.
Ein Beispiel für ein solches Bestätigungssignal 408, 416 ist 5 zu entnehmen. Das Bestätigungssignal 408, 416 ist ähnlich aufgebaut wie der Ereignisbericht 242. Das Bestätigungssignal 408,416 umfasst eine veränderliche Größe 254'. Die veränderliche Größe 254' verändert sich für jedes neu versendete Bestätigungssignal 408, 416. Die veränderliche Größe 254' könnte wieder beispielsweise durch eine Zufallszahl, einen Zähler, eine Zeit realisiert werden.
Besonders bevorzugt könnte die veränderliche Größe 254' des Bestätigungssignals 408,416 gebildet werden, indem die veränderliche Größe 254 des Ereignisbericht 242 wie eben übermittelt und, gegebenenfalls durch das Sicherheitsmodul 73 erzeugt, verwendet wird. Hierzu ist die übergeordnete Instanz 34,36, dazu eingerichtet, die veränderliche Größe 254 aus dem empfangenen Ereignisbericht 242 zu extrahieren und in das Bestätigungssignal 408,416 einzufügen. Damit könnte in einem nachfolgenden Schritt auch eine Authentifizierung des Bestätigungssignals 408,416 erfolgen, indem die empfangene veränderliche Größe 254' des Bestätigungssignals 408,416 verglichen wird mit der veränderlichen Größe 254 des eben zuvor gesendeten Ereignisberichts 242. Bei einer Übereinstimmung wird auf ein authentisches Bestätigungssignal 406,408 geschlossen. Außerdem muss die veränderliche Größe 254' in der übergeordneten Instanz 34,36 nicht selbst generiert werden. Daran kann die Freigabe des Speichers 206 folgen.
Weiterhin umfasst das Bestätigungssignal 408,416 bestimmte Daten 255', beispielsweise in Form beliebiger Pattern. Weiterhin umfasst das Bestätigungssignal 408, 416 eine Authentifizierungs-Information 256'. Die Authentifizierungs-Information 256' könnte ähnlich wie beim Ereignisbericht 242 wieder über einen bestimmten Algorithmus gebildet werden, der auf die restlichen Daten des Bestätigungssignals 408, 416, nämlich die veränderliche Größe 254' sowie die Daten 255' zurückgreift. Die so gebildete Authentifizierung Information 256' komplettiert das Bestätigungssignal 408, 416. Es weist eine feste Länge 257' auf. Dann erfolgt eine Verschlüsselung unter Verwendung eines Schlüssels 258'. Optional könnte auch auf diese Verschlüsselung 258' verzichtet werden.
Die empfangenden Instanzen (beispielsweise die übergeordnete Instanz 34 das Backend 36) und/oder der Kommunikationsadapter 32 bzw. der Ereignismanager 30 sind wiederum in der Lage, das Bestätigungssignal 408,412 zu entschlüsseln (unter Verwendung des Schlüssels 258') und zu authentifizieren. Hierzu wird wiederum aus den empfangenen Daten (veränderliche Größe 254', Daten 255') unter Verwendung eines entsprechend bekannten Algorithmus die sich daraus ergebende Authentifizierungs-Informationen 256" ermittelt und mit der erhaltenen Authentifizierungs-Informationen 256' verglichen. Bei Übereinstimmung wird von Authentizität ausgegangen. Sofern die erhaltene Authentifizierungsinformationen 256' in Ordnung ist, könnte das Signal 410 zur Freigabe des Speichers 206 erzeugt werden. Sollte die Authentifizierungsinformationen 256' nicht in Ordnung sein, könnte dieses Signal 410 nicht generiert werden, sodass die in dem Speicher 206 enthaltenen selektierten Ereignisse 226 (noch) nicht gelöscht werden.
Auch die weitere IDS Instanz 34 empfängt zyklisch ein Timer Interrupt- Signal 412, welches ähnlich wie das Signal 400 wie bereits beschrieben gebildet wird. Auf dieses Interrupt-Signal 412 sendet die weitere IDS Instanz 34 wiederum eine verschlüsselte Nachricht, Signal 414. Diese Nachricht enthält gegebenenfalls den Ereignisbericht 242 oder einen fahrzeugbezogenen Ereignisbericht (unter Einbeziehung weiterer Ereignisberichte) wie über Signal 406 vor dem Kommunikationsadapter 32 übermittelt. Ebenso wie beim Kommunikationsadapter 32 wird die Nachricht durch die weitere IDS Instanz 34 verschlüsselt, insbesondere durch eine sich ständig ändernde Größe 254' wie beispielsweise eine Zufallszahl 273. Sollte der Kommunikationsadapter 32 keinen Ereignisbericht 242 übermittelt haben, da beispielsweise kein neues selektiertes Ereignis 226 auftrat, wird wiederum eine Dummy-Nachricht mit dem selben Datenformat wie ein Ereignisbericht 242 verwendet und verschlüsselt an das Backend 36 übertragen (Signal 414). Das Backend 36 sendet ein Bestätigungssignal 416 und/oder eine weitere Mitteilung bzw. Aufforderung zum Überschreiben der im Pufferspeicher 206 zwischengespeicherten Ereignisse 236 oder Ähnliches an die weitere IDS Instanz 34. Das Bestätigungssignal 416 kann wie oben beschrieben gebildet sein.
Nach Erhalt des Signals 410 bezüglich der Ereignisfreigabe selektiert der Ereignismanager 30 weitere selektierte Ereignisse 226.3 sowie 226.4. Der weitere Ablauf lässt sich 6 entnehmen. Zwischenzeitlich selektierte der Ereignismanager 30 noch ein weiteres Ereignis 226.5. Erneut gelangt ein Timer Interrupt (Signal 420) an den Kommunikationsadapter 32. Dieser fordert nun für das Gateway 20 einen Ereignisbericht 242 an (Signal 422). Der Ereignismanager 30 übersendet an den Kommunikationsadapter 32 einen Ereignisbericht 242, der auf den selektierten Ereignissen 226.3, 226.4, 226.5 basiert, Signal 424. Nach Erhalt des Ereignisberichts 242 übersendet der Kommunikationsadapter 32 den durch eine neue veränderliche Größe 254 wie eine Zufallszahl verschlüsselten und authentifizierten Ereignisbericht 242 an die weitere IDS Instanz 34, Signal 426. Den Erhalt bestätigt die weitere IDS Instanz 34 durch ein Bestätigungssignal 428. Das Betätigungssignal 428 kann gebildet sein wie in Verbindung mit Betätigungssignal 408 (5) beschrieben. Nach Erhalt des Bestätigungssignals 428 sendet der Kommunikationsadapter 32 wiederum eine Anforderung an den Ereignismanager 30, die dem Ereignisbericht 242 zugrunde liegenden selektierten Ereignisse 226.3, 226.4, 226.5, zu überschreiben bzw. zu löschen, Signal 430. Zwischen dem Aussenden des Signals 424 und dem Empfang des Signals 430 wird zwischenzeitlich ein weiteres selektiertes Ereignis 226.6 selektiert. Dieses selektierte Ereignis 226.6 jedoch darf noch nicht überschrieben werden, da dieses selektierte Ereignis 226.6 noch nicht Basis für einen schon an den Kommunikationsadapter 32 übermittelten Ereignisbericht 242 war. Insofern bezieht sich das Signal 430 nicht darauf, das selektierte Ereignis 226.6 zu überschreiben, sondern lediglich diejenigen selektierten Ereignisse 226.3, 226.4, 226.5 zu überschreiben, die bereits im Rahmen des letzten Ereignisberichts 242 übermittelt wurden.
Wiederum tritt auch bei der weiteren IDS Instanz 34 ein Timer Interrupt auf (Signal 432) wie bereits beschrieben. Dadurch wird die weitere IDS Instanz 34 veranlasst, den in Signal 426 neu empfangenen Ereignisbericht 242 verschlüsselt an das Backend 36 zu übertragen, Signal 434. Den Erhalt der entsprechenden Nachricht 434 quittiert das Backend 36 durch ein entsprechendes Bestätigungssignal 436, welches an die weitere IDS Instanz 34 gesendet wird. Das Bestätigungssignal 436 könnte gebildet sein wie das Bestätigungssignal 408 bzw. 416.
Der weitere Ablauf wird in 7 gezeigt. Erneut tritt ein weiterer Timer Interrupt für den Kommunikationsadapter 32 auf, Signal 440. Daraufhin sendet der Kommunikationsadapter 32 aus der vertrauenswürdigen Zone Z2 eine Anforderung an den Ereignismanager 30 zur Übersendung eines Ereignisberichts 242, Signal 442. Der Ereignismanager 30 übersendet einen Ereignisbericht 242, der das zwischenzeitlich selektierte Ereignis 226.6 beinhaltet, Signal 444. Der Kommunikationsadapter 32 verschlüsselt den Ereignisbericht 242 unter Verwendung einer sich neuen veränderlichen Größe 256, gegebenenfalls unter Verwendung des Sicherheitsmoduls 73, und übersendet den verschlüsselten Ereignisbericht 242 über den in der nicht vertrauenswürdigen Zone Z1 befindlichen Teil des Kommunikationsadapter 32 an die weitere IDS Instanz 34, Signal 446. Bei Erhalt sendet die weitere IDS Instanz 34 eine Bestätigung, Signal 448, bei dessen Erhalt der Kommunikationsadapter 32 eine Anforderung an den Ereignismanager 30 sendet, die bereits übermittelten Ereignisse 226.6 zu überschreiben bzw. freizugeben, 450.
Wiederum empfängt die weitere IDS Instanz 34 einen Timer Interrupt, Signal 452. Daraufhin wird der verschlüsselte Ereignisbericht 242 gegebenenfalls zusammen mit weiteren Ereignisberichten weiterer IDS-Systeme fahrzeugbezogen an das Backend 36 übermittelt. Das Backend 36 sendet an die weiteren IDS Instanz(en) 34 ein Bestätigungssignal und/oder eine Anforderung, entsprechende Ereignisse freizugeben bzw. zu überschreiben etc., Signal 456.
Bei dem beispielhaften Ablauf gemäß 8 ist zwischen dem Versenden des letzten Ereignisberichts 242 und dem neuen Auftreten eines Timer Interrupts (Signal 460) kein neues selektiertes Ereignis 226 aufgetreten. Nach Erhalt des Timer Interrupts 460 sendet der Kommunikationsadapter 32 aus der vertrauenswürdigen Zone Z2 ein entsprechendes Anforderungssignal 462 für einen neuen Ereignisbericht 242 an den Ereignismanager 30. Der Ereignismanager 30 generiert - obwohl neues selektiertes Ereignis 226 aufgetreten ist - einen Ereignisbericht 242 mit einem Dummy-Inhalt, der dann an den Kommunikationsadapter 32 versendet wird, Signal 464. Dieser Dummy-Inhalt kann von den weiteren IDS Instanzen 34 und/oder vom Backend 36 als solcher erkannt werden. Der Kommunikationsadapter 32 verschlüsselt in der vertrauensvollen Zone Z2, gegebenenfalls unter Verwendung des Sicherheitsmoduls 73, den empfangenen Ereignisbericht 242, der einen Dummy-Inhalt aufweist, mit einer neuen veränderten Größe 254, versendet und verschickt den verschlüsselten und authentifizierten Ereignisbericht 242 an die weitere IDS Instanz 34, Signal 466. das Versenden erfolgt wieder aus der nicht vertrauenswürdige Zone Z1. Der Erhalt wird durch die weitere IDS Instanz 34 bestätigt, Signal 468. Bei dessen Erhalt sendet der Kommunikationsadapter 32 erneut ein Anforderungssignal an den Ereignismanager 30, die letzten selektierten Ereignisse 226 zu überschreiben, Signal 470. Dies erfolgt selbst dann, wenn keine neuen selektierten Ereignisse 226 wie in dieser Konstellation vorliegen.
Erneut erhält die weitere IDS Instanz 34 einen Timer Interrupt, Signal 472. Daraufhin verschlüsselt die weitere IDS Instanz 34 den zuletzt erhaltenen verschlüsselten Ereignisbericht 242 wie von dem Kommunikationsadapter 32 übermittelt und versendet ihn gegebenenfalls mit weiteren Ereignisberichten von weiteren IDS-Systemen fahrzeugbezogen an das Backend 36. Das Backend 36 sendet ein Bestätigungssignal 476 und/oder eine Anforderung zur Freigabe der zu Grunde liegenden Ereignisse etc. an die weitere IDS Instanz 34.
Bei der Kommunikationssequenz der 9 erhält der Kommunikationsadapter 32 erneut einen Timer Interrupt, Signal 480. Bei diesem Timer Interrupt 480 kann es sich um ein spezielles Signal handeln, so dass der Kommunikationsadapter 32 eine Ereigniszusammenfassung vom Ereignismanager 30 anfordert (und nicht einen der üblichen Ereignisberichte 242), Signal 482. Der Ereignismanager 30 übersendet die Ereigniszusammenfassung an den Kommunikationsadapter 32, Signal 484. dies erfolgt wieder in der vertrauenswürdigen Zone Z2. Bei der Ereigniszusammenfassung können übergeordnete Informationen enthalten sein wie beispielsweise die verschiedenen Zählerstände 231 für die verschiedenen Ereignisarten 218, oder das Auftreten einer neuen Ereignisart etc. Wiederum wird auch die Ereigniszusammenfassung vom Kommunikationsadapter 32 durch eine neue veränderliche Größe 254 wie eine Zufallszahl, gegebenenfalls unter Verwendung des Sicherheitsmoduls 73, in der sicherheitsrelevanten Zone Z2 verschlüsselt und an weitere IDS Instanzen 34 übertragen, Signal 486. die Übertragung erfolgt wieder aus der nicht sicherheitsrelevanten Zone Z1. Sobald die IDS Instanz 34 die verschlüsselte Ereigniszusammenfassung von dem Kommunikationsadapter 32 erhalten hat, sendet die weitere IDS Instanz 34 die Ereigniszusammenfassung besonders bevorzugt verschlüsselt an das Backend 36 weiter. Im Ausführungsbeispiel ist für den Sendevorgang zwischen der weiteren IDS Instanz 34 und dem Backend 36 kein Timer Interrupt zur Initiierung des Kommunikationsvorgangs vorgesehen. Alternativ könnte dieser jedoch wiederum zyklisch wie auch die Übersendung eines üblichen Ereignisberichts initiiert werden.
Bei der Kommunikationssequenz der 10 sendet das Backend 36 eine Anforderung für einen Ereignisbericht an die weitere IDS Instanz 34 aus, Signal 490. Die weitere IDS Instanz 34 sendet eine verschlüsselte Anforderung für einen Ereignisbericht, beispielsweise über eine Diagnoseschnittstelle, an den Kommunikationsadapter 32, Signal 492. Die Verschlüsselung kann wieder über die veränderliche Größe 254' wie beispielsweise eine Zufallszahl erfolgen, die sich insbesondere für jede Verschlüsselung ändert. Nach Erhalt der Anforderung 492 sendet der Kommunikationsadapter 32 in der sicherheitsrelevanten Zone Z2 eine Anfrage für einen Ereignisbericht 242 an den Ereignismanager 30, Signal 494. Nach Erhalt der entsprechenden Anfrage 494 übersendet der Ereignismanager 30 den Ereignisbericht 242 an den Kommunikationsadapter 32, Signal 496. Der Kommunikationsadapter 32 verschlüsselt den Ereignisbericht 242 beispielsweise über eine neue veränderliche Größe 254 wie eine Zufallszahl, gegebenenfalls unter Verwendung des Sicherheitsmoduls 73, und übersendet diesen aus der nicht sicherheitsrelevanten Zone Z1 an die weitere IDS Instanz 34, Signal 498. Nach Erhalt des verschlüsselten Ereignisbericht 242 sendet die weitere IDS Instanz 34 den Ereignisbericht 242 an das Backend 36. Den Erhalt quittiert das 36 Backend an die weitere IDS Instanz 34, Signal 492. Den Erhalt des Quittierungssignals 492 bestätigt die weitere IDS Instanz 34 dem Kommunikationsadapter 32, Signal 494. Nach Erhalt des entsprechenden Signals 494 sendet der Kommunikationsadapter 32 eine entsprechende Anforderung an den Ereignismanager 30, zumindest die im Rahmen des letzten Ereignisberichts 242 übermittelten Ereignisse 220 freizugeben bzw. zu überschreiben.
Die beschriebenen Verfahren können in einer Recheneinheit, Computer bzw. Controller implementiert sein, insbesondere in einem Steuergerät eines Fahrzeugs 18. Gleichermaßen kann das Verfahren im Rahmen eines Computerprogramms erstellt sein, das eingerichtet ist, das Verfahren auszuführen, wenn es auf einem Computer ausgeführt wird. Weiterhin kann das Computerprogramm auf einem maschinenlesbares Speichermedium abgespeichert sein. Gleichwohl kann das Programm beispielsweise als Software-„over-the-air“ drahtlos oder über Diagnoseschnittstellen kabelgebunden aufgespielt werden.
ZITATE ENTHALTEN IN DER BESCHREIBUNG
Diese Liste der vom Anmelder aufgeführten Dokumente wurde automatisiert erzeugt und ist ausschließlich zur besseren Information des Lesers aufgenommen. Die Liste ist nicht Bestandteil der deutschen Patent- bzw. Gebrauchsmusteranmeldung. Das DPMA übernimmt keinerlei Haftung für etwaige Fehler oder Auslassungen.
Zitierte Patentliteratur

DE 102018209407 A1 [0002]

Claims

Verfahren zur Behandlung einer Anomalie von Daten, insbesondere bei einem Kraftfahrzeug, wobei mindestens ein Sensor (24,26, 28) zur Anomalieerkennung Daten (211) erhält erhält, wobei der Sensor (24,26, 28) die erhaltenen Daten (211) auf Anomalien untersucht und bei einer erkannten Anomalie in Abhängigkeit der zugehörigen Daten (211) ein Ereignis (220, 221) erzeugt und an einen Ereignismanager (30) weiterleitet, dadurch gekennzeichnet, dass zumindest eine vertrauenswürdige Zone (Z2) und eine nicht vertrauenswürdige Zone (Z1) vorgesehen werden, wobei zumindest ein Sensor (24,26, 28; 40, 60) und/oder der Ereignismanager (30) der vertrauenswürdigen Zone (Z2) zugeordnet sind.
Verfahren nach Anspruch 1, dadurch gekennzeichnet, dass zumindest ein Kommunikationsadapter (32) in derselben Zone (Z2) angeordnet ist wie der Ereignismanager (30), wobei der Kommunikationsadapter (32) der Kommunikation eines von dem Ereignismanager (30) zumindest teilweise erstellten Ereignisberichts (242) dient.
Verfahren nach einem der vorhergehenden Ansprüche, dadurch gekennzeichnet, dass der Kommunikationsadapter (32) auch einer nicht-vertrauenswürdigen Zone (Z1) zugeordnet wird.
Verfahren nach einem der vorhergehenden Ansprüche, dadurch gekennzeichnet, dass der Sensor (24,26, 28) in der vertrauenswürdigen Zone (Z2) zumindest Daten (211), insbesondere defragmentierte Daten, von einem Sensor (38, 62) enthält, der in der nicht vertrauenswürdigen Zone (Z1) angeordnet ist, wobei der Sensor (24, 26, 28) in der vertrauenswürdigen Zone (Z2) die erhaltenen Daten (211) auf Anomalien prüft und bei Vorliegen einer Anomalie ein Ereignis (220) erzeugt und/oder wobei der Sensor (38,62) in der nicht vertrauenswürdigen Zone (Z1) die erhaltenen Daten (211) auf Anomalien prüft und bei Vorliegen einer Anomalie ein Ereignis (220) erzeugt.
Verfahren nach einem der vorhergehenden Ansprüche, dadurch gekennzeichnet, dass ein Versenden des Ereignisberichts (242) erfolgt, indem der Kommunikationsadapter (32) in der vertrauenswürdigen Zone (Z2) den Ereignisbericht (242) in einen Speicher der nicht vertrauenswürdigen Zone (Z1) bringt, auf den der Kommunikationsadapter (32) in der nicht vertrauenswürdigen Zone (Z1) zugreifen und verschicken kann.
Verfahren nach einem der vorhergehenden Ansprüche, dadurch gekennzeichnet, dass der Ereignisbericht (242) zumindest eine sich für jeden Ereignisbericht (242) verändernde Größe (254) und/oder zumindest eine Authentifizierungs-Information (256) umfasst und/oder durch eine Verschlüsselung (258) verschlüsselt wird.
Verfahren nach einem der vorhergehenden Ansprüche, dadurch gekennzeichnet, dass ein der vertrauenswürdigen Zone (Z2) zugeordnetes Sicherheitsmodul (73) eine sich für jeden Ereignisbericht (242) veränderliche Größe (254) und/oder eine Authentifizierungs-Information (256) und/oder eine Verschlüsselung (258) bereitstellt.
Verfahren nach einem der vorhergehenden Ansprüche, dadurch gekennzeichnet, dass nach Versenden des Ereignisberichts (242) ein Bestätigungssignal (408,416) empfangen wird, welches von dem Kommunikationsadapter (32) der nicht vertrauenswürdigen Zone (Z1) empfangen und an den Kommunikationsadapter (32) der vertrauenswürdigen Zone (Z2) weitergeleitet wird.
Verfahren nach einem der vorhergehenden Ansprüche, dadurch gekennzeichnet, dass das Bestätigungssignal (408,416) zumindest eine für jedes Bestätigungssignal (408,416) veränderliche Größe (254') und/oder zumindest bestimmte Daten bzw. Pattern (255') und/oder zumindest eine Authentifizierungs-Information (256') und/oder zumindest eine konstante Länge (257') umfasst und/oder mit einer Verschlüsselung (258') verschlüsselt wird.
Verfahren nach einem der vorhergehenden Ansprüche, dadurch gekennzeichnet, dass der Kommunikationsadapter (32) der vertrauenswürdigen Zone (Z2) das empfangene Bestätigungssignal (408,416) unter Verwendung eines in der sicherheitsrelevanten Zone (Z2) angeordneten Sicherheitsmoduls (73) entschlüsselt und/oder authentifiziert.
Verfahren nach einem der vorhergehenden Ansprüche, dadurch gekennzeichnet, dass das empfangene Bestätigungssignal (408,416) entschlüsselt und/oder authentifiziert wird, indem überprüft wird, ob die veränderliche Größe (256) des verschickten Ereignisberichts (242) in dem Bestätigungssignal (408,416) enthalten ist.
Verfahren nach einem der vorhergehenden Ansprüche, dadurch gekennzeichnet, dass bei einer Übertragung von Daten von einer Zone (Z1) in die andere Zone (Z2) der Sensor (24, 26, 28) die Daten vor einer Benutzung überprüft, insbesondere ob ein Ereignis (220) aufgetreten ist und/oder dass für den Fall, dass kein Ereigniss (220) detektiert wurde, die Daten für die Benutzung in der anderen Zone (Z2) freigegeben werden.
Verfahren nach einem der vorhergehenden Ansprüche, dadurch gekennzeichnet, dass bei einem Auftreten eines Ereignisses (220) die Daten nicht in die andere Zone (Z2) transferiert werden und/oder der Sensor (24,26, 28) das Ereignis (220) an den Ereignismanager (30) weiterleitet.
Verfahren nach einem der vorhergehenden Ansprüche, dadurch gekennzeichnet, dass der Ereignismanager (30) und/oder der Kommunikationsadapter (32) der vertrauenswürdigen Zone (Z2) und/oder der Sensor (24,26,28) der vertrauenswürdigen Zone (Z2) und/oder das Sicherheitsmodul (73) auf einem Rechnerkern (K2) implementiert sind.
Verfahren nach einem der vorhergehenden Ansprüche, dadurch gekennzeichnet, dass zumindest einer Recheneinrichtung (100a; 100b) bestimmte ausführbaren Anwendungsprogramme (AP) zu einer von den wenigstens zwei Zonen (Z1, Z2) zugeordnet werden, wobei die Zonen (Z1, Z2) Ressourcen der Recheneinrichtung (100b; 100b) charakterisieren, die für eine Ausführung eines betreffenden Anwendungsprogramms (AP) nutzbar sind, optional Ausführen wenigstens eines der Anwendungsprogramme (AP) in Abhängigkeit der ihm zugeordneten Zone (Z1, Z2).
Verfahren nach wenigstens einem der vorstehenden Ansprüche , weiter aufweisend : Austauschen von ersten Daten zwischen verschiedenen Zonen (Z1, Z2) über einen Pufferspeicher, insbesondere Arbeitsspeicher, wobei insbesondere das Austauschen der ersten Daten zwischen der ersten Zone (Z1) und der zweiten Zone (Z2) folgende Schritte aufweist: d1) Kopieren der ersten Daten in einen der ersten Zone (Z1) zugeordneten ersten Pufferspeicherbereich, d2) Überprüfen der kopierten ersten Daten, und, insbesondere in Abhängigkeit der Überprüfung, d3) Kopieren der ersten Daten aus dem der ersten Zone (Z1) zugeordneten ersten Pufferspeicherbereich in einen der zweiten Zone (Z2) zugeordneten zweiten Pufferspeicherbereich.
Vorrichtung zur Ausführung des Verfahrens nach wenigstens einem der vorstehenden Ansprüche.