Cyber Security in Fahrzeugen: Wettlauf zwischen Hackern und Industrie​

Mit der Digitalisierung von Autos nimmt die Bedrohung durch Cyber-Attacken zu. Die Industrie muss mit einer ganzheitlichen Sicherheitsinfrastruktur antworten.

In Pocket speichern vorlesen Druckansicht 80 Kommentare lesen
Mercedes Cockpit

Sicherheitslücken in Fahrzeugen, deren Software nicht mit der Außenwelt kommuniziert, wären wenig problematisch. Doch diese Situation gibt es in Neuwagen praktisch nicht mehr.

(Bild: Mercedes)

Lesezeit: 16 Min.
Von
  • Marcus Klische
Inhaltsverzeichnis

Die Zeiten, in denen Fahrzeuge vor allem aus mechanischen und elektronischen Komponenten bestanden, sind längst vorbei. Schon 1967 produzierte Volkswagen ein Fahrzeug mit dem computergestützten, elektronischen Einspritzsystem D-Jetronic von Bosch. Seit den 1970er-Jahren ist Software fester Bestandteil von Autos. Heute werden in modernen Fahrzeugen fast alle Funktionen durch Software unterstützt, selbst so simple Dinge wie ein Scheibenwischer. Dass sich zunehmend die Bezeichnung Software Defined Vehicle (SDV) durchsetzt, ist also nur folgerichtig.

Wie relevant Software für Autos ist, lässt sich auch mit Zahlen veranschaulichen. So umfasst die durchschnittliche Software in einem aktuellen Auto rund 120 Millionen Zeilen Code. Zum Vergleich: Der Tarnkappen-Kampfjet F-35 von Lockheed Martin benötigt etwa 25 Millionen Zeilen, die Boeing 787 zwischen10 und 15 Millionen. Richtig bescheiden nimmt sich das Space Shuttle aus. Mit lediglich 400.000 Zeilen Code beförderte das Raumschiff jahrzehntelang Menschen ins All und wieder zurück.

Ein Gastbeitrag von Marcus Klische, Associated Partner bei MHP

(Bild: 

MHP

)

Marcus Klische, Associated Partner bei MHP und unter anderem Teilnehmer der UNECE WP.29 GRVA Taskforce Cyber Security und Softwareupdates, DIN Normausschussmitglied Automobiltechnik Arbeitskreis Cybersecurity & Arbeitskreis Softwareupdate Engineering: „Funktionale Sicherheit im Fahrzeug kann nur gewährleistet werden, wenn die Hardware und Software im Fahrzeug gegen Manipulation geschützt wird – ohne Security keine Safety!“

Für Fahrer bringt die Digitalisierung der Fahrzeuge eine Reihe von Vorteilen mit sich. Dazu gehört in vielen Fällen auch eine zusätzliche, physische Sicherheit: Ein Abstandhalter hilft dabei, Auffahrunfälle zu vermeiden, ein Spurhalteassistent greift ein, wenn der Fahrer in einen Sekundenschlaf fällt. Gleichzeitig ergeben sich aus der Digitalisierung auch neue Risiken durch Cyber-Attacken. Das liegt vor allem an drei Faktoren.

Mit jeder zusätzlichen Zeile Code nimmt aus statistischer Sicht auch die Anzahl an Bugs zu. Als Faustregel gilt im Automotive-Kontext: Pro einer Million Zeilen Code ist mit etwa 1000 Bugs zu rechnen, was schon eine super Qualität ist. Von etwa fünf Prozent dieser Bugs geht die Gefahr von Cyber-Angriffen aus. Bei einer durchschnittlichen SDV-Software sind also 6000 kritische Programmierfehler wahrscheinlich. By the way: Bug-Bounty-Programme können den Herstellern helfen, gemeinsam mit der Security Community Bugs frühzeitig zu finden und dann rasch zu beheben. Tesla beispielsweise ist hier schon sehr aktiv.

Wären Autos in sich geschlossene Systeme, wären solche Bugs kein so großes Risiko, da die Angriffe einen physischen Zugang erfordern würden und sich auch nicht selbstständig verteilen könnten. Der Aufwand wäre für Cyberkriminelle zu hoch. Tatsächlich sind Fahrzeuge aber offen und kommunizieren über viele verschiedene Schnittstellen mit ihrer Umwelt. Nicht nur über das Internet, sondern ebenso über Bluetooth, das automatische Notrufsystem eCall, über Mirco-SD-Karten und über OBD-2-Diagnosebuchsen. All das sind potenzielle Einfallstore für Hacker.

Fahrzeuge kommunizieren außerdem nicht nur mit ihrer Umwelt, die einzelnen verbauten Komponenten tauschen sich auch untereinander aus. Das führt dazu, dass Hacker unabhängig davon, wo der Erstzugriff erfolgt ist, überall hingelangen – entlang von sogenannten Attack Trees. Auch vom Temperatursensor zur Lenkradsteuerung. In Summe sind die drei Faktoren eine Einladung an alle Cyberkriminellen, ihre Fähigkeiten auszuprobieren.

Sollte man angesichts dessen das mit der Digitalisierung und Vernetzung der Fahrzeuge wegen der Risiken doch lieber sein lassen? Natürlich nicht, schließlich steht wirklich eine Menge auf der Haben-Seite! Für die Automotive-Unternehmen, für die Fahrer und für alle Menschen, die irgendwie am Verkehr teilnehmen. Stattdessen sollten Hersteller und Zulieferer die neuen Bedrohungsszenarien als Herausforderung verstehen, der sie sich jetzt konsequent widmen müssen. Sie müssen ein digitales Sicherheitskonzept entwickeln und umsetzen – auch, wenn das ursprünglich nicht zu ihrer Kernkompetenz gehört.

Um auf Risiken reagieren zu können, müssen diese zunächst einmal bekannt sein. Das kontinuierliche Monitoring der Entwicklungen gehört deshalb unbedingt zu einem digitalen Sicherheitskonzept. Eine gute erste Orientierung liefert beispielsweise der jährlich erscheinende Global Automotive Cybersecurity Report des Cyber-Security-Unternehmens Upstream. In aktuellen Bericht werden für die nähere Zukunft vor allem drei Bedrohungsszenarien skizziert.

Zahlreiche OEMs bietet heute die Option an, via Abo-Modell zusätzliche Funktionalitäten freizuschalten – etwa Sitzheizung, Fernlichtassistenten oder Apple CarPlay. Das Stichwort dazu: Function on Demand. Für die Hersteller bietet das Angebot eine Reihe von Vorteilen. Sie verdienen mit einem Fahrzeug nicht nur einmal beim Verkauf, sondern haben dauerhafte Einnahmen. Außerdem können sie mehr oder weniger sämtliche Fahrzeuge eines Modells mit den gleichen mechanischen und elektronischen Komponenten ausstatten, was zu einem deutlich effizienteren Produktionsprozess führt. Es gibt allerdings auch einen erheblichen Nachteil: Die verbauten Komponenten müssen nur noch im Over-the-air-Verfahren (OTA) über die Software freigeschaltet werden. Für Hacker ist das ein großartiger Ansatzpunkt für Attacken.

Hinzu kommt, dass ein nicht autorisierter Zugriff auch im Auftrag des Besitzers erfolgen kann. Um die Function-on-Demand-Kosten zu umgehen, lassen sie die Software einfach "jailbreaken". Durch solche Manipulationen ergeben sich schnell zusätzliche Angriffsvektoren. Da die Hersteller diese zunächst nicht bekannt sind, können sie auch keine Gegenmaßnahmen entwickeln. Für Cyberkriminelle mit weniger Business-orientierten Absichten ist das ein Traum. Gerade erst ist es einer Gruppe von Forschern gelungen, das Infotainment-System von Tesla zu hacken und eigentlich kostenpflichtige Upgrades umsonst zu bekommen. Zudem konnten sie Daten der Nutzer abgreifen.

Viele Logistikunternehmen modernisieren derzeit ihre Flotten und ersetzen aussortierte Vehikel durch vernetzte Elektroautos. Damit kommen zum einen rechtlichen Vorgaben der Europäische Union nach (Stichwort: Green Deal). Zum anderen optimieren sie durch die Vernetzung die Auslastung ihrer gesamten Flotte – etwa durch eine flexiblere Routenplanung. Der Austausch zwischen den Fahrzeugen und dem System für das digitale Flottenmanagement macht allerdings auch Hackern den Zugriff vergleichsweise leicht – und zwar nicht nur auf ein einzelnes Vehikel, sondern auf die gesamte Flotte. Damit sind nicht nur in der Lage, bestimmte Fahrer zu gefährden. Sie haben auch die Möglichkeit, gesamte Flotten stillstehen zu lassen und damit Lieferketten erheblich zu stören. Angesichts der massiven Folgen, die Lieferschwierigkeiten mit sich bringen, gewinnen Cyberkriminelle dadurch ein erhebliches Erpressungspotenzial.

Neben einzelnen Fahrzeugen oder ganzen Flotten wird die Ladeinfrastruktur für Elektroautos zum immer beliebteren Ziel. Dabei nutzen Hacker oft das Open Charge Point Protocol (OCPP), das die Kommunikation zwischen einem Ladepunkt und dem Backend-System des Charge Point Operators (CPO) beziehungsweise des Mobility Service Providers (MSP) organisiert, und führen darüber Denial-of-Service- (DoS) und Distributed-Denial-of-Service-Angriffe (DDoS) aus. Auf diese Weise können Cyberkriminelle nicht nur essenzielle Bestandteile der Verkehrsinfrastruktur lahmlegen, sondern gegebenenfalls auch sensible Daten der Fahrer abgreifen. Derzeit ist die Zahl solcher Übergriffe noch überschaubar. Angesichts der voranschreitenden Elektrifizierung und dem damit einhergehenden Ausbau der Infrastruktur spricht aber viel dafür, dass sich das auf absehbare Zeit ändert.

Die Gesetzgeber weltweit haben längst die Risiken erkannt, die von Software Defined Vehicles ausgehen, und haben deshalb entsprechende regulatorische Vorgaben auf den Weg gebracht. Das gilt auch für die Staaten der Europäischen Union. Die EU bezieht sich dabei hauptsächlich auf zwei Richtlinien der United Nations Economic Commission for Europe (UNECE), die von der Working Party on Automated/Autonomous and Connected Vehicles (WP.29) erarbeitet wurden:

UN-Regulation No. 155 – Cyber security

UN-Regulation No. 156 – Software update

Die UNECE R 155 verpflichtet Automobilhersteller dazu, ein Cyber-Security-Management-System (CSMS) in ihren Fahrzeugentwicklungsprozess zu integrieren und dieses über den gesamten Lebenszyklus eines Fahrzeugmodells aktuell zu halten – prinzipiell bis zum End of Life des letzten einzelnen Fahrzeugs des Modells. Die UNECE R 156 verlangt von den OEMs, ein Software-Update-Management-System (SUMS) zu etablieren. Damit unterscheiden sich die beiden Vorgaben deutlich von anderen Anforderungen, die für eine Typzulassung neuer Fahrzeugmodelle erfüllt sein müssen. Die UNECE R 155 und die UNECE R 156 zielen nicht auf spezifische Produktmerkmale für eine Betriebsgenehmigung beziehungsweise die Straßenzulassung ab, sondern auf die Prozesse bei den Automobilherstellern.

Tatsächlich lässt sich der Umweg über die Prozesse kaum vermeiden, weil der Sicherheitsstatus zum Zulassungszeitpunkt nur wenig darüber aussagt, wie das Fahrzeug in Zukunft geschützt sein wird. Denn wie bei anderen Software-basierten Produkten findet auch bei SDVs ein Wettlauf zwischen Hackern auf der einen Seite und Sicherheitsexperten auf der anderen Seite statt. Bessere Sicherheitskonzepte fordern Cyberkriminellen häufig regelrecht heraus, auf die von ihnen neu entwickelten Attacken müssen dann die OEMS wieder reagieren. Und so weiter.

Dass die Vorgaben der UNECE auf die Prozesse abzielen, ist also nachvollziehbar. Beide Richtlinien sind aber sehr generisch formuliert und lassen bei der Auditierung einen großen Raum für Interpretationen. Dass es auch konkreter geht, zeigen drei Normen der International Standard Organisation. Die ISO/SAE[ ]21434 beschreibt ein System für das Engineering von Cybersicherheit, die ISO/PAS[ ]5112 macht Vorgaben für dessen Auditierung und für die Umsetzung eines Software-Update-Management-System wird durch die ISO[ ]24089 geregelt. Für die meisten OEMs sind diese strikteren Regeln vorteilhaft, weil sie den Einstieg in die Cyber Security erleichtern. Aus den Vorgaben lassen sich so – grob skizziert – drei Pflichten ableiten.

Die Hersteller müssen ein Riskmanagement etablieren, das Maßnahmen zur Risikoerkennung, -bewertung und -minderung bezüglich aller denkbaren Cybergefahren umfasst. Das erstreckt sich über den gesamten Produktlebenszyklus; die Verantwortung für die Cyber Security endet damit nicht mit der Typzulassung eines Modells, sondern reicht von der Designphase bei der Produktentwicklung bis zum End of Life eines einzelnen Fahrzeugs.

Das Risikomanagement an sich ist schon eine Herkulesaufgabe. Den ein OEM muss dazu jedes einzelne Bauteil kennen und dieses bei jedem einzelnen Fahrzeug in der Stückliste führen. Das gleich gilt für alle Softwarefunktionen, selbst das System on Chip (SoC) muss dokumentiert werden. Damit das gelingt, müssen alle Stakeholder entlang der Lieferkette eine volle Transparenz sicherstellen. Jede Veränderung an einem Bauteil oder an einer Softwarefunktion muss dokumentiert und neu bewertet werden.

Das Risikomanagement geht mit der Pflicht einher, aktiv nach möglichen neuen Bedrohungsszenarien zu suchen und auf diese zeitnah zu reagieren – beispielsweise mit regelmäßigen Softwareupdates, die sich nicht nachteilig auf andere Fahrzeugfunktionalitäten auswirken dürfen, was eine zusätzliche Herausforderung ist. Dabei soll sich die Suche nicht nur auf das Fahrzeug beziehen, sondern auch fahrzeugfremde Sektoren einschließen: Beispielsweise kann der Angriff auf einen eSIM oder einen Bluetooth-Chip bei einem Mobiltelefon auch Auswirkungen auf das Fahrzeug haben, wenn dort die gleiche Hardware verbaut wurde.