CAN-Bus

Was ist der CAN-Bus?

Der CAN-Bus ist ein serieller Feldbus, auf dem jeder angeschlossene Knoten senden kann und jeder Knoten jeden Frame empfängt. Ein Frame trägt einen Identifier (11 Bit, im erweiterten Format 29 Bit), ein Datenfeld mit bis zu 8 Byte bei klassischem CAN und 64 Byte bei CAN FD, eine CRC und ein Bestätigungsbit. Adressen gibt es nicht: Der Identifier sagt, was die Botschaft ist, zum Beispiel Raddrehzahl, und entscheidet zugleich, wer gewinnt, wenn zwei Knoten gleichzeitig senden, weil ein niedrigerer Identifier in der bitweisen Arbitrierung Vorrang hat. Fehlerbehandlung ist eingebaut: Knoten zählen Sende- und Empfangsfehler und nehmen sich vom Bus (Bus-off), wenn die Zähler zu hoch laufen.

Ein Fahrzeug hat mehrere CAN-Segmente (Antrieb, Fahrwerk, Karosserie, Diagnose), die ein Gateway-Steuergerät verbindet. Auch Maschinen und Industrieanlagen nutzen CAN, meist mit CANopen oder SAE J1939 als höherem Protokoll.

Wo ist es definiert?

ISO 11898-1 definiert die Sicherungsschicht und die physikalische Codierungsschicht, einschließlich klassischem CAN, CAN FD und, in der Ausgabe 2024, CAN XL mit Datenfeldern bis 2048 Byte. ISO 11898-2 definiert die Hochgeschwindigkeits-Bitübertragungsschicht, den differenziellen Zweidrahtbus, den die meisten Fahrzeuge nutzen. Höhere Schichten sind eigene Normen: ISO 15765-2 (ISO-TP) segmentiert größere Nachrichten für die Diagnose, ISO 14229 (UDS) definiert die Diagnosedienste, SAE J1939 und CANopen decken Nutzfahrzeuge und Maschinen ab.

Sicherheit ist außerhalb der Reihe ISO 11898 definiert. Secure Onboard Communication (SecOC) von AUTOSAR spezifiziert, wie ein Message Authentication Code und ein Frischewert an eine Botschaft angehängt werden, damit der Empfänger Absender und Aktualität prüfen kann. Die UN-Regelung Nr. 155 listet in Anhang 5 Bedrohungen für Fahrzeugkommunikationskanäle, darunter das Vortäuschen und Einschleusen von Botschaften und die Manipulation fahrzeuginterner Daten, und erwartet vom Hersteller Gegenmaßnahmen.

Was es in der Praxis bedeutet

Jeder Steuergeräte-Penetrationstest und jede Fuzzing-Kampagne bei uns berührt CAN, weil das Steuergerät dort auf den Rest des Fahrzeugs trifft. Drei Punkte entscheiden über die Sicherheit einer CAN-Architektur:

• Wer den Bus erreicht. Der Bus vertraut jedem Knoten, also lautet die eigentliche Frage, welche Steuergeräte mit externen Schnittstellen auf welchem Segment sitzen und wie gut das Gateway zwischen den Segmenten filtert. Eine Telematikeinheit auf demselben Segment wie die Bremse ist ein Architektur-Finding, bevor ein Frame gesendet wird.
• Welche Botschaften authentisiert sind. SecOC mit sauberem Schlüsselmanagement schützt die Signale, die für die Sicherheit zählen. Eine häufige Lücke: SecOC ist konfiguriert, aber der Empfänger verwirft Botschaften mit fehlgeschlagener Prüfung nicht, oder der Frischezähler wird so verwaltet, dass Wiederholungen durchgehen.
• Was der Diagnosekanal freigibt. UDS über CAN ist das eine Protokoll, das in das Steuergerät schreiben soll. Sein Zugriffsschutz und die Sessions, in denen es erreichbar ist, entscheiden, was ein Knoten auf dem Bus mit der Firmware machen kann.

Beim Fuzzing zielen wir auf die ISO-TP-Segmentierung, die Signaldecodierung und das Gateway-Routing und beobachten Resets, Error Frames und Knoten, die in Bus-off gehen. Auf Leistungselektronik-Steuergeräten wie DC/DC-Wandlern und Onboard-Ladegeräten hat das wiederholt Robustheitsprobleme gezeigt, die ein Funktionstest mit gültigen Frames nie erreicht. AutoST, unsere Testsuite, automatisiert diese Art von CAN- und UDS-Tests mit Reset-Erkennung.

Häufige Missverständnisse

CAN-Frames zu verschlüsseln ist selten die Antwort: Die Nutzlast ist zu klein, das Latenzbudget zu knapp, und Vertraulichkeit ist nicht das Problem, Authentizität ist es. Ein CAN-Intrusion-Detection-System erkennt Anomalien, stoppt aber keinen einzelnen wohlgeformten bösartigen Frame. Und “der Bus ist im Auto drin” war nur so lange ein Sicherheitsargument, wie kein Steuergerät ein Modem hatte.