Schwachstelle Keyless-Entry-Systeme

Analyse eines Schlüssel-Hacks

12. Juli 2021, 10:30 Uhr | Autor: Dr. Dennis Kengo Oka, Redaktion: Irina Hübner

Dass Komfort seinen Preis hat, ist bekannt. Bei Keyless-Entry-Systemen ist er allerdings ziemlich hoch, er geht auf Kosten der Sicherheit. Der folgende Beitrag analysiert einen solchen Schlüssel-Hack und erläutert, welche Sicherheitsmaßnahmen dazu beitragen können, solche Angriffe zu stoppen.

Die Konnektivität nimmt zu, der Anteil von Software in Automobilsystemen wird höher und komplexer und moderne Fahrzeuge damit anfälliger für Angriffe auf die Cybersicherheit. Über die Jahre haben Sicherheitsforscher bereits eine Reihe von Sicherheitslücken in Fahrzeugsystemen identifiziert, die diesen Befund belegen. Ein jüngeres Beispiel sind verschiedene Sicherheitslücken im Keyless-Entry-System des Tesla Model X, aufgedeckt von Lennert Wouters an der Universität von Leuven, Belgien, im November 2020.

Die Angriffsschritte beim Schlüssel-Hack

Die einzelnen Angriffsschritte auf das Keyless-Entry-System des Tesla Model X sind in Bild 1 dargestellt. Die Zahlen markieren die einzelnen Schritte. Das Zielfahrzeug ist verriegelt und der Schlüssel befindet sich nicht im Fahrzeug.

Der Angreifer verwendet ein vorbereitetes Gerät, das aus einem modifizierten Body Control Module (BCM), einem modifizierten Schlüssel (Key Fob) und einem Raspberry Pi besteht. Zu den Modifikationen gehört das Ersetzen des Secure-Element- (SE-)Chips durch Python-Skripte, die auf dem Raspberry Pi laufen und das SE emulieren. Der Angriff umfasst die folgenden Schritte:

Der Angreifer nähert sich dem Zielfahrzeug, liest die Fahrgestellnummer durch die Windschutzscheibe und konfiguriert das emulierte SE für das modifizierte BCM im Angriffsgerät so, dass es die Fahrgestellnummer des Zielfahrzeugs verwendet.
Der Angreifer ortet den Schlüssel des Zielfahrzeugs, bringt das angreifende Gerät in die Nähe und stellt über Niederfrequenz (NF) eine Verbindung in einer Entfernung von bis zu etwa 5 m her, indem er vorgibt, das Zielfahrzeug zu sein. Der Angreifer verwendet eine von der Fahrgestellnummer abgeleitete Kennung, um den zuvor gepaarten Schlüssel zu zwingen, sich über Bluetooth Low Energy (BLE) als verbindungsfähig zu melden.
Der Angreifer überträgt ein manipuliertes Firmware-Update über BLE vom Raspberry Pi auf den Zielschlüssel, um die vollständige Kontrolle zu erlangen. Dieses Update lässt sich über den Over-The-Air-(OTA-)Download-Service auf dem Zielschlüssel aus einer Entfernung von bis zu 30 Metern durchführen.
Nach dem Update des Zielschlüssels verbindet sich das angreifende Gerät erneut über BLE. Auf dem Schlüssel läuft jetzt die bösartige, vom Angreifer kontrollierte Firmware. Sie erlaubt es, beliebige APDU-Befehle (Application Protocol Data Unit) an die SE im Zielschlüssel zu senden, sodass der Angreifer eine Reihe gültiger einmaliger Entriegelungsbefehle (Tür entriegeln, Kofferraum entriegeln usw.) für das Zielfahrzeug von der SE im Schlüssel extrahieren kann.
Der Angreifer nähert sich dem Zielfahrzeug und verwendet die extrahierten Befehle, um das Zielfahrzeug zu entriegeln. Die Entriegelungsbefehle werden über BLE vom Raspberry Pi an das Ziel-BCM gesendet.
Der Angreifer verschafft sich physischen Zugang zum Innenraum des Fahrzeugs und kann das Angriffsgerät über den Diagnoseanschluss, der sich unterhalb des zentralen Displays befindet, physisch mit dem bordeigenen Netzwerk verbinden. Das Angriffsgerät verbindet sich über das Controller Area Network (CAN) mit dem Ziel-BCM.
Das Angriffsgerät weist das Ziel-BCM an, sich mit dem modifizierten Schlüssel zu koppeln. Nach einer Challenge-Response-Authentifizierung mit dem BCM, um den modifizierten Schlüssel hinzuzufügen, werden die erforderlichen Anmeldeinformationen in der emulierten SE für den Schlüssel gespeichert.
Der Angreifer startet das Fahrzeug mit dem neu gekoppelten Schlüssel auf dem Angriffsgerät, um erfolgreich eine Challenge-Response-Authentifizierung mit den zuvor gespeicherten Anmeldeinformationen in der emulierten Schlüssel-SE durchzuführen, und kann losfahren.

Sicherheitslücken, die zum Schlüssel-Hack führen

Zwei grundlegende Sicherheitslücken führen dazu, dass dieser Angriff möglich ist:

Zielsystem	Schwachstelle	Ermöglicht dem Angreifer
Schlüssel	Unzureichende Überprüfung der Signatur	Einspielen von manipulierter Firmware auf dem Zielschlüssel über Bluetooth (BLE)
BCM	Fehlende Überprüfung der Signatur	Koppeln des manipulierten Schlüssels mit dem BCM des Zielfahrzeugs

Tabelle 1. Zusammenfassung der Sicherheitslücken.

Obwohl die Signaturprüfung auf dem Schlüssel implementiert ist, ermöglicht eine Sicherheitslücke dem Angreifer, den Schlüssel über BLE mit bösartiger Firmware zu updaten. Darüber hinaus speichern gültige Schlüssel typischerweise signierte Zertifikate, die sie vom Backend bekommen und bei der Bereitstellung erworben haben. Aber gerade diese Zertifikate werden vom BCM des Fahrzeugs beim Koppeln mit dem Schlüssel nicht verifiziert.

Die Probleme wurden bereits im August 2020 an Tesla gemeldet. Im November 2020 veröffentlichte das Unternehmen dann einen Over-The-Air- (OTA)-Patch, um die offengelegten Sicherheitslücken zu schließen.

Da die öffentlich zugänglichen Informationen recht begrenzt sind, werden für die folgende Diskussion möglicher Sicherheitslösungen einige Annahmen zu den Zielsystemen und der Art der Sicherheitslücken getroffen.

Umfassendere Sicherheitsmaßnahmen in der Automobilbranche

In der Automobilindustrie laufen etliche Bemühungen, um die Cybersicherheit zu verbessern. Dazu zählen die Entwicklung des neuen Standards für Cybersicherheitstechnik ISO SAE 214342 und Vorgaben wie die UN-Regelung 155 Cybersicherheit. Um die eingangs beschriebenen Probleme zu identifizieren und zu beheben, gibt es verschiedene Ansätze. Hier soll der Fokus weniger auf einer spezifisch technischen Sicherheitslösung liegen. Vielmehr wollen wir eine breitere Diskussion vorantreiben, was die Automobilindustrie tun sollte, um die Sicherheit zu verbessern und die Risiken von Sicherheitslücken im Endprodukt bereits vor der Vermarktung zu senken.

Implementierungs- und Auslegungsprobleme mit Application Security Testing beheben

Das erste Problem ist die unsachgemäße Signaturprüfung in der Implementierung auf dem Schlüssel. Diese Art von Implementierungsproblemen lässt sich häufig mit statischer Codeanalyse, Software Composition Analysis (zur Identifizierung bekannter Sicherheitslücken) und Fuzz-Tests (zur Erkennung unbekannter Sicherheitslücken) erkennen. Darüber hinaus können auch Penetrationstests dazu dienen, solche Probleme aufzudecken, wenn sich die Tests auf risikoreiche Bereiche wie sicherheitsrelevante Funktionen und Firmware-Updates konzentrieren.

Das zweite Problem ist eine fehlende Zertifikatprüfung in der Auslegung des Pairing-Protokolls zwischen dem BCM und dem Schlüssel. Diese Art von Auslegungsproblemen lässt sich oftmals durch die Überprüfung der Sicherheitsauslegungen identifizieren. Zwingend notwendig ist zusätzlich eine ordnungsgemäße Bedrohungsanalyse und Risikobewertung des Zielsystems, um Bereiche mit hohem Risiko zu identifizieren. Dies trägt dazu dabei, geeignete Sicherheitsanforderungen zu definieren und angemessene Sicherheitskontrollen zu entwickeln. Auch diese Probleme lassen sich mittels Penetrationstests aufdecken, wenn man sich dabei auf risikoreiche Bereiche wie sicherheitsrelevante und Pairing-Funktionen konzentriert.

Proaktives Patch-Management

Es ist kaum möglich, zu 100 Prozent sichere Fahrzeugsysteme zu entwickeln. Automobilkonzerne sollten deshalb geeignete Maßnahmen zur Aktivierung von OTA-Updates in Betracht ziehen, um neu entdeckte Sicherheitslücken zeitnah zu patchen.

Und noch etwas anderes verdeutlicht das Beispiel dieses erfolgreichen Schlüssel-Hacks. Die Automobilindustrie wird nicht umhinkommen, interne Prozesse und Arbeitsabläufe zu etablieren, um Informationen über Sicherheitslücken (wie sie beispielsweise von Sicherheitsforschern bereitgestellt werden) nachzuvollziehen, zu sammeln und zu verarbeiten. Nur dann kann die Branche angemessen auf derartige Sicherheitsbedrohungen reagieren.

Der Autor

Dr. Dennis Kengo Oka
ist Automotive-Cybersecurity-Experte bei Synopsys – mit über 15 Jahren Erfahrung in der Automotive-Branche weltweit. Er hält einen Ph.D. in Automotive Security mit Schwerpunkt auf Lösungen für das vernetzte Auto. Dennis Oka hat über 60 Arbeiten veröffentlicht, darunter Konferenzbeiträge, Zeitschriftenartikel und Bücher. Er ist ein gefragter Redner auf internationalen Konferenzen und Veranstaltungen im Bereich Automotive und Cybersicherheit.