Glossar
Automotive-Security-Begriffe, erklärt von den Leuten, die Steuergeräte testen.
Jeder Eintrag sagt in wenigen Sätzen, was ein Begriff bedeutet, wo er definiert ist und wie er an einem echten Steuergerät auftaucht. Geschrieben vom AutoST-Team, geprüft gegen ISO 14229, ISO 13400 und ISO/SAE 21434.
Kurz gesagt
Das AutoST-Glossar definiert Begriffe aus Fahrzeugdiagnose und Automotive-Cybersecurity: UDS-Services und Negative Response Codes, Data und Routine Identifier, SecurityAccess, ISO-TP, CAN und CAN FD, DoIP, SOME/IP, ODX und CDD, TARA, CAL, CSMS, ISO/SAE 21434 und UN R155. Jeder Eintrag nennt seine Quelle.
Alle Begriffe
Von ADB bis UN R156
A
- ADB (Android Debug Bridge)ADB ist die Android-Debug-Schnittstelle über USB oder TCP-Port 5555. Warum du sie an einer Android-Head-Unit zuerst prüfst und was ein offenes ADB einem Angreifer gibt.
- Android Automotive OS (AAOS)Android Automotive OS läuft direkt auf der Head Unit und spricht über den Vehicle HAL mit dem Fahrzeug. Der Unterschied zu Android Auto und was wir am Prüfstand finden.
C
- CAL (Cybersecurity Assurance Level)Der Cybersecurity Assurance Level (CAL 1 bis 4) aus ISO/SAE 21434 Anhang E bestimmt, wie streng Verifikation und Validierung sein müssen. Ableitung und Folgen für Tests.
- CAN FD (CAN with Flexible Data Rate)CAN FD erweitert CAN auf 64 Datenbytes und eine schnellere Datenphase. Wie DLC, BRS-Bit und Bit-Timing funktionieren und was sich für Diagnose und Fuzzing ändert.
- CAN-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.
- CDD (CANdela Diagnostic Description)Eine CDD-Datei ist die Vector-CANdela-Beschreibung der Diagnoseschnittstelle eines Steuergeräts: Sessions, Services, DIDs, Routinen, Security Level. Inhalt und Nutzung.
- CommunicationControl (0x28)UDS CommunicationControl (0x28) schaltet normale und Netzwerknachrichten eines Steuergeräts ein oder aus. Sub-Funktionen, Bytes und was zu prüfen ist.
- ControlDTCSetting (0x85)UDS ControlDTCSetting (0x85) schaltet das Speichern von Fehlercodes eines Steuergeräts während eines Tests ein oder aus. Die Sub-Funktionen, Bytes und was zu prüfen ist.
- CSMS (Cybersecurity Management System)Ein CSMS ist das Prozesssystem, das UN R155 vom Fahrzeughersteller verlangt: Risikomanagement, Tests, Monitoring und Reaktion über den Lebenszyklus. Was es umfasst.
D
- Diagnose-Session (DiagnosticSessionControl 0x10)UDS DiagnosticSessionControl (0x10) wechselt ein Steuergerät zwischen Default, Extended und Programming Session. Bytes, Timing-Parameter und was zu prüfen ist.
- DID (Data Identifier)Eine DID ist der 16-Bit-Identifier, mit dem UDS Datensätze adressiert, gelesen mit 0x22, geschrieben mit 0x2E. Bereiche nach ISO 14229-1 Anhang C und schreibbare DIDs.
- DoIP (Diagnostics over Internet Protocol)DoIP (ISO 13400) trägt UDS über Ethernet: Vehicle Discovery, Routing Activation und Diagnosenachrichten auf Port 13400. Wie es funktioniert und wo Gateways Fehler machen.
- DTC (Diagnostic Trouble Code, Fehlercode)Ein DTC ist ein Fehlercode, den ein Steuergerät bei einem erkannten Problem speichert. Das 3-Byte-Format in UDS, das Status-Byte, 0x19, 0x14 und die Rolle beim Fuzzing.
E
F
- Funktionale vs. physische AdressierungPhysische Adressierung schickt einen UDS-Request an ein Steuergerät, funktionale an alle. CAN-IDs 0x7E0 und 0x7DF, die Single-Frame-Regel und die Antwortregeln.
- Fuzzing (Fuzz-Testing)Fuzzing schickt fehlerhafte und unerwartete Eingaben an ein Steuergerät und achtet auf Abstürze, Resets und Hänger. Wie UDS- und CAN-Fuzzing funktionieren.
G
H
I
- ISO-TP (ISO 15765-2)ISO-TP (ISO 15765-2) zerlegt UDS-Nachrichten in CAN-Frames mit Flow Control. Wie es funktioniert und warum fehlerhafte Frames Steuergeräte abstürzen lassen.
- ISO/SAE 21434ISO/SAE 21434:2021 ist der Standard für Cybersecurity Engineering von Straßenfahrzeugen: Prozesse, TARA, Konzept, Entwicklung, Validierung. Aufbau und Testkapitel.
- IVI (In-Vehicle Infotainment)IVI ist die Head Unit, die Apps, Medien und Konnektivität fährt, oft auf Android oder Linux. Warum sie eine große Angriffsfläche ist und was Härtungschecks suchen.
N
O
- ODX (Open Diagnostic Data Exchange)ODX (ISO 22901-1, ASAM MCD-2 D) ist das XML-Format, das beschreibt, wie ein Steuergerät UDS spricht: Services, DIDs, Routinen und Daten. Aufbau und Nutzen für Tester.
- OTA-Update (Over-the-Air-Software-Update)Ein OTA-Update bringt neue Software per Funk ins Fahrzeug statt über einen Werkstatttester. Wie die Kette funktioniert, was UN R156 verlangt, wo Steuergeräte mitspielen.
P
- PDX (Packaged ODX)Eine PDX-Datei ist ein ZIP-Container, der ODX-Diagnosedaten (ODX-D, ODX-C, ODX-F und mehr) mit einem Katalog bündelt, nach ISO 22901-1. Inhalt und Nutzung im Test.
- Programming Session (0x10 0x02)Die UDS Programming Session (10 02) ist der Diagnosemodus zum Flashen eines Steuergeräts. Wie man hineinkommt, welche Services sie freischaltet, warum sie heikel ist.
R
- ReadDataByIdentifier (0x22)UDS ReadDataByIdentifier (0x22) liest einen Data Identifier (DID) aus einem Steuergerät. Die Request- und Response-Bytes, welche Session nötig ist und was zu prüfen ist.
- ReadDTCInformation (0x19)UDS ReadDTCInformation (0x19) liest Diagnose-Fehlercodes und ihren Status aus einem Steuergerät. Die Sub-Funktionen, Request- und Response-Bytes und was zu prüfen ist.
- RequestDownload (0x34)UDS RequestDownload (0x34) öffnet einen Download in den ECU-Speicher. Request-Bytes, maxNumberOfBlockLength, NRCs und warum 0x34 ohne Sperre ein Top-Finding ist.
- RID (Routine Identifier)Eine RID ist der Zwei-Byte-Identifier, mit dem RoutineControl (0x31) eine Routine im Steuergerät startet, stoppt und abfragt, von Erase Memory (FF00) bis Herstellertests.
- RoutineControl (0x31)UDS RoutineControl (0x31) startet, stoppt und liest Routinen eines Steuergeräts über den Routine Identifier (RID). Die Request- und Response-Bytes und was zu prüfen ist.
S
- SARIF (Static Analysis Results Interchange Format)SARIF ist der OASIS-JSON-Standard für den Austausch von Tool-Findings. Was eine SARIF-Datei enthält, warum sie auch für Steuergeräte-Tests passt und worauf du achtest.
- 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.
- Secure 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.
- SID (Service Identifier)Der SID ist das erste Byte jeder UDS-Nachricht und benennt den Service, von 0x10 DiagnosticSessionControl bis 0x3E TesterPresent. Bereiche, Antwortregel, SID-Sweep.
- SOME/IP (Scalable service-Oriented MiddlewarE over IP)SOME/IP ist die AUTOSAR-Middleware für Services auf Automotive-Ethernet: Header, Methoden, Events und Service Discovery. Warum offene Services ein Finding sind.
- Steuergerät (ECU, Electronic Control Unit)Ein Steuergerät ist ein eingebetteter Rechner, der eine Funktion im Fahrzeug steuert. Was darin steckt, welche Schnittstellen es hat und warum jedes ein Testobjekt ist.
T
- TARA (Threat Analysis and Risk Assessment)TARA ist die Bedrohungs- und Risikoanalyse aus ISO/SAE 21434 Kapitel 15: Assets, Bedrohungsszenarien, Impact, Angriffspfade, Machbarkeit, Risikowert, Behandlung.
- TesterPresent (0x3E)UDS TesterPresent (0x3E) hält eine Non-Default Session am Leben. Request- und Response-Bytes, das Suppress-Bit, der S3-Server-Timer und die Session-Bugs am Prüfstand.
U
- UDS (Unified Diagnostic Services)UDS (ISO 14229) ist das Diagnoseprotokoll der meisten Steuergeräte: Sessions, Services, DIDs, SecurityAccess. Was es definiert und warum es die erste Angriffsfläche ist.
- UN R155 (UN-Regelung Nr. 155, Cyber Security)UN R155 ist die UNECE-Regelung, die ein zertifiziertes CSMS und Cyber-Security-Maßnahmen zur Bedingung der Typgenehmigung macht. Was sie fordert und was Tester liefern.
- UN R156 (UN-Regelung Nr. 156, Software-Update)UN R156 ist die UNECE-Regelung zu Software-Updates und zum SUMS. Was sie von OTA-Updates fordert und wie sie mit Steuergerätetests zusammenhängt.
V
W
So nutzt du es
Definitionen aus der Norm, plus das, was der Prüfstand zeigt
Das Diagnose-Vokabular ist in den Normen präzise und im Alltag unscharf. Wir definieren jeden Begriff so, wie ISO 14229, ISO 13400 oder ISO/SAE 21434 es tun, nennen die Klausel und ergänzen, was wir an echten Steuergeräten sehen: wie der Begriff im Trace auftaucht, was typischerweise schiefgeht und wie AutoST ihn testet.
Die Einträge verlinken auf passende Ratgeber, Vergleiche und Tools. Fehlt ein Begriff, sag uns Bescheid, dann ergänzen wir ihn.
FAQ
Zum Glossar
Wer schreibt die Einträge?
Das AutoST-Team bei Zyberum, dieselben Ingenieure, die Steuergeräte- und Fahrzeug-Penetrationstests machen. Jeder Eintrag wird gegen die Norm geprüft, die er nennt, und trägt das Datum der letzten Aktualisierung.
Darf ich einen Eintrag verlinken oder zitieren?
Ja. Jeder Eintrag hat eine stabile URL und eine Markdown-Kopie. Zitiere mit Link auf die Seite. Für eine Nutzung über ein Zitat hinaus frag uns.
Warum stehen Diagnose-Begriffe neben Regulierung?
Weil ECU-Security-Arbeit so abläuft: Eine SecurityAccess-Schwäche vom Prüfstand wird zum Bedrohungsszenario in der TARA und zum Nachweis im UN-R155-Audit. Die Einträge verbinden beide Seiten.
Sieh es auf deinem ECU
Ein Begriff, der für dein Steuergerät zählt?
In 15 Minuten sagen wir dir, wie AutoST ihn testet, wie ein Finding aussieht und was er für deinen ISO/SAE-21434-Nachweis bedeutet.
- Direkte Antwort von einem ECU-Security-Engineer
- Welcher Test den Begriff abdeckt
- Kostenlos und unverbindlich
Deine Demo ist mitTom ZaubermannGründer von Zyberum, früher Leiter des VW InCar Security Testing Lab
Bereits im Einsatz bei Tier-1-, Tier-2-Zulieferern und OEMs. Referenzen auf Anfrage.
Oder schreib uns eine Nachricht
Wir antworten innerhalb eines Werktags.