Startseite > Automotive > Authentische CAN-Kommunikation

Cyber-Security sicherstellen

Authentische CAN-Kommunikation

13. März 2018, 17:30 Uhr | Von Klaus Scheibert, Qing Wu Zou und Kok Cheng Gui

▶ Diesen Artikel anhören

Fortsetzung des Artikels von Teil 1

Frame-Zähler-Konzept

Bei diesem Konzept wird in jeder Sender- oder Empfänger-ECU ein dedizierter lokaler Frame-Zähler für die Übertragung der CAN-Nachrichten implementiert. Der Zähler zählt nur nach jedem erfolgreich gesendeten oder empfangenen Ereignis aufwärts. Aus diesem Grund gibt es hier auch keine Time-Jitter-(Delta)-Abweichung wie beim Zeitstempel-Ansatz. Darüber hinaus kann bei einem Verlust einer CAN-Nachricht oder fehlgeschlagener Synchronisation zwischen ECUs diese durch Resynchronisation des Frame-Zählers wiederhergestellt werden.

Jobangebote+ passend zum Thema

Regional Key Account (m/w/d) für Elektronische Bauteile

KOA Europe GmbH, Dägeling

Alle Jobangebote im Elektroniknet Karrierebereich anzeigen

Die Erzeugung des CMAC basiert wieder auf drei Eingabeparametern
(Bild 3): der eigentlichen Mitteilung, dem verkürzten Frame-Zähler (TFC) des Senders und einem zuvor geladenen, symmetrischen geheimen Schlüssel (TMAC). Der lokale Frame-Zähler des Senders muss beim erfolgreichen Versand – beispielsweise durch Überprüfung des eigenen Empfangs des Senders – einer sicheren CAN-Nachricht um einen Zählerwert erhöht werden. Bei einer fehlgeschlagenen Übertragung wird der Zählerwert nicht erhöht.
Ähnlich wie beim Zeitstempelkonzept muss der Empfänger (Bild 3) beim Empfang einer sicheren Mitteilung zwei Prüfungen (Freshness und Authentizität) durchführen. Wenn sowohl die Aktualitäts- als auch die Authentizitätsprüfung erfolgreich sind, muss der Frame-Zähler des Empfängers um eins erhöht werden. Bei einem erfolglosen Empfang wird der Zählerwert nicht erhöht und die aktuelle Nachricht entweder als gestört oder als Replay- bzw. Delay-Attacke interpretiert.

Implementierung beider Konzepte

Beide hier vorgestellten Konzepte weisen gewisse Herausforderungen bei der Implementierung auf. Beim Zeitstempel-Verfahren sind folgende Aspekte kritisch:

der Time-Jitter der Taktoszillatoren der verschiedenen ECUs
das Synchronisationsverhalten bei elektromagnetischen Störungen
die niedrige Priorität einer sicheren CAN-Message-ID kann zu einer nicht vorhersehbaren Übertragungsverzögerung führen, die die zulässigen Clock-Delta-Werte überschreitet.

Um durch die Prüfung der Aktualität eine Replay-Attacke auszuschließen, müssen die lokalen Zeitstempel von Sender und Empfänger synchronisiert werden. Es sei im folgendem angenommen, dass die Synchronisation nur einmal bei Key-On-Ereignissen erfolgt und dass die Clock-Toleranz jeder ECU maximal XTAL +/- 0,02 Prozent beträgt. Bei einer angenommenen ECU_A mit einer Clock Abweichung von +0,02 Prozent XTAL und einer ECU_B mit -0,02 Prozent XTAL ergeben sich dann die berechneten maximalen Jitter wie in Tabelle dargestellt.

Daraus lässt sich dann ablesen, dass für eine Freshness von einer Sekunde bezogen auf XTAL sich eine maximale Jitter-Abweichung von 400 µs zwischen ECU_A und ECU_B ergibt. Daher muss die Synchronisation des ECU-Netzwerks regelmäßig durchgeführt werden. Beim Frame-Zähler-Konzept ist eine Synchronisation nur erforderlich, wenn die Frame-Zähler nicht mehr synchronisiert sind, beispielsweise wenn aufgrund elektromagnetischer Störungen oder Unverträglichkeit die Synchronisation verloren geht.

Das ECU-CAN-Netzwerksystemverhalten muss selbst bei niedriger Nachrichten-Priorität garantieren, dass die ID der sicheren Synchronisationsmitteilung innerhalb von beispielsweise 5 ms versendet wird. Dafür wird das Akzeptanzfenster beispielsweise um +/- 5 ms erhöht. Alle sicheren CAN-ID Nachrichten sollten folglich eine CAN ID mit höherer Priorität als die Synchronisationsnachricht selbst bekommen.

Kritische Aspekte beim Frame-Zähler-Konzept sind:

Replay-Detektion und -Abwehr

Die Inkrementierung des Frame-Zählers erfolgt beim Empfang der CAN-Nachricht, wobei das Timing variiert. Wenn die ausgewählte CAN-Nachricht normalerweise sekündlich versendet wird, ist auch das Replay-Fenster eine Sekunde lang. Infolgedessen können innerhalb einer Sekunde 1.000 Nachrichten als Replay gesendet werden. Eine praktikable Schutzmaßnahme wäre eine lokale Replay-Zählervariable für jede Mitteilungs-ID in der empfangenden ECU. Wenn beispielsweise die gleiche Nachricht in der Lücke zwischen zwei aufeinanderfolgenden Standardnachrichten erneut empfangen wird, wird der lokale Zähler inkrementiert. Wenn der Zählerwert einen definierten Wert übersteigt, wird eine Replay-Attacke erkannt.

Höhere CPU-Belastung durch Frame-Zähler

Die Inkrementierung des Frame-Zählers führt zu einer höheren Belastung der CPU. Das gilt insbesondere dann, wenn mehrere CAN-Nachrichten ausgewählt wurden. Für jede empfangene Nachricht erhöht die Software den Frame-Zähler. Bei einer CAN-Aktualisierungsrate von standardmäßig 0,5 MBaud beträgt die CAN-Frame-Message-Zeit mindestens 1 ms. Das dürfte allerdings kein Problem sein, wenn der CAN-Interrupt-Service-Routine (ISR) eine relativ hohe Priorität besitzt, sodass ein Zähler nach jeweils 1 ms aktualisiert wird.

Umgang mit CRC CAN-Protokoll-Fehlern (Cyclic Redundancy Check) CRC-Fehler können durch elektromagnetische Störungen auftreten. Eine Lösung wäre die Einführung eines Rückmeldesignals (Feedback). Der Sender sollte über ein zusätzliches CAN-Message-Objekt verfügen, das die gleiche (selbst gesendete) sichere CAN-Nachricht auch selbst empfängt. Der Sender darf den Frame-Zähler nur dann inkrementieren, wenn er seine eigene Nachricht korrekt empfangen konnte.

Umgang mit Synchronisationsnachrichten

Bei Verlust der Synchronisation (Bild 4) kann die ECU eine „Request-Sync“-Nachricht an die globale Sync-Master-ECU senden. Sobald die Master-ECU eine derartige Anforderung empfängt, sendet sie per Broadcasting eine Sync-Nachricht an alle teilnehmenden ECUs im CAN-Netzwerk. Diese Anforderung kann eine normale CAN-Nachricht mit einer hohen ID-Priorität sein. Wenn Hacker die Request-Sync-Anforderung erneut abspielen, könnte die Master-ECU das CAN-System mit Spam überfluten. Die Master-ECU kann diesen Spam mit einem Software-Filter verhindern.

Unter Berücksichtigung der dargestellten Problemstellungen wurde für den Testaufbau zur Überprüfung der sicheren CAN-Kommunikation der Frame-Zähler-Ansatz gewählt. Die entsprechende Implementierung ist durch einen geringeren Kommunikations-Overhead und geringere Software-Komplexität gekennzeichnet. Außerdem können Jitter-Effekte in Bezug auf mehrere ECUs vernachlässigt werden.

Die sichere authentische Kommunikation erfordert den Schutz gegenüber unerlaubten Manipulationen und Replay-Angriffen. Dabei umfasst die Daten-manipulation das Einbringen, Löschen und den Austausch von Daten. Ein Replay-Angriff erfolgt in zwei Stufen – der passiven Erfassung der Nachricht und der mehrfachen Übertragung dieser Nachricht. Für die Manipulation und den Replay-Angriff kann eine entsprechende gehackte ECU oder ein neuer CAN-Knoten im Netzwerk genutzt werden.

Testaufbauten mit drei Applikation-Boards (Sender, Empfänger und Angreifer) auf Basis des Aurix 234LP zeigten die Robustheit des Ansatzes gegenüber Manipulationen und Replay-Angriffen (Bild 5). Bei dem Testaufbau fungierte das dritte Aurix-Board als Angreifer (Man-in-the-Middle Attacker). Das Board überwacht alle Nachrichten auf dem CAN-Bus, erfasst die letzte Nachricht, modifiziert diese oder sendet einfach die letzte Nachricht nochmals.

In dem Test konnte die Empfänger-ECU schnell Manipulationen detektieren, da die TMAC der manipulierten Nachrichten immer von der berechneten TMAC abweicht. Für die ECU ist es so unmöglich, zufällig die korrekte MAC zu erzeugen, wenn sie nicht über den entsprechenden Schlüssel verfügt.

Für alle beobachteten Testfälle konnte das System die Manipulations- und Replay-Angriffe detektieren und in den synchronisierten Betrieb zurückkehren. So war keine neue Synchronisation erforderlich. Es zeigte sich aber, dass wenn Hacker die Sync-Nachrichten erneut übertragen, die Synchronisation verloren geht. Hier empfiehlt sich ein zusätzlicher Fehler-Zähler, der nach einer bestimmten Anzahl von Fehlern dafür sorgt, dass der Empfänger eine Request-Sync-Nachricht an die Master-ECU sendet.

Die Autoren