Sicherheitslücken in selbstfahrenden Autos? Alles halb so wild
Sicherheit von selbstfahrenden Autos: Es gibt noch Arbeit, aber im Moment zumindest keine so fatalen Lücken, dass Leib und Leben der Passagiere gefährdet wären.
![Autonomes Fahren](https://heise.cloudimg.io/width/610/q85.png-lossy-85.webp-lossy-85.foil1/_www-heise-de_/imgs/18/2/4/8/0/5/4/7/urn-newsml-dpa-com-20090101-170330-99-878048_large_4_3-66b99bce09c94a47.jpeg)
Ein Mann fährt auf der Autobahn 81 bei Abstatt in einem Auto, das als Prototyp für autonomes Fahren genutzt wird.
(Bild: dpa, Daniel Naupold/Archiv)
Vor einigen Jahren steuerten die Promi-Hacker Charlie Miller und Chris Valasek einen Geländewagen über das Internet aus der Ferne. Miller und Valasek sind inzwischen in Diensten von Cruise, einer Tochter von General Motors, die selbstfahrende Autos entwickelt. Also Fahrzeuge der Stufe 4, die ohne Lenkrad und Pedale auskommen und sich selbständig im kartierten Bereich bewegen können. Wie Miller und Valasek während der Black Hat ausführten, sind diese Autos trotz Funktionen zum autonomen Fahren nur teilweise Neuentwicklungen. Sie basieren meist auf einem herkömmlichen Fahrzeug, das durch teure – die Rede war von 75.000 US-Dollar pro Auto – Pakete aus Sensoren fit gemacht wird für die selbstständige Fahrt. Die Basisfahrzeuge wurden jedoch meist ohne besonderen Fokus auf IT-Sicherheit entwickelt und müssen daher jetzt abgesichert werden.
Als Beispiel hierfür nannten Miller und Valasek das zu verbauende Ethernet-Netzwerk. Es ist nötig, da der heute übliche CAN-Bus die immensen Datenmengen, die die zur Erfassung der Umgebung notwendigen Sensoren (LIDAR, hochauflösende Kameras) erzeugen, nicht mehr übertragen kann. Die zum Verarbeiten der Sensordaten nötigen Rechner füllen heute noch einen ganzen Kofferraum aus und sind laut Valasek eher Supercomputer als KfZ-taugliche Rechnereinheit. Problematisch hierbei ist, dass die im Automotive-Umfeld üblichen Ethernet-Komponenten keinerlei Sicherheitsfunktionen aufweisen. Zumeist fließen die Daten per UDP, einen TCP/IP-Stack gibt es nicht. Ohne einen solchen sind aber gängige Sicherheitsmechanismen wie 802.1x oder TLS (Transport Layer Security) unmöglich. Miller scherzte, dass der führende LIDAR-Hersteller zwar TLS im Funktionsumfang habe – damit aber "Terrestrial Laser Scanner" meint.
Algorithmen zur Objekterkennung werden von Hand trainiert
Das Datennetzwerk muss absolut sicher sein vor Manipulationen, damit sämtliche Steuerkommandos wie Bremsen, Beschleunigen oder Einschlagen des Lenkrads so ankommen, wie sie der Rechner im Kofferraum losgeschickt hat. Ohne digitale Signatur der Datenpakete geht es hierbei also nicht.
Weniger Sorgen machen sich die Hacker hingegen über die Software, die die Sensordaten auswertet. Im Moment trainieren alle KfZ-Hersteller ihre zur Objekterkennung nötigen Algorithmen noch weitgehend per Hand: Menschen klassifizieren die während der ausgiebigen Testfahrten erfassten Objekte wie Autos, Kinder oder Radfahrer und verbessern so die Algorithmen. Manipulationen der Datensätze halten die Fachleute für ausgeschlossen. Laut Miller ist es auch ausgemachter Unsinn, dass ein per Aufkleber modifiziertes Stoppschild von der Software plötzlich übersehen wird: Das Auto sieht das Schild nicht nur per LIDAR oder Kamera, sondern kennt dessen exakte Position dank höchst detailliertem Kartenmaterial. "Solange das Schild in der Karte verzeichnet ist, hält das Auto an. Selbst wenn jemand das Schild abmontiert", so Miller.
"Was nicht eingebaut ist, kann nicht gehackt werden"
Von daher sei es auch kein Problem, wenn Angreifer per GPS-Jammer das Satellitensignal stören – das Auto orientiert sich nicht mittels des vergleichsweise unpräzisen GPS. Selbst ein Blenden der LIDAR-Sensoren oder ein Ausfall der Kameras sollte keine Gefahr für die Insassen bedeuten: Bekommt der Rechner keine verwertbaren Daten mehr, hält er das Auto einfach an.
Ansonsten gilt es, die Angriffsfläche in den Fahrzeugen zu reduzieren: Bluetooth, WLAN oder Multimedia-Zentralen sind dann nicht mehr nötig, wenn die vollautonom fahrenden Autos von Mobilitätsplattformen betrieben werden. "Was nicht eingebaut ist, kann nicht gehackt werden", so Valasek. Zum Signieren von Software nötige Private Keys müssen für den Fahrgast unzugänglich in TPM-Chips oder Secure Enclaves abgelegt werden und nicht in einem Filesystem. Sämtliche Software-Updates, also Firmware, Kalibrierungs- oder Kartendaten, müssen signiert sein. Und zur Kommunikation nach außen – das Backoffice der Mobilitätsplattform muss ja wissen, wo die Autos sind und zur Abrechnung nötige Daten vom Auto empfangen – sollte ausschließlich TLS mit Zertifikats-Pinning beziehungsweise von einer privaten Zertifizierungsstelle (Certificate Authority, CA) ausgestellte Zertifikate zum Einsatz kommen.
Relevante und weniger kritische Komponenten trennen
Im Auto müssen die für die Fahrt relevanten Komponenten durch VLANs von den weniger kritischen Komponenten getrennt werden. IP-Restriktionen und Logging aller Vorkommnisse machen das Paket rund. Also allesamt aus der klassischen Unternehmens-IT bekannte Schutzmechanismen, die kriminelle Hacker auch im rollenden Rechenzentrum ins Leere laufen lassen sollten. So zumindest die Ansicht von Miller und Valasek, die die Ergebnisse ihrer Überlegungen auch in einem Whitepaper zusammengefasst haben. (bme)