Software-Lösungen für mehr IT-Sicherheit im Auto

Wer sichere Elektronik im Kfz entwickeln will, muss alle Aspekte berücksichtigen.Wind River

Die Zahl der Steuergeräte und der Umfang der Software ist in modernen Fahrzeugen beachtlich gestiegen. Dies eröffnet neues Potenzial für Angreifer, da konzeptionelle Sicherheitslücken und schlichte Programmierfehler wahrscheinlicher werden. Connectivity durch Bluetooth, Wifi und Mobilfunk erhöht zudem die Chancen, dass Fahrzeuge zum Ziel für Angriffe aus der Ferne werden. Aber auch DVDs, USB-Abschlüsse oder das TPMS sind mögliche Angriffswege. Höchste Zeit also, das Thema Security ernst zu nehmen.

Zunehmende Systemkomplexität

Um neue Funktionen schneller ins Auto zu integrieren, sind die Hersteller gezwungen vermehrt vorhandene Software aus der Unterhaltungselektronik einzusetzen und mit häufigeren Firmware-Updates umzugehen, die der Endkunde selbst durchführt, sei es Over-the-Air oder per USB-Stick. Updates können Fehler beseitigen, sie sind aber ein weiterer potenzieller Angriffspfad.

Heute werden zwischen 70 und 120 ECUs eingesetzt. Die Konsolidierung von ECUs ist daher aus Gründen des Platzbedarfs, des Gewichts und des Energieverbrauchs zunehmend erforderlich. Immer mehr ECUs haben Schnittstellen zu den IVI-Systemen. So etwa das Instrument-Cluster-Display oder die Einpark-Hilfe-Steuerung oder ADAS wie automatische Verkehrszeichenerkennung: Es gibt also immer mehr Funktionalität pro Steuergerät und die Geräte kommunizieren intensiv miteinander. Das eröffnet mehr mögliche Schwachstellen für Angreifer.

Security-Bedrohungen

Selbst einfache „Hacks“ können einer Automarke schaden. Bei der Betrachtung der möglichen Schwachstellen eines Fahrzeugs ist Datendiebstahl wie etwa das Entwenden von Adress- und/oder Telefonbüchern einer der einfachsten Angriffe. DOS-Angriffe (Denial of Service) und andere Belästigungen sind typische weiter verbreitete Angriffe.

Die Beweggründe von Einzelpersonen oder Gruppen, einen Angriff durchzuführen, sind sehr unterschiedlich. Manche mögen vielleicht nur als Hacker bekannt werden, während andere auf bestimmte Marken oder Organisationen zielen oder finanzielle Interessen verfolgen. Zunehmend nutzen weniger erfahrene Angreifer Tools, die von Experten geschaffen wurden oder in offiziellen App-Download-Stores angeboten werden. Bei den bislang beobachteten Angriffstypen im Automotive-Bereich ging es meist um persönlichen Ruhm und die Beachtung als Hacker. Das kann sich aber jederzeit ändern.

Eine erhöhte Connectivity treibt die Notwendigkeit für mehr Security. Das IEEE (Institute of Electrical and Electronics Engineers) hat vor kurzem prognostiziert, dass bis 2025 etwa 60 % aller Autos über einen Internet-Zugang verfügen. Machine-to-Machine-Technologien (M2M) und sich entwickelnde Cloud-Architekturen im Internet der Dinge bedeuten eine höhere Komplexität bei der System-Konsolidierung mit verschiedenen Security-Ebenen, wie sie eine Reihe unterschiedlicher Applikationen und Geräte verlangen.

Schwachstellen beseitigen

Für die Automotive-Industrie wird es immer wichtiger, Security in die Herstellung und in die Systementwicklung einzubeziehen. Dazu gehören eine sichere Plattform und eine sichere Infrastruktur (siehe Infokasten „Aspekte der Fahrzeug-Security“). Eine umfassende Ende-zu-Ende-Bedrohungsanalyse sollte folgendes beinhalten: Systemdesign, unterstützte I/Os sowie verwendete Protokolle und die Applikationsentwicklung selbst. Außerdem sollten Implementierung, Konfiguration, Wartung und Updates sowie Endanwendung und Risiko-Ermittlung enthalten sein.

Die wichtigsten Schutzmaßnahmen sind: Verhinderung des Bypassing von Standardfunktionen innerhalb der APIs, Schutz vor System-Unterbrechung oder Beschädigung, Verhinderung nicht autorisierter Applikationsausführungen oder Updates sowie Verhinderung von Datenweitergabe oder Beschädigung.

Bei einer neuen Security-basierten Architektur zum Beispiel für eine IVI Head Unit, müssen viele Schritte adressiert werden, um Schwachstellen zu eliminieren. Ein Security-basiertes Konzept sollte in die Architekturplanungsphase für In-Vehicle-Infotainmentsysteme implementiert werden. Der erste Teil ist eine Auflistung der Bedrohungen. Dies beinhaltet eine komplette Bewertung der Gerätesicherheit. Dabei wird nach Spezialfällen Ausschau gehalten, in denen die Umgebung Gefahren ausgesetzt ist. Pfade für mögliche Angriffe müssen gefunden und Gegenmaßnahmen sowie Reaktionen auf Anforderungen definiert werden.

Sicherheit im Entwicklungszyklus

Von diesem Punkt aus muss der Entwicklungszyklus alle Security-Anforderungen einschließlich Komponenten, die zum Erfüllen dieser Anforderungen erforderlich sind, berücksichtigen. Der nächste Schritt ist ein auf Security optimiertes Design, das die Trennung von Systemkomponenten und die Nutzung von Security-Funktionen beinhaltet. Die Auswahl einer sicheren Laufzeitumgebung wird normalerweise zum Einsatz einer zertifizierten Laufzeitplattform einschließlich Hypervisor und Betriebssystem plus zertifizierte Middleware führen.

Applikationsschutz ist ebenfalls erforderlich, zum Beispiel durch Whitelisting wie bei IT-basierter Security verwendet (nur bekannt sichere Software und erlaubte Funktionen werden von der Plattform tatsächlich zugelassen). In Richtung Backend des Prozesses sollten Lifecycle-Entwicklung und Tools die Nutzung von Code-Analyse-Tools, Security-Test-Suites und What-if-Schwachstellenanalysen beinhalten. Außerdem sollten Systemkonfiguration und Bereitstellung, System-Updates und Management des Security-Konzeptes berücksichtigt werden.

Bild 1: Partition mit Hypervisor trennt Memory und Prozesse.Wind River

Partitionierung

Ein Beispielsystem mit Trennung von Ressourcen ist in Bild 1 zu sehen. Ein Hypervisor sitzt über der darunter liegenden realen Hardware und trennt die Systemprozesse und Memory-Zugriffe. Der Hypervisor partitioniert das System und ermöglicht es, dass verschiedene Betriebssysteme wie Linux/Android oder ein Echtzeit-Betriebssystem wie VxWorks auf virtuellen Geräten laufen, die sich eine reale Hardware teilen. Da alle Hardware-Zugriffe über den Hypervisor laufen, kann er sie auch kontrollieren und im Sinne des Whitelisting nur plausible Aktionen gestatten.

Jedes System läuft auf seiner eigenen Kernel-Basis so, als ob es zwei getrennte Hardware-Module wären. In diesem Fall befindet sich die Partition irgendwo im Fahrzeug, wo es einen Zugang zu den Automotive-Bussen wie CAN oder Flexray gibt. Damit das klappt, sind viele Anforderungen zu erfüllen einschließlich der Bestätigung, dass eine Nachricht das Interface tatsächlich durchlaufen hat. Dies Information muss vertrauenswürdig (trusted) sein, damit es zu keinen unerwünschten Aktionen kommt.

Bild 2: Applikationspartition mit Hypervisor für die Trennung zwischen Memory und Prozess.Wind River

Das IVI-System in Bild 2 zeigt die herkömmliche Trennung des Haupt-HMI-Systems (Human Machine Interface) mit Zugriff auf Middleware. Auf der anderen Seite befindet sich eine Sandbox oder Applikationssoftware-Entwicklungsumgebung, wiederum mit einem Hypervisor für eine vollständige Trennung zwischen Memory und Prozess. In der Sandbox kann ein Android-basiertes System entsprechend der Anforderungen der Kunden einschließlich spezieller Funktionen oder spezieller GUI-Skins modifiziert werden. Nachrichtenübermittlung oder Interfacing erfolgen über den Hypervisor.

Diese Lösung nutzt die Fähigkeiten von Android und steuert die Partition vom Haupt-IVI-System. Falls die Sandbox aus irgendeinem Grund abstürzt, hat dies wegen der Partition keine Auswirkungen auf das Hauptsystem. Aufgrund von Runtime-Scheduling-Policies gibt es auch eine Garantie für das richtige Maß an CPU-Performance für das Hauptsystem.

Hilfe gefragt

Bisher haben Automotive-OEMs proprietäre Netzwerk-Backbones mit völlig anderen Security-Konzepten entwickelt. Das Internet-fähige Auto der Zukunft im Zeitalter des Internet der Dinge birgt steigende Komplexitäten und den zunehmenden Einsatz von Software aus der IT und der Konsumelektronik. Mehr und mehr werden Automotive-Hersteller Partner brauchen, die über jahrelange Erfahrungen in vielen vertikalen Märkten verfügen und eine hohe Expertise in der Entwicklung robuster Security-Lösungen vorweisen können.

(lei)