Assistiertes & Autonomes Fahren: Worauf es bei der IT-Sicherheit wirklich ankommt

Mit der zunehmenden Vernetzung und Automatisierung unserer Fahrzeuge steigt auch der Bedarf an IT-Sicherheit. Warum die Standardisierung von Sicherheitsaspekten elementar ist, was die Gesetzgebung leisten muss und welche Entwicklungsansätze aktuell verfolgt werden, erläutert Dr. Frank van den Beuken.

Autos durchlaufen aktuell eine echte Evolution. Sie entwickeln sich vom elektromechanischen Gerät unter der Kontrolle eines menschlichen Fahrers zu einem komplett autonomen Fahrzeug. Wir befinden uns am Wendepunkt – heute schon sind die meisten Fahrzeuge mit Advanced Driver Assistance Systems (ADAS) ausgestattet. Dazu gehören Spurassistenten, autonome Notfall-Bremssysteme, verbesserte Sichtsysteme und vieles mehr. Gleichzeitig leisten voll-autonome Fahrzeuge gerade Millionen an Testkilometern ab.

Die Systeme, die all diese Funktionen zur Verfügung stellen, bestehen aus Sensoren, Aktivatoren und Radar- und Lidarsystemen, die über Netzwerke miteinander kommunizieren und über Mikrocontroller überwacht werden. Man könnte auch sagen, ein Auto ist heute schon ein „Internet auf Rädern“. Mehr noch: Autos kommunizieren heute auch mit anderen Fahrzeugen (Vehicle-to-Vehicle-Kommunikation oder „V to V“), mit der Infrastruktur (Ampeln oder Straßenschildern – „V to I“) und Satelliten für Navigation und Berichtswesen.

Die Basis für all das liefert, wie sollte es anders sein, Software. Zusammengerechnet mehr als 100 Millionen Codezeilen. Und dabei ist der Code für Anwendungen, Betriebssysteme, Middleware Communication Stacks und die Interfaces für Sensoren, Aktuatoren und das Armaturenbrett noch gar nicht eingerechnet.

Verbesserte Funktionalität – mehr Schwachstellen

Je komplexer das alles wird, desto größer ist die Gefahr durch Schwachstellen. Das betrifft beide Aspekte der Software-Sicherheit gleichermaßen: Safety und Security. Mit dem Anwachsen der „V to X“-Kommunikation öffnen sich Autos und deren Technik für böswillige Attacken von außen. Erst vor kurzem hat ein Angreifer die Kontrolle über einen Jeep übernommen, indem er den Fahrer einfach ausgeschaltet hat. Weitere Schwachstellen sind die „kleinen Helfer“ für den Fahrer. So gut wie alle Fahrzeughersteller nutzen On-Board-Diagnosesysteme (ODB).

Damit können verschiedene Parameter angezeigt werden, die bei Fehlersuche und Service wichtig sind. Das dafür notwendige Interface ODB II ist öffentlich zugänglich. Wer bei Google ODB2 eingibt, findet eine Fülle an Bluetooth-ODB-Konnektoren, die es dem Fahrer erlauben, sich auf seinem Smartphone Daten zum Zustand seines Motors anzeigen zu lassen. Gleichzeitig ist das aber auch ein Einfallstor für Menschen, die es weniger gut meinen. Der Universität von Michigan ist es gelungen, bei einem Versuch die Kontrolle über einen Lastwagen und einen Schulbus zu übernehmen – die Eingriffe der jeweiligen Fahrer wurden vom System einfach ignoriert.

Bei der schieren Masse an Code ist aber auch die funktionale Sicherheit kritisch. Sehr viel Legacy-Code ist minderwertig. Das bekam zum Beispiel Toyota zu spüren, als immer wieder wie von Geisterhand Fahrzeuge des Modells Aygo ohne Zutun des Fahrers beschleunigten; d.h. es braucht neuen Code mit einem deutlich höheren Standard.

Standardisierung

Erst vor fünf Jahren wurde ein neuer Sicherheitsstandard für Kraftfahrzeuge veröffentlicht. ISO 26262 basiert auf IEC 61508. Dieser Standard für die funktionale Sicherheit bündelt die Anforderungen an elektrische und elektronische Systeme in Pkws aus Serienproduktion. Er bezieht sich auf alle Vorgänge in sicherheitsrelevanten Systemen, während des gesamten Sicherheitslebenszyklus – einschließlich der Anforderungen an die Softwarequalität.

Wie bewertet man das Risiko, das mit einem Sub-System verbunden ist? Der Standard nutzt dazu ASIL (Automotive Safety Integrity Level). Die Bewertungsskala reicht von A bis D, wobei A den niedrigsten Level für die Sicherheitsintegrität darstellt und D den höchsten. Zusätzlich zu den ASIL kennzeichnet das Klassenqualitätsmanagement, wo eine Anforderung nicht mit ISO 26262 übereinstimmt. So gewährleistet die Entwicklungsorganisation die Qualität ihrer Software. Die Parameter Risikoschweregrad, Expositionswahrscheinlichkeit und Kontrollierbarkeit bestimmen den ASIL.

(ID:45188190)