DE102022213582A1 - Authentifizierungsgerät für ein Fahrzeug - Google Patents

Authentifizierungsgerät für ein Fahrzeug Download PDF

Info

Publication number
DE102022213582A1
DE102022213582A1 DE102022213582.2 DE102022213582A1 DE 102022213582 A1 DE102022213582 A1 DE 102022213582A1 DE 102022213582 A1 DE102022213582 A1 DE 102022213582A1
Authority
DE
Germany
Prior art keywords
network
authentication
validation value
network node
authentication device
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
DE102022213582.2
Other languages
English (en)
Inventor
Helge Zinner
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.)
Continental Automotive Technologies GmbH
Original Assignee
Continental Automotive Technologies GmbH
Filing date
Publication date
Application filed by Continental Automotive Technologies GmbH filed Critical Continental Automotive Technologies GmbH
Publication of DE102022213582A1 publication Critical patent/DE102022213582A1/de
Pending legal-status Critical Current

Links

Images

Abstract

Die Erfindung betrifft ein Authentifizierungsgerät (202), das zum Authentifizieren eines Netzwerks aus Netzwerkknoten für ein Fahrzeug (800) eingerichtet ist. Hierzu ist Authentifizierungsgerät (202) eingerichtet, einen Gesamtvalidierungswert einer addierbaren Größe von Authentifizierungsnachrichten über die Netzwerkknoten (204) zu ermitteln, den ermittelten Gesamtvalidierungswert mit einem von dem Authentifizierungsgerät (202) erwarteten Gesamtvalidierungswert zu vergleichen, und das Netzwerk (200) anhand des Vergleiches des erwarteten Gesamtvalidierungswertes mit dem ermittelten Gesamtvalidierungswert zu authentifizieren.

Description

  • Technisches Gebiet
  • Die Erfindung betrifft ein Authentifizierungsgerät für ein Fahrzeug, ein Netzwerkknoten, ein Verfahren zum Authentifizieren eines Netzwerks aus Netzwerkknoten für ein Fahrzeug, ein Programmelement und ein Speichermedium.
  • Stand der Technik
  • Mit dem teilautomatisierten und hochautomatisierten Fahren kommen zunehmend Anforderungen ins Fahrzeug, die vom Übertragungsnetzwerk und den Protokollen harte Echtzeitunterstützung verlangen. Den Datenmengen muss schnell vertraut werden können und die Integrität der Daten muss sichergestellt sein. Weiterhin wird ein Bordnetz in Zukunft viel flexibler als heute sein. Knoten werden während des Betriebes abgeschaltet, wenn sie nicht benötigt werden. Das wiederum bedeutet, dass sich das Bordnetz dynamisch zur Laufzeit sehr stark ändern wird. Hardware Plug 'n'Play von Sensoren wird ein immer wichtigeres Thema. In Fahrzeugen kann daher eine Veränderung in der Kommunikation, ein Angriff über den Diagnosezugang, ein manipuliertes Steuergerät sowie auch ausgetauschte Steuergeräte immer schwerer erkannt werden.
  • Eine Aufgabe der Erfindung ist es, eine verbesserte Authentifizierung eines Netzwerks für ein Fahrzeug bereitzustellen.
  • Die Aufgabe wird durch die Gegenstände der unabhängigen Patentansprüche gelöst. Vorteilhafte Ausführungsformen sind Gegenstand der abhängigen Ansprüche, der folgenden Beschreibung, sowie der Figuren.
  • Die beschriebenen Ausführungsformen betreffen in ähnlicher Weise das Authentifizierungsgerät für ein Fahrzeug, den Netzwerkknoten, das Verfahren zum Authentifizieren eines Netzwerks aus Netzwerkknoten für ein Fahrzeug, das Programmelement und das Speichermedium. Synergieeffekte können sich aus verschiedenen Kombinationen der Ausführungsformen ergeben, obwohl sie möglicherweise nicht im Detail beschrieben werden.
  • Ferner ist zu beachten, dass alle Ausführungsformen der vorliegenden Erfindung, die ein Verfahren betreffen, in der beschriebenen Reihenfolge der Schritte ausgeführt werden können, jedoch muss dies nicht die einzige und wesentliche Reihenfolge der Schritte des Verfahrens sein. Die hier vorgestellten Verfahren können mit einer anderen Reihenfolge der offenbarten Schritte ausgeführt werden, ohne von der jeweiligen Verfahrensausführungsform abzuweichen, sofern im Folgenden nicht ausdrücklich etwas Anderes angegeben ist.
  • Gemäß einem ersten Aspekt wird ein Authentifizierungsgerät bereitgestellt, das zum Authentifizieren eines Netzwerks aus Netzwerkknoten für ein Fahrzeug eingerichtet ist. Das Authentifizierungsgerät ist eingerichtet, einen Gesamtvalidierungswert einer addierbaren Größe von Authentifizierungsnachrichten über die Netzwerkknoten zu ermitteln, den ermittelten Gesamtvalidierungswert mit einem von dem Authentifizierungsgerät erwarteten Gesamtvalidierungswert zu vergleichen, und das Netzwerk anhand des Vergleiches des erwarteten Gesamtvalidierungswertes mit dem ermittelten Gesamtvalidierungswert zu authentifizieren.
  • Die Authentifizierungsnachrichten sind hierbei beispielsweise spezielle Nachrichten, die nur zur Authentifizierung erzeugt und gesendet werden. Das Authentifizierungsgerät kann einer der Netzwerkknoten sein, das, z.B. zusätzlich oder dediziert, besondere für die Authentifizierung notwendige Dienste oder Programmelemente aufweist.
  • Eine solche Authentifizierung kann beispielsweise bei einem Setup oder Starten bzw. Hochfahren des Netzwerkes oder bei jeglicher Manipulation des Netzwerkes durchgeführt werden. Eine Manipulation ist z.B. der Austausch eines Netzwerkknotens oder ein Software-Update. Ein Software-Update kann hierbei eine Konfiguration betreffen oder eine Aktualisierung eines Programms oder eines Programmteils, wie zum Beispiel einer dynamischen Bibliotheksdatei.
  • Gemäß einer Ausführungsform ist der Validierungswert eine Nachrichtenlänge oder eine Laufzeit. Eine Nachrichtenlänge kann beispielsweise eine Anzahl an Übertragungseinheiten wie z.B. Bits oder Symbole sein. Eine Laufzeit kann aus der Anzahl an Übertragungseinheiten und der Übertragungsgeschwindigkeit ergeben und z.B. durch eine Messung oder Bestimmung der empfangenen Bits ermittelt werden.
  • In einem Beispiel ist der Validierungswert ausschließlich eine Nachrichtenlänge oder ausschließlich eine Laufzeit.
  • Das Authentifizierungsgerät und die Netzwerkknoten sind beispielsweise über einen Netzwerkbus, hierin, das heißt, in dieser Offenbarung, auch kurz als Bus bezeichnet, miteinander verbunden. Die Authentifizierungsnachrichten können zum Beispiel einen Header mit einer ID zur Identifizierung des Nachrichtentyps aufweisen. Der Nachrichtenkörper, also der Inhalt der Nachricht bzw. die sog. „Payload“ ist belanglos und muss nicht dekodiert werden. Maßgeblich ist lediglich die Länge der Nachricht, die sich beispielweise durch die Anzahl der Bits der Payload oder die Gesamtzahl der Bits der Nachricht definiert. Die Laufzeit ergibt sich dann aus der Anzahl der Bits und der Übertragungsgeschwindigkeit.
  • Gemäß einer Ausführungsform ist das Authentifizierungsgerät eingerichtet, ein Beacon zu senden, wobei das Beacon die Aufforderung an einen ersten Netzwerkknoten ist, eine Authentifizierungsnachricht zu generieren und zu senden, und wobei das Authentifizierungsgerät eingerichtet ist, eine Authentifizierungsnachricht von einem zweiten Netzwerkknoten, der unterschiedlich zum ersten Netzwerkknoten ist, zu empfangen, und eingerichtet ist, einen Gesamtvalidierungswert zu ermitteln, wobei der Gesamtvalidierungswert den addierten Validierungswerten der Authentifizierungsnachrichten des ersten Netzwerkknotens und des zweiten Netzwerkknotens entspricht.
  • Das heißt, dass das Senden des Beacons zur Folge hat, dass der erste Netzwerkknoten eine Authentifizierungsnachricht sendet. Das Authentifizierungsgerät wartet, bis es eine Authentifizierungsnachricht von dem zweiten Netzwerkknoten empfängt und ermittelt einen addierten Validierungswert aus den Authentifizierungsnachrichten des ersten Netzwerkknotens und des zweiten Netzwerkknotens. Daraus folgt implizit, dass, um einen addierten Validierungswert zu erhalten, der zweite Netzwerkknoten die Nachricht nach dem zweiten Netzwerkknoten schickt, um die Addition zu ermöglichen, und das Authentifizierungsgerät eine addierte Größe wie eine Gesamtlaufzeit oder eine Gesamtlänge ermitteln kann. Das Authentifizierungsgerät kann hierbei eingerichtet sein, selbst eine Addition vorzunehmen oder eine Zeit zu messen, bis es die Nachricht des zweiten Knotens empfangen hat. Diese entsteht durch das serielle Senden der Authentifizierungsnachrichten über den ersten und den zweiten Netzwerkknoten. Es sei angemerkt, dass zwischen dem ersten und dem zweiten Netzwerkknoten noch weitere Netzwerkknoten liegen können, deren Validierungswerte sich dann zu denen des ersten und des zweiten Netzwerkknotens hinzuaddieren können. Die ermittelte Laufzeit oder „Gesamtlaufzeit“ kann hierbei Offsets enthalten, die an den Netzwerkknoten oder durch das Senden des Beacons entstehen, die teils physikalischer Natur sein können sowie teils durch die Datenprozessierung oder Vorgaben z.B. durch einen Standard entstehen.
  • Sobald das Authentifizierungsgerät eine Authentifizierungsnachricht empfangen hat, kann es erneut ein Beacon senden. Ein solcher Authentifizierungsvorgang bildet einen Zyklus ab, der in dieser Offenbarung als solcher bezeichnet wird. Die Dauer bzw. der Zeitraum dieses Zyklus entspricht als Größe dem Gesamtvalidierungswert und wird hierin auch als Zykluslänge bezeichnet.
  • Gemäß einer Ausführungsform ist das Authentifizierungsgerät ein Netzwerkknoten, ein Busmaster und/oder ein Gateway. Es kann aber auch z.B. ein Steuergerät sein, das die entsprechenden Voraussetzungen aufweist.
  • Gemäß einem zweiten Aspekt wird ein Netzwerkknoten eines Netzwerkes für ein Fahrzeug bereitgestellt, wobei der Netzwerkknoten eingerichtet ist, für eine Authentifizierung des Netzwerkes ein Beacon oder eine Authentifizierungsnachricht zu empfangen, eine Authentifizierungsnachricht zu generieren, die bezüglich der Authentifizierung durch einen Validierungswert einer addierbaren Größe der Authentifizierungsnachrichten definiert ist, und die erzeugte Authentifizierungsnachricht zu senden.
  • Wie bereits erwähnt, kann der Validierungswert eine Nachrichtenlänge oder eine Laufzeit sein, und insbesondere ausschließlich eine dieser Größen sein.
  • Hier wird in erster Linie ein Netzwerk betrachtet, das einen Netzwerkbus aufweist, auf dem nur immer ein Knoten senden darf. Der Netzwerkknoten ist beispielsweise weiterhin eingerichtet, die Authentifizierungsnachricht dann über den Bus zu senden, wenn er an der Reihe ist. Dies ist z.B. dann der Fall, nachdem ein Vorgänger-Knoten mit einer ihm bekannten Adresse oder ID seine Nachricht gesendet hat. Die Adresse oder ID des VorgängerKnotens ist beispielsweise vorkonfiguriert, oder kann durch das Authentifizierungsgerät erhalten werden.
  • Auf diese Weise kann eine Kette gebildet werden, die mit dem Empfang eines Beacons beginnt und der Reihe nach über einen oder mehrere weitere Netzwerkknoten geht, um wieder bei dem Authentifizierungsgerät zu enden, welches die addierte Laufzeit oder die addierte Länge der Authentifizierungsnachrichten ermittelt. Im letzteren Fall könnte beispielsweise die Authentifizierungsnachricht, bzw. deren Payload, des vorhergehenden Netzwerkknotens an die vom aktuellen Netzwerkknoten generierte Authentifizierungsnachricht angehängt werden oder das Authentifizierungsgerät ermittelt die Länge der Authentifizierungsnachrichten bei jedem Senden eines an der Authentifizierung beteiligten Knotens und addiert die Längen nach und nach auf.
  • Gemäß einer Ausführungsform ist der Netzwerkknoten ein Steuergerät (ECU, electronic control unit), ein Sensor, ein Anzeigegerät, ein Aktuator oder ein anderes netzwerkfähiges Gerät. In allen Fällen muss der Netzwerkknoten eine Hardwarelogik und/oder eine Softwarelogik aufweisen, die die Authentifizierungsnachrichten generieren und senden kann.
  • Gemäß einem dritten Aspekt wird ein Netzwerk bereitgestellt, das ein hierin beschriebenes Authentifizierungsgerät und mindestens einen hierin beschriebenen Netzwerkknoten aufweist. Das Netzwerk kann weiterhin einen Netzwerkbus aufweisen und ist nicht beschränkt auf ein Authentifizierungsgerät.
  • In einer Variante kann in dem Netzwerk ein oder können mehrere weitere Authentifizierungsgeräte vorhanden sein. Das Beacon ist ein netzwerkweites Signal oder eine netzwerkweite Nachricht, die von allen Netzwerkknoten empfangen werden kann. Ist ein weiteres Authentifizierungsgerät in dem Netzwerk vorhanden, das auch eine für sich gültige Gesamtvalidierungsgröße kennt, kann es ebenfalls eine Authentifizierung vornehmen. In diesem Fall ist das Start-Authentifizierungsgerät von dem die Authentifizierung vornehmenden Gerät unterschiedlich. In einer weiteren Variante kann das weitere Authentifizierungsgerät Teil der Kette sein, also sozusagen eine Zwischenauthentifizierungsstation, die selbst wieder eine Authentifizierungsnachricht sendet. So können in der Kette mehrere Authentifizierungsgeräte vorhanden sein.
  • Das Authentifizierungsgerät, z.B. ein Bus-Master, kann somit eingerichtet sein, die letzte Authentifizierungsnachricht der Kette zu empfangen, und für die Authentifizierung den Validierungswert einer addierbaren Größe der Authentifizierungsnachrichten zu erfassen.
  • Gemäß einer Ausführungsform ist der Validierungswert der Authentifizierungsnachrichten für jeden Netzwerkknoten individuell. Der Netzwerkknoten kann mit einem Validierungswert statisch oder dynamisch konfiguriert werden, wobei die Validierungswerte in der Regel von Netzwerkknoten zu Netzwerkknoten unterschiedlich sind.
  • Gemäß einer Ausführungsform weist das Netzwerk weitere Netzwerkknoten auf, und das Authentifizierungsgerät ist eingerichtet, nach einem dynamisch generierten oder einem abgespeicherten Sicherheits-Muster zu bestimmen, welcher Netzwerkknoten Teil der Kette ist.
  • Gemäß einer Ausführungsform enthält das Sicherheits-Muster weiterhin einen oder mehrere der folgenden Werte: individueller Validierungswert für jeden Netzwerkknoten, ID des vorhergehenden Netzwerkknotens.
  • Das heißt, dass der Validierungswert für einen Netzwerkknoten und ein Empfängerknoten vorkonfiguriert sein können. Der Validierungswert, z.B. die individuelle Länge einer Authentifizierungsnachricht eines Netzwerkknotens, kann beispielsweise vor der Auslieferung konfiguriert werden, so dass der individuelle Wert nur den jeweils betreffenden Netzwerkknoten bekannt ist. Weiterhin kennt jeder Netzwerkknoten nur den Vorgängerknoten, welcher vorkonfiguriert ist oder ihm dynamisch mitgeteilt wird.
  • Das Authentifizierungsgerät kann somit eingerichtet sein, den Validierungswert an die Netzwerkknoten zu senden. Dies erhöht die Flexibilität. Eine Sicherheit ist dadurch geboten, dass, solange eine schädliche Einrichtung nicht die Gesamtlaufzeit oder die Gesamtlänge kennt, diesem nicht möglich ist, einen einzelnen z.B. schädlichen Netzwerkknoten oder alle Netzwerkknoten mit Validierungswerten zu konfigurieren, die einen validen Gesamtvalidierungswert ergeben. Es muss lediglich sichergestellt sein, dass die Gesamtlaufzeit oder die Gesamtlänge der Authentifizierungsnachrichten geheim bleibt und nicht manipuliert werden kann, und dass der Validierungswert eines Netzwerkknotens nicht, z. B., wenn dieser dem Netzwerk entnommen und von einem Angreifer analysiert wird, ausgelesen werden kann. Da das Netzwerk nach vor z.B. einem Austausch eines Netzwerkknotens mit einem schädlichen Netzwerkknoten sicher ist, kann auch davon ausgegangen werden, dass keine schädliche Software in dem Netzwerk vorhanden ist, die während der Laufzeit die Validierungswerte auslesen kann.
  • Prinzipiell könnte das Netzwerk aus dem Authentifizierungsgerät und einem oder mehreren Netzwerkknoten bestehen. Es könnten aber auch mehrere solche Netzwerke oder Subnetzwerke nebeneinander bestehen. Hierdurch könnte ein schädliches Gerät direkt identifiziert werden oder zumindest eingegrenzt werden.
  • Gemäß einer Ausführungsform basiert das Netzwerk auf einer physikalischen Schicht nach einem Ethernet-Standard.
  • Zu den Ethernet-Standardisierungen, die für Automotive-Anwendungen zur Verfügung stehen gehören beispielsweise der 10 Mbit/s- IEEEP802.3cg Standard, oder Standardisierungen mit 100 Mbit/s, 1000 Mbit/s, oder auch 2.5, 5, 10 Gbit/s). Eine Variante des IEEEP802.3ch-Standards ist der auf CSMA/CD basierende MultiDrop-Modus, bei dem keine Switches (Switch ICs) benötigt werden, sondern der als Bus ausgelegt wird. Der Standard IEEE P802.3cg verwendet unter anderem einen Mechanismus (PLCA, Physical Layer Collision Avoidance) um Kollisionen beim Buszugriff zu vermeiden und einen fairen Zugriff zu bekommen. Dabei erhält immer nur genau ein PHY (Transceiver) zu genau einem Zeitpunkt Zugriff auf den Bus. Hierdurch kann es nicht zu Kollisionen kommen. Der Zugriff wird nach einem sog. Round Robin Verfahren gestaltet. Jedes Steuergerät (ECU, electronic control unit) bzw. jeder Knoten am Bus bekommt die Möglichkeit, innerhalb eines definierten Zyklus (bzw. Reihenfolge) zu senden. Ein sog. Headnode bestimmt dabei den Zyklus und sendet wiederkehrend „Beacons“ auf dem Bus. Damit starten die Knoten in Abhängigkeit der ihnen bekannten ID des Vorgängerknotens, die die Reihenfolgen bestimmt, wann sie senden dürfen, einen Timer und senden ihrerseits nach Ablauf des Timers sowie der Erkennung, dass sie an der Reihe sind.
  • Gemäß einem Aspekt wird ein Verfahren zum Authentifizieren eines Netzwerks aus Netzwerkknoten für ein Fahrzeug bereitgestellt. Das Verfahren weist folgende Schritte auf:
    • Ermitteln eines Gesamtvalidierungswertes einer addierbaren Größe von Authentifizierungsnachrichten über die Netzwerkknoten;
    • Vergleichen des Gesamtvalidierungswertes mit einer erwarteten Gesamtvalidierungswert;
    • Authentifizieren des Netzwerkes anhand des Vergleiches der erwarteten Laufzeit mit der ermittelten Laufzeit.
  • Das Verfahren stellt somit einen Mechanismus bereit, bei dem alle Steuergeräte zusammen eine Art Blockchain bilden und darüber authentifiziert werden. Sollte nur ein Knoten eine minimale Änderung an der Kommunikation vornehmen, so kann das ein Authentifizierungsgerät und den Bus beispielsweise als unsicher klassifizieren.
  • Gemäß einem weiteren Aspekt wird ein Programmelement bereitgestellt, das, wenn es auf einem Prozessor des Authentifizierungsgeräts ausgeführt wird, das Authentifizierungsgerät anweist, die Schritte des oben beschriebenen Verfahrens durchzuführen.
  • Das Computerprogrammelement kann Teil eines Computerprogramms sein, es kann jedoch auch ein ganzes Programm für sich sein. Beispielsweise kann das Computerprogrammelement verwendet werden, um ein bereits vorhandenes Computerprogramm zu aktualisieren, um zur vorliegenden Erfindung zu gelangen.
  • Gemäß einem weiteren Aspekt wird ein Speichermedium bereitgestellt, auf dem das Programmelement gespeichert ist.
  • Das computerlesbare Medium kann als ein Speichermedium angesehen werden, wie beispielsweise ein USB-Stick, eine CD, eine DVD, ein Datenspeichergerät, eine Festplatte oder ein beliebiges anderes Medium, auf dem sich ein Programmelement wie oben beschrieben befinden kann gelagert.
  • Durch die Erfindung kann beispielsweise eine Veränderung des Netzwerks, wie z.B. ein Angriff über den OBD-Zugang, ein Austausch oder eine Manipulation eines Steuergerätes oder ein Zugriff auf sicherheitskritische Steuergeräte über OBD oder Infotainment erkannt werden. Weiterhin können Angriffe wie zum Beispiel Hackerangriffe auf Fahrzeugnetze und Diebstahl erkannt und verhindert werden. Ferner können Sensoren und Sensordaten authentifiziert werden.
  • Andere Variationen der offenbarten Ausführungsformen können vom Fachmann bei der Durchführung der beanspruchten Erfindung durch das Studium der Zeichnungen, der Offenbarung und der beigefügten Ansprüche verstanden und ausgeführt werden. In den Ansprüchen schließt das Wort „umfassend“ andere Elemente oder Schritte nicht aus, und der unbestimmte Artikel „ein“ oder „eine“ schließt eine Vielzahl nicht aus. Ein einzelner Prozessor oder eine andere Einheit kann die Funktionen mehrerer Gegenstände oder Schritte erfüllen, die in den Ansprüchen aufgeführt sind. Die bloße Tatsache, dass bestimmte Maßnahmen in voneinander abhängigen Ansprüchen angegeben sind, bedeutet nicht, dass eine Kombination dieser Maßnahmen nicht vorteilhaft genutzt werden kann. Ein Computerprogramm kann auf einem geeigneten Medium wie einem optischen Speichermedium oder einem Halbleitermedium, das zusammen mit oder als Teil einer anderen Hardware geliefert wird, gespeichert / verteilt werden, kann aber auch in anderen Formen, beispielsweise über das Internet oder andere drahtgebundene oder drahtlose Telekommunikationssysteme verteilt sein. Bezugszeichen in den Ansprüchen sollten nicht so ausgelegt werden, dass sie den Umfang der Ansprüche begrenzen.
  • Kurze Beschreibung der Zeichnungen
  • Im Folgenden werden Ausführungsbeispiele der Erfindung anhand der schematischen Zeichnungen näher erläutert. Hierbei zeigt
    • 1A ein Diagramm eines ersten Beispielszenarios,
    • 1B ein Diagramm eines zweiten Beispielszenarios,
    • 2 ein Blockdiagramm eines Netzwerks gemäß einem Ausführungsbeispiel,
    • 3 ein Ablaufdiagramm eines Verfahrens zum Authentifizieren eines Netzwerks,
    • 4A ein Diagramm eines validen Bus-Zyklus,
    • 4B ein Diagramm eines fehlerhaften Bus-Zyklus,
    • 5 ein Ablaufdiagramm des Verfahrens mit weiteren Schritten,
    • 6 ein Ablaufdiagramm des Verfahrens mit Fokus Sicherheitsmuster,
    • 7A ein erstes Sicherheitsmusterbeispiel,
    • 7B ein zweites Sicherheitsmusterbeispiel,
    • 8 ein Fahrzeug mit einem Netzwerk gemäß einem Ausführungsbeispiel.
  • Einander entsprechende Teile sind in allen Figuren mit den gleichen Bezugszeichen versehen.
  • Ausführungsformen
  • 1A zeigt in ein Diagramm eines Beispielszenarios, bei dem in eine bestehende Kommunikationsverbindung 108 auf einem Netzwerkbus eingegriffen wird. In den Datenstrom zu einer ECU 102 wird zwischen den regulären Datenpaketen 104 ein zusätzliches Datenpaket 106 einer Schadsoftware eingefügt. Der Absender des Datenstroms einschließlich des zusätzlichen Datenpakets 106 ist derselbe. Ein solches Datenpaket in einer Authentifizierungsnachricht würde deren Länge verändern und damit erkannt werden.
  • 1B zeigt ein Diagramm eines zweiten Szenarios mit einer Manipulation von Steuergeräten, bei der ein Steuergerät 114 ausgetauscht wird. Im regulären Fall kommuniziert die ECU A 102 über die Transceiver 110 und 112 mit der ECU B 114. Die ECU B 114 könnte in einem Angriffsszenario durch eine ECU B' 116 mit Transceiver 118 ausgetauscht werden, um beispielsweise eine Wegfahrsperre zu umgehen oder die Motorsteuerung zu manipulieren. Aus Sicht der Anwendung kann nicht erkannt werden, dass es sich um ein ausgetauschtes Steuergerät ECU B' 116 handelt. Das Steuergerät ECU B' 116 kann beispielsweise den ursprünglichen Namen wie zum Beispiel eine ID, eine IP-Adresse oder eine Bussystemadresse, des ursprünglichen Steuergerätes ECU B 114 annehmen und ist dadurch für die Software unsichtbar. Dies stellt eine potentielle Gefahr dar und kann auch Sensoren und Aktuatoren betreffen.
  • In einem weiteren Beispielszenario soll ein Übersprung von zum Beispiel einer Infotainment Domain eines-ECU Servers bzw. Domain Controllers in eine Fahrerassistenzsystem- (ADAS, Advanced Driver Assistance Systems) Domain verhindert werden.
  • 2 zeigt ein Blockdiagramm eines Netzwerks, aufweisend ein Authentifizierungsgerät 202 und mehrere Netzwerkknoten 204 sowie einen Netzwerkbus 206.
  • 3 zeigt ein Blockdiagramm eines Verfahrens 300 zum Authentifizieren eines Netzwerks aus Netzwerkknoten für ein Fahrzeug, aufweisend die Schritte:
    • Ermitteln 302 eines Gesamtvalidierungswerts einer addierbaren Größe von Authentifizierungsnachrichten über die Netzwerkknoten, Vergleichen 304 des ermittelten Gesamtvalidierungswerts mit einem erwarteten Gesamtvalidierungswert, und Authentifizieren 306 des Netzwerkes anhand des Vergleiches des erwarteten Gesamtvalidierungswerts mit dem ermittelten Gesamtvalidierungswert.
  • 4A und 4B zeigen in einem Fall, in welchem den Netzwerkknoten N0, N1, N2, N3 die Gesamtlaufzeit 410 bekannt ist, die Auswirkungen von Angriffen und nicht authentifizierten Geräten auf den Bus. Wenn ein Knoten 414, 416 neu oder zusätzlich hinzukommt, verändert sich die Gesamtlaufzeit 410, 420 und verschiebt das Senden des nächsten Beacons 408, 418 um eine Differenz 424, so dass eine Abweichung zur erwarteten Gesamtlaufzeit 410 erkannt werden kann. Jeder interessierte Knoten kann diese Verschiebung erkennen.
  • In 4A ist das sichere Szenario dargestellt. Jeder Netzwerkknoten, z.B. ein Steuergerät, ein Sensor oder ein Aktuator, folgt dem Muster und schickt genau die Nachricht in der richtigen Größe (z. B. 200 Byte). Die Summe aller Datenpakete bzw. Nachrichtenlängen in dem Zyklus (gesendet und auch nicht gesendet) definiert dann die Zykluslänge 410, d.h. den Gesamtvalidierungswert, und damit auch den Zeitpunkt der Aussendung des nächsten Beacons 408, 410, welcher von allen Teilnehmern N0, N1, N2, N3 empfangen wird. Hierbei ist keine Synchronisation notwendig, da jeder Netzwerkknoten sofort sendet, wenn der Bus frei ist (unter Beachtung der vorgegebenen Reihenfolge). Somit funktioniert das Verfahren ohne dass eine präzise Abstimmung über den Sendezyklus vorhanden sein muss. In 4B ist ein Fall abgebildet, bei dem ein Angriff oder ein Fehler vorliegt. Ein oder mehrere Teilnehmer, d.h. Netzwerkknoten 414, 416, sind betroffen und verhalten sich anders als durch das Sicherheits-Muster definiert. Dadurch ist zwar zunächst die Buskommunikation nicht betroffen. Jedoch wird die eigentlich Zykluslänge beeinflusst und weicht deutlich von der vorher definierten ab. Dies kann dann als Problem identifiziert werden. Hierbei muss kein Netzwerkknoten das übergreifende Muster kennen, bzw. Kenntnis über die Daten der anderen Netzwerkknoten haben, was ein besonderer Vorteil des Verfahrens ist. Die Netzwerkknoten haben z.B. lediglich Kenntnis über den Beginn des nächsten Zyklus. Das Verfahren ist somit auch insbesondere für ein stark verteiltes System geeignet. Zum Zeitpunkt der Aussendung des neuen Beacons 408, der vom Authentifizierungsgerät bzw. Master ausgesendet wird, weiß dann jeder Netzwerkknoten, ob der Bus als sicher angesehen werden kann oder nicht.
  • Das in 3 vorgestellte Verfahren 300 kann Teil einer Netzwerkprozedur mit weiteren Schritten sein, die folgende Schritte aufweist, wie in 5 gezeigt:
    • In Schritt 502 wird der Netzwerkbus initialisiert.
    • In Schritt 504 wir der Anzahl der sendefähigen Busteilnehmer, d.h. die hier beschriebenen Netzwerkknoten bestimmt.
    • In Schritt 506 wird ein Sicherheits-Muster definiert. Das Sicherheitsmuster enthält zum Beispiel die individuellen Validierungswerte wie zum Beispiel die Laufzeit oder Länge der Authentifizierungsnachricht. Diese können beispielsweise mittels eines Zufallsgenerators festgelegt werden. Das Sicherheits-Muster kann weiterhin definieren, in welcher Reihenfolge die Netzwerkknoten ihre Authentifizierungsnachricht senden. Die Netzwerkknoten bilden somit eine Kette mit beispielsweise dem Authentifizierungsgerät als Anfangs- und Endglied, wobei das Authentifizierungsgerät selbst keine Authentifizierungsnachricht generiert und sendet. Alternativ gibt es weitere Authentifizierungsgeräte in der Kette, die nicht notwendigerweise ein Sicherheitsmuster generieren und verteilen, sondern dieses von dem Master des Busses erhalten.
    • In Schritt 508 wird der Gesamtvalidierungswert anhand des Musters berechnet. Alternativ kann z.B. auch erst ein Gesamtvalidierungswert festgelegt werden oder bereits konfiguriert sein und das Sicherheitsmuster in Schritt 506 wird unter der Bedingung dieses festgelegten Gesamtvalidierungswerts definiert. Der Gesamtvalidierungswert kann optional an alle Netzwerkknoten übermittelt werden. In einer Alternative kann der Gesamtvalidierungswert einem Teil der Netzwerkknoten übermittelt werden, die dann auch eine Authentifizierung vornehmen können.
    • In Schritt 510 wird das Sicherheits-Muster z.B. in individueller Form an die Netzwerkknoten gesendet. Das heißt, den Netzwerkknoten wird z.B. jeweils die Länge der zu generierenden Authentifizierungsnachricht und die ID des Vorgängerknotens gesendet. Alternativ können die Schritte 504 bis 510 oder ein Teil dieser Schritte durch eine Vorkonfiguration ersetzt werden. Die Reihenfolge der Schritte 510 und 508 können auch vertauscht sein.
    • In Schritt 512 wird ein Beacon gesendet, durch welches das Senden der Authentifizierungsnachrichten gestartet wird.
    • In Schritt 514 werden die von Authentifizierungsnachrichten durch die Netzwerkknoten in der definierten Reihenfolge gemäß dem jeweiligen Validierungswert generiert und gesendet. Das heißt, jeder Knoten am Bus sendet beispielsweise nach dem Aufstart bzw. Initialisierung oder nach dem Fahrzeugstart ein vordefiniertes Datenpaket. Hierbei ist nur die Größe des Paketes relevant und nicht der Inhalt. Hierdurch lässt sich implizit der Buszyklus abbilden. Erst nachdem ein Knoten gesendet hat, darf der nächste Knoten senden usw. Wenn alle Knoten an der Reihe waren, kann der Master einen neuen Beacon zum Start eines neuen Zyklus aussenden wobei der Zeitpunkt des Versandes dieses neuen Beacons somit ausschließlich von der Summe der Verzögerungen der Knoten abhängt. Somit hat jeder Teilnehmer einen direkten Einfluss auf diesen Zeitpunkt. Der nächste Beacon-Zeitpunkt kann daher genau vorhergesagt werden.
    • In Schritt 516 erfolgt die Validierung des Gesamtvalidierungswerts, d.h. die Durchführung der Authentifizierung und Prüfung des Gesamtvalidierungswerts gemäß dem Verfahren 300.
    • Die Schritte 504 bis 512 sowie 516 können zum Beispiel durch das Authentifizierungsgerät ausgeführt werden.
  • 5 stellt somit auch den Vorgang der Busidentifikation und der Musterdefinition und Übermittlung dar. Es kann verschiedene Zeitpunkte zur Prüfung der Authentifizierung geben. Hierbei kann es sich um eine sog. „Klemme 30“ handeln, also wenn die Stromversorgung verbunden wird, oder einen Service, ein Plug'n'Play eines neuen Steuergerätes, oder zu jedem beliebigen anderen Zeitpunkt handeln, welcher entweder fest konfiguriert ist oder den Teilnehmern dynamisch am Bus mitgeteilt wird.
  • Um die Zykluslänge zu definieren, ist Kenntnis über die Anzahl der Teilnehmer notwendig - also welche Steuergeräte in das Sicherheitsverfahren miteinbezogen werden, resp. welche Steuergeräte geprüft werden sollen. Beispielsweise könnten immer alle einbezogen werden oder auch nur ein Subset der angeschlossenen Teilnehmer. Beim Subset kann es sich um Steuergeräte handeln, die entweder besonders sicherheitskritisch sind, um Geräte mit Überwachungsfunktion oder auch nur um Geräte, die an dem Verfahren technisch teilnehmen können. Dies ist in 6 dargestellt. Weiterhin soll auch mit einbezogen werden, welche Steuergeräte zur Überwachung, d.h. als Authentifizierungsgerät dienen.
  • 6 zeigt ein Ablaufdiagramm des Verfahrens mit Fokus auf die Erstellung und Übermittlung des Sicherheitsmusters. Die Referenzzeichen sind zu 5 in Bezug gesetzt. Der Schritt 504 ist aufgeteilt in zwei Teilschritte 602 und 604. Demgemäß wird in 602 bestimmt, welche Steuergeräte bzw. Teilnehmer durch das Verfahren überprüft werden sollen. Dies sind beispielsweise neu verbundene Steuergeräte, Steuergeräte, die sich im Schlafmodus befunden haben, Steuergerät mit online-Verbindung, mehreren Schnittstellen, etc. In Schritt 604 werden die Steuergeräte bestimmt, die über das Sicherheitsergebnis in Kenntnis gesetzt werden sollen, wie zum Beispiel nur der Busmaster, alle Steuergeräte oder Diagnosegeräte, etc. In Schritt 508 bestimmt das Verfahren entweder dynamisch ein Sicherheits-Muster oder benutzt ein bereits abgespeichertes und vorkonfiguriertes Muster. Das Muster definiert, welcher Teilnehmer bzw. Netzwerkknoten (ECU, Sensor, Aktuator, etc.) eine Authentifizierungsnachricht sendet. Weiterhin definiert das Muster die Nachrichtenlängen, welche zu senden sind. Hierzu ist keine Zeitsynchronisation notwendig, denn die Steuergeräte senden der Reihe nach bzw. wenn der vorherige seine Authentifizierungsnachricht gesendet hat. In Schritt 510 wird die Zykluslänge bzw. der Gesamtvalidierungswert berechnet. In Schritt 612 wird entschieden, ob weitere Steuergeräte in Kenntnis gesetzt werden. Falls nur der Busmaster als Authentifizierungsgerät, beispielsweise das Gateway, den Bus überwachen soll, wird in Schritt 616 nur das Muster übermittelt. Die Zykluslänge muss in diesem Fall nicht übermittelt werden. Andernfalls, d.h., sollten weitere Steuergeräte zur Überprüfung hinzugezogen werden, kann in Schritt 614 erst die Zykluslänge übermittelt werden und anschließend zu Schritt 616 gegangen werden, um das Muster zu übermitteln. Dies ist selbst keine vertrauliche Information, da ein Angreifer mit der eigentlichen Zahl bzw. dem Wert nichts anfangen kann. Erst wenn die Kombination aller Steuergeräte bekannt ist, kann der Gesamtvalidierungswert erreicht werden.
  • 7A und 7B zeigen zwei Beispiele für ein Sicherheits-Muster 702. In dem in 7A gezeigten Muster 702 senden (Tx) die Knoten 0,1,5,7 und 8 eine Authentifizierungsnachricht mit der angegebenen Länge L in Byte, während alle anderen Knoten keine Authentifizierungsnachricht senden. Die Knoten, die keine Authentifizierungsnachricht senden, sind hierbei auch Teil des Musters 702, da auch das Nichtsenden die Zykluslänge beeinflusst. Der Vorteil daran ist, dass das Muster 702 nicht vollständig verteilt bzw. bekannt sein muss, sondern nur der jeweilige Knoten muss seine eigenen Werte kennen. In 7B senden die Knoten 1,3,5 und 8 eine Authentifizierungsnachricht. Die Längen L unterscheiden sich hierbei teilweise von denen des Musters 702 in 7A.
  • Die Sicherheitsstufe funktioniert in Kombination aller Teilnehmer, ähnlich zu einem auf Blockchain basierten System. Das applizierte Muster bestimmt dann eindeutig die Zykluslänge. Hier sind verschiedene Muster möglich. In einem ersten Beispiel ist das Muster ein statisches Muster, das verschlüsselt und programmiert vorliegt. In einem zweiten Beispiel ist das Muster ein dynamisch erstelltes Muster. In einem dritten Beispiel basiert das Muster auf vordefinierten Parametern wie beispielsweise der aktuellen Uhrzeit. In einem vierten Beispiel basiert das Muster auf den MAC-Adressen der Teilnehmer.
  • In einem Ausführungsbeispiel gibt das Muster nicht direkt die Länge der Authentifizierungsnachricht an, sondern es kann einen oder mehrere Parameter enthalten, aus der der Netzwerkknoten die Länge abgeleitet werden kann. Beispielsweise sendet das Authentifizierungsgerät, das Master, ist, einen Parameter-Wert an den Netzwerkknoten, z.B. ein Steuergerät, den das Steuergerät zu den letzten beiden Ziffern seiner Mac-Adresse aufaddiert und dann als Länge für das nächste Datenpaket, hier gleichbedeutend mit der Authentifizierungsnachricht, verwendet. Das Muster kann auch in einem sicheren Speicherbereich fix kodiert sein und dann auf Anfrage hin abgefragt werden bzw. die Framelänge damit bestimmt werden.
  • 8 zeigt schematisch ein Fahrzeug 800 mit einem hierin beschriebenen Netzwerk 200, aufweisend ein Authentifizierungsgerät 202, mehrere Netzwerkknoten 204, sowie einen Netzwerkbus 206.
  • Durch das Verfahren wird es möglich, Angriffe schon in der Hardware zu blocken und damit gar nicht erst bis zur Software der ECU oder gar einer möglichen Weiterleitung gelangen zu lassen. Hierdurch werden Ressourcen wie auch mögliche Firewalls entlastet. Der Angreifer kann mit dem Verfahren nicht mehr ins System gelangen. Weiterhin können Angriffe nicht nur abgewehrt werden, sondern es kann auch schon der alleinige Versuch diagnostiziert werden. Das Verfahren bietet ferner eine weitere Methode, um nur autorisierten Zugang zum Fahrzeugbordnetz zu erlauben. Die gängige Hardware muss hierbei nicht verändert werden, sondern die bestehende kann weiterverwendet werden. Die benötigten Rechenkapazitäten sind gering, so dass ein Sicherheitsverfahren implementiert und auch nachträglich in den Flashspeicher geschrieben werden kann, ohne dabei die Systemressourcen (Speicher, Rechenleistung, Echtzeitfähigkeit) zu beeinflussen. Das Verfahren hat weiterhin den besonderen Vorteil, dass nicht aktiv in die Kommunikation eingegriffen werden muss. Das Sicherheitsverfahren kann still ausgeführt und überprüft werden. Zudem müssen auch nicht alle Steuergeräte am Verfahren teilnehmen. Das Verfahren kann zudem ich Echtzeit ausgewertet werden und bedarf keiner weiteren Berechnung oder Analyse in einer Cloud.

Claims (15)

  1. Authentifizierungsgerät (202), eingerichtet zum Authentifizieren eines Netzwerks (200) aus Netzwerkknoten (204) für ein Fahrzeug (800); wobei das Authentifizierungsgerät (202) eingerichtet ist, einen Gesamtvalidierungswert einer addierbaren Größe von Authentifizierungsnachrichten über die Netzwerkknoten (202) zu ermitteln, den ermittelten Gesamtvalidierungswert mit einem von dem Authentifizierungsgerät (202) erwarteten Gesamtvalidierungswert zu vergleichen, und das Netzwerk anhand des Vergleiches des erwarteten Gesamtvalidierungswertes mit dem ermittelten Gesamtvalidierungswert zu authentifizieren.
  2. Authentifizierungsgerät (202) nach Anspruch 1, wobei der Validierungswert eine Nachrichtenlänge oder eine Laufzeit ist.
  3. Authentifizierungsgerät (202) nach Anspruch 1 oder 2, wobei das Authentifizierungsgerät (202) eingerichtet ist, ein Beacon (402) zu senden, wobei das Beacon (402) die Aufforderung an einen ersten Netzwerkknoten ist, eine Authentifizierungsnachricht zu generieren und zu senden; eine Authentifizierungsnachricht von einem zweiten Netzwerkknoten (204), der unterschiedlich zum ersten Netzwerkknoten (204) ist, zu empfangen; und einen Gesamtvalidierungswert zu ermitteln, wobei der Gesamtvalidierungswert den addierten Validierungswerten der Authentifizierungsnachrichten des ersten Netzwerkknotens (204) und des zweiten Netzwerkknotens (204) entspricht.
  4. Authentifizierungsgerät (202) nach einem der Ansprüche 1 bis 3, wobei das Authentifizierungsgerät (202) ein Busmaster und/oder ein Gateway ist.
  5. Netzwerkknoten eines Netzwerkes für ein Fahrzeug (800), wobei der Netzwerkknoten eingerichtet ist, für eine Authentifizierung des Netzwerkes ein Beacon (402) oder eine Authentifizierungsnachricht zu empfangen; daraufhin eine eigene Authentifizierungsnachricht zu erzeugen, die bezüglich der Authentifizierung durch einen Validierungswert einer addierbaren Größe der Authentifizierungsnachrichten definiert ist; und die erzeugte Authentifizierungsnachricht zu senden.
  6. Netzwerkknoten nach Anspruch 5, wobei der Netzwerkknoten ein Steuergerät (ECU, electronic control unit), ein Sensor, oder ein Aktuator ist.
  7. Netzwerk (200), aufweisend ein Authentifizierungsgerät (202) nach einem der Ansprüche 1 bis 4; und mindestens einen Netzwerkknoten (204) nach Anspruch 5 oder 6.
  8. Netzwerk (200) nach Anspruch 7, wobei der Validierungswert der Authentifizierungsnachrichten für jeden Netzwerkknoten (204) individuell ist.
  9. Netzwerk (200) nach einem der Ansprüche 7 oder 8, wobei das Netzwerk (200) weitere Netzwerkknoten (204) aufweist, und wobei das Authentifizierungsgerät (202) eingerichtet ist, nach einem dynamisch generierten oder einem abgespeicherten Sicherheits-Muster (702) zu bestimmen, welcher Netzwerkknoten (204) Teil der Kette ist.
  10. Netzwerk (200) nach einem der Ansprüche 8 oder 9, wobei das Sicherheits-Muster weiterhin einen oder mehrere der folgenden Werte enthält: individueller Validierungswert für jeden Netzwerkknoten (202), ID des vorhergehenden Netzwerkknotens (202).
  11. Netzwerk (200) nach einem der Ansprüche 7 bis 10, wobei das Netzwerk (200) auf einer physikalischen Schicht nach einem Ethernet-Standard basiert.
  12. Verfahren (300) zum Authentifizieren eines Netzwerks (200) aus Netzwerkknoten für ein Fahrzeug (800), aufweisend die Schritte: Ermitteln (302) eines Gesamtvalidierungswerts einer addierbaren Größe von Authentifizierungsnachrichten über die Netzwerkknoten (204); Vergleichen (304) des ermittelten Gesamtvalidierungswerts mit einem erwarteten Gesamtvalidierungswert; Authentifizieren (306) des Netzwerkes anhand des Vergleiches des erwarteten Gesamtvalidierungswerts mit dem ermittelten Gesamtvalidierungswert.
  13. Programmelement, das, wenn es auf einem Prozessor des Authentifizierungsgeräts (202) nach einem der Ansprüche 1 bis 4 anweist, die Schritte des Verfahrens nach Anspruch 12 durchzuführen.
  14. Speichermedium, auf dem das Programmelement nach Anspruch 13 gespeichert ist.
  15. Fahrzeug, aufweisend ein Authentifizierungsgerät (202) nach einem der Ansprüche 1 bis 4.
DE102022213582.2 2022-12-13 Authentifizierungsgerät für ein Fahrzeug Pending DE102022213582A1 (de)

Publications (1)

Publication Number Publication Date
DE102022213582A1 true DE102022213582A1 (de) 2024-06-13

Family

ID=

Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
DE102012216689A1 (de) 2012-09-18 2014-05-28 Continental Automotive Gmbh Verfahren zur Überwachung eines Ethernet-basierten Kommunikationsnetzwerks in einem Kraftfahrzeug
DE102018213898A1 (de) 2018-08-17 2020-02-20 Continental Automotive Gmbh Überwachung einer Netzwerkverbindung auf Abhören
DE102019220096A1 (de) 2019-12-18 2021-06-24 Continental Automotive Gmbh Verfahren zur Absicherung der Zeitsynchronisation eines Ethernet-Bordnetzes
DE102021202075A1 (de) 2020-07-23 2022-01-27 Robert Bosch Gesellschaft mit beschränkter Haftung Verfahren zur Validierung von Nachrichten

Patent Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
DE102012216689A1 (de) 2012-09-18 2014-05-28 Continental Automotive Gmbh Verfahren zur Überwachung eines Ethernet-basierten Kommunikationsnetzwerks in einem Kraftfahrzeug
DE102018213898A1 (de) 2018-08-17 2020-02-20 Continental Automotive Gmbh Überwachung einer Netzwerkverbindung auf Abhören
DE102019220096A1 (de) 2019-12-18 2021-06-24 Continental Automotive Gmbh Verfahren zur Absicherung der Zeitsynchronisation eines Ethernet-Bordnetzes
DE102021202075A1 (de) 2020-07-23 2022-01-27 Robert Bosch Gesellschaft mit beschränkter Haftung Verfahren zur Validierung von Nachrichten

Similar Documents

Publication Publication Date Title
EP3278529B1 (de) Angriffserkennungsverfahren, angriffserkennungsvorrichtung und bussystem für ein kraftfahrzeug
EP3501154A1 (de) Bereitstellen einer gesicherten kommunikation innerhalb eines echtzeitfähigen kommunikationsnetzwerkes
DE102018120915A1 (de) Fahrzeuginterne Gruppenschlüsselverteilung
DE112016003907T5 (de) Weiterleitungsvorrichtung
DE102017107879A1 (de) Nachrichten-Authentifizierungsbibliothek
DE102019130502A1 (de) Fahrzeug und Verfahren für eine fahrzeuginterne Mitteilungsübertragung
WO2018077528A1 (de) Erkennung von manipulationen in einem can-netzwerk mittels überprüfung von can-identifiern
EP3542511A1 (de) Verfahren für ein kommunikationsnetzwerk und elektronische kontrolleinheit
WO2019063256A1 (de) System, insbesondere authentizitätssystem
DE102012215167A1 (de) Authentifizierung eines ersten Gerätes durch eine Vermittlungsstelle
EP3688951B1 (de) Verfahren zum erfassen eines angriffs auf ein steuergerät eines fahrzeugs
DE102016222741A1 (de) Verfahren für ein Kommunikationsnetzwerk und elektronische Kontrolleinheit
DE102012210327A1 (de) Verfahren zum Übertragen von Nachrichten in einem Kommunikationssystem, insbesondere eines Fahrzeugs
DE102019220096B4 (de) Verfahren zur Absicherung der Zeitsynchronisation eines Ethernet-Bordnetzes
DE102020125262A1 (de) Warnsystem für Controller Area Networks
DE102022213582A1 (de) Authentifizierungsgerät für ein Fahrzeug
EP3641231A1 (de) Verfahren und vorrichtung zur überwachung einer datenkommunikation
DE102012219093A1 (de) Cyber-Sicherheit in einem Kraftfahrzeugnetzwerk
DE102019125493A1 (de) Slaveeinrichtung, Bussystem und Verfahren
DE102019220246A1 (de) Übertragungsvorrichtung zum Übertragen von Daten
EP3681099A1 (de) Verfahren zum betreiben eines rechnersystems für eine automatisierungsanlage und/oder fertigungsanlage sowie rechnersystem
DE102016212755B3 (de) Ethernet-Fahrzeugbordnetz mit geschützter Konfigurierbarkeit
EP3607437A1 (de) Verfahren zum konfigurieren zumindest eines geräts in einem netzwerk, computerprogramm und computerlesbares speichermedium
EP3560153B1 (de) Verfahren zum betreiben einer datenverarbeitungsanlage, datenverarbeitungsanlage
DE102020209043A1 (de) Verfahren zum Betreiben eines Netzwerks und Bypassverbindungseinheit