DE102018122152A1 - Systeme und verfahren zur eindringungserkennung in das netzwerk im fahrzeug - Google Patents

Systeme und verfahren zur eindringungserkennung in das netzwerk im fahrzeug Download PDF

Info

Publication number
DE102018122152A1
DE102018122152A1 DE102018122152.5A DE102018122152A DE102018122152A1 DE 102018122152 A1 DE102018122152 A1 DE 102018122152A1 DE 102018122152 A DE102018122152 A DE 102018122152A DE 102018122152 A1 DE102018122152 A1 DE 102018122152A1
Authority
DE
Germany
Prior art keywords
vehicle
event
resident
event logs
transmitted
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
DE102018122152.5A
Other languages
English (en)
Inventor
Samuel B. KUPFER
Joseph E. Ploucha
Abigail C. SHOCKLEY
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.)
GM Global Technology Operations LLC
Original Assignee
GM Global Technology Operations LLC
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 GM Global Technology Operations LLC filed Critical GM Global Technology Operations LLC
Publication of DE102018122152A1 publication Critical patent/DE102018122152A1/de
Pending legal-status Critical Current

Links

Images

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/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
    • H04L63/1416—Event detection, e.g. attack signature detection
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L12/00—Data switching networks
    • H04L12/28—Data switching networks characterised by path configuration, e.g. LAN [Local Area Networks] or WAN [Wide Area Networks]
    • H04L12/40—Bus networks
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L12/00—Data switching networks
    • H04L12/28—Data switching networks characterised by path configuration, e.g. LAN [Local Area Networks] or WAN [Wide Area Networks]
    • H04L12/40—Bus networks
    • H04L12/40169—Flexible bus arrangements
    • H04L12/40176—Flexible bus arrangements involving redundancy
    • H04L12/40202—Flexible bus arrangements involving redundancy by using a plurality of master stations
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L12/00—Data switching networks
    • H04L12/28—Data switching networks characterised by path configuration, e.g. LAN [Local Area Networks] or WAN [Wide Area Networks]
    • H04L12/46—Interconnection of networks
    • H04L12/4604—LAN interconnection over a backbone network, e.g. Internet, Frame Relay
    • H04L12/462—LAN interconnection over a bridge based backbone
    • H04L12/4625—Single bridge functionality, e.g. connection of two networks over a single bridge
    • 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
    • H04L63/1425—Traffic logging, e.g. anomaly detection
    • 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/1441—Countermeasures against malicious traffic
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W12/00—Security arrangements; Authentication; Protecting privacy or anonymity
    • H04W12/12—Detection or prevention of fraud
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L12/00—Data switching networks
    • H04L12/28—Data switching networks characterised by path configuration, e.g. LAN [Local Area Networks] or WAN [Wide Area Networks]
    • H04L12/40—Bus networks
    • H04L2012/40208—Bus networks characterized by the use of a particular bus standard
    • H04L2012/40215—Controller Area Network CAN
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/01—Protocols
    • H04L67/12—Protocols specially adapted for proprietary or special-purpose networking environments, e.g. medical networks, sensor networks, networks in vehicles or remote metering networks

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Security & Cryptography (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Computer Hardware Design (AREA)
  • Computing Systems (AREA)
  • General Engineering & Computer Science (AREA)
  • Small-Scale Networks (AREA)

Abstract

Systeme und Verfahren zur Eindringungserkennung in das Netzwerk im Fahrzeug, das folgendes beinhaltet: (i) ein Anomalieerkennungsmodul, das konfiguriert ist, um eine oder mehrere Netzwerkmeldungen von einem oder mehrerer Kommunikationsbusse eines Fahrzeugs zu erhalten, die ein oder mehrere mit dem Fahrzeug verbundene Ereignisse beschreiben, und zu erkennen, ob mindestens einige der einen oder mehreren Ereignisse eine Anomalie basierend auf vordefinierten Regeln darstellen, um erkannte anomale Ereignisdaten bereitzustellen; (ii) ein residentes Protokollerzeugungsmodul, das konfiguriert ist, um ein oder mehrere residente Ereignisprotokolle basierend auf den erkannten Anomalie-Ereignisdaten zu erzeugen, worin das eine oder die mehreren residenten Ereignisprotokolle Metadaten umfassen, die einem oder mehreren erfassten anomalen Ereignissen zugeordnet sind; und (iii) ein übertragendes Protokollerzeugungsmodul, das konfiguriert ist, um ein oder mehrere übertragene Ereignisprotokolle basierend auf dem einen oder den mehreren residenten Ereignisprotokollen zu erzeugen, worin jedes der einen oder mehreren übertragenen Ereignisprotokolle einem residenten Ereignisprotokoll entspricht.

Description

  • QUERVERWEIS AUF ZUGEHÖRIGE ANMELDUNGEN
  • Die vorliegende Offenbarung bezieht sich auf die U.S. Anmeldung Nr. 15/700,605 , eingereicht am 11. September 2017. Die gesamten Offenbarungen der vorstehend erwähnten Anmeldungen werden hierin durch Bezugnahme aufgenommen.
  • EINLEITUNG
  • Diese Einführung dient der allgemeinen Darstellung des Kontextes der Offenbarung. Die Arbeit der gegenwärtig genannten Erfinder im Umfang der Beschreibung in diesem Einführungsabschnitt sowie andere Aspekte der Beschreibung, gelten gegenüber der vorliegenden Offenbarung weder ausdrücklich noch konkludent als Stand der Technik.
  • Die vorliegende Offenbarung bezieht sich auf Systeme und Verfahren zum Überwachen von Netzwerken auf potenzielle bösartige Aktivitäten und insbesondere auf Systeme und Verfahren zur Erkennung und Reaktion auf potenzielle Eingriffe innerhalb eines Fahrzeug-Netzwerks.
  • Ein Eindringungserkennungssystem (IDS) ist eine Vorrichtung oder Anwendungssoftware zum Überwachen des Netzwerkverkehrs auf anormale oder bösartige Aktivitäten, die auf Richtlinienverletzungen basieren. Das System kann jede erkannte Aktivität an einen Administrator melden, der entscheiden kann, ob er basierend auf dem Bericht Maßnahmen ergreifen möchte.
  • KURZDARSTELLUNG
  • Bei einem Merkmal ist ein System vorgesehen. Das System kann ein Anomalieerkennungsmodul, ein residentes Protokollerzeugungsmodul und ein übertragenes Protokollerzeugungsmodul beinhalten. Das Anomalieerkennungsmodul kann zum Erhalten einer oder mehrerer Netzwerkmeldungen von einem oder mehrerer Kommunikationsbusse eines Fahrzeugs konfiguriert werden. Die eine oder mehrere Netzwerkmeldungen können ein oder mehrere Ereignisse im Zusammenhang mit dem Fahrzeug beschreiben. Das Anomalieerkennungsmodul ist weiterhin konfiguriert, um zu erkennen, ob zumindest einige der einen oder mehreren Ereignisse eine Anomalie basierend auf den vordefinierten Regeln darstellen, um erkannte Anomalie-Ereignisdaten bereitzustellen. Das residente Protokollerzeugungsmodul kann zum Erhalten der erkannten Anomalie-Ereignisdaten konfiguriert werden und ein oder mehrere residente Ereignisprotokolle basierend auf den erkannten Anomalie-Ereignisdaten erzeugen. Das eine oder die mehreren residenten Ereignisprotokolle können Metadaten beinhalten, die mit einem oder mehreren erkannten anomalen Ereignissen verknüpft sind. Das übertragende Protokollerzeugungsmodul kann konfiguriert werden, um das eine oder die mehreren residenten Protokolle zu erhalten und ein oder mehrere übertragene Ereignisprotokolle basierend auf dem einen oder den mehreren residenten Ereignisprotokollen zu erzeugen. Jedes der einen oder der mehreren übertragenden Ereignisprotokolle kann einem residenten Ereignisprotokoll entsprechen. Darüber hinaus kann das übertragende Protokollerzeugungsmodul konfiguriert werden, um ein oder mehrere übertragene Ereignisprotokolle an ein vom Fahrzeug entferntes Computersystem zu übertragen.
  • In einem Merkmal kann das System auch ein elektronisches Steuergerät (ECU) beinhalten. Das ECU kann einen Speicher beinhalten. Der Speicher kann mindestens eines oder mehrere der residenten Ereignisprotokolle beinhalten. In einem Beispiel des vorhergehenden Merkmals kann das ECU weiterhin konfiguriert werden, um einen Protokollsteuerungsbefehl von dem vom Fahrzeug entfernten Computersystem zu erhalten. Das ECU kann als Reaktion auf das Erhalten des Protokollsteuerungsbefehls mindestens eine der folgenden Maßnahmen durchführen: (i) Löschen von mindestens einem residenten Ereignisprotokoll des einen oder der mehreren residenten Ereignisprotokolle; und/oder (ii) Einstellen einer Speicherzuordnung für mindestens eines der einen oder mehreren residenten Ereignisprotokolle.
  • In einem Merkmal ist das übertragende Protokollerzeugungsmodul des Systems weiterhin konfiguriert, um einen Protokollsteuerungsbefehl von dem vom Fahrzeug entfernten Computersystem zu erhalten. Das übertragende Protokollerzeugungsmodul kann als Reaktion auf das Erhalten des Protokollsteuerungsbefehls mindestens eine der folgenden Maßnahmen durchführen: (i) Übertragen von mindestens einem des einen oder mehreren residenten Ereignisprotokolle an das vom Fahrzeug entfernte Computersystem; (ii) Anpassen von Inhalt von mindestens einem der einen oder mehreren residenten Ereignisprotokolle vor der Übertragung an (iii) Einstellen einer Protokollübertragungsrate, die dem übertragenden Protokollerzeugungsmodul zugeordnet ist, wobei die Protokollübertragungsrate eine Frequenz beschreibt, mit der übertragene Ereignisprotokolle von dem übertragenden Protokollerzeugungsmodul an das vom Fahrzeug entfernte Computersystem übertragen werden; und/oder (iv) Einschränken einer Datengröße von einem oder mehreren der übertragenen Ereignisprotokolle.
  • In einem weiteren Merkmal kann das System ein Abhilfemaßnahmenmodul beinhalten. Das Abhilfemaßnahmenmodul kann konfiguriert werden, um einen Eindringungsreaktionsbefehl von dem vom Fahrzeug entfernten Computersystem zu erhalten. Als Reaktion auf den Eindringungsreaktionsbefehl kann das Abhilfemaßnahmenmodul mindestens eine der folgenden Maßnahmen durchführen: (i) Einschränken der Kommunikationen von mindestens einem der einen oder mehreren Kommunikationsbusse; und/oder (ii) Beleuchten einer Störungsanzeigeleuchte (MIL) des Fahrzeugs.
  • In einem Merkmal kann jedes Ereignisprotokoll des einen oder der mehreren Ereignisprotokolle ein Manifest und einen oder mehrere Ereignisprotokolleinträge beinhalten. Jeder Ereignisprotokolleintrag des einen oder der mehreren Ereignisprotokolleinträge kann einem Verstoß gegen eine oder mehrere der vordefinierten Regeln entsprechen. In einem Beispiel des vorhergehenden Merkmals kann das Manifest (i) eine Softpart-Referenznummer beinhalten, die einen Regelsatz der vordefinierten Regeln identifiziert, denen ein bestimmtes residentes Ereignisprotokoll entspricht; und (ii) eine Zusammenfassung aller Regelverstöße, die eine Gesamtzahl der protokollierten Ereignisse für alle Regelverstöße innerhalb eines bestimmten Regelsatzes beschreibt, der durch die Softpart-Referenznummer definiert ist. In einem weiteren Beispiel des vorhergehenden Merkmals kann jeder der einen oder mehreren Ereignisprotokolleinträge einen oder mehrere der folgenden beinhalten: (i) die vordefinierte Regel, die verletzt wurde; (ii) eine Anzahl von Malen, in denen gegen die vordefinierte Regel verstoßen wurde; (iii) einen Zeitraum, in dem gegen die vordefinierte Regel verstoßen wurde; (iv) die Netzwerkmeldung, die gegen die Regel verstoßen hat; und/oder (v) historische Daten über das Ereignis, wobei die historischen Daten einen oder mehrere Zeitstempel beinhalten können, die einen bestimmten Zeitpunkt, zu dem gegen die Regel verstoßen wurde, und einen Zustand des Fahrzeugs zum Zeitpunkt, zu dem gegen die Regel verstoßen wurde, beschreiben.
  • In einem weiteren Merkmal können eine oder mehrere Netzwerkmeldungen eine oder mehrere der folgenden beinhalten: (i) Controller Area Network-(CAN)-Nachrichten von einem oder mehrerer CAN-Busse des Fahrzeugs und/oder (ii) Ethernet-Nachrichten von einem oder mehrerer Ethernet-Busse des Fahrzeugs.
  • In einem Merkmal können sich die vorgegebenen Regeln zumindest teilweise an den Betriebszustandsparametern des Fahrzeugs orientieren. In einem der vorstehenden Beispiele können die Betriebszustandsparameter des Fahrzeugs mindestens einige der folgenden Parameter beinhalten: (i) Geschwindigkeit des Fahrzeugs; (ii) Betriebsmodus des Fahrzeugs; (iii) Leistungsmodus des Fahrzeugs; (iv) Zustand eines Gangwahlschalters des Fahrzeugs; und/oder (v) Vorhandensein eines Testwerkzeugs in Verbindung mit dem Fahrzeug.
  • In einem weiteren Merkmal kann das System das vom Fahrzeug entfernte Computersystem beinhalten. In einem Beispiel des vorhergehenden Merkmals kann das vom Fahrzeug entfernte Computersystem konfiguriert werden, um ein Bestätigungssignal als Reaktion auf das Empfangen eines gesendeten Ereignisprotokolls vom übertragenden Protokollerzeugungsmodul zu erzeugen und das Bestätigungssignal über einen drahtlosen Kommunikationskanal an das Fahrzeug zu übermitteln.
  • In einem Merkmal kann das Anomalieerkennungsmodul konfiguriert werden, um zu erkennen, ob zumindest einige der einen oder mehreren Ereignisse eine Anomalie basierend auf den vordefinierten Regeln darstellen, indem bestimmt wird, ob eine bestimmte Netzwerkmeldung, die einem bestimmten Ereignis zugeordnet ist, in einem Netzwerk des Fahrzeugs sichtbar ist. In einem Beispiel des vorhergehenden Merkmals kann das Anomalieerkennungsmodul konfiguriert werden, um eine Anomalie zu erkennen, wenn bestimmt wird, dass die Nachricht im Netzwerk des Fahrzeugs sichtbar ist. In einem Beispiel des vorhergehenden Merkmals kann das Anomalieerkennungsmodul konfiguriert werden, um das Fehlen einer Anomalie zu erkennen, wenn bestimmt wird, dass die Nachricht im Netzwerk des Fahrzeugs nicht sichtbar ist.
  • In einem weiteren Merkmal ist jede der einen oder mehreren Netzwerkmeldungen mit entsprechenden Nachrichten-IDs verknüpft. In diesem Merkmal kann das Anomalieerkennungsmodul konfiguriert werden, um zu erkennen, ob zumindest einige der einen oder mehreren Ereignisse eine Anomalie basierend auf den vordefinierten Regeln darstellen, indem bestimmt wird, ob eine der vordefinierten Regeln einer bestimmten Nachrichten-ID entspricht, und als Reaktion darauf, dass eine vordefinierte Regel der bestimmten Nachrichten-ID entspricht, der Vergleich eines zulässigen Zustands, der mit der vordefinierten Regel verknüpft ist, mit einem aktuellen Zustand des Fahrzeugs. In einem Beispiel des vorhergehenden Merkmals kann das Anomalieerkennungsmodul konfiguriert werden, um eine Anomalie zu erkennen, wenn der aktuelle Zustand des Fahrzeugs nicht dem zulässigen Zustand der vordefinierten Regel entspricht. In einem weiteren Beispiel des vorhergehenden Merkmals kann das Anomalieerkennungsmodul konfiguriert werden, um das Fehlen einer Anomalie zu erkennen, wenn der aktuelle Zustand des Fahrzeugs dem zulässigen Zustand der vordefinierten Regel entspricht.
  • In einem Merkmal kann jedes der übertragenen Ereignisprotokolle weniger Metadaten beinhalten als sein entsprechendes residentes Ereignisprotokoll.
  • Weitere Anwendungsbereiche der vorliegenden Offenbarung ergeben sich aus der ausführlichen Beschreibung, den Ansprüchen und den Zeichnungen. Die ausführliche Beschreibung und die spezifischen Beispiele dienen lediglich der Veranschaulichung und schränken den Umfang der Offenbarung nicht ein.
  • Figurenliste
  • Die vorliegende Offenbarung wird verständlicher unter Zuhilfenahme der ausführlichen Beschreibung und der zugehörigen Zeichnungen, worin gilt:
    • 1 ist ein Funktionsblockdiagramm, das ein Beispiel für ein Eindringungserkennungssystem (IDS) darstellt;
    • 2 ist ein Diagramm, das eine exemplarische Datenstruktur für ein residentes Ereignisprotokoll und/oder ein übertragenes Ereignisprotokoll veranschaulicht;
    • 3 ist ein Diagramm, das eine exemplarische Datenstruktur für ein Manifest eines residenten Ereignisprotokolls veranschaulicht;
    • 4 ist ein Diagramm, das eine exemplarische Datenstruktur für ein Manifest eines übertragenen Ereignisprotokolls veranschaulicht;
    • 5 ist ein Flussdiagramm, das ein exemplarisches Verfahren zum Erzeugen eines übertragenen Ereignisprotokolls veranschaulicht;
    • 6 ist ein Flussdiagramm, das ein exemplarisches Verfahren zum Steuern der Verwaltung von Ereignisprotokollen veranschaulicht;
    • 7 ist ein Flussdiagramm, das ein exemplarisches Verfahren zur Beseitigung eines Eindringens in ein Fahrzeugnetzwerk veranschaulicht;
    • 8 ist ein Funktionsblockdiagramm, das ein System und ein entsprechendes Kommunikationsprotokoll zum Durchführen einer Eindringungserkennung im Fahrzeug veranschaulicht;
    • 9 ist ein Flussdiagramm, das ein exemplarisches Verfahren zur Kommunikation zwischen einem Fahrzeug und einem entfernten Computersystem zur Eindringungserkennung im Fahrzeug veranschaulicht;
    • 10 ist eine exemplarische Datenstruktur für einen Speicher zum Speichern von Betriebszustandsparametern eines Fahrzeugs;
    • 11 ist ein Flussdiagramm, das ein Verfahren zur Durchführung einer Anomalieerkennung veranschaulicht;
    • 12 ist ein Flussdiagramm, das ein Verfahren zur Durchführung einer Anomalieerkennung unter Einbeziehung von Betriebszustandsparametern des Fahrzeugs veranschaulicht;
    • 13 ist ein Flussdiagramm, das ein Verfahren zur Durchführung einer Anomalieerkennung basierend auf vordefinierten Regeln bezüglich einer Paketweiterleitungsrichtlinie für ein Controller Area Network (CAN) veranschaulicht;
    • 14 ist ein Flussdiagramm, das ein Verfahren zur Durchführung einer Anomalieerkennung basierend auf vordefinierten Regeln bezüglich einer zulässigen Fahrzeugzustandsrichtlinie darstellt; und
    • 15 ist ein Funktionsblockdiagramm, das ein weiteres Beispiel für ein Eindringungserkennungssystem veranschaulicht.
  • In den Zeichnungen werden dieselben Bezugszeichen für ähnliche und/oder identische Elemente verwendet.
  • AUSFÜHRLICHE BESCHREIBUNG
  • Netzwerkrichtlinien können unter Verwendung von Mustern definiert werden, die mit „schlechtem“ Verhalten und potenziellen Bedrohungen verbunden sind, oder indem statistisch begrenztes „gutes“ Verhalten definiert oder erlernt wird. Im Rahmen von Transportsystemen kann ein Eindringungserkennungssystem (IDS) entwickelt werden, um anormale Netzwerkaktivitäten im Fahrzeug zu identifizieren, die auf ein „Abstimmen“ der Leistung oder die Existenz eines Cyber-Angriffs hinweisen können.
  • Unter Bezugnahme nun auf 1 ist ein IDS 100 dargestellt. Das IDS 100 beinhaltet ein Fahrzeug 102 und ein entferntes Computersystem 104. Obwohl das Fahrzeug 102 jeder geeignete Fahrzeugtyp sein kann, stellt das Fahrzeug 102 im Beispiel von 1 ein Automobil dar. Das Fahrzeug 102 kann drahtlos mit dem entfernten Computersystem 104 über jedes geeignete, in der Technik bekannte drahtlose Netzwerk verbunden werden. In einem Beispiel kann das entfernte Computersystem 104 von einem oder mehreren Servercomputern oder dergleichen implementiert werden.
  • In dem in 1 dargestellten Beispiel beinhaltet das Fahrzeug 102 ein Anomalieerkennungsmodul 108, ein residentes Protokollierungsmodul 110, eine elektronische Steuereinheit 112, ein übertragenes Protokollierungsmodul 114, einen oder mehrere Controller Area Network-(CAN)-Busse 106, einen oder mehrere Ethernet-Busse 142, ein Sanierungsmodul 104 und eine Störungsanzeigeleuchte (MIL) 150. Das entfernte Computersystem 104 beinhaltet ein Eindringungserkennungsmodul 116, ein Eindringungsreaktionsmodul 118 und ein Protokollsteuerungsmodul 120.
  • Im Betrieb kann das System 100 zum Erkennen von Eindringversuchen innerhalb eines Netzwerks des Fahrzeugs 102 wie folgt funktionieren. Das Anomalieerkennungsmodul 108 des Fahrzeugs 102 ist konfiguriert, um eine oder mehrere Netzwerknachrichten 148 von einem oder mehreren Kommunikationsbussen des Fahrzeugs, wie dem/den CAN-Bus(en) 106 und/oder dem/den Ethernet-Bus(en) 142, zu erhalten (d. h. abzuholen oder zu empfangen). Die Netzwerkmeldung(en) 148 können CAN-Nachrichten 128 und/oder Ethernet-Nachrichten 144 beinhalten. Die Netzwerkmeldung(en) 148 können ein oder mehrere Ereignisse im Zusammenhang mit dem Fahrzeug beschreiben. Wie hierin verwendet, kann ein Ereignis jede Aktivität beinhalten, die innerhalb der mechanischen, elektrischen oder Softwaresysteme des Fahrzeugs stattfindet. Als Beispiel und nicht als Einschränkung kann ein Ereignis eine mechanische Fehlfunktion, eine elektrische Fehlfunktion, das Erzeugen einer Meldung oder jede andere Aktivität beinhalten, die möglicherweise auf ein Eindringen in das Netzwerk des Fahrzeugs 102 hindeuten könnte. In einem Beispiel könnte eine mechanische Fehlfunktion eine fehlerhafte Verkabelung in einem Fahrzeug beinhalten.
  • Darüber hinaus ist das Anomalieerkennungsmodul 108 konfiguriert, um zu erkennen, ob mindestens ein Teil des einen oder der mehreren Ereignisse eine Anomalie basierend auf den vordefinierten Regeln 122 darstellt. Ein Ereignis kann als Anomalie erkannt werden, wenn es eine anormale, einzigartige und/oder unerwartete Aktivität im Fahrzeug signalisiert. Das Anomalieerkennungsmodul 108 kann erkennen, ob ein bestimmtes Ereignis eine Anomalie darstellt, indem es Informationen, die das Ereignis beschreiben, mit den vordefinierten Regeln 122 vergleicht, welche die Begrenzungen für anomales und nicht-anomales Verhalten festlegen.
  • Gemäß einigen Beispielen können sich die vorgegebenen Regeln 122 zumindest teilweise basierend auf den Betriebszustandsparametern des Fahrzeugs 102 beziehen. Die Betriebszustandsparameter können beispielsweise (i) die Geschwindigkeit des Fahrzeugs 102, (ii) die Betriebsart des Fahrzeugs 102 (z. B. Teenie-Fahrermodus usw.), (iii) die Leistungsart des Fahrzeugs 102, (iv) den Zustand eines Gangwahlschalters (z. B. „PRNDL“) des Fahrzeugs 102 und/oder (v) das Vorhandensein eines Testwerkzeugs (z. B. eines Diagnosewerkzeugs) in Verbindung mit dem Fahrzeug 102 beinhalten.
  • Gemäß weiteren Beispielen können die vordefinierten Regeln 122 zusätzlich oder alternativ basierend auf einem oder mehreren dem Fahrzeug zugeordneten Netzwerkdesign-Parametern verwendet werden. Die Netzwerkdesign-Parameter können Netzwerk-ID, Nachrichtenübertragungsrate, zugeordnete(s) Netzwerk(e) und/oder Länge der Meldung beinhalten.
  • In einigen Implementierungen ist das Anomalieerkennungsmodul 108 zum Erkennen konfiguriert, ob ein bestimmtes Ereignis eine Anomalie basierend auf den vordefinierten Regeln 122 darstellt, indem bestimmt wird, ob eine bestimmte Netzwerkmeldung, die einem bestimmten Ereignis zugeordnet ist, in einem Netzwerk des Fahrzeugs 102 sichtbar ist. Wenn sich herausstellt, dass die Netzwerkmeldung tatsächlich im Netzwerk des Fahrzeugs sichtbar ist, kann das Anomalieerkennungsmodul 108 gemäß einiger Beispiele eine Anomalie erkennen. Wenn sich herausstellt, dass die Netzwerkmeldung nicht im Netzwerk des Fahrzeugs sichtbar ist, kann das Anomalieerkennungsmodul 108 gemäß einiger Beispiele das Fehlen einer Anomalie erkennen.
  • In einigen Beispielen ist jede der einen oder mehreren Netzwerkmeldungen 148 einer Nachrichten-ID zugeordnet und das Anomalieerkennungsmodul 108 ist zum Erkennen, ob ein bestimmtes Ereignis eine Anomalie basierend auf den vordefinierten Regeln 122 darstellt, indem bestimmt wird, ob eine der vordefinierten Regeln 122 mit einer bestimmten Nachrichten-ID übereinstimmt. Wenn eine vordefinierte Regel einer bestimmten Nachrichten-ID entspricht, ist das Anomalieerkennungsmodul 108 zum Vergleichen eines der vordefinierten Regel zugeordneten zulässigen Zustands mit einem aktuellen Zustand des Fahrzeugs 102 konfiguriert. Wenn der aktuelle Zustand des Fahrzeugs 102 nicht dem zulässigen Zustand der vordefinierten Regel entspricht, kann das Anomalieerkennungsmodul 108 eine Anomalie erkennen. Wenn der aktuelle Zustand des Fahrzeugs 102 jedoch dem zulässigen Zustand der vordefinierten Regel entspricht, kann das Anomalieerkennungsmodul 108 das Fehlen einer Anomalie erkennen.
  • Nachdem bestimmt wurde, dass einige der einen oder mehreren Ereignisse eine Anomalie darstellen, kann das Anomalieerkennungsmodul 108 Anomalie-Ereignisdaten 130 erzeugen, welche die anomalen Ereignisse beschreiben. Das residente Protokollerzeugungsmodul 110 kann die Anomalie-Ereignisdaten 130 zur weiteren Verarbeitung erhalten. Genauer gesagt, kann das residente Protokollerzeugungsmodul 110 zum Erzeugen eines oder mehrerer residenter Ereignisprotokolle 126 basierend auf den erkannten Anomalie-Ereignisdaten 130 konfiguriert werden. Das/die residenten Ereignisprotokoll(e) 126 können Metadaten beinhalten, die mit einem oder mehreren erkannten anomalen Ereignissen verknüpft sind. Die spezifischen Arten der Metadaten, die als Teil eines bestimmten residenten Ereignisprotokolls eingebunden sind, werden in den 2-3 veranschaulicht und im Folgenden näher erläutert.
  • Gemäß einigen Implementierungen kann das Fahrzeug 102 auch ein elektronisches Steuergerät (ECU) 112 beinhalten. Das ECU kann die residenten Ereignisprotokolle 126 vom residenten Protokollerzeugungsmodul 110 beziehen und die residenten Ereignisprotokolle 126 im Speicher 124 ablegen. Obwohl als separates Element des Anomalieerkennungsmoduls 108, des residenten Protokollerzeugungsmoduls 110, des übertragenen Protokollerzeugungsmoduls 1154 und des Fehlerbehebungsmoduls 140 dargestellt, können gemäß einigen Implementierungen eines oder mehrere der vorgenannten Module 108, 110, 114 und 140 als Teil des ECU 112 implementiert werden. So kann beispielsweise das ECU 112 gemäß einigen Implementierungen einen oder mehrere Mikrocontroller beinhalten, die zum Ausführen von ausführbaren Anweisungen im Speicher 124 konfiguriert sind, um einige oder alle Funktionen auszuführen, die den Modulen 108, 110, 114 und 140 zugeordnet sind.
  • Das übertragene Protokollerzeugungsmodul 114 ist konfiguriert, um die residenten Ereignisprotokolle 126 vom ECU 112 zu erhalten und ein oder mehrere übertragene Ereignisprotokolle 132 basierend auf den residenten Ereignisprotokollen zu erzeugen. Jedes einzelne übertragene Ereignisprotokoll kann einem residenten Ereignisprotokoll entsprechen. Ein gegebenes übertragenes Ereignisprotokoll kann einem gegebenen Ereignisprotokoll entsprechen, da das übertragene Ereignisprotokoll einige oder alle Metadaten beinhaltet, die als Teil des Ereignisprotokolls enthalten sind. In einigen Implementierungen kann ein bestimmtes übertragenes Ereignisprotokoll weniger Metadaten beinhalten als das entsprechende residente Ereignisprotokoll. Auf diese Weise können die Datenübertragungskosten, die mit der Übertragung der übertragenen Ereignisprotokolle vom Fahrzeug 102 zum entfernten Computersystem 104 verbunden sind, minimiert werden. Gemäß einigen Implementierungen kann die Menge der gemeinsamen Daten, die ein übertragenes Ereignisprotokoll mit dem entsprechenden residenten Ereignisprotokoll teilt, basierend beispielsweise auf den Befehlen des entfernten Computersystems 104 variieren, wie im Folgenden näher erläutert wird. In einigen Beispielen kann ein bestimmtes übertragenes Ereignisprotokoll alle Metadaten beinhalten, die in dem entsprechenden residenten Ereignisprotokoll enthalten sind.
  • Das Modul zum Erzeugen des übertragenen Ereignisprotokolls ist weiterhin so konfiguriert, dass es das/die übertragene(n) Ereignisprotokoll(e) 132 zur weiteren Verarbeitung an das entfernte Computersystem 104 überträgt.
  • Das Eindringungserkennungsmodul 116 des entfernten Computersystems 104 ist konfiguriert, um die übertragenen Ereignisprotokolle 132 von dem übertragenen Ereignisprotokoll-Erzeugungsmodul 114 des Fahrzeugs 102 zu erhalten. Nachdem die übertragenen Ereignisprotokolle 132 erhalten wurden, wird das Eindringungserkennungsmodul 116 zum Bestimmen, ob ein Eindringen in das Fahrzeugnetzwerk stattgefunden hat, basierend auf den übertragenen Ereignisprotokollen 132 konfiguriert. Gemäß einigen Beispielen kann das Eindringungserkennungsmodul 116 einen regelbasierten Ansatz zum Ausführen der Eindringungserkennung verwenden, wobei die übertragenen Ereignisprotokolle 132 gemäß den vorgegebenen Regeln und/oder Richtlinien analysiert werden, um ein Eindringen zu erkennen. Gemäß weiteren Beispielen kann das Eindringungserkennungsmodul 116 überwachte oder unbeaufsichtigte maschinelle Lerntechniken verwenden, um ein Eindringen basierend auf dem (den) übertragenen Ereignisprotokoll(en) 132 zu erkennen.
  • Das Eindringungserkennungsmodul 116 ist konfiguriert, um beim Erkennen eines Eindringens Eindringungsdaten 134 zu erzeugen. Die Eindringungserkennungsdaten 134 beinhalten Daten, welche die Art des Eindringens beschreiben. Das Eindringungserkennungsmodul 116 ist weiterhin konfiguriert, um die Eindringungserkennungsdaten 134 zur weiteren Verarbeitung an das Eindringungsreaktionsmodul 118 und das Protokollsteuerungsmodul 120 zu übertragen.
  • Das Eindringungserkennungsmodul 118 ist konfiguriert, um die Eindringungserkennungsdaten 134 zu erhalten und als Reaktion darauf einen Eindringungsbefehl 118 zu erzeugen. Der Eindringungsreaktionsbefehl 136 ist konfiguriert, um das Fahrzeug anzuweisen, einige positive Maßnahmen zu ergreifen, um die Auswirkungen des erkannten Eindringens zu beheben oder zu mildern.
  • Das Abhilfemaßnahmenmodul 140 des Fahrzeugs ist konfiguriert, um den Eindringungsreaktionsbefehl 136 zu erhalten und daraufhin einige Abhilfemaßnahmen durchzuführen. Konkret kann das Abhilfemaßnahmenmodul 140 beispielsweise die Kommunikation von einem oder mehreren Kommunikationsbussen (z. B. einem oder mehreren CAN-Bussen oder einem oder mehreren Ethernet-Bussen) einschränken oder die Beleuchtung einer Störungsanzeige (MIL) 150 verursachen.
  • Das Protokollsteuerungsmodul 120 ist konfiguriert, um die Eindringungserkennungsdaten 134 zu erhalten und daraufhin einen Protokollsteuerbefehl 138 zu erzeugen. Der Protokollsteuerbefehl 138 ist konfiguriert, um das Fahrzeug anzuweisen, die Art und Weise zu definieren und/oder zu ändern, in der die residenten Ereignisprotokolle 126 und/oder die übertragenen Ereignisprotokolle 132 gespeichert, erzeugt, übertragen usw. werden.
  • Gemäß einigen Implementierungen ist das ECU 112 zum Erhalten des Protokollsteuerbefehls 138 und zum Ausführen einer oder mehrerer der folgenden Maßnahmen konfiguriert: (i) Löschen von mindestens einem residenten Ereignisprotokoll des einen oder der mehreren residenten Ereignisprotokolle 126 aus dem Speicher 124 und/oder (ii) Anpassen einer Speicherzuordnung im Speicher 124 für mindestens eines der einen oder mehreren residenten Ereignisprotokolle 126.
  • Gemäß einigen Beispielen ist das übertragene Protokollerzeugungsmodul 114 konfiguriert, um den Protokollsteuerbefehl 138 zu erhalten und eine oder mehrere der folgenden Maßnahmen zu ergreifen: (i) Übertragen von mindestens einem des einen oder mehreren residenten Ereignisprotokolle 126 an das entfernte Computersystem 104; (ii) Einstellen des Inhalts von mindestens einem der einen oder mehreren residenten Ereignisprotokolle 126 vor der Übertragung an das entfernte Computersystem 104; (iii) Einstellen einer Protokollübertragungsrate, die dem übertragenen Protokollerzeugungsmodul 114 zugeordnet ist, wobei die Protokollübertragungsrate eine Frequenz beschreibt, mit der übertragene Ereignisprotokolle 132 von dem übertragenen Protokollerzeugungsmodul 114 an das entfernte Computersystem 104 übertragen werden; und/oder (iv) Einschränken einer Datengröße von einem oder mehreren der übertragenen Ereignisprotokolle 132.
  • Unter Bezugnahme auf 2 wird nun eine exemplarische Datenstruktur 200 für ein residentes Ereignisprotokoll und/oder ein übertragenes Ereignisprotokoll dargestellt. Gemäß einigen Beispielen können residente Ereignisprotokolle und übertragene Ereignisprotokolle im Allgemeinen die gleiche Datenstruktur aufweisen. In vielen Fällen beinhalten die übertragenen Ereignisprotokolle jedoch weniger Daten als die entsprechenden residenten Ereignisprotokolle, um unter anderem die Kosten für die Übertragung von Informationen über ein oder mehrere drahtlose Netzwerke an ein entferntes Computersystem zu verringern. Die Datenstruktur 200 beinhaltet ein Manifest 202 mit einer zyklischen Redundanzprüfung (CRC) 204 und ein Ereignisprotokoll 206 mit einem oder mehreren Ereignisprotokolleinträgen. Das Manifest 202 kann Angaben zur Datenstruktur 200 sowie Angaben darüber beinhalten, ob ein neues Ereignis eingetreten ist. Der CRC 204 kann einen Prüfwert basierend auf dem Rest einer Polynomteilung deren Inhalts beinhalten, wodurch die Datenstruktur 200 teilweise oder vollständig wiederhergestellt werden kann, wenn bei der Übertragung der Datenstruktur 200 Fehler auftreten. Jeder Ereignisprotokolleintrag kann Details über einen Verstoß gegen eine oder mehrere vordefinierte Regeln beinhalten (z. B. die vordefinierten Regeln 122 von 1).
  • Jeder Ereignisprotokolleintrag kann eine nicht eingehaltene Regel-ID 208, einen Gesamtverstoßzähler 210, einen aufgetretenen Zeitrahmenverstoß 212, eine Netzwerkmeldung, welche gegen die Regel 214 verstoßen hat, und historische Daten 216 beinhalten. Der Abschnitt der nicht eingehaltenen Regel-ID 208 eines bestimmten Ereignisprotokolleintrags kann eine Identifizierung einer bestimmten Regel beinhalten, gegen die aus einer Vielzahl von Regeln verstoßen wurde, die zusammen eine Regelrichtlinie bilden. Der Teil des Gesamtverstoßzählers 210 eines bestimmten Ereignisprotokolleintrags kann einen Zähler beinhalten, der die Anzahl der Verstöße gegen die betreffende Regel wiedergibt. Der aufgetretene Zeitrahmenverstoß 212 kann sowohl (i) einen ersten Zeitstempel (z. B. im koordinierten Universalzeitformat (UTC)) beinhalten, der ein erstes Mal anzeigt, dass der Regelverstoß aufgetreten ist, als auch (ii) einen zweiten Zeitstempel (z. B. im koordinierten Universalzeitformat (UTC)), der ein letztes Mal anzeigt, dass der Regelverstoß aufgetreten ist. Die Netzwerkmeldung, die gegen den Teil der Regel 214 eines bestimmten Ereignisprotokolleintrags verstoßen hat, kann eine Identifikation (z. B. eine Nachrichten-ID) beinhalten, die auf eine bestimmte Netzwerkmeldung hinweist, die gegen die betreffende Regel verstoßen hat. Abschließend kann der Abschnitt mit den historischen Daten 216 eines gegebenen Ereignisprotokolleintrags Informationen beinhalten, die eine historische Zeitleiste für die fragliche Regelverletzung bereitstellen, einschließlich, aber nicht beschränkt auf, (1) einen Zeitstempel für eine Netzwerkmeldung, der einen Hinweis auf eine Zeit bereitstellt, zu der die fragliche Regel verletzt wurde, (2) eine Nachrichten-ID, welche die Netzwerk-ID identifiziert, wobei die fragliche Nachricht im Netzwerk des Fahrzeugs zu sehen war, und (3) Fahrzeugzustandsinformationen einschließlich Fahrzeugstatusparameter zum Zeitpunkt, zu dem die fragliche Regel verletzt wurde.
  • 3 veranschaulicht ein Beispiel einer Datenstruktur für ein residentes Ereignisprotokoll-Manifest 300. Das residente Ereignisprotokoll-Manifest 300 beinhaltet einen Regelsatz 302 und neu protokollierte Ereignis-Highlights 306. Der Regelsatz 302 beinhaltet eine Soft-Part-Referenznummer 304. Die Softpart-Referenznummer 304 kennzeichnet einen Regelsatz, dem das residente Ereignisprotokoll entspricht. In einem Beispiel, in dem der Regelsatz einen kalibrierungsbasierten Regelsatz darstellt, kann die Softpart-Referenznummer 304 eine zugehörige Kalibrierdateinummer beinhalten. In einem Beispiel, in dem der Regelsatz eine Datenmenge darstellt, die in einem anwendungscodebasierten Regelsatz enthalten ist, kann die Softpart-Referenznummer 304 einen Verweis auf die entsprechende Anwendungscode-Teilenummer beinhalten. Die neu protokollierten Ereignis-Highlights 306 beinhalten eine Gesamtanzahl von Regelverstößen 308. Die Gesamtanzahl der Regelverstöße 308 beinhaltet eine Zusammenfassung der Gesamtanzahl der protokollierten Vorfälle für alle Regelverstöße innerhalb eines durch die Softpart-Referenznummer 304 definierten Regelsatzes.
  • 4 veranschaulicht ein Beispiel einer Datenstruktur für ein übertragenes Ereignisprotokoll-Manifest 400. Das übertragene Ereignisprotokoll-Manifest 400 beinhaltet eine Protokolltypkennung 402, einen Regel satz 410, ein Zeitfenster 412, eine Fahrzeugkennung 422 und einen CRC 424.
  • Die Protokolltypkennung 402 beinhaltet die Nachrichtentypinformation 404 und die Protokollformatinformation 406. Die Nachrichtentypinformation 404 beinhaltet die Identifikation einer Funktion einer bestimmten Nachricht. Gemäß einigen Beispielen kann der Nachrichtentyp 404 die fragliche Meldung als (i) reserviert kennzeichnen, (ii) ein Ereignisprotokoll von einem bestimmten Kern eines bestimmten Mikrocontrollers widerspiegeln, (iii) ein Nicht-Ereignisprotokoll (z. B. eine Meldung) von einem bestimmten Kern eines bestimmten Mikrocontrollers oder, weiter gefasst, als einfach von einem bestimmten Mikrocontroller stammend, (iv) ein Nicht-Ereignisprotokoll (z. B. eine Meldung) von einem vom Fahrzeug entfernten Computersystem widerspiegeln, und (v) ein Zustandsprotokoll wiedergeben. Die Protokollformatinformation 406 definiert ein Format für die in der Nachricht eingebundenen Daten.
  • Der Regelsatz 410 beinhaltet eine Softpart-Teilenummer 408. Die Softpart-Teilenummer 408 identifiziert einen Regelsatz, dem das übertragene Ereignisprotokoll entspricht. In einem Beispiel, in dem der Regelsatz einen kalibrierungsbasierten Regelsatz darstellt, kann die Softpart-Teilenummer 408 eine zugehörige Kalibrierdateinummer beinhalten. In einem Beispiel, in dem der Regelsatz eine Datenmenge darstellt, die in einem anwendungscodebasierten Regelsatz enthalten ist, kann die Softpart-Teilenummer 408 einen Verweis auf die entsprechende Anwendungscode-Teilenummer beinhalten.
  • Das Zeitfenster 412 beinhaltet eine StartRecord-Zeit 414 und eine nächste StartRecord-Zeit 416. Die StartRecord-Zeit 414 kann einen Zeitstempel (z. B. im UTC-Format) beinhalten, der den Startpunkt für das übertragene Ereignisprotokoll angibt. Die nächste StartRecord-Zeit 416 kann einen Zeitstempel (z. B. im UTC-Format) beinhalten, der den Startpunkt für das nächste übertragene Ereignisprotokoll angibt, das zum Übertragen an das entfernte Computersystem vorgesehen ist.
  • Die Fahrzeugkennung 422 beinhaltet eine VIN-Nummer 418 und eine eindeutige ID-Nummer 420. Die VIN-Nummer 418 identifiziert das Fahrzeug, welches das übertragene Ereignisprotokoll, auf das sich das Manifest 400 bezieht, übertragen hat. Die eindeutige ID-Nummer 420 identifiziert ein ECU des Fahrzeugs, welches das übertragene Ereignisprotokoll, auf das sich das Manifest 400 bezieht, übertragen hat.
  • Abschließend kann der CRC 424 einen Prüfwert basierend auf dem Rest einer Polynomteilung deren Inhalts beinhalten, wodurch ein Teil oder das gesamte übertragene Ereignisprotokoll-Manifest 400 wiederhergestellt werden kann, wenn bei der Übertragung des Manifests 400 Fehler auftreten.
  • Unter Bezugnahme auf 5 wird nun ein Flussdiagramm bereitgestellt, das ein Verfahren 500 zum Erzeugen eines übertragenen Ereignisprotokolls gemäß den hierin aufgeführten Beispielen veranschaulicht. Das Verfahren 500 beginnt bei 502, wobei eine oder mehrere Meldungen von einem oder mehreren Kommunikationsbussen eines Fahrzeugs empfangen werden. Die eine oder mehrere Meldungen können ein oder mehrere Ereignisse im Zusammenhang mit dem Fahrzeug beschreiben. Bei 504 beinhaltet das Verfahren 500 das Erkennen, ob zumindest einige der Ereignisse basierend auf vordefinierten Regeln eine Anomalie darstellen, um erkannte Anomalieereignisdaten bereitzustellen. Bei 506 werden ein oder mehrere residente Ereignisprotokolle basierend auf den ermittelten Anomalieereignisdaten erzeugt. Das eine oder die mehreren residenten Protokolle können Metadaten beinhalten, die sich auf erkannte anomale Ereignisse beziehen. Abschließend werden bei 508 ein oder mehrere übertragene Ereignisprotokolle basierend auf den residenten Ereignisprotokollen erzeugt. Jedes der übertragenen Ereignisprotokolle kann einem residenten Ereignisprotokoll entsprechen. Darüber hinaus kann gemäß einigen Implementierungen jedes der übertragenen Ereignisprotokolle weniger Metadaten beinhalten als das jeweilige residente Ereignisprotokoll. Im Anschluss an 508 wird das Verfahren beendet.
  • Unter Bezugnahme auf 6 wird nun ein Flussdiagramm bereitgestellt, das ein Verfahren 600 zum Steuern der Verwaltung von Ereignisprotokollen veranschaulicht. Das Verfahren 600 beginnt bei 502. Die Schritte 502 bis 508 werden im Wesentlichen auf die gleiche Weise durchgeführt, wie in 5 beschrieben. Folglich beinhaltet das Verfahren 600 bei Schritt 602 das Ermitteln, ob ein Protokollsteuerungsbefehl erhalten wurde. Gemäß einem Beispiel kann der Protokollsteuerungsbefehl vom entfernten Computersystem zum Fahrzeug übertragen werden, um die Verwaltung der Ereignisprotokolle zu steuern. Wenn kein Protokollsteuerungsbefehl erhalten wurde, kehrt das Verfahren 600 zu 502 zurück und die Schritte 502 bis 508 können wiederholt werden. Wenn jedoch ein Protokollsteuerungsbefehl erhalten wurde, kann das Verfahren 600 mit einem oder mehreren von 604, 606, 608, 610, 612 und 614 zur weiteren Verarbeitung fortfahren.
  • Im Anschluss an 602 können eine oder mehrere der unter 604, 606, 608, 610, 612 und 614 aufgeführten Maßnahmen durchgeführt werden. Darüber hinaus können eine oder mehrere Maßnahmen nacheinander oder parallel durchgeführt werden. Die unter 604, 606, 608, 610, 612 und 614 beschriebenen Maßnahmen können beispielsweise verschiedene Optionen darstellen, die einem Fahrzeug zur Verfügung stehen, wenn es einen Steuerbefehl vom entfernten Computersystem erhält. Bei 604 können ein oder mehrere residente Ereignisprotokolle aus dem Speicher gelöscht werden (z. B. einem flüchtiger oder nichtflüchtiger Speicher des Fahrzeugs). Bei 606 kann eine Speicherzuordnung für das eine oder die mehreren residenten Ereignisprotokolle angepasst werden. Gemäß einem Beispiel kann das Anpassen einer Speicherzuordnung auch das Ändern der Speicherung eines oder mehrerer residenter Ereignisprotokolle im physischen oder virtuellen Speicher beinhalten. Bei 608 können ein oder mehrere residente Ereignisprotokolle oder übertragene Ereignisprotokolle vom Fahrzeug zum entfernten Computersystem übertragen werden. Bei 610 kann der Inhalt eines oder mehrerer residenter Ereignisprotokolle oder übertragener Ereignisprotokolle vor dem Übertragen vom Fahrzeug zum entfernten Computersystem angepasst werden. Bei 612 kann eine Protokollübertragungsrate eingestellt werden. Die Protokollübertragungsrate kann eine Frequenz beschreiben, mit der übertragene Ereignisprotokolle vom Fahrzeug zum entfernten Computersystem übertragen werden. Abschließend kann bei 614 eine Datengröße von einem oder mehreren übertragenen Ereignisprotokollen eingeschränkt werden. Im Anschluss an die Durchführung von 604, 606, 608, 610, 612 und 614 wird das Verfahren 600 beendet.
  • Unter Bezugnahme auf 7 ist ein Flussdiagramm bereitgestellt, das ein Verfahren 700 zum Ergreifen von Abhilfemaßnahmen als Reaktion auf das Erkennen eines Eindringens in ein Fahrzeugnetzwerk darstellt. Das Verfahren 700 beginnt bei 502. Die Schritte 502 bis 508 werden im Wesentlichen auf die gleiche Weise durchgeführt, wie in 5 beschrieben. Somit beinhaltet das Verfahren 700, beginnend bei Schritt 702, das Ermitteln, ob ein Eindringreaktionsbefehl zum Beispiel über das Fahrzeug vom entfernten Computersystem erhalten wurde. Wenn kein Eindringreaktionsbefehl erhalten wurde, kehrt das Verfahren 700 zu 502 zurück und die Schritte 502 bis 508 können wiederholt werden. Wenn jedoch ein Eindringreaktionsbefehl erhalten wurde, kann das Verfahren 700 zur weiteren Verarbeitung zu 704 und/oder 706 übergehen.
  • Im Anschluss an 702 können eine oder mehrere der unter 704 und 706 beschriebenen Maßnahmen nacheinander oder parallel durchgeführt werden. Die unter 704 und 706 beschriebenen Maßnahmen können beispielsweise verschiedene Optionen darstellen, die einem Fahrzeug zur Verfügung stehen, wenn es einen Eindringreaktionsbefehl vom entfernten Computersystem erhält. Bei 704 kann die Kommunikation von einem oder mehreren der Kommunikationsbusse (z. B. CAN-Bus(e) und/oder Ethernet-Bus(e)) des Fahrzeugs eingeschränkt werden. Bei 706 kann eine Störungsmeldeleuchte (MIL) aufleuchten. Die leuchtende MIL-Leuchte kann beispielsweise einem Fahrzeuginsassen signalisieren, dass ein Problem mit dem Fahrzeug (z. B. ein Netzwerkeindringling) vorliegt, das seine Aufmerksamkeit erfordert. Im Anschluss an 704 und/oder 706 wird das Verfahren 700 beendet.
  • Nun zu 8, ist ein System 800 und das dazugehörige Kommunikationsprotokoll zur Kommunikation zwischen dem Fahrzeug 102 und dem entfernten Computersystem 104 dargestellt. Das Fahrzeug 102 und das entfernte Computersystem 104 können dem abgebildeten und beschriebenen Fahrzeug 102 und dem entfernten Computersystem 104 in Bezug auf 1 im Wesentlichen ähnlich sein. Das exemplarische Fahrzeug 102 von 8 unterscheidet sich vom exemplarischen Fahrzeug von 1 dadurch, dass das Fahrzeug 102 von 8 mit einem zentralen Gateway-Modul (CGM) 802 und einem drahtlosen Sender 804 dargestellt ist. Das CGM 802 kann einen ersten Mikrocontroller 806 und einen zweiten Mikrocontroller 808 beinhalten. Darüber hinaus kann der erste Mikrocontroller 806 des CGM 802 einen zweiten Kern 810 und einen ersten Kern 812 beinhalten. Gemäß einigen exemplarischen Implementierungen können der zweite Kern 810 und der erste Kern 812 auf einen gemeinsamen, gesicherten Speicher (nicht dargestellt) zugreifen, der unter anderem zum Erzeugen, Speichern und Übertragen von residenten Ereignisprotokollen und/oder übertragenen Ereignisprotokollen verwendet wird.
  • Der zweite Mikrocontroller 808 kann über einen oder mehrere geeignete drahtgebundene oder drahtlose Kommunikationskanäle mit dem drahtlosen Sender 804 verbunden werden. Ähnlich kann der zweite Mikrocontroller 808 über einen oder mehrere geeignete drahtgebundene oder drahtlose Kommunikationskanäle kommunikativ mit dem ersten Mikrocontroller 806 verbunden werden. Der drahtlose Sender 804 ist zur Kommunikation mit dem entfernten Computersystem 104 über ein oder mehrere drahtlose Kommunikationsnetze unter Verwendung eines oder mehrerer geeigneter Kommunikationsprotokolle (z. B. VCP/TCP, usw.) konfiguriert.
  • Gemäß einigen exemplarischen Implementierungen können die Komponenten des Systems 800 wie folgt zusammenarbeiten. Bei 814 kann der zweite Kern 810 des ersten Mikrocontrollers 806 ein übertragenes Ereignisprotokoll erzeugen und an den ersten Kern 812 des ersten Mikrocontrollers 806 übertragen. Der erste Kern 812 des ersten Mikrocontrollers 806 kann anschließend das übertragene Ereignisprotokoll 814 an den zweiten Mikrocontroller 808 weiterleiten. Nach dem Empfangen des übertragenen Ereignisprotokolls 814 kann der zweite Mikrocontroller 808 (i) eine Bestätigung 816 erzeugen, die den erfolgreichen Empfang des übertragenen Ereignisberichts 814 bestätigt; (ii) die Bestätigung 816 an den ersten Kern 812 des ersten Mikrocontrollers 806 übertragen; und (iii) den übertragenen Ereignisbericht 814 an den drahtlosen Sender 804 weiterleiten. Nach dem Empfangen der Bestätigung 816 kann der erste Kern 812 die Bestätigung 816 an den zweiten Kern 810 des ersten Mikrocontrollers 806 weiterleiten.
  • Der drahtlose Sender 804 kann das gesendete Ereignisprotokoll 814 vom zweiten Mikrocontroller 808 empfangen und denselben 814 über ein oder mehrere drahtlose Netzwerke an das entfernte Computersystem 104 weiterleiten. Nach dem Empfangen des gesendeten Ereignisprotokolls 814 vom drahtlosen Sender 804 des Fahrzeugs 102 kann das entfernte Computersystem 104 (i) eine Bestätigung 818 erzeugen, die den erfolgreichen Empfang des gesendeten Ereignisberichts 814 bestätigt; (ii) die Bestätigung 818 an den drahtlosen Sender 804 des Fahrzeugs 102 übertragen; (iii) einen Befehl 820 erzeugen; und den Befehl 820 an den drahtlosen Sender 804 des Fahrzeugs 102 übertragen. Der Befehl 820 kann mindestens einen Protokollsteuerungsbefehl und einen Eindringreaktionsbefehl beinhalten. Sowohl die Bestätigung 818 als auch der Befehl 820 können von dem entfernten Computersystem 104 über Zwischenstationen einschließlich des drahtlosen Senders 804, des zweiten Mikrocontrollers 808 und des ersten Kerns 812 des ersten Mikrocontrollers 806 an den zweiten Kern 810 weitergeleitet werden.
  • Nach dem Empfangen des Befehls 820 kann der zweite Kern 810 des ersten Mikrocontrollers (i) eine Bestätigung 822 erzeugen, die den erfolgreichen Empfang des Befehls 820 bestätigt, und (ii) die Bestätigung 822 an den ersten Kern 812 übertragen. Der erste Kern 812 kann anschließend die Bestätigung 822 über Zwischenstationen einschließlich des zweiten Mikrocontrollers 808 und des drahtlosen Senders 804 an das entfernte Computersystem 104 weiterleiten.
  • Das vorstehend in Bezug auf 8 behandelte System 800 und das Kommunikationsprotokoll bringt mehrere Vorteile im Zusammenhang mit der Eindringungserkennung im Fahrzeug. Zunächst ermöglicht die Architektur des Systems 800 die Isolierung bestimmter Eindringungserkennungsfunktionen (z. B. Anomalieerkennung) von der Netzwerkverbindung, um die Wahrscheinlichkeit eines direkten, Fernangriffs zu verringern. Gemäß einer Implementierung kann beispielsweise die Anomalieerkennung und das Erzeugen eines residenten Ereignisprotokolls/eines übertragenen Ereignisprotokolls vom zweiten Kern 810 durchgeführt werden, der über Zwischenkomponenten, wie beispielsweise den zweiten Mikrocontroller 808 und den drahtlosen Sender 804, kommunikativ von der direkten Kommunikation außerhalb des Fahrzeugs isoliert werden kann. Darüber hinaus ist der erste Mikrocontroller 806 gemäß einigen exemplarischen Implementierungen nicht mit einem Netzwerkstapel ausgestattet, der in der Lage ist, Ereignisprotokolle (z. B. übertragene Ereignisprotokolle) direkt an das entfernte Computersystem 104 zu übertragen. Dies kann die Komplexität und den Aufwand des ersten Mikrocontrollers 806 reduzieren. Vielmehr kann der zweite Mikrocontroller 804 der einzige Mikrocontroller sein, der Teil des CGM 802 ist und einen Netzwerkstapel beinhaltet, der in der Lage ist, Ereignisprotokolle an das entfernte Computersystem 104 zu übertragen (z. B. über den drahtlosen Sender 804). Wenn der erste Mikrocontroller 806 nicht isoliert wird, könnten sowohl die Gate- als auch die Anomalie-Erkennungsfunktionalitäten für direkte Fernangriffe zugänglich gemacht werden. Die Verwendung von Bestätigungen (z. B. die Bestätigungen 818, 818, 822, usw.) verbessert die Zuverlässigkeit des Systems durch die Gewährleistung, dass die Kommunikation (z. B. übermittelte Ereignisprotokolle) ihren Bestimmungsort erreicht. Somit kann die in Bezug auf 8 offenbarte Architektur und das Kommunikationsprotokoll ein End-to-End-Kommunikationssystem 800 bereitstellen, das gemäß einigen Beispielen gewährleistet, dass ein spezifischer Kommunikationsweg bei der Schicht 4 des Open Systems Interconnection (OSI)-Modells verwendet wird, während andere Systeme nur gewährleisten können, dass ein zuverlässiger Weg aus einer Vielzahl von Optionen verwendet wird (der normalerweise bei Schicht 2 des OSI-Modells behandelt wird).
  • Unter Bezugnahme auf 9 veranschaulicht nun ein Flussdiagramm ein Verfahren 900 zur Kommunikation zwischen einem Fahrzeug und einem entfernten Computersystem zum Zwecke der Bereitstellung von Eindringversuchen in das Fahrzeugnetzwerk. Das Verfahren 900 beginnt bei 902, wobei ein übertragenes Ereignis in einem ersten Mikrocontroller erzeugt wird. Bei 904 wird das übertragene Ereignisprotokoll vom ersten Mikrocontroller zum zweiten Mikrocontroller übertragen. Bei 906 wartet der erste Mikrocontroller auf eine Bestätigung des zweiten Mikrocontrollers bezüglich des Empfangs des übertragenen Ereignisprotokolls. Bei 908 wird ermittelt, ob die Bestätigung vom ersten Mikrocontroller durch den zweiten Mikrocontroller empfangen wurde.
  • Wenn keine Bestätigung empfangen wurde, fährt das Verfahren 900 mit 910 fort und es wird ermittelt, ob eine Zeitüberschreitung aufgetreten ist (d. h. ob nach der Übertragung des übertragenen Ereignisprotokolls vom ersten Mikrocontroller zum zweiten Mikrocontroller eine vorbestimmte Zeitspanne verstrichen ist). Wenn eine Zeitüberschreitung aufgetreten ist, kehrt das Verfahren 900 zu 904 zurück und das übertragene Ereignisprotokoll wird erneut vom ersten Mikrocontroller zum zweiten Mikrocontroller übertragen. Wenn keine Zeitüberschreitung aufgetreten ist, kehrt das Verfahren 900 zu 906 zurück und der erste Mikrocontroller wartet auf eine Bestätigung vom zweiten Mikrocontroller.
  • Wenn bei 908 eine Bestätigung durch den ersten Mikrocontroller vom zweiten Mikrocontroller empfangen wurde, fährt das Verfahren 900 mit 912 fort. Bei 912 wartet der zweite Mikrocontroller auf eine Bestätigung vom entfernten Computersystem (z. B. eine Bestätigung, dass das entfernte Computersystem das gesendete Ereignisprotokoll empfangen hat, wie es vom zweiten Mikrocontroller an den ersten Mikrocontroller übermittelt wurde (Schritt nicht in 9 dargestellt)). Bei 914 wird ermittelt, ob die Bestätigung vom entfernten Computersystem durch den zweiten Mikrocontroller empfangen wurde.
  • Wenn keine Bestätigung empfangen wurde, fährt das Verfahren 900 mit 916 fort und es wird ermittelt, ob eine Zeitüberschreitung aufgetreten ist (d. h. ob nach der Übertragung des übertragenen Ereignisprotokolls vom zweiten Mikrocontroller zum entfernten Computersystem eine vorbestimmte Zeitspanne verstrichen ist). Wenn eine Zeitüberschreitung aufgetreten ist, kehrt das Verfahren 900 zu 904 zurück und das übertragene Ereignisprotokoll wird erneut vom ersten Mikrocontroller zum zweiten Mikrocontroller übertragen. Wenn keine Zeitüberschreitung aufgetreten ist, kehrt das Verfahren 900 zu 912 zurück und der zweite Mikrocontroller wartet auf eine Bestätigung vom entfernten Computersystem. Im Anschluss an 914 wird das Verfahren 900 beendet.
  • 10 veranschaulicht eine exemplarische Datenstruktur 1000 für einen Speicher zum Speichern von Betriebszustandsparametern eines Fahrzeugs. Gemäß einigen Beispielen kann die Datenstruktur 1000 in einem oder mehreren Registern gespeichert werden, auf welche die Komponente(n) des Eindringungserkennungssystems zugreifen, die eine Anomalieerkennung durchführen (z. B. das Anomalieerkennungsmodul 108 von 1, der erste Mikrocontroller 806 von 8, usw.). Auf diese Weise können die Parameter des Fahrzeugbetriebszustands zur Bestimmung berücksichtigt werden, ob gegen eine der vordefinierten Regeln, die als Teil der Anomalieerkennung betrachtet werden, verstoßen wurde. Wie dargestellt, kann die Datenstruktur 1000 Bits und/oder Bytes von Daten reservieren, um die folgenden Informationsarten über den Zustand eines Fahrzeugs auszudrücken: (i) ob eine Präsentationsfähigkeit aktiv ist; (ii) ob der Fahrermodus A oder der Fahrermodus B aktiv ist; (iii) ob der Teenager-Fahrermodus aktiv ist; (iv) ob ein Testwerkzeug aktuell mit dem Fahrzeug verbunden ist; (v) ein CGM-Sicherheitszugriffsstatus; (vi) Fahrzeuggeschwindigkeit; (vii) Fahrzeugleistungsmodus; und (viii) Zustand eines Gangwahlschalters (z. B. der „PRNDL“-Zustand).
  • Die Berücksichtigung der vorgenannten Parameter des Fahrzeugbetriebszustands kann beim Erkennen von Anomalien hilfreich sein, indem sie den Kontext um mögliche Regelverletzungen herum darstellt und eine verbesserte Klassifizierung von Netzwerkereignissen ermöglicht. Gemäß einigen Implementierungen kann die Anomalieerkennung boolesche Operationen (z. B. UND/ODER Operationen) integrieren, um flexible logische Ausdrücke zu definieren, die in der Lage sind, Netzwerknachrichten mit Leistungsdesign-Parametern, Nachrichtennutzlast, Fahrzeugbetriebszuständen, Häufigkeit des Auftretens und einer Netzwerkreaktion mit Elementen, die bei der Definition eines Ausdrucks nicht gewünscht werden, durch eine geeignete Schreibweise innerhalb des gesamten logischen Ausdrucks ignoriert werden.
  • Neben anderen Vorteilen kann die Einbeziehung von Betriebszustandsparametern eines Fahrzeugs bei der Durchführung einer Anomalieerkennung (i) die Fähigkeit beinhalten, die Anzahl der Fehlalarme zu reduzieren, die erzeugt werden könnten (d. h. eine Erkennung eines anomalen Ereignisses, wenn das Ereignis nicht tatsächlich anomal war oder nicht tatsächlich ein Eindringen signalisiert hat) und (ii) das Erzeugen von Netzwerk-Eindringungsregeln, die normales Verhalten im Kontext einer anormalen Nutzung zur Unterstützung von Initiativen gegen Fahrzeugdiebstahl und Betrug ermöglichen.
  • Die 11-12 stellen ein Beispiel dafür dar, wie die Berücksichtigung von FahrzeugBetriebszustandsparametern die Anomalie- und Eindringungserkennung verbessern kann. Insbesondere ist 11 ein Flussdiagramm, das ein Verfahren zur Durchführung einer Anomalieerkennung ohne den Vorteil von Fahrzeugbetriebszustandsparametern veranschaulicht, während 12 ein Verfahren zur Durchführung einer Anomalieerkennung unter Verwendung von Fahrzeugbetriebszustandsparametern ist.
  • Im Hinblick auf das Flussdiagramm von 11 beginnt das Verfahren 1100 bei 1102, wobei der Modus 0x28 funktionell vom CAN-Bus 6 gesendet wird. Der Modus 0x28 bezieht sich auf einen vereinheitlichten Diagnosedienst-(UDS-Unified Diagnostic Services)-Zustand, der die Kommunikation auf einem oder mehreren Netzwerkbussen eines Fahrzeugs einschränkt. Bei 1104 übergibt das CGM des Fahrzeugs die CAN-Kommunikation an das Anomalieerkennungsmodul. Bei 1106 erkennt das Anomalieerkennungsmodul, ob die CAN-Kommunikation beispielsweise auf vordefinierten Regeln basiert. Bei 1008 wird im Rahmen der Anomalieerkennung ermittelt, ob der Modus 0x28 von einem Diagnosebus, wie beispielsweise dem CAN-Bus 6 oder dem CAN-Bus 7, ausgeht. Wenn der Modus 0x28 von einem Diagnosebus stammt, fährt das Verfahren 1100 mit 1110 fort, wobei bestimmt wird, dass der Modus 0x28 eine Service-Routine reflektieren könnte und dass kein anomales Verhalten erkannt wird. Im Anschluss an 1110 wird das Verfahren 1100 beendet. Wenn jedoch der Modus 0x28 nicht von einem Diagnosebus stammt, geht das Verfahren 1100 zu 1112 über, wobei bestimmt wird, dass der Modus 0x28 vom CAN 1 stammt und ein anomales Verhalten erkannt wird. Im Anschluss an 1112 wird das Verfahren 1100 beendet.
  • Nun zu 12, ist ein weiteres Verfahren 1200 vorgesehen. Die Schritte 1102 bis 1112 verfahren im Wesentlichen gemäß den Beschreibungen dieser Schritte wie oben in Bezug auf 11. Das Verfahren 1200 beinhaltet jedoch die Verwendung von Fahrzeugbetriebszustandsparametern bei 1202, um die Genauigkeit der Anomalieerkennung zu verbessern. Insbesondere nach der Bestimmung, dass der Modus 0x28 auf einem Diagnosebus bei 1108 entstanden ist, fährt das Verfahren 1200 mit 1202 fort, wobei bestimmt wird, dass der Modus 0x28 eine Service-Routine reflektieren könnte und dass kein anomales Verhalten erkannt wird.
  • Anstatt jedoch nach diesem Schritt zu schließen (wie im Fall des Verfahrens 1100 von 11), fährt das Verfahren 1200 mit 1204 fort, wobei bestimmt wird, ob 0x28 aufgetreten ist, während das Fahrzeuggetriebe im Fahrbetrieb war. Falls dies der Fall ist, fährt das Verfahren 1200 mit 1206 fort, wobei bestimmt wird, dass 0x28 nur dann auftreten soll, wenn sich das Fahrzeuggetriebe im Parkbetrieb befindet, und ein anomales Verhalten erkannt und protokolliert wird. Wenn ermittelt wird, dass 0x28 aufgetreten ist, während das Fahrzeuggetriebe nicht im Fahrbetrieb war, fährt das Verfahren 1200 mit 1208 fort, wobei bestimmt wird, ob 0x28 aufgetreten ist, während die Geschwindigkeit des Fahrzeugs 3 Kilometer pro Stunde (km/h) überschritten hat. (Obwohl 3 km/h der in diesem Beispiel verwendete Schwellenwert ist, werden Personen mit gewöhnlichen Fähigkeiten in diesem Bereich zu schätzen wissen, dass jeder geeignete Geschwindigkeitsschwellenwert als Teil dieses Schrittes einbezogen werden kann, ohne von den hierin dargelegten Lehren abzuweichen).
  • Wenn 0x28 aufgetreten ist, während die Geschwindigkeit des Fahrzeugs 3 km/h überschritten hat, fährt das Verfahren 1200 mit 1210 fort, wobei bestimmt wird, dass 0x28 nur auftreten soll, wenn das Fahrzeug stillsteht, und ein anomales Verhalten erkannt und protokolliert wird. Wenn bestimmt wird, dass 0x28 aufgetreten ist, während die Geschwindigkeit des Fahrzeugs 3 km/h nicht überschritten hat, fährt das Verfahren 1200 mit 1212 fort, wobei bestimmt wird, dass kein anomales Verhalten erkannt wurde. Im Anschluss an 1210 oder 1212 wird das Verfahren 1200 beendet.
  • Unter Bezugnahme auf 13 wird ein Flussdiagramm bereitgestellt, das ein Verfahren 1300 zur Durchführung einer Anomalieerkennung basierend auf vordefinierten Regeln bezüglich einer Richtlinie zur Weiterleitung von CAN-Paketen veranschaulicht. Obwohl das in 13 dargestellte Beispiel auf eine Richtlinie zur Weiterleitung von CAN-Paketen zutrifft, werden Personen mit normalen Fähigkeiten erkennen, dass das Verfahren 1300 auch auf andere Arten von Netzwerknachrichten, wie Ethernet-Nachrichten oder dergleichen, angewendet werden kann. Des Weiteren nimmt das Verfahren 1300 an, dass die Komponente des Systems, die eine Anomalieerkennung durchführt, alle Netzwerknachrichten sowie alle Nachrichten empfängt, die das CGM entweder besitzt oder weiterleiten wird. Die in 13 reflektierte Richtlinie zur Weiterleitung von CAN-Paketen kann beispielsweise gewährleisten, dass jede Nachricht, die innerhalb des Fahrzeugnetzwerks ohne Verwendung des CGM geroutet wurde, als anormal erkannt wird.
  • Das Verfahren 1300 beginnt bei 1302, wobei eine CAN-Nachricht erhalten wird. Bei 1304 wird bestimmt, ob die CAN-Nachricht erfolgreich übertragen wurde. Ist dies der Fall, fährt das Verfahren 1300 mit 1306 fort, wobei keine Verletzung vordefinierter Regeln erkannt wird und das System auf die nächste CAN-Nachricht wartet. Wenn jedoch bei 1304 bestimmt wird, dass die CAN-Nachricht nicht erfolgreich übertragen wurde, fährt das Verfahren 1300 mit 1308 fort. Um 1308 wird bestimmt, ob die CAN-Nachricht im Fahrzeugnetzwerk gesehen wurde. Wenn nicht, kehrt das Verfahren 1300 zu 1304 zurück. Wenn die CAN-Nachricht jedoch im Fahrzeugnetzwerk gesehen wurde, fährt das Verfahren 1300 mit 1310 fort, wobei bestimmt wird, dass eine vordefinierte Regel verletzt wurde (was zu einer Erkennung einer Anomalie führen kann). Im Anschluss an 1310 wird das Verfahren beendet.
  • Unter Bezugnahme nun auf 14 veranschaulicht ein Flussdiagramm ein Verfahren 1400 zur Durchführung einer Anomalieerkennung basierend auf vordefinierten Regeln für eine zulässige Fahrzeugzustandsrichtlinie. Obwohl das in 14 dargestellte Beispiel auf eine CAN-Nachricht zutrifft, werden Personen mit normalen Fähigkeiten erkennen, dass das Verfahren 1400 auch auf andere Arten von Netzwerknachrichten, wie Ethernet-Nachrichten oder dergleichen, angewendet werden kann.
  • Das Verfahren 1400 beginnt bei 1402, wobei eine CAN-Nachricht mit einer CAN_ID erhalten wird. Bei 1404 wird bestimmt, ob die CAN-ID einer vordefinierten Regel zugeordnet ist. Wenn nicht, fährt das Verfahren 1400 mit 1406 fort, wobei keine Verletzung erkannt wird und das System auf die nächste CAN-Nachricht wartet. Wird jedoch festgestellt, dass die CAN_ID einer Regel zugeordnet ist, fährt das Verfahren 1400 mit 1408 fort, wobei bestimmt wird, ob der zulässige Zustand der zugehörigen Regel einem aktuellen Zustand des Fahrzeugs entspricht. Falls ja, fährt das Verfahren 1400 mit 1410 fort, wobei keine Verletzung erkannt wird und das System auf die nächste CAN-Nachricht wartet. Wenn jedoch bestimmt wird, dass der zulässige Zustand der zugehörigen Regel nicht dem aktuellen Zustand des Fahrzeugs entspricht, fährt das Verfahren 1400 mit 1412 fort, wobei eine Regelverletzung erkannt wird. Im Anschluss an 1406, 1410 und 1412 wird das Verfahren 1400 beendet.
  • Unter Bezugnahme auf 15 wird ein weiteres Beispiel für ein System 1500 zur Durchführung einer Eindringungserkennung in einem Fahrzeugnetzwerk dargestellt. Das System 1500 beinhaltet das Fahrzeug 102, das über ein drahtloses Netzwerk 1510 mit dem entfernten Computersystem 104 verbunden ist. Das System 1500 von 15 entspricht dem System 100 von 1 und dem System 800 von 8. Das System 1500 von 15 veranschaulicht jedoch zusätzliche Details, die unter anderem das CGM 802 betreffen. Insbesondere veranschaulicht 15 eine Architektur für das CGM 802, die es ermöglicht, dass ein Knoten in einem herausgeforderten Netzwerk (d. h. der zweite Kern 810 des ersten Mikrocontrollers 806) das Netzwerk überwacht, von dem er funktional isoliert ist. Darüber hinaus veranschaulicht 15 die Art und Weise, wie der gemeinsame Speicher 1502 - geteilt zwischen dem zweiten Kern 810 und dem ersten Kern 812 des ersten Mikrocontrollers 806 - genutzt werden kann, um Netzwerknachrichten sicher für einen vom Netzwerk isolierten Knoten sichtbar zu machen. Weitere Vorteile ergeben sich unter Bezugnahme auf 15 und die anschließende Abhandlung.
  • Wie vorstehend erwähnt, kann das Fahrzeug 102 ein CGM 802 und einen mit dem CGM 802 verbundenen drahtlosen Sender 804 beinhalten. Der drahtlose Sender 804 kann zum Übertragen (und Empfangen) von Nachrichten, Signalen, Befehlen usw. zum (und vom) entfernten Computersystem 104 über das drahtlose Netzwerk 1510 konfiguriert werden.
  • Das CGM 802 kann einen ersten Mikrocontroller 806 und einen zweiten Mikrocontroller 808 beinhalten. Gemäß einigen exemplarischen Implementierungen kann jeder Mikrocontroller 806, 808 einen 32-Bit-Mikrocontroller darstellen. Im Rahmen dieser Offenbarung können jedoch auch andere geeignete Mikrocontroller-Architekturen eingesetzt werden, ohne von den hierin dargelegten Lehren abzuweichen. Gemäß einigen Beispielen kann das CGM 802 als ein oder mehrere ECUs oder dergleichen implementiert werden.
  • Der erste Mikrocontroller 806 kann einen ersten Kern 812, einen zweiten Kern 810 und einen Speicher 1502 beinhalten, der mit den ersten und zweiten Kernen 812, 810 verbunden ist. Der erste Kern 812 kann mit einem oder mehreren CAN-Bussen 106 und/oder einem oder mehreren Ethernet-Bussen 142 verbunden werden, um daraus Netzwerknachrichten 148 zu erhalten. Gemäß einigen Beispielen kann der erste Kern 812 konfiguriert werden, um die Netzwerknachricht(en) 148 in den Speicher 1502 (z. B. den gemeinsamen Speicher 1506) zu schreiben, sodass der zweite Kern 810 auf die Nachrichten zugreifen und sie analysieren kann, um eine Anomalieerkennung gemäß den Lehren der vorliegenden Offenbarung durchzuführen. Gemäß einigen Beispielen kann der gemeinsame Speicher 1506 nur durch den ersten Kern 812 und den zweiten Kern 810 des ersten Mikrocontrollers 806 direkt zugänglich sein, um das Eindringungserkennungssystem 1500 selbst vor einer Beeinträchtigung durch einen Cyber-Angriff oder dergleichen zu schützen.
  • Der Speicher 1502 kann einen gesicherten Direktzugriffsspeicher (RAM) 1504 und einen gesicherten nichtflüchtigen Speicher (NVM) 1512 beinhalten. Der gesicherte RAM 1504 kann als jeder geeignete RAM-Typ implementiert werden, einschließlich, jedoch nicht beschränkt auf SRAM, DRAM, FPM DRAM, EDO DRAM, SDRAM, DDR SDRAM, RDRAM, CMOS RAM, usw. Der gesicherte RAM 1504 kann einen gemeinsamen Speicher 1506 beinhalten, der zwischen dem ersten Kern 812 und dem zweiten Kern 810 des ersten Mikrocontrollers 806 geteilt wird. Der gesicherte RAM 1504 kann auch ein oder mehrere residente Ereignisprotokolle 126 und/oder ein oder mehrere übertragene Ereignisprotokolle 132 speichern. Die residenten Ereignisprotokolle 126 und/oder die übertragenen Ereignisprotokolle 132 können vom zweiten Kern 810 in den gesicherten RAM 1504 geschrieben werden, beispielsweise als Teil einer Ereignisprotokollerstellung nach einer Anomalieerkennung.
  • Der gesicherte NVM 1512 kann als jeder geeignete NVM-Typ implementiert werden, einschließlich, jedoch nicht beschränkt auf Flash, ROM, ferroelektrischer RAM, magnetische Speichervorrichtungen, optische Laufwerke, usw. Der gesicherte NVM 1512 kann ein oder mehrere residente Ereignisprotokolle 126 und/oder ein oder mehrere übertragene Ereignisprotokolle 132 beinhalten. Gemäß einigen Implementierungen können die residenten Ereignisprotokolle 126 und/oder die übertragenen Ereignisprotokolle 132 vom gesicherten RAM 1504 zum gesicherten NVM 1512 übertragen oder gesichert werden. So kann beispielsweise der zweite Kern 810 konfiguriert werden, um die residenten Ereignisprotokolle 126 und/oder die übertragenen Ereignisprotokolle 132 in den gesicherten NVM 1512 zu schreiben, bevor der Speicher 1502 an Leistung verliert (z. B. als Reaktion auf das Abschalten einer Fahrzeugzündung oder dergleichen). Obwohl das vorstehende Beispiel den zweiten Kern 810 in Betracht zieht, der die residenten Ereignisprotokolle 126 und/oder die übertragenen Ereignisprotokolle 132 in den gesicherten NVM 1512 schreibt, bevor der Speicher 1502 an Leistung verliert, betrachtet die vorliegende Offenbarung auch andere, nicht leistungsreduzierte Szenarien, wohingegen der zweite Kern 810 die residenten Ereignisprotokolle 126 und/oder die übertragenen Ereignisprotokolle 132 in den gesicherten NVM 1512 schreibt.
  • Der zweite Mikrocontroller 808 kann über einen beliebigen Kommunikationskanal mit dem ersten Mikrocontroller 806 verbunden und konfiguriert werden, um die Kommunikation zwischen dem ersten Mikrocontroller 806 und dem entfernten Computersystem 104 zu erleichtern. Insbesondere, während der erste Mikrocontroller 806 gemäß einigen Beispielen keinen Netzwerkstapel beinhaltet (und somit nicht außerhalb des Fahrzeugnetzwerks kommunizieren kann), beinhaltet der zweite Mikrocontroller 808 einen Netzwerkstapel 1508. Der Netzwerkstapel 1508 ermöglicht dem zweiten Mikrocontroller 808 die Kommunikation über externe Netzwerke des Fahrzeugs 102 (z. B. das drahtlose Netzwerk 1510) über den drahtlosen Sender 804. Auf diese Weise kann der zweite Mikrocontroller 808 als Schnittstelle oder Gateway zwischen dem ersten Mikrocontroller 806 und Netzwerken außerhalb des Fahrzeugs 102 dienen.
  • Im Betrieb kann das System 1500 zum Erkennen von Eindringversuchen innerhalb eines Netzwerks des Fahrzeugs 102 wie folgt funktionieren. Der erste Kern 812 des ersten Mikrocontrollers 806 kann von einem oder mehreren Kommunikationsbussen des Fahrzeugs (z. B. CAN-Bus(e) 106 und/oder Ethernet-Bus(e) 142) Netzwerknachrichten 148 empfangen. Die Netzwerkmeldung(en) 148, die von dem/den Kommunikationsbus(e) erhalten wurde(n), kann/können von anderen Komponenten im Fahrzeug ausgehen (nicht dargestellt), einschließlich, jedoch nicht beschränkt auf, einen Datenverbindungsstecker (DLC), wie beispielsweise ein OBD-II, eine Mittelkonsole usw. Die Netzwerkmeldung(en) 148 können ein oder mehrere Ereignisse im Zusammenhang mit einem Fahrzeug beschreiben, wie vorstehend in Bezug auf 1 ausführlich erörtert wurde.
  • Der erste Kern 812 kann eine oder mehrere Meldungen 148 in den Speicher 1502 schreiben. Insbesondere kann gemäß einigen Beispielen der erste Kern 812 die Netzwerkmeldung(en) in den gemeinsamen Speicher 1506 schreiben, sodass die Meldungen 148 durch den zweiten Kern 810 zugänglich sind (d. h. gelesen werden können). Neben dem Schreiben der Netzwerkmeldungen 148 in den Speicher kann der erste Kern 812 auch weitere Informationen in den Speicher schreiben (z. B. den gemeinsamen Speicher 1506), sodass die zusätzlichen Informationen für den zweiten Kern 810 zugänglich sind, um beispielsweise eine Anomalieerkennung und Ereignisprotokollierung durchzuführen. So kann beispielsweise der erste Kern 812 die folgenden zusätzlichen Informationen in den Speicher 1502 schreiben: (i) geroutete Netzwerkmeldungen; (ii) Diagnosemeldungen; und/oder (iii) Betriebszustandsparameter des Fahrzeugs. Gemäß einigen Beispielen können die Betriebszustandsparameter des Fahrzeugs gemäß der in 10 dargestellten und zuvor erörterten Datenstruktur im Speicher 1502 gespeichert werden.
  • Der zweite Kern 810 kann eine oder mehrere im Speicher 1502 gespeicherte Netzwerkmeldungen 148 lesen (z. B. den gemeinsamen Speicher 1506 des gesicherten RAM 1504) und darauf aufbauend eine Anomalieerkennung und Protokollerzeugung durchführen. Insbesondere kann der zweite Kern 810 erkennen, ob zumindest einige der in der/den Netzwerkmeldung(en) 148 beschriebenen Ereignisse eine auf vordefinierten Regeln basierende Anomalie darstellen (z. B. vordefinierte Regeln 122). Darüber hinaus kann der zweite Kern 810 ein oder mehrere residente Ereignisprotokolle 126 basierend auf den erkannten Anomaliedaten erzeugen (z. B. die in 1 dargestellten erkannten Anomaliedaten 130).
  • Wie vorstehend erwähnt, kann das eine oder die mehreren residenten Ereignisprotokolle 126 Metadaten beinhalten, die einem oder mehreren erkannten anomalen Ereignissen zugeordnet sind. Des Weiteren kann der zweite Kern 810 ein oder mehrere übertragene Ereignisprotokolle 132 basierend auf dem einen oder den mehreren residenten Ereignisprotokollen 126 erzeugen. Wie bereits erwähnt, kann das/die übertragene(n) Ereignisprotokoll(e) 132 dem/den jeweiligen residenten Ereignisprotokoll(en) 126 entsprechen. Gemäß einigen Beispielen kann das eine oder die mehreren übertragenen Ereignisprotokolle 132 weniger Metadaten beinhalten als ihre jeweiligen, entsprechenden ein oder mehrere residenten Ereignisprotokolle 126, um unter anderem die Datenübertragungskosten zu reduzieren, wenn die übertragenen Ereignisprotokolle 132 und/oder residenten Ereignisprotokolle 126 vom Fahrzeug 102 über das drahtlose Netzwerk 1510 an das entfernte Computersystem 104 übertragen werden.
  • Der zweite Kern 810 kann alle erzeugten residenten Ereignisprotokolle 126 und/oder übertragenen Ereignisprotokolle 132 in den Speicher 1502 schreiben, sodass die Protokolle 126, 132 (i) vom ersten Kern 812 gelesen werden können; (ii) über den ersten Kern 812 des ersten Mikrocontrollers 806 zum zweiten Mikrocontroller 808 übertragen werden; und (iii) vom zweiten Mikrocontroller 808 zum entfernten Computersystem 104 über das drahtlose Netzwerk 1510 über den drahtlosen Sender 804 übertragen werden. Insbesondere kann der zweite Kern 810 alle erzeugten residenten Ereignisprotokolle 126 und/oder übertragene Ereignisprotokolle 132 in den gesicherten RAM 1504 und/oder den gesicherten NVM 1512 schreiben. Der erste Kern 812 kann alle erzeugten residenten Ereignisprotokolle 126 und/oder übertragenen Ereignisprotokolle 132 lesen, die vom zweiten Kern 810 über den gesicherten RAM 1504 (einschließlich des gemeinsamen Speichers 1506) und/oder den gesicherten NVM 1512 in den Speicher 1502 geschrieben werden.
  • Die Architektur des CGM 802 ermöglicht es unter anderem, die Funktionen der Anomalieerkennung und Ereignisprotokollerzeugung des Eindringungserkennungssystems 1500 innerhalb des zweiten Kerns 810 des ersten Mikrocontrollers 806 zu isolieren, der keinen direkten Zugriff auf einen Netzwerkstapel (z. B. den Netzwerkstapel 1508) gemäß den hierin beschriebenen Implementierungen besitzt. Auf diese Weise können die Anomalieerkennungs- und Protokollerzeugungsfunktionen des Eindringungserkennungssystems 1500 vor direkten Netzwerkangriffen aus der Ferne geschützt werden.
  • Gemäß bestimmten Implementierungen ist das System 1500 von 15 weiterhin konfiguriert, um Bestätigungssignale im Wesentlichen gemäß dem hierin beschriebenen und in Bezug auf 8 veranschaulichten Protokoll zu erzeugen und zu übertragen. So kann beispielsweise der zweite Mikrocontroller 808 nach erfolgreichem Empfangen eines oder mehrerer gesendeter Ereignisprotokolle 132 und/oder residenter Ereignisprotokolle 126 vom ersten Mikrocontroller 806 ein Bestätigungssignal (Bestätigung des erfolgreichen Empfangs des betreffenden Ereignisprotokolls) erzeugen und dieses Bestätigungssignal an den ersten Mikrocontroller 806 zurücksenden. Gemäß einigen Beispielen kann der erste Kern 810 des ersten Mikrocontrollers 806 anschließend das Bestätigungssignal in den Speicher 1502 schreiben, sodass beispielsweise der zweite Kern 810 die Bestätigung lesen kann, dass ein bestimmtes Ereignisprotokoll erfolgreich entlang mindestens eines „Sprungs“ des Systems 1500 übertragen wurde.
  • Ebenso kann das entfernte Computersystem 104 nach erfolgreichem Empfangen des einen oder der mehreren übertragenen Ereignisprotokolle 132 und/oder residenten Ereignisprotokolle 126 vom zweiten Mikrocontroller 808 (über den drahtlosen Sender 804 und das drahtlose Netzwerk 1510) ein Bestätigungssignal erzeugen und dieses an den zweiten Mikrocontroller 808 zurücksenden, der wiederum das Bestätigungssignal an den ersten Kern 812 des ersten Mikrocontrollers 806 weiterleiten kann, von wo es in den Speicher 1502 oder dergleichen geschrieben werden kann (und schließlich vom zweiten Kern 810, falls gewünscht, ausgelesen werden kann).
  • Abschließend kann das entfernte Computersystem 104 gemäß einigen Beispielen verschiedene Befehle zum Zwecke der Verwaltung des Ereignisprotokolls und/oder der Abhilfemaßnahmen im Falle eines Eindringens in das Netzwerk erzeugen und an das Fahrzeug übermitteln.
  • So kann beispielsweise, wie im Zusammenhang mit 1 zuvor erläutert, das entfernte Computersystem 104 einen Protokollsteuerungsbefehl erzeugen und übertragen. Der Protokollsteuerungsbefehl kann vom entfernten Computersystem 104 an den zweiten Mikrocontroller 808 übertragen werden, der wiederum den Protokollsteuerungsbefehl an den ersten Mikrocontroller 806 weitergeben kann. Der erste Mikrocontroller 806 kann nach dem Erhalten des Protokollsteuerungsbefehls eine oder mehrere der folgenden Verwaltungsmaßnahmen in Bezug auf die Ereignisprotokolle durchführen: Löschen mindestens eines residenten Ereignisprotokolls des einen oder der mehreren residenten Ereignisprotokolle 126; Anpassen einer Speicherzuordnung für mindestens eines der einen oder mehreren residenten Ereignisprotokolle 126; Übertragen mindestens eines der einen oder mehreren residenten Ereignisprotokolle 126 an das entfernte Computersystem 104; Einstellen des Inhalts von mindestens einem der einen oder mehreren residenten Ereignisprotokolle 126 vor der Übertragung; Einstellen einer zugehörigen Protokollübertragungsrate, wobei die Protokollübertragungsrate eine Frequenz beschreibt, mit der übertragene Ereignisprotokolle 132 vom ersten Mikrocontroller 806 zum entfernten Computersystem 104 übertragen werden; und/oder Einschränken einer Datengröße des einen oder der mehreren übertragenen Ereignisprotokolle 132.
  • Darüber hinaus kann das entfernte Computersystem 104 einen Eindringungsreaktionsbefehl erzeugen und übertragen. Der Eindringungsreaktionsbefehl kann vom entfernten Computersystem 104 an den zweiten Mikrocontroller 808 übertragen werden, der wiederum den Eindringungsreaktionsbefehl an den ersten Mikrocontroller 806 weitergeben kann. Nach dem Erhalten des Eindringungsreaktionsbefehls kann der erste Mikrocontroller 806 eine oder mehrere der folgenden Abhilfemaßnahmen ergreifen: die Kommunikation von mindestens einem der einen oder mehreren Kommunikationsbusse (z. B. CAN-Bus(e) 106 und/oder Ethernet-Bus(e) 142) einschränken und/oder eine MIL des Fahrzeugs 102 beleuchten.
  • Die vorhergehende Beschreibung ist rein illustrativ und soll die vorliegende Offenbarung sowie ihre Ausführungen oder Verwendungen keineswegs einschränken. Die umfassenden Lehren der Offenlegung können in zahlreichen Formen umgesetzt werden. Obwohl die vorliegende Offenbarung also bestimmte Beispiele beinhaltet, ist der eigentliche Umfang der Offenbarung hierdurch in keiner Weise eingeschränkt und weitere Modifikationen gehen aus dem Studium der Zeichnungen, der Beschreibung und den folgenden Patentansprüchen hervor. Es sei daraufhingewiesen, dass einer oder mehrere Schritte innerhalb eines Verfahrens in anderer Reihenfolge (oder gleichzeitig) ausgeführt werden können, ohne die Prinzipien der vorliegenden Offenbarung zu verändern. Ferner, obwohl jede der Ausführungsformen oben dahingehend beschrieben ist, dass sie bestimmte Merkmale aufweist, kann/können eines oder mehrere dieser Funktionen, die in Bezug auf jede Ausführungsform der Offenbarung beschrieben sind, in jeder der anderen Ausführungsformen implementiert und/oder kombiniert werden, selbst wenn diese Kombination nicht explizit beschrieben wird. Mit anderen Worten ausgedrückt, schließen sich die beschriebenen Ausführungsformen nicht gegenseitig aus, und Permutationen von einer oder mehreren Ausführungsformen gegeneinander bleiben innerhalb des Schutzumfangs dieser Offenbarung.
  • Räumliche und funktionale Beziehungen zwischen Elementen (z. B. zwischen Modulen, Schaltkreiselementen, Halbleiterschichten usw.) werden unter Verwendung von verschiedenen Begriffen beschrieben, einschließlich „verbunden“, „eingerastet“, „gekoppelt“, „benachbart“, „neben“, „oben auf“, „über“, „unter“ und „angeordnet“. Sofern nicht ausdrücklich als „direkt“ beschrieben, kann eine Beziehung eine direkte Beziehung sein, wenn eine Beziehung zwischen einem ersten und zweiten Element in der oben genannten Offenbarung beschrieben wird, wenn keine anderen intervenierenden Elemente zwischen dem ersten und zweiten Element vorhanden sind, kann jedoch auch eine indirekte Beziehung sein, wenn ein oder mehrere intervenierende(s) Element(e) (entweder räumlich oder funktional) zwischen dem ersten und zweiten Element vorhanden ist/sind. Wie hierin verwendet, sollte der Satz „zumindest eines von A, B und C“ so zu verstehen sein, dass damit eine Logik gemeint ist (A ODER B ODER C), unter Verwendung eines nicht ausschließlichen logischen ODER, und sollte nicht dahingehend zu verstehen sein, dass gemeint ist „zumindest eines von A, zumindest eines von B und zumindest eines von C.“
  • In den Figuren bezeichnen die Pfeilrichtungen, wie angezeigt, durch die Pfeilspitze im Allgemeinen den Fluss von Informationen (wie Daten oder Befehlen), die im Kontext der Darstellung relevant sind. Wenn beispielsweise Element A und Element B eine Vielzahl von Informationen austauschen, aber die Informationen, die von Element A nach Element B übertragen werden, für die Darstellung relevant sind, kann der Pfeil von Element A nach Element B zeigen. Diese unidirektionalen Pfeile implizieren nicht, dass keine anderen Informationen von Element B nach Element A übertragen werden. Zudem kann Element B im Zusammenhang mit Informationen, die von Element A nach Element B gesendet werden, Anforderungen oder Bestätigungen dieser Informationen zu Element A senden.
  • In dieser Anwendung kann einschließlich der folgenden Definitionen der Begriff „Modul“ oder der Begriff „Steuerung“ ggf. durch den Begriff „Schaltung“ ersetzt werden. Der Begriff „Modul“ kann auf Folgendes verweisen bzw. Teil von Folgendem sein oder Folgendes beinhalten: einen anwendungsspezifischen integrierten Schaltkreis (ASIC); eine digitale, analoge oder gemischt analog/digitale diskrete Schaltung; eine digitale, analoge oder gemischt analog/digitale integrierte Schaltung; eine kombinatorische Logikschaltung; ein feldprogrammierbares Gate-Array (FPGA); eine Prozessorschaltung (gemeinsam genutzt, dediziert oder Gruppe), die Code ausführt; eine Memory-Schaltung (gemeinsam genutzt, dediziert oder Gruppe), die einen von der Prozessorschaltung ausgeführten Code speichert; andere geeignete Hardware-Komponenten, die die beschriebene Funktionalität bereitstellen; oder eine Kombination von einigen oder allen der oben genannten, wie zum Beispiel in einem System-on-Chip.
  • Das Modul kann eine oder mehrere Schnittstellenschaltungen beinhalten. In einigen Beispielen können die Schnittstellenschaltungen kabelgebundene oder -lose Schnittstellen beinhalten, die mit einem lokalen Netzwerk (LAN), dem Internet, einem Weitverkehrsnetz (WAN) oder Kombinationen hier aus verbunden sind. Die Funktionalität der in vorliegender Offenbarung genannten Module kann auf mehrere Module verteilt werden, die über Schnittstellenschaltungen verbunden sind. So können zum Beispiel mehrere Module einen Lastenausgleich zulassen. In einem anderen Beispiel können von einem Servermodul (z. B. Remote-Server oder Cloud) ermittelte Funktionen eines Client-Moduls übernommen werden.
  • Der Begriff Code, wie oben verwendet, kann Software, Firmware und/oder Mikrocode beinhalten und auf Programme, Routinen, Funktionen, Klassen, Datenstrukturen und/oder Objekte verweisen. Der Begriff „gemeinsame Prozessorschaltung“ bezieht sich auf eine einzelne Prozessorschaltung, die ermittelten oder vollständigen Code von mehreren Modulen ausführt. Der Begriff „gruppierte Prozessorschaltung“ bezieht sich auf eine Prozessorschaltung, die in Kombination mit zusätzlichen Prozessorschaltungen ermittelten oder vollständigen Code von ggf. mehreren Modulen ausführt. Verweise auf mehrere Prozessorschaltungen umfassen mehrere Prozessorschaltungen auf diskreten Matrizen, mehrere Prozessorschaltungen auf einer einzelnen Scheibe, mehrere Kerne auf einer einzelnen Prozessorschaltung, mehrere Threads einer einzelnen Prozessorschaltung oder eine Kombination der oben genannten. Der Begriff „gemeinsame Memory-Schaltung“ bezieht sich auf eine einzelne Memory-Schaltung, die ermittelten oder vollständigen Code von mehreren Modulen speichert. Der Ausdruck „gruppierte Memory-Schaltung“ bezieht sich auf eine Memory-Schaltung, die in Kombination mit zusätzlichem Speicher ermittelte oder vollständige Codes von ggf. mehreren Modulen speichert.
  • Der Begriff Memory-Schaltung ist dem Begriff computerlesbares Medium untergeordnet. Der Begriff „computerlesbares Medium“, wie er hier verwendet wird, bezieht sich nicht auf flüchtige elektrische oder elektromagnetische Signale, die sich in einem Medium ausbreiten (z. B. im Falle einer Trägerwelle); der Ausdruck „computerlesbares Medium“ ist daher als konkret und nichtflüchtig zu verstehen. Nicht einschränkende Beispiele eines nichtflüchtigen konkreten computerlesbaren Mediums sind nichtflüchtige Memory-Schaltungen (z. B. Flash-Memory-Schaltungen, löschbare programmierbare ROM-Schaltungen oder Masken-ROM-Schaltungen), flüchtige Memory-Schaltungen (z. B. statische oder dynamische RAM-Schaltungen), magnetische Speichermedien (z. B. analoge oder digitale Magnetbänder oder ein Festplattenlaufwerk) und optische Speichermedien (z. B. CD, DVD oder Blu-ray).
  • Die im Rahmen dieser Anmeldung beschriebenen Vorrichtungen und Verfahren können teilweise oder vollständig mit einem speziellen Computer, der für die Ausführung ermittelter Computerprogrammfunktionen konfiguriert ist, implementiert werden. Die Funktionsblöcke, Flussdiagramm-Komponenten und weiter oben beschriebenen Elemente dienen als Softwarespezifikationen, die von entsprechend geschulten Technikern oder Programmierern in Computerprogramme umgesetzt werden können.
  • Die Computerprogramme beinhalten prozessorausführbare Anweisungen, die auf mindestens einem nicht-transitorischen greifbaren computerlesbaren Medium gespeichert sind. Die Computerprogramme können ebenfalls gespeicherte Daten enthalten oder auf gespeicherten Daten basieren. Die Computerprogramme können ein Basic-Input-Output-System (BIOS) umfassen, das mit der Hardware des speziellen Computers zusammenwirkt, Vorrichtungstreiber, die mit ermittelten Vorrichtungen des speziellen Computers, einem oder mehreren Betriebssystemen, Benutzeranwendungen, Hintergrunddiensten, im Hintergrund laufenden Anwendungen usw. zusammenwirken.
  • Die Computerprogramme können Folgendes beinhalten: (i) beschreibenden Text, der gegliedert wird, wie z. B. HTML (Hypertext Markup Language), XML (Extensible Markup Language) oder JSON (JavaScript Object Notation), (ii) Assembler Code, (iii) Objektcode, der von einem Quellcode durch einen Compiler erzeugt wurde, (iv) Quellcode zur Ausführung durch einen Interpreter, (v) Quellcode zur Kompilierung und zur Ausführung durch einen Justin-Time-Compiler usw. Nur exemplarisch kann der Quellcode mittels der Syntax der Sprachen, einschließlich C, C++, C#, Objective-C, Swift, Haskell, Go, SQL, R, Lisp, Java®, Fortran, Perl, Pascal, Curl, OCaml, Javascript®, HTML5 (Hypertext Markup Language 5. Version), Ada, ASP (Active Server Pages), PHP (PHP: Hypertext Preprocessor), Scala, Eiffel, Smalltalk, Erlang, Ruby, Flash®, Visual Basic®, Lua, AMTLAB, SIMULINK und Python®, geschrieben werden.
  • Keines der in den Ansprüchen genannten Elemente ist als Mittel für eine Funktion (sog. „means plus function“) nach 35 U.S.C. §112(f) zu verstehen, es sei denn, ein Element wird ausdrücklich unter Verwendung des Begriffes „means for“ (Mittel für) beschrieben oder falls in einem Verfahrensanspruch die Begriffe „Vorgang für“ oder „Schritt für“ verwendet 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
    • US 15/700605 [0001]

Claims (10)

  1. System, das Folgendes umfasst: ein Anomalieerkennungsmodul, konfiguriert zum: Erhalten von einer oder mehrerer Netzwerkmeldungen von einem oder mehrerer Kommunikationsbusse eines Fahrzeugs, worin die eine oder die mehreren Netzwerkmeldungen ein oder mehrere mit dem Fahrzeug verbundene Ereignisse beschreiben; und Erkennen, ob mindestens eines oder mehreren Ereignisse eine Anomalie basierend auf vordefinierten Regeln darstellen, um erkannte Anomalie-Ereignisdaten bereitzustellen; ein residentes Protokollerzeugungsmodul, konfiguriert um: die ermittelten Anomalie-Ereignisdaten zu erhalten; und ein oder mehrere residente Ereignisprotokolle basierend auf den erfassten Anomalieereignisdaten zu erzeugen, wobei das eine oder die mehreren residenten Ereignisprotokolle Metadaten umfassen, die mit einem oder mehreren erfassten anomalen Ereignissen verknüpft sind; und ein übertragendes Protokollerzeugungsmodul, konfiguriert um: ein oder mehrere übertragene Ereignisprotokolle zu erhalten; basierend auf dem einen oder den mehreren residenten Ereignisprotokollen eine oder mehrere übertragene Ereignisprotokolle zu erzeugen, worin jedes der einen oder mehreren übertragenen Ereignisprotokolle einem residenten Ereignisprotokoll entspricht; und ein oder mehrere übertragene Ereignisprotokolle an ein vom Fahrzeug entferntes Computersystem zu übertragen.
  2. System nach Anspruch 1, weiterhin umfassend: ein elektronisches Steuergerät (ECU) umfassend einen Speicher, worin der Speicher mindestens einige der einen oder mehreren residenten Ereignisprotokolle umfasst.
  3. System nach Anspruch 2, worin das ECU weiterhin zu Folgendem konfiguriert ist: Erhalten eines Protokollsteuerungsbefehls von dem vom Fahrzeug entfernten Computersystem; und als Reaktion auf das Erhalten des Protokollsteuerungsbefehls, durchführen mindestens eine der folgenden Maßnahmen: Löschen mindestens eines residenten Ereignisprotokolls des einen oder der mehreren residenten Ereignisprotokolle; und Anpassen einer Speicherzuordnung für mindestens eines der einen oder mehreren residenten Ereignisprotokolle.
  4. System nach Anspruch 1, worin das übertragende Protokollerzeugungsmodul ferner konfiguriert ist, zum: Erhalten eines Protokollsteuerungsbefehls von dem vom Fahrzeug entfernten Computersystem; und als Reaktion auf das Erhalten des Protokollsteuerungsbefehls, durchführen mindestens eine der folgenden Maßnahmen: Übertragen von mindestens einem oder mehreren residenten Ereignisprotokolle an das vom Fahrzeug entfernte Computersystem; Anpassen des Inhalts von mindestens einem oder mehreren residenten Ereignisprotokollen vor der Übertragung; Einstellen einer zugehörigen Protokollübertragungsrate mit dem übertragenden Protokollerzeugungsmodul, worin die Protokollübertragungsrate eine Frequenz beschreibt, mit der übertragene Ereignisprotokolle vom ersten Mikrocontroller zum entfernten Computersystem übertragen werden; und Beschränken einer Datengröße des einen oder der mehreren übertragenen Ereignisprotokolle.
  5. System nach Anspruch 1, weiterhin umfassend ein Abhilfemaßnahmenmodul, das konfiguriert ist zum: Erhalten eines Eindringungsreaktionsbefehls von dem vom Fahrzeug entfernten Computersystem; und als Reaktion auf das Erhalten des Eindringungsreaktionsbefehls, durchführen mindestens eine der folgenden Maßnahmen: Beschränken der Kommunikation von mindestens einem der einen oder mehreren Kommunikationsbusse; und Beleuchten einer Störmeldeleuchte (MIL) des Fahrzeugs.
  6. Das System von Anspruch 1, worin jedes residente Ereignisprotokoll des einen oder der mehreren residenten Ereignisprotokolleinträge ein Manifest und einen oder mehrere Ereignisprotokolleinträge umfasst, worin jeder Ereignisprotokolleintrag des einen oder der mehreren Ereignisprotokolleinträge einem Verstoß gegen eine oder mehrere der vordefinierten Regeln entspricht.
  7. System nach Anspruch 6, worin das Manifest Folgendes umfasst: eine Softpart-Referenznummer, die einen Regelsatz der vordefinierten Regel identifiziert, dem ein bestimmtes residentes Ereignisprotokoll entspricht; und eine Zusammenfassung aller Regelverstöße, die eine Gesamtzahl von Vorfällen beschreibt, die für alle Regelverstöße innerhalb eines durch die Softpart-Referenznummer definierten Regelsatzes protokolliert wurden.
  8. Das System von Anspruch 6, worin jeder der einen oder mehreren Ereignisprotokolleinträge einen oder mehrere der folgenden beinhaltet: den vordefinierten Regelsatz, gegen den verstoßen wurde; eine Anzahl von Malen, bei denen gegen die vordefinierte Regel verstoßen wurde; einen Zeitrahmen, in dem gegen die vordefinierte Regel verstoßen wurde; die Netzwerkmeldung, die gegen die Regel verstoßen hat; und historische Daten über das Ereignis, worin die historischen Daten einen oder mehrere Zeitstempel umfassen, die einen bestimmten Zeitpunkt, zu dem gegen die Regel verstoßen wurde, und einen Zustand des Fahrzeugs zum Zeitpunkt, zu dem gegen die Regel verstoßen wurde, beschreiben.
  9. System nach Anspruch 1, worin die eine oder die mehreren Netzwerkmeldungen mindestens eine der folgenden umfassen: Controller Area Network (CAN)-Nachrichten von einem oder mehrerer CAN-Busse des Fahrzeugs; und Ethernet-Nachrichten von einem oder mehrerer Ethernet-Busse des Fahrzeugs.
  10. Das System nach Anspruch 1, worin sich die vordefinierten Regeln zumindest teilweise auf die Betriebszustandsparameter des Fahrzeugs beziehen.
DE102018122152.5A 2017-09-11 2018-09-11 Systeme und verfahren zur eindringungserkennung in das netzwerk im fahrzeug Pending DE102018122152A1 (de)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
US15/700,725 2017-09-11
US15/700,725 US10498749B2 (en) 2017-09-11 2017-09-11 Systems and methods for in-vehicle network intrusion detection

Publications (1)

Publication Number Publication Date
DE102018122152A1 true DE102018122152A1 (de) 2019-03-14

Family

ID=65441469

Family Applications (1)

Application Number Title Priority Date Filing Date
DE102018122152.5A Pending DE102018122152A1 (de) 2017-09-11 2018-09-11 Systeme und verfahren zur eindringungserkennung in das netzwerk im fahrzeug

Country Status (3)

Country Link
US (1) US10498749B2 (de)
CN (1) CN109495439B (de)
DE (1) DE102018122152A1 (de)

Cited By (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2021089359A1 (de) 2019-11-04 2021-05-14 Audi Ag Verfahren und steuergerät zum detektieren eines unautorisierten datenverkehrs in einem paketorientierten datennetzwerk eines kraftfahrzeugs sowie entsprechendes kraftfahrzeug
WO2021197824A1 (de) * 2020-03-28 2021-10-07 Robert Bosch Gmbh Verfahren zur behandlung einer anomalie von daten, insbesondere bei einem kraftfahrzeug
DE112019006821B4 (de) 2019-03-06 2023-02-09 Mitsubishi Electric Corporation Angriffserfassungseinrichtung und angriffserfassungsprogramm

Families Citing this family (23)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2019146976A1 (ko) * 2018-01-23 2019-08-01 현대자동차주식회사 차량 내 네트워크에 보안을 제공하는 시스템 및 방법
JP7037748B2 (ja) * 2018-01-26 2022-03-17 トヨタ自動車株式会社 電子制御ユニット及び接続認証方法
RU2706887C2 (ru) * 2018-03-30 2019-11-21 Акционерное общество "Лаборатория Касперского" Система и способ блокирования компьютерной атаки на транспортное средство
FR3086090B1 (fr) * 2018-09-17 2022-01-14 Commissariat Energie Atomique Methode de traitement confidentiel de logs d'un systeme d'information
EP3767913B1 (de) * 2019-07-17 2023-08-02 AO Kaspersky Lab Systeme und verfahren zur korrelation von ereignissen zur erkennung eines informationssicherheitsereignisses
US11975714B2 (en) * 2019-11-01 2024-05-07 GM Global Technology Operations LLC Intelligent vehicles with distributed sensor architectures and embedded processing with computation and data sharing
CN113132298B (zh) * 2019-12-30 2023-10-27 厦门雅迅网络股份有限公司 一种汽车网关上实现网络入侵检测的方法及系统
CN111431864A (zh) * 2020-02-28 2020-07-17 深圳开源互联网安全技术有限公司 车联网监控系统、方法、装置及可读存储介质
US11425155B2 (en) * 2020-03-12 2022-08-23 The Aerospace Corporation Monitoring the integrity of a space vehicle
CN113497777B (zh) * 2020-03-18 2023-05-30 广州汽车集团股份有限公司 汽车网关信息安全日志的收集方法及装置
CN113839904B (zh) * 2020-06-08 2023-08-22 北京梆梆安全科技有限公司 基于智能网联汽车的安全态势感知方法和系统
CN112104608A (zh) * 2020-08-17 2020-12-18 华人运通(上海)云计算科技有限公司 一种车辆信息安全防护方法、系统及存储介质
EP3968572A1 (de) * 2020-09-09 2022-03-16 Volkswagen Ag Verfahren zur bereitstellung von protokolleinträgen
US11677582B2 (en) 2020-12-09 2023-06-13 Raytheon Company Detecting anomalies on a controller area network bus
CN112866270B (zh) * 2021-01-29 2023-03-24 中汽创智科技有限公司 入侵检测防御方法及系统
WO2023073761A1 (ja) * 2021-10-25 2023-05-04 三菱電機株式会社 侵入検知システム
CN114710528B (zh) * 2022-03-25 2023-06-06 重庆长安汽车股份有限公司 一种座舱网联异常状态实时监控方法
CN114978630A (zh) * 2022-05-11 2022-08-30 重庆长安汽车股份有限公司 车载can网络的安全事件检测系统、方法及存储介质
CN115021977A (zh) * 2022-05-17 2022-09-06 蔚来汽车科技(安徽)有限公司 车机系统及包括其的车辆、预警方法以及存储介质
CN114995330A (zh) * 2022-05-18 2022-09-02 中国第一汽车股份有限公司 一种车辆can总线入侵检测测试方法和测试系统
CN114978729A (zh) * 2022-05-27 2022-08-30 重庆长安汽车股份有限公司 基于can总线车载入侵的检测方法、系统及可读存储介质
WO2024065093A1 (zh) * 2022-09-26 2024-04-04 华为技术有限公司 一种入侵检测方法、装置和系统
CN115603975B (zh) * 2022-09-30 2023-06-09 北京天融信网络安全技术有限公司 报文的入侵检测方法、装置、电子设备及存储介质

Family Cites Families (14)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
IL161333A0 (en) * 2001-10-10 2004-09-27 Mcloughlin Pacific Corp Method and apparatus for tracking aircraft and securing against unauthorized access
MX2008012891A (es) * 2006-04-06 2009-07-22 Smobile Systems Inc Sistema y metodo de deteccion de software dañino para plataformas moviles de acceso limitado.
US20120136802A1 (en) * 2010-11-30 2012-05-31 Zonar Systems, Inc. System and method for vehicle maintenance including remote diagnosis and reverse auction for identified repairs
US10600096B2 (en) * 2010-11-30 2020-03-24 Zonar Systems, Inc. System and method for obtaining competitive pricing for vehicle services
US10665040B2 (en) * 2010-08-27 2020-05-26 Zonar Systems, Inc. Method and apparatus for remote vehicle diagnosis
US20120136743A1 (en) * 2010-11-30 2012-05-31 Zonar Systems, Inc. System and method for obtaining competitive pricing for vehicle services
CN102568053B (zh) * 2010-12-31 2015-02-11 上海博泰悦臻电子设备制造有限公司 综合车辆故障检测系统的车载端及其数据处理方法
CN102529903B (zh) * 2010-12-31 2015-10-07 上海博泰悦臻电子设备制造有限公司 综合车辆故障检测系统
JP5522160B2 (ja) * 2011-12-21 2014-06-18 トヨタ自動車株式会社 車両ネットワーク監視装置
US10607424B2 (en) * 2012-02-10 2020-03-31 Appareo Systems, Llc Frequency-adaptable structural health and usage monitoring system (HUMS) and method with smart sensors
CN104503427B (zh) * 2014-11-25 2017-09-22 杭州云乐车辆技术有限公司 一种基于事件触发的实时车辆异常报告方法
CN104678990A (zh) * 2014-12-25 2015-06-03 上海通用汽车有限公司 一种用于车辆自诊断的方法、装置和车辆自诊断系统
WO2017127639A1 (en) * 2016-01-20 2017-07-27 The Regents Of The University Of Michigan Exploiting safe mode of in-vehicle networks to make them unsafe
US10370102B2 (en) * 2016-05-09 2019-08-06 Coban Technologies, Inc. Systems, apparatuses and methods for unmanned aerial vehicle

Cited By (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
DE112019006821B4 (de) 2019-03-06 2023-02-09 Mitsubishi Electric Corporation Angriffserfassungseinrichtung und angriffserfassungsprogramm
WO2021089359A1 (de) 2019-11-04 2021-05-14 Audi Ag Verfahren und steuergerät zum detektieren eines unautorisierten datenverkehrs in einem paketorientierten datennetzwerk eines kraftfahrzeugs sowie entsprechendes kraftfahrzeug
WO2021197824A1 (de) * 2020-03-28 2021-10-07 Robert Bosch Gmbh Verfahren zur behandlung einer anomalie von daten, insbesondere bei einem kraftfahrzeug

Also Published As

Publication number Publication date
CN109495439A (zh) 2019-03-19
US10498749B2 (en) 2019-12-03
CN109495439B (zh) 2021-09-07
US20190081960A1 (en) 2019-03-14

Similar Documents

Publication Publication Date Title
DE102018122152A1 (de) Systeme und verfahren zur eindringungserkennung in das netzwerk im fahrzeug
DE102018122143A1 (de) Systeme und verfahren zur eindringungserkennung in das netzwerk im fahrzeug
EP3278529B1 (de) Angriffserkennungsverfahren, angriffserkennungsvorrichtung und bussystem für ein kraftfahrzeug
DE102018119244A1 (de) Fahrzeugkommunikation
WO2016096599A1 (de) Verfahren und vorrichtung zum rückwirkungsfreien erfassen von daten
DE3719283A1 (de) Verfahren zur lokalisierung defekter stationen in lokalen netzwerken und dazugehoeriger schnittstellencontroller
DE102013201596A1 (de) Fehlerdetektion und -abschwächung für eine verwaltung eines fahrzeuginternen lan-netzes
DE112012006879T5 (de) Neuer Ansatz zum Handhaben eines Controller-Area-Network Bus-Off
DE112008000795B4 (de) In einem Fahrzeug verbaute Weiterleitungs-Verbindungseinheit
DE102015213378A1 (de) Verfahren und Gerät zum Diagnostizieren eines Netzes
WO2018077528A1 (de) Erkennung von manipulationen in einem can-netzwerk mittels überprüfung von can-identifiern
DE102017200958A1 (de) Betriebsmodus-übergangsverfahren in einem netz
DE102014111361A1 (de) Verfahren zum Betreiben einer Sicherheitssteuerung und Automatisierungsnetzwerk mit einer solchen Sicherheitssteuerung
EP3688951B1 (de) Verfahren zum erfassen eines angriffs auf ein steuergerät eines fahrzeugs
DE102012206529A1 (de) Drahtloses Echtzeitübertragungssystem
DE102010028485B4 (de) Verfahren und Vorrichtung zur Absicherung von über eine Schnittstelle zu übertragenden Datenpaketen
DE102020208536A1 (de) Gateway-vorrichtung, abnormitätsüberwachungsverfahren und speichermedium
DE102018211844B4 (de) Elektronische Anomalieerkennungseinheit zum Einsatz in einem Fahrzeug und Verfahren zum Erkennen einer Anomalie in einer Komponente eines Fahrzeugs
DE102021208459A1 (de) Verfahren zur authentischen Datenübertragung zwischen Steuergeräten eines Fahrzeugs, Anordnung mit Steuergeräten, Computerprogramm und Fahrzeug
DE102013204891B4 (de) Verfahren zur Rekonstruktion von Messdaten
DE102022124470B3 (de) Verfahren zur Steuerung einer Diagnosesession eines Fahrzeugs, Computerprogram, Vorrichtung und Fahrzeug
DE102018114218B4 (de) Verfahren zum Betreiben einer Sensoranordnung in einem Kraftfahrzeug auf Basis eines DSI-Protokolls
DE102020212452B3 (de) Verfahren zur Reduzierung der Auswirkungen von einer auf einem Kommunikationsbus eingeschleusten Botschaft
DE10347381B4 (de) Verfahren und Vorrichtung zur fehlerabgesicherten Übertragung von Nutzdaten
DE102022124382A1 (de) Erzeugen eines Indikators für das Angeben einer Güte einer Datenübertragung

Legal Events

Date Code Title Description
R012 Request for examination validly filed
R082 Change of representative

Representative=s name: MANITZ FINSTERWALD PATENT- UND RECHTSANWALTSPA, DE

R079 Amendment of ipc main class

Free format text: PREVIOUS MAIN CLASS: H04L0012260000

Ipc: H04L0043000000