bereitgestellt

Treffen: Fahrzeug-Initiative RLP
Embedded Systeme im Automobil:
Architekturen, Security und Virtualisierung
Manuel Duque-Antón
comlet Verteilte Systeme GmbH
4. Juni 2014
ITK Engineering AG
Rülzheim
1 von 50
• Die comlet GmbH bietet Dienstleistungen und Produkte im Bereich Embedded Systeme mit dem
Schwerpunkt Software an, im Einzelfall auch Hardware-Entwicklungen.
• Die comlet ist im Bereich Automotive gestartet und deckt mittlerweile andere Anwendungsbereiche
ab, wie z.B. Landwirtschaft oder Gebäude bzw. Heizungs-Management und vieles mehr.
• Unsere Erfahrungen zeigen, dass die abstrakten Problemstellungen und damit auch die geeigneten
Lösungen im Wesentlichen unabhängig vom konkreten Anwendungsbereich sind.
• Dabei spielt der Entwurf einer geeigneten Architektur eine zentrale Rolle. In diesem Vortrag wird am
Beispiel von Automotive dieser Sachverhalt erläutert.
• Da keine Kunden-Details verraten werden können, werden die Ausführungen am Beispiel der
bekannten AUTOSAR-Architektur erläutert werden.
• Natürlich spielt beim Entwurf einer geeigneten Architektur der Aspekt der Security (Datensicherheit)
eine immer wichtiger werdende Rolle. An Hand einiger Fallbeispiele werden die relevanten Sicherheitsschwächen im Fahrzeug vorgestellt und entsprechende Abwehrrmaßnahmen kurz skizziert.
Neben den klassischen kryptographischen Ansätzen, spielt die Virtualisierung eine zentrale Rolle.
Beispiel eines Fahrzeug-Netzwerks
Lichtweitensteuerung.
Sitzsteuerung.
Komfort, Sicherheits- und
Karosseriebereich (CAN-B)
Antriebstrang (CAN-C)
Instrumente
Instrumente
Klimasteuerung
Türsstr.
links.
LIN - Bus
Sitzsteuerung.
Sonnendach.
Klimapanel
Scheibenwischer
Stand-By
Heizung
...
LIN - Bus
Airbag
Unterhaltung/Telematik (MOST)
Zentrale ECU
und Gateway
Multiflenkrad
Motorsteuerung
Multifdisplay
Getriebesteuerung
Telefon
Fahrzeugdynamik
Navigation
Parkabstandsstrg.
...
Fahrwerk (FlexRay)
Stellmotorsteuerung
Pedalsteuerung
Radknoten
hinten
Airbagzünder
Sensoren
...
3 von 50
• Das Kommunikations-Netzwerk in einem Automobil kann sehr unterschiedlich gestaltet sein. Mittlerweile kommen mehrere verschiedene Kommunikationsprotokolle zum Einsatz, und zwar das am
besten geeignete für die jeweilige Anwendung. Auf der Folie wird ein Beispiel für ein solches Netzwerk
gezeigt:
• Typisch ist der Einsatz des Low-Speed-CANs für Anwendungen, die nur wenig Bandbreite benötigen, wie z.B. für Tür, Klima- und Sitz-Steuerungen.
• Der High-Speed-CAN kommt bei Anwendungen mit einem höheren Bandbreitenbedarf zur Anwendung wie z.B. bei Motor-, Getriebe- und Fahrwerk-Steuerungen.
• LIN-Sub-Busse werden für Sitzverstellungen, die Klimasteuerung und für Spiegeleinstellungen eingesetzt.
• FlexRay wird bevorzugt im Fahrwerksbereich und im Antriebsstrang eingesetzt und ersetzt langfristig Lösungen mit mehreren CAN-Bussen bzw. wird neue Anwendungen dort ermöglichen. Allerdings kann man nicht sagen, dass sich FlexRay so recht durchsetzt. Möglicherweise wird FlexRay
durch zukünftige CAN-Standards mit höheren Bitraten ersetzt werden.
• MOST wird typischerweise zur Vernetzung und Bedienung von Entertainment-Komponenten im
Auto (Premiumklasse) eingesetzt.
• Was genau ist das Problem?
• Die Entwicklung von Software für Steuergeräte im Auto stellt einen enorm komplexen Prozess dar!
• Die Steuergeräte laufen auf verschiedenen Maschinen und Betriebssystemen, i.d.R. in unterschiedlichen Programmiersprachen geschrieben. Es gibt eine Vielzahl von Kommunikationsprotokollen, die insbesondere permanenten Veränderungen/Erweiterungen unterworfen sind.
Viele Funktionen ergeben sich erst aus dem Zusammenspiel mehrere Komponenten, die
möglicherweise von verschiedenen Lieferanten entwickelt wurden und vieles mehr.
Probleme / Herausforderungen
• Bisher erläutert:
• Beherrschung der Komplexität, gerade vor dem Hintergrund, dass Funktionali-
täten im Zusammenspiel von mehreren Komponenten geliefert werden.
• Vielfalt der angeschlossenen Geräte, Systeme, Kommunikationsprotokolle
beherrschen und vieles mehr.
• Es gibt aber auch weitere Herausforderungen:
• Hoher Kostendruck
• Flexibilität bzw. Erweiterbarkeit
• Security bzw. Datensicherheit
• Safety bzw. Testbarkeit
5 von 50
• Kostendruck:
• Automobile werden in sehr hohen Stückzahlen, über einen langen Zeitraum gefertigt. VW lieferte z.B.
2012 über 9 Millionen Fahrzeuge aus.
• Die tief eingebetteten Systeme wie Tür-, Licht- oder Motor-Steuergeräte werden vom Kunden nicht
als eigenständige Geräte wahrgenommen. Ein eventueller Mehrpreis für einen besonders innovative
Lösung läßt sich in einem Verkaufsgespräch nur schwer begründen.
• Erweiterbarkeit:
• Auch hier kann wieder das Volkswagen (Baukasten-Prinzip) als Beispiel herangezogen werden.
Eine entsprechende Architektur muss mit vielen über die Zeit erweiterbaren Varianten, die sich in
Details unterscheiden, aber in der Grundform ähneln, zurecht kommen.
• Datensicherheit:
• Durch die Öffnung der Entertainment-Systeme im Automobile, aber auch durch die Verwendung von
drahtlosen Kommunikationsprotokollen im Automobil (z.B. Reifensensor, der per Funk angeschlossen ist) wird das Auto zu einem offenen Systemen, welches nun von Außen angegriffen werden
kann.
• Testbarkeit:
• Generell kann Fehlerfreiheit nie zweifelsfrei garantiert werden. Alter Informatiker-Witz: „Ein fehlerfreies Software-System ist veraltet".
• Im Automotive-Fall ergeben sich häufig die Funktionalitäten aus dem Zusammenspiel mehrerer Komponenten. Wie soll eine Komponente getestet werden, wenn man nicht weiß, ob die
anderen Komponenten fehlerfrei sind.
• In der nächsten Folie wird diese Problematik etwas genauer untersucht!
Komplexität und Zuverlässigkeit
• Mit jedem neuen Teilsystem, also etwa funkgesteuerter Zentralverriegelung,
elektronischer Heckdeckelsteuerung etc. wächst die Fehlerwahrscheinlichkeit
für das Gesamtfahrzeug. Das ist ein statistisches Phänomen.
• Als Beispiel wird ein Fahrzeug mit nur einem einzigen Steuergerät s1 betrach-
tet.
• Falls die gefertigten Steuergeräte mit einer Wahrscheinlichkeit P (s1) pro Jahr
von 99,9% zuverlässig funktionieren,
• wäre jedes Jahr eins von 1000 Fahrzeugen in der Werkstatt.
• Würde in dieses Fahrzeug ein weiteres Steuergerät s2 eingebaut werden und
• hätte diese Gerät dieselbe Ausfallwahrscheinlichkeit, dann ergibt sich die
Gesamtwahrscheinlichkeit (zuverlässig zu arbeiten) mit dem Multiplikationssatz
P (s1)  P (s2) = 0,999  0,999 = 0,998001
• Damit wären pro Jahr schon zwei von 1000 Fahrzeugen in der Werkstatt,
obwohl die Qualität in der Fertigung gar nicht verändert wurde.
• Wie kann dieses Problem aufgefangen werden?
7 von 50
• Praktische Situation ist noch schlimmer: Die Zuverlässigkeit einer Komponente ist i.d.R. beim
ersten Integrationstest weit von 100% (Produktreife nach Ende der Entwicklungsphase) entfernt:
• Wenn wir also 10 Komponenten mit einer Zuverlässigkeit von immerhin 70% unterstellen ergibt sich
eine Gesamtwahrscheinlichkeit, dass alle 10 Komponenten beim ersten Integrationstest zuverlässig zusammenarbeiten von 0,710 = 0,028. Also unter 3%.
• Bei diesen Zahlen wäre es nahezu unmöglich, irgendwelche Schlüsse aus dem Integrationstest zu ziehen.
• Als Lösung kann
• die Zuverlässigkeit der einzelnen Komponenten erhöht werden. Das geht nur, wenn isolierte Komponententests möglich sind. Da aber die Korrektheit einer Komponente nur im Wechselspiel mit
den anderen Komponenten überprüft werden kann, muss dazu die Umgebung simuliert werden.
Dieser Vorgang wird auch Restbus-Simulation genannt.
• Die Anzahl der integrierten Komponenten wird kontinuierlich gesteigert. In einer typischen Schichtenarchitektur sollte die Integration schrittweise von unten nach oben erfolgen.
• Insgesamt zeigt sich, dass die Wahl einer geeigneten Architektur eine zentrale Rolle spielt, um
mit möglichst geringen Kosten aller geforderten Kriterien zu erfüllen.
• In diesem Zusammenhang spielt der Begriff des „Software-Bus“ eine zentrale Rolle, den ich im folgenden am Beispiel von AUTOSAR erläutern will.
Schlüssel-Technologie: Software-Bus
Component
A
Component
B
Container
Container
Software Bus
• Zugrundeliegende Technologie stammt aus der Theorie der „Verteilten Systeme",
bekannt unter dem Schlagwort „Komponenten Basierte Entwicklung".
• In unterschiedlichen Ausprägungen wird es unter anderem eingesetzt in:
• Java Enterprise Beans, aber auch
• Android Plattformen und AUTOSAR.
9 von 50
• Die Kernaufgabe eines Software-Busses ist die Realisierung von Transparenz:
• Der Anwendungs-Entwickler muß die Details des Systems, also die Details aller beteiligten Steuergeräte (ECU Electronic Control Unit) nicht kennen, um seine Software entwickeln zu können.
• Vielmehr wird die Anwendung auf einer rein funktionalen Ebene geschrieben und erst nachträglich
auf das Ziel-System mit Hilfe von Tools, im wesentlichen Software-Generatoren, abgebildet.
• Dieses Prinzip wurde im Zusammenhang der Verfeinerung von SW-Engineering-Methoden für Verteilte Systeme entwickelt. Das wesentliche Ziel ist es, die Anwendungs-Logik von der SystemLogik zu trennen.
•
Im AUTOSAR (AUTOmotive Open System Architecture) Kontext wird der Software-Bus VFB
(Virtual Functional Bus) genannt und
• trennt beispielsweise die Entwicklung einer Blinker-Anwendung von den Details des darunter liegenden Steuergeräts, wie z.B. das benutzte Betriebssystem aber auch das verwendete Kommunikationsprotokoll.
• Dieser Sachverhalt ist besonders wichtig, wenn man sich vor Augen führt, dass aktuelle Automobile
über Dutzende von Kontrolleinheiten, Tausende von Funktionen und zehntausende von
potentiellen Vernetzungsmöglichkeiten verfügen.
• Aus der Abbildung wird auch deutlich, dass die weitere Aspekte wie Erweiterbarkeit oder Testbarkeit
mit Hilfe des Software-Busses ebenfalls sehr leicht umgesetzt werden können:
• Um den Anspruch der Safety zu genügen, erlaubt der Bus eine sogenannte Restbus-Simulation.
Reale Komponenten können gegen virtuelle Komponenten getestet werden, die nur in Form
von Software (minimalistisch) realisiert sind.
AUTOSAR
Software
Component n
AUTOSAR
Software
Component 3
AUTOSAR
Software
Component 2
AUTOSAR
Software
Component 1
AUTOSAR: Virtual Functional Bus
Virtual Functional Bus
AUTOSAR
Software
Component 3
AUTOSAR
Software
Component 1
RTE
BSW
AUTOSAR
Software
Component 2
ECU b
ECU a
RTE
BSW
11 von 50
• Bei der technischen Umsetzung wird in AUTOSAR ein funktionelles und ein strukturelles Modell
unterschieden.
• In der oberen Abbildung auf der Folie wird das funktionelle Modell beschrieben, welches sich aus
Softwaremodulen zusammensetzt, die miteinander kommunizieren.
• Jedes Softwaremodul realisiert dabei eine Funktion.
• Die Kommunikation der Softwaremodule erfolgt ausschließlich über den Virtual Functional Bus
(VFB), der einen virtuellen Kommunikationskanal darstellt.
• Der VFB abstrahiert von der Hardware, so dass die Anwendung nach rein funktionalen Aspekten,
also Hardware-unabhängig, entworfen werden kann.
• Durch die standardisierte Schnittstelle (zum VFB) wird die Modularität und Wiederverwendbarkeit
garantiert.
• Während der Entwurf und die Entwicklung der Softwarekomponenten eine Domäne der einzelnen
Automobilhersteller und -Zulieferer ist und wohl bleiben wird, wird die Realisierung des VFB von den
Mitglieder-Unternehmen des AUTOSAR-Konsortiums gemeinsam angegangen.
AUTOSAR
Software
Component n
AUTOSAR
Software
Component 3
AUTOSAR
Software
Component 2
AUTOSAR
Software
Component 1
AUTOSAR: Run Time Environment
Virtual Functional Bus
ECU b
AUTOSAR
Software
Component 2
AUTOSAR
Software
Component 3
Anwendung
AUTOSAR
Software
Component 1
ECU a
Ports
AUTOSAR
Infrastruktur
RTE
RTE
BSW
BSW
Hardware
Physikalisches Bus-System
13 von 50
• In der unteren Abbildung wird das strukturelle Modell dargestellt. Beim Übergang vom rein funktionalen
Modell (obere Abbildung) zu einem strukturellen Modell (untere Abbildung) wird der VFB aufgelöst und
in Teilfunktionen zerlegt. Dieser Vorgang erfolgt Tool-gestützt, im Wesentlichen kommen hier
Software-Generatoren zum Einsatz.
• Die Softwaremodule werden einzelnen ECUs zugeordnet, der VFB wird in das Real Time Environment (RTE), die Basic Software (BSW) und die Kommunikation zwischen den ECUs aufgeteilt.
• Das RTE stellt dabei eine Laufzeit-Implementierung des VFB dar und zwar in einer konkreten ECU.
• Die Schnittstelle für die Softwaremodule bleibt aber gleich. Sie kommunizieren nur mit dem RTE
über eine standardisierte Schnittstelle.
• Der Anwendungs-Entwickler schreibt seinen Code unabhängig vom Target Steuergerät bzw.
unabhängig von der Konfiguration aller Steuergeräte. Auf einem Steuergerät können wie in der
Abbildung ersichtlich auch mehrere SW-Komponenten laufen.
• Der Informationsaustausch zwischen den SW-Komponenten erfolgt über Ports, welche die Schnittstellen zu den Kommunikationspfaden darstellen. Die Ports sind Teil der Architektur. Die eigentliche
Codierung der SW-Komponenten liegt außerhalb des AUTOSAR-Standards.
• Die Laufzeitumgebung RTE und BSW werden automatisch generiert und zwar in Abhängigkeit der
System-Konfiguration, die der Entwickler angibt (welche SW-Komponente soll auf welches Steuergerät gelegt werden)
• Die Abstraktion von der HW und der Kommunikation zwischen den ECUs erfolgt also mit Hilfe der
Software-Generatoren, die RTE und BSW auf der Basis der Ziel-Konfiguration erzeugen. Empfängt
eine Softwarekomponente Informationen von einer anderen Softwarekomponente, macht es funktional keinen Unterschied, ob diese Softwarekomponente in der gleichen ECU läuft oder nicht.
AUTOSAR - Architektur
RTE
Basissoftware
Service Layer
ECU Abstraction Layer
Complex
Drivers
Microcontroller Abstraction Layer
ECU Hardware
15 von 50
• AUTOSAR verwendet das bekannte Schichtenmodell, Diese Schichten haben die Aufgabe, verschiedene HW-Aspekte wie Prozessoreigenschaften, Eigenschaften des Steuergerätes selbst oder der
Sensoren/Aktoren auch in Software zu trennen.
• Die oberste Schicht eines Steuergerätesoftware-Stacks bildet die Anwendungssoftware und enthält
neben den eigentlichen Anwendungssoftware-Komponenten auch die Sensor/Aktor-SoftwareKomponenten. Sie ist auf der Folie zuvor dargestellt.
• Die RTE liegt zwischen Anwendungssoftware und Basissoftware und stellt die Implementierung der
VFB-Extrakte je Steuergerät dar. Die RTE wird also für jede ECU spezifisch generiert. Werden
Anwendungen zwischen Steuergeräten verschoben, ändert sich die Systemsicht und damit der VFB,
was eine Neu-Generierung der RTEs der betroffenen Steuergeräte zur Folge hat.
• Innerhalb der Basissoftware bietet der Service Layer den Anwendungen und anderen BasissoftwareModulen grundlegende Dienste an wie beispielsweise: Betriebssystem-, Speicherverwaltungs-,
Diagnose- und Kommunikationsfunktionen.
• Der ECU Abstraction Layer dient der Abstraktion der Steuergeräte-spezifischen Eigenschaften. Zum
Beispiel kann damit von Anzahl der verbauten CAN-Controller und deren genauen Ort (on-chip/onboard) auf dem Steuergerät abstrahiert werden.
• Der Microcontroller Abstraction Layer abstrahiert vom Microcontroller. Dies umfaßt die
Konfiguration und Initialisierung des Microcontrollers und integrierter Geräte.
• Die Schicht der Complex Drivers durchschneidet alle Schichten der Basissoftware. Beispielsweise
zum Ansteuern und Verwalten von Sensoren, bei denen die Software aus Zeitgründen direkt auf die
Hardware zugreifen muss.
Beispiel: Warnblinkfunktion aus VFB-Sicht
Anwendungsebene
BlinkgeschwindigkeitsKalibrierung
adjustFrequency
adjustFrequency
setLight
takeStatus
StateRequest
crtlLamp
setLight
BlinkleuchteHintenRechts
WarnblinkTaster
giveStatus
BlinkleuchteHintenLinks
BlinkergeberAnwendung
currentState
setLight
crtlLamp
BasisSoftware
StateRequest
currentState
crtlLamp6
crtlLamp9
ECU State Manager
(EcuM)
I/O Hardware Abstraction
(IoHwA)
DIO Driver
17 von 50
• Der AUTOSAR-Standard gibt im Grunde nur Kommunikations-Beziehungen und Strukturen vor
und überläßt die eigentliche Programmierung (i.d.R. in der Programmiersprache C) den Anwendungs-Entwicklern. Dieser Sachverhalt soll an Hand einer einfachen Blinkgeber-Anwendung erläutert werden. Dazu aber vorher ein paar generelle Notationen:
• Generell unterscheidet AUTOSAR atomare SW-Komponenten (Rechtecke), zusammengesetzte
SW-Komponenten (oben 3 Quadrate) und Sensor/Aktor-Komponenten (oben Pfeil).
• Die Kommunikationsbeziehungen werden mit Hilfe von Ports beschrieben, kleine Quadrate mit
unterschiedlichen Inhalten an den Grenzen der Rechtecke.
• Es gibt Ports für die Kommunikation von Anwendungen untereinander, für die Kalibrierung
(Kalilbrierungswerte bereitzustellen oder auszulesen) und Servicemodule der BSW stellen über
diese Ports ihre Funktionen anderen Softwarekomponenten zur Verfügung.
• In den Bereichen Anwendungssoftware und AUTOSAR-Service stehen die beiden Arten von Kommunikationsmechanismen Sender/Receiver (nur Daten austauschen) und Client/Server (Funktionen aufrufen inklusive Datenaustausch) zur Verfügung.
Beispiel: Warnblinkfunktion aus VFB-Sicht
Anwendungsebene
BlinkgeschwindigkeitsKalibrierung
adjustFrequency
adjustFrequency
setLight
takeStatus
StateRequest
crtlLamp
setLight
BlinkleuchteHintenRechts
WarnblinkTaster
giveStatus
BlinkleuchteHintenLinks
BlinkergeberAnwendung
currentState
setLight
crtlLamp
BasisSoftware
StateRequest
currentState
crtlLamp6
crtlLamp9
ECU State Manager
(EcuM)
I/O Hardware Abstraction
(IoHwA)
DIO Driver
19 von 50
•
Die Anwendung erhält auf der „linken Seite" Input von einer Kalibrierungskomponente, die einen
Faktor für die Abstimmung der Blinkgeschwindigkeit liefert, und von einer SensorSoftwarekomponente, die eine Nachricht schickt, wenn sich der Zustand des Warnblinktasters
ändert.
• Auf der „rechten Seite" sendet sie eine Nachricht mit dem gewünschten Blinkleuchten-Zustand („an“
oder „aus“). Diese Nachricht wird von den beiden Aktor-Komponenten BlinkleuchteHintenLinks und
BlinkleuchteHintenRechts empfangen. Die beiden Aktoren stehen hier stellvertretend für die Vielzahl
der eigentlichen Aktoren wie „vorne“ und „seitlich“.
• Die Blinkleuchten-Aktoren nutzen ein C/S-Interface, um mittels I/O-Hardware-Abstraktion gezielt die
Lampenausgänge der ECU zu aktivieren/deaktivieren. Hierbei ist es typisch, dass die I/O-HWAbstraktion ihre Funktionen über Server-Ports bereitstellt.
• Die Blinkgeber-Anwendung nutzt in diesem Fall zwei Services des Basissoftwaremoduls ECU State
Manager, und zwar currentState zur Abfrage des aktuellen Status der ECU und StateRequest, um den
benötigten RunMode der ECU anzufordern.
Was ist mit Sicherheit?
• Der Begriff der Sicherheit ist im Deutschen nicht eindeutig festgelegt:
• Der englische Begriff Security „beschäftigt“ sich mit dem Schutz gegen böswil-
lige Manipulationen.
• Der englische Begriff Safety hat den Schutz gegen technische Ausfälle im
Fokus.
• Der Aspekt der Safety (funktionale Sicherheit) kann bereits mit Hilfe einer „geeig-
neten“ Architektur (z.B. Rest-Bus-Simulation) angegangen werden und muss
natürlich um die entsprechende Aspekte systematischer Tests erweitert werden.
• Der Aspekt der Security (Datensicherheit) wird im Umfeld automobiler Kommuni-
kationssysteme immer noch eher stiefmütterlich behandelt im Gegensatz zu anderen Bereichen wie dem Finanzgewerbe, in dem schon immer sehr viel Wert auf
angemessene Sicherheitsmaßnahmen gelegt wurde.
• In den meisten Fahrzeugen, aber auch in Flugzeugen, wird noch immer der CAN-
Bus verwendet. Der Zugriff auf den Bus ist meist sehr einfach, ungesichert und
leicht auszulesen. Kontrollen gegen unrechtmäßigen Zugriff oder Ähnliches gibt es
nicht.
21 von 50
• So ist es nicht verwunderlich, dass die CAN-Sicherheitslücken dazu verwendet werden, um z.B.
• durch Manipulationen an den CAN-Bus-Nachrichten eine Leistungssteigerung zu implementieren,
• Wegfahrsperren auszuschalten oder
• die Laufleistung und andere Fahrzeugfunktionen zu manipulieren.
•
So kann bzw. konnte man bis vor kurzem CAN-Bus-Module erwerben, die an die OBD (On Board
Diagnose) 2 Schnittstelle angeschlossen werden können (einfach aufgesteckt), die vornehmlich für
GM-Fahrzeuge verfügbar sind.
• Damit kann man die Funktionen des Fahrzeugs erweitern, z.B. um ein adaptives Bremslicht oder
Alarmanlagensimulation etc. Siehe auch www.happyligthschow.de bzw. .com)
•
Der Nachfolger von CAN (der im Übrigen sich nicht so recht durchsetzen kann) FlexRay besitzt
ebenfalls keine Sicherheitsmechanismen.
•
Den einzigen Schutz, den bisher Hersteller verwenden, besteht darin, die CAN-NachrichtenIdentifier geheim zu halten und den Zugriff zum Fahrzeug zu erschweren. Allerdings hat auch
hier das Gesetz von Moore zugeschlagen, und es sind billige Zugriffsvarianten über Funk (Bluetooth)
oder gar über Reifendruckkontrollsysteme (TPMS) verfügbar, die i.d.R. schlecht abgesichert sind.
Angriffspunkte
• Bevor die konkreten Bedrohungsmodelle vorgestellt und die entsprechenden
Abwehrmechanismen erläutert werden, sollte die Frage geklärt werden, wie ein
Hacker überhaupt ein eingebettetes System infiltrieren kann.
• Generell lassen sich die Zugänge zu eingebetteten Systemen im allgemeinen und
Automotive im Speziellen in die folgenden drei Kategorien einteilen: Indirekter physischer Zugang, Kurzstrecken- und Langstrecken-Zugang.
• Beim indirekten physischer Zugang unterscheidet man OBD-II Schnittstelle,
Infotainment-Geräte und zukünftig wohl auch Ladekabel.
• Der Langstrecken-Zugang zerfällt in den Rundfunk-Bereich (Broadcast Kanäle)
und in die adressierbaren Kanäle (z.B. UMTS).
• Beim Kurzstrecken-Zugang stellen Bluetooth, Keyless Entry-Systeme, Reifen-
drucksensoren und RFID Wegfahrsperren wichtige Kandidaten dar.
23 von 50
• Indirekter physischer Zugang
• OBD-II ist derzeit wichtigste Schnittstelle bei modernen Automobilen, die ursprünglich zur Überwachung aller abgassbeeinflussenden Systeme diente und in den USA entwickelt wurde. Schnittstelle
wurde schnell weiterentwickelt und bietet im Grunde einen direkten Zugriff auf alle wichtigen CANBussysteme und um insbesondere Fehlerspeicher auszulesen. Zum Anschluß eines Notebooks an
OBD-II wird ein „PassThru“-Gerät angeboten, welche auch die Programmierung der Steuergeräte
erlauben. Diese Geräte sind teilweise bei eBay käuflich. Durch Kompromittierung des Notebooks,
kann Schadsoftware auf Steuergerät gelangen.
• Andere Zugriffsmöglichkeit besteht über Schnittstellen (USB, CD/DVD, SD-Karten etc.) des Infotainment-Systems. Über diese Schnittstelle sind ebenfalls Angriffe denkbar. Zum Beispiel könnte mit
Hilfe der CD/SD eine speziell präparierte Datei abgespielt werden, welche die Software flasht, also
ein schadhaftes Update erzeugt. Da die Infotainment-Systeme über Gateway mit CAN-Segmenten
verbunden sind, könnten auf diese Weise auch Angriffe auf CAN produziert werden.
• Um die Ladestation zu informieren, wann ein Fahrzeug vollständig geladen ist, muss diese mit dem
Ladesteuergerät über das Ladekabel in Kontakt stehen. Möglicherweise geschieht das auch über
den CAN-Bus.
• Langstrecken-Funkzugang
• Moderne Fahrzeuge haben eine Fülle solcher Broadcast-Kanäle wie GPS, DAB, RDS und TMC,
die alle für gewöhnlich via Entertainmentsystem mit CAN-Bus verbunden sind. Der Vorteil für
Angreifer ist, dass Angriffe nur schwer zuzuordnen sind, mehrere Empfänger erreichbar sind und
keine Adressierung der Opfer notwendig ist.
• Die größte Angriffsfläche bieten Funkzugänge, die über lange Strecken adressierbar sind (z.B. Telematik-Systeme). Solche Systeme haben eine ständige Verbindung zu einem Telefonanbieter mit
Internetzugang (z.B. UMTS). In Holland wurde 2011 iPhones mit jailbreak gehackt.
Angriffspunkte
• Bevor die konkreten Bedrohungsmodelle vorgestellt und die entsprechenden
Abwehrmechanismen erläutert werden, sollte die Frage geklärt werden, wie ein
Hacker überhaupt ein eingebettetes System infiltrieren kann.
• Generell lassen sich die Zugänge zu eingebetteten Systemen im allgemeinen und
Automotive im Speziellen in die folgenden drei Kategorien einteilen: Indirekter physischer Zugang, Kurzstrecken- und Langstrecken-Zugang.
• Beim indirekten physischer Zugang unterscheidet man OBD-II Schnittstelle,
Infotainment-Geräte und zukünftig wohl auch Ladekabel.
• Der Langstrecken-Zugang zerfällt in den Rundfunk-Bereich (Broadcast Kanäle)
und in die adressierbaren Kanäle (z.B. UMTS).
• Beim Kurzstrecken-Zugang stellen Bluetooth, Keyless Entry-Systeme, Reifen-
drucksensoren und RFID Wegfahrsperren wichtige Kandidaten dar.
25 von 50
• Kurzstrecken-Funkzugang
• Mit Bluetooth hat sich ein de-facto Standard für Freisprecheinrichungen etabliert, der immer mehr
den Weg in Kleinwagen findet.
• Viele der Fahrzeuge aus der Premiumklasse bieten heute keyless entry-Systeme an, die ein weiteres Einfallstor ins Fahrzeugnetzwerk bieten (via Relay-Station Attack).
• In den USA seit 2007 Vorschrift sind Reifendrucksensoren, welche die Aufgabe haben, den Fahrer
vor einem Platten bzw. undichten Reifen rechtzeitig zu warnen. Die entsprechenden Sensordaten
werden auf derselben Frequenz wie bei den Keyless-Entry-Systeme übertragen: 433 MHz (EUR)
und 315 MHz (USA).
• Mittlerweile serienmäßig vorhanden sind RFID Technologie basierte Wegfahrsperren. Im Fahrzeugschlüssel ist dazu ein Transponder und im Fahrzeug in der Nähe des Zündschlosses ein Empfangssystem verbaut. Ohne den richtigen Transponder in der Nähe, wird zuverlässig verhindert,
dass das Fahrzeug gestartet werden kann.
Wie geht ein Hacker vor?
• Während ein System-Designer bei der Suche nach Schwächen die Architektur und
die verwendeten Kommunikationsprotokolle im Fokus hat, wählen Cracker oft
einen pragmatischen Weg, der im Wesentlichen auf den folgenden drei Schritten
basiert:
• Pakete abhören und gezielt sondieren!
• Fuzzing!
• Reverse Engineering!
27 von 50
• Der erste Schritt ist das Belauschen der Kommunikationsverbindung mit dem Ziel die Kommunikation
zwischen den einzelnen Clients zu verstehen und für seine Zwecke zu benutzen. Besonders hilfreich
ist das Auslösen verschiedener Events und Nachrichten und die Beobachtung der Kommunikation
währenddessen. So kann schnell eruiert werden, welcher Befehl für welche Aktion verwendet wird.
• Wenn man nur Schaden anrichten möchte, ist kein oder zumindest kein vollständiges Verständnis der
Kommunikation und der verfügbaren Teilnehmer notwendig. Beispielsweise ist die Anzahl der
gültigen CAN-Bus-Nachrichten beschränkt. Zufällig gewählte Nachrichten können in die
Kommunikation eingebracht werden und anschließend die Effekte beobachtet werden und
entsprechende Korrelationen über das Wirkprinzip erstellt werden.
•
Der anspruchsvollste Weg einen Schaden zu produzieren, besteht im Rahmen eines Reverse
Engineerings. Dabei wird versucht, den Speicher einer Komponente, oder den gesamten
Nachrichtenfluss zu lesen und anschließend zu verstehen. Dieses Vorgehen ist dann notwendig,
wenn neue Funktionalität hinzugefügt oder existierende manipuliert werden soll.
Lücken in der Software
• Heutige Fahrzeuge haben
• eine Vielzahl an vernetzten eingebetteten Systemen, die sehr eng zusammenar-
beiten müssen.
• Die oft sehr komplexe Software kann aus Zeit- und Kostengründen daher nicht
fehlerfrei sein und ist auch nur rudimentär gesichert.
• Der Fokus der Hersteller liegt eher auf Safety und weniger auf Security.
• Das Ziel der Angreifer ist es, geheime Informationen der Software zu entlocken
(Spionage) oder nicht autorisierte Schadsoftware zu installieren. Dabei werden
die folgenden Lücken ausgenutzt:
• Fehlerhafte Implementierung.
• Software-Updates bzw. das Aktivieren neuer Funktionen.
• Speicherort der Software.
29 von 50
• Heutige Systeme bestehen aus mehrere Dutzenden Steuergeräten, Tausende Funktionalitäten
und Zehntausende Vernetzungsmöglichkeiten.
• Fehlerhafte Implementierung:
• Häufige Fehler ergeben sich über sogenannte Buffer Overflows oder eine schlecht gewählte Architektur. Allerdings sind Buffer Overflow im Bereich der eingebetteten Systeme seltener auf Grund
der verwendeten Harward-Architektur, die im Gegensatz zur von Neumann-Architektur zwei
getrennte Speicher für Befehle und Daten verwendet. Bei der von Neumann-Architektur kann durch
einen Buffer Overflow in einen Datenbereich gesprungen werden, der schadhafte Befehle codiert.
Daneben gibt es aber noch eine Fülle an anderen typischen Fehlern, wie die Verwendung unsicherer kryptographischer Algorithmen, einen fehlerhaften Update-Prozess, Protokollfehler, Fehler bei
der Verwaltung der Schlüssel, Verwendung schlechter Zufallszahlengenerator, Umgehung von
Sicherheitsmaßnahmen durch eine möglicherweise implementierten Debug-Modus, fehlerhafte
Implementierung von Algorithmen --> Eigentliche alle Bestandteile können betroffen sein.
•
Zum Software-Update
• muss einfach nach Außen ein entsprechender Updatekanal angeboten werden, der i.d.R. nicht hinreichend gesichert sein kann.
• Ein weitere Verwundbarkeit stellt der Speicherort der Software dar.
• Diese ist meistens auf Speicherchips abgelegt, die von der Platine genommen und mit speziellen
Equipment gelesen werden können. Eine komplette Verschlüsselung der Software hilft nicht so
sehr, wie man gerne glauben würde, da die Software zur Ausführung entschlüsselt und dann entsprechend gelesen werden kann. Zudem werden oft geheime Schlüssel oft ungeschützt im Speicher abgelegt.
Lücken in der Buskommunikation: CAN
• Das CAN-Bus-Protokoll sieht keinerlei Verschlüsselung der Bus-Nachrichten
vor:
• Angreifer kann also problemlos Nachrichten abhören und Inhalt erfahren.
• Da zum Versenden kein Schlüssel benötigt wird, kann Angreifer ebenfalls ohne
Schwierigkeiten eigene (schadhafte) Nachrichten versenden.
• Da CAN-Bus auf CSMA/CA (unter Verwendung von Nachrichten-Prioritäten)
basiert, sind Denial of Service Angriffe problemlos möglich.
• In CAN-Nachrichten sind keine Felder für eine Authentifizierung oder Absender-
erkennung vorgesehen.
• Die in CAN-Bus verwendete Fehlerbehandlungsstrategie, welche bei der Fehler-
behandlung sehr effektiv ist, kann von Angreifer mißbraucht werden.
• Einige Beispiele: Tachometerrückstellung (häufig praktiziert, eher harmlos),
HappyLigthShow (CAN-Bus-Modul, welches auf OBD-II Port gesteckt wird),
Chiptuning (häufig praktiziert zur Leistungssteigerung), Komponentensimulation (Vorhandensein einer fehlenden Komponente z.B. Airbag vortäuschen) und
Schlüssel-Klonen (via OBD-Port, der ständig mit Strom versorgt wird).
31 von 50
• Da CAN im Wesentlichen Broadcast-Mechanismus (CSMA/CA) verwendet, kann Angreifer alle
Nachrichten im Bus mitlesen. Dazu kann man z.B. günstigen USB-to-CAN Adapter und Tool CarShark
verwenden. Damit können auch beliebige Nachrichten auf den Bus geschrieben werden.
• Denial of Service-Attacke: Angreifer versucht sich als Nachricht mit der höchsten Priorität auszugeben
und legt damit das gesamte Netz lahm.
• Wegen der fehlender Authentifizierung kann jede Komponente an eine andere Komponente eine
beliebige Nachricht senden, die z.B. Fehlinformationen enthält und zu einem dauerhaften
Fehlverhalten auf dem Bus führt.
• Falls im CAN-Bus Fehler (fehlerhafte Nachricht) entdeckt wird, werden über ein Error-Flag andere
Komponenten informiert, die in Schlaf-Modus wechseln. Auf diese Weise wird der aktuelle
Datenverkehr unterbrochen und erst nach einer gewissen Zeit wieder gestartet. Ein Angreifer kann
durch das systematische Aussenden solcher Fehler-Flags ebenfalls den Bus lahm legen.
• Beispiele sind aus Presse oder aus experimentellen Analysen. OEMs halten sich hier sehr bedeckt.
• Tachometerrückstellung: Auf tachoteam.de wird diese Dienstleistung offiziell beworben.
• HappyLightShow.de bzw. .com: Vornehmlich für GM-Fahrzeuge, um Funktionalitäten des Fahrzeugs zu erweitern, wie Bremslichter, spezielle Warnblicklichter, wenn Kofferraum geöffnet wird und
vieles mehr.
• Chiptuning: Nicht nur Leistungssteigerung auch günstigeren Verbrauch. Im einfachsten Fall wird
die Programmierung der kompletten Steuergeräte-Software vorgenommen (statt Austausch ECU).
• Komponentensimulation: So kann per Reverse Engineering Nachrichtenfluss ermittelt werden.
• Schlüssel-Klonen: OBD-Port besitzt CAN-Bus-Anschluß, in 3 Minuten kann so mit Hilfe einer Software neuer Schlüssel generiert werden. Wegfahrsperre muss nicht umgangen werden.
Lücken in der Buskommunikation: LIN, FlexRay und MOST
• LIN-Bus ist ein (kleiner) Subbus zur Kommunikation mit intelligenten Sensoren und
Aktoren und wird eingesetzt, wenn CAN über dimensioniert ist.
• LIN arbeitet ebenfalls ohne Verschlüsselung, verwendet Broadcast aber keine
Authentifizierung. Das Power Management kann prinzipiell vom Angreifer mißbraucht werden.
• Allerdings sind bisher keine direkten Angriffe auf den LIN-Bus aus der Presse
bekannt.
• Die Sicherheitslücken sind im Falle von FlexRay ähnlich zu bewerten. Auch hier
sind keine Angriffe aus der Presse bekannt.
• Der MOST-Bus ist ebenfalls im Vergleich zum CAN-Bus ein seltener Angriffspunkt.
• Das könnte daran liegen, dass MOST nicht so leicht zugänglich ist und passende
Geräte zum Zugriff recht teuer sind.
• Zudem wird dieser Entertainment-Bus nur in den Fahrzeugen der Premium-
Klasse eingesetzt.
• MOST bietet allerdings im Bereich von Content Protection Sicherheits-Features
an.
33 von 50
• LIN-Bus hat ähnliche Sicherheitslücken wie der CAN-Bus.
• Im Power-Management kann bei Bedarf in Energiesparmodus gewechselt werden, was von einem
Angreifer mißbraucht werden könnte.
• Möglicherweise ist LIN-Bus für Angreifer nicht interessant, da er nur sehr gering Bandbreite hat und
eher unkritische Aufgaben übernimmt.
• FlexRay war als Nachfolger für CAN gedacht, setzt sich aus meiner Sicht allerdings nicht so gut durch.
• Eine genau Studie von MOST zeigt im Grunde ähnliche Sicherheitslücken wie die anderen BusSysteme, lediglich mit dem Unterschied:
• dass hier der Content geschützt werden kann.
• MOST-Bus verfügt über M6- und AES-128 Verschlüsselungstechniken für DTCP (Digital Transmission Content Protection), die eine Voraussetzung zur Übertragung von HQ (High Quality) Audio
und Video- Signalen darstellt. Die Umsetzung weiterer Sicherheitsaspekte ist optional (kann also
der Anwendungsprogrammierer entscheiden). Jeder verschlüsselten Datenübertragung geht ein
AKE (Authentification and Key Exchange) voraus.
Lücken in der Funkkommunikation
• Die drahtlose Kommunikation mit eingebetteten Systemen wird durch den techni-
schen Fortschritt immer wichtiger und stellt einen möglichen Angriffspunkt dar.
• Die folgenden Techniken stellen entsprechende Beispiele dar:
• Bluetooth
• Funkschlüssel (Keyless Entry-Systeme)
• Reifendruckmessung (Tire Presure Monitoring System: TPMS)
• Internet-Kommunikation
• Obwohl
einige dieser Varianten krytographische Sicherheitsmaßnahmen
anwenden, sind sie doch häufig Ziel einiger erfolgreicher Angriffe.
• So stellen beispielsweise Wegfahrsperren oder ganz allgemein Keyless Entry-
Systeme eine der ältesten Anwendungsgebiete der Kryptographie in Fahrzeugen dar und wurden bereits erfolgreich gebrochen.
35 von 50
• Aus Zeitgründen werden die entsprechenden Details nicht weiter beleuchtet. Es sei nur erwähnt, dass
gerade im Bereich Bluetooth sehr viele Schwächen vorliegen und einige Angriffe bekannt sind.
• Car Whisperer: Dieses Tool wurde von europäischen Forschern entwickelt mit dem Ziel alle Beteiligten zu sensibilisieren, insbesondere die Hersteller von Bluetooth-Geräten. Da nahezu immer die
Standard-PIN-Codes 0000 oder 1234 verwendet werden. Die „Schad-Software“ versucht mit Hilfe
dieser Codes mit erreichbaren Audio-Geräten eine Verbindung aufzubauen und kann anschließend
über Mikrofon die Kommunikation im Fahrzeug belauschen.
• Der wohl berühmteste Angriff BlueSnarf nutzt eine Lücke in speziellen Profil OPP (OBEX Push Profile) aus, welches üblicherweise dazu verwendet wird, Visitenkarten oder andere Dateien auszutauschen. Da keine Authentifikation benötigt wird, kann ein Angreifer sich problemlos mit dem Gerät
verbinden. Mit Hilfe eines OBEX-GET-Befehls kann auf bestimmte Dateinamen zugegriffen werden.
Auf Grund fehlerhafter Gerätefirmware kann beim Zugriff auf bestimmte Dateinamen wie z.B. telecom/pb.vcf auf den Kalender oder das Telefonbuch zugegriffen werden.
• Keyless Entry Systeme basieren auf einem sogenannten Challenge-Response Verfahren.
• Challenge-Response Verfahren setzt auf den Austausch eines Zufallswerts, der mit einem
gemeinsam bekannten Schlüssel verschlüsselt wieder an das Fahrzeug gesendet wird.
• 2008 gelang es einer der bisherigen als sicher gekannten Verfahren (KeeLoq) zu brechen. Man
muss wissen, dass KeeLoq in nahezu allen Fahrzeugen und Garagentoröffnern in Europa und USA
eingesetzt wird. Bei Fahrzeugen wird diese Technik zur Öffnung von Türen und zur Realisierung
von Wegfahrsperren eingesetzt. Praktische Informationen zur Durchführung sind nicht bekannt (Via
Sidechannel-Angriff gelang es den Mastercode des Herstellers auszulesen)
• Viele eingebettete Systeme bieten mittlerweile WLAN oder UMTS Zugang an. In diesem Fall ist das
Fahrzeug mit einem Schlag dem riesigen Bedrohungspotential ausgeliefert, der im Internet aktuell gilt.
Sicherheits-Mechanismen
• Grundlegend bei der Umsetzung von Sicherheitsmaßnahmen ist, dass ein System
weiß, wer ein Nutzer ist, um zu entscheiden zu können, ob er über ausreichende
Rechte für eine gewählte Aktion verfügt.
• Das Thema Umsetzung von Sicherheit ist sehr vielschichtig und kann hier nur grob
angerissen werden. Die wichtigen Themen in diesem Bereich betreffen:
• Kryptographie ist Technik zur Verschlüsselung von Informationen. Die Sicher-
heit der Kryptographie basiert auf Geheimhaltung der Schlüssel und nicht der
Algorithmen.
• Firewall kontrolliert (separiert) den Datenverkehr zwischen verschiedenen Berei-
chen.
• Antivirenprogramme versuchen das Vorhandensein oder die Aktivität von
Schadprogrammen im System zu erkennen bzw. zu unterbinden.
• Zugriffskontrolle verwendet im Wesentlichen eine Zugriffsmatrix, die in tabella-
rischer Form die Rechte von zu schützenden Objekten, den zu nutzenden Subjekten zuordnet.
• Gefängnisse und Sandkästen
37 von 50
•
Wenn System von Beginn an nach dem oben beschrieben Prinzip entwickelt würden, dann
gäbe es viele Sicherheitsprobleme nicht. Häufig wird Sicherheit erst im Nachhinein konzipiert
und realisiert, so dass die grundlegende Sicherheitsproblematik bestehen bleibt.
•
Bei der Kryptographie unterscheidet man verschiedene Schutzziele und verschiedene Realisierungsvarianten:
• Man unterscheidet die Schutzziele „Unleserlich machen", „Daten-Integrität“ und „Absender-Authentizität“ (Digitale Signatur).
• Bei der Realisierung unterscheidet man symmetrische Varianten (1 Schlüssel: sehr schnell) und
asymmetrische Varianten (privater und öffentlicher Schlüssel: langsamer).
• Daneben gibt es auch Hashfunktionen, welche zur Optimierung eingesetzt werden. Um den Aufwand zu reduzieren, ein sehr großes Dokument zu unterschreiben, wird zunächst das Dokument
mit Hilfe einer Hash-Funktion (so was wie eine Quersumme) verkleinert und anschließend unterschrieben.
• Im einfachsten Fall kann eine Firewall wie ein Internet-Router interpretiert werden, welcher zusätzlich
mit Hilfe von Regeln, Pakete blockiert oder durchläßt, dem sogenannten Paket-Filter.
• Ein guter Paket-Filter verfügt über Gedächtnis, kennt also das entsprechende Kommunikationsprotokoll.
• Intrusion Detection Systeme bzw. Intrusion Reaction Systeme verwenden zusätzlich VerkehrsMuster, um aus bekannten Muster, Angriffe ableiten zu können.
Sicherheits-Mechanismen
• Grundlegend bei der Umsetzung von Sicherheitsmaßnahmen ist, dass ein System
weiß, wer ein Nutzer ist, um zu entscheiden zu können, ob er über ausreichende
Rechte für eine gewählte Aktion verfügt.
• Das Thema Umsetzung von Sicherheit ist sehr vielschichtig und kann hier nur grob
angerissen werden. Die wichtigen Themen in diesem Bereich betreffen:
• Kryptographie ist Technik zur Verschlüsselung von Informationen. Die Sicher-
heit der Kryptographie basiert auf Geheimhaltung der Schlüssel und nicht der
Algorithmen.
• Firewall kontrolliert (separiert) den Datenverkehr zwischen verschiedenen Berei-
chen.
• Antivirenprogramme versuchen das Vorhandensein oder die Aktivität von
Schadprogrammen im System zu erkennen bzw. zu unterbinden.
• Zugriffskontrolle verwendet im Wesentlichen eine Zugriffsmatrix, die in tabella-
rischer Form die Rechte von zu schützenden Objekten, die zu nutzende Subjekte zuordnet.
• Gefängnisse und Sandkästen
39 von 50
•
Antivirenprogramme untersuchen Dateien und Hauptspeicher nach Schädlingen (Rootkits,
Spyware, Trojaner etc.).
• Dabei werden Signaturen bekannter Schädlinge verwendet oder Codesequenzen mit heuristischen
Verfahren auf ein Schadpotential hin untersucht.
• Einige Variante untersuchen Metadaten und zwar werden die dynamische Daten analysiert. Es wird
also nicht der Programmcode untersucht, sondern das Verhaltensmuster der Anwendung zur Laufzeit wie Datei- oder Netzwerkzugriffe.
• Bei der Zugriffskontrolle stellen Dateien, Geräte oder Prozesse typische Objekte dar und User oder
Gruppen typische Subjekte. Es geht darum, die entsprechenden gültigen Rechte zu erfassen und zu
kontrollieren.
• Gefängnisse und Sandkäste
• Bei dem Jailing (Gefängnisse) genannten Verfahren wird ein vertrauenswürdiger Prozeß eingesetzt, um einen anderen Prozeß zu beobachten und im Bedarfsfall einzuschreiten. Immer wenn der
Gefangenenprozeß einen Systemaufruf tätigt, wird der Wärter aktiv und entscheidet, ob er diesen
Aufruf zuläßt oder unterbindet. Das Maß an Sicherheit liegt am Wissen des Wärters über schadhaftes Verhalten.
• Das Sandboxing (Sankasten) Verfahren erzeugt für potentiell gefährliche Prozesse oder zu Testzwecken eine isolierte Umgebung, den Sandkasten. Um das System gegenüber der im System laufenden Anwendung zu schützen, werden Zugriffe von dort unterbunden, reglementiert oder auf
ungefährliche Bereiche umgeleitet.
• Die technische Umsetzung dieser Sicherheitskonzepte findet mit Hilfe von Virtualisierungskonzepten statt.
Was sollte im Fahrzeug eingesetzt werden?
• Wie bisher erläutert, wurden in der Vergangenheit in Fahrzeugen Sicherheitsme-
chanismen eher selten eingesetzt.
• Einige Bereiche werden bereits gesichert, wie z.B. die Keyless Entry Systeme,
aber auch die Versionsverwaltung (Updates der Steuergeräte) der Hersteller etc.
• Andere Bereiche, wie z.B. die gesamte Bus-Kommunikation erfolgt ungeschützt.
• Die Frage, ob die bekannten Sicherheitsmaßnahmen auf bereits etablierte Kommu-
nikationslücken oder andere Sicherheitslücken anzuwenden ist, ist eher mit Nein
zu beantworten zumindest in der nahen Zukunft.
• Allerdings stellt die Bereitstellung des Internets im Fahrzeug eine kritische Sicher-
heitslücke dar, deren Behandlung keinen zeitlichen Aufschub dulden sollte.
• Die Gefahren, die durch das Internet im Fahrzeug ermöglicht werden, müssen
sofort beantwortet werden.
• In diesem Fall ist das Konzept der Virtualisierung das Mittel der Wahl.
41 von 50
• Beim SW-Update werden die bekannten Prinzipien aus der Kryptographie insbesondere das Arbeiten
mit Schlüsselzentralen und zertifizierten Produkten verwendet.
•
Die bisherigen Sicherheitslücken werden eher mit Hilfe zukünftiger Protokoll-Generationen gelöst
werden, und weniger durch eine simple Erweiterung.
•
Beim Internet muss sofort reagiert werden: Aus meiner Sicht kann man nur versuchen,
Fahrzeug und Internet möglichst vollständig zu trennen:
• Eine komplette Trennung in Hardware verbietet sich wohl eher aus Kostengründen.
• Daher kommt nur eine Trennung mit Hilfe der Virtualisierung in Frage.
Virtualisierungs-Varianten
• Im Wesentlichen wird zwischen zwei Teilsystemen unterschieden. Das Host-
System ist ein realer, physischer Computer, welcher die Virtualisierungstechnik
anbietet (hostet). Das Gast-System bezeichnet einen virtuellen Computer, der
durch das Host-System angeboten bzw. verwaltet wird. Es werden die folgenden
Virtualisierungs-Techniken unterschieden:
• Die Emulation bezeichnet die funktionale Simulation eines Computers auf Soft-
warebasis. D.h. für jede zu emulierende HW-Komponente reproduziert der Emulator dasselbe Verhalten durch ein Programm.
• Bei der Maschinen-Virtualisierung werden auf einem Computer eine oder meh-
rere virtuelle Maschinen (VM) erzeugt und verwaltet.
• Bei der OS (Operating System) Virtualisierung wird die Trennung der einzel-
nen Instanzen (Container), durch Trennung der Namensräume des Betriebssystem realisiert. Zum Beispiel durch eigene Prozess-IDs, ein eigenes RootDateisystem oder Netzwerkadresse je Container.
• Bei der Prozessvirtualisierung wird für jede Ausführung einer Anwendung (Pro-
zeß) eine eigene Laufzeitumgebung gestartet, die ebenfalls als Virtuelle
Maschine (VM) bezeichnet wird.
43 von 50
•
Da die Emulation ein komplettes System vollständig in Software abbildet, kann das Host-System
jede Form von Architektur und Hardware emulieren, wenn die entsprechenden Routinen verfügbar
sind.
• Die Maschinen-Virtualisierung wird auf der nächsten Folie etwas ausführlicher beschrieben.
• Die OS-Virtualisierung ist auch unter dem Namen Container Virtualisierung bekannt, da sie ja auf
der Trennung mit Hilfe von Container basiert.
• In Abhängigkeit von der Konfiguration kann jede Instanz eines Containers unterschiedlich stark vom
Host bzw. von anderen Containern isoliert werden. Das Betriebssystem wird dazu um einige Tools
ergänzt, welche die Container einrichten, isolieren und die Ressourcen für einen Container
beschränken.
• Als Konsequenz aus dieser Methode muss der Host-Kernel die Eigenschaften aller Gast-Kernel
umfassen, da es genau einen Kernel zur Laufzeit gibt. Auf diese Weise ist es z.B. möglich, einen
Android-Container auf einen Linux-Host zu betreiben, da auch Android auf einem Linux-Kernel
basiert.
• Im Gegensatz zur Maschinen-Virtualisierung ist die dynamische Zuteilung der Container-Ressourcen möglich, also die Veränderung der Ressourcen, ohne das virtuelle System im Container
herunter fahren zu müssen.
• Im Unterschied zu den anderen Techniken ist bei der Prozessvirtualisierung die Laufzeit der VM
direkt an die Anwendung gekoppelt. Sie startet und endet mit dieser. Bei dieser VM handelt es sich
um eine abstrakte Maschine, von der es im Grunde nur eine Spezifikation gibt.
• Das vorrangige Ziel der Prozessvirtualisierung liegt in der Plattformunabhängigkeit für die Anwendungsentwicklung. Beispiele sind die Java VM, dotNET oder auch Dalvik VM von Android.
Maschinen-Virtualisierung
Linux
WIN 7
Kernel
...
App
App
...
App
...
App
VM
App
App
...
App
VM
App
App
VM
BSD
Kernel
Kernel
Virtual Machine Monitor
Host
Host-OS
Kernel
45 von 50
• Die Software-Komponente, die auf dem Host-System läuft und die Steuerung der virtuellen Maschine
dient, wird Hypervisor oder Virtual Machine Monitor (VMM) genannt.
• Im Unterschied zur Emulation muss hier die HW-Architektur des Gast-Systems identisch mit der
Architektur des Host-Systems sein.
• Die Wahl des verwendeten BS hängt hingegen nur von der Architektur des Gast-Systems ab.
• Im einfachsten Fall (siehe Folie) läuft der Hypervisor unmittelbar auf der Hardware. Das BS besteht
also nur aus dem Hypervisor. Der Hypervisor hat dadurch die volle Kontrolle über die HW. HW-Zugriffe
müssen allerdings vom Hypervisor selbst umgesetzt werden.
• Bei einer erweiterten Form setzt der Hypervisor auf einem vollwertigen BS auf. In diesem Fall fällt
der Hypervisor kleiner aus, da er für die HW-Zugriffe das BS verwenden kann.
• Über die Zeit sind verschiedene Formen der Maschinen-Virtualisierung entwickelt worden, deren
Abgrenzung nicht immer trennscharf ist. Im Wesentlichen erfolgt die Trennung an Hand des
entsprechenden Privilegierungsmodell:
• In der x86 - Architektur (Intel) gibt es ein Privilegierungsmodell, das aus den Ringen 0 bis 3
besteht. Ring 0 besitzt dabei die höchste Priorität und wird auch Kernel-Mode genannt. Die übrigen
Schichten werden als User-Mode bezeichnet. Ring 0 hat als einziger direkten Zugriff auf die HW
und kapselt diese gegen die anderen Schichten ab. Anwendungen laufen typischerweise im Ring 3
ab und können keine CPU-Instruktionen ausführen, die andere Prozesse beeinflussen könnten.
• Aus der Sicht eines CPU-Designers teilen sich alle CPU-Instruktionen in privilegierte und nicht-privilegierte Instruktionen. Nicht-privilegierte Instruktionen werden im User-Mode ausgeführt, eine Ausnahmebehandlung wird ausgelöst und die HW relevante Zugriffe im Kernel-Mode durchgeführt.
• Die Maschinen-Virtualisierungs-Varianten unterscheiden sich in der Abbildung der HW-Zugriffe
des Gast-Systems auf das Host-System bzgl. privilegierte bzw nicht-privilegierter Instruktionen.
Virtualisierungs-Techniken: Analyse
• Bei der Analyse der verschiedenen Varianten spielt neben dem Aspekt der Sicher-
heit natürlich auch der Leistungsaspekt eine entscheidende Rolle:
• Die Fähigkeit der Emulation, verschiedene Systeme zu simulieren und architek-
turübergreifend zu arbeiten, führt zu einem hohen Performanceverlsut und
kommt daher für den Einsatz im Eingebetteten Systemen nicht in Frage.
• Das primäre Ziel der Prozessvirtualisierung liegt weder in der Virtualisierung
noch in der Sicherheit. sondern in der Plattform-Unabhängigkeit für die Anwendungsentwicklung.
• Seitdem die Chip-Hersteller ihre CPUs um Virtualisierungsfunktionen erweitert
haben, ist der Leistungsverlust bei der Maschinen-Virtualisierung eher moderat. Da die i.d.R. entsprechende Varianten Gast-Systeme als vollständige
Maschine virtualisieren, bleiben Angriffe zunächst auf diese beschränkt. Das
vom Gast-System isolierte Host-System bleibt unbehelligt.
• Bei der OS- Virtualisierung wird nur ein sehr geringer zusätzlicher Bedarf an
Ressourcen erforderlich. Häufig werden Container Varianten (z.B. LXC) verwendet. Da der Kernel von Host und Containern identsich ist und Root-User aller
Umgebungen darauf zugreifen können, hängt die Sicherheit davon ab, wie
restriktiv der Root-User eines Containers mit dem Kernel kommunizieren darf.
47 von 50
• Ehemals erfolgte die Maschinen-Virtualisierung rein in Software und war daher aus Perfomancegründen für Embedded Systeme völlig ungeeignet.
• Neuere Hardware kann durch die Unterstützung von I/O- und Speichervirtualisierung einen großen
Teil des Overheads reduzieren, der sonst durch Indirektion über den Hypervisor entsteht.
• Innerhalb von Linux stehen für die Maschinen-Virtualisierungsvarianten bereit wie z.B. VMware,
Citriy XEN und Kernel Based Virtual Machine (KVM).
• Mit der Virtualisierungstechnik wird natürlich auch eine Softwareschicht eingeführt, die ebenfalls
angegriffen werden kann. Sogar bei fehlerfreien Gast-BS kann ein Angreifer den Hypervisor oder
die Peripherie-Emulation selbst attackieren, was sich häufig als DoS-Attacke auf Gast-System oder
Host-System auswirkt.
•
Falls man auf Linux als BS festgelegt ist, schränkt sich die Auswahl der OS-Level basiert
Virtualisierungen auf unter Linux verfügbare Lösungen ein.
• Seit der Version 2.6.24 des Linux-Kernels gibt die Container-Lösung Linux Container (LXC), welche direkt in den Kernel integriert und damit sofort verfügbar ist. Daher auch die gute Performance.
• Zum Schutz des Gesamtsystems müssen die Root-Aktivitäten innerhalb der Container restriktiv
gehandhabt werden. Ubuntu stattet beispielsweise ihre LXC Container mit einem Satz von Apparmor Regeln (Zugriffsrechte) aus. weist aber allerdings darauf hin, dass dies kein vollwertiger Schutz
vor bösartigen Aktivitäten bietet, sondern eher zur Vermeidung unabsichtlicher Schäden dient.
• Im Wesentlichen steht die Sicherheit im Widerspruch zur vollen Funktionalität. Wenn der Root-User
eines Containers nicht direkt mit dem Kernel kommunizieren darf, wird gleichzeitig seine Rolle als
Administrators innerhalb der Container-Umgebung eingeschränkt.
• LXC ist also nur bedingt geeignet, eine sichere Umgebung zur Verfügung zu stellen, eher für
die komfortable Partitionierung eines Systems.
Vielen Dank für Ihre Aufmerksamkeit!
Fragen?
gerne auch später an:
manuel.duque-anton@comlet.de
+49 6332 811 100
49 von 50
•