GlossarAutomotive

UDS (Unified Diagnostic Services)

UDS (ISO 14229) ist das Diagnoseprotokoll fast jedes Steuergeräts. Welche Dienste es gibt, wie der Zugriffsschutz funktioniert und was im Test zählt.

Aktualisiert 7. Oktober 2026Diese Seite als Markdown

Kurz gesagt

UDS (Unified Diagnostic Services) ist das in ISO 14229 definierte Diagnoseprotokoll, mit dem ein Tester Daten aus einem Steuergerät liest, Fehlerspeicher löscht, Routinen startet und Software flasht. Es läuft über CAN (mit ISO-TP) und Ethernet (mit DoIP). Weil UDS Speicher schreiben und das Steuergerät neu programmieren kann, ist sein Zugriffsschutz, SecurityAccess (0x27) und Authentication (0x29), eine der wichtigsten Sicherheitsgrenzen im Fahrzeug.

Was ist UDS?

UDS ist das Diagnoseprotokoll, mit dem ein Diagnosetester (Client) Funktionen in einem Steuergerät (Server) steuert. ISO 14229-1 definiert die Dienste unabhängig vom Bus: Jeder Dienst hat eine Service-ID, einen Request mit optionalen Sub-Functions und Parametern, eine positive Antwort (Service-ID plus 0x40) und eine negative Antwort (0x7F, Service-ID, Negative Response Code).

Die wichtigsten Dienste: DiagnosticSessionControl (0x10) wechselt zwischen Default, Extended und Programming Session; ECUReset (0x11); ReadDataByIdentifier (0x22) und WriteDataByIdentifier (0x2E) lesen und schreiben Daten über 16-Bit-Data-Identifier (DIDs); ReadDTCInformation (0x19) liest den Fehlerspeicher; RoutineControl (0x31) startet herstellerspezifische Routinen; RequestDownload (0x34), TransferData (0x36) und RequestTransferExit (0x37) flashen Software; TesterPresent (0x3E) hält eine Session offen. SecurityAccess (0x27) und Authentication (0x29) schützen die sensiblen Dienste.

Wo ist es definiert?

Die Normenreihe ISO 14229 besteht aus mehreren Teilen: Teil 1 definiert die Anwendungsschicht, Teil 2 die Session-Layer-Dienste, Teil 3 UDS auf CAN (UDSonCAN), Teil 5 UDS auf IP (UDSonIP) sowie weitere Teile für FlexRay, K-Line und LIN. Auf CAN übernimmt ISO 15765-2 (ISO-TP) die Segmentierung in Botschaften mit bis zu 4095 Bytes, auf Ethernet transportiert ISO 13400 (DoIP) die Diagnosenachrichten über TCP/IP. Die konkrete Belegung der DIDs und Routinen steht nicht in der Norm, sondern in der Diagnosespezifikation des Herstellers, oft als ODX- oder CDD-Datei.

ISO/SAE 21434 nennt in Klausel 10 Fuzz-Tests und Penetrationstests als Verifikationsmethoden, und UN R155 verlangt in Anhang 5 Maßnahmen gegen den Missbrauch von Diagnosefunktionen. Beides trifft in der Praxis die UDS-Schnittstelle.

Was es in der Praxis bedeutet

UDS ist in jedem Steuergerät vorhanden, erreichbar über den OBD-Anschluss, über Telematikeinheiten mit Ferndiagnose und über DoIP im Fahrzeugnetz. Deshalb ist die Diagnoseschnittstelle in fast jedem unserer Steuergeräte-Penetrationstests im Fokus, von Leistungselektronik-Steuergeräten wie DC/DC-Wandlern und Onboard-Ladegeräten bis zu Infotainment-Systemen. Die Beurteilung folgt drei Fragen:

Was ist erreichbar, und in welcher Session? Wir erfassen alle angebotenen Dienste, DIDs und Routinen und vergleichen mit der Spezifikation. Abweichungen sind häufig: vergessene Fertigungsroutinen, DIDs mit Kalibrierdaten oder Schlüsselmaterial, Schreibdienste ohne Session-Wechsel.
Wie gut ist der Zugriffsschutz? Eine solide SecurityAccess-Implementierung nutzt zufällige Seeds mit ausreichender Länge, einen kryptografisch starken Schlüsselalgorithmus mit steuergerätespezifischem Schlüssel, Fehlversuchszähler und Verzögerungen. Fehlt einer dieser Punkte, bewerten wir das als Finding und zeigen den Nachweis am Gerät.
Hält die Implementierung ungültigen Eingaben stand? Falsche Längen, unbekannte Sub-Functions, abgebrochene Transfers und manipulierte ISO-TP-Segmentierung dürfen das Steuergerät nicht zum Absturz oder Reset bringen. Fuzzing beantwortet das; die Erkennung läuft über TesterPresent-Heartbeats, Reset-Beobachtung und die Fehlerantworten des Steuergeräts.

Unser Produkt AutoST automatisiert genau diese Schritte: Erfassung von Sessions, Diensten, DIDs und Routinen, Vergleich mit ODX- oder CDD-Datenbanken, Bewertung des Zugriffsschutzes und protokollbewusstes Fuzzing mit Reset-Erkennung.

Häufige Missverständnisse

“UDS ist nur für die Werkstatt” unterschätzt, dass die Schnittstelle über Telematik und DoIP auch aus der Ferne erreichbar sein kann und dass Diagnosetester für wenig Geld zu kaufen sind. “SecurityAccess ist aktiv, also ist der Flash geschützt” sagt nichts über die Qualität des Algorithmus und des Schlüsselmanagements. Und eine fehlerfreie Diagnosespezifikation garantiert nicht, dass die Firmware sie fehlerfrei umsetzt; das zeigt erst der Test am Gerät.

FAQ

Häufig gestellte Fragen

Ist UDS ein Sicherheitsprotokoll?

Nein. UDS ist ein Diagnoseprotokoll mit zwei angebauten Zugriffsschutzdiensten. SecurityAccess (0x27) ist ein Seed-and-Key-Verfahren, dessen Algorithmus der Hersteller wählt; die Norm sagt nichts über dessen Stärke. Authentication (0x29), neu in ISO 14229-1:2020, bringt zertifikatsbasierte Authentifizierung, aber die meisten Steuergeräte in Serie verlassen sich weiterhin auf 0x27.

Wie prüft ihr UDS im Steuergeräte-Penetrationstest?

Wir erfassen, welche Sessions, Dienste, Data Identifier und Routinen das Steuergerät anbietet, vergleichen das mit der Diagnosespezifikation und prüfen, ob der Zugriffsschutz überall dort greift, wo er laut Spezifikation greifen soll. Danach bewerten wir die Implementierung von SecurityAccess und fuzzen die Parser hinter den Diensten. AutoST automatisiert die Erfassung und das Fuzzing.

Verlangt UN R155 etwas zu UDS?

Nicht namentlich. Anhang 5 der UN R155 listet Bedrohungen, die den Missbrauch von Diagnosefunktionen und unbefugten Zugriff auf Fahrzeugdaten und Software umfassen, und verlangt vom Hersteller Maßnahmen dagegen. UDS ist in der Praxis der Weg, über den diese Bedrohungen eintreten, und der Nachweis läuft über Tests der Diagnoseschnittstelle.

Quellen

Passende Seiten

← Glossar