Separierung, Sicherheit und das vernetzte Auto

Seite: 2/3

Firmen zum Thema

Grundlagen der Hardware-basierten Separierung

Das Tesla-Modell S nutzt eine physische (LAN-CAN) Gateway-Box, um das Infotainment-System von der sicherheitskritischen Fahrzeugsteuerung zu isolieren (Bild 1). In der Gateway-Box kommt ein strukturiertes API zum Einsatz, das nur einen begrenzten Befehlssatz zwischen den beiden Netzwerken erlaubt. Dies bedeutet, dass, sollte auf die sicherheitskritischen Fahrzeugsteuerungen zugegriffen werden, ein detailliertes Wissen rund um dieses API erforderlich wäre.

Dennoch hat es sich nicht als komplett sicher erwiesen, was vielleicht zeigt, welch schwierige Herausforderung ein vernetztes Fahrzeug tatsächlich darstellt. Fast genauso wichtig: es führt zu beträchtlichen Hardware-Overheadkosten.

Bildergalerie

Vorteile der Software-basierten Separierung

Auch wenn Hardware-Separierung einen effektiven Ansatz darstellt – ließe sich eine ähnliche oder gar bessere Lösung über die Software finden, wäre sie mit ziemlicher Wahrscheinlichkeit kostengünstiger.

Sucht man nach „Embedded Hypervisor“ auf jeder beliebigen der beliebten Webseiten zum Thema Automobilelektronik, könnte man leicht annehmen, dass sämtliche Angebote gleichwertig sind. Um dieser Wahrnehmung ein wenig näher nachzugehen, sehen wir uns ein Automobilsystem an, das für den hiesigen Zweck statt Separierung durch Hardware einen Hypervisor einsetzt (Bild 2).

Die Hypervisor-Funktion ist wichtig, weil sie es dem Tesla-System erlaubt, sich bei der Erlaubnis beschränkter Kommunikation zwischen zwei sehr unterschiedlichen Anwendungen (Virtual Machines, VM) zu spiegeln – eine zur Fahrzeugsteuerung und die andere für die Infotainment-Systeme. Ein ähnlich verborgenes und strukturiertes API hierfür im Tesla wäre hier ebenfalls sinnvoll.

Doch was die Security betrifft, ist es unbedingt notwendig, dass, selbst wenn die Infotainment-VM gehackt und beeinträchtigt wird, die Fahrzeugsteuerungs-VM nicht gefährdet ist. Sollten die VM echt separiert sein statt über den Hypervisor miteinander verbunden, ist es entscheidend, dass die Angriffsoberfläche durch die Minimierung der gemeinsamen Ressourcen so klein wie möglich gehalten wird.

Wie sich der Linux-Kernel als Typ-1-Hypervisor verhält

Um diesen Punkt zu verdeutlichen, betrachte man die Kernel-based Virtual Machine (KVM), eine Virtualisierungsinfrastruktur, die den Linux-Kernel zu einem Hypervisor macht [1]. Es dient als Beispiel für ein Problem, das bei jedem Typ 1-Hypervisor auftritt.

Wäre die Linux KVM der Hypervisor der Wahl im abstrahierten Automotive-System, wäre die Sicherheit der Fahrzeugsteuerungs-VM abhängig von einem monolithischen Kernel, der mindestens 390 Schnittstellen bereitstellt, mit hunderttausend Parameterwahlmöglichkeiten, implementiert durch 19,5 Millionen sich ständig verändernder Codezeilen. Nicht nur das, auch der I/O-Stack würde sich im monolithischen Kernel des Hypervisors befinden – ein leichter Angriffsvektor für die Fahrzeugsteuerungs-VM.

Linux KVM bietet exakt die Hypervisor-Funktionalität, die erforderlich ist, um die Systemfunktionen zu unterstützen. Doch wenn das Hauptziel in der Separierung zwischen virtuellen Maschinen (VM) unterschiedlicher Kritikalität besteht, ist diese Lösung keinesfalls optimal. Ein besserer Ansatz wäre, die Funktionalität des Hypervisors zu erhalten, aber die Separierung und die Minimierung der Angriffsoberfläche zu Schwerpunkten der Architektur zu machen.

Um zu verstehen, wie das erreicht werden kann, ist es hilfreich, sich zunächst einmal die Prinzipien von Least Privilege und eines Separation-Kernels anzusehen.

Artikelfiles und Artikellinks

(ID:44602403)