SecOC (Secure Onboard Communication)
SecOC ist der AUTOSAR-Mechanismus, der Fahrzeugnachrichten mit MAC und Freshness authentifiziert. Wie er auf CAN funktioniert und was ein Bustest prüfen kann.
Aktualisiert Diese Seite als Markdown
Kurz gesagt
SecOC (Secure Onboard Communication) ist das AUTOSAR-Modul, das ausgewählte Fahrzeugnachrichten gegen Spoofing und Replay schützt. Es hängt an eine geschützte Nachricht einen Message Authentication Code (MAC) und einen Freshness-Wert an, sodass ein Empfänger prüfen kann, dass der Sender den gemeinsamen Schlüssel hielt und dass die Nachricht kein Replay ist. Die Payload wird nicht verschlüsselt. Auf CAN begrenzt der kleine Frame, wie viele MAC- und Freshness-Bytes passen, was die meisten realen Designs prägt.
Was ist SecOC?
SecOC ist ein AUTOSAR-Modul, das zwischen Applikation und Kommunikationsstack sitzt und den Nachrichten, die ein Projekt als geschützt markiert, Authentifizierung hinzufügt. Für eine solche Nachricht berechnet es mit einem gemeinsamen symmetrischen Schlüssel einen MAC über Nachricht und Freshness-Wert und überträgt die Nachricht zusammen mit (einem Teil) der Freshness und einem (meist gekürzten) MAC. Der Empfänger rechnet den MAC nach, vergleicht ihn und prüft die Freshness und verwirft die Nachricht, wenn eines davon fehlschlägt.
Auf CAN sieht ein geschütztes Signal typisch so aus: Payload-Bytes, ein paar Freshness-Bits und ein gekürzter MAC, gepackt in denselben 8-Byte-Frame oder in einen Begleit-Frame, wenn kein Platz ist. CAN FD mit bis zu 64 Bytes macht einen MAC in voller Länge praktikabel.
Wo ist es definiert?
AUTOSAR spezifiziert SecOC in der Classic Platform (Specification of Secure Onboard Communication) und in der Adaptive Platform. Die Krypto darunter kommt über den Crypto Service Manager und wird meist von einem HSM oder SHE gestützt. SecOC adressiert mehrere Bedrohungen, die UN R155 Anhang 5 für die Fahrzeugkommunikation listet, vor allem Spoofing und Replay von Nachrichten.
Was es in der Praxis bedeutet
SecOC macht aus einem Bus, auf dem jeder Knoten jeden Identifier senden kann, einen, auf dem geschützte Nachrichten einen Herkunftsnachweis tragen. Das zählt für safety-relevante Signale, die früher trivial zu spoofen waren. Die Kompromisse liegen im Freshness-Management (Zähler, die nicht driften dürfen, Resynchronisation nach Reset), in der Kürzungslänge und in der Frage, welche Nachrichten überhaupt geschützt sind, denn jede Nachricht zu schützen ist selten bezahlbar.
Am Prüfstand sind die beobachtbaren Fragen: Lehnt ein Empfänger eine geschützte Nachricht mit falschem oder fehlendem MAC wirklich ab, lässt sich eine alte aufgezeichnete Nachricht erfolgreich wieder einspielen, und existiert eine ungeschützte Kopie eines Safety-Signals. Den Schlüssel oder den MAC-Algorithmus selbst anzugreifen ist Krypto- und Firmware-Arbeit.
Wie AutoST es testet
AutoST arbeitet auf Bus- und Diagnoseebene. Bei CAN- und CAN-FD-Tests erfasst es, welche Identifier geschützte Nachrichten tragen, und kann Frames mit veränderten oder fehlenden Authentifizierungsbytes senden, um zu beobachten, ob das empfangende Steuergerät sie ablehnt. Schlüssel gewinnt AutoST nicht zurück, den MAC-Algorithmus bricht es nicht, und das Freshness-Schema verifiziert es nicht kryptografisch; das ist Penetrationstest- und Firmware-Arbeit.
Häufige Missverständnisse
SecOC ist Authentifizierung, keine Verschlüsselung, ein geschütztes Signal bleibt also lesbar. Ein kurzer MAC ist eine Bandbreitenentscheidung, für sich kein Fehler, aber er verkleinert den Sicherheitsabstand. Und SecOC schützt nur die Nachrichten, die ein Projekt zu schützen gewählt hat; eine ungeschützte Dublette hebt den Zweck auf.
FAQ
Häufig gestellte Fragen
Verschlüsselt SecOC Nachrichten?
Nein. SecOC authentifiziert, es hält Daten nicht vertraulich. Es ergänzt MAC und Freshness, damit ein Empfänger Herkunft prüfen und Replays ablehnen kann, aber die Payload bleibt auf dem Bus lesbar. Vertraulichkeit braucht einen eigenen Mechanismus wie TLS auf Ethernet-Links.
Wofür ist der Freshness-Wert da?
Er stoppt Replay-Angriffe. Ohne Freshness könnte ein Angreifer eine authentifizierte Nachricht aufzeichnen und später erneut senden, und der MAC würde weiter stimmen. Der Freshness-Wert, meist ein Zähler oder ein zeitbasierter Wert, macht jede authentifizierte Nachricht einmalig, und beide Seiten müssen ihn synchron halten.
Warum werden MAC und Freshness auf CAN oft gekürzt?
Ein klassischer CAN-Frame fasst nur 8 Bytes, die meist die Payload braucht. Designs senden deshalb nur die unteren Bits der Freshness und einen gekürzten MAC, oft 24 oder 28 Bit. Das ist ein bewusster Kompromiss, und wie viele Bits genutzt werden, ist ein Design-Parameter, den man prüfen sollte.
Quellen
Passende Seiten
- GlossarCAN-Bus (Controller Area Network)CAN (ISO 11898) ist der Broadcast-Bus, den sich die meisten Steuergeräte teilen: Identifier, Arbitrierung, Fehlerbehandlung. Was das für Security-Tests bedeutet.
- GlossarHSM (Hardware Security Module)Ein HSM ist ein geschützter Kern im Mikrocontroller, der Schlüssel speichert und Krypto für SecOC, Secure Boot und Diagnose ausführt. Was ein Bustest davon sieht.
- GlossarSecure BootSecure Boot verifiziert ein Firmware-Image, bevor es läuft, damit unsignierte oder veränderte Software nicht startet. Wie es funktioniert und was ein Bustest sieht.
- InsightsSecOC testen von der Bus-Seite: was ein Tester prüfen kannWie du AUTOSAR SecOC ohne die Keys testest: Freshness und MAC auf dem Bus, Replay- und Reorder-Verhalten, verkürzte MAC-Länge, und was jedes Ergebnis sagt.
- PlattformSpricht die Busse, die deine ECUs sprechen.AutoST unterstützt CAN, CAN FD, ISO-TP, UDS, XCP, CCP, DoIP und SOME/IP, mit SocketCAN-, Vector-XL- und comma.ai-Panda-Adaptern unter Windows und Linux.
