SecOC am CAN-Bus — Authentisierung statt Verschlüsselung erklärt

Ein Diagnosetool meldet einen SecOC-Fehler — und die Leitung ist in Ordnung

Das Diagnosegerät hängt am OBD-Stecker, die Spannung ist stabil, und trotzdem verweigert ein Steuergerät die Annahme einer eigentlich unauffälligen Nachricht. Im Fehlerspeicher steht ein Hinweis auf eine fehlgeschlagene Authentisierung, nicht auf einen Kurzschluss oder eine unterbrochene Leitung. Wer jetzt beginnt, Stecker nachzumessen und Kabelbäume zu prüfen, verliert Zeit an der falschen Stelle. Der Fehler liegt nicht am physischen Bus, sondern an einer Softwareprüfung, die eine Ebene darüber arbeitet.

Diese Prüfung heißt SecOC, ausgeschrieben Secure Onboard Communication, und sie ist Teil der AUTOSAR-Kommunikationsschicht moderner Steuergeräte. Sie entscheidet, ob eine Nachricht auf dem CAN-Bus als authentisch gilt, bevor ein Empfänger sie weiterverarbeitet. Dieser Beitrag ordnet, was SecOC tatsächlich prüft, wie ein Message Authentication Code und ein Freshness-Wert zusammenwirken, und warum ein Verifikationsfehler etwas anderes ist als ein physikalischer Defekt.

Was SecOC wirklich schützt: Herkunft und Aktualität, nicht Geheimhaltung

Die AUTOSAR-Spezifikation zu SecOC nennt den Zweck der Prüfung wörtlich so: Authentisierung und Integritätsschutz sensibler Daten seien notwendig, um die korrekte und sichere Funktion der Fahrzeugsysteme zu schützen, und das stelle sicher, dass empfangene Daten vom richtigen Steuergerät stammen und den richtigen Wert tragen. Dieser Satz nennt zwei Dinge, keine drei. Er spricht von Herkunft und von Korrektheit des Werts, nicht von Geheimhaltung.

Genau das ist der Kern der Verwechslung, die diesem Beitrag zugrunde liegt. Authentisierung beantwortet die Frage, ob eine Nachricht wirklich von dem Steuergerät stammt, das sie zu senden vorgibt, und ob sie nicht nachträglich verändert wurde. Verschlüsselung beantwortet eine völlig andere Frage: ob ein Dritter den Inhalt überhaupt lesen kann. SecOC beantwortet ausschließlich die erste Frage. Ein CAN-Logger, ein Diagnosetool oder ein simples Abhörgerät am Bus sieht den Drehmomentwert, den Bremsdruck oder den Lenkwinkel weiterhin im Klartext, SecOC ändert daran nichts.

Der Message Authentication Code: wie eine Nachricht ihre Herkunft beweist

Der eigentliche Beweis heißt Authenticator, in der Praxis meist ein Message Authentication Code, kurz MAC. Nach der AUTOSAR-Spezifikation wird dieser Wert aus vier Bestandteilen gebildet: einem geheimen Schlüssel, dem Data Identifier der geschützten Nachricht, der eigentlichen Nutzlast und dem Freshness-Wert. Formal beschreibt die Spezifikation das als Verkettung: Data Identifier, gesicherter Teil der Nutzlast und vollständiger Freshness-Wert werden aneinandergehängt und gemeinsam durch den Authentisierungsalgorithmus geschickt.

Sender und Empfänger teilen sich denselben symmetrischen Schlüssel. Der Sender berechnet den MAC bei jeder Übertragung neu und hängt ihn an die Nachricht an. Der Empfänger führt dieselbe Berechnung unabhängig mit seinem eigenen, identischen Schlüssel durch und vergleicht das Ergebnis. Stimmen beide Werte überein, gilt die Nachricht als authentisch. Weicht auch nur ein einziges Bit der Nutzlast vom Originalzustand ab, verändert sich der berechnete MAC vollständig, und der Vergleich schlägt fehl. Genutzt wird dafür überwiegend CMAC auf Basis von AES-128, ein symmetrisches Verfahren, das die Spezifikation ausdrücklich wegen seiner kleinen Schlüssellänge und seiner effizienten Umsetzung in Software wie Hardware bevorzugt.

Der Freshness-Wert: warum eine echte, aber alte Nachricht trotzdem abgelehnt wird

Ein MAC allein würde ein zentrales Problem nicht lösen. Eine mitgeschnittene, tatsächlich echte Nachricht ließe sich später einfach erneut auf den Bus legen, und der MAC bliebe gültig, weil sich an Absender und Inhalt nichts geändert hat. Dieses Vorgehen heißt Replay-Angriff, und genau dagegen schützt der zweite Baustein von SecOC: der Freshness-Wert.

Der Freshness-Wert ist nach Definition der Spezifikation ein monotoner Zähler, der die Aktualität einer geschützten Nachricht sicherstellt. Realisiert wird er entweder über einen fortlaufenden Nachrichtenzähler, den Freshness Counter, oder über einen Zeitstempel, den Freshness Timestamp. Bereitgestellt wird er von einer eigenen Softwarekomponente, dem Freshness Value Manager, kurz FVM. Wichtig ist die Position dieses Werts in der Formel von oben: Er ist kein Anhängsel neben dem MAC, sondern fließt selbst in dessen Berechnung ein. Eine wiederholte, alte Nachricht trägt zwangsläufig einen veralteten Freshness-Wert, und weil dieser Wert Teil der MAC-Berechnung ist, erzeugt er beim Empfänger einen anderen Vergleichswert als erwartet. Die Nachricht fällt durch, obwohl ihr Inhalt Byte für Byte echt ist.

Secured I-PDU und Authentic I-PDU: wie die geschützte Nachricht aufgebaut ist

AUTOSAR unterscheidet zwei Zustände derselben Nachricht. Die Authentic I-PDU ist die ursprüngliche Nutzlast, etwa ein Drehmomentwunsch oder ein Sensorwert, bevor SecOC etwas hinzufügt. Die Secured I-PDU ist dieselbe Nutzlast, ergänzt um die Authentisierungsinformation, also den gekürzten MAC und den gekürzten Freshness-Wert. Erst in dieser gesicherten Form verlässt die Nachricht das sendende Steuergerät und läuft über den Bus.

Konstruiert wird die Secured I-PDU vom SecOC-Modul selbst, das auf Ebene des PDU-Routers in den AUTOSAR-Kommunikationsstapel eingebunden ist. Für die eigentliche Kryptografie greift SecOC auf den Crypto Service Manager zurück, kurz CSM, während die Laufzeitumgebung, die RTE, den Zugriff auf Schlüssel und Zähler organisiert. Auf der Empfängerseite läuft derselbe Weg rückwärts: Das SecOC-Modul zieht die Authentisierungsinformation von der Nutzlast ab, berechnet den erwarteten MAC neu und gibt bei einem Treffer erst die enthaltene Authentic I-PDU an die höheren Softwareschichten weiter.

Warum der Inhalt trotzdem für jeden lesbar bleibt

An dieser Stelle lohnt der Blick auf das, was in der ganzen Kette fehlt: eine Verschlüsselung. Die Authentic I-PDU, also die eigentliche Nutzlast, wird an keiner Stelle in Geheimtext umgewandelt. Sie steht weiterhin unverändert im Datenfeld der CAN-Nachricht, ergänzt lediglich um zusätzliche Bytes für MAC und Freshness-Wert. Ein Werkstatt-Tester, ein CAN-Logger oder ein einfaches Abhörgerät am Bus liest Drehmoment, Bremsdruck oder Lenkwinkel deshalb weiterhin im Klartext, exakt wie ohne SecOC.

Der Unterschied zeigt sich erst, sobald jemand versucht, eine eigene Nachricht einzuspeisen, die ein Steuergerät als echt akzeptieren soll. Ohne den passenden Schlüssel lässt sich kein MAC berechnen, der beim Empfänger den Vergleich besteht, unabhängig davon, wie plausibel der eingespeiste Wert inhaltlich wirkt. Genau diese Eigenschaft macht den Unterschied zwischen Authentisierung und Verschlüsselung praktisch bedeutsam: SecOC verbirgt nichts, aber es erschwert gezielt das Fälschen und Wiedereinspielen von Nachrichten auf geschützten Kommunikationspfaden. Eine Anleitung zum Erzeugen oder Umgehen gültiger Authentisierungswerte liefert dieser Beitrag bewusst nicht, weil er Systemlogik erklärt und keine Eingriffsanleitung ist.

Drei Profile, ein Kompromiss: wie MAC und Freshness-Wert gekürzt werden

Ein vollständiger CMAC auf Basis von AES-128 ist 16 Byte lang, doppelt so viel wie das gesamte Datenfeld einer klassischen CAN-Nachricht mit acht Byte Nutzlast. Ein vollständiger MAC neben dem eigentlichen Signal würde also gar nicht auf den Bus passen. Die AUTOSAR-Spezifikation löst das über Kürzung, englisch Truncation, und definiert dafür drei feste Profile mit unterschiedlichen Längen für den gekürzten MAC und den gekürzten Freshness-Wert.

Profil 1 verwendet einen auf 24 Bit gekürzten MAC zusammen mit einem auf 8 Bit gekürzten Freshness-Wert. Profil 2 verwendet ebenfalls einen 24-Bit-MAC, verzichtet aber vollständig auf einen mitgesendeten Freshness-Wert, und die Spezifikation schreibt ausdrücklich vor, dieses Profil nur zu verwenden, wenn kein synchronisierter Freshness-Wert etabliert werden kann. Profil 3, auch JASPAR-Profil genannt, kürzt den MAC auf 28 Bit und den Freshness-Wert auf 4 Bit, arbeitet mit einer Master-Slave-Synchronisation und ist laut Spezifikation gezielt für den Einsatz auf CAN vorgesehen. Welches Profil ein Fahrzeughersteller je Nachricht konfiguriert, ist eine Entwicklungsentscheidung und variiert zwischen Baureihen und Steuergeräten.

Der Schlüssel: warum er nie auf dem Bus steht

Der symmetrische Schlüssel, mit dem Sender und Empfänger denselben MAC berechnen, wird selbst zu keinem Zeitpunkt über den CAN-Bus übertragen. Er liegt vorab in beiden beteiligten Steuergeräten, verwaltet über die Laufzeitumgebung und die kryptografischen Dienste des Crypto Service Managers. Wie genau ein Schlüssel in ein Steuergerät gelangt, wie er gegen Auslesen geschützt wird und welche Rolle dabei ein Hardware-Sicherheitsmodul oder eine vertrauenswürdige Startkette spielt, ist ein eigenes Themenfeld der Fahrzeug-Cybersecurity und wird hier nicht vertieft.

Für das Verständnis von SecOC reicht die Funktionsebene: Ohne Kenntnis dieses Schlüssels lässt sich kein gültiger Authenticator für eine geschützte Nachricht berechnen, egal wie genau der Aufbau der Secured I-PDU bekannt ist. Der Bus selbst verrät den Schlüssel an keiner Stelle, weil dort ausschließlich das Ergebnis der Berechnung sichtbar wird, nie ihre Eingabe.

Wenn die Prüfung fehlschlägt: kein Kabelfehler, sondern ein definierter Zustand

Was passiert, wenn die Prüfung beim Empfänger scheitert, ist in der Spezifikation genau festgelegt, und dieser Ablauf erklärt, warum ein SecOC-Fehler selten etwas mit der Verkabelung zu tun hat. Schlägt die Freshness-Prüfung fehl, erhöht das SecOC-Modul einen internen Zähler für Authentisierungsversuche. Erreicht dieser Zähler die konfigurierte Grenze, verwirft das Modul die betroffene Nachricht endgültig und meldet den Fehler als Freshness-Failure an die interne Fehlerverfolgung. Unabhängig davon meldet eine gescheiterte oder erfolgreiche Verifikation einer Secured I-PDU zusätzlich einen eigenen Zustand an das Diagnose-Ereignismanagement des Fahrzeugs, jenen Teil der Software, der später auch die im Werkstattgerät sichtbaren Fehlercodes verwaltet.

Diese ganze Kette läuft ausschließlich in Software ab, oberhalb der physischen Bitübertragung. Ein besonders alltagsnaher Auslöser zeigt das deutlich: Wird die Fahrzeugbatterie abgeklemmt, etwa bei einer Werkstattarbeit oder einer Nachrüstung, kann der Freshness-Zustand einzelner Steuergeräte zurückgesetzt werden. Die Synchronisation zwischen einem führenden und den beteiligten Steuergeräten arbeitet dabei laut Spezifikation mit eigenen Zählern für Fahrt, Reset und Nachricht, die nach einem solchen Ereignis erst neu abgeglichen werden müssen. Bis dieser Abgleich abgeschlossen ist, können geschützte Nachrichten vorübergehend abgelehnt werden, obwohl der Bus elektrisch vollkommen unauffällig arbeitet. Wer das nicht kennt, jagt einem Kabelfehler hinterher, der nie existiert hat.

SecOC, Secure Gateway und Secure Boot: drei getrennte Aufgaben

Drei Begriffe aus der Fahrzeug-Cybersecurity werden in der Praxis häufig vermischt, obwohl sie unterschiedliche Ebenen betreffen. Secure Boot prüft beim Start eines Steuergeräts, ob dessen Software unverändert und vertrauenswürdig ist, bevor sie überhaupt ausgeführt wird. Ein Secure Gateway entscheidet, welche Diagnosezugriffe und welche Kommunikationswege zwischen Steuergeräten überhaupt erlaubt sind, und verlangt dafür häufig eine eigene Freigabe. SecOC arbeitet auf einer dritten Ebene: Es prüft nicht den Startzustand eines Steuergeräts und nicht die Berechtigung eines Zugriffswegs, sondern ausschließlich, ob eine einzelne, bereits übertragene Nachricht echt und aktuell ist.

Diese drei Mechanismen laufen unabhängig voneinander. Ein Steuergerät kann einen einwandfreien Secure-Boot-Zustand haben und trotzdem eine SecOC-Nachricht ablehnen, wenn deren Freshness-Wert nicht passt. Ein Diagnosezugriff kann über das Secure Gateway freigegeben sein, ohne dass das etwas an der Authentisierung der laufenden Buskommunikation ändert. Wer einen Fehler einer dieser drei Ebenen zuschreibt, ohne die anderen beiden auszuschließen, verwechselt Schutzmechanismen, die auf dem Papier ähnlich klingen, aber technisch nichts miteinander zu tun haben.

Was ein Nachrüstteil mit SecOC-geschützten Nachrichten zu tun hat

Für ein reines Auslesegerät, das Werte nur mitliest und selbst nichts auf den Bus sendet, ändert SecOC praktisch nichts. Der Inhalt bleibt lesbar, ein Logger zeichnet ihn unverändert auf, ganz gleich, ob die zugehörige Nachricht zusätzlich authentisiert ist oder nicht. Anders sieht es bei einem Nachrüstteil aus, das aktiv einen Wert auf einem geschützten Kommunikationspfad einspeisen oder verändern müsste, damit ein Steuergerät ihn übernimmt. Genau für diesen Fall ist SecOC nach eigener Zweckbeschreibung der AUTOSAR-Spezifikation als ressourcenschonender, praxistauglicher Zusatzschutz für bestehende Systeme konzipiert worden, ohne dabei die übrige Kommunikation spürbar zu belasten.

Praktisch bedeutet das: Ein Steuergerät, das eine bestimmte Nachricht als SecOC-geschützt erwartet, nimmt einen unpassend authentisierten oder unauthentisierten Ersatzwert nicht als echt an, selbst wenn Format und Dateninhalt korrekt aussehen. Für die Arbeit an einem nachgerüsteten Fahrzeug folgt daraus vor allem eine Dokumentationspflicht statt einer Bastelanleitung. Wer erkennt, dass eine bestimmte Nachricht authentisiert ist, hält das fest, statt sie unbeachtet zu lassen, und prüft nach jedem größeren Eingriff, ob ein zuvor unauffälliges Steuergerät neue Verifikationsfehler zeigt. Und nach jedem Abklemmen der Batterie gehört ein kurzer Blick auf den Fehlerspeicher zur Routine, bevor ein neuer Fehler vorschnell einem eingebauten Bauteil zugeschrieben wird.

Regulatorischer Rahmen: wo Softwareänderungen an sicherheitsrelevanten Systemen stehen

Cybersecurity in Fahrzeugen ist inzwischen kein rein technisches Thema mehr, sondern auch ein geregeltes. ISO/SAE 21434 beschreibt Cybersecurity als Aufgabe über den gesamten Lebenszyklus elektrischer und elektronischer Systeme, von der Entwicklung bis zur Außerbetriebnahme, und steht 2026 unter einer laufenden turnusmäßigen Überprüfung, ohne dass bereits eine neue Ausgabe feststeht. Auf Genehmigungsseite ergänzen die UN-Regelungen Nr. 155 und Nr. 156 den organisatorischen Rahmen für Cybersecurity-Managementsysteme und für kontrollierte Software-Updates, und auch hier laufen 2026 weiterhin Änderungs- und Umsetzungsarbeiten in mehreren Rechtsräumen. Ein Entwurfsstand wird deshalb in diesem Beitrag nicht als bereits geltende Endfassung behandelt.

Wer softwareseitig in eine Kommunikationsschicht eingreift, die solche Sicherheits- und Authentisierungsfunktionen trägt, verändert damit möglicherweise mehr als nur einen einzelnen Wert im Fahrzeugverhalten. Die Straßenverkehrs-Zulassungs-Ordnung behandelt Softwareänderungen an einem zugelassenen Fahrzeug ausdrücklich, nicht nur den Tausch von Hardware, und genau darauf zielt die Kette aus Genehmigung, Auflagen und Abnahme, die weiter unten belegt ist.

Umbauten am eigenen Fahrzeug. Ob ein Umbau auf öffentlichen Straßen betrieben werden darf, entscheidet der Genehmigungszustand des Fahrzeugs — die Genehmigung des Teils, der Einbau nach ihren Auflagen und, wo nötig, die Abnahme durch eine dafür zuständige Stelle. Solange diese Kette nicht vollständig ist, gehört der Umbau auf Privatgelände, Testflächen und in nicht öffentliche Bereiche.

Welche Norm dabei konkret greift und welchen Wortlaut sie trägt, steht ausführlich im Einordnungsblock am Ende dieses Beitrags. Für diesen Abschnitt zählt der Grundsatz: Eine Änderung, die sicherheitsrelevante Kommunikation berührt, kann die genehmigte Fahrzeugart oder eine Gefährdungslage so verändern, dass die Betriebserlaubnis betroffen ist, und Softwareänderungen sind davon ausdrücklich nicht ausgenommen.

Häufige Fragen

Einordnung: wo die Angaben herkommen

Die Fundstellen stehen hier gebündelt, damit der Fließtext ohne Normzitate und Spezifikationsverweise auskommt. Die AUTOSAR-Spezifikation ist am 18.09.2026 am amtlichen Angebot des Herausgebers beschafft und im Volltext gegengelesen worden, der Normtext zu § 19 StVZO am selben Tag am amtlichen Angebot.