-
Die vorliegende Erfindung betrifft ein Verfahren zum Betreiben eines Steuergerätes in einem Verbund von Steuergeräten. Die vorliegende Erfindung betrifft darüber hinaus eine entsprechende Vorrichtung, ein entsprechendes Computerprogramm sowie ein entsprechendes maschinenlesbares Speichermedium.
-
Stand der Technik
-
In der IT-Sicherheit wird jedwedes System zur Erkennung von Angriffen, die gegen ein Computersystem oder Rechnernetz gerichtet sind, als Angriffserkennungssystem (intrusion detection system, IDS) bezeichnet. Bekannt sind insbesondere Netzwerk-basierte IDS (NIDS), die alle Pakete in einem zu überwachenden Netzwerksegment aufzeichnen, analysieren und anhand bekannter Angriffsmuster verdächtige Aktivitäten melden.
-
DE102017210647A1 offenbart ein Verfahren zur Erkennung eines Angriffes auf einen Feldbus, gekennzeichnet durch folgende Merkmale: Über den Feldbus wird eine erste Nachricht empfangen; die erste Nachricht wird einer Integritätsprüfung unterzogen; schlägt die Integritätsprüfung fehl, so wird die erste Nachricht verworfen und eine zweite Nachricht erzeugt; und die zweite Nachricht wird über den Feldbus an ein Angriffserkennungssystem gesendet.
-
Offenbarung der Erfindung
-
Die Erfindung stellt ein Verfahren zum Betreiben eines Steuergerätes in einem Verbund von Steuergeräten, eine entsprechende Vorrichtung, ein entsprechendes Computerprogramm sowie ein entsprechendes Speichermedium gemäß den unabhängigen Ansprüchen bereit.
-
Der erfindungsgemäße Ansatz fußt auf der Erkenntnis, dass ein modernes Fahrzeug aus vielen vernetzten Komponenten besteht, welche gemeinsam unterschiedliche Fahrzeugfunktionen erfüllen. Diese Fahrzeugfunktionen können einzeln oder auch überlagernd aktiv sein. Zur Steuerung werden Fahrzeugbetriebsmodi zur Klassifizierung von Betriebszuständen des Fahrzeugs definiert, etwa der Fahrer fährt, das Fahrzeug fährt autonom oder teilautonom mit z. B. Abstandsregeltempomat (adaptive cruise control, ACC) usw. Jede funktionsnotwendige Komponente innerhalb des Netzwerks muss hierzu ebenfalls den „richtigen“ (übergeordneten) Zustand einnehmen, um die Fahrzeugfunktion wie vorgesehen zu erfüllen.
-
Das vorgeschlagene Verfahren trägt ferner dem Umstand Rechnung, dass derartige Komponentenzustände zueinander funktional und sicherheitstechnisch kompatibel sein müssen. Im Rahmen bekannter Sicherheitskonzepte werden Sicherheitsmechanismen (limiter) in für die Betriebssicherheit (safety) relevanten Komponenten (z. B. Aktuatoren) eingesetzt, welche die Wirkung einer fehlerhaften Eingangsgröße begrenzen. Um Komfortfunktionen und sicherheitsrelevante Funktion innerhalb einer Fahrzeugarchitektur einsetzen zu können, werden solcherlei skalierbare Sicherheitsmechanismen eingesetzt, welche die Wirkung funktionsspezifisch begrenzen. Hierzu werden die sicherheitsrelevanten Komponenten auf Basis ihrer Eingangsinformationen in den entsprechenden notwendigen Betriebszustand (nachfolgend: Modus) versetzt. Die Fähigkeit der Komponenten zur Modus-Änderung ermöglicht einen Angriff über einzelne durch einen Angreifer korrumpierte Komponenten durch Manipulation der Netzwerksignale. Über die Netzwerksignale werden in diesem Fall Modus-Änderungen einzelner Komponenten in der Art bewirkt, dass die verwendeten Sicherheitsmechanismen deaktiviert werden. In Betracht kommen etwas das Frei- bzw. Abschalten skalierbarer Limiter von Aktuatoren oder das Umschalten von Sensorbetriebszuständen. Des Weiteren können mehrere Komponenten in eine inkompatible Kombination von Betriebszuständen versetzt werden.
-
Ein Vorzug der erfindungsgemäßen Lösung liegt in Anbetracht dieser Bedrohung darin, dass Einzelsteuergeräte der vorgeschlagenen Art in einem Verbund ihre Konfiguration nicht wechseln können, ohne dass andere Steuergeräte des Verbundes dem angeforderten Modus-Wechsel zustimmen.
-
Durch die in den abhängigen Ansprüchen aufgeführten Maßnahmen sind vorteilhafte Weiterbildungen und Verbesserungen des im unabhängigen Anspruch angegebenen Grundgedankens möglich. So kann vorgesehen sein, dass der Verbund über einen die Steuergeräte umfassenden Feldbus eines Kraftfahrzeuges kommuniziert und die Prüfung der Aufforderung, den Modus des Verbundes zu wechseln, die durch das Kraftfahrzeug einzuhaltenden Betriebsbedingungen berücksichtigt. Auf diesem Wege wird gleichsam ein den einzelnen Steuergeräten übergeordneter Modus des Fahrzeugs geschaffen, welcher nicht durch eine einzige Komponente verändert werden kann.
-
Gemäß einem weiteren Aspekt kann vorgesehen sein, dass der Verbund definierte Modi aufweist, welche bestimmten Funktionen des Kraftfahrzeuges entsprechen, wobei die besagte Prüfung anhand zulässiger Übergänge zwischen den Modi erfolgt. Vom Verbund umfasste Steuergeräte lassen somit nur Transitionen zu kompatiblen Systemkonfigurationen zu.
-
Figurenliste
-
Ausführungsbeispiele der Erfindung sind in den Zeichnungen dargestellt und in der nachfolgenden Beschreibung näher erläutert. Es zeigt:
- 1 das Flussdiagramm eines Verfahrens gemäß einer ersten Ausführungsform.
- 2 das Blockschaltbild einer Steuerkette.
- 3 das Zustandsübergangsdiagramm eines Sensors.
- 4 das Zustandsübergangsdiagramm einer Steuerung.
- 5 das Zustandsübergangsdiagramm eines Aktuators.
- 6 das Blockdiagramm eines die Steuerkette umfassenden Bussegmentes im Modus „Fahrerinformationssystem“.
- 7 das Verhalten bei einem zulässigen Wechsel in den Modus „Stauassistent“.
- 8 ein potenziell gefährliches Verhalten durch Angriff über Gateway oder Systemschnittstelle.
- 9 das Verhalten bei einem erkannten Angriff über Gateway oder Systemschnittstelle auf ein Element und entsprechender Zurückweisung des Zustandswechsels.
- 10 das Verhalten bei Erkennung einer korrumpierten Komponente anhand eines fehlenden oder ungültigen Zustandsvektors und entsprechender Zurückweisung des Zustandswechsels.
- 11 das Blockdiagramm eines drei oder mehr Sensoren umfassenden Systems im Modus „Fahrerinformationssystem“.
- 12 die Anwendung des byzantinischen Fehlermodells mit Mehrheitsentscheider auf Basis verteilter Zustandsvektoren.
-
Ausführungsformen der Erfindung
-
Eine Steuereinheit, welche die Gestalt eines eigenständigen Hardwareproduktes oder eines Softwareprozesses annehmen mag, wechselt ihren Modus erfindungsgemäß nicht nur auf Basis einer ankommenden Nachricht aus dem Fahrzeugnetzwerk, sondern plausibilisiert diese vorher anhand der Statusvektoren der anderen Steuergeräte im Funktionsverbund. Die Steuereinheit wechselt ihren Modus sodann nur bei einer gültigen Funktionskonfiguration.
-
Als Voraussetzung dazu wird bei jedem Modus-Wechsel die entsprechende Statusinformation ins Fahrzeugnetzwerk verteilt und dort synchronisiert. Damit wird die Statusinformation des Fahrmodus verteilt und nicht mehr von einer einzigen Quelle im Fahrzeugnetzwerk bezogen.
-
Ein Modus-Wechsel erfolgt, wie 1 illustriert, gemäß folgendem Ablauf: Ein Steuergerät informiert einen per Funktionskonfiguration wohldefinierten Steuergeräteverbund über die Anforderung zur Modus-Änderung (Prozess 11). Jedes Steuergerät im relevanten Steuergeräteverbund prüft die Vollständigkeit der Anforderung. Jedes Steuergerät im relevanten Steuergeräteverbund prüft die angeforderte Modi-Änderung ferner auf Integrität (die in der unten stehenden Tabelle dargestellte Konfiguration und die in den 3, 4, 5 dargestellten Transitionen) und auf Randbedingungen bzgl. Verträglichkeit mit der Funktionalität, also daraufhin, ob die Fahrzeugsituation einen sicheren Wechsel in den angeforderten Modus erlaubt (Prozess 12). Die Prüfung (Prozess 12) kann auch nacheinander oder in Teilen erfolgen, um hierdurch spezifische Fehlerreaktionen zu ermöglichen. Jedes Steuergerät im relevanten Steuergeräteverbund teilt das Ergebnis dieser Prüfung und seinen Status im Zustandsvektor den anderen Steuergeräten mit und empfängt entsprechende Rückmeldungen (Prozess 13). Jedes Steuergerät schließlich führt die Modus-Änderung nur dann durch (Prozess 14), wenn alle Steuergeräte zustimmen und eine gültige Systemkonfiguration vorliegt oder wenn - gemäß einem byzantinischen Fehlermodell - eine vorgegebene Mindestzahl der Rückmeldungen positiv ausfällt und der angeforderte Modus eine eingeschränkte Funktionalität mit einer Untermenge der am Verbund beteiligten Steuergeräte erlaubt. Letzteres könnte zum Beispiel bei Vorliegen multipler redundanter Sensoren der Fall sein.
-
Für den Fall, dass nicht alle Steuergeräte im Verbund in der Lage sind, die Vollständigkeit, Integrität und Authentizität der Anforderung einer Modus-Änderung zu überprüfen, bleibt gleichwohl eine Variante der Erfindung anwendbar, solange zumindest ein Steuergerät zu dieser Prüfung in der Lage ist. In diesem Szenario nehmen lediglich die hierzu fähigen Steuergeräte die jeweilige Prüfung vor und teilen deren Ergebnis den übrigen Steuergeräten mit.
-
2 zeigt exemplarisch einen Verbund (11) aus drei Komponenten (C, D, E) mit potenziell gefährlicher Umgebungsinteraktion. Die in 2 dargestellte Systembeschreibung wird in den folgenden Beispielen verwendet. Ein Gefahrenpotenzial geht hierbei direkt vom Aktuator (E) und indirekt von Sensor (C) und Controller (B) aus. Hierbei sei angenommen, dass der Aktuator (E) die Wirkung auf die Umgebung zustandsabhängig auf generell sichere Grenzwerte limitieren und das System die notwendigen Randbedingungen wie Geschwindigkeit, Zustand eines etwaigen Antiblockiersystems (ABS), Systemfehler und Umwelteinflüsse für einen Konfigurationswechsel in die Entscheidung einbeziehen kann.
-
Die Steuergeräte (
C,
D,
E) mögen hierbei als endliche Automaten betrachtet werden, deren Zustände (CO-C3, DO-D3, EO-E2) und zulässige Zustandsübergänge in den
3,
4 bzw.
5 veranschaulicht sind. Die Bedeutung der aus der Kombination dieser Zustände resultierenden Modi des Verbundes (
11) ist folgender Tabelle zu entnehmen:
Zustand des Sensors | Zustands des Controllers | Zustand des Aktuators | Bedeutung und Risikoeinstufung |
C0 | D0 | E0 | Gültiger und sicherer Ausgangszustand |
C0 | D0 | E1 | Gestörte Komfortfunktion |
C0 | D0 | E2 | Sicherheitskritisch |
C0 | D1 | E0 | Gestörte Komfortfunktion |
C0 | D1 | E1 | Gestörte Komfortfunktion |
C0 | D1 | E2 | Sicherheitskritisch |
C0 | D2 | E0 | Gestörte Komfortfunktion |
C0 | D2 | E1 | Gestörte Komfortfunktion |
C0 | D2 | D2 | Sicherheitskritisch |
C0 | D3 | E0 | Gestörte Komfortfunktion |
C0 | D3 | E1 | Gestörte Komfortfunktion |
C0 | D3 | E2 | Sicherheitskritisch |
C1 | D0 | E0 | Gestörte Komfortfunktion |
C1 | D0 | E1 | Gestörte Komfortfunktion |
C1 | D0 | E2 | Sicherheitskritisch |
C1 | D1 | E0 | Gültige Funktion 1 (Fahrerinformation), Teilkonfiguration |
C1 | D1 | E1 | Gestörte Komfortfunktion |
C1 | D1 | E2 | Sicherheitskritisch |
C1 | D2 | E0 | Gestörte Komfortfunktion |
C1 | D2 | E1 | Gestörte Komfortfunktion |
C1 | D2 | D2 | Sicherheitskritisch |
C1 | D3 | E0 | Gestörte Komfortfunktion |
C1 | D3 | E1 | Gestörte Komfortfunktion |
C1 | D3 | E2 | Sicherheitskritisch |
C2 | D0 | E0 | Gestörte Komfortfunktion |
C2 | D0 | E1 | Gestörte Komfortfunktion |
C2 | D0 | E2 | Sicherheitskritisch |
C2 | D1 | E0 | Gestörte Komfortfunktion |
C2 | D1 | E1 | Gestörte Komfortfunktion |
C2 | D1 | E2 | Sicherheitskritisch |
C2 | D2 | E0 | Gestörte Komfortfunktion |
C2 | D2 | E1 | Gültige Funktion 2 (Abstan dsregeltem pomat) |
C2 | D2 | D2 | Sicherheitskritisch |
C2 | D3 | E0 | Gestörte Komfortfunktion |
C2 | D3 | E1 | Gestörte Komfortfunktion |
C2 | D3 | E2 | Sicherheitskritisch |
C3 | D0 | E0 | Gestörte Komfortfunktion |
C3 | D0 | E1 | Gestörte Komfortfunktion |
C3 | D0 | E2 | Sicherheitskritisch |
C3 | D1 | E0 | Gestörte Komfortfunktion |
C3 | D1 | E1 | Gestörte Komfortfunktion |
C3 | D1 | E2 | Sicherheitskritisch |
C3 | D2 | E0 | Gestörte Komfortfunktion |
C3 | D2 | E1 | Gestörte Komfortfunktion |
C3 | D2 | D2 | Sicherheitskritisch |
C3 | D3 | E0 | Gestörte Komfortfunktion |
C3 | D3 | E1 | Gestörte Komfortfunktion |
C3 | D3 | E2 | Gültige Funktion 3 (Stauassistent) |
-
6 beleuchtet beispielhaft ein diesen Verbund umfassendes Bussegment, wobei sich der Verbund zunächst im Modus „Fahrerinformationssystem“ befindet. Das Verhalten des Verbundes bei Anforderung des Modus „Stauassistent“ (travel jam assistant, TJA) sei nunmehr anhand der 7 erläutert. Jedes Element (C, D, E) des Verbundes sendet in diesem Fall den angeforderten eigenen Modus und den von den übrigen Teilnehmern empfangenen Modus in Gestalt einer im Folgenden als Statusvektor bezeichneten Struktur an jeden anderen Teilnehmer. Im vorliegenden Beispiel herrscht unter den besagten Teilnehmern Einigkeit über den Statusvektor (C3, D3, E2). Eine durch jedes Element (C, D, E) vorgenommene Auswertung des Statusvektors im Rahmen einer Missbrauchsprüfung ergibt die Gültigkeit des Statusvektors sowie die Einhaltung der Randbedingungen. Jedes Element (C, D, E) erklärt den angeforderten Zustandsübergang somit für ordnungsgemäß, teilt die entsprechende Entscheidung mit den anderen Elementen und nimmt die Konfigurationsänderung vor.
-
8 stellt diesem Verhalten ohne Angriff - wiederum ausgehend von der Ausgangskonfiguration gemäß 6 - ein potenziell gefährliches Verhalten durch einen Angriff über ein Gateway (A) oder eine Systemschnittstelle gegenüber, bei welchem der Angreifer durch Versetzen des Aktuators (E) in den Modus E2 die Stauassistent-Schnittstelle erfolgreich im ungültigen Modus C1, D1, E2 konfiguriert.
-
Ein derartiger Angriff lässt sich erfindungsgemäß abwehren, wie
9 verdeutlicht: Hier herrscht unter sämtlichen Teilnehmern Einigkeit über den Statusvektor (
C1,
D1,
E2). Eine durch jedes Element (
C,
D,
E) vorgenommene Auswertung des Statusvektors ergibt dessen Ungültigkeit sowie die Einhaltung der Randbedingungen. Jedes Element (
C,
D,
E) erklärt den angeforderten Zustandsübergang somit für nicht ordnungsgemäß, teilt die entsprechende Entscheidung und den lokal bekannten Statusvektor mit den anderen Elementen und weist den angeforderten Zustandswechsel zurück. Im Falle des Aktuators (
E) könnte eine derartige Prüfung des Zustandes der übrigen TJA-Komponenten beispielsweise gemäß des folgenden Pseudocodes erfolgen:
-
Eine Auswertung von Teilkonfigurationen ergäbe, dass (C1, D1) einer gültigen Teilkonfiguration des Fahrerinformationssystems entspräche, während die Kombinationen C1/E2 sowie D1/E2 als ungültig erkannt würden.
-
Ebenfalls anhand der 9 lässt sich das entsprechende Verhalten bei einem Angriff über Gateway (A) oder Systemschnittstelle auf eine vollständige Konfiguration erläutern, bei welchem der Angreifer versucht, den Verbund in den Modus C3, D3, E2 zu versetzen. Hier herrscht unter sämtlichen Teilnehmern Einigkeit über den Statusvektor (C3, D3, E2). Jeder der Teilnehmer C, D, E prüft die Einhaltung der Randbedingungen, die Zulässigkeit des Statusvektors (Tabelle) und die Zulässigkeit seines Transitionsziels (3, 4, 5). Die Teilnehmer sind sich einig über die Zulässigkeit des Statusvektors. Die Transitionsziele werden von den Teilnehmern C und D als unzulässig erkannt, da gemäß 3, 4 keine Übergänge von den Zuständen C1, D1 in die Zustände C2, D2 erlaubt sind. C, D informieren den Verbund über die Unzulässigkeit der geforderten Modusänderung. Die geforderte Modusänderung erfolgt daraufhin nicht und das Fahrzeug bleibt im sicheren Ausgangszustand.
-
Aufgrund der Erfindung sind nur die Angriffe erfolgreich, die darauf abzielen, den Verbund in einen Zustand zu versetzen, der sowohl zu den Randbedingungen passt als auch den Transitionsregeln der einzelnen Teilnehmern entspricht und von allen Teilnehmern als zulässig erkannt wird. Alle Angriffe dieser Art resultieren in einen sicheren Zustand und stellen daher keine Gefahr für Leib und Leben dar.
-
10 illustriert das Verhalten des Systems in dem Fall, dass ein entsprechender Angriff vom Sensor (
C) ausgeht. Dessen Statusvektor fehlt in diesem Fall oder ist falsch. Sowohl Controller (
B) als auch Aktuator (
E) erkennen diesen Fehlerzustand anhand der Bedingung
-
Es sei bemerkt, dass auch ein geeignetes asymmetrisches Kryptosystem eingesetzt werden sollte, um den Sensor (C, F, G) anhand seines öffentlichen Schlüssels zu authentifizieren.
-
11 zeigt das Blockdiagramm eines drei oder mehr Sensoren (C, F, G) umfassenden Systems im Modus „Fahrerinformationssystem“. Wie 12 veranschaulicht, ist angesichts der Anzahl vom Verbund umfasster Steuergeräte (A-G, X) ausgehend von dieser Konfiguration das byzantinische Fehlermodell mit Mehrheitsentscheider auf Basis des verteilten Zustandsvektors - im vorliegenden Falle (F1, G1, C3, D3, E2) - anwendbar.
-
Als zweites Ausführungsbeispiel sei nunmehr ein Staupilot (travel jam pilot, TJP) angeführt. Zur Vereinfachung sei dabei angenommen, dass das System lediglich die Modi „manuelle Steuerung“ und „automatische Steuerung“ unterstützt. Im ersteren Falle verbleibt die volle Kontrolle über das Fahrzeug beim Fahrer und entsprechende Limiter erlauben die volle Lenkfreiheit sowie die Erhöhung der Geschwindigkeit bis zur baulich bedingten Höchstgeschwindigkeit. Im letzteren Falle reduzieren die Limiter die Freiheiten auf kleinere Lenkwinkel und eine Geschwindigkeit von 65 km/h. Der Limiter ist vorzugsweise dynamisch und verändert sich je nach ASIL-Einstufung des Modus.
-
Ferner sei angenommen, dass ein Angreifer einen Unfall erzeugen möchte und ein Steuergerät, das nicht die Lenkung steuert, bereits unter seine Kontrolle gebracht hat, mit dem er valide Nachrichten an das Steuergerät der Lenkung schicken kann. Beispielsweise wolle der Angreifer den Limiter im automatischen Fahrmodus dazu veranlassen, maximale Freiheiten bei der Steuerung zu erlauben, da der üblicherweise in diesem Modul begrenzte Lenkwinkel nicht ausreichend ist. Der Angreifer könne jedoch den Limiter nur durch Signale konfigurieren und nicht etwa direkt dessen Speicher beschreiben.
-
Ausgehend von diesen Annahmen bestünde eine Angriffsmöglichkeit darin, ein Signal zum Modus-Wechsel an die Lenkung zu schicken, sodass sich der Limiter an einen vermeintlich manuellen Fahrmodus anpasst, der volle Lenkfreiheit erlaubt. Da der Modus durch die erfindungsgemäß ausgetauschten Statusvektoren jedoch allen Steuergeräten bekannt ist, kann er nicht ohne Weiteres geändert werden; vielmehr müssten mehrere Steuergeräte - basierend auf deren Sensorauswertung - einem durch den Angreifer angeforderten Modus-Wechsel gleichsam „zustimmen“. Die Aufforderung des Angreifers zum Modus-Wechsel würde daher vom erfindungsgemäßen System verworfen (Prozess 15 - 1).
-
Dieses Verfahren (10) kann beispielsweise in Software oder Hardware oder in einer Mischform aus Software und Hardware beispielsweise in einem der Steuergeräte (A-G, X) implementiert sein.
-
ZITATE ENTHALTEN IN DER BESCHREIBUNG
-
Diese Liste der vom Anmelder aufgeführten Dokumente wurde automatisiert erzeugt und ist ausschließlich zur besseren Information des Lesers aufgenommen. Die Liste ist nicht Bestandteil der deutschen Patent- bzw. Gebrauchsmusteranmeldung. Das DPMA übernimmt keinerlei Haftung für etwaige Fehler oder Auslassungen.
-
Zitierte Patentliteratur
-
- DE 102017210647 A1 [0003]