Automotive & Mobility
Ein Fahrzeug ist ein verteiltes System aus Steuergeräten, Bussen, Funkschnittstellen und Backend-Diensten. Die Angriffsfläche endet nicht am Fahrzeug: Sie umfasst Werkstattdiagnose, OTA-Kette und Zulieferkette.
Was an Fahrzeugen bereits demonstriert wurde
2015 übernahmen zwei Forscher aus der Ferne die Kontrolle über einen fahrenden SUV. Der Weg führte über die Mobilfunkanbindung des Infotainmentsystems, von dort auf den Fahrzeugbus und schließlich auf Bremse und Getriebe. Der Hersteller rief anschließend rund 1,4 Millionen Fahrzeuge zurück. Es war der Fall, der die Branche von Produktsicherheit auf Cybersicherheit umstellte.
Seither hat sich der Schwerpunkt verschoben, weg vom spektakulären Fernzugriff hin zum Alltagsdiebstahl. Bei der sogenannten CAN-Injection wird über ein zugängliches Kabel am Fahrzeugäußeren eine Botschaft auf den Bus gelegt, die dem Gateway eine gültige Entriegelung vortäuscht. Es genügt ein Bus, auf dem jeder senden darf, der physisch daran kommt.
Parallel bleiben die Funkschnittstellen ein Dauerthema: Relaisangriffe auf schlüssellose Systeme funktionieren seit Jahren und werden nicht durch Software behoben, sondern durch Laufzeitmessung im Protokoll.
Drei Ansatzpunkte, je nach Rolle
Ob Sie Fahrzeuge bauen, Komponenten liefern oder eine Flotte betreiben, entscheidet, welcher davon für Sie zuerst zählt.
Fahrzeug und Steuergerät prüfen
Bus-Kommunikation, Wirksamkeit der Gateway-Filter, Verhalten bei manipulierten Botschaften, Diagnosezugang über OBD und Werkstatt-Tooling, dazu die Firmware selbst mit Debug-Schnittstellen und hartcodierten Zugangsdaten.
Backend und Update-Kette prüfen
Die Verbindung zum Backend, Umgang mit Zertifikaten und Schlüsselmaterial und die Frage, ob ein Update signiert, rollback-fest und manipulationssicher ausgeliefert wird. Das ist klassischer Anwendungs- und Infrastrukturtest, nur mit Fahrzeugen am anderen Ende.
Erkennen, was im Feld passiert
Ein Security Operations Center für Fahrzeuge wertet aus, was Steuergeräte und Telematik melden. Wir haben ein solches Vehicle SOC in einem Forschungsprojekt entwickelt, samt Angriffserkennung für Fahrzeugbusse.
Wie ein Fahrzeug-Penetrationstest abläuft
Nicht zwingend am Fahrzeug. Vieles lässt sich an einzelnen Steuergeräten, an Prüfständen und im Labor abbilden. Für Angriffspfade, die mehrere Domänen verbinden, ist ein vollständiger Aufbau oder ein Fahrzeug allerdings aussagekräftiger.
Wir arbeiten uns von außen nach innen: zuerst die Schnittstellen, die ohne Demontage erreichbar sind, dann der Bus hinter dem Gateway, dann das Steuergerät selbst. Jeder Schritt beantwortet die Frage, ob eine Trennung, die im Architekturdokument steht, im Fahrzeug auch wirkt.
Was wir zur Fahrzeugdiagnose beigetragen haben
Der Diagnosezugang ist der Weg, den in der Praxis jede Werkstatt nutzt und jeder Angreifer als Erstes prüft. Wir haben dazu in einem geförderten Verbundvorhaben zwei Dinge erarbeitet, die begutachtet veröffentlicht sind.
Erstens eine systematische Ordnung der Angriffstechniken auf das Diagnoseprotokoll, vorgestellt auf einer IEEE-Konferenz zu Kommunikations- und Netzwerksicherheit. Zweitens Erkennungsstrategien vom Steuergerät bis in die flottenweite Auswertung, in drei Kategorien: Muster im Fahrzeugprotokoll, Bewertung im Kontext von Fahrzeugzustand und Wartungsvorgängen und Einbeziehung öffentlicher Schwachstelleninformationen. Gegen die Taxonomie geprüft decken diese Strategien nahezu alle darin erfassten Techniken ab.
Umgesetzt ist das in einer Erkennung, die das Protokoll tatsächlich interpretiert statt nur Rahmen zu zählen. In unserem tragbaren Demonstrator ist sie nachvollziehbar. Dazu kommt das Taktik- und Technikmodell für Fahrzeuge, das wir 2023 auf einem ACM-Symposium vorgestellt haben.
Training für Entwicklung und Security-Team
Entwicklerinnen und Entwickler lernen, wo Fahrzeugarchitektur und klassische Anwendungssicherheit auseinanderlaufen: Ein Bus kennt keine Benutzerrechte, Segmentierung entsteht über Domänenschnitt und Gateway-Filter und ein Steuergerät bleibt zehn Jahre und länger im Feld.
Security-Teams arbeiten an Protokollanalyse, Angriffserkennung und der Frage, welche Meldung aus einem Fahrzeug überhaupt auswertbar ist. Geübt wird am Demonstrator, nicht an Folien.
R155 und R156 adressieren nicht dieselbe Rolle
UN R155 verlangt vom Hersteller ein Managementsystem für Cybersicherheit und macht es zur Voraussetzung der Typgenehmigung. UN R156 regelt die Seite der Software-Updates: Prozesse, Nachvollziehbarkeit und Absicherung von Aktualisierungen über die Fahrzeuglebensdauer. ISO/SAE 21434 liefert das technische Vorgehen dazu.
Genehmigungsseite und Betreiberseite werden dabei häufig verwechselt. R155 adressiert den Hersteller und den Fahrzeugtyp. Ein Flottenbetreiber oder Mobilitätsanbieter erfüllt damit keine der Pflichten, die ihn aus seiner eigenen Rolle treffen, etwa wenn er Telematik- oder Sharing-Plattformen an die eigene IT anbindet.
Wir klären diese Rollenfrage zu Beginn, weil sie über Umfang und Nachweisform entscheidet.
Was Hersteller, Zulieferer und Flottenbetreiber fragen
Nicht zwingend. Steuergeräte, Prüfstände und Laboraufbauten decken den größten Teil ab. Ein Fahrzeug oder ein vollständiger Aufbau lohnt sich, sobald Angriffspfade mehrere Domänen verbinden.
Vor der Typgenehmigung als unabhängige technische Bewertung neben dem eigenen Nachweis, bei Integration eines neuen Steuergeräts oder Zulieferers und vor dem Rollout einer Update-Funktion über die Luftschnittstelle.
Nicht direkt. Ihre Pflichten entstehen aus Ihrer Rolle als Betreiber und aus der Anbindung von Telematik- und Plattformdiensten an Ihre eigene IT. Das ist ein anderer Prüfumfang als eine Typgenehmigung.
Firmware-Analyse, Update-Weg und Umgang mit Schlüsselmaterial gehören zum Prüfumfang. Ein Steuergerät bringt die Sicherheitseigenschaften mit, die sein Hersteller ihm gegeben hat.