DE102020213844A1

DE102020213844A1 - Taktsteuerung zum erhöhen von robustheit einer schnittstelle mit seriellem bus

Info

Publication number: DE102020213844A1
Application number: DE102020213844.3A
Authority: DE
Inventors: Shalabh Jain; Jorge Guajardo Merchan; Sekar Kulandaivel
Original assignee: Robert Bosch GmbH
Current assignee: Robert Bosch GmbH
Priority date: 2019-11-27
Filing date: 2020-11-04
Publication date: 2021-05-27
Also published as: US11714474B2; CN112859801A; US11209891B2; US20210157388A1; US20220121264A1

Abstract

Eine elektronische Steuereinheit (ECU) beinhaltet einen Prozessor, einen Controller Area Network(CAN)-Controller, Takttastlogik und Sicherheitstastlogik. Der CAN-Controller weist einen Status auf und ist ausgelegt zum Empfangen von Daten- und Steuersignalen von dem Prozessor und eines Taktsignals, Packen der Daten zum Schaffen eines CAN-Protokoll-Frames, der in mindestens einem Übertragungspuffer gehalten wird, und Verschieben des CAN-Protokoll-Frames zu einem CAN-Transceiver, der ausgelegt ist zum Übertragen des CAN-Protokoll-Frames an einen CAN-Bus. Die Takttastlogik kann ausgelegt sein zum selektiven Blockieren eines Taktsignals zum CAN-Controller auf der Grundlage eines Steuersignals von dem Prozessor. Die Sicherheitstastlogik ist ausgelegt zum, als Reaktion darauf, dass der Status des CAN-Controllers aktiv ist, Hemmen des Blockierens des Taktsignals.

Description

TECHNISCHES GEBIET
Diese Erfindung betrifft allgemein ein System und ein Verfahren zum Erhöhen der Robustheit einer Schnittstelle eines seriellen Busses mit nachrichtenbasiertem Protokoll über erweiterte Tastung und Stilltaktdetektion.
HINTERGRUND
Ein modernes Fahrzeug enthält mehrere elektronische Steuereinheiten (Electronic Control Units - ECUs). Die meisten dieser ECUs kommunizieren über einem Kommunikationsbus unter Verwendung eines Kommunikationsprotokolls (z. B. ein Controller Area Network(CAN)-Protokoll). Die Topologie mehrerer über einen Kommunikationsbus kommunizierender ECUs schafft ein Fahrzeugnetzwerk, das viele Systeme des Fahrzeugs steuert und zu vielen Vorteilen beim Fahrzeugbetrieb geführt hat. Allerdings wurden diese Fahrzeugnetzwerke im Zusammenspiel mit der zusätzlichen Funktionalität zu einem Hauptziel für Angriffe auf Automobilnetzwerke.
KURZFASSUNG
Eine elektronische Steuereinheit (ECU) beinhaltet einen Prozessor, einen Controller Area Network(CAN)-Controller, Takttastlogik und Sicherheitstastlogik. Der CAN-Controller weist einen Status auf und ist ausgelegt zum Empfangen von Daten- und Steuersignalen von dem Prozessor und eines Taktsignals, Packen der Daten zum Schaffen eines CAN-Protokoll-Frames, der in mindestens einem Übertragungspuffer gehalten wird, und Verschieben des CAN-Protokoll-Frames zu einem CAN-Transceiver, der ausgelegt ist zum Übertragen des CAN-Protokoll-Frames an einen CAN-Bus. Die Takttastlogik kann ausgelegt sein zum selektiven Blockieren eines Taktsignals zum CAN-Controller auf der Grundlage eines Steuersignals von dem Prozessor. Die Sicherheitstastlogik ist ausgelegt zum, als Reaktion darauf, dass der Status des CAN-Controllers aktiv ist, Hemmen des Blockierens des Taktsignals.
Eine elektronische Steuereinheit (ECU) beinhaltet einen Prozessor, einen Controller, Takttastlogik und Sicherheitstastlogik. Der Controller kann ausgelegt sein zum Empfangen von Daten- und Steuersignalen von dem Prozessor, Packen der Daten zum Schaffen eines Protokoll-Frames, der in mindestens einem Übertragungspuffer gehalten wird, und seriellen Verschieben des Protokoll-Frames über einen Schiebepuffer zu einem Transceiver, der Transceiver ist ausgelegt zum Empfangen serieller Daten von dem Controller und zum Übertragen eines Signals auf einem Bus. Die Takttastlogik kann ausgelegt sein zum selektiven Blockieren eines Takts zum Controller auf der Grundlage eines Signals von dem Prozessor. Die Sicherheitstastlogik ist ausgelegt zum, als Reaktion darauf, dass ein Status des Controllers aktiv ist, Hemmen des Blockierens des Takts.
Eine elektronische Steuereinheit (ECU) beinhaltet einen Prozessor, einen Controller, Takttastlogik, Sicherheitstastlogik und Rücksetzlogik. Der Controller kann ausgelegt sein zum Empfangen von Daten- und Steuersignalen von dem Prozessor, Packen der Daten zum Schaffen eines Protokoll-Frames, der in mindestens einem Übertragungspuffer gehalten wird, und seriellen Verschieben des Protokoll-Frames über einen Schiebepuffer zu einem Transceiver, der Transceiver ist ausgelegt zum Empfangen serieller Daten von dem Controller und zum Übertragen des Protokoll-Frames auf einem Bus. Die Takttastlogik kann ausgelegt sein zum selektiven Blockieren eines Takts zum Controller auf der Grundlage eines Signals von dem Prozessor. Die Sicherheitstastlogik kann ausgelegt sein zum, als Reaktion darauf, dass ein Status des Controllers aktive Übertragung des Protokoll-Frames angibt, Hemmen des Blockierens des Takts. Die Rücksetzlogik kann ausgelegt sein zum Rücksetzen des mindestens einen Übertragungspuffers, wenn das Signal von aktiv zu inaktiv übergeht.
Figurenliste

1 ist ein Blockdiagramm eines Controller Area Network(CAN)-Stacks in einer elektronischen Steuereinheit (ECU).
2 ist ein Blockdiagramm eines CAN-Stacks in einer ECU, der eine angeschlossene Leistung und Takt aufweist.
3 ist ein Flussdiagramm eines Angriffs auf einen CAN-Controller über Einsetzen eines willkürlichen Bits.
4 ist ein Flussdiagramm eines einzelnen dominanten Bits, das für eine willkürliche Dauer durch einen CAN-Controller eingesetzt wird.
5 ist ein Blockdiagramm von Takttastung für einen CAN-Controller.
6 ist ein Blockdiagramm von Takttastung über Status und Freischaltung für einen CAN-Controller.
7 ist ein Blockdiagramm von Takt-, Datenbus- und Steuerbustastung über Status und Freigabe für einen CAN-Controller.
8 ist ein Blockdiagramm eines Übertragungspufferstatus auf der Grundlage eines Werts des Übertragungspuffers.
9 ist ein Blockdiagramm einer Rücksetzschaltung zum Rücksetzen des Übertragungspuffers über ein Asynchron-Rücksetzsignal.
10 ist ein Blockdiagramm einer Rücksetzschaltung zum Rücksetzen des Übertragungspuffers über ein Synchron-Rücksetzsignal.
11A ist ein Blockdiagramm einer Detektionsschaltung zum Detektieren eines persistenten High-Taktsignals.
11B ist ein Blockdiagramm einer Detektionsschaltung zum Detektieren eines persistenten Low-Taktsignals.
12 ist ein Flussdiagramm einer Peripheriezustand-Prüffunktion.
13 ist ein Flussdiagramm einer Peripheriezustand-Prüffunktion über einen sicheren Coprozessor.
14 ist ein Flussdiagramm einer Peripheriezustand-Prüffunktion über einen Übergang in einen sicheren Betriebsmodus.
15 ist ein Flussdiagramm einer Peripheriezustand-Prüffunktion über eine Compiler-Anweisung.
16 ist ein Blockdiagramm eines Kommunikationsbusses, der einen Supervisor-Knoten, einen Angreiferknoten und einen Zielknoten beinhaltet.

AUSFÜHRLICHE BESCHREIBUNG
Wie erforderlich werden hier detaillierte Ausführungsformen der vorliegenden Erfindung offenbart; allerdings versteht sich, dass die offenbarten Ausführungsformen lediglich beispielhaft für die Erfindung sind, die in verschiedenen und alternativen Formen umgesetzt werden kann. Die Figuren sind nicht notwendigerweise maßstabsgetreu; manche Merkmale können übertrieben oder minimiert sein, um Einzelheiten spezieller Komponenten zu zeigen. Die spezifischen hier offenbarten strukturellen und funktionalen Einzelheiten sind daher nicht als einschränkend aufzufassen, sondern lediglich als eine repräsentative Basis zum Lehren eines Durchschnittsfachmanns, die vorliegende Erfindung auf verschiedentliche Weise einzusetzen.
Der Ausdruck „im Wesentlichen“ kann hier verwendet werden, um offenbarte oder beanspruchte Ausführungsformen zu beschreiben. Der Ausdruck „im Wesentlichen“ kann einen Wert oder eine relative Charakteristik modifizieren, der/die in der vorliegenden Offenbarung offenbart oder beansprucht ist. In solchen Fällen kann „im Wesentlichen“ kennzeichnen, dass der Wert oder die relative Charakteristik, den/die es modifiziert, innerhalb von ± 0 %, 0,1 %, 0,5 %, 1 %, 2 %, 3 %, 4 %, 5 % oder 10 % des Wertes oder der relativen Charakteristik liegt.
Sicherheitsmechanismen zum Verhindern von auf abgesetzter Software basierenden Angriffen auf Knoten, die mit dem Controller Area Network(CAN)-Bus verbunden sind, gehen davon aus, dass gegnerische Handlungen auf Nutzung von Nachrichten begrenzt sind, die den Spezifikationen der Bitübertragungsschicht in ISO-11898/1, ISO-11898/2, ISO-11898/3 usw. genügen, die Nachrichten-Framing und Timing bestimmen. Allerdings ist eine derartige Annahme für ECUs, die einen CAN-Bus verwenden, nicht länger ausreichend. Die Offenbarung veranschaulicht Softwareverfahren, die zum Übertragen von Nachrichten genutzt werden können, die nicht mit der CAN-Spezifikation konform sind, indem CAN-Controller-Funktionalität missbraucht wird. Weiter werden neuartige Verfahren zum effizienten Schützen eines CAN-Controllers vor solchen Angriffen unter Verwendung einer Vielfalt von auf Software und Hardware basierenden Steuerungsstrukturen offenbart. Die Konzepte werden über eine spezifische CAN-Architektur veranschaulicht, wobei die Konzepte allerdings auch auf andere CAN-Architekturen anwendbar sind, wie etwa Eindraht-CAN (Single Wire CAN - SW-CAN oder SWC), CAN mit flexibler Datenrate (Flexible Data Rate CAN - FD-CAN oder CAN FD), J1939 und ISO 11783. Auch können diese Konzepte auf andere Architekturen serieller Busse angewandt werden, wie etwa Ethernet (IEEE802.11 und Varianten davon), Local Interconnect Network (LIN), Flexray (ISO 17458-1 bis 17458-5).
Ein CAN-Bus ist ein zentrales Kommunikationsnetzwerk, das in vielen Systemen verwendet wird, einschließlich Automobilsystemen, Luft- und Raumfahrtsystemen, Endverbrauchersystemen und Industriesystemen. Das Hinzufügen von abgesetzten Schnittstellen an manchen Knoten auf dem Bus hat Verletzlichkeiten geschaffen und diese Systeme für Fernangriffe geöffnet. Diese Verletzlichkeiten wurden zu einer Betriebs- und Sicherheitsfrage. Somit wurde Verbessern der Sicherheit des CAN-Busses zu einem wichtigen Thema, da die Technologie fortschreitet und die Autonomie des Fahrzeugbetriebs zunimmt.
Aufgrund der ursprünglichen Designgrundsätze für CAN und Rechenfähigkeiten eines typischen Knotens in einem Netzwerk hat die Schwierigkeit, Sicherheit in das Netzwerk zu integrieren, signifikant zugenommen. Techniken, diese Schwierigkeit anzugehen, beinhalten neuartige Schlüsselvereinbarungsmechanismen, leichtgewichtige Authentifikationsschemata und Verwendung eines dedizierten Eindringdetektionssystems (Intrusion Detection System - IDS). Einige dieser Mechanismen gehen davon aus, dass die gegnerischen Handlungen darauf beschränkt sind, Software in den Knoten zu schädigen, wodurch dem Angreifer die Fähigkeit vermittelt wird, willkürliche CANkonforme Nachrichten einzustreuen. Solche Annahmen erlauben Optimierung des Designs von Sicherheitsmechanismen.
Allerdings können es moderne integrierte CAN-Schnittstellen einem Gegner erlauben, vorhandene Softwareschnittstellen zu nutzen, um böswillig Nachrichten einzustreuen, die nicht mit dem CAN-Protokoll konform sind. Dies beinhaltet willkürliche Biteinstreuung oder Einsetzen von teilweisen bzw. fehlerhaften Nachrichten. Vorhandene Verteidigungsmechanismen sind gegen diese neue Klasse von Gegnern ineffektiv. Hier werden Systeme und Verfahren offenbart, die dafür verwendet werden können, Missbrauch des CAN-Controllers zu verhindern, wodurch gegnerische Steuerung begrenzt wird.
Wenden wir uns softwarebasiertem Biteinsetzen zu, wobei die Schichtstruktur eines herkömmlichen Knotens in einem CAN-Bus in 1 veranschaulicht ist. 1 ist ein Blockdiagramm eines Controller Area Network(CAN)-Stacks 100 in einer elektronischen Steuereinheit (ECU). Der CAN-Stack 100 beinhaltet einen Prozessor 102, wie etwa einen Mikrocontroller, einen eingebetteten Prozessor, einen Prozessor, eine anwendungsspezifische integrierte Schaltung (ASIC), ein feldprogrammierbares Gate-Array (FPGA) oder eine ähnliche Vorrichtung. Der Prozessor 102 kommuniziert mit einem CAN-Controller 104 durch Senden und Empfangen von Daten, wie etwa einer Nachrichten-ID und Nutzdaten. Der CAN-Transceiver 106 ist die Schnittstelle zwischen dem CAN-Protokoll-Controller 104 und den physischen Drähten der CAN-Bus-Leitungen. Die CAN-Bus-Leitungen sind typischerweise 2-drähtig (z. B. verdrilltes Paar - twisted pair), können aber auch als Einzeldraht-CAN (z. B. GM-LAN) oder 4-drähtig (einschließlich gemeinsamer Masse) implementiert sein. Die Schnittstelle zwischen dem CAN-Controller 104 und dem CAN-Transceiver 106 kann über ein 2-Draht dediziertes TX-RX, RX-TX vorliegen, bei dem das Senden (TX) auf dem CAN-Controller 104 mit dem Empfangen (RX) des CAN-Transceivers 106 gekoppelt ist, und RX auf dem CAN-Controller 104 mit dem TX des CAN-Transceivers 106 gekoppelt ist.
Wie bei herkömmlichem schichtaufgebautem Design ist eine herkömmliche und übliche Annahme, dass die Interaktionen zwischen den Schichten nur an den Nachrichtenschnittstellen auftreten. In einem herkömmlichen CAN-Stack überwacht der CAN-Controller den Bus hinsichtlich übertragener Pakete und garantiert die Konformität aller übertragenen Nachrichten mit dem CAN-Protokoll.
Der CAN-Controller akzeptiert Nutzdaten und eine Nachrichten-ID von der Anwendung und sendet den CAN-konformen Nachrichten-Frame an den CAN-Transceiver, der das Analogsignal auf dem Bus (d. h. physische Drähte) überträgt. Der Controller garantiert richtigen Streitfallauflösungsbetrieb, wie etwa Abweisung, falls Arbitrierung zwischen zwei simultanen Sendern verloren ist, wodurch richtige Übertragung von Fehler-Frames, Nachrichten-ID-Filterung und Einhaltung von Zwischen-Frame-Beabstandung (inter-frame spacing - IFS) gewährleistet werden.
Die CAN-Controller-Logik ist typischerweise in Hardware implementiert. Somit wird angenommen, dass auf Software-Manipulation beschränkte Gegner das Verhalten des CAN-Controllers nicht modifizieren können. Folglich werden die auf dem Bus übertragenen Nachrichten als CAN-konform angenommen.
In manchen modernen ECUs sind der CAN-Controller und der Prozessor Teil derselben physischen Packung; dies kann als ein Multi-Chip-Modul (MCM) oder monolithisch durch peripheres Integrieren eines CAN-Controllers mit einem Prozessor erzielt werden, wodurch neue Schnittstellen zur MCU offengelegt werden, einschließlich einer Taktsteuerungsschnittstelle und einer Leistungssteuerungsschnittstelle. Die neuen Schnittstellen, in 2 veranschaulicht, sind typischerweise für die Anwendung unsichtbar und werden von Gerätetreibern auf niedrigem Niveau verwendet, um die Leistungsaufnahme des Chips und während Debug-Betriebs zu optimieren. Solche Schnittstellen können allerdings durch eine bösartige Software genutzt werden, um die Struktur der auf dem Bus übertragenen Nachrichten zu beeinflussen. Im Allgemeinen wird der CAN-Systemtakt entweder von dem MCU-System-Taktgeber oder von einem externen Oszillator abgeleitet. Dies ergibt eine mögliche CAN-Systemtaktfrequenz, die typischerweise durch einen Vorskalierer auf ganze Bruchteile des MCU-Systemtakts oder Oszillators begrenzt wird. Der CAN-Systemtakt ist so gewählt, dass die gewünschte Nennbitzeit (Nominal Bit Time - NBT) des CAN-Busses eine ganzzahlige Anzahl von Zeitquanten (CAN-Systemtaktperioden) ist, beispielsweise von 8 bis 25. Man betrachte beispielsweise eine Bitrate von 125 kBit pro Sekunde, eine Buslänge = 50 m, eine Busausbreitungsverzögerung = 5 × 10^-9 s·m^-1, eine Ausbreitungsverzögerung der Physischen Schnittstelle (Sender plus Empfänger) von 150 ns bei 85C, und eine MCU-Oszillatorfrequenz = 8 MHz. Ein Vorskaliererwert von 4 ergibt einen CAN-Systemtakt von 2 MHz und ein Zeitquantum von 500 ns. Dies ergibt 8000 / 500 = 16 Zeitquanten pro Bit.
2 ist ein Blockdiagramm eines CAN-Stacks 200 in einer ECU, der eine angeschlossene Leistungssteuerungsschnittstelle und einen Taktgeber aufweist. Der CAN-Stack 200 beinhaltet einen Prozessor 202, wie etwa einen Mikrocontroller, einen eingebetteten Prozessor, einen Prozessor, eine anwendungsspezifische integrierte Schaltung (ASIC), ein feldprogrammierbares Gate-Array (FPGA) oder eine ähnliche Vorrichtung. Der Prozessor 202 kommuniziert mit einem CAN-Controller 204 durch Senden und Empfangen von Daten, wie etwa einer Nachrichten-ID und Nutzdaten und über Schnittstellen, die eine Taktschnittstelle und eine Leistungssteuerungsschnittstelle beinhalten. Der CAN-Transceiver 206 ist die Schnittstelle zwischen dem CAN-Protokoll-Controller 204 und den physischen Drähten des CAN-Busses.
3 ist ein Flussdiagramm eines Angriff-Vorläufers 300 auf einen CAN-Controller über Einsetzen eines willkürlichen Bits. In Schritt 302 schaltet ein Controller (z. B. Controller 102, 202) einen Takt für einen CAN-Controller (z. B. Controller 104, 204) frei. In Schritt 304 konfiguriert der Controller (z. B. Controller 102, 202) den CAN-Controller (z. B. Controller 104, 204), wie etwa Baudrate, Nachrichtenfilter und Protokoll (z. B. GM-LAN, FNOS usw.). In Schritt 306 wartet der Controller (z. B. Controller 102, 202) auf eine Detektion einer Zwischen-Frame-Beabstandung (inter-frame spacing - IFS) (z.B. eine Sequenz von rezessiven Bits nach einer Frame-Ende-Übertragung (end of frame - EOF), empfangen von dem CAN-Controller (z. B. Controller 104, 204). In Schritt 308 sendet der Controller (z.B. Controller 102, 202) ein Paket an einen Puffer (z.B. ID 0x00 und Nutzdaten 0101010) an den CAN-Controller (z. B. Controller 104, 204). Da die ID von 0x00 alles dominante Bits sind, würde die ID die höchste Priorität für Zugriff auf den Bus aufweisen. Die ID 0x00 kann eine 11 -Bit oder 29-Bit als Teil des Arbitrierungsfelds (ARB) der CAN-Nachricht sein. In Schritt 310 wartet der Controller (z. B. Controller 102, 202) auf Abschluss der Arbitrierung über das Arbitrierungsfeld bzw. ARB-Feld und einen Datenlängencode (DLC) in einem Kontrollfeld bzw. CTRL-Feld, der eine Übertragung von dem CAN-Controller (z. B. Controller 104, 204) angibt. In Schritt 312 blockiert der Controller (z. B. Controller 102, 202) den Takt für den CAN-Controller (z. B. Controller 104, 204). In Schritt 314 greift der Controller (z. B. Controller 102, 202) den CAN-Bus über eine bösartige Operation des CAN-Busses an, die andere Module auf dem CAN-Bus über den CAN-Controller (z. B. Controller 104, 204) beeinträchtigt.
4 ist ein Flussdiagramm eines Angriffs 400 eines einzelnen dominanten Bits, das für eine willkürliche Dauer durch einen CAN-Controller eingesetzt wird. In Schritt 402 beginnt ein Controller (z. B. Controller 102, 202) einen Angriff auf einen CAN-Bus über eine an einen CAN-Controller (z. B. Controller 104, 204) gesendete Nachricht. In Schritt 404 wartet der Controller (z. B. Controller 102, 202) auf eine an den CAN-Controller (z.B. Controller 104, 204) zu sendende Zielnachricht. Hier kann das Ende des Wartezeitraums durch ein externes Signal oder einen Frame-Start (Start of Frame - SOF) ausgelöst werden, der ein einzelnes dominantes Bit ist, dem mindestens 11 rezessive Bits vorangehen. In Schritt 406 schaltet der Controller (z. B. Controller 102, 202) einen Takt für einen CAN-Controller mit einem dominanten Bit frei, das durch den CAN-Controller (z. B. Controller 104, 204) übertragen wurde. In Schritt 408 blockiert der Controller (z. B. Controller 102, 202) den Takt für den CAN-Controller (z. B. Controller 104, 204), während das dominante Bit auf dem CAN-Bus aktiv gesetzt wird. In Schritt 410 schaltet der Controller (z. B. Controller 102, 202) den Takt für den CAN-Controller frei, während der CAN-Bus in einen durch den CAN-Controller (z. B. Controller 104, 204) ausgegebenen rezessiven Zustand überführt wird. In Schritt 412 blockiert der Controller (z. B. Controller 102, 202) den Takt für den CAN-Controller (z. B. Controller 104, 204). In Schritt 414 verzweigt der Controller (z. B. Controller 102, 202) zu einem anderen Angriff des CAN-Busses oder anderer Nachrichten auf dem CAN-Bus über den CAN-Controller (z. B. Controller 104, 204).
In 3 und 4 ist ein allgemeines Verfahren zum Nutzen der neuen Schnittstellen zum Übertragen eines dominanten Bits (0 Bit) von willkürlicher Länge auf dem CAN-Bus veranschaulicht. Die Operationen CLKOFF/CLKON bezeichnen die Aktion des Blockierens und Freischaltens des peripheren Takts (Takttastung) an den CAN-Controller. Die Implementationsdetails dieser Operation variieren mit der spezifischen MCU/ECU. Beispielsweise besteht ein Verfahren unter Verwendung des Arduino Due darin, Befehle einer tiefen Ebene zu nutzen, die in dem Software Developers Kit (SDK) verfügbar sind, (z. B. pmc_disable_periph_clk). Auf ähnliche Weise variieren die Verfahren zur Messung von Timing auf tiefer Ebene zum Synchronisieren der Aktionen für verschiedene MCUs.
Der Angriff nutzt eine Nachricht mit ID 0x00 und 8 Byte Nutzdaten mit abwechselnden Nullen und Einsen (0101 .. 01). Dieser beispielhafte Angriff besteht aus zwei getrennten Phasen. In der ersten Phase wird die Hochprioritäts-Nachrichten-ID übertragen, was den CAN-Controller veranlasst, in einen Zustand zur Übertragung der Nutzdaten zu gehen. Nach Warten auf Übertragung des Return to Ready(RTR)-Bits, wird der Befehl CLKOFF zum Blockieren des Takts verwendet, was den Zustand des CAN-Controllers (z. B. Controller 104, 204) einfriert. Dies bereitet den Controller (z. B. Controller 102, 202) auf Übertragen der Nachricht vor. Bei Identifikation einer Zielnachricht beginnt die zweite Angriffsphase. Diese besteht aus Verwendung des CLKON-Befehls zum Übertragen des ersten dominanten Bits der Nutzdaten. Der CLKOFF-Befehl wird dann zum Einfrieren des Controllers in einem dominanten Zustand verwendet. Sobald der dominante Zustand für die gewünschte Dauer gehalten wurde, wird der Controller durch sukzessive CLKON- und CLKOFF-Signale in den rezessiven Zustand überführt.
Dieser Mechanismus erlaubt Übertragung eines einzelnen dominanten Bits von willkürlicher Dauer zum Zeitpunkt der Wahl eines Angreifers. Das kontrollierte Pausieren und Freigeben der CAN-Controller-Zustandsmaschine gewährleistet, dass sie immer zum Übertragen des Angriffsbits bereit ist.
Diese Offenbarung veranschaulicht neue Verfahren zum Schützen einer/eines ECU (z.B. 100, 200)/CAN-Controllers/Ethernet-Controllers (z.B. Controller 104, 204) davor, zum Übertragen nichtkonformer Nachrichten verwendet zu werden. Im Hinblick auf die CAN-Norm werden alle Nachrichten typischerweise als Frames bezeichnet, was Daten-Frames, Remote-Frames, Error-Frames und Overload-Frames beinhaltet. An einen CAN-Bus gesendete Informationen müssen mit definierten Frame-Formaten von unterschiedlichen aber begrenzten Längen konform sein. Ein nicht-konformer CAN-Frame ist ein Frame, der die Spezifikation, die durch die International Organization for Standardization (ISO) verabschiedete CAN-Norm ISO 11898 dargelegt wird, nicht erfüllt. Vorteile für diese Systeme und Verfahren beinhalten:
Erstens, Verfahren zum Schützen bestehender CAN-Systeme gegen eine neue Klasse von Gegnern, die zuvor unbekannt waren und gegen die kein Schutz bestand.
Zweitens, Anwendung von Verfahren in unterschiedlichen Schichten (z. B. Hardware, Anwendungssoftware, Firmware oder in einen Compiler eingebaut), womit dem Systemdesigner auf der Grundlage der spezifischen Architektur eine Vielfalt von Optionen gegeben wird. Die Hardwareverfahren benötigen minimales Schaltungsneudesign und minimalen Mehraufwand. Zusätzlich liefern die Verfahren Flexibilität, so dass sie durch den Eigner des CAN-Controllers oder durch den Gesamtsystemintegrator implementiert werden können.
Drittens sind diese Verfahren auf eine Vielfalt von Systemen anwendbar, die ein CAN-Netzwerk nutzen, wie etwa Automobil-, Luft- und Raumfahrtsysteme, Industrieautomatisierungssysteme, Gebäudeautomatisierungstechnologien. Ferner können die offenbarten Verfahren auf allgemeine Systeme angewandt werden, bei denen Taktsteuerung genutzt werden kann, um die Peripherie in einen unerwünschten Zustand zu treiben.
Ein hier offenbarter Angriff nutzt die Fähigkeit der MCU (z.B. 102, 202), CLKON/CLKOFF-Betrieb von Softwareschnittstellen mit regulären Privilegien durchzuführen. Ferner stützt er sich auf eine Annahme, dass der CAN-Controller seinen Zustand (eingefrorener Zustand) beibehält, wenn der Takt blockiert wird, ohne die Stromzufuhr zu blockieren. Somit können einige Gegenmaßnahmen designt werden, um das Auftreten von einer oder beider dieser Bedingungen von Software zu verhindern. In dieser Offenbarung werden einige wenige Gegenmaßnahmen veranschaulicht, die Verhindern von Taktblockierung, ein Rücksetzen von Taktblockierung, vertrauenswürdige Steuerung des Peripherietakts und Abschalten des Angreifers beinhalten.
Verhindern der Taktblockierung ist ein Schlüsselaspekt zum Schutz gegen Angriffe auf den CAN-Controller, um die Fähigkeit zu hemmen, den Takt willkürlich zu blockieren, und dadurch den Zustand des CAN-Controllers mitten in einer Übertragung zu pausieren. Blockieren des Takts befähigt einen Angreifer dazu, potentiell Teil- und selektive Nachrichtenbits zu übertragen. Den Takt daran zu hindern, zu willkürlichen Zeiten blockiert zu werden, ist eine Technik zum Verhindern willkürlicher Steuerung.
Basierend auf der Implementation der Takttastlogik sind einige Designs zum Steuern des Taktblockierungsmerkmals möglich. Ein Beispiel für den herkömmlichen Takttastmechanismus unter Verwendung eines Active-High-Freischaltsignals ist in 5 veranschaulicht. 5 ist ein Blockdiagramm einer ECU 500, die Takttastung für einen CAN-Controller aufweist. Der Prozessor 502 kommuniziert mit einem CAN-Controller 504 über einen Steuerungs- und Datenbus. Zusätzlich beinhaltet der Prozessor 502 einen Eingabe-/Ausgabe(E-/A)-Pin, der zum Tasten des Takts über Logik 506, wie etwa ein UND-Gatter, verwendet werden kann. Der E-/A-Pin führt eine CAN-Freischaltung-Funktion aus, die den Takt tastet. 6 ist ein Blockdiagramm von Takttastung über Status und Freischaltung für einen CAN-Controller.
6 ist ein Blockdiagramm einer ECU 600, die eine Datenbus- und Steuerbus- und eine Takttastung über Status und Freischaltung für einen CAN-Controller aufweist. Der Prozessor 602 kommuniziert mit dem CAN-Controller 604 über einen Datenbus und einen Steuerbus, und die Takttastlogik 606 wird ferner durch Zusatzlogik 608, wie etwa ein Signal von dem CAN-Controller 604, das den CAN-Controller-Status angibt, qualifiziert. Das System in 6 nutzt eine zusätzliche Indikatorleitung, die den Zustand des CAN-Controllers kennzeichnet. Solch ein Zustand kann eine Kombination verschiedener Signale innerhalb des CAN-Controllers sein, die einen Belegt-Zustand kennzeichnet. Ein Beispiel für einen derartigen Mechanismus ist in 8 präsentiert, in der der Inhalt des Übertragungspuffers zum Verhindern von Takttastung verwendet wird. Der Controller kann beispielsweise nur dann blockiert werden, wenn alle anhängigen Nachrichten übertragen wurden.
8 ist ein Blockdiagramm 800 eines CAN-Controllers 802, der einen Übertragungspufferstatus auf der Grundlage eines Werts eines oder mehrerer Übertragungspuffer 806 aufweist. Der CAN-Controller weist ein Schieberegister 804 auf, das ausgelegt ist zum Wandeln von Daten aus dem bzw. den Übertragungspuffer(n) 806 in einen seriellen Strom von Daten, der über CAN-Tx gesendet werden soll. Der bzw. die Übertragungspuffer 806 beinhalten auch die Logik 808 zum Erzeugen einer Controllerstatusausgabe auf der Grundlage eines Werts oder eines Status des bzw. der Übertragungspuffer(s) 806.
Es sei angemerkt, dass ein derartiges Zusatzsignal den CAN-Controller daran hindern kann, in den Niederleistungsmodus überzugehen, indem immer wieder Daten zu den Übertragungspuffern hinzugefügt werden. Dies kann von einem Gegner ausgenutzt werden, um auch Dienstverweigerungsangriffe bzw. Denial of Service(DoS)-Angriffe zu verursachen. Dies kann allerdings verhindert werden, indem Senden zusätzlicher Nachrichten an die Controllerwarteschlange blockiert wird, nachdem das Taktfreischaltungssignal ausgelöst wurde. Ein Beispiel für ein derartiges System ist in 7 präsentiert, in der die gesamte Schnittstelle zwischen der MCU und dem Controller blockiert ist, wenn das Taktsignal an den Controller blockiert ist. Basierend auf der spezifischen Implementation wird möglicherweise nur eine Untermenge der Schnittstellensignale, verantwortlich für Initialisieren neuer Aktivitäten, blockiert. 7 ist ein Blockdiagramm einer ECU 700, die Takt-, Datenbus- und Steuerbustastung über Status und Freigabe für einen CAN-Controller aufweist. Der Prozessor 702 kommuniziert mit dem CAN-Controller 704 über einen getasteten Datenbus und einen getasteten Steuerungsbus, wobei der Tastmechanismus durch das Taktfreischaltungssignal gesteuert wird. Die Takttastlogik 706 ist ferner durch Zusatzlogik 708, wie etwa ein Signal von dem CAN-Controller 704, das den CAN-Controller-Status angibt, qualifiziert.
Rücksetzen auf Taktblockierung ist eine weitere Schaltung und ein weiteres Verfahren zum Schützen der Integrität von CAN-Kommunikation. Dies basiert darauf, dass der Befähiger für den Angriff die Persistenz des CAN-Controller-Status nach Blockieren des Takts ist. Somit kann eine alternative Schadenminderungsstrategie darin bestehen, zu gewährleisten, dass der Controller in einen sicheren oder einen initialisierten Zustand zurückgesetzt wird, nachdem der Takt für eine hinreichend lange Dauer blockiert wurde. Basierend auf der Architektur des CAN-Controllers sind einige Designs zum Gewährleisten des Rücksetzens des Controllerzustands machbar.
Bei einer einfachen Lösung ist ein Rücksetzsystem unter Verwendung des Signals zum Blockieren des Takts designt. Ein derartiges System ist bei Szenarien nützlich, bei denen ein zusätzlicher Port über den Controllerblock verfügbar ist, um das Taktblockiersignal aufzunehmen. Basierend auf der Controllerarchitektur und dem durch die sequenziellen Logikelemente unterstützten Rücksetzmechanismus kann das System synchrone oder asynchrone Rücksetzsignale erzeugen.
Zur Verhinderung des einfachsten Angriffs ist es nötig, dass das Signal zum Rücksetzen von zumindest der Übertragungspuffer verwendet wird. Es sei angemerkt, dass Werte von Konfigurationsregistern, wie etwa Busgeschwindigkeit, Akzeptanzfilter, Abtastpunkt, keine Sicherheitsbedrohung darstellen und nicht zurückgesetzt werden müssen. Dies würde die Latenz von CAN-Aufsetzen beim Neufreischalten des Takts beträchtlich reduzieren.
9 ist ein Blockdiagramm einer Rücksetzschaltung zum Rücksetzen des Übertragungspuffers über ein Asynchron-Rücksetzsignal. Der CAN-Controller weist ein Schieberegister 904 auf, das ausgelegt ist zum Wandeln von Daten aus dem bzw. den Übertragungspuffer(n) 906 in einen seriellen Strom von Daten, der über CAN-Tx gesendet werden soll. Der bzw. die Übertragungspuffer 906 beinhaltet bzw. beinhalten auch die Logik 908 zum Erzeugen eines Rücksetzens des bzw. der Übertragungspuffer(s) 906 auf der Grundlage einer Taktfreischaltungseingabe. Die Logik 908 kann Verzögerungspuffer beinhalten.
10 ist ein Blockdiagramm einer Rücksetzschaltung zum Rücksetzen des Übertragungspuffers über ein Synchron-Rücksetzsignal. Der CAN-Controller weist ein Schieberegister 1004 auf, das ausgelegt ist zum Wandeln von Daten aus dem bzw. den Übertragungspuffer(n) 1006 in einen seriellen Strom von Daten, der über CAN-Tx gesendet werden soll. Die Logik 1008 wird zum Erzeugen eines Asynchron-Rücksetzsignals verwendet. Die Logik 1008 kann, wie gezeigt, DQ-Flipflops mit Verzögerungspuffern beinhalten, so dass das Rücksetzen an den Übertragungspuffer mit dem Takt synchron ist.
9 veranschaulicht ein einfaches Szenarium, in dem das Taktfreischaltungssignal zum direkten und asynchronen Rücksetzen der Übertragungspuffer verwendet wird. Ein alternatives Verfahren zum synchronen Rücksetzen der sequenziellen Elemente ist in 10 veranschaulicht. In welcher eine Kombination von D-Flipflops, die durch invertierte Taktflanken getriggert werden, und ein hinreichend großer Verzögerungspuffer am Eingang verwendet werden, um zu gewährleisten, dass die Übertragungspuffer zurückgesetzt werden, sobald das Taktsignal blockiert wird. Um richtigen Betrieb zu gewährleisten, sollte die Verzögerung des Eingangspuffers (d_buf) größer als der Taktskew (t_skew) des Controllers sein. Dies gewährleistet, dass die Ausbreitung des Freigabesignals hinreichend verzögert ist, um den Controllerzustand zurückzusetzen.
In Architekturen, in denen keine zusätzlichen Ports verfügbar sind, muss die Rücksetzerzeugungslogik im Innern des Controllerblocks sein. Somit muss das Taktsignal auf den Ruhezustand hin geprüft werden und zum Rücksetzen des Controllerzustands verwendet werden.
Ein derartiges System erfordert die folgenden Komponenten:

Eine Takt-High-Haltedetektionsschaltung, die aus dem Taktsignal besteht und eine Ausgabe liefert, die Takt-Gehalten angibt, wenn das Signal für eine größere Zeitdauer als zweimal die maximale Taktperiode konstant ist. Bei anderen Ausführungsformen kann die Takt-Haltedetektionsschaltung ein Vielfaches von 1,5, 2, 3, 4, 5, 10, 20 Mal die maximale Taktperiode oder eine andere passende periodenbasierende Zeit sein.
Eine Takt-Low-Haltedetektionsschaltung, die aus dem Taktsignal besteht und eine Ausgabe liefert, die Takt-Gehalten angibt, wenn das Signal für eine größere Zeitdauer als zweimal die maximale Taktperiode konstant ist.
Einen Rücksetzerzeugungsmechanismus, der die Ausgabe der Takthaltedetektion nimmt und das Rücksetzsignal für die Controllerelemente ausgibt.

11A ist ein Blockdiagramm eines CAN-Steuerungssystems 1100 mit einem CAN-Controller 1102, der eine Detektionsschaltung 1110 zum Detektieren eines persistenten High-Taktsignals aufweist, mit einer Rücksetzschaltung 1108, die ausgelegt ist zum Rücksetzen des CAN-Controllers 1102 und des bzw. der Übertragungspuffer 1106. Der CAN-Controller 1102 weist ein Schieberegister 1104 auf, das ausgelegt ist zum Wandeln von Daten aus dem bzw. den Übertragungspuffer(n) 1106 in einen seriellen Strom von Daten, der über CAN-Tx gesendet werden soll. Der CAN-Controller 1102 beinhaltet auch eine Persistenter-Takt-Detektionslogik 1110 und eine Rücksetzschaltung 1108 zum Erzeugen eines Rücksetzens an den bzw. die Übertragungspuffer 1106. Die Persistenter-Takt-Detektionslogik 1110 ist ausgelegt zum Detektieren eines persistenten High-Taktsignals. Eine alternative Ausführungsform ist in 11B veranschaulicht, die ein Blockdiagramm eines Detektionssystems 1150 mit einer Detektionsschaltung 1152 zum Detektieren eines persistenten Low-Taktsignals ist.
12 ist ein Flussdiagramm einer Peripheriezustand-Prüffunktion 1200. In Schritt 1202, prüft ein Controller (z. B. Controller 102, 202) den Zustand des Peripheriemoduls (z. B. CAN-Controller, Ethernet-Controller usw.), stellt das Peripheriegerät in den Betriebsmodus zurück (Rückstellen des Peripheriegeräts beinhaltet Rücksetzen der Übertragungspuffer auf null, Neuinitialisieren des Peripheriegeräts, Neuausführen der Peripheriegeräteinitialisierung oder Ähnliches). Schritt 1202 ist der Start der Funktion, die aufgerufen wird, wenn irgendjemand während einer Teilübertragung eine Taktblockierung versucht. In Schritt 1204 prüft der Controller (z. B. Controller 102, 202), ob während einer Teilübertragung ein Versuch zum Blockieren des Takts auftritt. Wenn dem so ist, wird der Controller in Schritt 1206 die Controllerdaten zurücksetzen, in Schritt 1208 die Übertragungspuffer zurücksetzen oder beides. Rücksetzen der Controllerdaten in Schritt 1206 beinhaltet Neuinitialisieren des Peripheriegeräts, Neuausführen der Peripheriegeräteinitialisierung oder Umschalten eines Modul-Rücksetzens über einen Pin oder ein Register. Rücksetzen des Übertragungspuffers in Schritt 1208 beinhaltet Überschreiben des Übertragungspuffers mit Nullen. Der Controller wird zum Schritt 1210 weitergehen, in dem der Controller das Taktblockierung-Taktsignal ausüben wird. Falls in Schritt 1204 die Übertragungspuffer leer sind, wird der Controller zu Schritt 1210 springen.
13 ist ein Flussdiagramm einer Peripheriegerätezustand-Prüffunktion über einen sicheren Coprozessor 1300. In Schritt 1302 geht ein Controller (z. B. Controller 102, 202) zum Schritt 1304 weiter, falls eine Taktblockierungsanweisung erteilt wird, während sich der Controller in einem Benutzerebene-Betriebsmodus befindet. In Schritt 1304, Übergehen des Controllers in den Betrieb über einen sicheren Coprozessor (z. B. einen sicheren Coprozessor, ein Hardware Security Module, eine Trust Zone (in ausgewählten ARM-Prozessoren), eine Secure Guard Extension (SGX) (in ausgewählten Intel-Prozessoren), Secure Encrypted Virtualization Technology (in ausgewählten AMD-Prozessoren), ein Modul einer vertrauenswürdigen Plattform), oder allgemeiner gesagt durch eine Trusted Execution Environment (TEE), die über einen sicheren Prozessor oder Coprozessor gebootstrapped werden kann, die aber auch über eine Kombination von Software und Hardware instanziiert werden kann. Die TEE sollte in einer isolierten Umgebung laufen, in der Operationen an Daten, Code oder einer Kombination von beiden sicher ablaufen (wobei sich sicher auf die Integrität aber auch möglicherweise auf Vertraulichkeit der Daten bezieht). In Fällen, in denen die TEE über eine Kombination von Software und Hardware instanziiert ist, muss die Software mit anderen Mitteln (beispielsweise durch Speichern von dieser in einem Nurlesespeicher) vor Manipulation/Modifikation geschützt werden. In Schritt 1306 führt der sichere Coprozessor eine Peripheriegerätezustand-Prüffunktion aus, wie in 12 veranschaulicht ist. Der sichere Coprozessor prüft beispielsweise, ob während einer Teilübertragung ein Versuch zum Blockieren des Takts auftritt. Wenn dem so ist, wird der sichere Coprozessor wie in Schritt 1206 die Controllerdaten zurücksetzen, wie in Schritt 1208 die Übertragungspuffer zurücksetzen oder beides. Dann wird der sichere Coprozessor den Takt blockieren und zum Schritt 1308 weitergehen. In Schritt 1308 wird der sichere Coprozessor den Betrieb an den im Benutzermodus betriebenen Controller zurückgeben.
Ein Beispiel für eine einfache Kondensatorschaltung, die zum Detektieren eines solchen persistenten Takt-High-Zustands verwendet werden kann, ist in 11A dargestellt. In dieser sollte die Zeitkonstante der Kondensatorschaltung derart eingestellt sein, dass das bei der niedrigsten Frequenz, für die der Controller designt ist, betriebene Taktsignal keine Änderung des binären Zustands des Kondensators auslöst. Dies kann erreicht werden, indem sichergestellt wird, dass τ = RC > 1/(1n(2)*f_min) ist, wobei f_min die minimale Betriebsfrequenz des CAN-Controllers ist. Eine ähnliche Entladeschaltung, in 12 veranschaulicht, kann zum Detektieren eines getasteten Takts, der sich in dem Low-Zustand bzw. 0-Zustand befindet, verwendet werden.
14 ist ein Flussdiagramm einer Peripheriegerätezustand-Prüffunktion über einen Übergang in einen sicheren Betriebsmodus 1400. In Schritt 1402 geht ein Controller (z. B. Controller 102, 202) zum Schritt 1404 weiter, falls eine Taktblockierungsanweisung erteilt wird, während sich der Controller in einem Benutzerebene-Betriebsmodus befindet. In Schritt 1404 geht der Controller in einen sicheren Betriebsmodus über (z. B. von einem Benutzermodus in einen Supervisormodus, von einem Anwendungsmodus in einen Kernel-Modus.) In Schritt 1406, während im sicheren Betriebsmodus, führt der Controller eine Peripheriegerätezustand-Prüffunktion aus, wie in 12 veranschaulicht ist. Der Controller prüft beispielsweise, während im sicheren Betriebsmodus, ob während einer Teilübertragung ein Versuch zum Blockieren des Takts auftritt. Das kann Lesen und/oder Schreiben von Registern beinhalten, die in dem unsicheren Betriebsmodus nicht zugänglich sind. Wenn dem so ist, wird der Controller, während im sicheren Betriebsmodus, wie in Schritt 1206 die Controllerdaten zurücksetzen, wie in Schritt 1208 die Übertragungspuffer zurücksetzen oder beides. Dann wird der Controller den Takt blockieren und zum Schritt 1408 weitergehen. In Schritt 1408 wird der Controller vom sicheren Betriebsmodus in einen unsicheren Betriebsmodus (z. B. Benutzermodus, Anwendungsmodus) übergehen.
Für beide dieser Systeme besteht der Rücksetzerzeugungsmechanismus einfach aus einem Puffer, der mit den Asynchron-Rücksetzpins der Controllerelemente verbunden werden kann. Alternativ kann das Rücksetzsignal mit dem Rücksetzpin der ganzen Peripherie verbunden werden oder kann einen Hardware-Interrupt auslösen, der den Controllerzustand zurücksetzt.
15 ist ein Flussdiagramm einer Peripheriegerätezustand-Prüffunktion über eine Compiler-Funktion 1500, um Taktblockierung mit 12 zu füllen. Bei dieser Ausführungsform beinhaltet ein Compiler eine Taktblockierungsfunktion, in der die Taktblockierung vor Ausführung der Taktblockierung eine Peripheriegerätezustand-Prüffunktion beinhaltet. Während der Codeerzeugung, wenn der Programmierer eine Blockiere-Takt-Funktion in die Kommunikationsperipherie einführt (z. B. Blockiere CAN-Takt, Blockiere Ethernet-Takt), wie etwa in Schritt 1502, wird der Compiler Code dafür einsetzen, eine Peripheriegerätezustand-Prüffunktion (einen Funktionsaufruf, einen Zeilencode oder eine Kombination davon) durchzuführen. In Schritt 1504 wird der Code über einen Compiler/Assembler/Linker verarbeitet, um Anweisungen für den Prozessor zu erzeugen. In Schritt 1506 ersetzt der Compiler den Takt-Blockieren-Aufruf durch die Zustandsprüfungsfunktion.
Obgleich dieses Beispiel ein Compiler ist, kann dies auch in einer Umgebung mit Virtueller Maschine verwendet werden, wie etwa JAVA, Parrot-Virtuelle-Maschine, Common Language Runtime (CLR) oder eine andere Laufzeit-Virtuelle-Maschine.
Eine weitere Ausführungsform ist ein System und ein Verfahren zum Liefern von Schutzbetrieb des CAN-Controllers mit vertrauenswürdiger Steuerung des Peripherietakts. Wenn der CAN-Controller mit dem Prozessor integriert und häufig in einer einzigen Zusammenstellung gepackt ist, ist die Fähigkeit zum Durchführen von CLKON/CLKOFF von nicht-privilegierter Software eine kritische Komponente beim Ermöglichen des Angriffs. In vielen Fällen überlassen diese Systeme die Prüfung, um zu gewährleisten, dass die Übertragungspuffer gespült wurden, dem Softwaredesigner. Während solche Steuerung auf niedriger Ebene den Systemdesignern eine größere Kontrolle gibt, kann sie durch einen Gegner missbraucht werden.
Der Zweck des CLKON/CLKOFF-Merkmals besteht darin, die Chipleistungsaufnahme zu optimieren, und wird somit, basierend auf dem Anwendungsfall, nicht häufig von der Anwendungssoftware benötigt. Um Missbrauch zu verhindern, kann eine derartige Funktionalität in vertrauenswürdige Codestücke ausgelagert werden, wie etwa Gerätetreiber auf niedriger Ebene oder Komponenten, die in einem sicheren Modul laufen, wie etwa ein Hardware-Sicherheitsmodul (HSM), das den Zustand des Controllers vor dem Blockieren des Takts validiert.
16 ist ein Blockdiagramm eines Kommunikationssystems 1600, das einen Supervisor-Knoten 1606, einen Angreiferknoten 1604 und einen Zielknoten 1602 beinhaltet. Der Überwachungsknoten 1606 beinhaltet einen Mikrocontroller 1608, einen Kommunikationscontroller 1610 (z.B. einen CAN-Controller, einen Ethernet-Controller), einen Kommunikationstransceiver 1612 (z. B. einen CAN-Transceiver, einen Ethernet-Transceiver), und eine Kurzschließ- oder Nebenschlussvorrichtung. Der Nebenschluss kann ein Metall-Oxid-Halbleiter-Feldeffekttransistor (MOSFET), ein Bipolartransistor (Bipolar Junction Transistor - BJT), ein Relais oder eine andere Schaltkomponente sein.
Eine Ausführungsform einer MCU mit einem sicheren Prozessor (oder HSM) kann über eine Architektur mit einer Taktzustand-Änderungsanfragefunktion implementiert werden, die als ein Interrupt auf den sicheren Prozessor (oder Enklave) implementiert werden kann. Der sichere Prozessor beinhaltet eine direkte Anfrage, den Zustand des Peripherietakts zu ändern (entweder aktivieren oder deaktivieren), eine alternative Anfrage beinhaltet eine Modusänderungsanfrage zum Ändern des Zustands des Peripherietakts auf der Grundlage von Modusregeln (z. B. HALT-Modus, STOP-Modus, SAFE-Modus, TEST-Modus usw.). Eine Peripheriegerätezustand-Prüffunktion kann innerhalb des sicheren Prozessors oder einer vertrauenswürdigen Umgebung laufen und eine Prüfung von Statusregistern von Peripheriegeräten für einen aktiven Übertragungspuffer (entweder einen Puffer, der nicht leer ist, oder einen, der aktiv überträgt), eine Prüfung des Buszustands des Peripheriegeräts, wie etwa eine aktive Übertragung von irgendeinem Gerät in dem Netzwerk beinhalten.
Ein System oder ein Verfahren, das signierten (oder vertrauenswürdigen) Code verwendet, kann die Standard-Peripheriegerätezustand-Prüffunktion ersetzen. Dieses System oder dieses Verfahren würde gewährleisten, dass der Benutzer weiter Kontrolle auf tiefem Niveau ausübt, wobei diese Kontrolle allerdings nur in einer sicheren Enklave ausgeführt werden kann.
Mit MCUs, die keinen sicheren Coprozessor (oder HSM) aufweisen, kann eine Ausführungsform zum Implementieren einer solchen Anfrage und einer Prüffunktionalität über Treiber auf niedriger Ebene geschehen, die in Firmware implementiert sind. Bei einer anderen Ausführungsform, in der angepasste Compiler (oder Erweiterungen) durch den Chiphersteller der integrierten Schaltung (z. B. Prozessor, eingebetteter Prozessor, Mikrocontroller, ASIC usw.) geliefert werden, um den Code auf hoher Ebene in binären auf niedriger Ebene zu übersetzen, kann die Logik zum Implementieren solcher Prüfungen durch den Compiler für jede Peripheriegeräteanfrage hinzugefügt werden.
Eine weitere Ausführungsform beinhaltet eine Liste von vertrauenswürdigen Autoritäten und Verfahren zum Validieren kryptographischer Signaturen durch die vertrauenswürdigen Autoritäten, wobei die geschützte Peripheriegerätezustandsfunktion durch einen Benutzer definiert werden kann, indem vertrauenswürdige Anweisungen, die aus den Anweisungen und einer kryptographischen Signatur bestehen, über die durch eine vertrauenswürdige Autorität in der Liste ausgegebenen Anweisungen bereitgestellt werden.
Es versteht sich, dass Hinzufügen solcher Anweisungen, Unterroutinen, Funktion usw. zu einem Compiler nicht gegen Gegner schützt, die Laufzeitsoftware unter Verwendung von Techniken, wie etwa Ausgabe-Orientiertes-Programmieren, direkt manipulieren. Allerdings können diese Hinzufügungen eine zusätzliche Schicht an Robustheit liefern, die zusammen mit anderen hier offenbarten Techniken verwendet werden kann.
Abschalten des Angreifers ist der nächste Schritt. Die hier offenbarten Verfahren können zum Verbessern der Robustheit und Sicherheit eines Controllers, der von einem Gegner kontrolliert wird, verwendet werden. In Szenarien, in denen es der Gegner fertig bringt, sämtliche solchen Schutzmaßnahmen zu umgehen, können zusätzliche Gegenmaßnahmen in anderen Knoten, die mit dem Bus verbunden sind, implementiert sein, die den Gegner blockieren (oder angreifen) können, womit der Schaden, den ein Gegner anrichten kann, minimiert wird.
Man nehme zuerst an, dass einige der Knoten auf dem Netzwerk zusätzliche Überwachungsfähigkeiten aufweisen, die zum Detektieren solcher Biteinsetzangriffe verwendet werden können. Diese Knoten können mächtige Knoten beinhalten, wie etwa die Gateway-ECU oder den Karosserie-Controller.
Bei Detektion von schädlichem Verhalten kann ein Knoten während einer Einstreuung von schädlichen Error-Frames durch eine angreifende ECU, gewaltsam rezessive Bits einstreuen. Um solche Bits einzusetzen, benötigt ein Knoten die folgenden Zusatzkomponenten:
einen Schalter (z. B. Metall-Oxid-Halbleiter-Feldeffekttransistor (MOSFET), Bipolartransistor (BJT), eine Tastung, eine Brücke oder ein Relais) in dem CAN-Transceiver, der die Verbindung zwischen den CAN-Bus-Leitungen (z. B. CANH und CANL) überbrücken kann. Einführen eines rezessiven Bits unter Verwendung des Schalters verursacht einen absichtlichen Kurzzeitkurzschluss auf dem CAN-Bus. Dieser absichtliche Kurzschluss kann typischerweise ohne Probleme von den Knoten gehandhabt werden.
Ein erzwungenes rezessives Bitsignal kann zum Aktivieren des Schalters verwendet werden. Solch ein Signal kann typischerweise durch Hinzufügen zusätzlicher Logik bereitgestellt werden, die als eine Schnittstelle zwischen dem Controller und dem Transceiver fungiert.
Bei einer Ausführungsform, bei der die Detektionslogik in dem Prozessor und nicht in dem CAN-Controller vorhanden ist, wird ein zusätzliches Signal zwischen der MCU und dem CAN-Controller benötigt, das zum Signalisieren des erzwungenen rezessiven Bits verwendet werden kann. Bei einer anderen Ausführungsform kann ein Signal direkt zwischen der MCU und dem Transceiver eingespeist werden, wodurch der Controller umgangen wird.
Solche Fähigkeit kann dafür verwendet werden, Bitfehler in den Angreifer einzuführen, womit dieser dazu veranlasst wird, in einen Bus-Aus-Zustand bzw. Rücksetz-Zustand zu gehen. Es sei angemerkt, dass Hinzufügen einer solchen Fähigkeit Abweichen vom typischen Design von CAN-Transceivern und Controllern erfordert, was zusätzliche Fähigkeiten erfordert. Solche Hinzufügungen müssen konform mit dem CAN-Protokoll durchgeführt werden.
In Szenarien, in denen Angreiferknoten-Übertragungen unter Verwendung physischer Charakteristika der Übertragungen (wie etwa Takt-Skew, Spannungspegel oder Transienten) identifiziert werden können, kann der Knoten durch Punktieren jeglicher rezessiver Bits in der Gegneraufsetzphase (z. B. in dem Datenlängensegment der Nachricht) blockiert werden. Ein derartiges Verfahren erfordert zusätzliche Detektionsfähigkeiten auf niedriger Ebene, aber keine zusätzliche Schaltung, um die Busleitungen zu überbrücken. Stattdessen ist es nötig, dass der CAN-Controller die Fähigkeit aufweist, ein erzwungenes dominantes Bit einzustreuen, das zum Übertragen eines Bits verwendet werden kann, selbst dann, wenn der Knoten den Bus nicht kontrolliert.
Der Angriff kann sich auf dieselbe in Software implementierte Funktionalität stützen, womit die Einstreuung der erzwungenen Bits durch einen sicheren Coprozessor (oder HSM) kontrolliert werden kann.
Der Programmcode, der die Algorithmen und/oder Methodologien, die hier beschrieben sind, umsetzt, ist dazu in der Lage, einzeln oder kollektiv in einer Vielzahl von unterschiedlichen Formen als ein Programmprodukt verteilt zu werden. Der Programmcode kann unter Verwendung eines computerlesbaren Speicherungsmediums mit computerlesbaren Programmanweisungen darauf zum Veranlassen, dass ein Prozessor Aspekte einer oder mehrerer Ausführungsformen ausführt, verteilt werden. Computerlesbare Speicherungsmedien, die inhärent beständig sind, können flüchtige und nichtflüchtige und entfernbare und nichtentfernbare greifbare Medien beinhalten, die mit einem beliebigen Verfahren oder einer beliebigen Technologie zur Speicherung von Informationen, wie etwa computerlesbaren Anweisungen, Datenstrukturen, Programmmodulen oder anderen Daten, implementiert werden. Computerlesbare Speicherungsmedien können ferner RAM, ROM, löschbaren programmierbaren Nurlesespeicher (EPROM), elektrisch löschbaren programmierbaren Nurlesespeicher (EEPROM), Flash-Speicher oder eine andere Solid-State-Speichertechnologie, tragbaren Compact-Disc-Read-Only-Speicher (CD-ROM) oder eine andere optische Speicherung, Magnetkassetten, Magnetband, Magnetplattenspeicherung oder andere Magnetspeicherungsvorrichtungen oder ein beliebiges anderes Medium beinhalten, das verwendet werden kann, um die gewünschten Informationen zu speichern, und das von einem Computer gelesen werden kann. Computerlesbare Programmanweisungen können von einem computerlesbaren Speicherungsmedium auf einen Computer, einen anderen Typ einer programmierbaren Datenverarbeitungseinrichtung oder eine andere Vorrichtung oder über ein Netzwerk auf einen externen Computer oder eine externe Speicherungsvorrichtung heruntergeladen werden.
Computerlesbare Programmanweisungen, die auf einem computerlesbaren Medium gespeichert sind, können verwendet werden, um einen Computer, andere Typen einer programmierbaren Datenverarbeitungseinrichtung oder andere Vorrichtungen dazu anzuweisen, auf eine spezielle Weise zu arbeiten, sodass die in dem computerlesbaren Medium gespeicherten Anweisungen einen Herstellungsgegenstand einschließlich Anweisungen produzieren, die die Funktionen, Handlungen und/oder Operationen implementieren, die in den Flussdiagrammen oder Diagrammen spezifiziert sind. Bei gewissen alternativen Ausführungsformen können die Funktionen, Handlungen und/oder Operationen, die in den Flussdiagrammen und Diagrammen spezifiziert sind, in Übereinstimmung mit einer oder mehreren Ausführungsformen umgeordnet, seriell verarbeitet und/oder gleichzeitig verarbeitet werden. Zudem können beliebige der Flussdiagramme und/oder Diagramme mehr oder weniger Knoten oder Blöcke als jene beinhalten, die in Übereinstimmung mit einer oder mehreren Ausführungsformen veranschaulicht sind.
Obgleich die gesamte Erfindung mittels einer Beschreibung von verschiedenen Ausführungsformen veranschaulicht wurde und obgleich diese Ausführungsformen in beträchtlichem Detail beschrieben wurden, hat der Anmelder nicht die Absicht, den Schutzumfang der angehängten Ansprüche auf derartige Details zu beschränken oder auf irgendeine Weise einzuschränken. Zusätzliche Vorteile und Modifikationen werden dem Fachmann sofort in den Sinn kommen. Die Erfindung in ihren breiteren Aspekten ist daher nicht auf die spezifischen Details, die repräsentative Einrichtung und das zugehörige Verfahren und gezeigte und beschriebene veranschaulichende Beispiele beschränkt. Dementsprechend können Abweichungen von solchen Details vorgenommen werden, ohne von dem Wesen oder dem Schutzumfang des allgemeinen erfinderischen Konzepts abzuweichen.
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 Nicht-Patentliteratur

ISO-11898/1 [0008]
ISO-11898/2 [0008]
ISO-11898/3 [0008]
ISO 11783 [0008]
ISO 17458-1 [0008]
ISO 11898 [0023]

Claims

Elektronische Steuereinheit (ECU), die Folgendes umfasst: einen Prozessor; einen Controller Area Network(CAN)-Controller, der einen Status aufweist und ausgelegt ist zum Empfangen von Daten- und Steuersignalen von dem Prozessor und eines Taktsignals, Packen der Daten zum Schaffen eines CAN-Protokoll-Frames, der in mindestens einem Übertragungspuffer gehalten wird, und Verschieben des CAN-Protokoll-Frames zu einem CAN-Transceiver, der ausgelegt ist zum Übertragen des CAN-Protokoll-Frames an einen CAN-Bus; Takttastlogik, ausgelegt zum selektiven Blockieren eines Taktsignals zum CAN-Controller auf der Grundlage eines Steuersignals von dem Prozessor; und Sicherheitstastlogik, ausgelegt zum, als Reaktion darauf, dass der Status des CAN-Controllers aktiv ist, Hemmen des Blockierens des Taktsignals.
Elektronische Steuereinheit nach Anspruch 1, wobei der Status aktiv ist, wenn der CAN-Controller aktiv den CAN-Protokoll-Frame überträgt.
Elektronische Steuereinheit nach Anspruch 2, wobei der Status aktiv ist, wenn mindestens ein Übertragungspuffer über Daten zur Übertragung verfügt, so dass ein Hemme-Takt-Stoppsignal ausgeübt wird, wenn irgendein Bit des mindestens einen Übertragungspuffers eine logische 1 ist.
Elektronische Steuereinheit nach Anspruch 1, ferner umfassend ein Datentransfertasttor und ein Steuersignaltransfertasttor, wobei Übertragung von Daten- und Steuersignalen durch das Datentransfertasttor und das Steuersignaltransfertasttor basierend auf dem Signal gehemmt wird.
Elektronische Steuereinheit nach Anspruch 1, wobei die Sicherheitstastlogik ein Hemme-Takt-Stoppsignal beinhaltet, das ausgeübt wird, während der mindestens eine Übertragungspuffer einen Wert größer als null aufweist, und als Reaktion auf Abschluss von Übertragung eines Frame-Ende bzw. EoF von dem Schiebepuffer, Zurückziehen des Hemme-Takt-Stoppsignals.
Elektronische Steuereinheit nach Anspruch 1, wobei die Sicherheitstastlogik ferner ausgelegt ist zum Rücksetzen des CAN-Controllers, wenn das Taktfreigabesignal inaktiv ist.
Elektronische Steuereinheit nach Anspruch 1, wobei der CAN-Bus ein CAN-High- und ein CAN-Low-Signal umfasst und der CAN-Transceiver ferner zum Kurzschließen des CAN-High- und des CAN-Low-Signals ausgelegt ist.
Elektronische Steuereinheit nach Anspruch 1, wobei die Sicherheitstastlogik ferner ausgelegt ist zum Detektieren eines nicht-konformen CAN-Frames auf dem CAN-Bus.
Elektronische Steuereinheit nach Anspruch 8, die ferner eine Verbindung zwischen dem CAN-Controller und dem CAN-Transceiver beinhaltet, wobei, als Reaktion auf Detektion eines nicht-konformen CAN-Frames auf dem CAN-Bus, ein rezessives Bit auf den CAN-Bus aufgezwungen wird.
Elektronische Steuereinheit nach Anspruch 8, die ferner eine Verbindung zwischen dem Prozessor und dem CAN-Transceiver beinhaltet, wobei, als Reaktion auf Detektion eines nicht-konformen CAN-Frames auf dem CAN-Bus, ein rezessives Bit auf den CAN-Bus aufgezwungen wird.
Elektronische Steuereinheit (ECU), die Folgendes umfasst: einen Prozessor; einen Controller, ausgelegt zum Empfangen von Daten- und Steuersignalen von dem Prozessor, Packen der Daten zum Schaffen eines Protokoll-Frames, der in mindestens einem Übertragungspuffer gehalten wird, und seriellen Verschieben des Protokoll-Frames über einen Schiebepuffer zu einem Transceiver, wobei der Transceiver ausgelegt ist zum Empfangen serieller Daten von dem Controller und zum Übertragen eines Signals auf einem Bus; eine Takttastlogik, ausgelegt zum selektiven Blockieren eines Takts zum Controller auf der Grundlage eines Signals von dem Prozessor; und eine Sicherheitstastlogik, ausgelegt zum, als Reaktion darauf, dass ein Status des Controllers aktiv ist, Hemmen des Blockierens des Takts.
Elektronische Steuereinheit nach Anspruch 11, wobei der Controller ein Institute of Electrical and Electronics Engineers 802-Ethernet-Controller bzw. IEEE 802-Ethernet-Controller ist, der Protokoll-Frame ein Ethernet-Protokoll-Frame ist, der Transceiver ein Ethernet-Transceiver ist und der Bus ein Ethernet-Bus ist.
Elektronische Steuereinheit nach Anspruch 11, wobei der Controller ein Controller Area Network-Controller bzw. CAN-Controller ist, der Protokoll-Frame ein CAN-Protokoll-Frame ist, der Transceiver ein CAN-Transceiver ist und der Bus ein CAN-Bus ist, wobei der Controller ein Controller Area Network-Controller bzw. LIN-Controller ist, der Protokoll-Frame ein LIN-Protokoll-Frame ist, der Transceiver ein LIN-Transceiver ist und der Bus ein LIN-Bus ist, oder wobei der Controller ein Flexray-Controller ist, der Protokoll-Frame ein Flexray-Protokoll-Frame ist, der Transceiver ein Flexray-Transceiver ist und der Bus ein Flexray-Bus ist.
Elektronische Steuereinheit nach Anspruch 13, wobei die Sicherheitstastlogik ein Persistenter-Takt-Detektionssignal beinhaltet, das erzeugt wird, wenn sich der Takt für einen Zeitraum größer als ein minimaler akzeptierter Taktzeitraum nicht ändert.
Elektronische Steuereinheit nach Anspruch 13, wobei die Sicherheitstastlogik ferner ausgelegt ist zum Detektieren eines nicht-konformen CAN-Frames auf dem CAN-Bus, und, als Reaktion auf Detektion eines nicht-konformen CAN-Frames auf dem CAN-Bus zum Aufzwingen eines rezessiven Bits auf den CAN-Bus.
Elektronische Steuereinheit (ECU), die Folgendes umfasst: einen Prozessor; einen Controller, ausgelegt zum Empfangen von Daten- und Steuersignalen von dem Prozessor, Packen der Daten zum Schaffen eines Protokoll-Frames, der in mindestens einem Übertragungspuffer gehalten wird, und seriellen Verschieben des Protokoll-Frames über einen Schiebepuffer zu einem Transceiver, wobei der Transceiver ausgelegt ist zum Empfangen serieller Daten von dem Controller und zum Übertragen des Protokoll-Frames auf einem Bus; eine Takttastlogik, ausgelegt zum selektiven Blockieren eines Takts zum Controller auf der Grundlage eines Signals von dem Prozessor; eine Sicherheitstastlogik ausgelegt zum, als Reaktion darauf, dass ein Status des Controllers aktive Übertragung des Protokoll-Frames angibt, Hemmen des Blockierens des Takts; und eine Rücksetzlogik, ausgelegt zum Rücksetzen des mindestens einen Übertragungspuffers, wenn das Signal von aktiv zu inaktiv übergeht.
Elektronische Steuereinheit nach Anspruch 16, wobei die Rücksetzlogik ein zu dem Takt asynchrones Rücksetzsignal ausgibt.
Elektronische Steuereinheit nach Anspruch 16, wobei die Rücksetzlogik ein zu dem Takt synchrones Rücksetzsignal ausgibt.
Elektronische Steuereinheit nach Anspruch 18, wobei das synchrone Rücksetzsignal durch einen Puffer erzeugt wird, der mit einem ersten D-Flipflop verbunden ist, das durch eine positive Taktflanke getriggert wird, und der mit einem zweiten D-Flipflop verbunden ist, das durch eine negative Flanke getriggert wird.
Elektronische Steuereinheit nach Anspruch 16, wobei die Sicherheitstastlogik ein Persistenter-Takt-Detektionssignal beinhaltet, das erzeugt wird, wenn sich der Takt für einen Zeitraum größer als ein minimaler akzeptierter Taktzeitraum nicht ändert.