SecurityAccess Seed/Key-Schwächen und wie du sie testest

SecurityAccess (UDS-Service 0x27, ISO 14229-1) ist das Tor, das zwischen einem Tester und den gefährlichen Services stehen soll: Flashen, Memory Access, Routinen, die Aktoren bewegen. Es arbeitet als Challenge und Response. Der Tester fragt einen Seed an, das ECU gibt einen Zufallswert zurück, der Tester berechnet daraus einen Key und sendet ihn zurück. Das Tor ist nur so stark wie der schwächste Teil dieses Austauschs, und am Prüfstand sehen wir regelmäßig jeden Teil versagen. Dies ist eine Beschreibung der Testmethode, kein Angriffsrezept gegen ein einzelnes Produkt.

Der Austausch, Byte für Byte

tx 27 01            requestSeed, Level 1
rx 67 01 3F A2 9C   Seed = 3F A2 9C
tx 27 02 11 22 33   sendKey, Level 2 (ungerade = requestSeed, gerade = sendKey)
rx 67 02            Key akzeptiert, Level entsperrt

Ein falscher Key wird mit 7F 27 35 (invalidKey) abgelehnt. Nach einem bereits gewährten Level gibt ein Seed-Request 00 00 00 zurück, was korrektes Verhalten ist und keine Schwäche.

Die Schwächen, und wie man jede testet

Konstanter oder niedrig-entropischer Seed

Frage mehrmals hintereinander einen Seed an und vergleiche. Gibt das ECU jedes Mal denselben Wert zurück oder einen, der nur hochzählt, gibt es nichts zu raten: ein Angreifer zeichnet einmal einen Seed und den passenden Key auf und spielt sie für immer wieder ab.

27 01 -> 67 01 3F A2 9C
27 01 -> 67 01 3F A2 9C    identisch, konstanter Seed

Test: den Seed vielfach über frische Sessions anfragen und die Verteilung messen. Konstante, Null-, niedrig-entropische oder hochzählende Seeds markieren. Keine Key-Berechnung nötig.

Zeit- oder uptime-basierter Seed

Manche Seeds werden aus einer Uhr oder einem Uptime-Zähler abgeleitet. Solche Seeds wirken innerhalb einer Session zufällig, werden aber vorhersagbar, wenn du weißt, wann das ECU gebootet ist. Das Merkmal ist ein Seed, der sich langsam und monoton ändert oder nach einem Power-Cycle zurückspringt.

Test: Seeds über die Zeit und nach einem Reset abtasten. Ein Seed, der sich wiederholt oder mit dem ECU zurückspringt, deutet auf eine vorhersagbare Quelle. Weil dies einen Reset erfordert, ist es die eine Prüfung, die vor dem Ausführen bestätigt werden muss.

Kein Attempt-Counter

Ein echtes Tor zählt falsche Keys und sperrt. Sende eine Reihe falscher Keys und beobachte den NRC:

27 02 00 00 -> 7F 27 35   invalidKey
27 02 00 00 -> 7F 27 35
27 02 00 00 -> 7F 27 35   ...weiter 0x35, kein Lockout

Ein gesundes ECU eskaliert nach der konfigurierten Anzahl Versuche zu 7F 27 36 (exceedNumberOfAttempts). Ein ECU, das endlos 0x35 antwortet, hat keinen Zähler, was heißt, dass ein Angreifer den Key-Raum mit voller Geschwindigkeit durchprobieren kann.

Keine Verzögerung

Selbst mit einem Zähler muss das ECU vor dem nächsten Versuch eine Verzögerung durchsetzen, beantwortet mit 7F 27 37 (requiredTimeDelayNotExpired). Miss die Zeit zwischen einem abgelehnten Key und der nächsten akzeptierten Seed-Anfrage. Eine Verzögerung von null, oder eine, die nach einem Reset zurückspringt, nimmt die Hauptverteidigung gegen Brute Force.

Kurze Konstante oder aus dem Seed ableitbarer Key

Viele schwache Algorithmen sind eine dünne Transformation: key = seed XOR Konstante, key = seed + Konstante oder eine Byte-Rotation. Sammle einen Satz Seed/Key-Paare (aus einem Tool, das du nutzen darfst, oder durch Beobachten eines legitimen Testers) und suche nach einer festen Beziehung. Erklärt dieselbe Konstante jedes Paar, ist der Algorithmus rekonstruierbar, und die Konstante umfasst oft nur wenige Bytes.

Test: Seed/Key-Paare sammeln und auf einfaches XOR, Addition, Rotation und kleine Lookup-Beziehungen prüfen. Ein Treffer heißt, der Key lässt sich berechnen, nicht raten.

Default-Keys und wiederverwendete Keys

Manche ECUs kommen mit einem dokumentierten oder erratbaren Key oder nutzen denselben Key über jede Variante einer Familie. Ein kleiner Katalog bekannter Default-Keys entsperrt mehr ECUs, als er sollte.

Test: einen Katalog von Default-Keys probieren und das Schema über Varianten vergleichen. Derselbe Key, der auf mehr als einem ECU funktioniert, ist eine Lieferketten-Schwäche, kein Einzelstück-Bug.

Eine sinnvolle Reihenfolge

1. Seed-Zufälligkeit. Billig, nicht-destruktiv, fängt die schlimmsten Fälle zuerst.
2. Attempt-Counter und Verzögerung. Falsche Keys senden, auf 0x36 dann 0x37 achten.
3. Sequenz-Durchsetzung. Einen Key ohne vorherigen Seed-Request senden; das ECU muss ihn ablehnen.
4. Algorithmus-Analyse. Paare sammeln, nach einfacher Beziehung suchen, Default-Keys probieren.
5. Reset-Vorhersagbarkeit. Zuletzt, und nur mit Bestätigung, weil es das ECU zurücksetzt.

Schritt eins bis drei brauchen überhaupt keinen gültigen Key und finden die meisten Probleme. Auf einem getesteten Leistungselektronik-ECU war der Seed über Sessions konstant und der Lockout löste nie aus, sodass das Tor keinen echten Schutz bot, obwohl ein Key-Algorithmus vorhanden war.

Wie ein starkes Tor aussieht

Ein zufälliger Seed mit voller Entropie, ein Key, der sich ohne das Geheimnis nicht aus dem Seed ableiten lässt, ein Attempt-Counter, der nach wenigen falschen Keys auslöst, eine durchgesetzte Verzögerung, die einen Reset übersteht, und keine Default- oder geteilten Keys. Die SecurityAccess-Engine von AutoST läuft diese Prüfungen der Reihe nach ab, standardmäßig begrenzt und nicht-destruktiv, und meldet, welcher Teil des Tors versagt hat, statt nur “gesperrt” oder “entsperrt”. Es geht nie darum, in ein bestimmtes ECU einzudringen, sondern zu zeigen, ob das Tor jemanden aufhalten würde, der es versucht.