SecOC testen von der Bus-Seite: was ein Tester prüfen kann

SecOC (AUTOSAR Secure Onboard Communication) ergänzt ausgewählte CAN-Nachrichten um einen Message Authentication Code (MAC) und einen Freshness-Wert, damit ein Empfänger gefälschte oder wiederholte Frames ablehnen kann. AutoST und jeder Bus-seitige Tester arbeiten an dem Teil, den du ohne den geheimen Key beobachten kannst: ist der Authenticator wirklich vorhanden, lehnt der Empfänger ein Replay ab, verwirft er einen Frame mit gebrochenem MAC, und verhält sich das Freshness-Fenster sauber. Diese Prüfungen fangen die Konfigurationsfehler, die SecOC wirkungslos machen, und keine davon bricht die Kryptografie. Das Fälschen eines gültigen MAC gehört hier nicht dazu; dort übernimmt ein Penetrationstester mit Schlüsselmaterial oder ein HSM-Review.

Was auf dem Bus liegt

Eine SecOC-geschützte Nachricht trägt ihren normalen Payload plus einen Secured-Teil: einen Freshness-Wert (oft ein verkürzter Zähler) und einen verkürzten MAC. Ein typisches Layout auf einem klassischen CAN-Frame sieht so aus:

Payload:    2 Bytes  (das eigentliche Signal, z. B. eine Momentanforderung)
Freshness:  1 Byte   (niedrige Bits des Freshness-Zählers)
MAC:        bis zu 5 Bytes (verkürzter Authenticator)

Der MAC wird über Payload, Freshness-Wert und einen Data Identifier berechnet, mit einem Key im sendenden und im empfangenden Steuergerät. Der Empfänger berechnet den MAC aus seiner eigenen Freshness-Schätzung neu und vergleicht das verkürzte Ergebnis. Ein Tester liest dieses Layout aus der Kommunikationsmatrix: welche Message-IDs gesichert sind, wie lang der MAC ist und wie die Freshness aufgebaut ist.

Die Prüfungen, die ein Bus-seitiger Tester ausführen kann

Ist der Authenticator überhaupt vorhanden

Die erste Prüfung ist die billigste. Zeichne die Nachrichten auf, die die Matrix als gesichert markiert, und bestätige, dass die Freshness- und MAC-Bytes wirklich da sind und sich über die Zeit ändern. Ein als gesichert geführtes Signal, das als reiner Payload rausgeht oder mit einem MAC, der sich nie ändert, ist eine Konfiguration, die nie eingeschaltet wurde.

Wird ein Replay abgelehnt

Zeichne einen echten gesicherten Frame auf und sende ihn später unverändert erneut. Ein korrekter Empfänger lehnt ihn ab, weil der Freshness-Wert jetzt veraltet ist. Handelt der Empfänger auf das wiederholte Signal, ist entweder die Freshness-Prüfung aus oder das Fenster so breit, dass ein Replay darin trivial ist. Das ist die wertvollste einzelne SecOC-Prüfung, und sie braucht keinen Key.

beobachtet: echter Frame, Freshness-Zähler = 0x41
Replay:     gleicher Frame, Freshness-Zähler = 0x41   (jetzt veraltet)
erwartet:   Empfänger ignoriert ihn
schwach:    Empfänger handelt darauf  -> Freshness nicht durchgesetzt

Wird ein verfälschter MAC verworfen

Nimm einen echten Frame, kippe ein Bit im MAC-Feld und sende ihn. Der Empfänger muss ihn verwerfen. Wird er verarbeitet, ist die Verifikation entweder aus oder fällt bei einem Fehler auf Akzeptieren zurück, eine häufige und ernste Fehlkonfiguration. Ein Bit im Payload zu kippen und den MAC unangetastet zu lassen prüft dasselbe von der anderen Seite: der neu berechnete MAC passt nicht mehr, also muss der Frame verworfen werden.

Wie breit ist das Freshness-Fenster

Empfänger tolerieren etwas Drift im Freshness-Zähler, damit ein verlorener Frame sie nicht desynchronisiert. Sende Frames mit Freshness-Werten vor und hinter dem aktuellen und beobachte, wo die Akzeptanz endet. Ein Fenster von wenigen Zählwerten ist vertretbar; ein Fenster von Hunderten oder ohne obere Grenze schwächt den Replay-Schutz, den du gerade bestätigt hast.

Sind alle Nachrichten einer Gruppe geschützt

Eine häufige Lücke ist Teilabdeckung: die Hauptnachricht einer Funktion ist gesichert, eine verwandte Nachricht, die denselben Aktor beeinflusst, aber nicht. Vergleiche den gesicherten Satz auf dem Bus mit dem vollen Satz sicherheits- oder security-relevanter Nachrichten dieser Funktion. Eine ungeschützte Schwester-Nachricht ist ein Weg um die geschützte herum.

Was die Ergebnisse bedeuten

Beobachtung	Was es bedeutet
Kein MAC oder statischer MAC auf einer gesicherten ID	SecOC für diese Nachricht nicht aktiv
Replay akzeptiert	Freshness nicht durchgesetzt oder Fenster zu breit
Verfälschter MAC akzeptiert	Verifikation aus oder Fail-Open-Rückfall
Payload-Änderung ohne MAC-Änderung akzeptiert	Empfänger prüft den MAC nicht
Verwandte Nachricht ungeschützt	Teilabdeckung, Schutz umgehbar

Jedes davon ist ein Finding über die Konfiguration und das Empfängerverhalten, nicht über die Chiffre. Dieser Unterschied zählt im Bericht: der Fix ist meist eine Änderung an der Message- oder Empfängerkonfiguration, kein neuer Algorithmus.

Wo der Bus-Tester aufhört

Was ein Bus-seitiger Test nicht sagen kann, ist, ob Key-Management, Freshness-Master und die HSM-gestützte Schlüsselhaltung in Ordnung sind. Ob der MAC-Algorithmus und seine Kürzungslänge für die Bedrohung stark genug sind, ob Keys pro Fahrzeug eindeutig sind und wie sie eingebracht werden, sind Fragen für ein kryptografisches Review und den Penetrationstest, nicht für die Verkehrsbeobachtung. Ein sauberes Bus-seitiges Ergebnis heißt, der Schutz ist eingeschaltet und wird durchgesetzt; es bescheinigt die Kryptografie darunter nicht.

Wie AutoST SecOC testet

AutoST übt das bus-seitige Verhalten: es bestätigt, dass der Authenticator auf den gesicherten IDs vorhanden ist, spielt aufgezeichnete Frames erneut ein, um die Freshness-Durchsetzung zu testen, verfälscht MAC und Payload, um die Verifikation zu testen, und tastet das Freshness-Fenster ab, alles aus CAN- oder CAN-FD-Verkehr. Die Findings gehen in denselben Risiko-Score und Fix Plan wie die UDS- und DoIP-Ergebnisse. AutoST analysiert das Key-Management oder das HSM nicht und fälscht keine MACs; die kryptografische Seite bleibt beim Penetrationstester.