Automotive Security — Referenz.

In-Cabin-Netze

• CAN (classical). Multi-Master-Broadcast, 1 Mbit/s, keine Auth, keine Verschlüsselung. Jeder Node sieht jede Message. Spoofen = beliebige CAN-ID mit höherer Priorität senden und Arbitration gewinnen. candump can0, cansend can0 123#DEADBEEF aus can-utils.
• CAN FD. Gleiches Protokoll, höhere Bitrate (5 Mbit/s typisch), größerer Payload (64 Bytes). Gleiche fehlende Auth.
• Automotive Ethernet. 100/1000BASE-T1 Single-Pair. Einige Deployments fügen MACsec für L2-Authentifizierung hinzu; viele nicht.
• LIN, FlexRay, MOST. Niedrigratige Busse für Body-Elektronik, X-by-Wire, Infotainment. Eigener Bus + eigene Quirks pro Bus.
• Domain-Bridges. Die Steuerunits, die zwischen Bussen gatewayen, sind der Engpass. Gateway kompromittieren = Cross-Domain-Kontrolle.

Telematik-Gateway / TCU

• Externe Oberflächen. Cellular-Modem (LTE/5G), Bluetooth (BLE-Pairing-Flow), Wi-Fi-Hotspot, manchmal V2X.
• Backend-API. Fahrzeug authentifiziert sich zur OEM-Cloud mit per-Fahrzeug-Cert + Token. App-seitige API für mobile Companion-App. Beide sind HTTP-Services — gleicher Web-App-Review gilt.
• Berühmte Fehler-Muster. Cellular-Telematik mit öffentlich auflösbaren internen Hostnames; fahrzeug-seitiger Token über die ganze Flotte wiederverwendet; flache Backend-API wo Fahrzeug-ID einzige AuthZ ist.
• Partitionierung. Modernes Gateway trennt Infotainment-Domäne von Powertrain-Domäne via Hypervisor oder dediziertem MCU. Bypass = Hypervisor-Escape exploiten oder unbeabsichtigte Bridge finden (USB, BT-zu-CAN-Debug, Supplier-Diagnostic-Port).

Diagnostik — UDS / OBD-II

• OBD-II-Port. Physischer Zugriff, weltweit vorgeschrieben. Direkter CAN-Zugriff. Aftermarket-Dongles lassen oft permanent zu Bluetooth/Wi-Fi gebrückt.
• UDS (ISO 14229). Diagnose-Protokoll geschichtet auf CAN. Service-IDs: 0x10 DiagnosticSessionControl, 0x27 SecurityAccess (Seed/Key-Challenge), 0x34/0x36/0x37 RequestDownload/TransferData/RequestTransferExit für Firmware-Flashing.
• SecurityAccess-Schwäche. Seed→Key-Algorithmus historisch aus einer Tool-DLL oder einem gecapturten Paar reverse-engineerbar. Modernes AUTOSAR nutzt Crypto + per-ECU-Keys; Legacy nicht.
• Engineering-Services aktiv gelassen. ECUs in Produktion mit freigeschalteten Engineering-Mode-UDS-Services. Diagnose-Protokoll wird zur RCE-Kette.

OTA-Update-Kanal

• Uptane-Referenz-Framework. Zwei Metadata-Roles (Director + Image-Repo), per-Fahrzeug-Targeting, Rollback-Protection. Adoption uneinheitlich.
• Häufige Fehler. Update-Paket signiert, aber Rollback-Protection fehlt (Downgrade-Attack); per-Fahrzeug-Targeting fehlt (Angreifer-Payload an ein Fahrzeug durch VIN-Spoofing pushen); Supplier-signierte ECU-Images vom Gateway ohne Cross-OEM-Check akzeptiert.
• Test. Update-Flow mit Man-in-the-Middle auf der HTTPS der TCU capturen. Ohne sauberes Cert-Pinning kannst du das Image substituieren.

Supplier-Dependency-Graph

• Ein modernes Fahrzeug hat 50–150 ECUs von Dutzenden Tier-1-Suppliern. Jeder Supplier hat eigenes Codebase, Debug-Interfaces, Key-Management.
• OEM-Sicherheits-Posture wird durch den schwächsten Tier-1 begrenzt. UNECE R155 (Cybersecurity) und R156 (Software-Update) pushen OEMs, Supplier-Posture zu tracken; Abdeckung in der Praxis schwankt.
• Wiederkehrender Befund: Tier-1-ECU shippt mit Debug-Shell, OEM-Integration deaktiviert sie nicht.