DE102020204052A1 - Verfahren zur Behandlung einer Anomalie von Daten, insbesondere bei einem Kraftfahrzeug - Google Patents

Verfahren zur Behandlung einer Anomalie von Daten, insbesondere bei einem Kraftfahrzeug Download PDF

Info

Publication number
DE102020204052A1
DE102020204052A1 DE102020204052.4A DE102020204052A DE102020204052A1 DE 102020204052 A1 DE102020204052 A1 DE 102020204052A1 DE 102020204052 A DE102020204052 A DE 102020204052A DE 102020204052 A1 DE102020204052 A1 DE 102020204052A1
Authority
DE
Germany
Prior art keywords
event
events
data
memory
random number
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Pending
Application number
DE102020204052.4A
Other languages
English (en)
Inventor
Manuel Jauss
Mustafa Kartal
Roland Steffen
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Robert Bosch GmbH
Original Assignee
Robert Bosch GmbH
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Robert Bosch GmbH filed Critical Robert Bosch GmbH
Priority to DE102020204052.4A priority Critical patent/DE102020204052A1/de
Priority to JP2022558499A priority patent/JP7441326B2/ja
Priority to PCT/EP2021/056573 priority patent/WO2021197828A1/de
Priority to CN202180024776.5A priority patent/CN115398428A/zh
Publication of DE102020204052A1 publication Critical patent/DE102020204052A1/de
Pending legal-status Critical Current

Links

Images

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F21/00—Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F21/50—Monitoring users, programs or devices to maintain the integrity of platforms, e.g. of processors, firmware or operating systems
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/14—Network architectures or network communication protocols for network security for detecting or protecting against malicious traffic
    • H04L63/1408—Network architectures or network communication protocols for network security for detecting or protecting against malicious traffic by monitoring network traffic
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F11/00—Error detection; Error correction; Monitoring
    • G06F11/30—Monitoring
    • G06F11/3065—Monitoring arrangements determined by the means or processing involved in reporting the monitored data
    • G06F11/3072—Monitoring arrangements determined by the means or processing involved in reporting the monitored data where the reporting involves data filtering, e.g. pattern matching, time or event triggered, adaptive or policy-based reporting
    • G06F11/3082—Monitoring arrangements determined by the means or processing involved in reporting the monitored data where the reporting involves data filtering, e.g. pattern matching, time or event triggered, adaptive or policy-based reporting the data filtering being achieved by aggregating or compressing the monitored data
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F2201/00—Indexing scheme relating to error detection, to error correction, and to monitoring
    • G06F2201/86—Event-based monitoring
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F2221/00—Indexing scheme relating to security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F2221/21—Indexing scheme relating to G06F21/00 and subgroups addressing additional information or applications relating to security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F2221/2101—Auditing as a secondary aspect

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, wobei der Sensor (24,26, 28) die erhaltenen Daten (211) auf Anomalien untersucht, bei einer erkannten Anomalie in Abhängigkeit der zugehörigen Daten (211) ein Ereignis (220, 221) erzeugt, wobei entschieden wird, ob das Ereignis (220, 221) weiterverarbeitet wird, insbesondere abgespeichert und/oder zumindest teilweise weiterkommuniziert wird.

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 gemäß den Merkmalen des unabhängigen Anspruchs erreicht.
  • Dadurch, dass entschieden wird, ob das Ereignis weiterverarbeitet wird, insbesondere abgespeichert und/oder zumindest teilweise weiterkommuniziert wird, sodass unterschiedliche Ereignisse mit unterschiedlicher Priorität geloggt werden können. Dadurch wird es möglich, dass Ereignisse mit höherer Priorität häufiger abgespeichert werden als Ereignisse mit niedrigerer Priorität.
  • In einer zweckmäßigen Weiterbildung ist vorgesehen, dass zufällig entschieden wird und/oder in Abhängigkeit von einer Anzahl eines Auftretens eines Ereignisses für eine bestimmte Ereignisart entschieden wird, ob das Ereignis weiterverarbeitet wird. Dadurch werden für den Angreifer auf nicht deterministische Art und Weise Ereignisse selektiert. Dadurch wird eine Reduktion der Ereignisse vorgenommen. Dadurch vereinfacht sich die Weiterverarbeitung der selektierten Ereignisse.
  • In einer zweckmäßigen Weiterbildung ist vorgesehen, dass bei einem erstmaligen Auftreten eines Ereignisses für eine bestimmte Ereignisart dieses Ereignis weiterverarbeitet wird. Dadurch wird pro Ereignisart immer ein Ereignis mit den zugehörigen Metadaten selektiert. Damit erhält man einen Gesamtüberblick über die auftretenden Anomalien.
  • In einer zweckmäßigen Weiterbildung ist vorgesehen, dass für ein Ereignis mit einer Ereignisart, die zuvor bereits bei einem vorherigen Ereignis aufgetreten ist, zufällig entschieden wird, ob das Ereignis weiterverarbeitet wird. Dadurch werden für den Angreifer auf nicht deterministisch Art und Weise Ereignisse selektiert, nachdem zuvor jedoch immer das erstmalige Auftreten eines Ereignisses zuverlässig selektiert wurde.
  • In einer zweckmäßigen Weiterbildung ist vorgesehen, dass für unterschiedliche Ereignisarten die zugehörige Anzahl der jeweils aufgetretenen Ereignisse ermittelt wird. Dadurch werden hilfreiche Zusatzinformationen generiert, die für eine spätere Auswertung nützlich sind. Dadurch können auch die einzelnen Ereignisarten zueinander in Relation gesetzt werden.
  • In einer zweckmäßigen Weiterbildung ist vorgesehen, dass bestimmten Ereignisarten jeweils unterschiedlichen Prioritätsgruppen zugeordnet werden, wobei Ereignisse einer höheren Prioritätsgruppe mit höherer Wahrscheinlichkeit insbesondere zufällig für die weiterverarbeitet werden als Ereignisse mit einer niedrigeren Prioritätsgruppe. Gerade durch das Zusammenfassen zu verschiedenen Prioritätsgruppen können einzelne Ereignisse hinsichtlich ihrer Bedeutung vereinfacht selektiert werden. Durch die zufällige Auswahl eines selektierten Ereignisses innerhalb der Prioritätsgruppe bleibt jedoch das Verhalten weiterhin für den Angreifer nicht nachvollziehbar bzw. nicht deterministisch nachvollziehbar.
  • In einer zweckmäßigen Weiterbildung ist vorgesehen, dass den unterschiedlichen Prioritätsgruppen jeweils bestimmte Offsets bzw. Bereiche zugeordnet sind, aus denen jeweils zumindest ein weiterzuverarbeitendes Ereignis der jeweiligen Prioritätsgruppe ausgewählt wird, wobei der Offset bzw. der Bereich einer Prioritätsgruppe mit höherer Priorität kleiner ist als der Offset bzw. der Bereich einer Prioritätsgruppe mit niedrigerer Priorität. Dadurch kann immer zufallsbasiert innerhalb eines Offsets ausgewählt werden, wie viele Ereignisse je nach Priorität durchschnittlich selektiert werden. Dadurch werden bei Ereignissen höherer Prioritätsgruppe mehr Ereignisse zufällig selektiert, bei Ereignissen mit niedrigerer Prioritätsgruppe weniger Ereignisse zufällig selektiert.
  • In einer zweckmäßigen Weiterbildung ist vorgesehen, dass aus mehreren Ereignissen mit derselben Ereignisart und/oder Prioritätsgruppe zufällig entschieden wird, welches dieser Ereignisse mit derselben Ereignisart und/oder Prioritätsgruppe weiterverarbeitet wird. Ereignisse aus unterschiedlichen Quellen können mit gleicher Priorität behandelt werden. Dadurch vereinfacht sich das Prioritätshandling.
  • In einer zweckmäßigen Weiterbildung ist vorgesehen, dass zufällig entschieden wird unter Verwendung einer Zufallszahl und/oder eines Bereiches einer Zufallszahl, insbesondere einer fahrzeugspezifischen und/oder steuergerätspezifischen Zufallszahl. Dadurch wird das nicht-deterministische Verhalten der Anomaliereduktion sichergestellt. Selbst im Falle der Offenlegung der Zufallszahl in einem Fahrzeug kann das erworbene Wissen nicht auf ein weiteres Fahrzeug übertragen werden. Durch die Verwendung von unterschiedlichen Zufallszahlen über die Fahrzeugflotte hinweg wird sichergestellt, dass unterschiedliche Ereignisse pro Fahrzeug selektiert werden. Dies erhöht bei einem Flottenangriff die Datenvielfalt und ermöglicht eine breitere Auswertung bzw. vollständige Rekonstruktion des Angriffs.
  • In einer zweckmäßigen Weiterbildung ist vorgesehen, dass das weiterzuverarbeitende Ereignis zumindest teilweise in einem Speicher abgespeichert wird, insbesondere in einem flüchtigen Speicher oder Pufferspeicher und/oder in einem nichtflüchtigen Speicher (208) und/oder im Rahmen eines Ereignisberichts kommuniziert wird und/oder mit weiteren Informationen, insbesondere generische Metadaten wie beispielsweise die Anzahl der aufgetretenen Ereignisse, Zeitsignal, Anzahl nicht weiterverarbeiteter Ereignisse, Länge versehen wird. Dadurch lassen sich hilfreiche Zusatzinformationen generieren, die für die spätere Auswertung hilfreich sind. Gerade durch das Archivieren der Länge pro Ereignis lassen sich Rückschlüsse auf den Füllstand des Puffers ziehen, ohne dass der Füllstand eigens ausgelesen werden muss.
  • In einer zweckmäßigen Weiterbildung ist vorgesehen, dass mehrere Sensoren zur Anomalieerkennung vorgesehen sind, die jeweils Daten aus unterschiedlichen Datenquellen erhalten, insbesondere ein Kommunikationssystem und/oder ein Host bzw. Microcontroller, wobei jeder der Sensoren die erhaltenen Daten auf Anomalien untersucht, bei einer erkannten Anomalie in Abhängigkeit der zugehörigen Daten ein Ereignis erzeugt und das Ereignis an einen Ereignismanager weiterleitet. Gerade bei unterschiedlichen Datenquellen stellte Ereignismanager übergeordnete Sichtweise in einer geeigneten Auswahl der zu selektierenden Ereignisse sicher.
  • Weitere vorteilhafte Ausgestaltungen ergeben sich aus weiteren abhängigen Ansprüchen sowie der folgenden Beschreibung und der Zeichnung. In der Zeichnung zeigt
    • 1 schematisch Komponenten einer Anomalieerkennung,
    • 2 einen beispielhaften Aufbau bzw. Wechselwirkung von empfangenen Daten, daraus abgeleitetem Ereignis, Aufbau des zugehörigen selektierten Ereignisses sowie einen Ereignisbericht,
    • 3 einen genaueren Aufbau eines Ereignismanagers,
    • 4 ein Flussdiagramm zur Auswahl eines weiterzuverarbeitenden Ereignisses,
    • 5 ein Flussdiagramm für die Zählerinkrementierung,
    • 6 ein Flussdiagramm für das Abspeichern eines nichtflüchtigen Speichers,
    • 7 eine schematische Übersicht für die zufällige Auswahl eines abzuspeichernden Ereignisses,
    • 8 die Zuordnung bestimmter in 7 verwendeter Größen,
    • 9-14 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 ü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. Oftmals werden die jeweiligen Ereignisarten 218 mit ereignisspezifischen Event-ID bzw. Ereignis-ID versehen. Es besteht eine Vielzahl von vordefinierten Ereignisarten 218 für unterschiedlichste Datenquellen mit zugehörigen eindeutigen Ereignis-ID's.
  • 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 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.
  • 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.
  • 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.
  • IDS Sensoren 24, 26, 28 leiten die Ereignisse 220 bzw. reduzierte Ereignisse 221 an den Ereignismanager 30 weiter. Gerade bei Ethernet-Netzwerken kann bei einem Angriffsversuch ein Speicher 206, insbesondere ein flüchtiger Speicher bzw. Pufferspeicher 206, sehr schnell bei einer Vielzahl von weiterzuleitenden Ereignissen 220 mit großen Datenmengen bzw. ereignisabhängigen Metadaten 216 nicht mehr sämtliche Ereignisse 220 aufnehmen. Dies kommt von der hohen Datenübertragungsrate bzw. hohen Datenmengen, die übertragen werden können. Daher kann es Sinn machen, dass ein oder mehrere IDS-Sensoren 24, 26, 28 bereits eine Vorauswahl der weiterzuleitenden Ereignisse 220 und/oder eine Datenreduktion (reduzierte Ereignisse 221) nach bestimmten Kriterien treffen. Diese Kriterien sollen sich durch geringe Vorhersagbarkeit auszeichnen.
  • Bei den IDS Sensoren 24,26, 28, insbesondere bei den IDS Ethernet Sensoren 26, erfolgt bevorzugt zur Erhöhung der Sicherheit die Auswahl bestimmter weiterzuleitender Ereignisse 220 und/oder die Reduzierung der Ereignisse zu reduzierten Ereignissen 221 zufallsgesteuert. Eine zufällige bzw. willkürliche Auswahl bzw. Reduzierung von bestimmten Ereignissen 220 bzw. Datenblöcken eines Ethernet-Frames erfolgt für einen Angreifer nicht deterministisch und verschleiert. Die zufallsgesteuerte Auswahl bzw. Reduzierung könnte beispielsweise auf einer für ein bestimmtes Steuergerät individuellen Zufallszahl 273 basieren. Die gleiche Zufallszahl 273 könnte im einfachsten Fall auch für die anderen zufallsbasierten Szenarien als Referenz im Ereignismanager 30 für die Reduktion bzw. Priorisierung aller Ereignisse 220, dem zufallsabhängigen Abspeichern von Ereignissen 220 oder Ähnliches verwendet werden. Alternativ könnten auch entsprechende Zufallszahlen wieder im Steuergerät neu generiert werden.
  • Eingehende Nachrichten bzw. Daten 211 weisen üblicher Weise entsprechende Header-Informationen 214 (beispielsweise bestimmte Adressdaten) und nachfolgende Nutzdaten 213 auf. Üblicherweise sind viele Header-Informationen enthalten, die nicht unbedingt für die Anomalieauswertung notwendig sind. Erfindungsgemäß werden lediglich bestimmte Adressanteile, die unbedingt nötig sind, als Bestandteil eines reduzierten Ereignisses 221 im Rahmen der ereignisabhängigen Metadaten 216 weitergeleitet wie beispielsweise die Adresse der Quelle (beispielsweise MAC Adresse, z.B. 48 Bit), die Adresse des Ziels (beispielsweise MAC Adresse, z.B. 48 Bit) sowie die ID-Nummer, die zu einer Anomalie geführt hat (Ereignisart 218). Andere Informationen wie beispielsweise eventuell der physikalische Port bzw. Port-ID, wo das Frame empfangen wurde, IP-Adresse von Quelle oder Ziel, Angaben zum UDP/TCP-Port der Quelle oder des Ziels, falls solche Informationen im Frame enthalten sind, müssen nicht oder nicht vollständig im Ereignis 220 übertragen werden.
  • Der weiterzuleitende bzw. ausgewählte Nutzdatenbereich 219 jedoch wird zufallsbasiert ausgewählt aus den Nutzdaten 213 der eingehenden Daten 211 wie auch schon in Verbindung mit den 2a und 2b erläutert. So könnte beispielsweise die Nummer des Anfangs-Datums (Anfang des zu übertragenden Speicherbereichs der Nutzdaten, beispielsweise Byte Nr. xyz) zufallsbasiert festgelegt werden (übertrage beispielsweise einen Datenbereich, dessen Anfangswert zufällig ermittelt wurde, beispielsweise für dieses Ereignis 220 Nutzdaten-Byte Nr. 538. Der Offset des ausgewählten Nutzdatenbereiches 219 (Anzahl der übermittelten Daten, beispielsweise 10 Bytes) könnte fest gewählt sein. Somit würden die Nutzdaten-Bytes mit den Nummern 538-547 neben den Minimal-Adressinformationen (Quelladresse, Zieladresse) als ausgewählter Nutzdatenbereich 219 im Rahmen des so reduziertes Ereignis 221 an den Ereignismanager 30 weitergeleitet. Alternativ könnte auch der Offset des ausgewählten Nutzdatenbereichs 219 (Anzahl der übermittelten Nutzdaten) variiert werden, vorzugsweise zufallsabhängig. Bevorzugt hängt der ausgewählte Nutzdatenbereich 219, insbesondere der Anfangs- oder Endbereich ausgewählten Nutzdatenbereichs 219 ab von einer Zufallszahl 273. Besonders bevorzugt ist diese Zufallszahl 273 abhängig von dem Steuergerät bzw. dem Gateway 20. Besonders bevorzugt ist die Zufallszahl 273 eindeutig, also nur für dieses spezielle Steuergerät einmalig vergeben.
  • Optional kann die Zufallszahl 273 aber auch erneuert werden. Dadurch ergeben sich nachfolgende Vorteile. Durch die Erneuerung der Zufallszahl werden bei der gleichen Angriffs-Sequenz (Sequenz von Ereignissen 220) unterschiedliche Ereignisse 220 geloggt bzw. selektiert. Dies ist auch der Fall, wenn der Angriff nur auf ein einzelnes Steuergerät/Fahrzeug 18 und nicht auf die gesamte Flotte erfolgt. Folgende Annahme/ Beispiel:
    1. 1. Mehrfache Wiederholung derselben Angriffs-Sequenz (Sequenz von Ereignissen 220)
    2. 2. Zwischen Angriffs-Sequenzen werden Zufallszahlen 273 erneuert
    3. 3. Im Rahmen einer Angriffs-Sequenz können nicht alle Ereignisse 220 geloggt bzw. selektiert werden werden (Ereignis Burst). Es folgt eine EreignisReduktion für den Ereignisbericht 242
    4. 4. Ein Ereignisbericht 242 mit reduzierten Ereignissen 221 wird an die übergeordnete Instanz 34, 36 vollständig zwischen zwei Angriffs-Sequenzen weitergeleitet. Hierdurch kann nach mehrmaliger Wiederholung der gleichen Angriffs-Sequenz die komplette Angriffs-Sequenz über die Ereignisberichte 242 rekonstruiert werden.
  • Der Sensor 26 könnte vorzugsweise die Wahl der Zufallszahl 273 bzw. die verschiedenen Bereiche der Zufallszahl 273 anpassen an die Größe der eingehenden Daten 211, insbesondere an die Größe der eingehenden Nutzdaten 213. Weisen die Nutzdaten 213 einen kleineren Datenbereich auf, so muss die Zufallszahl 273 so gewählt werden, dass die Auswahl eines bestimmten reduzierten Nutzdatenbereiches 219 auch nur in diesen kleinen Datenbereich der Nutzdaten 213 fällt. Die Zufallszahl 273 bzw. der betrachtete Bereich der Zufallszahl 273 muss also entsprechend klein sein. Weisen die eingehenden Nutzdaten 213 jedoch einen sehr großen Datenbereich auf, so muss die Zufallszahl 273 bzw. der betrachtete Bereich der Zufallszahl 273 so groß gewählt werden, dass die Auswahl eines bestimmten reduzierten Nutzdatenbereichs 219 auch diesen großen Datenbereich der Nutzdaten 213 abdecken kann. Die Zufallszahl 273 fällt also entsprechend größer aus.
  • Indem die Zufallszahl 273 eindeutig für ein jeweiliges Steuergerät 20 vergeben wurde, könnte bei Vorliegen weiterer Steuergeräte eventuell die komplette Nachricht (die auch an die weiteren Steuergeräte ging und mit dort entsprechend ausgestatteten Sensoren 26 ebenfalls entsprechend detektiert und reduziert weitergeleitet wurde) mit dem kompletten Datenbereich bei einer Analyse im Backend 36 durch das Zusammenführen vieler reduzierter Ereignisse 221 mehrerer Steuergeräte zusammengesetzt werden. Denn andere Steuergeräte mit derselben Sensorfunktion wie beschrieben wählen nun zufällig auch andere Nutzdatenbereiche 219 (mit anderen zufällig ausgewählten Start-oder Endadressen) aus, die nach dem Zusammenführen mehrerer reduzierter Ereignisse 221 einen großen Teil des (Nutz)Datenbereichs 213 oder den kompletten Datenbereich der Nutzdaten 213 anhand der Teilbereiche bzw. ausgewählter Nutzdatenbereiche 219 der verschiedenen Steuergeräte abdecken können. So könnten von verschiedenen Steuergeräten aus den reduzierten Ereignissen 221 bzw. ausgewählten Nutzdatenbereichs 219 ein Ereignis 220 rekonstruiert werden, indem beispielsweise Teil-Datenbereich 538-547 (des einen ausgewählten Nutzdatenbereichs 219) von dem einen Steuergerät, Teil-Datenbereich 548-557 (eines weiteren ausgewählten Nutzdatenbereichs 219) von einem weiteren Steuergerät, Teil-Datenbereich 558-567 (eines weiteren ausgewählten Nutzdatenbereichs 219) von einem weiteren Steuergerät zur Verfügung gestellt und die jeweiligen ausgewählten Nutzdatenbereiche 219 beispielsweise in einem übergeordneten Steuergerät oder im Backend 36 wieder zum kompletten (Nutz)Datenbereich 213 zusammengesetzt werden. Dies ist insbesondere bei einem sogenannten Broadcast-Angriff auf die gesamte Fahrzeugflotte oder einem sogenannten Multicast-Angriff auf Teile der Fahrzeugflotte der Fall.
  • Die zufällige Ermittlung des Beginns und/oder das Endes des weitergeleiteten bzw. ausgewählten Nutzdatenbereichs 219 wird vorzugsweise nach bestimmten Ereignissen (zyklisch, Hochfahren des Steuergeräts, Reset eines Steuergeräts etc.) neu durchgeführt. Hierzu könnte beispielsweise die Zufallszahl 273 neu erzeugt werden. Alternativ könnte ein anderer Bereich der Zufallszahl 273 für die Generierung des Beginns und/oder Endes des weiterzuleitenden Datenbereichs bzw. ausgewählten Nutzdatenbereichs 219 herangezogen werden.
  • 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. Prinzipiell könnten jedoch auch dort die Daten wie entsprechend beschrieben reduziert werden.
  • Prinzipiell laufen somit folgende Schritte zur Reduzierung der Ereignisse 220 im Sensor 24, 26, 28 ab. Daten 211 werden von dem Sensor 24, 26, 28 empfangen und/oder Daten 211 werden ausgewertet, ob eine Anomalie vorliegt. Bei Vorliegen einer Anomalie werden die Daten 211 reduziert. Die Reduktion erfolgt durch Reduzierung des Adressbereichs bzw. Header 214 und/oder des Datenbereichs bzw Nutzdaten 213. Die Reduzierung des Adressbereichs 214 könnte erfolgen durch Auswahl der Zieladresse und/oder der Quellenadresse. Die Reduzierung der Nutzdaten 213 erfolgt zufallsabhängig. Die Reduzierung der Nutzdaten 213 erfolgt zufallsabhängig durch zufällige Auswahl eines Startwerts und/oder eines Endwerts eines Teil-Bereichs der Nutzdaten 213. Der Offset des Datenbereichs (Anzahl der übermittelten Daten) ist auf einen bestimmten Wert festgelegt. Die reduzierten Ereignisse 221 werden an den Ereignismanager 30 übermittelt. Die reduzierten Ereignisse 221 beinhalten reduzierte Adressdaten und/oder reduzierte bzw. ausgewählte Nutzdaten 219. Eine Aktualisierung der Zufallszahl 273 erfolgt in Abhängigkeit von bestimmten Systemzuständen (zyklisch, Hochfahren, Reset etc.). Alternativ könnte eine Aktualisierung der Zufallszahl 273 zufällig und/oder zeitgesteuert erfolgen. Die Zufallszahl 273 bzw. Bereiche der Zufallszahl 273 zur Bestimmung des Start-oder Endbereichs des ausgewählten Nutzdatenbereich 219 kann abhängen von der Größe des Nutzbereichs 213 der empfangenen Daten 211.
  • Gemäß 3 ist der Aufbau des Ereignismanagers 30 genauer gezeigt. Der Ereignismanager 30 weist mehrere funktionale Blöcke auf, die in Wechselwirkung zueinander stehen. Jedes der von den Sensoren 24, 26, 28 detektierten Ereignisse 220 bzw. reduzierten Ereignisse 221 gelangen an einen Block 202. Block 202 dient der Auswahl der eingehenden Ereignisse 220, bzw. reduzierten Ereignisse 221, die weiterverarbeitet werden sollen. Insbesondere dient Block 202 der Priorisierung und Reduzierung von Ereignissen 220, 221.
  • Jedes Ereignis 220 bzw. jedes reduzierte Ereignis 221 gelangt ebenfalls an einen Block 204, der als Zähler 204 für Ereignisse 220, 221 dient. Bei einem auftretenden Ereignis 220, 221 wird ein entsprechender Zähler inkrementiert, insbesondere ein globaler Ereigniszähler 205. Besonders bevorzugt weist der Zähler 204 unterschiedliche Zähler Z1, Z2,... Zn auf für unterschiedliche Ereignisarten 218 (ID1, ID2, ...IDn) wie oben in Verbindung mit den entsprechenden Sensoren 24, 26, 28 näher ausgeführt. Der globale Ereigniszähler 205 wiederum stellt die Summe sämtlicher Zählerstände der Zähler Z1, Z2,...Zn für unterschiedliche Ereignisarten 218 (ID1, ID2,... IDn) dar. Das Ausgangssignal 231 des Blocks 204 bzw. Zählers beinhaltet die Zählerstände sämtlicher Ereignisse 220,221, also Zählerstände der jeweiligen ereignisabhängigen Zähler Z1, Z2,... Zn sowie des globalen Ereigniszählers 205. Das entsprechende Ausgangssignal 231 von Block 204 wird einem Block 210 zur Kommunikation der Ereignisse 220 zugeführt. Block 204 ist eingerichtet zum Empfang eines Rücksetzsignals 222, welches eine Rücksetzungsanforderung an den bzw. die Zähler bzw. Ereigniszähler 204, 205 darstellt. Block 204 erhält von Block 202 ein Signal für einen Reduktionsstatus 225, beispielsweise „Ereignisreduktion aktiv“. In Block 202 ist beispielsweise dann eine Ereignisreduktion aktiv, wenn nur eine reduzierte Anzahl bestimmter Ereignisse 220, 221 als selektierte Ereignisse 226 weiterverarbeitet werden. Dies ist insbesondere dann der Fall, wenn beispielsweise im Rahmen eines sogenannten Ereignis-Bursts eine hohe Anzahl von Ereignissen 220, 221 eingehen mit einem erhöhten Füllstand 228 des Pufferspeichers 206. In diesem Fall soll ein zusätzliches Ereignis 220 generiert werden, beispielsweise mit einer Ereignisart 218 „Ereignisreduktion aktiv“ wie oben beschrieben. Für dieses Ereignis 220' mit zugehöriger Ereignisart 218 gibt es dann ebenfalls einen entsprechenden Zähler bzw. Zählerstand.
  • Die von Block 202 bearbeiteten Ereignisse gelangen als selektierte Ereignisse 226 an einen Block 206, der als Speicher bzw. Pufferspeicher für die von Block 202 zugeführten selektierte Ereignisse 226 dient und die entsprechende Logik hierzu umfasst. Im Gegenzug meldet der Speicher 206 den Füllstand bzw. die Speicherbelegung 228 zurück an den Block 202. Bei dem Speicher 206 handelt es sich vorzugsweise um einen flüchtigen Speicher, insbesondere um einen Pufferspeicher eines RAM. Außerdem gelangt das Zeitsignal 224, insbesondere ein globales Zeitsignal 224, an den Speicher 206 bzw. an den Block zum Puffern der selektierten Ereignisse 226. Der Speicher 206 ist ein Bestandteil des Ereignismanagers 30.
  • Bestimmte in dem Speicher 206 abgespeicherte bzw. gepufferte Ereignisse 236 gelangen an einen Block 210, der der Kommunikation von Ereignisberichten 242 in Abhängigkeit von den selektierten Ereignissen 226 bzw. abgespeicherten Ereignissen 236 dient. Der Block 210 zur Kommunikation von Ereignissen erhält darüber hinaus Ausgangssignale 231 des Ereigniszählers 204, beispielsweise Zählerstände der Zähler Z1, Z2 ... Zn für die jeweiligen Ereignisarten 218 und/oder den Zählerstand des globalen Ereigniszählers 205. Der Block 210 zur Kommunikation von Ereignissen, insbesondere von Ereignisberichten 242, tauscht Signale 244 mit einem Kryptographiemodul 212 aus. Das Kryptografiemodul führt Kryptographieoperationen wie beispielsweise Verschlüsselungsoperationen, Authentisierungs- und Authentifizierungs-Operationen sowie Zufallszahlen-Generierung etc. durch. Mithilfe des Kryptographiemoduls 212 kann eine verschlüsselte Kommunikation des Blocks 210 nach außen erfolgen. Das Kryptografiemodul 212 führt insbesondere eine Verschlüsselung des Ereignisberichts 242 unter Verwendung der in 2d angedeuteten Verschlüsselung 257 durch. Ebenfalls kann das Kryptografiemodul 212 eine Authentifizierung des Ereignisberichts 242 unter Verwendung der Authentifizierungsinformation 256 durchführen, vergleiche ebenfalls 2d. Block 210 kann in dem Kommunikationsadapter 32 und/oder im Ereignismanager 30 angesiedelt sein. Der Block 210 gibt entsprechende Ereignisberichte 242 aus. Block 210 empfängt einen Anforderungsbefehl 240, entsprechende im Speicher 206, 208 abgespeicherte Ereignisse 236 auszulesen. Der Anforderungsbefehl 240 kann zyklisch erfolgen und/oder auf explizite Anforderung hin. Außerdem sendet der Block 210 ein Signal 239 (Ereignisfreigabe) an den Speicher 206. Damit wird in der Regel nach einer erfolgreichen Übertragung der zugehörigen Ereignisberichte 242, die auch die gespeicherten Ereignisse 236 bzw. selektierten Ereignisse 226 beinhalten, dem Speicher 206 bzw. 208 mitgeteilt, dass die abgespeicherten und weiterkommunizierten Ereignisse 236, 226 überschrieben bzw. gelöscht werden dürfen.
  • Außerdem ist in dem Ereignismanager 30 ein weiterer Speicher 208 vorgesehen, insbesondere ein nichtflüchtiger Speicher. In dem weiteren insbesondere nichtflüchtigen Speicher 208 werden bestimmte Ereignisse 234, die in dem Pufferspeicher 206 zwischengespeichert wurden, und/oder Zählerstände des Ereigniszählers 204 dauerhaft abspeichert. Hierzu tauscht der Speicher 208 Daten aus mit dem Ereigniszähler 204 und/oder mit dem Pufferspeicher 206.
  • Anhand 4 nachfolgend wird die Arbeitsweise des Blocks 202 zur Priorisierung und Reduzierung von Ereignissen 220 genauer beschrieben. Der nachfolgend beschriebene Mechanismus wird verwendet, um zu selektieren, ob für ein Ereignis 220, 221 ergänzende hilfreiche (und speicherintensive) Metadaten 215 abgespeichert werden sollen. Weiter verallgemeinernd dient Block 202 dazu, aus den dem Ereignismanager 30 zugeführten Ereignissen 220,221 die weiterzuverarbeitenden Ereignisse als selektierte Ereignisse 226 auszuwählen. Für jede Ereignisart 218 des erhaltenen Ereignisses 220, 221 wird nachverfolgt, ob es sich um das erstmalige Auftreten dieser bestimmten Ereignisart 218 handelt oder ob ein Ereignis 220 mit dieser Ereignisart 218 bereits an den Speicher bzw. Puffer 206 gesendet wurde; Abfrage 301. Beim erstmaligen Auftreten einer Ereignisart 218 schließt sich Block 304 an, in dem das jeweilige Ereignis 220 als selektiertes Ereignis 226 an den Puffer 206 übertragen und dort abgespeichert wird. Andernfalls schließt sich Block 302 an. In diesem Schritt 302 wird nach einem bestimmten Kriterium entschieden, ob das hinsichtlich der Ereignisart 218 bereits aufgetretene Ereignis 220, 221 trotzdem abgespeichert werden soll. Dies erfolgt beispielsweise nach einer zufälligen Auswahl des Ereignisses 220, 221, insbesondere basierend auf einer Zufallszahl 273. Diese zufällige Auswahl könnte besonders bevorzugt basieren auf einer steuergerätespezifischen oder fahrzeugspezifischen Zufallszahl 273. Für die zufällige Auswahl soll ein intelligenter Algorithmus verwendet werden, um das Überlaufen des Pufferspeichers 206 bei Worst-Case-Angriffsszenarien (lang anhaltender Angriff mit sog. Ereignis-Bursts) zu begrenzen. Andererseits soll eine vernünftige Anzahl von gespeicherten Ereignissen 236 bzw. selektierten Ereignissen 226 bzw. Log-Einträgen in normalen Szenarios erhalten werden, um ein möglichst großes Spektrum über den kompletten Angriff zu erfassen. Hierzu wird in Schritt 303 das in Schritt 302 ausgewählte Ereignis 220 an den Speicher 206 als selektiertes Ereignis 226 zum Abspeichern übermittelt.
  • Sofern nun also nach zufälligen Kriterien gemäß Schritt 302 das Ereignis ausgewählt wurde, Abfrage 303, so wird auch dieses Ereignis 220, 221 als selektiertes Ereignis 226 an den Speicher 206 geschickt, Schritt 304. Andernfalls endet der Programmablauf ohne Abspeichern dieses Ereignisses 220, 221 im Speicher 206 bzw. ohne ergänzendes Abspeichern weiterer Metadaten 215 zum Ereignis 220. Das Überwachen des erstmaligen Auftretens der Ereignisart 218 wird zurückgesetzt, wenn der Speicher 206 ausgelesen und über Block 210 kommuniziert wurde. Falls ein Ereignis 220, 221 nicht ausgewählt bzw. verworfen wurde, so wird der Zustand „Ereignis zurückgewiesen“ getriggert für jedes verworfene Ereignis 220, 221. besonders bevorzugt ist hierzu ein weiterer Zähler 204 vorzusehen, der die Anzahl der nicht selektierten Ereignisse 220 erfasst.
  • Für eine zusätzliche Priorisierung könnten die Ereignisse 220, 221 optional in Abhängigkeit von der jeweiligen Ereignisart 218 gruppiert und eine eigene Instanz für die zufällige Ereignisreduktion für jede Ereignisart 218 vorgesehen werden. Eine Priorisierung kann ergänzend erreicht werden durch Gruppenbildung. Dies bedeutet, dass die Ereignisarten 218 unterschiedlichen Prioritätsgruppen zugeordnet werden. Der Prioritätsgruppe mit höchster Priorität (Prio 1) werden bestimmte Ereignisarten 218 (beispielsweise Ereignisarten 218 mit den ID-Nummern ID1, ID6, ID14, ID23 etc.), einer Prioritätsgruppe mit nächst niedrigerer Priorität (Prio 2) werden zugehörige weitere Ereignisarten 218 (beispielsweise Ereignisarten 218 mit den ID-Nummern ID2, ID5, ID12, ID27 etc.), einer Prioritätsgruppen mit nächst niedrigerer Priorität (Prio 3) werden zugehörige weitere Ereignisarten 218 (beispielsweise Ereignisarten 218 mit den ID-Nummern ID3, ID9, ID13, ID19 etc.) usw. zugeordnet. Für unterschiedliche Prioritätsgruppen (Prio1, Prio2, Prio3, ...) werden zufallsbasiert unterschiedlich viele Ereignisse 220 im Mittel als selektierte Ereignisse 226 ausgewählt (N1: (Anzahl selektierter Ereignisse für Prioritätsgruppe 1 (Prio1), Nx: Anzahl selektierter Ereignisse für Prioritätsgruppe x (Prio_x). Bei Prioritätsgruppen mit hoher Priorität werden zufallsbasiert im Mittel mehr Ereignisse 220 selektiert als bei Prioritätsgruppen mit niedriger Priorität (N1 > N2...). Dies könnte beispielsweise dadurch erreicht werden, dass die Bereiche B1, B2.. Bx (mit den zugehörigen Prioritätsgruppen Prio1, Prio2... Prio_x) bzw. Anzahl, aus denen ein Ereignis 220 selektiert wird, je kleiner gewählt werden, desto höher die Priorität ist (B1<B2...).
  • Selektierte Ereignisse 226 werden im flüchtigen Speicher 206 abgespeichert. Selektierte Ereignisse 226 sollen jedoch nicht unmittelbar in dem nichtflüchtigen Speicher 208 abgespeichert werden, da ein zu häufiges Speichern den nichtflüchtigen Speicher 208 beschädigen könnte. Ein Abspeichern der selektierten Ereignisse 226 im nichtflüchtigen Speicher 208 könnte zufallsbasiert erfolgen wie beispielsweise in Verbindung mit 6 näher erläutert.
  • Der bzw. die Speicher 206, 208 können selektierte Ereignisse 226 mit unterschiedlicher Größe behandeln. In der 7 ist hier beispielhaft der Speicher 206 gezeigt. Er umfasst einen freien Speicherbereich 250 sowie einen gefüllten Speicherbereich 252. In dem gefüllten Speicherbereich 252 sind mehrere selektierte Ereignisse 226 bzw. 226 hinterlegt. Die Einträge 226 können jeweils unterschiedliche Größen aufweisen. Durch die nicht starre Einteilung von Speicherbereichen wird der Speicherplatz optimal ausgenutzt. Falls der Speicher 206 voll ist, würden neue selektierte Ereignisse 226 verworfen. Prinzipiell wird jedoch wie nachfolgend ausgeführt ein vollständiges Füllen des Speichers 206 durch einen selbstregelnden Mechanismus unterbunden. So werden bei einem sehr hohen Füllstand 228 des Speichers 206 zufallsbasiert im Mittel viel weniger Ereignisse 220 selektiert als bei einem niedrigen Füllstand 228 des Speichers 206. Sofern dennoch selektierte Ereignisse 226 verworfen werden aufgrund eines vollen Puffers 206, dann wird ein Ereigniszähler für eine neue Ereignisart 218 „Logging Buffer Overflow (Overflow des Speichers 206)“ implementiert, um die Anzahl der verworfenen Ereignisse bzw. Einträge zu ermitteln. Dies kann wie in 3 gezeigt beispielsweise dadurch erfolgen, dass der Status 230 des Speichers 206 dem Zähler 204 mitgeteilt wird bzw. dieses Signal 230 immer dann einen Impuls an den Zähler 204 sendet, wenn wieder ein weiteres selektiertes Ereignis 226 aufgrund vollen Speichers 206 nicht abgespeichert werden kann.
  • Sobald alle gespeicherten Ereignisse 236 bzw. selektierten Ereignisse 226 erfolgreich über Block 210 im Rahmen eines Ereignisberichts 242 beispielsweise zu einem externen Datenlogger in dem Steuergerät berichtet wurden, wird der Puffer 206 zum Überschreiben oder Löschen der entsprechenden Ereignisse 226 freigegeben (Signal 239 free event). Das Schreiben von Ereignissen 236 insbesondere in einen nichtflüchtigen Speicher 208 wie einen Flash Speicher könnte vorteilhaft über einen Nicht-AUTOSAR Speichermechanismus abgebildet werden, um Speichereffizienz und Performanceanforderungen sicherzustellen. Es besteht aber auch die Möglichkeit, einen Standard-AUTOSAR Speichermechanismus zu nutzen.
  • In Verbindung mit 5 wird der Ereigniszähler 204 näher beschrieben. Für jede Ereignisart 218 wird ein eigener Zähler Z1, Z2...Zn im Rahmen des Ereigniszählers 204 implementiert. Der Ereigniszähler 204 startet jeweils mit dem Wert Null. Zunächst wird ermittelt, ob der Zählerstand noch kleiner als ein Maximalwert ist, Abfrage 260. Sofern dies der Fall ist, wird bei Auftreten eines Ereignisses 220, 221 einer bestimmten Ereignisart 218 der Zähler Z1, Z2...Zn für die jeweilige Ereignisart 218 inkrementiert, Schritt 262. Andernfalls wird der Zählerstand auf dem Maximalwert gehalten, es kommt also zu keinem Overflow. Es ist möglich, den Ereigniszähler 204 auf Anfrage zurückzusetzen auf Null. Der Zähler 204 könnte beispielsweise als 32-Bit-Zähler implementiert werden.
  • Gemäß 6 wird das nichtflüchtige Abspeichern des Ereigniszählers 204 und/oder bestimmter selektierter Ereignisse 226 in dem nichtflüchtigen Speicher 208 beschrieben. Die Daten sollen in den nichtflüchtigen Speicher 208 in regelmäßigen Zeitabständen abgespeichert werden. Solche Zeitabstände liegen beispielsweise im Sekunden-, Minuten- bis Stundenbereich, beispielsweise erfolgt ein Speichern der Daten jede 30 Minuten. Der Zeitpunkt für das Abspeichern soll zufallsabhängig gewählt werden, um das Schreibverhalten für einen Angreifer unvorhersehbar zu machen. Die Speicherzyklen könnten zufallsgesteuert beispielsweise in einem bestimmten Intervall (beispielsweise innerhalb von 30 Minuten etc., der genaue Zeitpunkt des Abspeicherns innerhalb des bspw. 30 Minuten-Intervalls ist jedoch zufallsgesteuert) erfolgen. Wiederum könnte die Zufallsgröße (für die Bestimmung des Speicherzeitpunkts) in Abhängigkeit von einer steuergeräteindividuellen oder fahrzeugindividuellen Zufallszahl 273 erzeugt bzw. gewählt werden.
  • Alternativ könnten zeitgesteuerte Speichermomente zufallsabhängig gewählt werden, indem eine Zufallszahl multipliziert wird mit einem Grund-Zeitintervall. So handelt es sich beispielsweise um ein bestimmtes Grund-Zeitintervall von 15 Sekunden, welches multipliziert wird mit einer beispielsweise 3 Bit-Zufallszahl bzw. Zufallszahlsbereich einer Zufallszahl 273. Die Zufallszahl 273 selbst könnte zyklisch und/oder zufällig aktualisiert werden. Alternativ könnte die Zufallszahl 273 steuergerätespezifisch bzw. fahrzeugspezifisch individuell vergeben werden beispielsweise in der Produktion und Fertigung. Alternativ könnte ein bestimmter Bereich der Zufallszahl 273 ausgewählt werden, auf dessen Basis der Faktor in Abhängigkeit von dem Bereich der Zufallszahl 273 gebildet wird.
  • Sobald ein neues selektiertes Ereignis 226 auftritt und ein Abspeichern im nichtflüchtigen Speicher 208 möglich ist, werden die selektierten Ereignisse 226 nichtflüchtig abgespeichert. Darüber hinaus wird ein Abspeichern der selektierten Ereignisse 226 (im Speicher 206) und/oder weitere Informationen wie bestimmte Zählerstände 232 des Ereigniszählers 204 in dem nichtflüchtigen Speicher 208 eingeleitet, wenn ein Zustandswechsel (der auch durch einen Angreifer hervorgerufen worden sein könnte) des Steuergeräts zu einem Verlust des gegenwärtigen RAM-Inhalts (und damit dem Verlust des Pufferspeichers 206) beispielsweise durch einen angeforderten Reset oder Ruhemodus ansteht.
  • Die Daten sollen in redundanter Art und Weise gespeichert werden, um ein Wiederherstellen möglich zu machen, selbst dann, wenn ein Teil der Daten korrumpiert war. Die Authentizität und Integrität der gespeicherten Daten soll überprüft bzw. sichergestellt werden nach dem Auslesen aus dem nichtflüchtigen Speicher 208. Bevorzugt ist der nichtflüchtige Speicher 208 in einer vertrauenswürdigen Zone angeordnet. Es wird dabei davon ausgegangen, dass der IC-interne Speicher als vertrauenswürdig (Trusted) eingestuft wird. Ein Standard-AUTOSAR NVM (Non Volatile Memory)-Handler könnte hierfür eingesetzt werden.
  • In 5 ist beispielhaft ein Zustandsgraph zum Abspeichern von selektierten Ereignissen 226 im nichtflüchtigen Speicher 208 gezeigt. In einem Zustand 264 ist das Abspeichern von Daten im nichtflüchtigen Speicher 208 grundsätzlich möglich, wenn dieser Zustand 264 erreicht wird. In einem Zustand 266 ist ein Abspeichern im nichtflüchtigen Speicher 208 nicht möglich. Ein Wechsel vom Zustand 264 in den Zustand 266 erfolgt nach durchgeführtem Abspeichern. Ein Wechsel zurück in den Zustand 264, in dem ein Speichern möglich ist, erfolgt Zeit-gesteuert. Vorzugsweise ist die Zeit zufallsabhängig wie bereits beschrieben. Das System verbleibt im Zustand 266 (kein Abspeichern), wenn das Steuergerät nicht einen Ruhezustand oder Reset vorbereitet.
  • 7 zeigt eine genauere Darstellung der Komponenten des Ereignismanagers 30. In dem Pufferspeicher bzw. Speicher 206 sind mehrere Ereignisse 226 abgespeichert und bilden den gefüllten Speicherbereich 252. Beispielhaft wurden ein Ereignis Nr. 2 (226.2), ein Ereignis Nr. 4 (226.4), ein Ereignis Nr. 8 (226.8), ein Ereignis Nr. 13 (226.13), ein Ereignis Nr. 25 (226.25), ein Ereignis Nr. 38 (226.38), ein Ereignis Nr, 77 (226.77) sowie ein Ereignis Nr. 97 (226.97) als selektierte Ereignisse 226 in dem Pufferspeicher 206 abgespeichert. Diese selektierten Ereignisse 226 wurden wie nachfolgend beschrieben nach einer bestimmten Vorgehensweise aus einer Reihe von auftretenden Ereignissen 220 (Nr. 0- bis bspw. 200) ausgewählt und im Pufferspeicher 206 als selektierte Ereignisse 226 abgespeichert.
  • Der nicht gefüllte Bereich bzw. der verbleibende Bereich des Pufferspeichers 206 bildet den freien Speicherbereich 250.
  • Der entsprechende Füllstand 228 der gezeigten Speicherbelegung wird im Ausführungsbeispiel gebildet durch das zuletzt abgespeicherte selektierte Ereignis 226.97. Der Speicherbereich des Pufferspeichers 206 ist nun in mehrere Bereiche 267 bzw. Füllstandsbereiche 267 aufgeteilt zwischen 0 und 100 %. Im Ausführungsbeispiel sind dies beispielsweise zehn (Füllstands)bereiche 267.1-267.10. Im Ausführungsbeispiel sind die Bereiche 267 immer gleich groß gewählt, im Ausführungsbeispiel sind dies 10 %- Intervalle. Im Ausführungsbeispiel weist der Speicher 206 gerade den aktuellen Bereich 267.4, also den vierten Bereich 267.4 auf, der zwischen 30 und 40 % der kompletten Speicherbelegung liegt.
  • Der aktuelle Speicherbereich 267.4, in dem sich der aktuelle Füllstand 228 des Speichers 206 befindet, wird in dem funktionalen Block 268 ermittelt. Der aktuelle Füllstandsbereich 267, im Ausführungsbeispiel 267.4 für den vierten Bereich, gelangt an einen Block 270.
  • In Block 270 wird der Offset 271 für das nächste Ereignis ermittelt. Der Offset 271 gibt an, aus wievielen Ereignissen 220 das nächste im Speicher 206 abzuspeichernde Ereignis 226 ausgewählt werden soll. Diese Anzahl (Offset 271) der Ereignisse 220, aus denen das nächste abzuspeichernde Ereignis 226 insbesondere zufällig ausgewählt werden soll, hängt ab von dem jeweiligen Füllstand 228 bzw. zugehörigen Speicherbereich 267. Bei niedrigem Füllstand 228 bzw. Speicherbereich 267 (der Füllstand 228 des Speichers 206 ist relativ niedrig) werden schneller Ereignisse 20 abgespeichert, also ist der Offset 271 relativ gering. Mit zunehmenden Füllstand 228 bzw. Speicherbereich 267 nimmt der Offset 271 zu, es werden also weniger Ereignisse 220 abgespeichert bzw. es wird nur ein Ereignis 220 aus einer größeren Anzahl (Offset 271) ausgewählt. Dadurch kann gezielt ein Overflow des Speichers 206 hinausgezögert bzw. verhindert werden. Innerhalb eines Offsets 271 erfolgt die zufallsbasierte Auswahl des nächsten abzuspeichernden Ereignisses 226. Pro Offset 271 wird immer nur ein Ereignis 220 (innerhalb des Offsets 271) zufallsbasiert selektiert bzw. abgespeichert. Durch Variation der Offset-Größe in Abhängigkeit des Füllstands 228 des Speichers 206 werden somit im Mittel mehr oder weniger Ereignisse 220 zufallsbasiert selektiert bzw. abgespeichert. Solange sich also der Füllstand 228 des Speichers 206 innerhalb eines bestimmten Bereichs 227 befindet, wählt der Ereignismanager 30 immer aus dem selben zugehörigen Offset 271 ein zu selektiertes Ereignis 226 aus, bis der Füllstand 228 den nächsten Bereich 227 erreicht mit einem veränderten, in der Regel erhöhten Offset 271.
  • Wird der Speicherbereich 267, definiert durch unteren bzw. oberen Grenzwert, verlassen, so kann der nächste Offset 271 für den neuen Bereich erhöht oder erniedrigt werden, beispielsweise um einen bestimmten Faktor bzw. Divisor.
  • Beispielhaft ist ein entsprechendes Szenario in der Tabelle gemäß 8 gezeigt, das zu einer Belegung des Speichers 206 wie in 7 gezeigt führt. Der Offset 271 könnte für die unterschiedlichen Füllstände 228 bzw. Speicherbereiche 267 beispielhaft wie nachfolgend angegeben gewählt werden. So könnte beispielsweise bei dem Speicherbereich zwischen 0 und 10 % (267.1) der Offset 271 zu zwei (von Null bis zwei, die Auswahl erfolgt also aus drei Ereignissen 220), bei dem Speicherbereich zwischen 10 % und 20 % (267.2) zu 8 (von Null bis acht, die Auswahl erfolgt also aus neun Ereignissen 220), für den Speicherbereich zwischen 20 % und 30 % (267.3) 32 (von Null bis 32, die Auswahl erfolgt also aus 33 Ereignissen 220) sowie für den Speicherbereich zwischen 30 % und 40 % zu 128 (von Null bis 128, die Auswahl erfolgt also aus 129 Ereignissen 220) usw. zugeordnet werden. Eine entsprechende Vergrößerung des Offsets 271 für den nächsten Speicherbereich 267 könnte beispielsweise durch einen entsprechenden Faktor (4) oder Ähnliches vorgenommen werden. Sowohl die Speicherbereiche 267 wie auch die Offsetwerte 271 können frei konfiguriert und damit an die jeweilige gewünschte Situation wie beispielsweise Speichergröße etc. angepasst werden.
  • In dem nachfolgenden Block 272 der 7 soll nun das nächste abzuspeichernde Ereignis 220 zufällig (in Abhängigkeit von der Zufallszahl 273 wie in 7 beispielhaft dargestellt) in Abhängigkeit von dem Füllstand 228 bzw. dem Speicherbereich 267 ausgewählt werden. Dabei muss sichergestellt werden, dass der Offset 271, also die Anzahl der Ereignisse 220 bzw. der Bereich der nächsten zu betrachtenden Ereignisse 220, aus denen das jeweilige abzuspeichernde Ereignis 220 zufällig ausgewählt werden soll, von der Zufallszahl 273 bzw. einem entsprechenden Bereich der Zufallszahl 273 abgedeckt werden kann. Abhängig von dem jeweiligen Offset 271 wird die Größe des Bereichs der zu betrachtenden Zufallszahl 273 gewählt. Ist die Zufallszahl 273 beispielsweise Bit-codiert wie in 7 beispielhaft gezeigt, werden beispielsweise für einen Offset 271 von zwei (0-2) zunächst ein vorläufger Bereich der Zufallszahl 273_temp vorläufiger in der Größe von zwei Bits ausgewählt. Bei einem Offset 271 von 8 (0-8) wird ein Bereich x der Zufallszahl 273.x_v in der Größe von 4 Bits ausgewählt. Bei einem Offset 271 von 32 (0-32) wird ein vorläufiger Bereich der Zufallszahl 273_v in der Größe von 6 Bits ausgewählt. Bei einem Offset 271 von 128 (0-128) wird ein vorläufiger Bereich der Zufallszahl 273_v in der Größe von 8 Bits ausgewählt. Der vorläufige Bereich der Zufallszahl 273_v lässt sich Spalte 4 entnehmen, dort beispielhaft angegeben für die konkrete Zufallszahl 273 der 7. Anschließend wird überprüft, ob der in dem vorläufigen Bereich 273_temp enthaltene Abschnitt der Zufallszahl 273 kleiner oder gleich ist als der Offset 271 für den nächsten Speicherbereich 276. Ist dies der Fall, so wird der vorläufige Bereich 273_v auch tatsächlich als Abschnitt der Zufallszahl 273.x als Zufallszahlbereich verwendet. Die entsprechende Abfrage in Spalte 5 kann mit „TRUE“ beantwortet werden. Für diese Fälle stimmen der temporäre Abschnitt der Zufallszahl 273.x_v mit dem ausgewählten Abschnitt der Zufallszahl 273.x überein. Ist dies nicht der Fall (Abfrage in Spalte 5 wird mit „FALSE“ beantwortet), so wird der vorläufige Abschnitt der Zufallszahl 273.x_v verkleinert. Dies kann durch Weglassen eines Bits erfolgen, bevorzugt des höherwertigsten Bits (MSB). Für den sich dann ergebenden Wert der Zufallszahl in diesem Bereich 273.x kann nun sichergestellt werden, dass dieser Wert innerhalb des Offsets 271 für den nächsten Speicherbereich 267 liegt.
  • So werden beispielsweise für einen Offset 271 von 8 (0-8) zunächst 4 Bits der Zufallszahl 273 betrachtet, um auch die Zahl 8 selbst (Größe des aktuellen Offsets 271) abzudecken, vgl. hierzu Spalten mit Puffereinträgen Nr. 3, 4, 5 in 8. Ist der 4 Bit große Wert des zugehörigen vorläufigen Zufallszahl-Bereichs 273.5_v <= der Offset 271 - bspw. Ereignis Nr. 25, 273.5 = 0b0111 = 7, dann wird diese 4 Bit Zahl direkt verwendet. Die zugehörige Abfrage zeigt Spalte 5 der 8. Da die Bedingung erfüllt ist, ist das Ergebnis „TRUE“.
  • Ist der 4 Bit große Wert des zugehörigen vorläufigen Zufallszahl-Bereichs 273.4_v > der Offset 271 - bspw. Ereignis Nr. 13, 273.4 = 0b1100 = 12, dann wird diese 4 Bit-Zahl nicht direkt verwendet, sondern das MSB (höchstwertiges Bit für den betrachteten Bereich der Zufallszahl 273.4) abgeschnitten und die daraus resultierende 3 Bit-Zahl 0b100 = 4 verwendet. Das abgeschnittene MSB muss nicht weggeworfen werden, sondern geht als LSB (niederwertigstes Bit) des nächsten zu betrachtenden Bereichs der Zufallszahl 273.5_v ein. Die zugehörige Bedingung (ist der entsprechende Zufallszahlbereich 273.3 <= Offset 271) ist in diesem Fall nicht erfüllt (zugehöriges Ergebnis „FALSE“ in Spalte 5). Durch diese Vorgehensweise kann sichergestellt werden, dass die Zufallszahl 273 komplett verwendet und nicht unnötig schnell verbraucht wird.
  • Für die Ermittlung der Größe des Zufallszahlbereichs 273.x (bspw. der Anzahl der benötigten Bits für den Bereich der Zufallszahl 273) ist zu berücksichtigen, ob die Größe (bswp. die Anzahl der benötigten Bits) zur Darstellung der Größe des Offsets 271 des zugehörigen Speicherbereichs 267 des nächsten Ereignisses 220 ausreicht.
  • Beim Ausführungsbeispiel gemäß 8 wird also gemäß Zeile 1 bei dem Offset 271 von 2 (von 0-2) bei der ausgewählten Zufallszahl 273.1 von 2 also Ereignis Nr. 2 (220.2, globaler Ereigniszähler 285 beträgt 2) (nach Verwerfen der Ereignisse 220.0, 220.1 Nr.0 und Nr.1) als selektiertes Ereignis 226.2 ausgewählt. Gemäß Zeile 2 wird beim nächsten Offsetbereich 271 (immer noch bei 0-2) zufällig Ereignis Nr. 1 bezogen auf diesen Offsetbereich 271 ausgewählt. Ereignis Nr. 0 in diesem Offsetbereich 271 wurde verworfen (entspräche dem globalen Zählerstand 285 von 3), jedoch Ereignis Nummer 1 in diesem Offsetbereich 271 wurde selektiert (entspricht dem globalen Zählerstand 285 von 4, ergibt selektiertes Ereignis 226.4). Der nächste Offsetbereich 271 liegt gemäß Zeile 3 immer noch bei 2 (0-2), da der Füllstand 267 des Puffers 206 immer noch im Bereich 267.1 zwischen 0 und 10 % liegt. Die Zufallszahl für 273.3 liegt bei 2, sodass nach Verwerfen der Ereignisse Nummer 0 und 1 in diesem Offsetbereich 271 das Ereignis Nr. 2 selektiert wird (globaler Zählerstand 285 bei 8, selektiertes Ereignis 226.8). Da sich anschließend der Füllstand 267 im nächsten Füllstandsbereich 267.2 befindet, verändert sich der neue Offset 271 nun auf 8 (0-8). Wie oben beschrieben werden nun die nächsten 4 Bits des vorläufigen Zufallszahlbereichs 273.4_v betrachtet. Da die zugehörige Zufallszahl des vorläufigen Zufallszahlbereichs 273.4_v mit 12 größer ist als der aktuelle Offset 271 (Abfrage 12<=8 in Spalte 5 ergibt „FALSE“) wird das höchstwertige Bit des vorläufigen Zufallszahlbereichs 273.4_v nicht verwendet, sondern lediglich die niederwertigen 3 Bits im Rahmen des ausgewählten Zufallszahlbereichs 273.4 (binär 100, also 4). Somit werden für diesen neuen Offsetbereich 271 von 8 (0-8) die Ereignisse Nr. 0 (globaler Zählerstand 285 ist 9) bis Nr. 3 verworfen und Ereignis Nummer 4 (globaler Zählerstand 285 ist somit 13) als selektiertes Ereignis 226.13 ausgewählt. Beispielhaft stellt 8 die entsprechenden Werte für weitere Füllstände 267 zusammen.
  • In Block 272 wurde also nun zufallsabhängig ermittelt, welches Ereignis 220 als nächstes ausgewählt wird als selektiertes Ereignis 226. Der entsprechende Block 280 überwacht nun das Auftreten neuer Ereignisse 220 (Block 284). Vorher festgelegt wurde beispielsweise das nach dem abgespeicherten Ereignis 226.8 (8. Ereignis) als nächstes das Ereignis 226.13 (13. Ereignis) abgespeichert werden soll. Block 280 wartet also auf das Ereignis Nr. 13, verwirft also die nächsten Ereignisse Nr. 9-12 und speichert erst Ereignis Nr. 13 als selektiertes Ereignis 226.13 im Speicher 206 ab. Abhängig von dem neuen selektierten Ereignis 226 mit einer Datengröße der Metadaten 215 (ereignisabhängige Metadaten 216 und generische Metadaten 217) wird der neue Füllstand 228 des Speichers 206 ermittelt. Dies könnte beispielsweise besonders einfach unter Verwendung der Länge 232 wie bereits in den Metadaten 215 enthalten erfolgen.
  • Die Zufallszahl 273 ist für unterschiedliche Steuergeräte bzw. Fahrzeuge 18 unterschiedlich zu wählen. So könnte die Zufallszahl 273 beispielsweise in der Produktion einmalig fahrzeugindividuell bzw. steuergeräteindividuell vergeben werden. Alternativ könnte die Zufallszahl 273 intern nach bestimmten Regeln selbst neu generiert werden. Die Neugenerierung könnte beispielsweise bei Übergängen von Systemzuständen (beim Booten, Reset, Überführen in einen Schlafmodus etc.) und/oder zyklisch nach bestimmten Zeiten erfolgen.
  • Aus den entsprechenden Informationen ermittelt der Block 272 den nächsten Ereignis-Treffer 278 (next event hit: der nächste Ereignistreffer 278 im nächsten Offset 271). Der nächste Ereignis-Treffer 278 gelangt an einen Block 280 (throw the dice), in dem zufallsbasiert das zugeführte Ereignis 220 entweder verworfen (Ereignis 220 wird nicht im Pufferspeicher 206 abgespeichert) oder ausgewählt wird als selektiertes Ereignis 226 zum Abspeichern im Pufferspeicher 206. Sofern die Auswahl erfolgt (Ereignis-Treffer 282, event hit) schließt sich Block 284 an. Block 284 wird bei jedem Ereignis 220 aufgerufen. Block 284 selbst ruft jedoch (bei jedem Ereignis 220) Block 280 auf, welcher Rückmeldung an Block 284 gibt, ob das Ereignis 220 selektiert werden soll oder nicht. Falls das Ereignis 220 durch Block 280 selektiert wurde, dann triggert Block 284 das Speichern des Ereignisses 220 im Speicher 206 als selektiertes Ereignis 226.
  • In Block 284 (on event) erfolgt das Einlesen des ausgewählten Ereignisses 220 zum anschließenden Abspeichern in dem freien Bereich 250 des Pufferspeichers 206 als selektiertes Ereignis 226. Block 284 wird immer bei jedem neu eingehenden Ereignis 220, 221 aufgerufen. Block 284 dient der zufälligen Auswahl inklusive möglicher Reduktion und Priorisierung eingehender Ereignisse 220, 221.
  • Neben der zufallsbasierten Auswahl in Block 280 kann darüber hinaus eine zufallsabhängige Reduzierung des Ereignisses 220 erfolgen wie beispielsweise bereits mit den ETH Sensoren 26 beschrieben. So kann zufallsabhängig ein bestimmter Datenbereich (Beginn eines vorzugsweise festen Datenbereichs oder Ende eines Datenbereich) ausgewählt werden. Ebenso könnten nur bestimmte reduzierte Adressdaten abgespeichert werden.
  • Ebenso könnte bei einem hohen Aufkommen von Ereignissen 220 oder generell der Sensor 24, 26, 28 selbst (bei einer bestimmten Quelle, beispielsweise Ethernet) Ereignisse 220 selektieren bzw. reduzieren, quasi eine Vor-Filterung analog zum Ereignismanager 30, um den Ereignismanager 30 (bei dem auch Ereignisse 220 anderer Quellen eingehen) zu entlasten. Falls der Sensor 24, 26, 28 bereits einzelne Ereignisse 220 nicht an den Ereignismanager 30 weiterleitet, sollte dies ebenfalls als eigene Ereignisart 218 an den Ereignismanager 30 kommuniziert werden (analog des Reduktionsstatus 225 im Ereignismanager 30). Generell könnte jedoch die ereignisabhängige Selektierung von Ereignissen 220 im Sensor 24,26, 28 selbst erfolgen und in einem Pufferspeicher des Sensors 24, 26, 28 abgelegt werden. Entsprechende Zähler können ebenfalls auch im im Sensor 24, 26, 28 für die jeweiligen Ereignisarten 218 vorgesehen werden, die bei Bedarf an den Ereignismanager 30 übermittelt werden könnten. Auch könnten die vom Sensor 24, 26 ,28 selektierten Ereignisse 226' auf Anforderung durch den Ereignismanager 30 an diesen kommuniziert werden zur eventuellen Weiterleitung an die übergeordnete Instanz 34 und/oder das Backend 36. Die in Verbindung mit dem Ereignismanager 30 beschriebenen Vorgehensweisen zur zufälligen Auswahl und/oder Priorisierung können gleichwohl im Sensor 24,26, 28 ablaufen. Gleichwohl können sie lediglich auf die speziellen Daten 211 für die jeweilige Quelle beschränkt sein, der Sensor 24,26, 28 kann also nur sensorspezifische Ereignisse 220 selektieren.
  • Der Kommunikationsadapter 32 könnte zur Erhöhung der Sicherheit eine zufallsbasierte, für einen Angreifer nicht determininistisches und verschleiertes Versenden eines Ereignisberichts 242 zu anderen IDS Instanzen 34 vorsehen.
  • Wie bereits in Verbindung mit 2d beschrieben wird aus in dem Pufferspeicher 206 abgelegten selektierten Ereignissen 226 ein Ereignisbericht 242 generiert. Dieser umfasst die in dem Pufferspeicher 206 abgelegten selektierten Ereignisse 226. 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 und der den Ereignisbericht 242 empfangenden Einheit (IDS Instanz 34, Backend 36 oder Ähnliches) erfolgen. Die Authentifizierungs-Information 256 könnte beispielsweise gebildet werden aus zumindest einem Teil der Daten des Ereignisberichts 242, vorzugsweise aus sämtlichen Daten des Ereignisberichts 242 (mit Ausnahme natürlich der zu bildenden Authentifizierungs-Information 256). Hierzu ist ein entsprechender Algorithmus im Ereignismanager 30 hinterlegt. Zum Zwecke der Authentifizierung kann eine übergeordnete Einheit 34 und/oder das Backend 36 in gleicher Weise aus den entsprechenden Daten des empfangenen Ereignisberichts 242 nach Entschlüsselung die zugehörige Authentifizierungs-Imformation 256' gebildet werden und mit der tatsächlich empfangenen Authentifizierung-Information 256 wie in dem Ereignisbericht 242 übermittelt verglichen werden. Bei Übereinstimmung wird von Authentizität ausgegangen.
  • 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. Selbst wenn sich die für jeden Ereignisbericht 242 verändernde Größe 254 sich beispielsweise nur um 1 Bit unterscheidet, so bewirkt die anschließende Verschlüsselung 258, dass sich der verschlüsselte Ereignisbericht 242 stark (und nicht nur in einem Bit) von dem vorhergehenden Ereignisbericht 242 unterscheidet.
  • So könnten bestimmte Ereignisse 220 zyklisch und verschlüsselt (sowohl mit einer immer veränderten Größe 254 als Teil des Ereignisberichts 242 im Klartext sowie mit der Verschlüsselung 258 des Ereignisberichts 242) im Rahmen des Ereignisbereichts 242 übertragen werden. Doch auch wenn keine neuen Ereignisse 220 vorliegen, könnten sogenannte Dummy-Ereignisse (bestehend bspw. aus Fülldaten 255) 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 34.
  • 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 9-14 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äß 9 selektiert der 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 Kommunikationsadapter 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 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 Kommunikationsadapter 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 erfolgen, wenn die entsprechenden Sicherheitserfordernisse erfüllt sind.
  • Alternativ könnte der Kommunikationsadapter 32 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.
  • 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. Nach Erhalt des Bestätigungssignals 408 generiert der Kommunikationsadapter 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 9 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 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 zur Authentifizierung. 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 10 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 (9) 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 11 gezeigt. Erneut tritt ein weiterer Timer Interrupt für den Kommunikationsadapter 32 auf, Signal 440. Daraufhin sendet der Kommunikationsadapter 32 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 und übersendet den verschlüsselten Ereignisbericht 242 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äß 12 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 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 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. 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 13 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. 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 verschlüsselt und an weitere IDS Instanzen 34 übertragen, Signal 486. 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 14 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 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 und übersendet diesen 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 (12)

  1. Verfahren zur Behandlung einer Anomalie von Daten, insbesondere bei einem Kraftfahrzeug, wobei mindestens ein Sensor (24, 26, 28) zur Anomalieerkennung Daten (211) erhält, wobei der Sensor (24,26, 28) die erhaltenen Daten (211) auf Anomalien untersucht, bei einer erkannten Anomalie in Abhängigkeit der zugehörigen Daten (211) ein Ereignis (220, 221) erzeugt, wobei entschieden wird, ob das Ereignis (220, 221) weiterverarbeitet wird, insbesondere abgespeichert und/oder zumindest teilweise weiterkommuniziert wird.
  2. Verfahren nach Anspruch 1, dadurch gekennzeichnet, dass zufällig entschieden wird und/oder in Abhängigkeit von einer Anzahl eines Auftretens eines Ereignisses (220,221) für eine bestimmte Ereignisart (218) entschieden wird, ob das Ereignis (220,221 weiterverarbeitet wird.
  3. Verfahren nach einem der vorhergehenden Ansprüche, dadurch gekennzeichnet, dass bei einem erstmaligen Auftreten eines Ereignisses (220,221) für eine bestimmte Ereignisart (218) dieses Ereignis (220,221) weiterverarbeitet wird.
  4. Verfahren nach einem der vorhergehenden Ansprüche, dadurch gekennzeichnet, dass für ein Ereignis (220,221) mit einer Ereignisart (218), die zuvor bereits bei einem vorherigen Ereignis (220,221) aufgetreten ist, zufällig entschieden wird, ob das Ereignis (220,221) weiterverarbeitet wird.
  5. Verfahren nach einem der vorhergehenden Ansprüche, dadurch gekennzeichnet, dass für unterschiedliche Ereignisarten (218) die zugehörige Anzahl der jeweils aufgetretenen Ereignisse (220,221) ermittelt wird.
  6. Verfahren nach einem der vorhergehenden Ansprüche, dadurch gekennzeichnet, dass bestimmten Ereignisarten (218) jeweils unterschiedlichen Prioritätsgruppen zugeordnet werden, wobei Ereignisse (220) einer höheren Prioritätsgruppe mit höherer Wahrscheinlichkeit insbesondere zufällig für die weiterverarbeitet werden als Ereignisse (220) mit einer niedrigeren Prioritätsgruppe.
  7. Verfahren nach einem der vorhergehenden Ansprüche, dadurch gekennzeichnet, dass den unterschiedlichen Prioritätsgruppen jeweils bestimmte Offsets (271) bzw. Bereiche zugeordnet sind, aus denen jeweils zumindest ein weiterzuverarbeitendes Ereignis (220) der jeweiligen Prioritätsgruppe ausgewählt wird, wobei der Offset (271) bzw. der Bereich einer Prioritätsgruppe mit höherer Priorität kleiner ist als der Offset (271) bzw. der Bereich einer Prioritätsgruppe mit niedrigerer Priorität.
  8. Verfahren nach einem der vorhergehenden Ansprüche, dadurch gekennzeichnet, dass aus mehreren Ereignissen (220,221) mit derselben Ereignisart (218) und/oder Prioritätsgruppe zufällig entschieden wird, welches dieser Ereignisse (220,221) mit derselben Ereignisart (218) und/oder Prioritätsgruppe weiterverarbeitet wird.
  9. Verfahren nach einem der vorhergehenden Ansprüche, dadurch gekennzeichnet, dass zufällig entschieden wird unter Verwendung einer Zufallszahl (273) und/oder eines Bereiches (273.x) einer Zufallszahl (273), insbesondere einer fahrzeugspezifischen und/oder steuergerätspezifischen Zufallszahl (273).
  10. Verfahren nach einem der vorhergehenden Ansprüche, dadurch gekennzeichnet, dass das weiterzuverarbeitende Ereignis (220,221) zumindest teilweise in einem Speicher (206, 208) abgespeichert wird, insbesondere in einem flüchtigen Speicher (206) oder Pufferspeicher und/oder in einem nichtflüchtigen Speicher (208) und/oder im Rahmen eines Ereignisberichts (242) kommuniziert wird und/oder mit weiteren Informationen, insbesondere generische Metadaten (217) wie beispielsweise die Anzahl der aufgetretenen Ereignisse (220,221), Zeitsignal (274), Anzahl nicht weiterverarbeiteter Ereignisse (220,221), Länge (232) versehen wird.
  11. Verfahren nach einem der vorhergehenden Ansprüche, dadurch gekennzeichnet, dass das weiterzuverarbeitende Ereignis (220,221) aus einer bestimmten Anzahl bzw. Offset (271) von Ereignissen (220,221) zufällig ausgewählt wird.
  12. Verfahren nach einem der vorhergehenden Ansprüche, dadurch gekennzeichnet, dass mehrere Sensoren (24,26, 28) zur Anomalieerkennung vorgesehen sind, die jeweils Daten (211) aus unterschiedlichen Datenquellen (25, 27,29) erhalten, insbesondere ein Kommunikationssystem und/oder ein Host (29) bzw. Microcontroller, wobei jeder der Sensoren (24,26, 28) die erhaltenen Daten (211) auf Anomalien untersucht, bei einer erkannten Anomalie in Abhängigkeit der zugehörigen Daten (211) ein Ereignis (220, 221) erzeugt und das Ereignis (220, 221) an einen Ereignismanager (30) weiterleitet.
DE102020204052.4A 2020-03-28 2020-03-28 Verfahren zur Behandlung einer Anomalie von Daten, insbesondere bei einem Kraftfahrzeug Pending DE102020204052A1 (de)

Priority Applications (4)

Application Number Priority Date Filing Date Title
DE102020204052.4A DE102020204052A1 (de) 2020-03-28 2020-03-28 Verfahren zur Behandlung einer Anomalie von Daten, insbesondere bei einem Kraftfahrzeug
JP2022558499A JP7441326B2 (ja) 2020-03-28 2021-03-15 特に自動車におけるデータの異常を処理するための方法
PCT/EP2021/056573 WO2021197828A1 (de) 2020-03-28 2021-03-15 Verfahren zur behandlung einer anomalie von daten, insbesondere bei einem kraftfahrzeug
CN202180024776.5A CN115398428A (zh) 2020-03-28 2021-03-15 用于处理数据异常的方法，特别是在机动车辆中

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
DE102020204052.4A DE102020204052A1 (de) 2020-03-28 2020-03-28 Verfahren zur Behandlung einer Anomalie von Daten, insbesondere bei einem Kraftfahrzeug

Publications (1)

Publication Number Publication Date
DE102020204052A1 true DE102020204052A1 (de) 2021-09-30

Family

ID=75111568

Family Applications (1)

Application Number Title Priority Date Filing Date
DE102020204052.4A Pending DE102020204052A1 (de) 2020-03-28 2020-03-28 Verfahren zur Behandlung einer Anomalie von Daten, insbesondere bei einem Kraftfahrzeug

Country Status (4)

Country Link
JP (1) JP7441326B2 (de)
CN (1) CN115398428A (de)
DE (1) DE102020204052A1 (de)
WO (1) WO2021197828A1 (de)

Citations (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
DE102018209407A1 (de) 2018-06-13 2019-12-19 Robert Bosch Gmbh Verfahren und Vorrichtung zur Behandlung einer Anomalie in einem Kommunikationsnetzwerk

Family Cites Families (8)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US7219239B1 (en) * 2002-12-02 2007-05-15 Arcsight, Inc. Method for batching events for transmission by software agent
US9027120B1 (en) * 2003-10-10 2015-05-05 Hewlett-Packard Development Company, L.P. Hierarchical architecture in a network security system
CN102246156A (zh) * 2008-10-14 2011-11-16 惠普开发有限公司 在网络系统中管理事件流量
JP5240013B2 (ja) 2009-04-01 2013-07-17 日本電気株式会社 ネットワーク装置、ネットワーク装置の制御方法、及びプログラム
CN106170953B (zh) 2014-04-17 2019-10-18 松下电器（美国）知识产权公司 车载网络系统、网关装置以及不正常检测方法
US10120746B1 (en) * 2016-06-14 2018-11-06 Amazon Technologies, Inc. Throttling system and method
US10129280B2 (en) * 2016-09-14 2018-11-13 Microsoft Technology Licensing, Llc. Modular event pipeline
CN110226310B (zh) 2017-12-01 2022-07-19 松下电器（美国）知识产权公司 电子控制装置、不正当检测服务器、车载网络系统、车载网络监视系统以及方法

Patent Citations (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
DE102018209407A1 (de) 2018-06-13 2019-12-19 Robert Bosch Gmbh Verfahren und Vorrichtung zur Behandlung einer Anomalie in einem Kommunikationsnetzwerk

Also Published As

Publication number Publication date
WO2021197828A1 (de) 2021-10-07
JP2023519911A (ja) 2023-05-15
CN115398428A (zh) 2022-11-25
JP7441326B2 (ja) 2024-02-29

Similar Documents

Publication Publication Date Title
EP3278529B1 (de) Angriffserkennungsverfahren, angriffserkennungsvorrichtung und bussystem für ein kraftfahrzeug
EP3136285B1 (de) Verfahren und speichermodul für sicherheitsgeschützte schreibvorgänge und/oder lesevorgänge auf dem speichermodul
DE102015211451A1 (de) Verfahren zu einem Manipulationsschutz von über ein Bussystem zwischen Systemkomponenten zu übertragenden Nutzdatenpaketen
WO2014206695A1 (de) Datenspeichervorrichtung zum geschützten datenaustausch zwischen verschiedenen sicherheitszonen
DE102016103498A1 (de) Ein Verfahren zum Übermitteln von Daten von einem Sensorbauelement an eine elektronische Steuereinheit, ein Sensorbauelement und eine elektronische Steuereinheit
WO2018077528A1 (de) Erkennung von manipulationen in einem can-netzwerk mittels überprüfung von can-identifiern
DE102017221889A1 (de) Datenverarbeitungseinrichtung, Gesamtvorrichtung und Verfahren zum Betrieb einer Datenverarbeitungseinrichtung oder Gesamtvorrichtung
EP3506144A1 (de) Verfahren und system zum überprüfen einer integrität einer kommunikation
WO2021197823A1 (de) Verfahren zur behandlung einer anomalie von daten, insbesondere bei einem kraftfahrzeug
WO2021197820A1 (de) Verfahren zur behandlung einer anomalie von daten, insbesondere bei einem kraftfahrzeug
DE102016212137A1 (de) Verfahren und Vorrichtung zum Verarbeiten von Signalen aus Nachrichten auf wenigstens zwei Datenbussen, insbesondere CAN-Bussen; vorzugsweise in einem Fahrzeug; sowie System
DE102012210327A1 (de) Verfahren zum Übertragen von Nachrichten in einem Kommunikationssystem, insbesondere eines Fahrzeugs
EP3723007B1 (de) Verfahren und steuersystem zum steuern einer ausführung von transaktionen
DE102020204052A1 (de) Verfahren zur Behandlung einer Anomalie von Daten, insbesondere bei einem Kraftfahrzeug
DE102020204054A1 (de) Vorrichtung zur Behandlung einer Anomalie von Daten, insbesondere bei einem Kraftfahrzeug
DE102020204056A1 (de) Verfahren zur Behandlung einer Anomalie von Daten, insbesondere bei einem Kraftfahrzeug
DE102020204058A1 (de) Verfahren zur Behandlung einer Anomalie von Daten, insbesondere bei einem Kraftfahrzeug
DE102020204057A1 (de) Verfahren zur Behandlung einer Anomalie von Daten, insbesondere bei einem Kraftfahrzeug
EP3871393B1 (de) Verfahren zur überwachung eines datenübertragungssystems, datenübertragungssystem und kraftfahrzeug
DE102020204059A1 (de) Verfahren zur Behandlung einer Anomalie von Daten, insbesondere bei einem Kraftfahrzeug
EP4014424B1 (de) Verfahren zum verarbeiten von telegrammen in einem automatisierungsnetzwerk, automatisierungsnetzwerk, masterteilnehmer und slaveteilnehmer
DE102017204156B3 (de) System und Verfahren zur sicheren Fahrzeugkommunikation
EP3363146B1 (de) Verfahren zur erzeugung eines schlüssels in einer schaltungsanordnung
DE102018221349A1 (de) Verfahren zur Verwaltung eines Speichers
EP3306507B1 (de) Komponente für eine sicherheitskritische funktionskette

Legal Events

Date Code Title Description
R079 Amendment of ipc main class

Free format text: PREVIOUS MAIN CLASS: H04L0012260000

Ipc: H04L0043000000