Automotive Cybersecurity: UN-ECE WP.29, ISO 21434 und Fahrzeug-Hacking

Seit Juli 2022 gilt: alle neuen Fahrzeugtypen die in der EU zugelassen werden, müssen UN-ECE WP.29 R155 und R156 erfüllen. Kein Cybersecurity-Management-System (CSMS) = keine Typgenehmigung. Automotive Cybersecurity ist von einer Engineering-Disziplin zur Voraussetzung für Marktzugang geworden. Und das ist keine Überraschung: Moderne Fahrzeuge haben über 100 ECUs, 100+ Millionen Codezeilen, CAN-Bus, LTE-Verbindungen, V2X-Kommunikation und OTA-Update-Systeme - jede dieser Schnittstellen ist ein potenzieller Angriffsvektor.

Regulatorischer Rahmen

R155 - Cybersecurity und CSMS

Geltungsbereich: Alle neuen M/N/O/L-Fahrzeugtypen in UN-ECE-Ländern (in Kraft seit Juli 2022)

Kernpflichten für OEMs:

• CSMS (Cybersecurity Management System) nachweisen
• TARA für jedes Fahrzeugmodell durchführen
• Cybersecurity-Maßnahmen implementieren + testen
• Cybersecurity-Monitoring über gesamten Lebenszyklus
• Security-Updates bereitstellen können
• Zulieferer-Chain-Management (Tier 1/2 einbinden!)

Zertifizierung:

• Nationale Typgenehmigungsbehörde prüft CSMS-Nachweis
• Deutschland: KBA (Kraftfahrt-Bundesamt)
• Nachweis: unabhängige CSMS-Zertifizierung (TÜV, DEKRA, etc.)

R156 - Software Update Management System (SUMS)

Anforderungen für OTA-Update-Sicherheit:

• Secure Boot: nur signierte Software wird geladen
• Update-Authentizität: kryptografische Signatur
• Rollback-Schutz: keine Downgrade-Angriffe möglich
• Update-Integrität: Manipulation erkennbar

ISO 21434 - Road Vehicles Cybersecurity Engineering

Was: Prozessstandard für Cybersecurity-Engineering | Status: ISO-Standard 2021, Referenz für R155-Compliance | Scope: Gesamter Product-Lifecycle (Konzept → End-of-Life)

Kapitel	Inhalt
Kap. 8	Kontinuierliche Cybersecurity-Aktivitäten
Kap. 9	Konzeptphase (Item Definition, TARA)
Kap. 10	Produktentwicklung (Spezifikation, Design, Test)
Kap. 11	Post-Development (Produktion, Betrieb, Abkündigung)
Kap. 12	Zulieferer-Management (Cybersecurity Interface Agreement!)
Kap. 15	TARA-Methodik

TARA - Threat Analysis and Risk Assessment

Schritt 1 - Asset-Identifikation

Damage Scenarios definieren: Was kann durch einen Angriff geschädigt werden? Welche Sicherheitsziele sind betroffen?

Beispiel-Assets für Fahrzeuge:

• Fahrzeugsteuerung (Lenkung, Bremsen, Antrieb)
• Fahrer- und Insassendaten (persönliche Daten, Fahrstil)
• Fahrzeugidentität (VIN, Zertifikate)
• OTA-Update-Mechanismus

Schritt 2 - Threat Scenarios

Angreifer-Profil: Motivation, Fähigkeiten, Ressourcen, Angriffsvektoren (direkt/drahtlos/remote)

Beispiel Threat Scenarios:

• T1: OBD-II-Port Zugang → Injection in CAN-Bus → Brems-ECU manipulieren
• T2: Remote-Angriff über Telematik-Modem → Fahrzeugsteuerung
• T3: OTA-Update-Manipulation → Schadhafter Code in ECU
• T4: Key-Fob-Relay-Attack → Fahrzeugdiebstahl ohne Original-Schlüssel
• T5: V2X-Spoofing → Phantom-Fahrzeuge als Kollisionsgefahr

Schritt 3 - Wirkungsanalyse (Impact)

Kategorien nach ISO 21434:

Kategorie	Beschreibung
Safety	Verletzung oder Tod von Personen
Financial	Wirtschaftlicher Schaden (Hersteller/Nutzer)
Operational	Funktionsverlust des Fahrzeugs
Privacy	Datenschutzverletzung

Schaden-Schwere (Severity):

• S0: Kein Schaden
• S1: Leichte Verletzung
• S2: Schwere, nicht lebensbedrohliche Verletzung
• S3: Lebensbedrohliche / tödliche Verletzung

Schritt 4 - Attack Feasibility

Faktor	Beschreibung
Elapsed Time	Wie lange braucht der Angreifer?
Specialist Expertise	Welche Expertise ist nötig?
Knowledge of Item	Wie viel Wissen über Fahrzeug-Interna?
Window of Opportunity	Zugang physisch oder remote?
Equipment	Welche Ausrüstung wird benötigt?

Feasibility Rating:

• High (1-3): Angriff sehr realistisch
• Medium (4-6): Mittlerer Aufwand
• Low (7-10): Sehr hoher Aufwand
• Very Low (11-14): Nur staatliche Akteure

Schritt 5 - Risikobewertung + Behandlung

Risiko = Severity × Attack Feasibility

Behandlungsentscheidung	Beschreibung
Vermeiden	Feature entfernen (z.B. OBD-Remotezugang)
Reduzieren	Maßnahmen implementieren (z.B. CAN-Message-Authentifikation)
Akzeptieren	Dokumentiertes Restrisiko (bei sehr geringer Feasibility)
Transfer	Versicherung (selten in Automotive sinnvoll)

Fahrzeug-Angriffsvektoren

1. CAN-Bus (Controller Area Network)

Problem: CAN ist unsicher by Design

• Kein Authentifizierungsmechanismus
• Jeder Teilnehmer kann jede Message senden!
• Keine Verschlüsselung

Angriffe:

• Message Injection: eigene CAN-Messages senden
• Bus-Off Attack: ECU durch Fehler-Frames vom Bus trennen!
• Fuzzing: Random Messages → unerwartetes Verhalten

Demo-Angriff (nicht für echte Fahrzeuge!):

# python-can Library:
import can
bus = can.interface.Bus(channel='can0', interface='socketcan')
# Brems-ECU: Message mit ID 0x152 injizieren
msg = can.Message(arbitration_id=0x152, data=[0xFF, 0x00, 0x00, 0x00])
bus.send(msg)

Schutz:

• CANsec (CAN-FD Security Extension): Authentifizierung + Verschlüsselung
• Automotive Intrusion Detection System (IDS): CAN-Traffic-Analyse
• Gateway-ECU: filtert und validiert Messages zwischen Subnetzen

2. OBD-II-Port

Risiko: Physischer Zugang → direkter CAN-Bus-Zugriff (Werkstätten, Tuner, Dongles, Versicherungs-Tracker!)

Bekannte Angriffe:

• Jeep Cherokee Hack (Miller & Valasek, 2015): remote via UConnect
• BMW Remote Access (2020): OTA-Schwachstelle
• Lockpicking Lawyers: Key-Fob-Relay-Attacks demonstriert

Schutz:

• OBD-Port-Zugangskontrolle (selten implementiert)
• Whitelisting für diagnostische Sessions
• Anomalie-Erkennung im Gateway

3. Drahtlose Schnittstellen

Bluetooth:

• Pairing-Angriffe, BIAS (Bluetooth Impersonation Attacks)
• Ältere Stacks: CVEs in BlueZ, Qualcomm

WLAN (Hotspot-Funktion):

• Schwaches Passwort, WPA2-Schwachstellen
• Infotainment-zu-CAN-Bridge: Lateral Movement!

Schlüssellos-Systeme (PKES):

• Relay-Angriff: Schlüssel-Signal verlängern (Relay-Box)
• Signal von Schlüssel im Haus → Auto öffnet, startet!
• Schutz: UWB-Technologie (präzise Distanzmessung), Ultrabreitband

4. Telematik-Einheit (TCU)

• LTE/5G-Verbindung zum Backend
• Remote-Angriff über TLS-Schwachstellen
• Backend-Kompromittierung → Flotten-Fernzugriff!
• OTA-Updates: Signaturprüfung kritisch

5. V2X (Vehicle to Everything)

• V2I: Fahrzeug zu Infrastruktur (Ampeln, Schilder)
• V2V: Fahrzeug zu Fahrzeug (Notfallwarnung)
• Protokoll: ETSI ITS G5 / C-V2X (5G)
• Angriff: Phantom-Fahrzeuge einspeisen → Brems-Reaktion
• Schutz: PKI für V2X-Zertifikate (Certificate Revocation!)

6. Ladekommunikation (EV)

• ISO 15118: Bidirektionale Kommunikation Fahrzeug ↔ Ladesäule
• Powerline Communication (PLC) über Ladekabel
• Angriffe auf Ladesäulen-Backend → Fahrzeugdaten
• OCPP (Open Charge Point Protocol): Schwachstellen in Implementierungen

Security-by-Design in der Entwicklung

Secure Boot und HSM

Secure Boot:

• Hardware Security Module (HSM) in jeder ECU
• Boot-Prozess: Firmware-Signatur vor Ausführung prüfen
• Infineon/NXP: SHE+ (Secure Hardware Extension)

Hardware Security Module (HSM):

• Kryptografische Operationen in gesichertem Chip
• Schlüssel verlassen das HSM nie im Klartext!
• Funktionen: Secure Boot, Key Storage, CMAC für CAN

AUTOSAR SecOC

AUTOSAR (AUTomotive Open System ARchitecture) implementiert SecOC (Secure On-Board Communication): CAN-Message-Authentifizierung mit kryptografischem MAC auf jeder sicherheitskritischen Message. Key-Management erfolgt mit symmetrischen Keys im HSM.

# SecOC in AUTOSAR (vereinfacht):
# Sender-ECU: MAC über Message generieren
MAC = CMAC(SessionKey, CAN-ID || Counter || Data)
CAN-Frame = Data + truncated_MAC (24 bit)

# Empfänger-ECU: MAC verifizieren
expected_MAC = CMAC(SessionKey, CAN-ID || Counter || Data)
if MAC != expected_MAC: REJECT!
# → Injizierte Messages werden erkannt!

Automotive Intrusion Detection System (IDS)

• Überwacht CAN-Bus-Traffic auf Anomalien
• Baseline: normale Message-Frequenzen pro ID
• Alert bei: unbekannter Message-ID, ungewöhnlicher Frequenz
• Lösungen: Argus Cyber Security, ESCRYPT, C2A Security

Security-Testing im Automotive

• TARA-basiertes Penetrationstest-Scope
• CAN-Bus-Fuzzing (CANalyzer, canoe, python-can)
• RF-Testing: Key-Fob-Relay, Bluetooth-Angriffe
• OTA-Update-Security: Signatur-Verification testen
• TCU-Pentest: Remote-Angriff auf Telematik
• Backend-API-Test: Fahrzeug-Backend-Schnittstellen
• CVSS-Bewertung mit Automotive-Extension (CVSS-AE)

Zulieferer-Management (ISO 21434 Kap. 12)

• Cybersecurity Interface Agreement (CIA) mit jedem Tier-1
• Security Requirements im Design-Vertrag
• SBOM (Software Bill of Materials) für jede ECU
• TARA-Austausch zwischen OEM und Zulieferer
• Vulnerability-Handling-Prozess definiert
• Security-Testing-Nachweise einfordern

Incident Response im Automotive-Kontext

Kontinuierliches Monitoring (R155 Anforderung)

• Threat Intelligence für Automotive (ENISA, AutoISAC)
• PSIRT (Product Security Incident Response Team) aufbauen
• CVE-Monitoring für verwendete Softwarekomponenten
• Bug-Bounty-Programm für Fahrzeugsysteme

Vulnerability Disclosure

• Coordinated Vulnerability Disclosure (CVD) Prozess
• Security.txt im Backend: security@oem.com
• Response-Zeit: < 24h Bestätigung, < 90 Tage Patch (Richtwert)

OTA-Update-Rollout

1. Schwachstelle identifiziert + bewertet (CVSS)
2. Patch entwickelt + getestet (Regressionstests!)
3. Signiertes Update-Paket erstellt (R156 konform!)
4. Staged Rollout: 1% → 10% → 100% der Fahrzeuge
5. Erfolgsrate monitoren: Update erfolgreich installiert?
6. Notfall-Rollback: wenn Probleme erkannt

Recall-Entscheidung

Bei physischer Sicherheitsrelevanz (S3 = Todesgefahr):

• Software-Recall via OTA wenn möglich
• Physischer Recall wenn OTA nicht ausreicht
• KBA (Deutschland) + NHTSA (USA) informieren

Bekannte CVEs im Automotive-Bereich

CVE	Beschreibung
CVE-2015-5611	BMW ConnectedDrive Remote Control
CVE-2020-14150	Renault/Mitsubishi TPMS Spoofing
CVE-2022-37459	Bosch Rexroth Hydraulics Remote Code Execution
CVE-2023-38544	Snapdragon Automotive BLE Stack Overflow

---

Automotive Cybersecurity ist komplexer als IT-Security - Sicherheit muss über 15+ Jahre Fahrzeuglebenszyklus gewährleistet sein. AWARE7 unterstützt Automobilzulieferer und OEMs bei ISO 21434-Implementierung, TARA-Durchführung und Fahrzeug-Penetrationstests.

Automotive Security Beratung anfragen | OT/ICS Penetrationstest