Konzeption einer sicheren Fahrzeugarchitektur bei fortschreitender Vernetzung des Fahrzeugs mit Konsumelektronik

Inhaltsverzeichnis

1 Einleitung
1.1 Motivation
1.2 Ziel und Forsehungsfragen
1.3 Methodische Vorgehensweise

2 Grundlagen der Fahrzeug- und Konsumelektronik-Industrie
2.1 Wertsehöpfungsketten der Fahrzeug- und Konsumelektronik-Industrie
2.2 Wertsehöpfungskette einer Fahrzeug-App anhand des 2-3-6-Konzepts
2.3 Fortschreitende Vernetzung und Dienstarten im Fahrzeug
2.3.1 Navigation
2.3.2 Infotainment
2.3.3 Integrierte Dienste
2.3.4 Car2x
2.3.5 Big Data
2.4 Sieherheitsanforderungen an die Fahrzeugarehitektur
2.4.1 Unterscheidung zwischen Safety und Security
2.4.2 Physische Sicherheit von Mensch, Fahrzeug und Umgebung
2.4.3 Keine Ablenkung des Fahrers
2.4.4 HMI-Hoheit
2.4.5 Datenschutz und Datensieherheit
2.5 Übersieht bestehender Multimediasysteme
2.5.1 Brought-In-Systeme
2.5.2 Embedded-Systeme
2.5.3 Hybrid-Systeme
2.5.4 Beispiele
2.5.4.1 MirrorLink
2.5.4.2 Apple CarPlay und Android Auto
2.5.4.3 BMW ConneetedDrive

3 Technische Grundlagen der Fahrzeug- und Smartphone-Architekturen
3.1 Betrachtung auf vier Ebenen
3.2 Siebenschichtenmodell
3.3 Dreischichtenmodell
3.4 Grundlagen Ebene 1 - Physische Ebene
3.5 Grundlagen Ebene 2 - Physische Datenübertragungsebene
3.5.1 Technische Eigenschaften von Bussystemen
3.5.1.1 Topologie
3.5.1.2 Interaktionsstruktur
3.5.1.3 Adressierung
3.5.1.4 Buszugriffsverfahren
3.5.1.5 Datensicherung
3.5.1.6 Synchronisation
3.5.1.7 Physikalische Übertragung
3.5.2 Eingesetzte serielle Bussysteme
3.5.3 Ethernet
3.6 Grundlagen Ebene 3 - Software-Datenübertragungsebene
3.6.1 Kryptographie
3.6.1.1 Sicherheitsanforderungen an Informationsübertragung
3.6.1.2 Symmetrische kryptographisehe Verfahren
3.6.1.3 Asymmetrische kryptographisehe Verfahren
3.6.1.4 Hybride kryptographisehe Verfahren
3.7 Grundlagen Ebene 4 - Software-Ebene
3.7.1 Betriebssystem
3.7.2 Virtualisierung
3.7.2.1 Ohne Virtualisierung
3.7.2.2 Vollvirtualisierung
3.7.2.3 Paravirtualisierung
3.7.2.4 Software-Virtualisierung
3.7.2.5 OS-Virtualisierung
3.7.2.6 Hardware-Virtualisierung
3.7.3 Sandbox
3.7.4 API

4 Analyse der technischen Gefahrenpotentiale
4.1 Gefahrenpotentiale der verschiedenen Dienstarten
4.1.1 Gefahrenpotentiale bei Embedded-Svstemen
4.1.2 Gefahrenpotentiale bei Brought-In-Svstemen
4.2 Gefahrenpotentiale beim Smartphone-Betriebssvstem
4.3 Perspektive eines Automobil-Hackers
4.4 Gefahren Ebene 1 - Physische Ebene
4.5 Gefahren Ebene 2 - Physische Datenübertragungsebene
4.6 Gefahren Ebene 3 - Software-Datenübertragungsebene
4.7 Gefahren Ebene 4 - Software-Ebene

5 Konzepte und Vorschläge für eine sichere Fahrzeugarchitektur
5.1 Konzepte Ebene 1 - Physische Ebene
5.2 Konzepte Ebene 2 - Physische Datenübertragungsebene
5.3 Konzepte Ebene 3 - Software-Datenübertragungsebene
5.4 Konzepte Ebene 4 - Software-Ebene
5.5 Security-by-Ansatz
5.6 Standardisierungs-Ansatz
5.7 Flexibilitäts- Ansatz

6 Evaluation der Konzepte und der Vorgehensweise
6.1 Evaluation nach Sicherheitsanforderungen
6.2 Evaluation anhand des 2-3-6-Konzeptes
6.3 Evaluation anhand der Zielkonflikte
6.4 Evaluation der Vorgehensweise

7 Zusammenfassung und Ausblick auf weitere Forschung
7.1 Beantwortung der Forschungsfragen
7.2 Ausblick auf weitere Forschung
7.3 Einschätzung zukünftiger Entwicklungen

Literaturverzeichnis

Abbildung in dieser Leseprobe nicht enthalten

Abbildungsverzeichnis

2.1 Traditionelle Wertschöpfungskette der Automobilindustrie und neue Akteure

2.2 Felder des 2-3-6-Konzepts

2.3 Unterscheidung zwischen Safety und Security

3.1 Vier Ebenen

3.2 ISO/OSI-Kommunikationsmodell

3.3 Dreischichtenmodell in der Automobilelektronik

3.4 Topologiearten

3.5 Unterscheidung zwischen Client-Server- und Produeer-Consumer-Interaktion

3.6 Beispiel eines Bussystems im Fahrzeug

3.7 Standardprotokoll für hybride Kryptosysteme

3.8 Ringdarstellung der Modi und Zuordnung der Ringe ohne Aktualisierung

3.9 Vollvirtualisierung ohne, mit Hardware-Assistenz, Paravirtualisierung

3.10 Hosted Aktualisierung, OS-Aktualisierung, Partitionierung

4.1 Injektion eines Rootkits und dessen Auswirkungen

5.1 IP-basierte Kommunikations-Middleware mit modularem Security-Framework

5.2 Partitionierung mit mehreren Betriebssystemen und Echtzeitumgebungen

6.1 Einfluss des OEM bei verschiedenen Ansätzen

6.2 Zielkonflikte bei verschiedenen Ansätzen

3.1 Vor- und Nachteile verschiedener Bustopologien

3.2 Vor- und Nachteile verschiedener Interaktionsstrukturen

3.3 Vor- und Nachteile verschiedener Buszugriffsverfahren

3.4 Vor- und Nachteile verschiedener Datensicherungsverfahren

3.5 Vor- und Nachteile verschiedener Synchronisationsverfahren

3.6 Vor- und Nachteile verschiedener Übertragungsarten

3.7 Eigenschaften bestehender Bussysteme und Ethernet

4.1 Gefahrenpotentiale eines Embedded-Systems

4.2 Gefahrenpotentiale eines Brought-In-Svstems

4.3 Angreiferarten, ihre Kenntnisse, ihr Zugang und ihre Ziele

6,1 Gewährleistung der Sicherheitsanforderungen bei verschiedenen Ansätzen

1. Einleitung

1.1 Motivation

„Da die Konnektivität bei der jüngeren Generation als äußerst bedeutungsvoll gilt, muss sieh dieser Lebensstil aueh im Fahrzeug widerspiegeln,“ erläutert Anupam Malhotra, Ge­schäftsführer Connected Vehicles von Audi of America [ + , S.25], VW-Chef Martin

Winterkorn warnt hingegen, das Auto dürfe „nicht zur Datenkrake werden“ |Reul4|, Die Sys­temarchitektur einiger Fahrzeugmodelle sei zudem „leicht hackbar,“ wie Fahrzeug-Hacker im Auftrag der Forschung feststellen |VM14|, „Schließlich erweitern zunehmende Fahrzeugver­netzung und Integration innovativer Services die traditionelle automobile Wertschöpfungs­kette, Neben zusätzlichen Wachstumspotenzialen erhöht sich damit der Wettbewerbsdruck durch neue Player aus anderen Industrien,“ resümiert eine Studie von Oliver Wyman |Karl2, S.31. Diese vielfältigen Positionen reflektieren lediglich einen Auszug aus der Liste an Her­ausforderungen, denen Fahrzeughersteller angesichts der fortschreitenden Vernetzung des Fahrzeugs mit Konsumelektronik gegenüber stehen.

Diese aktuellen Entwicklungen folgen einer jahrzehntelangen Elektronifizierung des Fahr­zeugs: Zum Zweck, den anspruchsvolleren Wünschen nach Sicherheit und Komfort, den strengeren gesetzlichen Vorgaben und dem Innovationsdruck gerecht zu werden, integrier­ten Fahrzeughersteller zahlreiche elektronische Kommunikationssysteme und Steuergeräte in das Fahrzeug, Zwar ist die Architektur dieser Systeme auf die Sicherheitsrelevanz der tra­ditionellen Anwendungen angepasst. Allerdings wird nun fraglich, ob einzelne Bestandteile der Architektur sowie das Gesamtkonstrukt in Zukunft auch modernen Anwendungen aus der Konsumelektronik standhalten können.

Diese Bedenken sind im Hinblick auf aktuelle Ergebnisse der Meinungsforschung legitim: Aufgrund der progressiven Vernetzung des Menschen im Internet und der Nutzung von Kon­sumelektronikgeräten im Alltag besteht die Erwartungshaltung, auch innerhalb des Fahr­zeugs auf Internet und Applikationen sowie von außen auf das Fahrzeug zugreifen zu können |Taml2, S,9|, Dass „durch die Bedienung von Smartphones am Steuer immer mehr Auto­Unfälle verursacht werden,“ wie das deutsche Innenministerium verkündet, geht mit diesem Lebensstil einher |Kurl4|, Um diesem gefährlichen Trend zu begegnen, versuchen Implemen­tierungen aus Forschung und Entwicklung die Unfallzahlen zu minimieren: So sollen in das Fahrzeug eingebettete Multimedia-Systeme mit Spraehbedienung und an die Fahrt angepass­ten Anwendungen das Autofahren sieherer gestalten. Allerdings steigt dureh die vernetzten Dienste wiederum das Risiko, ungewollte Funktionalitäten oder sehädliehen Code - beispiels­weise dureh Haeker - in die Fahrzeugarchitektur einzusehleusen.

Obwohl laut einer Umfrage der University of Miehigan in den USA, Australien und Groß­britannien die Mehrheit nicht viel von den neuen Technologien im Bereich Car Connectivity versteht, sind 80 % davon überzeugt, dass Autofahren dadurch sieherer und zahlreiche Un­fälle vermieden werden, Xur 37 % äußerten auch starke Bedenken bezüglich Security und Datensieherheit im Fahrzeug |Thul4|, Eine umgekehrte Meinungsverteilung ist jedoch bei den Experten der Branche auf der Cebit 2014 zu beobachten: 24 % glauben an mehr Fahr- zeugsieherheit dureh die fortschreitende Connectivity, während sogar 36 % weniger Sicherheit prognostizieren |MKW14|, Hierbei treten besonders die technologischen Schwierigkeiten zum Vorschein, einen Kompromiss zwischen Vernetzung und Sicherheit zu finden.

Daher sind bei der Konzeption eines vernetzten Multimedia-Systems im Fahrzeug besondere Sieherheitsanforderungen zu berücksichtigen: Im Hinblick auf überlebensnotwendige Funk­tionalitäten besitzen die Anforderungen nach physischer Sicherheit und keiner Ablenkung des Fahrers höchste Relevanz, Für die Positionierung des Fahrzeugherstellers und die Pri­vatsphäre des Fahrers hingegen spielen die Hoheit über die Multimedia-Plattform sowie Datenschutz und -Sicherheit eine besonders hohe Rolle, Kontrolle über die Daten und die Oberfläche des Multimedia-Systems repräsentiert dabei nicht zuletzt die Macht Verteilung zwischen den Akteuren aus Automobilindustrie, Konsumelektronik und Telekommunikation, Inwiefern ein Dienst auf Steuergeräte und sieherheitsrelevante Systeme zugreifen oder Daten zu Fahrer, Fahrzeug oder Fahrverhalten auslesen kann, hängt letztlich von der Implementie­rung ab. Unabhängig von der genauen Realisierung soll sieh der Markt für Car Connectivity laut einer Studie von MeKinsey bis 2020 verfünffachen. Gleichzeitig werden 20 % der Kun­den weltweit bereit sein, die Automarke zu wechseln, wenn das Internetangebot besser ist - im chinesischen Markt mehr, im deutschen weniger |Frel4|, Der Fahrzeughersteller steht so insgesamt vor der Herausforderung, die neuen Kundenerwartungen zu erfüllen, die Fahrzeug­architektur an die neuen Sieherheitsgefahren anzupassen und gleichzeitig einen strategischen Vorteil aus seiner Vorherrschaft im Fahrzeug gegenüber anderen Akteuren zu erzielen. Die­se Überlegungen des Fahrzeugherstellers werden nicht zuletzt von Möglichkeiten begleitet, das Multimedia-System an andere Akteure auszulagern oder einen industrieweiten Standard einzuführen.

1.2 Ziel und Forschungsfragen

In dieser wissenschaftlichen Arbeit wird untersucht, wie eine Fahrzeugarchitektur mit Internet- und Applikationssehnittstellen konzipiert werden kann, die den Anforderungen nach An- griffssehutz und physischer Sicherheit gerecht wird. Der Fokus liegt primär auf den tech­nischen Konzepten für fahrzeuginterne und -externe Kommunikationssysteme, während die wirtschaftlichen Auswirkungen bei der Evaluation berücksichtigt werden.

Hierbei widmet sieh die Arbeit den folgenden Forsehungsfragen:

1, Welche Sieherheitsanforderungen müssen Vernetzungs-Systeme im Fahrzeug erfüllen?

2, Wie kann die Fahrzeugarchitektur angepasst werden, um den Sicherheitsanforderungen zu genügen?

3, Wie wirkt sieh ein Veränderungsansatz auf die Wertschöpfungskette aus?

1.3 Methodische Vorgehens weise

Die folgende Herangehensweise zielt darauf ab, den Verlauf der Analyse klar zu strukturieren und die verschiedenen, im vorherigen Abschnitt aufgeworfenen Fragestellungen gezielt zu beantworten.

Zunächst werden in Kapitel 2 die wirtschaftlichen Grundlagen der Fahrzeug- und Konsum­elektronikindustrie und der Status Quo von Fahrzeug-Multimedia-Systemen dargestellt, um die Problemstellung in den richtigen Kontext zu setzen.

Im Anschluss werden in Kapitel 3 die technischen Grundlagen - eingeteilt auf vier Ebenen - detailliert erläutert. Diese Vierteilung wird auch für die Analyse und die Vorstellung der Konzepte zur Strukturierung und Übersichtlichkeit in den darauffolgenden Kapiteln verwen­det.

Die Analyse in Kapitel 4 beschäftigt sieh mit den Gefahrenpotentialen der derzeitigen Fahr­zeugarchitektur, der derzeitigen Smartphone-Technologien und der zukünftigen Kombination beider Systeme, Um diesen Gefahrenpotentialen zu begegnen, werden in Kapitel 5 bestehende Sicherheits­konzepte aus Forschung und Entwicklung vorgestellt und drei eigene Konzeptionsansätze entworfen, welche ausgewählte Konzepte vereinen.

Diese Konzeptionsansätze werden anschließend nach (1) Sicherheitsanforderungen, (2) wirt­schaftlichen Auswirkungen auf die Marktposition des OEM sowie (3) anhand möglicher Ziel­konflikte in Kapitel 6 evaluiert.

Zum Schluss werden die Ergebnisse dieser Arbeit zusammengefasst und die zuvor aufge­stellten Forschungsfragen beantwortet, Neben einem Ausblick auf weitere Forschung schließt Kapitel 7 mit einer subjektiven Einschätzung zukünftiger Entwicklungen, Die Inhalte dieser Arbeit basieren auf einer ausgiebigen Literaturrecherche sowie teilweise auch auf Interviews mit Mitarbeitern von Mieschke Hofmann und Partner (МНР), Dabei lassen sieh die Quellen grob in zwei Segmente unterteilen: Mithilfe von wissenschaftlichen Papers und Grundlagenliteratur werden insbesondere technische Inhalte bearbeitet, während Artikel und Marktanalysen dazu dienen, Trends zu beschreiben. Insgesamt wird auf eine Balance zwischen technischen Details und übergreifenden Entwicklungen geachtet.

2. Grundlagen der Fahrzeug- und Konsumelektronik-Industrie

Damit die technischen Grundlagen und Veränderungsmöglichkeiten im Gesamtkontext er­läutert werden können, gilt es zunächst, die wirtschaftliche Ausgangssituation aus der Per­spektive des Automobilherstellers bei fortschreitender Vernetzung des Fahrzeugs mit Kon­sumelektronik zu betrachten.

Dabei werden zunächst die Wertschöpfungsketten der Fahrzeug- und Konsumelektronikin­dustrie einander gegenüber gestellt sowie die Wertschöpfungskette eines Multimediasystems anhand des 2-3-6-Konzeptes erläutert, welches für die Evaluation in Kapitel 6 verwendet wird. Im Anschluss werden verschiedene Bereiche der fortschreitenden Vernetzung des Fahr­zeugs und der Sicherheitsanforderungen an die Fahrzeugarchitektur vorgestellt und anhand dieser Bereiche eine thematische Abgrenzung der Arbeit vorgenommen. Parallel zur Beschrei­bung des Status Quo erfolgt in diesem Kapitel die Definition relevanter Begriffe, Am Ende dieses Kapitels werden drei Arten von Multimediasystemen beschrieben und bestehende Im­plementierungen beispielhaft eingeordnet,

2.1 Wertschöpfungsketten der Fahrzeug- und Konsumelektronik-Industrie

„Die zunehmende Fahrzeugvernetzung und Integration innovativer Services erweitern die tra­ditionelle automobile Wertschöpfungskette. Neben zusätzlichen Wachstumspotenzialen er­höht sieh damit der Wettbewerbsdruck durch neue Player aus anderen Industrien, |,,,| Eine weitere Verschiebung tritt auch in der Arbeitsteilung zwischen Original Equipment Manu­facturers (OEMs) und Zulieferern auf. Durch die Fokussierung der Hersteller auf zusätzliche Kernkompetenzen gewinnen Zulieferer in den kommenden Jahren zusätzliche Wertschöp­fungsanteile,“ resümiert eine Studie zum Wandel in der automobilen Wertschöpfungsstruk­tur, die von „Oliver Wyman“ in Kooperation mit dem „Verband der Automobilindustrie“ ver­öffentlicht wurde |Karl2, S,3|.

Diese Entwieklung seheint einen Brneh zur traditionellen Wertsehöpfnngskette in der Au­tomobilindustrie darzustellen - einem über die letzten Jahrzehnte optimierten System zwi­schen den folgenden drei Hauptakteuren |Sehl3, S.13 ff.|, welche auch in Abbildung 2,1 zu erkennen sind: Lieferanten, Original Equipment Manufacturer (OEM) und Händler, Dabei halfen und helfen Lean-, Qualitäts- und Prozessmanagement den OEMs, die vielen Abläufe zu systematisieren und so eine möglichst reibungslose, kostenminimale und kontrollierbare Wortschöpfung zu gewährleisten |Sch 13, S.53 f,|. In diesem ganzheitlieh regulierten Rahmen sind die Aktivitäten der drei Akteure von vornherein eingeplant |Schl3|:

- Zulieferer: Der Zulieferer passt seine Produktion und Logistik ganz an den Produk­tionsplan, die Lieferverträge und die Vorgaben des OEM an,

- OEM: Auf strategischer Ebene steht der OEM - der Automobilhersteller - vor der Herausforderung, neue Modelle zu entwickeln. Ist dieser Schritt erledigt, so müssen auf taktischer Ebene die Produktionspläne an die Aufträge des Händlers angepasst und entsprechende Lieferverträge mit dem Zulieferer geschlossen werden. Auf operati­ver Ebene spielen Ansätze wie „Just-in-Time“ und „Just-In-Sequence“ in der Logistik eine hohe Rolle, um Lagerhaltungskosten zu minimieren und die Anlieferung an den Produktionsplan zu takten. Dieser Plan sieht aufgrund der voranschreitenden Perso- nalisierung von Automobilen vor, dass die Bauteile für ein spezifisches Produkt zur rechten Zeit an der richtigen Produktionsstufe in das richtige Automobil eingebaut werden,

- Händler: Der Händler fungiert in erster Linie als Vertrieb, Gleichzeitig liefert er den Input für den Produktionsplan, indem Kaufverträge abgeschlossen werden, in denen der Kunde die Zusammensetzung seines Fahrzeugs angibt.

Traditionelle

Wertschöpfungskette

Zusammenfassend lässt sich feststellen, dass die Komplexität der automobilen Wertschöp­fungskette durch einen stark regulierten ganzheitlichen Ansatz nach einem präzisen Pro­duktionsplan geordnet wird. Dabei gilt traditionell eine Produktlebensdauer von 10 Jahren [ + , S.ll], Im Kontext dieser Arbeit stellt sich nun die Frage, ob ein System zur Vernetzung des Fahrzeugs mit der Umwelt lediglich ein weiteres Bauteil darstellt, das in die traditionelle Wortschöpfung integrierbar ist, oder ob die Wertschöpfungskette dadurch neue Formen annehmen wird. Hierbei ist insbesondere zu beachten, dass die Wertschöpfungs­ketten in der Mobilfunkindustrie und Unterhaltungselektronik auch den groben drei Stufen Zulieferung, Herstellung und Vertrieb folgt, die Produktlebensdauer jedoch nur wenige Mo­nate beträgt. Dadurch altert ein Multimedia-System im Fahrzeug schneller als das Fahrzeug selbst |BSEW13, S,18|, |FFO£, S,9|, Versicherungen repräsentieren einen weiteren Akteur, indem sie anhand von Daten zum Fahrverhalten Versicherungstarife beispielsweise nach dem „Pay-as-you-drive“-Prinzip anbieten |Wenl4|.

Es ist ebenfalls zu berücksichtigen, dass sowohl diese drei neuen Akteure im Automobilmarkt als auch die traditionellen Zulieferer, OEMs und Händler eigene Interessen verfolgen, um ihre Alleinstellungsmerkmale dem Kunden anzubieten und im Gegenzug von den Kundendaten und der App-Xutzung zu profitieren |BSEW13, S.30|. So könnte der OEM durch Direktver­trieb der Multimedia-Dienste selbst als Händler fungieren. Als problematisch erweisen sieh dabei die Fragen, wer für den Kundensupport verantwortlich wäre und ob der traditionelle Händler die durch den OEM direkt vertriebenen Dienste dem Kunden auch vorführen würde, ohne selbst daran zu verdienen.

Der OEM, der bisher in vielerlei Hinsicht die Herrschaft über sein Produkt besitzt, steht vor der Entscheidung, seine optimierte Wertschöpfungskette mit einem eigenen geschlosse­nen System fortzusetzen oder zumindest Teile des Systems zu öffnen, was wiederum eine Änderung der Wertschöpfungskette zur Folge haben kann. Laut der Studie von „Oliver Wy- man“ fokussiert sieh der OEM in Zukunft stärker auf das Kerngeschäft |Karl2, S,5|, sodass tendenziell auch Aufgaben aus der Vernetzung des Fahrzeugs mit der Konsumelektronik an die anderen Akteure abgegeben werden.

2.2 Erklärung der Wertschöpfungskette einer Fahrzeug- App anhand des 2-3-6-Konzepts

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 2,2: Felder des 2-3-6-Konzepts (nach |XeuO , S,15|)

Dass mit weiteren Schnittstellen der Fahrzeugarchitektur zu Konsumelektronik und Internet der Einfluss des OEM im Fahrzeug schwinden kann, wurde im vorangehenden Abschnitt erläutert. Welche Einflussbereiche dabei tatsächlich betroffen sind, wird nun anhand des 2-3-6-Konzeptes genauer beschrieben.

Das 2-3-6-Konzept ist ein Werkzeug zur Analyse der Wertschöpfungsketten von Informati­onssystemen, bei denen eine Konkurrenz um zwei Zugangsarten zum Konsumenten besteht: Zugang durch Inhalt und Zugang durch Bereitstellung der Infrastruktur |XeuO , S,14|, Im oberen Teil der Abbildung 2,2 sind diese allgemeinen zwei Zugangsarten zu erkennen, wäh­rend der untere Teil verdeutlicht, dass sieh die Wertschöpfungsketten weiter in jeweils drei Schritte aufteilen lassen.

Das 2-3-6-Konzept wird weiterhin dazu verwendet, um die strategische Position eines Ak­teurs in den sechs Feldern der Wertschöpfungskette zu analysieren. Auf Basis dieser Unter­suchungen können Entscheidungen darüber getroffen werden, ob sieh das Unternehmen in bestimmte Felder weiterentwickeln oder aus ihnen zurückziehen soll. Für einen Fahrzeugher­steller dient es zur Überlegung, bei welchen Feldern der Fahrzeug-App-Wertschöpfungskette in eigene Leistungen investiert und wo das Know-How anderer Akteure verwendet werden soll.

Eine ähnliche Dreiteilung ist bereits in der traditionellen Wertschöpfungskette der Auto­mobilindustrie beschrieben worden: Die Zulieferer stellen die Ressourcen bereit; der OEM stellt das fertige Produkt her; der Händler vertreibt es. Innerhalb des 2-3-6-Konzeptes sind dieselben Schritte auf eine Inhalts- und eine Infrastrukturschiene aufgeteilt. Beim nicht- vernetzten Fahrzeug ist eine Aufteilung in Inhalt und Infrastruktur nicht notwendig, wäh­rend bei Informationssystemen wie einem vernetzten Multimedia-System im Fahrzeug diese Unterscheidung zum Tragen kommt. Das Informationsprodukt, das bei der folgenden Be­trachtung interessiert, ist weder das Fahrzeug, noch das Multimedia-System selbst, sondern die App, die der Kunde auf seinem Fahrzeug nutzen möchte. Deswegen werden nun die sechs Felder des 2-3-6-Konzepts für das Produkt „Fahrzeug-App“ untersucht:

- Inhalt gestalten: Die Idee für eine App wird geschaffen,
- Inhalt verpacken: Experten programmieren die App mit den erforderlichen Funktiona­litäten,
- Markt gestalten: Die Kunden werden beispielsweise über einen Support-Center oder eine Installationshilfe betreut. Mit Werbe-Kampagnen und über Distributionskanäle wird die App vertrieben,
- Transport: Dieses Feld betrachtet die Datenübertragung, welche über Telekommunika­tionsunternehmen und Mobilfunkbetreiber bereitgestellt wird,
- Backendsysteme: Dieses Feld, das ursprünglich „Delivery Support and Services“ heißt, stellt Datenbank- und Server-Infrastrukturen wie Datenspeicherung, Zugriffskontrolle, Bezahl- und Sicherheitssysteme zur Verfügung,
- Interface, Systeme: Dieses Feld beinhaltet die Plattform, das Betriebssystem und die Hardware des Multimediasystems, auf denen die App laufen soll.

In Kapitel 6 wird das 2-3-6-Konzept verwendet, um für die eigenen Konzeptionsansätze die Rolle des OEM in der sechsgeteilten Wertschöpfungskette zu untersuchen.

2.3 Fortschreitende Vernetzung und Dienst art en

Die fortschreitende Vernetzung in der Gesellschaft ist durch verschiedene Entwicklungen charakterisiert: Einerseits erfolgt eine Verbreitung von Laptops, Tablets, Smartphones und Wearables durch die Unterhaltungselektronik |Taml2|. Andererseits findet auf der Infrastruk­turseite das Einrichten von Hotspots an öffentlichen Plätzen, wie auch auf dem Privatgelände von Shopping Mails, Flughäfen oder in Zügen statt |Karl2|, Gleichzeitig passt die Mobil­funkindustrie ihre Tarife und Verträge an. Summa summarum steigen Qualität, Quantität, Erreichbarkeit und Erschwinglichkeit von vernetzten Diensten mit der Zeit an, was mit ei­nem vorherrschenden Trend einhergeht: der Erwartung, überall und jederzeit verbunden zu sein |Taml2, S,9|, Dies bestätigen auch zahlreiche Trendstudien: Bis 2018 werden 85% der Weltbevölkerung mobilen Internetzugang besitzen |Litl·:, S,14|, wobei das größte Wachstum für die Sehwellenländer erwartet wird |TamU , S,3|.

Das Fahrzeug, als Symbol für traditionelle Mobilität und Freiheit |Wei04|, trifft im Laufe der fortschreitenden Vernetzung auf die modernen mobilen Geräte, Das zuvor geschlossene System und der isolierte kapselartige Raum des Fahrzeugs, dessen Entwicklung und Design allein im Einflussbereich des OEM liegen, öffnet Schnittstellen für die neuen Geräte und kann dadurch zu einem halboffenen System werden |BSEW13, S,31|, Gleichzeitig wird, wie bereits angedeutet, Spielraum für die anderen Akteure aus Unterhaltungselektronik, Infrastruktur und Mobilfunkindustrie eröffnet |BSEW1·:, S,18|.

Nicht nur auf Basis wirtschaftlicher Interessen, sondern auch in der elektrotechnischen Infra­struktur des Fahrzeugs, könnte es dadurch zu Kontroversen, Kompromissen und Missbrauch kommen. Dies hängt einerseits davon ab, wie viel Zugang der Automobilhersteller gewährt, und andererseits davon, welche Zugriffe ein solcher Dienst vornehmen möchte |BSEW13|, Da­bei ist zu erwarten, dass „nicht alle Funktionalitäten von einer Killer-Applikation, sondern von zahlreichen großen Diensten und Anbietern“ bereitgestellt werden |Taml2, S,10|, Diese Dienste lassen sieh in fünf Kategorien einteilen, welche im Folgenden beschrieben werden |BSEWl: , S,39| und |FF12, S.20 f.|.

2.3.1 Navigation

Unter „Navigation“ fallen Standardanwendungen, die bereits in vielen Fahrzeugen durch den OEM integriert sind, aber auch nach dem Fahrzeugkauf als mobiles Gerät im Fahrzeug ange­bracht werden können. Im Allgemeinen sollen Navigationsanwendungen die Fahrt erleichtern. Dazu gehören beispielsweise Navigationssysteme, die Anzeige von „Points of Interest“ und Verkehrsflussdaten mit Stau- und Gefahrenmeldungen, Für Elektroautos kann dabei auf Ba­sis des Batteriestands berechnet werden, wie weit das Fahrzeug noch fahren kann und wo eine Aufladung möglich und empfehlenswert ist [ + , S.23],

2.3.2 Infotainment

Zum Bereich „Infotainment, Entertainment und Multimedia“ zählen Anwendungen, die der Information und Unterhaltung der Insassen dienen, aber nicht mit der Fahrt, dem Fahrer oder dem Fahrzeug Zusammenhängen, Insbesondere ist neben Autoradio und Autotelefon in dieser Rubrik das Internet zu verorten, über welches auf World Wide Web, E-Mail, Da­teiübertragung und andere Internetprotokolle zugegriffen werden kann |FFU , S,16|, Damit gelangen sämtliche Inhalte, die bereits auf modernen mobilen Geräten aufgerufen werden können, in das Fahrzeug, Als Beispiele seien Webradio, soziale Netzwerke aber auch Spiele und Hörbücher genannt. Neben dem Web-Browser, gehören auch Apps zum „Infotainment“.

Diese Entwieklung seheint einen Brneh zur traditionellen Wertsehöpfnngskette in der Au­tomobilindustrie darzustellen - einem über die letzten Jahrzehnte optimierten System zwi­schen den folgenden drei Hauptakteuren |Sehl3, S.13 ff.|, welche auch in Abbildung 2,1 zu erkennen sind: Lieferanten, Original Equipment Manufacturer (OEM) und Händler, Dabei halfen und helfen Lean-, Qualitäts- und Prozessmanagement den OEMs, die vielen Abläufe zu systematisieren und so eine möglichst reibungslose, kostenminimale und kontrollierbare Wortschöpfung zu gewährleisten |Sch 13, S.53 f,|. In diesem ganzheitlieh regulierten Rahmen sind die Aktivitäten der drei Akteure von vornherein eingeplant |Schl3|:

- Zulieferer: Der Zulieferer passt seine Produktion und Logistik ganz an den Produk­tionsplan, die Lieferverträge und die Vorgaben des OEM an,

- OEM: Auf strategischer Ebene steht der OEM - der Automobilhersteller - vor der Herausforderung, neue Modelle zu entwickeln. Ist dieser Schritt erledigt, so müssen auf taktischer Ebene die Produktionspläne an die Aufträge des Händlers angepasst und entsprechende Lieferverträge mit dem Zulieferer geschlossen werden. Auf operati­ver Ebene spielen Ansätze wie „Just-in-Time“ und „Just-In-Sequence“ in der Logistik eine hohe Rolle, um Lagerhaltungskosten zu minimieren und die Anlieferung an den Produktionsplan zu takten. Dieser Plan sieht aufgrund der voranschreitenden Perso- nalisierung von Automobilen vor, dass die Bauteile für ein spezifisches Produkt zur rechten Zeit an der richtigen Produktionsstufe in das richtige Automobil eingebaut werden,

- Händler: Der Händler fungiert in erster Linie als Vertrieb, Gleichzeitig liefert er den Input für den Produktionsplan, indem Kaufverträge abgeschlossen werden, in denen der Kunde die Zusammensetzung seines Fahrzeugs angibt.

Traditionelle

Wertschöpfungskette

Zusammenfassend lässt sich feststellen, dass die Komplexität der automobilen Wertschöp­fungskette durch einen stark regulierten ganzheitlichen Ansatz nach einem präzisen Pro­duktionsplan geordnet wird. Dabei gilt traditionell eine Produktlebensdauer von 10 Jahren [ + , S.ll], Im Kontext dieser Arbeit stellt sich nun die Frage, ob ein System zur Ver­

netzung des Fahrzeugs mit der Umwelt lediglich ein weiteres Bauteil darstellt, das in die traditionelle Wortschöpfung integrierbar ist, oder ob die Wertschöpfungskette dadurch neue Formen annehmen wird. Hierbei ist insbesondere zu beachten, dass die Wertschöpfungs­ketten in der Mobilfunkindustrie und Unterhaltungselektronik auch den groben drei Stufen Zulieferung, Herstellung und Vertrieb folgt, die Produktlebensdauer jedoch nur wenige Mo­nate beträgt. Dadurch altert ein Multimedia-System im Fahrzeug schneller als das Fahrzeug

Die vorgestellten fünf Dienstarten sind nicht als disjunkt zu betrachten, sodass manche Anwendungsfälle nicht eindeutig einer Dienstart zuordenbar sind: Typische Anwendungen wie der Staumeldeservice, Informationen zu Tankstellen auf der Route oder das Berücksich­tigen des Batteriestandes eines Elektroautos werden im Rahmen dieser Arbeit auf Basis der beschriebenen Abgrenzungen zu Navigation gezählt, insbesondere wenn die Abfrage über ein Xavigationsgerät verläuft. Sofern jedoch ein Internet-Browser verwendet wird, könnte die Funktionalität zu Infotainment gerechnet werden, Falls eine App dabei auf das Fahrzeug zugreift, könnte sie auch den Integrierten Diensten zugeordnet werden.

Im Hinblick auf die fortschreitende Vernetzung schreitet die Elektronifizierung des Fahrzeugs mit der Weiterentwicklung dieser Dienstarten voran. Die Bedienungsmöglichkeiten für Fahrer und Insassen vervielfältigen sieh. Gleichzeitig repräsentiert der Zugriff auf das Fahrzeug und der Zugang des Fahrzeugs auf externe Systeme und Dienste ein Risiko für die Sicherheit - ein Aspekt, welcher neben den Werten Freiheit und Mobilität bei einem Fahrzeug von besonderer Bedeutung ist | >K14|.

Für die thematische Einordnung dieser wissenschaftlichen Arbeit ist herauszustellen, dass der Forschungsrahmen explizit die ersten drei Dienstarten „Navigation“, „Infotainment“ und „Integrierte Dienste“ umfasst, während „Car2x“ und „Big Data“ nicht berücksichtigt werden. Der Fokus liegt auf der Kommunikation innerhalb des Fahrzeugs sowie den Zugriff auf das Fahrzeug von außen.

2.4 Sicherheitsanforderungen an die Fahrzeugarchitektur

Jährlich sterben laut der Weltgesundheitsorganisation 1,24 Millionen Menschen bei Ver­kehrsunfällen |Smil , S,37|, Daher ist nicht verwunderlich, dass in deutschen Umfragen beim Autokauf das Kriterium „Sicherheit“ neben „Qualität“ an erster Stelle steht, während „inte­grierte Kommunikation“ bislang den letzten Platz einnimmt |FF12, S,14|, Dadurch entsteht für den OEM die Verpflichtung, besondere Verantwortung für die Fahrzeugsicherheit zu übernehmen und somit vom Design des Fahrzeugs, über die Auswahl der Lieferanten bis hin zur fehlerfreien Ausführung des Produktionsplans stets mit Integrität für das Ziel „Sicher­heit“ zu handeln. Für die Unterhaltungselektronik und Mobilfunkindustrie allerdings spielt Sicherheit nicht die Hauptrolle: Während ein Fahrzeug bei technischen Schäden Menschenle­ben gefährden kann, sind ein beschädigtes Display, eine Fehlfunktion im Betriebssystem des Smartphones oder eine wiederholt abbrechende Verbindung für den Benutzer ungefährlich und akzeptierbar. So kann es beispielsweise bei mehreren iPhone-Modellen zum Abbruch eines Telefonates durch den „Todesgriff“ - einen bestimmten Haltewinkel des Gerätes - kom­men, In den Zertifizierungstests sind diese Mängel nicht bemerkt worden, jedoch in der Benutzung durch Endkunden häufig vorgekommen [ + , S.4], Derartige Fehler können im Fahrzeug zu verheerenden Folgen führen. Insgesamt wird im Infotainment-Bereich und in der Unterhaltungselektronik der Term Sicherheit bevorzugt mit Datenschutz und Da­tensicherheit assoziiert, während die Zuverlässigkeit des technischen Gerätes vernachlässigt wird.

2.4.1 Unterscheidung zwischen Safety und Security

Im Allgemeinen ist beim Automobil wie bei jedem Produkt der Unterschied zwischen Be­triebssicherheit und Gebrauchssicherheit zu betrachten. Im Rahmen dieser wissenschaftlichen Arbeit spielt jedoch auch der davon unabhängige Angriffsschutz eine relevante Rolle:

- Betriebssicherheit bezeichnet den Teil der Sicherheit, der durch die Spezifikation des Produkts gewährleistet wird. Dabei ist zu überprüfen, ob das Produkt die Funktionen korrekt ausführt, d.h, so wie sie vom Hersteller vorgesehen sind. Die Entwicklung von software-basierten Fahrzeugsystemen erfolgt unter Befolgung des Standards ISO 26262 - Funktionale Sicherheit für Straßenfahrzeuge |Orgl 11, |Hilll, S,91|,

- Gebrauchssicherheit bezeichnet den Teil der Sicherheit, der während der Bedienung des Produkts durch den Kunden gewährleistet wird. Es ist zu überprüfen, ob ein funktional sicheres Produkt in speziellen Anwendungsfällen oder bei Fehlgebrauch des Kunden das gewünschte Verhalten aufweist,

- Angriffsschutz bezeichnet den Teil der Sicherheit, der während mutwilliger Attacken von außen auf das Fahrzeug gewährleistet wird. Dazu zählen physische Diebstahl- und Beschädigungsversuche genauso wie Malware auf virtueller Ebene, Während in der deutschen Sprache in allen drei Fällen der Term „Sicherheit“ verwendet wird, unterscheidet der englische Wortschatz die zwei Oberbegriffe „Safety“ und „Security“: „Safety“ bezeichnet den Schutz der Umwelt vor dem Fahrzeug, was mit Betriebssicherheit und Gebrauchssicherheit erreicht werden soll. Als „Security“ hingegen wird der Schutz des Fahrzeugs vor der Umwelt benannt, worunter Angriffsschutz fällt |PfiO , Summary|.

Abbildung 2,3: Unterscheidung zwischen Safety und Security

Die Zuordnung ist in Abbildung 2,3 dargestellt, Betriebssicherheit repräsentiert für den Au­tomobilhersteller die zu erfüllende Mindestvoraussetzung, bevor für ein Modell die Serien­produktion zugelassen wird, Fehler in der Betriebssicherheit können zu Rückrufaktionen führen, wie beispielsweise aufgrund von Problemen mit der Servolenkung, den Gaspedalen und den Bremsen bei verschiedenen Fahrzeugreihen von Toyota im Jahr 2010, „Insgesamt wurden über 8,5 Millionen Fahrzeuge in mehreren Aktionen zurückgerufen“ |Weyl2, S,37|, Da hiermit nicht nur finanzielle Belastungen, sondern auch ein Reputationsverlust verbunden sind |Coo07, S,163|, nimmt die Betriebssicherheit während der Entwicklung und der Tests zunächst die oberste Rolle ein.

Jedoch ist keine Sicherheit geboten, wenn nicht möglichst viele Anwendungsfälle und Ge­brauehsfehler - die Gebrauchssicherheit - berücksichtigt sind: Eine fast vollständige Ge­brauchssicherheit ist nur nach dem „Рока Yoke“-Prinzip möglich, welches u.a, dafür sorgen kann, dass das Zapfventil an einer Diesel-Zapfsäule nur in ein Dieselfahrzeug eingeführt wer­den kann sowie dass der Tankvorgang bei vollem Tank automatisch beendet wird |SysO(, S.102|. Im Fahrzeug selbst helfen Fahrerassistenzsysteme, wie beispielsweise das Antiblo­ckiersystem (ABS), das Elektronische Stabilitätsprogramm (ESP), der Bremsassistent oder auch der Abstandsregeltempomat, bereits traditionellerweise in verschiedenen Situationen; künftige Systeme könnten beispielsweise durch mehr Kontakt zum Fahrer auch weitere Be­dienungsfehler vermeiden. Ein Beispiel für Betriebsfehler ist das Problem, dass 41 % der 18- bis 29-jährigen Autofahrer in Deutschland während der Fahrt Textnachrichten schreiben oder lesen |GD14|, Ein vorgeschriebener Anschluss des Smartphones an das Multimedia-System und die Nutzung über Sprachbefehle könnte diese Risiken senken, jedoch neue Gefahren in sieh bergen, die in Abschnitt 4,2 analysiert werden. Ein weiteres grundlegendes Problem liegt darin, dass die Betriebssicherheit in der Unterhaltungselektronik eine vergleichsweise untergeordnete Rolle spielt und den Anforderungen des Automobils nicht genügt. Ebenso kann die Bedienung im Automobil gewöhnungsbedürftig sein und zu bisher unbekannten Gebrauehsfehlern durch den Anwender führen.

Weitere neuartige Gefahren gehen jedoch besonders von mutwilligen Hackerangriffen auf das Fahrzeug aus, welche in den Bereich des Angriffsschutzes fallen |VM14|,

Es besteht damit insgesamt die Gefahr, dass durch die Vernetzung des Fahrzeugs mit Konsu­melektronik die Betriebssicherheit, die Gebrauchssicherheit und der Angriffsschutz reduziert werden. Dabei ist anzumerken, dass der Fokus dieser Arbeit zur Konzeption einer sicheren Fahrzeugarchitektur auf Security liegt, während Safety lediglich in ihrer Schnittmenge mit Security betrachtet wird.

Neben der Unterscheidung zwischen Betriebssicherheit, Gebrauchssicherheit und Angriffs­schutz sind die folgenden Sicherheitsanforderungen an die Fahrzeugarchitektur zu erklären. Diese werden zur Analyse der Gefahrenpotentiale und zur Bewertung der vorgeschlagenen Konzepte herangezogen.

2.4.2 Physische Sicherheit von Mensch, Fahrzeug und Umgebung

Die traditionelle Anforderung an ein Fahrzeug stellt die physische Sicherheit dar: Sowohl Betriebs- als auch Gebrauchssicherheit und Angriffsschutz sollen das Leben und die Ge­sundheit der Insassen, den Zustand des Fahrzeugs sowie die Unversehrtheit von Passanten, anderen Verkehrsteilnehmern und der Infrastruktur gewährleisten. An die Fahrzeugarchitek­tur werden damit hohe Erwartungen gestellt [ + , S.l],

Betrachtet man beispielsweise eine Applikation, die durch einen Klick vom Smartphone aus das Ein- und Ausparken des Fahrzeugs erlaubt, so wird die Information zunächst im Smart­phone verarbeitet, dann auf kabellosem Wege zum Fahrzeug übertragen, dort von externer Seite aufgenommen und vom Programm für das automatische Parken so an die Steuergeräte übersetzt, dass das Fahrzeug die notwendigen Bewegungen ausführt. Auf diesem Kommuni­kationsweg bestehen mehrere Fehlerquellen, wie beispielsweise

- Diebstahl des Smartphones und Fremdbedienung

- versehentliches Bedienen des Smartphones

- Kompatibilitätsschwierigkeiten zwischen der Applikation und dem Betriebssystem des Smartphones

- ungesicherte kabellose Verbindung

- Fahrzeugteile sind umgebaut worden und nicht kompatibel mit dem System

- falscher Befehl vom Fahrzeug erfasst

- auf dem Fahrzeug ist eine andere Version der Applikation installiert

- das automatische Parken funktioniert nicht fehlerfrei an diesem Ort

Eine solche Applikation, die für den Benutzer an der Oberfläche ganz simpel erscheint, verbirgt also einen Komplex aus verschiedenen Medien, die alle aufeinander abzustimmen sind und eine Gefahr für die physische Sicherheit repräsentieren können.

2.4.3 Keine Ablenkung des Fahrers

Durch die Elektronifizierung des Automobils entstand die Anforderung, die Ablenkung des Fahrers von der Fahrtätigkeit - auf Englisch „driver’s distraction“ - so gering wie möglich zu halten. Dabei kategorisiert die „National Highway Traffic Safety Administration“ (XHTSA) Ablenkungen des Fahrers als „visuell“, „auditiv“, „biomechanisch“ oder „kognitiv“ |RMGG0C. S.l|.

- Visuelle Ablenkungsquellen lenken den Blick von der Fahrbahn, Im Falle eines Multimediasystems gehören dazu insbesondere ein flackernder Bildschirm und visuelle Xavigationsauskiinfte,

- Sämtliche Geräusche, die für den Fahrer überraschend auftreten, sind auditive Ab­lenkungen und können zu einer fehlerhaften und riskanten Reaktion wie das Umreißen des Lenkrads führen. Beginnend bei der Meldung einer geringen Tankfüllung über das Radio bis hin zum Xavigationsgerät beinhaltet das nieht-vernetzte Automobil bereits auditive Ablenkungsquellen, Durch ein neues app-basiertes Multimedia-System kom­men das Vorlesen von Nachrichten oder weitere Signale und Spraehmitteilungen hinzu. Als neue Ablenkungsquelle, die seit der Einführung der Software „Síri“ im Jahre 2011 zum Standard in der Unterhaltungselektronik gehört |Mozl , S,24|, lässt sich hier das Diktieren einer Nachricht und sämtliche Steuerung über Sprache verorten. Die­se Funktionalität könnte beispielsweise unter streitenden Insassen dazu führen, dass verschiedene Befehle gleichzeitig gegeben werden.

- Eine biomechanische Ablenkung entsteht dadurch, dass der Fahrer mit seinem Körper bestimmte Bewegungen ausführt, die seine Konzentration auf die Fahrt be­einträchtigen, Traditionellerweise gehören dazu die Bedienung eines Smartphones, des Radios oder des Xavigationsgerätes durch Handbewegungen genauso wie das Suchen nach Gegenständen im Fahrzeug, In vielen Geräten soll dies dadurch unterbunden wer­den, dass die Berührung der Bildschirmoberfläche für den Fahrer nur im Stand möglich ist oder sämtliche Steuerung über Sprache erfolgt. Allerdings kann die Funktionalität, dem Fahrer nur im Stand die Bildschirmberührung zuzulassen den Beifahrern jedoch auch während der Fahrt, dazu führen, dass der Fahrer während der Fahrt versucht, nach dem Beifahrerbildschirm zu greifen,

- Eine kognitive Ablenkung liegt vor, wenn der Fahrer in Gedanken versunken oder müde ist. Durch Müdigkeitsmessungen könnte der Fahrer gewarnt werden, bevor er am Steuer einschläft |BSEW1 , S,39|, Vor Fehlverhalten durch Tagträume schützt aller­dings kein Sensor,

Daraus lässt sich schließen, dass Applikationen, die auf einem mobilen Gerät ungefährlich sind, sich im Automobil zur Gefahrenquelle für die Aufmerksamkeit des Fahrers entwickeln können. Gleichzeitig besteht jedoch auch die Möglichkeit, durch gewisse Funktionalitäten die Ablenkung zu verringern.

2.4.4 Human-Machine-Interface (HMI)-Hoheit

Die Dienste eines nieht-vernetzten Automobils befinden sich vollständig im Einflussgebiet des OEM, Aufgrund der Öffnung der Fahrzeugarchitektur wird zwar das Funktionsangebot als absolute Größe erweitert. Allerdings wird das Einflussgebiet des OEM als relative Größe verringert, da andere Akteure besonders aus der Unterhaltungselektronik, der Applikations­entwicklung und der Telekommunikation an Einfluss gewinnen. Der OEM stellt daher die Anforderung an die Kooperationsverträge und die Fahrzeugarchitektur, so viel eigenen Spiel­raum wie möglich zu wahren und wegen fehlender Expertise so viele Aufgaben auszugliedern wie nötig (siehe Abschnitt 2,2).

Die Bedienungsoberfläche am Armaturenbrett - das Human Machine Interface (HMI) - spie­gelt dabei auch den Grad der Öffnung gegenüber den anderen Akteuren wider - daher kann diese Anforderung als „HMI-Hoheit“ bezeichnet werden: Bei einem weiterhin vollständig ge­schlossenen System würde der OEM ausschließlich eigene Applikationen anbieten, die auf einem eigens programmierten Betriebssystem mit durchgängig gleichmäßigem Layout ver­wendet würden. Die Anbindung des Fahrzeugsystems an ein Smartphone oder Tablet sowie die Verwendung eines Browsers und die tarifliche Regelung des Internetzugangs impliziert bereits die Abgabe einzelner Einflussbereiche und die Aufnahme gewisser Sicherheitsrisiken durch die Vernetzung, Eine besonders relevante Rolle spielt dabei das optische Erscheinungs­bild der Bedienungsoberfläche: Ein Hersteller, der Automobile als Luxus- und High-End- Produkte entwickelt, legt Wert auf eine einheitliche Optik des Armaturenbretts, weshalb eine von Drittanbietern programmierte Applikation mit unpassenden Elementen die Seriosi­tät des OEM gegenüber dem Kunden reduzieren ließe. Im Gegensatz dazu kann es für den Nutzer von Vorteil sein, die gewohnte Bedienoberfläche des Smartphones auch im Fahrzeug wiederzufinden. Dabei kann eine intuitive Bedienung insbesondere angesichts der Gebrauchs­sicherheit vor Fehlbedienung schützen |BSEW13, S,10|.

2.4.5 Datenschutz und Datensicherheit

Im Kontext dieser wissenschaftlichen Arbeit bezeichnet „Datenschutz“ den Schutz einer na­türlichen Person vor der Verletzung von Persönlichkeitsrechten |WHB12, S,246|, Im Multi­media-System gibt der Kunde dafür an, welche Daten in welcher Situation von welchem Akteur gesammelt werden dürfen,

„Datensicherheit“ hingegen bezeichnet den Schutz von hardware-, software- und anwendungs­bezogenen Daten vor Verlust, Zerstörung und Missbrauch durch Unbefugte |WHB1: , S,246|, Dies definiert die Anforderung an das System, dass Datenschutzangaben des Kunden nicht missbraucht sowie Vertraulichkeit im Hinblick auf Nutzung, Weitergabe und Veröffentlichung der Daten sichergestellt werden. Neben dieser Integrität auf moralischer Ebene seitens al­ler Akteure, sind auch angemessene technische Mechanismen zur Speicherung, Freigabe und Übertragung von Daten zu gewährleisten.

Alles in allem lässt sieh unterscheiden, dass Datenschutz die Person schützt, während Da­tensicherheit die virtuellen Daten- und Informationseinheiten schützt. Viele Probleme und Lösungen fallen jedoch in beide Bereiche, sodass eine große Schnittmenge besteht |WHB12, S.246I.

Während die Forderung nach „physischer Sicherheit“ bereits im nicht-vernetzten Automobil besteht, gelangt die Thematik „Datenschutz und Datensicherheit“ aus dem Social-Media- Bereich in das Fahrzeug |Taml2, S,10|, Aus der Schnittstelle von Automobil und mobilen Geräten der Unterhaltungselektronik wiederum gewinnen die Sicherheitsanforderungen „kei­ne Ablenkung des Fahrers“ und „HMI-Hoheit“ an Relevanz, Inwiefern ein OEM die Betriebs­sicherheit, Gebrauchssicherheit und den Angriffsschutz des angebotenen Fahrzeugs gemäß der vier Sicherheitsanforderungen an die Fahrzeugarchitektur gewährleisten kann, hängt da­von ab, wie viel Spielraum den anderen Akteuren gegeben wird. Unterschiedliche bereits bestehende Systeme präsentieren die Vielfalt an Optionen, denen sieh der OEM gegenüber sieht.

2.5 Übersicht bestehender Multimediasysteme

Viele Kraftfahrzeughersteller haben sieh bereits für erste Systeme entschieden, die Infotain­ment und integrierte Dienste durch Vernetzung des Fahrzeugs mit Konsumelektronik er­möglichen |BSEW1 , S.39 ff.I. Aufgrund der Vielzahl an Features, Bepreisungsoptionen und eingesetzten Technologien variieren die endgültigen Lösungen der OEMs und Drittanbie- ter. Trotzdem lassen sie sieh auf drei grundlegende Systemarten zurückführen: „brought-in“, „embedded“ und „hybrid“.

2.5.1 Brought-In-Systeme

In einem „Brought-In-System“ werden sowohl der Internet-Zugang als auch sämtliche An­wendungen auf dem Smartphone zur Verfügung gestellt. Dieses in das Fahrzeug eingebrachte - brought-in - Gerät verbindet sieh mit oder ohne Kabel mit dem in die Fahrzeugarmatur eingebauten System, Im Regelfall sind dann die Smartphone-Applikationen auf dem einge­bauten Bildschirm bedienbar, laufen aber vollständig auf dem Smartphone, Das Fahrzeug dient dafür als externes Ein- und Ausgabegerät,

Da das HMI die Ausführung einer Applikation vornimmt und die Aktivitäten einheitlich dar­stellt, können Smartphones unterschiedlicher Hersteller beispielsweise über standardisierte Schnittstellen verwendet werden |BSEW13, S,38|, Ebenso wird die Open-Source-Entwicklung von Applikationen unterstützt. Gleichzeitig ist die Implementierung einer HMI, die mit allen Betriebssystemen kommunizieren kann, nicht nur schwer zu realisieren, sondern auch mit Ri­siken verbunden: Die von Drittanbietern programmierten Applikationen auf dem Smartphone können Malware oder andere unkontrollierte und unerwünschte Funktionalitäten beinhalten, welche die Sicherheitsanforderungen gefährden (siehe Abschnitt 4,1,2),

2.5.2 Embedded-Systeme

In einem Embedded-System sind sämtliche Applikationen auf dem eingebauten Multimedia­System installiert und die Internetverbindung wird ebenfalls über das Fahrzeug bereitgestellt. Ein Smartphone wird nicht benötigt |BSEW13, S,38|,

Der OEM hat eine hohe Kontrolle über das System, lässt nur eigene Applikationen zu und kann auf die Sicherheitsanforderungen besondere Rücksicht nehmen. Im idealisierten Fall müssen alle Applikationen vom OEM erstellt und geprüft werden. Allerdings besit­zen Fahrzeughersteller bisher geringere Kompetenzen in der App-Programmierung in kurzen Entwicklungs-Zyklen als Drittanbieter (siehe Abschnitt 4,1,1),

2.5.3 Hybrid-Systeme

In einem Hybrid-System können sowohl OEM-eigene Applikationen des eingebauten Mul­timediasystems benutzt sowie die Anwendungen auf einem Smartphone eingebunden wer­den, Ob die Internetverbindung über das Fahrzeug oder über das mobile Gerät erfolgt, ist nicht eindeutig. Insgesamt werden die Vorteile, aber auch Xachteile von Brought-In- und Embedded-Systemen vereint | 5SEW13, S,38|.

Zahlreiche Applikationen von Drittanbietern können genutzt, aber wahrscheinlich nicht je­des Endgerät mit dem Fahrzeug verbunden werden. Das System wird komplexer, da auch Schnittstellen zwischen OEM-eigenen und -fremden Anwendungen entstehen und Tarife un­klar sein können. Dem Kunden, dem OEM und den Drittanbietern bietet es jedoch eine höhere Flexibilität,

2.5.4 Beispiele

Exemplarisch werden bestehende Systeme den drei Typen zugeordnet und näher beschrieben,

2.5.4.1 MirrorLink

„MirrorLink“ des Car Connectivity Consortiums entspricht der vorhergehenden Definition eines Brought-In-Systems, Das Infotainment-System spiegelt auf dem eingebauten Display

genau die Oberfläche des Smartphones wider. Jede Benutzung auf dem Display wird an das Smartphone umgeleitet und die gewünschte Funktionalität dort ausgeführt. Um der Sicherheitsanforderung „keine Ablenkung des Fahrers“ gerecht zu werden, können die meisten Programme ausschließlich im Stand verwendet werden, Xur zertifizierte Applikationen sind während der Fahrt zugelassen, beispielsweise ein Internetradio-Player, eine Location-Suche und eine Spritsparhilfe |Grul4|.

Das System findet unter anderem Anwendung im VW Polo, VW Golf, bei Honda, Toyota, Peugeot, Citroen und in Aftersales-Lösungen |Shel4a| und |Shel4b|, Alfred Tom vom Car Connectivity Consortium erklärt: „Die Idee ist, das Smartphone des Fahrers als erschwing­liche Möglichkeit zu nutzen, sieh im Fahrzeug mit der Cloud zu verbinden, |,,,| Bis jetzt haben Automobilhersteller Vernetzungstechnologien nur in teureren Modellen in etablierten Märkten präsentiert. Wir brauchen erschwinglichere Lösungen an Orten wie China, Indi­en, Russland, Osteuropa und Lateinamerika “ |WG11|, Dies deutet daraufhin, dass solche Brought-In-Systeme derzeit eher für Low-End-Fahrzeuge konzipiert werden.

2.5.4.2 Apple CarPlay und Android Auto

Der Einfluss und die Expertise der traditionellen Hersteller von Konsumelektronik und App- Entwickler wird besonders anhand der Systeme „CarPlay“ von Apple und „Android Auto“ von Google sichtbar | 3SEWL:, S,43|.

Beide Unternehmen stellen ein hybrides System mit Brought-In-Tendenz vor: „Es gab Spe­kulationen, dass die Smartphone-Apps einfach nur auf dem Bildschirm gespiegelt würden. Dies ist sicherlich nicht der Fall,“ |Xell4| erklären Entwickler von Android Auto im Sillieon Valley, Diese Aussage ist damit zu erläutern, dass Apple CarPlay und Android Auto ähnlich zu MirrorLink darauf basieren, dass ein Smartphone bzw, iPhone über ein USB-Kabel mit dem Multimedia-System des Fahrzeugs verbunden werden muss, um die Funktionalitäten nutzen zu können. Als weitere Parallele zu MirrorLink ist zu nennen, dass insbesondere die Dienstarten Xavigation und Infotainment zur Verfügung gestellt werden, während Fahrzeug­bezogene Dienste vom OEM präzise in ihren Zugriffsmögliehkeiten eingeschränkt oder gar nicht erst vorgesehen sind |WieU , S,7|.

Der Unterschied zu MirrorLink liegt jedoch darin, dass über Spraehsteuerung beispielweise mit Siri bei Apple CarPlay die Bedienung auch während der Fahrt möglich ist. Dafür sind am Lenkrad zusätzliche Bedienelemente angebracht |Gool4|, |Appl4|, um Befehle und An­forderungen anzukündigen. Laut eigener Angaben wurden zahlreiche Applikationen auf eine Bedienung im Fahrzeug hin modifiziert |Appl4|, Allerdings sind die Systeme nicht mit jedem Gerät kompatibel, sondern erwarten die Betriebssysteme Android bzw, iOS, Daher planen viele Automobilhersteller - wie Audi - CarPlay und Android Auto in bestimmten Fahrzeugen gleichzeitig unterzubringen |Audl4|, Dieses Vorgehen, falls technisch möglich, scheint nahe­liegend, denn 95% aller Smartphones weltweit verwenden Android oder iOS als Betriebs­system |Xell4|, Kein Kunde, kein Automobilhersteller und letztlich auch weder Apple noch Google möchten die Entscheidung für den Kauf eines Fahrzeugs von dem Betriebssystem des Smartphones oder umgekehrt abhängig machen |Frel4|, Zudem bestehen Android- und iOS-Betriebssysteme in verschiedenen Versionen, die untereinander bereits nicht kompatibel sind.

2.5.4.3 BMW ConnectedDrive

BMW ConnectedDrive repräsentiert ein hybrides System mit Embedded-Tendenz: Das Fahr­zeug besitzt eine integrierte SIM-Karte, stellt die Internetverbindung selbst her und wird so zu einem eigenen mobilen Endgerät. Zwar lässt sieh auch im BMW das Smartphone an- sehließen, um Kontakte und Musik abzurufen, aber der Fokus liegt eindeutig auf einer von den üblichen Anbietern unabhängigen Plattform.

Anders als die zuvor genannten Systeme werden sämtliche Applikationen von BMW selbst programmiert, eingebunden und auf Sicherheit während der Bedienung und der Fahrt ge­prüft. Dabei existieren neben den üblichen Infotainment-Anwendungen auch fahrzeugbezo­gene Dienste: Mit „MyBMW Remote“ können über das Smartphone Funktionen zur Kli­matisierung, Türen auf- und zusehließen, Hupe oder Lichthupe aktiviert werden. Für das Elektroauto BMWi wird auch der Reiehweitenassistent und die Ladesäulenanzeige verwen­det, um eine möglichst effiziente Route zu berechnen. Darüber hinaus werden auch Komfort- und Fahrassistenzsysteme vernetzt, wie beispielsweise der Abstandsregler, Real Time Traf­fic Information zur Stauumfahrung oder eine Wärmebildkamera für die nächtliche Fahrt |BMW13|.

Die Tatsache, dass alle Anwendungen von BMW erstellt werden, erlaubt erst eine weit­reichende Verwendung fahrzeugbezogener Dienste. Auch Mercedes-Benz |Merl4| und Audi |Audl4| weisen Multimedia-Systeme auf, die ohne Smartphone OEM-eigene Applikationen und Internetzugriff ermöglichen. Dies wiederum lässt darauf schließen, dass für High-End- Fahrzeuge Embedded-Systeme bevorzugt werden.

Abbildung in dieser Leseprobe nicht enthalten

3. Technische Grundlagen der Fahrzeug- und Smartphone-Architekturen

Unabhängig von den zuvor beschriebenen bestehenden Systemen werden in dieser Arbeit Konzepte für eine vernetzte Fahrzeugarchitektur erarbeitet, welche die Sicherheitsanforde­rungen möglichst gut berücksichtigen. Bevor diese Modelle allerdings beschrieben werden können, sind zunächst einzelne IT-teehnisehe Bereiche aus der Fahrzeugelektronik, der Kon­sumelektronik und der PC-Welt zu erläutern. In diesem Kapitel werden diese technischen Grundlagen - unterteilt auf vier Ebenen - behandelt.

3.1 Betrachtung auf vier Ebenen

Um ein übergreifendes Konzept für ein Multimedia-System im Fahrzeug erstellen zu können, wird der Kommunikationsweg zwischen einem externen vernetzten Gerät bis hin zum Steu­ergerät grob unterteilt. Dabei kristallisieren sieh die folgenden vier zu betrachtenden Ebenen heraus, die in Abbildung 3,1 zu erkennen sind:

1, Physische Ebene: Auf der physischen Ebene sind die Steuergeräte, Sensoren und Ak­toren angesiedelt, die letztlich die erforderlichen Funktionen im Fahrzeug ausführen.

Dazu gehören neben der Bewegung des Fahrzeugs auch Komfort- und Sicherheitsassis­tenz sowie Multimedia-Anwendungen,

2, Physische Datenübertragungsebene: Im Fahrzeug erfolgt die Datenübertragung physisch über serielle Kommunikationssysteme, In der Computerwelt gilt jedoch Ether­net - keine serielle Kommunikationsform - als Standard, Beide Technologien werden in Abschnitt 3,5 vorgestellt,

3, Software-Datenübertragungsebene: Damit die physisch übertragenen Daten nicht unerlaubt gelesen, manipuliert oder generiert werden können, wirken auf der Software­Datenübertragungsebene kryptographische Verfahren, welche sowohl im Fahrzeug als auch bei der Kommunikation mit der Umwelt verwendet werden können. Auf diese Ebene fallen aber auch Protokolle, die das Routing und das Segmentieren von Daten­paketen übernehmen,

4, Software-Ebene: Das Multimedia-System soll es ermöglichen, Dienste analog der Apps auf einem Smartphone nachzuladen. Daher entspricht die Software-Architektur zum Teil der eines Smartphones, Aus diesem Grund spielen auf der Software-Ebene insbesondere Virtualisierung und Schnittstellenprogrammierung eine relevante Rolle,

Es sei anzumerken, dass weder das Siebenschichtenmodell aus der Computerwelt noch das Dreischichtenmodell aus der Fahrzeugelektronik, die im Anschluss erläutert werden, direkt auf die vier Ebenen projizierbar sind. Trotzdem sind diese Modelle implizit in den vier Ebenen enthalten. Aufgrund des umfassenden Charakters dieser vier Ebenen dienen sie der Gliederung in diesem und den nachfolgenden Kapiteln,

3.2 Siebenschichtenmodell

Wie jedes vernetzte elektronische Gerät muss auch ein vernetztes Fahrzeug mit Geräten ande­rer Hersteller Daten austauschen können |Reil: , S,2|, Dies ist bei Einhaltung des standardi­sierten „Open Systems Interconnection“-Kommunikationsmodells (OSI-Kommunikationsmo- dell) realisierbar, welches 1983 von der „International Standardization Organization“ (ISO) für einen reibungslosen Kommunikationsfluss festgelegt wurde | VHB12, S.58 ff,|. Es handelt sieh um eine Schichtarchitektur aus sieben Schichten, bei der - wie in Abbildung 3,2 dar­gestellt - ein Datum in jeder Schicht des Senders einen weiteren Header erhält, der in der gleichen Schicht des Empfängers gelesen und wieder abgelegt wird. Bildhaft lässt sieh der Mechanismus als Versand eines Briefes vorstellen: Das Datum repräsentiert einen Brief, der von jeder Schicht in einen eigenen Briefumschlag mit dem Header als Empfängeranschrift verpackt wird, welcher nur von derselben Schicht auf der Empfängerseite geöffnet werden kann.

Jede Schicht übernimmt eine eng begrenzte Aufgabe |OH13, S,17|, In Anbetracht verschiede­ner Anwendungsfälle und Anforderungen bezüglich Sicherheit, Zuverlässigkeit und Effizienz bestehen verschiedene Protokolle pro Schicht, die auf unterschiedliche Weise die schichtspe­zifische Aufgabe erfüllen |OH13, S.21 Abbildung!.

• Schicht 7 - Anwendungsschicht: realisiert die eigentliche Schnittstelle zwischen Mensch und Computer z.B, die Dateneingabe und -ausgabe ,

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 3,2: ISO/OSI-Kommunikationsmodell (nach |WHB12, S,58 ff.|

- Schicht 6 - Darstellungsschicht: bringt die Daten auf ein einheitliches Format z.B. über Datenkompression oder Verschlüsselung,

- Schicht 5 - Sitzungsschicht: synchronisiert das Zusammenspiel mehrerer Stationen und legt fest, wie eine Sitzung zeitlich abzulaufen hat z.B, Aufforderung zum Senden eines Passwortes, Senden des Passwortes, Bestätigung des Passwortes, Um Zusammen­brüche einer Sitzung zu beheben, werden Check Points eingeführt, an denen die Sitzung wieder synchronisiert werden kann, ohne die Übertragung erneut starten zu müssen,

- Schicht 4 - Transportschicht: bereitet die Daten für Transport und Empfang auf und übernimmt z.B, die Segmentierung des Datenstroms sowie Stauvermeidung bei der Übertragung, Die bekanntesten Protokolle auf dieser Schicht repräsentieren das „Transmission Control Protocol“ (TCP) und das „User Datagram Protocol“ (UDP) ,

- Schicht 3 - Vermittlungsschicht: stellt durch Routing die Verbindung zwischen zwei beliebig miteinander verbundenen Xetzwerkknoten her, wobei die Datenpakete von auf dem Weg liegenden Knoten weitergeleitet werden müssen. Die Vermittlungssehieht stellt dafür netzwerkiibergreifende Adressen, den Aufbau und die Aktualisierung von Routingtabellen sowie die Fragmentierung von Datenpaketen bereit. Das bekannteste Protokoll auf dieser Schicht stellt das „Internet Protocol“ (IP) dar ten auf den einzelnen Teilstrecken des gesamten Übertragungsweges sicher. Beispiels­weise wird der Bitdatenstrom in Blöcke aufgeteilt, denen Prüfsummen hinzugefügt werden. So sind fehlerhafte Blöcke vom Empfänger verwerfbar oder korrigierbar,

• Schicht 1 - Bitübertragungsschicht: repräsentiert das physische Übertragungsme­dium z.B, das Xetzwerkkabel oder Funk sowie mechanische und elektrische Hilfsmittel, z.B, elektrische und optische Signale oder elektromagnetische Wellen,

3.3 Dreischichtenmodell

Alle sieben Sehiehten des OSI-Kommunikationsmodells sind fiir das vernetzte Fahrzeug re­levant, Im unvernetzten Fahrzeug hingegen wird traditionell eine vereinfachte Version des Standardreferenzmodells fiir die Elektronik verwendet: das Dreischichtenmodell.

Im Dreischichtenmodell wird der Datenaustausch zwischen elektronischen Steuergeräten im Fahrzeug realisiert |Reil2, S,4|, Um beispielsweise Informationen über den Betriebszustand eines Steuergerätes mit anderen Steuergeräten auszutauschen, sind nicht alle sieben Sehiehten des OSI-Kommunikationsmodells notwendig, sondern die in Abbildung 3,3 dargestellten drei IReil2, S.4 ff.I:

- Schicht 1 - Bitübertragungsschicht: realisiert die physische Busankopplung und Signalübertragung mittels eines Transceivers, der die zu sendenden Daten in einen Spannungspegel umsetzt und umgekehrt zu empfangende Daten in Eingangssignale übersetzt,

- Schicht 2 - Sicherungsschicht: realisiert Adressierung, Nachrichtenbildung, Buszu­griff, Synchronisation, Fehlererkennung und Fehlerkorrektur mittels eines Kommuni­kationskontrollers, der die Daten aus dem Mikrocontroller für die Weitergabe an den Transceiver kapselt,

- Schicht 7 - Anwendungsschicht: übernimmt Aufgaben der nicht berücksichtigten Schichten des OSI-Kommunikationsmodells,

Sehiehtübergreifend agiert das Netzwerkmanagement, das beispielsweise die Netzwerkinitia­lisierung sowie das Schlafenlegen und Aufwecken des Netzwerkes übernimmt |ReiE , S,51|.

Im Hinblick auf die Fahrzeugarchitektur in einem vernetzten Fahrzeug ist gefordert, dass die nach außen gerichtete Kommunikation im Siebenschichtenmodell und die konventionel­le nach innen gerichtete Kommunikation im Dreischichtenmodell so miteinander verknüpft werden, dass die Sicherheitsanforderungen eingehalten werden. Für den Fahrzeughersteller ist besonders relevant, dass ein von außen einwirkendes System keine unerwünschte oder gar schädliche Funktionalität im Bordnetz des Automobils ermöglicht. Damit eine solche Verein­barkeit der Kommunikation nach innen mit der nach außen möglich ist, werden im Folgenden die dafür notwendigen technischen Grundlagen des Fahrzeugs und der Konsumelektronik auf vier Ebenen erläutert.

3.4 Grundlagen Ebene 1 - Physische Ebene

Die physische Ebene ist definiert als die Gesamtheit aller Steuergeräte, Sensoren, Akto­ren und Kabel im Fahrzeug: Steuergeräte sind elektronische Module, die an verschiedenen Hardware-Komponenten im Fahrzeug Messungen, Regelungen und Steuerung übernehmen |WR1 , S.204|. Dazu zählen beispielsweise das Bremssystem, die Motorsteuerung, das Aus­lösen von Airbags, das Kontrollieren und Xachregeln der Motorzündung oder die Überprü­fung, ob alle Türen geschlossen sind |WRF , S.190|. Abhängig von Hersteller, Fahrzeugtyp und Kundenanforderungen befinden sieh in einem Fahrzeug zwischen 10 und 70 Steuergerä­ten, wobei Low-End-Fahrzeuge weniger Steuergeräte besitzen, High-End-Fahrzeuge dagegen mehr I [5]SF0 , S.9|.

Messungen werden von Sensoren durchgeführt. Diese ermitteln technische Ist-Werte zur Lauf­zeit und vergleichen diese mit den im Steuergerät bekannten Soll-Werten. Im Falle einer kri­tischen Überschreitung des Ist-Wertes gegenüber dem tolerierten Soll-Werte-Bereieh regeln Aktoren korrigierend den physischen Prozess nach. Diese Messungs- und Steuerungslogik übernimmt der Mikrocontroller im Steuergerät, auf dem das korrigierende Programm läuft |WR1 , S.37|.

3.5 Grundlagen Ebene 2 - Physische Datenübertragungs­ebene

Die verschiedenen Steuergeräte aus der physischen Ebene müssen für zahlreiche Anwen­dungen miteinander kommunizieren. Das Versenden von Information erfolgt innerhalb des Fahrzeugs über die Bussysteme CAX, LIX, FlexRay und MOST sowie in Zukunft möglicher­weise auch über Ethernet. Xeben diesen fünf Kommunikationsprotokollen werden in diesem Abschnitt insbesondere auch die allgemeinen technischen Eigenschaften serieller Bussysteme sowie ihre Vor- und Xachteile beschrieben.

3.5.1 Technische Eigenschaften von Bussystemen

Die im Fahrzeug eingesetzten Bussysteme unterscheiden sieh dadurch, dass sieh auf der Bitübertragungsschicht und der Sicherungsschicht unterschiedliche Konzepte für die Eigen­schaften „Topologie“, „Interaktionsstruktur“, „Adressierung“, „Buszugriffsverfahren“, „Daten­sicherung“, „Synchronisation“ und „Physikalische Übertragung“ implementieren lassen |ZS11, S,9-34|, Diese Eigenschaften werden im Folgenden erläutert.

3.5.1.1 Topologie

Die Topologie beschreibt die Struktur der Verbindungen unter den Kommunikationsteilneh­mern in seriellen Kommunikationssystemen |ZS1 , S,13|, Dabei werden die drei in Abbildung 3.4 gezeigten besonders häufig verwendet.

Abbildung in dieser Leseprobe nicht enthalten

Bustopologie Sterntopologie Ringtopologie

Abbildung 3,4: Topologiearten (nach |ZS1 , S,13|)

1, Bustopologie: Jeder Kommunikationsteilnehmer greift mit einer eigenen Verbindung auf ein gemeinsames Medium zu, ohne über eine direkte Verbindung mit anderen Kom­munikationsteilnehmern kommunizieren zu können. Die Kommunikation erfolgt indi­rekt über die gemeinsame Verbindung - den Bus |ZS11, S,13|,

2, Sterntopologie: Ein Kommunikationsteilnehmer repräsentiert das Zentrum, an den alle anderen Kommunikationsteilnehmer sternförmig angesehlossen sind. Analog zur Master-Slave-Interaktion (siehe Abschnitt 3,5,1,2) steuert der Knoten im Zentrum - der Master - die Zugriffe der Slaves, die untereinander stets nur über den Master Da­ten austausehen können. Wird diese Struktur hierarchisch fortgesetzt, so entsteht eine Baumtopologie mit einem Wurzelknoten, Zwisehenknoten und verzweigten Blattknoten |ZS1 , S.13|.

3, Ringtopologie: Die Kommunikationsteilnehmer sind in einer Kette nacheinander an­geordnet, sodass jeder Knoten direkte Verbindungen zu genau zwei anderen Knoten besitzt. Der Zugriff wird über ein als „Token“ bezeiehnetes im Ring zirkulierendes Zei­chen gewährt IZS11, S,13|,

Wie aus Tabelle 3,1 ablesbar, besteht bei der Bustopologie der geringste Verkabelungsauf­wand und es lassen sieh einfach neue Kommunikationsteilnehmer an den Bus ansehließen. Während der Bus nicht für lange Kabellängen ausgerichtet ist, eignet sieh die Ringtopolo­gie mit stets neuen Verbindungen zwischen den Steuergeräten für weit entfernte Busknoten, Einen Nachteil besitzen alle Topologien: Das gesamte System kann ausfallen. Dies geschieht bei der Bustopologie, wenn der Bus ausfällt; bei der Sterntopologie, wenn der Master ausfällt; bei der Ringtopologie, wenn ein beliebiger Knoten ausfällt |VA14|,

3.5.1.2 Interaktionsstruktur

Die Interaktionsstruktur in einem seriellen Bussystem beschreibt, in welchem Verhältnis Kommunikationspartner wie die elektronischen Steuergeräte eines Automobils miteinander kommunizieren dürfen |Rei 11 , S,6|,

1, Client-Server-Interaktion: Ein Server stellt einen Dienst bereit, der vom Client explizit angefordert wird. Nach erfolgreicher Bestätigung des Dienstes durch den Server können Daten zwischen Client und Server in beiden Richtungen ausgetauseht werden IReil2, S.6|.

Abbildung in dieser Leseprobe nicht enthalten

Tabelle 3.1: Vor- und Nachteile verschiedener Bustopologien

2, Producer-Consumer-Interaktion: Im Gegensatz zur Client-Server-Struktur wird der Sender nicht zum Versand aufgefordert, sondern stellt anderen Busknoten per Mul­ticasting oder Broadcasting Daten zur Verfügung, Der Empfänger entscheidet selbst, ob er die Daten nutzt; eine Xutzungsbestätigung als Antwort wird nicht versandt, wie in Abbildung 3,5 zu sehen ist. Als „Publisher-Subscriber“-Interaktion bezeichnet man den Spezialfall, dass die Datenbereitstellung nach vorheriger Aufforderung erfolgt IReil2, S.6|.

3, Multi-Master-Interaktion: Sämtliche Busknoten sind gleichberechtigt beim Zugriff auf den gemeinsamen Bus |Reil2, S,6|,

4, Master-Slave-Interaktion: Im Gegensatz zur Multi-Master-Interaktion sind die Bus­knoten nicht gleichberechtigt, da ein als Master eingesetzter Busknoten für die anderen als Slaves dienenden Busknoten zentral den Buszugriff steuert |Reil2, S,6|,

5, Bedarfsorientierte Interaktion: Jeder Busknoten darf zu jedem Zeitpunkt bei Be­darf auf das gemeinsame Bussystem zugreifen |Reil2, S,6|,

6, Zeitgesteuerte Interaktion: Im Gegensatz zur bedarfsorientierten Interaktion darf jeder Busknoten nur gemäß eines vorher definierten Ablaufplans für eine spezifizierte Zeitdauer auf das gemeinsame Bussystem zugreifen |Rei 1 , S,6|.

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 3.5: Unterscheidung zwischen Client-Server- und Producer-Consumer-Interaktion

Im Folgenden werden die Vor- und Nachteile verschiedener Interaktionsstrukturen, wie in Tabelle 3,2 zusammengefasst, vorgestellt.

Abbildung in dieser Leseprobe nicht enthalten

Tabelle 3,2: Vorund Nachteile verschiedener Interaktionsstrukturen

Da bei Client-Server-Interaktion die Kommunikation One-to-One und zwischen beiden Kno­ten stattfindet, eignet sie sieh beispielsweise für Fälle, in denen eine oder beide Seiten ei­ne Bestätigung oder eine allgemeine Antwort erhalten sollen. Bei der Producer-Consumer­Interaktion hingegen muss sieh der Producer darauf verlassen, dass der Consumer die Nach­richt tatsächlich erhält. Dafür ist der Versand einer Nachricht an mehrere Knoten mög­lich. um beispielsweise einen relevanten Status mehreren Steuergeräten mitteilen zu können |VA14|.

Eine Master-Slave-Interaktion kann so konzipiert sein, dass zwischen den einzelnen Slaves über den Master eine One-to-One-Kommunikation abläuft. Dadurch ist die Kollisionsgefahr geringer im Vergleich zu einem Bus, an den sämtliche gleichberechtigte Multi-Master ange- sehlossen sind und bedarfsorientiert Nachrichten versenden |VA14|,

Die bedarfsorientierte Interaktion birgt ein besonders hohes Kollisionspotential bei hoher Buslast; bei angemessener Buslast jedoch ist die Echtzeitfähigkeit besonders gut. Bei einem deterministischen Zeitplan hingegen werden Kollisionen verhindert. Nachteile sind jedoch, dass sieh sämtliche Knoten an die genau definierten Slots zu halten haben und Testen des Zeitplans aufwendig sein kann. Entgegen möglicher Befürchtungen können neue Steuergeräte aber ohne erneutes Testen innerhalb des Zeitplans integriert werden |Reil2, S,6| und |VA14|,

3.5.1.3 Adressierung

Während die Interaktionsstruktur das Verhältnis der Kommunikationsteilnehmer im seriellen Kommunikationssystem untereinander besehreibt, ordnet die Adressierung ein Xutzdatum eindeutig einem Busknoten zu |Reil , S.10|.

1. Senderselektive Adressierung: Der Sender versieht das Xutzdatum mit der ein­deutigen Adresse des gewünschten Empfängers. Diese Adressierungsart erlaubt One- to-One-Kommunikation zwischen zwei Busknoten |ReiK , S.10|.

2, Empfängerselektive Adressierung: Der Sender versieht das Xutzdatum mit einem Identifier und alle anderen Busknoten selektieren, ob sie das Xutzdatum empfangen möchten. Diese Adressierungsart erlaubt One-to-All- und One-to-Many-Kommunikati- on sowie in diesem Sinne Multicasting und Broadcasting |Rei 12, S,10|,

3.5.1.4 Buszugriffsverfahren

Eine der relevantesten Eigenschaften in einem seriellen Bussystem stellt das Buszugriffs­verfahren dar, das die Zugriffsreehte für jeden Busknoten auf den gemeinsamen Bus regelt. Hierbei unterscheidet man zwei Kategorien: kontrollierte und probabilistische Buszugriffsver­fahren. Bei kontrollierten Buszugriffsverfahren wird das Zugriffsreeht vor dem eigentlichen Buszugriff festgelegt, während bei probabilistischen Buszugriffs verfahren erst bei sieh anbah­nendem Buszugriff das Zugriffsreeht an den Busknoten vergeben wird |Reil , S.8|. Die im Folgenden vorgestellten Buszugriffsverfahren sind so spezifiziert, dass sie bereits zuvor be­schriebene Alternativen anderer Eigenschaften implizieren oder aussehließen: So wurden für die Eigenschaft „Interaktionsstruktur“ bereits bedarfsorientierte bzw. zeitgesteuerte Inter­aktion differenziert. Diese gehen allerdings nicht mit probabilistischem bzw. kontrolliertem Buszugriffsreeht einher.

1. Zentral kontrolliert - Delegated-Token-Verfahren: In einer Master-Slave-Anord­nung ist der Master dafür verantwortlich, den Slaves mittels eines Tokens ihr Buszu­griffsreeht für einen gewissen Zeitraum zuzuweisen. In der Regel liegt dem Master ein deterministischer Zeitplan vor, der berücksichtigt, welche Busknoten überhaupt Infor­mationen untereinander austausehen müssen. Da nach dem empfängerselektiven Prin­zip jeder Busknoten die versandten Xutzdaten der anderen Kommunikationsteilnehmer erhalten kann, aufgrund beschränkter Relevanz jedoch Informationen einiger Buskno­ten nicht benötigt, entsteht eine Many-to-Many-Kommunikation - eine Clusterbildung unter den Busknoten |ReiK , S.8|.

2. Dezentral kontrolliert - Time-Division-Multiple-Access-Verfahren (TDMA- Verfahren) : Im Gegensatz zum Delegated-Token-Verfahren wird der Zeitplan nicht von einer zentralen Instanz auf Zugriffsreehte einzelner Busknoten heruntergebroehen und überwacht, sondern dezentral mit einer einheitlichen Zeittaktung allen Busknoten kommuniziert. Der Zeitplan besteht aus repetitiven fixen Kommunikationsrunden, die wiederum Zeitsehlitze für den Buszugriff eines jeden Busknotens reservieren. Obwohl alle Busknoten in der Multi-Master-Anordnung gleichberechtigt und mit dem Zeitplan vertraut sind, werden denzentrale Wächter eingesetzt, um die Einhaltung der Buszu- griffsreehte zu kontrollieren |Reil , S.8|.

Abbildung in dieser Leseprobe nicht enthalten

Tabelle 3,3: Vor- und Nachteile verschiedener Buszugriffsverfahren

3, Probabilistisch - Carrier-Sense-Multiple-Access-with-Collision-Avoidance-Ver fahren (CSMA/CA) : Jeder Busknoten kann bei Bedarf auf den Bus zugreifen, oh­ne einen Zeitplan einhalten zu müssen. Damit keine Kollisionen entstehen, d.h. eine laufende Datenübertragung zerstört wird, muss ein sendewilliger Busknoten vor dem Zugriff den Bus abtasten, was als „Carrier Sense“ bezeichnet wird |ZS11, S,24|, Wird beim Abtasten der Bus als leer erfasst, können eigene Daten gesendet werden. Sofern mehrere Busknoten simultan auf den gemeinsamen Bus zugreifen möchten, entscheidet die Priorität des Datums über die Reihenfolge der Zugriffe |Reil: , S,8|.

Wie in Tabelle 3,3 zu lesen ist, kann beim Delegated-Token-Verfahren der Ausfall des Masters zum Ausfall des gesamten Systems führen. Vergleichbar zu Delegated Token besteht auch beim TDMA-Verfahren keine Kollisionsgefahr, aber die deterministische Interaktion führt zu einer Verlangsamung der Reaktionsfähigkeit, Umgekehrt sind mit CSMA/CA durch die bedarfsorientierte Interaktion schnelle Reaktionen aber auch Kollisionen möglich |VA14|,

3.5.1.5 Datensicherung

Die Robustheits-Anforderung an ein Fahrzeug setzt voraus, dass Daten im seriellen Bussys­tem korrekt und in Echtzeit übertragen werden. Die Datensicherung sorgt dabei für die Ver­meidung, Abwehr, Erkennung und Korrektur von Fehlern in der Datenübertragung |WR11, S.208|. Xichtsdestotrotz können Fehler nie vollständig ausgeschlossen werden, sodass das Bussystem ein Restfehlerwahrscheinlichkeit besitzt. Dieses statistische Maß resultiert einer­seits aus der Wahrscheinlichkeit, dass Daten falsch übertragen werden, und andererseits aus der Wahrscheinlichkeit, dass Verfälschungen nicht erkannt werden. Solche Fehler in der Datenübertragung entstehen aufgrund elektromagnetischer, mechanischer, thermischer und chemischer Einflussfaktoren |Reil2, S,ll|.

Den Xutzbits werden Prüfbits angehängt, welche bis zu einer bestimmten Anzahl an falsch übertragenen Bits eine Fehlererkennung erlauben und im Falle eines erkannten Fehlers unter Umständen auch eine Fehlerkorrektur sicherstellen können. Je mehr Prüfbits angehängt wer­den, umso mehr Fehler können erkannt und im Umkehrschluss korrigiert werden. Allerdings

Abbildung in dieser Leseprobe nicht enthalten

Tabelle 3,4: Vor und Nachteile verschiedener Datensicherungsverfahren

steigt marginal auch die Wahrscheinlichkeit von inkorrekt übertragenen Prüfbits |WR11 S.208I.

1, Paritätsprüfung: Im Regelfall der Paritätsprüfung wird einem Block von acht Xutz- bits ein Paritätsbit zugewiesen. Als Ergebnis einer XOR-Operation über die acht Xutz- bits ergibt das Paritätsbit nur dann eine Eins, wenn die Anzahl an Einsen im Xutzbit- Block ungerade ist. Somit können nur eine ungerade Anzahl an Fehlern in den Xutzbits detektiert werden, vorausgesetzt, das Prüfbit ist selbst korrekt übertragen worden. Eine Korrektur ist nicht möglich, da die Position des falschen Xutzbits nicht identifizierbar ist I VRl , S.208|.

2, Cyclic Redundancy Check (CRC) : Mit möglichst wenig Paritätsbits sollen mög­lichst viele Übertragungsfehler in einem möglichst langen Xutzbit-Block erkannt und korrigiert werden. Im Sinne dieser Optimierungsaufgabe wird der CRC verwendet. Statt über eine XOR-Operation wird der Inhalt der Xutzbits mittels eines Generator­polynoms in die CRC-Sequenz - analog zu den Prüfbits - umgewandelt. Die sender­seitige Erzeugung dieser Sequenz ist im Vergleich zu Standardoperationen aufwendig; die empfängerseitige Anwendung und die damit einhergehende Fehlererkennung und -korrektur erfordern hingegen keine große Rechenleistung |WR11, S.208|.

Aus Tabelle 3,4 ist ersichtlich, dass CRC die Anforderung an eine hohe Datensicherheit besser erfüllt, während die Paritätsprüfung nur in nicht sicherheitsrelevanten Bereichen zum Einsatz kommen kann |VA14|.

3.5.1.6 Synchronisation

Je nach Datenlänge und Robustheitsanforderung ist eine asynchrone oder eine synchrone Datenübertragung zu wählen |WRF , S.208|.

1, Asynchrone Datenübertragung: Der Empfänger synchronisiert sieh über die Län­ge der versandten Daten hinweg, indem die Synchronisation bei einem Start-Bit vor dem Datenblock etabliert und nach zwei Stopp-Bits beendet wird. Der Empfang kann unabhängig vom Versand erfolgen, aber die Länge der übertragenen Daten ist limitiert |WR1 , S.208|.

Abbildung in dieser Leseprobe nicht enthalten

Tabelle 3.5: Vor- und Nachteile verschiedener Synchronisationsverfahren

2. Synchrone Datenübertragung: Empfänger und Sender synchronisieren sieh über ein Taktsignal auf der Übertragungsleitung, Um längere Datenmengen übertragen zu können, ist eine Xachsynchronisation erforderlich. Zur Rückgewinnung des Tak­tes durch den Empfänger werden Flankenwechsel in der Signalübertragung eingebaut, sodass keine langen Folgen von Nullen oder Einsen entstehen |WR1 , S.208|.

Wie aus Tabelle 3,5 interpretiert werden kann, ist die synchrone Variante mit mehr Aufwand, aber auch mit mehr Sicherheit verbunden |VA14|,

3.5.1.7 Physikalische Übertragung

Für die unterste Schicht spielt das physikalische Übertragungsmedium eine besonders re­levante Rolle, wobei zwischen leitungsungebundenen und leitungsgebundenen Übertragun­gen unterschieden wird. Leitungsungebundene Übertragungsmedien umfassen Funk, RFID, Bluetooth und WLAX, die den freien Raum als Übertragungsmedium nutzen |HPS0(, S,59|, Leitungsgebundene Übertragungsmedien hingegen bezeichnen die Bit-Kommunikation über physische elektrische oder optische Leitungen, Da im Dreischichtenmodell traditionell lei­tungsgebundene Kommunikation erfolgt, werden im Folgenden verschiedene Leitungssysteme beschrieben.

1, Asymmetrische Übertragung: Die Signale werden auf einer Leitung übertragen, an welche die elektronischen Steuergeräte indirekt angekoppelt sind |VA14|,

2, Symmetrische Übertragung: Die Signale werden als Spannungsdifferenzen über zwei Leitungen übertragen. Dabei überträgt eine Leitung ein invertiertes Signal, wäh­rend die andere simultan ein nicht invertiertes Signal kommuniziert. Die Differenz aus nicht-invertiertem und invertiertem Signal resultiert in der ursprünglichen Nachricht. Gleichzeitig verhindert dieser Mechanismus eine Verfälschung des Signals durch äuße­re Störungen, da die Differenz über beide Leitungen korrekt bleibt. Damit zusätzlich induktive Kopplungen der zwei Leitungen keine Störungen verursachen, sind die Si­gnalleitungen ineinander verdrillt, sodass man von einem „Twisted-Pair“-Kabel spricht I /A14|,

3, Optische Übertragung: Die Signale werden als Lichtstrahl über das Prinzip der Totalreflexion im Kern eines optischen Mediums reflektiert |VA14|.

In Tabelle 3,6 lässt sieh allgemein erkennen, dass eine hohe Störfestigkeit eines Kabels auch mit höheren finanziellen Kosten einhergeht |VA14|,

Abbildung in dieser Leseprobe nicht enthalten

Tabelle 3.6: Vor- und Nachteile verschiedener Übertragungsarten

3.5.2 Eingesetzte serielle Bussysteme

Auf Basis der beschriebenen Eigenschaften folgt nun in Tabelle 3,7 eine Übersieht über die im Fahrzeug eingesetzten seriellen Bussysteme CAN, LIX, FlexRav und MOST sowie den LAX-Standard Ethernet, Dabei ist auch angegeben, welches System welche Eigenschaften besitzt und für welche Sicherheitsanforderungen diese besonders relevant sind.

- CAN: Das Controller Area Network (CAN) ist dazu konzipiert, auch unter schwe­ren Störeinflüssen am Fahrzeug eine sichere Datenübertragung zu gewährleisten |ISO 11898|, High-Speed-CAX mit Drehraten von bis zu 1 MBit/'s stellt die Kommunikati­on für Antrieb und Fahrwerk sicher, während Low-Speed-CAX mit Drehraten bis 125 KBit/'s im Komfort-Bereich verwendet wird |Hakl , S. 1351.

für die Übertragung kleiner Datenmengen zu Sensoren und Aktoren im Komfortbereich verwendet |ISO 17987|, Im Regelfall dient ein LIX als lokaler Bus, der wie in Abbildung 3,6 einem Steuergerät im Low-Speed-CAX assistiert |Hakl·:, S,135|.

- FiexRay: FlexRav kommt bei besonders sicherheitskritischen Fahrtassistenzfunktio­nen zum Einsatz |ISO 17458|, Im Vergleich zum CAX-Bus können höhere Datenraten und höhere Datensicherheit mit einem deterministischen Buszugriffsverfahren sicher­gestellt werden | iakl , S,135|.

- MOST: Media Oriented Systems Transport (MOST) verbindet Multimedia-Anwen­dungen, die hohe Datenraten benötigen, in einer Ringtopologie, Dabei werden Video-, Audio-, Sprach- oder andere Datensignale meist über ein optisches Medium übertragen |Hakl3, S.135|.

Wie in Abbildung 3,6 zu erkennen ist, sind die einzelnen Bussysteme über Gateways mit­einander verbunden. Diese werden benötigt, da in den Bussystemen verschiedene Protokolle vorliegen.

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 3,6: Beispiel eines Bussystems im Fahrzeug (nach |Hakl, , S,135| und |Mav06, S.73I)

In Tabelle 3,7 ist zu erkennen, dass die zuvor beschriebenen Vor- und Xachteile der techni­schen Eigenschaften in Abhängigkeit der Sicherheitsanforderungen für die Bussysteme einge­setzt werden: CAX und FlexRav mit den höchsten Sicherheitsanforderungen besitzen beide eine Multi-Master-Interaktionsstruktur, verwenden CRC, synchrone Übertragung und ver­drillte Zweidrahtleitungen, Der Unterschied zwischen CAX und FlexRav liegt in der Me­thode des Buszugriffs: Während bei CAX Kollisionen mit dem bedarfsorientierten System CSMA/CA im Falle hoher Buslast möglich sind, werden bei FlexRav alle Kommunikati­onsteilnehmer per TDMA dezentral zeitgesteuert. Die langsamere Reaktionszeit bei TDMA wird bei FlexRav durch eine höhere Datenrate kompensiert |VA14|.

Bei einem günstigen LIX-Unterbus mit geringen Sicherheitsanforderungen hingegen greifen die weniger sicheren Mechanismen der Master-Slave-Interaktionsstruktur, des Delegated To­ken, der Paritätsprüfung, einer asynchronen Übertragung und einer Eindrahtleitung,

Welche Risiken die Eigenschaften eines jeden Bussystems bei der fortschreitenden Vernetzung des Fahrzeugs mit Konsumelektronik in sieh bergen, wird in Abschnitt 4,5 beschrieben.

3.5.3 Ethernet

Als neuer Trend in der Automobilindustrie kristallisiert sieh Ethernet zur Übertragung von Multimedia-Daten innerhalb des Fahrzeugs heraus |Ebel4|: Die One-Pair-Ether-Xet (ОРЕХ) Alliance Special Interest Group (SIC) verfolgt das Ziel, eine weitreichende Anwendung von Ethernet-basierten Xetzwerken als Standard in automobilen Xetzwerkanwendungen durch­zusetzen |OPE14a|, Die Ethernet-Technologie soll insbesondere im Infotainment- und Kom­fortbereich zum Tragen kommen. Ein Beispiel ist die Übermittlung der Aufnahmen von Fahrtassistenz-Kameras, Diese Anwendungen sind nicht relevant für die Sicherheitsanforde­rung der physischen Sicherheit und müssen nicht zuverlässig und in Echtzeit erfolgen, Xeben höheren Übertragungsgeschwindigkeiten verspricht Ethernet eine Reduktion von Komplexi-

Abbildung in dieser Leseprobe nicht enthalten

Tabelle 3,7: Eigenschaften bestehender Bussysteme und Ethernet (nach |Hakl , S,135| und |Mav06, S.731)

tat und Verkabelungskosten |Ebel4| und |OPE14a|, Da die Verkabelung mit Ethernet güns­tiger ist als eine optische Leitung, wird sie als Ersatz für den MOST-Bus geplant |OPE14a|.

Für das Automobil wurde bereits im Rahmen der Bemühungen der ОРЕХ Alliance SIG die Technologie „BroadR-Reach“ von Broadcom vorgestellt, welche in Kapitel 5,2 detaillierter erläutert wird. Das Forschungsprojekt „EtherCar“ wiederum setzt sieh damit auseinander, etablierte Echtzeit-Ethernet-Systeme aus der Automationstechnik in die Fahrzeugarchitektur zu übertragen | Dthl4| und |FDWS1 |.

Ursprünglich wurde zur Kollisionsvermeidung bei Ethernet in Computer-Xetzwerken ähn­lich zu CAX eine CSMA-'Technologie verwendet |KS0 , S.212 ff,|. Diese wird allerdings durch den Einsatz von Switches im Vollduplexmodus abgelöst: Switches unterteilen das gesamte Ethernet-Xetzwerk in Kollisions-Domänen, denen bestimmte Kommunikationsteilnehmer zu­geordnet sind. Die Knoten in einer Kollisions-Domäne konkurrieren untereinander um den Zugriff auf ein gemeinsames Übertragungsmedium, Gleichzeitig ermöglicht die Vollduplex­Verkabelung jedem einzelnen Teilnehmer simultan Pakete zu senden wie auch zu empfangen. Dabei wird über die Switches sowohl eine One-to-One-Kommunikation von einem Teilnehmer zum anderen als auch Broadcasting ermöglicht.

Dennoch kann ein Empfänger nicht mehrere Pakete gleichzeitig empfangen, sondern muss sie in einem Datenpuffer Zwischenspeichern. Einen solchen Puffer kann man sieh als War­teschlange für Daten mit begrenzten Warteplätzen vorstellen. Reicht die Größe des Puffers nicht aus, gehen Daten verloren. Zur Vermeidung von Datenverlusten wurde die „Ether­net Flow Control“ Funktionalität eingebaut, die es einem Empfänger erlaubt, den anderen Kommunikationsteilnehmern mitzuteilen, dass eine Sendepause erwünscht ist |RL9' , S,511|, Diese Implementierung erschwert allerdings Reaktionen der Mikrocontroller in Echtzeit und ist daher für einen Einsatz in sicherheitsrelevanten Xetzwerken als kritisch zu betrachten. Eine weitere Einschätzung des Einsatzes von Ethernet im Fahrzeug wird in Abschnitt 5,2 gegeben.

3.6 Grundlagen Ebene 3 - Software-Datenübertragungs­ebene

Die Anwendungsschicht im Dreischichtenmodell umspannt die Funktionalitäten der fünf oberen Schichten des OSI-Kommunikationsmodells und kann im Vergleich zu den unte­ren beiden Schichten als ausschließliche Softwareumgebung charakterisiert werden. Diese Software-Aspekte werden nun in die Software-Datenübertragungsebene und die Software­Ebene aufgeteilt, ohne die Schichten zu berücksichtigen. Wie bei der physischen Ebene und der physischen Datenübertragungsebene sind auch hier verschiedene Sicherheitsanforderun­gen zu betrachten: Bei den Hardware-Ebenen liegt in der Grundlagenbesehreibung der Fokus auf den Zugriffsrechten einzelner Busknoten und der Robustheit der Übertragungsmechanis­men. Analog dazu wird das Augenmerk bei den Software-Ebenen auf die im Programmeode implementierten Zugriffsrechte virtueller Objekte und die Robustheit von Verschliisselungs- mechanismen bei der Übertragung gelenkt.

Als Unterschied zwischen den Hardware- und den Software-Ebenen ist zu nennen, dass auf den Hardware-Ebenen die Komponenten und die einmal festgelegte Infrastruktur nach der Produktion nicht mehr verändert werden können, während auf den Software-Ebenen

Änderungen möglich sind. Diese Modifikationen sind allerdings durch die feste Hardware­Architektur limitiert. Obwohl virtuelle Zugriffsrechte in der Software festgelegt werden, kön­nen sie durch Angriffe verletzt werden und die gesamte Fahrzeugarchitektur bis zu den Hardware-Grenzen gefährden. Aus dem Internet sind Angriffe wie beispielsweise Viren, Wür­mer, Trojaner, Denial-of-Service (DoS-) und Buffer-Overflow-Attacken bekannt |Eckl3, S.78 ff, I, Zur Absicherung bedient man sieh verschiedener Kapselungs- und Verschlüsselungstech­niken, von denen einige zur Verwendung in nachfolgenden Analysen in diesem Grundlagen­kapitel erläutert werden. Auf der Software-Datenübertragungsebene befinden sieh die kryp- tographischen Verfahren, die in diesem Abschnitt thematisiert werden. Im darauffolgenden Abschnitt werden die Kapselungsmechanismen auf der Software-Ebene erläutert.

3.6.1 Kryptographie

„Kryptologie“ bezeichnet die Wissenschaft der Informationssicherheit. Sie lässt sieh unter­teilen in die „Kryptographie“ als Wissenschaft der Verschlüsselung von Informationen und die „Kryptanalyse“ als Wissenschaft der Entschlüsselung von zuvor verschlüsselten Informa­tionen |Ert 12, S,21|, Während in der Kryptographie Methoden der sicheren Verschlüsselung von Daten entworfen und implementiert werden, greifen kryptanalvtische Verfahren diese Verschlüsselungen an und prüfen sie auf ihre Einsatzfähigkeit, Je schneller und einfacher die Kryptanalyse das ursprüngliche Datum hervorbringt, umso leichter fällt diese Aufgabe auch einem Hacker mit möglichen mutwilligen Absichten,

3.6.1.1 Sicherheitsanforderungen an Informationsübertragung

Um sieh diesen gefährlichen Intentionen entgegen zu stellen, definiert die Kryptographie die folgenden drei übergreifenden Anforderungen an eine sichere Kommunikation |BucO£, S, 11

1, Vertraulichkeit: bezeichnet den Prozess der Umwandlung des ursprünglichen „Plain- textes“ in einen verschlüsselten „Ciphertext“, um diesen für jeden außer den Besitzer des Schlüssels unlesbar zu machen,

2, Integritätsprüfung: bezeichnet eine Methode zur Überprüfung, ob die Daten bzw, der Datenfluss zwischen Versand und Erhalt verändert wurden,

3, Authentifizierung: bezeichnet die korrekte Identifikation des Senders der Nachricht.

In Anlehnung an diese drei Anforderungen lässt sieh jeweils eine Attacke beschreiben, die ohne Verschlüsselung leicht zu vollziehen ist. Es wird jeweils der Versand einer Nachricht von A zu В betrachtet, der von einem Feind E angegriffen wird |Buc08, S,63|,

1, Passive Atta>2, Aktive Attacke - Umleitung: E greift die von A versandte Nachricht ab, ändert die Inhalte ab und verzögert den Datenverkehr, Die Integrität ist dadurch nicht gegeben.

3, Aktive Attacke - Maskerade: E versendet im Xamen von A eine Xaehrieht an B, В besitzt keine Möglichkeit den Sender zu authentifizieren.

Zur Sicherstellung von Zugriffskontrollen und Verschlüsselung gegen passive Angriffe sowie von Authentifizierung und Integritätsprüfung gegen aktive Angriffe existieren drei Arten kryptographiseher Methoden: symmetrische, asymmetrische und hybride Methoden |Bue08, S.60 f.|.

Bei symmetrischen Methoden wird vom Sender und vom Empfänger jeweils derselbe Schlüssel zur Vor- und Entschlüsselung verwendet, wohingegen sieh bei asymmetrischen Methoden die Schlüssel bei den Kommunikationspartnern unterscheiden, Hybride Methoden repräsentieren eine Kombination aus symmetrischen und asymmetrischen Elementen,

3.6.1.2 Symmetrische kryptographische Verfahren

Die am häufigsten eingesetzten symmetrischen Methoden sind „Triple Data Encryption Stan­dard“ (3DES) und „Advanced Encryption Standard“ (AES) ,

3DES führt drei Mal den ursprünglichen Algorithmus „Data Encryption Standard“ (DES) mit jeweils einem anderen Schlüssel aus, wobei die mittlere Ausführung rückwärts abläuft. Der DES-Algorithmus besteht aus einer Folge von Aufspaltungen, Permutationen, Verschie­bungen und XOR-Operationen sowohl für einen 64 Bits langen Plaintext als auch einen 56 Bits langen Schlüssel, Dabei werden „Feistel-Runden“- benannt nach dem IBM-Mitarbeiter Feistei - 16 Mal hintereinander wiederholt, was insbesondere in Kombination mit nonli­nearen Substitutionen eine gewisse Komplexität des Algorithmus sicherstellen soll |BucO£, S.103-lll|.

Gleichzeitig ist DES dadurch charakterisiert, dass die inverse Ausführung des Algorithmus der Entschlüsselung entspricht. Dies ist im Hinblick auf Vertraulichkeit nur möglich, wenn der symmetrische Schlüssel bei Sender und Empfänger identisch ist. Allerdings ist gerade die sichere Übertragung des Schlüssels eine Schwachstelle symmetrischer Algorithmen, sodass folgende erfolgreiche kryptanalytisehe Angriffe auf DES möglich sind |BucO , S,103-lll|:

1. Brute force: Ein Computer testet sämtliche 2[56] « 72· 10[15] Schlüssel durch, was bei genügend Rechenleistung in weniger als einem Tag möglich ist |Buc08, S,103-lll|,

2. Differential cryptanalysis: Verwende möglicherweise ähnliche Plaintexts und ana­lysiere Unterschiede in den entstehenden Ciphertexts nach Durchführen von DES, um Informationen über den Schlüssel zu erhalten. Dieses Vorgehen wurde laut |LanO(, S,349| von der „Xational Security Agency“ (XSA) seit vielen Jahrzehnten praktiziert.

3. Physical cryptanalysis: Ändere Code-Ausführung oder Schlüssel durch externes Zu­greifen auf in einer SmartCard enthaltenen Informationen beispielsweise bei Chipkar­ten, Analysiere den entstehenden Ciphertext |BueO< , S. 103-1111.

4. Trivial cryptanalysis: Erhalte die Bits des Schlüssels direkt vom Speichermedium, Für ein vernetztes Fahrzeug bedeutet dies, dass die Verwendung von DES sowohl durch physische, als auch softwaretechnische Angriffe keine Sicherheit garantiert. Die dreifache

Ausführung durch den 3DES bietet zumindest softwaretechnisch mehr Sicherheit, da die Kombination dreier Schlüssel in der korrekten Reihenfolge zu finden ist. Trotzdem wurde 3DES durch AES als Standard abgelöst.

AES wurde 2000 in einem ausgeschriebenen Wettbewerb ermittelt, wobei der Rijndael- Algorithmus gewann |BucO , S. 1131. Die Funktionalität unterscheidet sich grundlegend von der des DES-Algorithmus: Je nach Länge des Plaintext-Bloekes und des Schlüssels wird be­stimmt, wie viele Runden des Algorithmus durchgeführt werden. Jede Runde besteht aus vier verschiedenen Transformationen¹, wobei als Parameter der Schlüssel und eine Matrix namens „State“ eingehen,

1, Bitsubstitution: Wie bei DES werden die Bits der State-Matrix an bestimmten Stel­len an andere Stellen nichtlinear verschoben,

2, Zyklische Reihenverschiebung: Die unteren Reihen der State-Matrix werden um eine bestimmte Anzahl an Positionen verschoben,

3, Spaltenvermischung: Es erfolgt eine Matrixmultiplikation über die Spalten der State- Matrix, In der letzten Runde wird dieser Schritt ausgelassen,

4, Rundenschlüssel addieren: Bitweise wird der Schlüssel der aktuellen Runde über eine XOR-Operation mit den Elementen der State-Matrix verbunden.

Lineare und differentielle Kryptanalysen sind auf AES nachweisbar nicht anwendbar. In der Theorie bestehen umstrittene Möglichkeiten, AES anzugreifen; in der Praxis sind sie jedoch aufgrund hoher Komplexitäten von mindestens 2[100] Rechenschritten bisher nicht durchführ­bar, Daher gilt AES vorerst als äußerst sicherer kryptographiseher Algorithmus |Ertll, S,73|,

3.6.1.3 Asymmetrische kryptographische Verfahren

Die populärste asymmetrische Methode ist das „Rivest-Shamir-Adleman“ (RSA)-Kryptosys- tem. Anders als bei symmetrischen Methoden liegen bei n Kommunikationsteilnehmern nicht G O(n [4]) Schlüssel im gesamten System vor, sondern jedem Kommunikationsteilnehmer

S = (N, d) und öffentlichem Schlüs­sel P = (N, c) zugeordnet. Beide Schlüssel besitzen ein gemeinsames Element N, welches das Produkt aus zwei sehr großen Primzahlen p und q bildet. Gleichzeitig hängt es mit den Wer­ten c und d durch folgende Gleichung zusammen: c· d = (p — l)(q — 1) · k + 1 mit k G N. Auf den ersten Blick könnte man vermuten, dass man aus dem öffentlichen Schlüssel P = (N, c), der jedem bekannt ist, ohne Schwierigkeiten über obige mathematische Bedingung das d aus dem privaten Schlüssel S = (N, d) ermitteln könne. Da die Suche großer Primzahlen zu den komplexesten mathematischen Aufgabenstellungen gehört, erweist sich eine kryptana- lytisehe Attacke jedoch als schwieriger |Ertl: , S,82|, Gleichzeitig repräsentiert diese Hürde die Güte und die Sicherheitsstufe des RSA-Algorithmus, Ein weiterer Vorteil wird dadurch erreicht, dass kein symmetrischer Schlüssel zwischen Sender und Empfänger ausgetauscht werden muss. Allerdings bestehen aufgrund der langen Schlüssel hohe Rechenleistungskos­ten und man vermutet, dass in Zukunft effizientere Quantencomputer Primzahlenprobleme in angemessener Zeit lösen können |Bne08, S,172|, Es darf zudem nicht vernachlässigt werden, dass auch die asymmetrischen Schlüssel gespeichert werden müssen und dieser Speicherort angreifbar sein kann.

Mathematisch betrachtet ist die Vor- und Entschlüsselung von Nachrichten einfacher im Vergleich zu Algorithmen wie 3DES oder AES: Möchte A eine Nachricht an В senden, so verwendet A den öffentlichen Schlüssel von В zum Verschlüsseln der Nachricht, Nach dem Versand kann nur В mit seinem privaten Schlüssel die Nachricht entschlüsseln, die mit seinem öffentlichen Schlüssel verschlüsselt wurde.

Da RSA-basierte Verfahren insgesamt nicht sicher sind, fungiert die Elliptisehe-Kurven- Kryptographie als immer häufiger verwendete Alternative im Bereich der asymmetrischen kryptographisehen Verfahren |Bue08, S,232|, Während RS A durch die Komplexität der Be­rechnung großer Primzahlen gesichert wird, stützt sieh die Elliptisehe-Kurven-Kryptographie auf die komplexe Berechnung des diskreten Logarithmus in der Gruppe der Punkte der el­liptischen Kurve,

Bei der Verschlüsselung werden die Operationen, die in einem Verfahren durehgefiihrt wer­den, welches auf dem diskreten Logarithmus in endlichen Körpern basiert, durch Operationen der Punkte auf der elliptischen Kurve ersetzt. Diese Operationen sind wesentlich aufwendi­ger, werden jedoch „durch die geringere Länge der verwendeten Zahlen kompensiert“ |Bue08, S,232| und stellen die Sicherheit vor kryptanalytisehen Angriffen her. Der Vorteil gegenüber RSA liegt darin, dass mit kleineren Zahlen, also auch geringerer Leistung, dieselbe krypto- graphisehe Sicherheit erreicht werden kann |BueO< , S,232|,

3.6.1.4 Hybride kryptographische Verfahren

Indem Aspekte symmetrischer und asymmetrischer Verfahrensarten miteinander kombiniert werden, heben sieh die Nachteile beider auf, während sieh ihre Vorteile potenzieren. In der Umsetzung bedeutet dies, dass der Plaintext symmetrisch verschlüsselt und der symmetrische Schlüssel wiederum asymmetrisch verschlüsselt wird. Sowohl der Ciphertext, als auch der asymmetrisch verschlüsselte Schlüssel werden vom Sender an den Empfänger übertragen. So entstehen keine hohen Kosten für die Reehenleistung und der symmetrische Schlüssel wird sicher zwischen Sender und Empfänger übertragen |BueO , S,134|.

Vertraulichkeit ist gegeben, da das asymmetrische RSA- oder das Elliptisehe-Kurven-Ver­fahren als besonders sicher einzustufen sind. Allerdings wird dieser Mechanismus nicht der Anforderung an Integrität gerecht, denn ein Hacker könnte Inhalte im Laufe der Übertra­gung verändert haben. Deswegen werden „Digitale Signaturen“ neben dem Ciphertext mit­gesendet, die eine mit einem privaten Schlüssel des Senders verschlüsselte Hash-Funktion darstellen. Eine solche Hash-Funktion besitzt die Aufgabe, die ursprüngliche Nachricht so zu komprimieren, dass jede weitere Anwendung der Hash-Funktion auf dieselbe Nachricht wieder dasselbe Ergebnis liefert, jedoch nur schwer eine andere Nachricht gefunden werden kann, die bei Anwendung derselben Hash-Funktion auch dieses Ergebnis liefert. Oft verwen­dete Hash-Funktionen gehören der Familie der „Secure Hash Algorithm“ (SHA) an. Sie sind nicht invertierbar, d.h, die ursprüngliche Nachricht aus dem Ergebnis der Hash-Funktion ist nicht reproduzierbar. Im Kontext des hybriden kryptologischen Verfahrens dienen Hash- Funktionen also nicht der Vor- und Entschlüsselung, sondern allein der Möglichkeit für den Empfänger durch erneutes Anwenden der Hash-Funktion auf eine empfangene und entsehliisseite Nachricht, zu vergleichen, ob auf dem Übertragungsweg unerwünschte Veränderungen vorgenommen wurden.

Der Einsatz Digitaler Signaturen gewährleistet Integrität, berücksichtigt wiederum jedoch nicht die Anforderung nach Authentifizierung, Der damit einhergehende Angriff wird als „Man in the Middle Attack“ bezeichnet, bei dem ein Hacker auf dem Übertragungsweg die verschlüsselte Nachricht, den verschlüsselten Schlüssel und die Digitale Signatur des Senders verwirft und aus seiner eigenen Nachricht diese drei Komponenten kreiert, die dann an den Empfänger geleitet werden. Er gibt sieh so als Sender aus, dass der Adressat keine Möglichkeit hat, den Betrug zu erkennen |Ertl , S.90 f,|. Aus dieser Problemstellung heraus werden Zertifikate von offiziell autorisierten Instanzen ausgestellt, die das zertifizieren, was einen jeden Kommunikationsteilnehmer eindeutig identifiziert: seinen öffentlichen Schlüssel P =(N,c).

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 3,7: Standardprotokoll für hybride Kryptosysteme (Schritte im Text erklärt.)

In Abbildung 3,7 wird das Standard-Protokoll für hybride Kryptosysteme vorgestellt, welches Vertraulichkeit, Integrität und Authentifizierung sicherstellt. Es gliedert sieh in folgende Schritte:

1, Der Sender A wendet eine Hash-Funktion auf die Nachricht an, damit ein nicht- invertierbares und damit inhaltlich wertloses Datenpaket entsteht, das erst zum Ver­gleich beim Empfänger wieder relevant wird. Damit dem Empfänger auch ersichtlich ist, dass A die Nachricht versandt hat, wird das Datenpaket mit As geheimem Schlüssel SA zur Digitalen Signatur verschlüsselt,

2, Gleichzeitig wird die Nachricht mit einem symmetrischen Schlüssel verschlüsselt und der symmetrische Schlüssel wiederum asymmetrisch mit dem öffentlichen Schlüssel des Empfängers В verschlüsselt. Damit A auch sichergehen kann, dass der symmetrische Schlüssel nur von В entschlüsselt werden kann, ist der öffentliche Schlüssel zertifiziert und identifiziert damit eindeutig B,

3, Die Digitale Signatur, der symmetrische Schlüssel und die verschlüsselte Nachricht werden zu В übermittelt.

4, Der Empfänger В verwendet seinen geheimen Schlüssel , um den symmetrischen Schlüssel zu erhalten und damit die Nachricht zu entschlüsseln,

5, Um nun sicherzugehen, dass die Nachricht nicht verändert worden ist, wendet В die Hash-Funktion auf die erhaltene Nachricht an und vergleicht dieses Datenpaket mit dem Datenpaket, das über die Entschlüsselung der Digitalen Signatur mit As öffentli­chem Schlüssel entsteht. Wenn dieser Vergleich positiv ist, hat В die Nachricht erhalten, die A versandt hat.

3.7 Grundlagen Ebene 4 - Software-Ebene

Während im vorhergehenden Abschnitt der Fokus auf der sicheren Datenübertragung lag, soll nun betrachtet werden, wie durch Kapselung die Sicherheit eines Betriebssystems und Software-Systeme allgemein erreicht werden können,

Malware kann bei vernetzten Geräten dazu führen, dass auf deren Hardware unerwünscht lesend und schreibend zugegriffen wird. Dies gilt nicht nur bei Computern und vernetzten Fahrzeugen, sondern auch bei Smartphones, Damit ein Smartphone beispielsweise aufgrund von Viren in einer Applikation nicht unkontrolliert Töne und Vibration auslöst, Einstellungen ändert, SMS versendet, Passwörter ändert oder gar auf andere Applikationen zugreift, „läuft jede App in einer eigenen virtuellen Maschine“ |GS1( , S,13|, „Jede Android-Anwendung läuft mit einem eigenen Prozess |,,,| und mit einer eigenen Instanz in der virtuellen Ma­schine von Android, |,,,| Es laufen immer mehrere Instanzen der Dalvik Virtual Machine auf einem Android-Smartphone, |,,,| Wird die Anwendung beendet, dann wird auch der Prozess beendet“ |DirlO|, Die Kapselung einer jeden Anwendung in einer eigenen Ausfüh­rungsumgebung reduziert die Zugriffsmöglichkeiten der Anwendung nach den Vorstellungen des Smartphone-Herstellers und beschränkt damit das Schadenpotential, Inwiefern jedoch „physische Sicherheit“, „keine Ablenkung des Fahrers“, „HMI-Hoheit“ sowie „Datenschutz und Datensicherheit“ tatsächlich respektiert werden, hängt davon ab, welche Aktivitäten der Anwendung von der virtuellen Maschine und der darunter liegenden Architektur zugelassen werden.

Um solche Konzepte der Kapselung auch auf die Fahrzeugarchitektur zu übertragen, werden im Folgenden Grundlagen von Betriebssystemen und verschiedene Arten der Virtualisierung vorgestellt,

3.7.1 Betriebssystem

Ein Betriebssystem umfasst Algorithmen, welche die vier Systemressourcen Datenspeicher, Prozessoren, Geräte sowie Informationen verwalten |MD7- , S,8|, Dem Betriebssystem fällt die Aufgabe zu, den Status aller Ressourcen zu überwachen und sie effizient den Prozessen zuzuweisen. Da das Betriebssystem zur Bedienung der Hardware dient, repräsentiert es eine grundlegende Schnittstelle zwischen Benutzerprogrammen und Hardware.

Bei Bedienungsinstruktionen werden im Allgemeinen zwei Modi unterschieden: „User-Mode“ und „Kernel-Mode“, Anwendungsprogramme befinden sich im Regelfall im User-Mode, wel­cher keinen direkten Ressourcenzugriff ermöglicht. Im Gegensatz dazu befinden sich Funktio­nalitäten des Betriebssystems im Kernel-Mode, damit sie auf alle Hardware-Ressourcen zu­greifen können. Das Scheduling und Treiber sind typische Betriebssystemfunktionalitäten, die beispielsweise auch auf Interrupts, Input/Output-Ressourcen und Netzwerk-Schnittstellen zugreifen dürfen |BBKS0 , S,406| und |MD74, S,7|, Der Kernel des Betriebssystems läuft auf der Hardware, während Anwendungsprogramme darauf aufbauen. Möchte ein Anwen­dungsprogramm privilegierte Kernel-Instruktionen ausführen, muss es beim Kernel durch ein „Supervisor Call“ anfragen |MD7 , S,16|, Anschaulich lassen sieh Funktionalitäten im Kernel-Mode als Administratoren und Anwendungen im User-Mode als gewöhnliche Nutzer beschreiben.

Diese Modi werden auch im in Abbildung 3,8 dargestellten Ring eingeordnet, welcher die Privilegierungs- und Sicherheitsstufen eines Prozesses angibt |Manl , S,27|, In Ring 0 läuft meistens der Kernel des Betriebssystems, während in Ring 3 die Anwendungen ansässig sind. Die Sicherheitsabgrenzung wird dadurch erreicht, dass Segmente in Ring i auf Segmen­te in Ring i direkt zugreifen können, jedoch nur mit „Procedure Calls“ bzw, „Supervisor Calls“ bei Ringen i anfragen können |MD74, S.5411. Im Hinblick auf die Sicherheit fällt den Schnittstellen zwischen den Ringen eine relevante Rolle zu, da dort zu entscheiden ist, ob ein Call ausgeführt wird | 11)7 1. S.5511.

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 3,8: Ringdarstellung der Modi und Zuordnung der Ringe ohne Virtualisierung (nach |MD7 , S,542|, | lanll , S.27| und | Vlanl3, S.296|)

3.7.2 Virtualisierung

Für die virtuelle Kapselung ist diese Differenzierung der Ringe und der Befehle insofern relevant, als sie eine Platzierung der Virtualisierungsschicht im Ring-Schema ermöglicht. Dadurch können Anwendungen im User-Mode nur innerhalb der eigenen virtuellen Maschi­ne arbeiten, während Funktionalitäten im Kernel-Mode auch andere virtuelle Maschinen beeinflussen und so Konflikte erzeugen können.

Nachfolgend werden fünf Virtualisierungsarten mit einer Einordnung der Komponenten in die Sicherheitsstufen vorgestellt,

3.7.2.1 Ohne Virtualisierung

In Abbildung 3,8 wird die Architektur ohne Virtualisierung dargestellt: Das Betriebssystem agiert direkt auf der Hardware und stellt das Verbindungsglied zu den Anwendungen dar.

3.7.2.2 Vollvirtualisierung

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 3.9: Vollvirtualisierung ohne, mit Hardware-Assistenz, Paravirtualisierung (nach |Manl3, S.299 f.|)

Wie in Abbildung 3.9 ersichtlich wird bei der Vollvirtualisierung jede Anwendung in einer Virtuellen Maschine (VM) gekapselt. Diese Virtuellen Maschinen werden von einem „Virtual Machine Monitor“, auch „Hypervisor“ genannt, bereitgestellt.

In der Variante „ohne Hardware-Assistenz“ operiert der Hypervisor in Ring 0 und verschiebt damit die Virtuellen Maschinen und das Kontrollbetriebssystem in Ring 1. Diese Systeme glauben allerdings, sieh in Ring 0 zu befinden. Daher muss der Hypervisor die Kernel-Befehle selbst zusätzlich an die Hardware weiterleiten, was mit Zeitaufwand und zusätzlicher Reehen- leistung einhergeht |Manl3, S,296|.

Bei der Variante „mit Hardware-Assistenz“ werden Virtuelle Maschinen und Kontrollbetriebs- systeme auf Ring 0 beibehalten und lediglich der Hypervisor auf den dafür speziell entwi­ckelten Ring -1 gelegt. Dies bietet den Vorteil, dass sieh der Hypervisor auf seine Aufgaben zur Verwaltung der Virtuellen Maschinen fokussieren kann, ohne Kernel-Befehle weiterleiten zu müssen |BBKS0! , S.398|.

3.7.2.3 Paravirtualisierung

Anders als bei der Vollvirtualisierung wissen bei der Paravirtualisierung die einzelnen in Virtuellen Maschinen gekapselten Betriebssysteme, dass sie über einen Hypervisor auf die Hardware zugreifen. Diese Gast-Betriebssysteme werden so modifiziert, dass sie statt ihrer Kernel-Befehle „Hyperealls“ an den Hypervisor senden, der die Aufgabe selbst auf der Hard­ware ausführt. Abbildung 3.9 zeigt, dass Virtuelle Maschinen und das Kontrollbetriebssystem direkt mit dem Hypervisor kommunizieren können |Manl3, S.300 f,|.

Paravirtualisierung beschränkt den Einsatz von Open-Souree-Betriebssystemen |KrolO|, er­möglicht jedoch mehr Anpassung des Betriebssystems an die vorliegende Architektur.

3.7.2.4 Software-Virtualisierung

Voll- und Paravirtualisierung nutzen beide den „Typ 1 Hypervisor“, der direkt auf die Hard­ware zugreift. Bei Software-Virtualisierung - auch als „Hosted Virtualisierung“ bezeichnet - wird jedoch der „Typ 2 Hypervisor“ verwendet, der - wie in Abbildung 3,10 erkennbar - in einem bestehenden Betriebssystem läuft und wiederum einen eigenen Raum für Virtuelle Maschinen bildet |Manl3, S.299 f,|. Er greift nicht selbst auf die Hardware zu. Bei Com­putern wird diese Virtualisierungsart besonders häufig gewählt, um eine Virtuelle Maschine wie ein gewöhnliches Programm parallel zu anderen Anwendungen laufen zu lassen,

3.7.2.5 OS-Virtualisierung

Anders als bei den zuvor beschriebenen Arten werden bei OS-Virtualisierung keine Vir­tuellen Maschinen verwendet, Stattdessen werden wie in Abbildung 3,10 Anwendungen in Containern gekapselt und die Rolle des Hypervisors übernimmt der Container Manager, Zu­dem können nicht mehrere unterschiedliche Betriebssysteme zum Einsatz kommen. Entweder laufen die Container im Host-Betriebssystem oder sofern ein eigenes Betriebssystem in einem Container nötig ist, muss es dasselbe sein wie das Host-Betriebssystem, OS-Virtualisierung ist auch dadurch charakterisiert, dass verschiedene Container auf die gleichen Dateien zu­greifen können, was den Speicherplatz reduziert |BBKS01, S,400|,

3.7.2.6 Hardware-Virtualisierung

Ein weiterer Ansatz ist die Partitionierung als eine Art der Hardware-Virtualisierung, Dabei wird - wie in Abbildung 3,10 dargestellt - die Hardware in Partitionen aufgeteilt, „Unter­schiedliche Betriebssysteme |laufen in den Partitionen| parallel nebeneinander, Speicherbe­reiche, Reehenzeit, und I/O-Ressoureen sind jedoch streng voneinander getrennt“ |KrolO|.

Oft werden Partitionierung und die zuvor beschriebenen Virtualisierungsarten miteinan­der verknüpft, beispielsweise um Echtzeitfähigkeit auf Multicore-Prozessoren zu realisieren |BBKSO£, S.405|. In Smartphones werden diese Virtualisierungsarten sehr unterschiedlich miteinander kombiniert, was wiederum mit unterschiedlichen Levels der Datensicherheit ein­hergeht |JFA14, S.10|.

3.7.3 Sandbox

Als eine verbreitete Form von Virtualisierung ist die „Sandbox“ zu nennen. Sie stellt einen vom ausgeführten Code isolierten Bereich dar und wird sowohl zum Testen von Code als auch zur Eingrenzung der Zugriffsrechte einer Anwendung und zur Abschottung von Malware eingesetzt |WM12, S,217|, Im Unterschied zur Virtuellen Maschine wird bei der Sandbox kein Computer oder Server virtuell reproduziert.

Mithilfe einer Sandbox können Befehle im Kernel-Mode unterschieden und eingeschränkt werden. So können auf einem Smartphone vom Betriebssystem eingestellte Zugriffsrechte eingehalten und benutzerspezifische Zugriffsrechte eingestellt werden,

Software, die als schädlich identifiziert wurde, kann hingegen so weit isoliert werden, dass sie keinerlei Auswirkungen auf ihre Umgebung nehmen kann - zumindest in der Theorie |WM12, S,217|, Neben der Quarantäne-Funktion wird Sandboxing auch für Antivirus-Programme verwendet, da eine Sandbox detektieren kann, wenn eine Anwendung aus ihrem virtuellen Raum ausbrechen möchte (siehe Abschnitt 4,7).

3.7.4 API

Mithilfe einer Application Programming Interface (API) können App-Entwickler auf Funk­tionalitäten bestehender Betriebssysteme wie Android und iOS aber auch auf Dienste-Platt- formen wie Facebook, Twitter, Youtube oder andere zugreifen |Sirl4, S,l|, Falls im Fahrzeug Apps von Drittanbietern angeboten werden sollen, müssten vom Hersteller bzw, den Entwick­lern des Betriebssystems auch eigene APIs veröffentlicht werden, mit denen App-Entwickler Fahrzeug-Apps programmieren können. Sofern keine Dritt-Entwicklungen erwünscht sind, ist es für die OEM-Entwickler dennoch interessant, die APIs anderer Anbieter für Musik oder Social Media selbst zu verwenden. Es bestehen daher zwei Anwendungsfälle für APIs im Fahrzeug-Multimedia-System: (1) Verwendung fremder APIs durch den OEM und (2) Veröffentlichung einer OEM-eigenen API zur Verwendung durch Dritt-Entwickler.

Inwiefern eine App auf Daten im Fahrzeug zugreifen kann, hängt von den Zugriffsbeschrän­kungen durch die API ab. Der Zugang zu bestimmten Informationen kann wiederum dadurch verwehrt werden, dass keine kritischen Schnittstellen-Funktionen angeboten werden. Erfolgt eine solche Eingrenzung nicht, kann der App-Betreiber für die ihm zur Verfügung stehen­den Zugriffsrechte sämtliche Daten aus dem Fahrzeug über die Internetverbindung sammeln |Sirl4, S,3|, Dienste wie OAuth sorgen zumindest dafür, dass Benutzername und Kennwort idealerweise nicht vom Provider einer Applikation gelesen werden können |Sirl4, S,3|.

Im Sinne der Standardisierung von Multimediasystemen im Fahrzeug lohnt sieh eine ein­heitliche API für verschiedene OEMs, da eine fremde App dann nur einmal vom Entwickler programmiert werden müsste und in allen Fahrzeugen verwendet werden könnte. Allerdings sind in dem Fall die Zugriffsrechte auf den kleinsten gemeinsamen Nenner über alle partizi­pierenden OEMs einzustellen.

4. Analyse der technischen Gefahrenpotentiale

„Bis vor 20 Jahren bezog sieh Fahrzeugsicherheit auf mechanische Fahrzeugschlüssel sowie Warneinrichtungen und mechanische Verriegelung, die das Fahrzeug vor Diebstahl und un­erlaubter Benutzung sicherten“ [ + , S.l], Mittlerweile bestehen jedoch aufgrund der fortschreitenden Vernetzung der Fahrzeugarchitektur nach innen und außen weitreichende Gefahrenpotentiale, die mit solchen Vorrichtungen nicht vermieden werden können. Solche Risiken werden in diesem Kapitel analysiert werden: Dabei wird zunächst auf allgemeine Ge­fahrenpotentiale von Embedded- und Brought-In-Systemen eingegangen und im Anschluss tatsächliche Sicherheitslücken derzeitiger Smartphone-Betriebssysteme näher betrachtet. Um den Fokus auf die gefährlichste Art von Angriffen zu richten, welche bei einem Fahrzeug die physische Sicherheit gefährden, werden das Vorgehen eines Fahrzeug-Hackers und die Ge­fahrenpotentiale auf den vier technischen Ebenen analysiert.

4.1 Gefahrenpotentiale der verschiedenen Dienstarten

Im Grundlagenkapitel sind die drei Dienstarten „Navigation“, „Infotainment“ und „Integrierte Dienste“ sowie die vier allgemeinen Sicherheitsanforderungen „Physische Sicherheit“, „keine Ablenkung des Fahrers“, „HMI-Hoheit“ sowie „Datenschutz und Datensicherheit“ vorgestellt und erläutert worden. Auf diesen Erklärungen aufbauend wird in diesem Abschnitt unter­sucht, inwiefern die einzelnen Dienstarten eine Gefahr für die Sicherheitsanforderungen von Embedded- und Brought-In-Systemen darstellen.

4.1.1 Gefahrenpotentiale bei Embedded-Systemen

Bei Systemen, die vollständig ohne Smartphone betrieben werden, liegt es in den Händen des OEM, ob Applikationen von Open-Source-Anbietern die physische Sicherheit, die Fah­rerkonzentration, die HMI-Hoheit sowie Datenschutz und Datensicherheit gefährden. Eine

Abbildung in dieser Leseprobe nicht enthalten

Tabelle 4,1: Gefahrenpotentiale eines Embedded-Systems

Ausnahme ergibt sieh, wenn der Hersteller aueh Drittanbieter Applikationen für die eigene Plattform programmieren lässt.

Von der Benutzung eines Web-Browsers abgesehen, ist die HMI-Hoheit in jedem Fall gewähr­leistet, Die Anfälligkeit für Attacken durch Malware kann ebenfalls als niedriger eingeschätzt werden als bei offenen Architekturen, Allerdings liegt gerade bei Embedded-Systemen eine stärkere Vernetzung des Multimedia-Systems mit den Steuergeräten - aueh mit sicherheits­kritischen Systemen - vor, sodass ein Hacker-Angriff, der nicht über Apps eingeschleust wird, einfacher wird (siehe Abschnitt 4,3), Im Hinblick auf Datenschutz und -Sicherheit besitzt der Hersteller zunächst als einziger Akteur Zugang, Lediglich das Angebot fremder Dienste wie Google Maps oder aueh Facebook ermöglicht es anderen Akteuren, Daten aus dem Fahrzeug­Multimedia-System heraus zu sammeln. Welche Dienstarten für welches Sicherheitskriterium eine Gefahr darstellen können, ist in Tabelle 4,1 zusammengefasst.

4.1.2 Gefahrenpotentiale bei Brought-In-Systemen

Die Unterschiede zwischen den Gefahrenpotentialen bei Embedded-Systemen und bei Brought- In-Systemen sind in Tabelle 4,2 fett und mit blauer Schriftfarbe gekennzeichnet. Im Vergleich fällt auf, dass insbesondere die HMI-Hoheit beim Brought-In-System nur mehr geringfügig im Einflussbereich des Herstellers liegt: entweder ist das gesamte Betriebssystem und damit

Abbildung in dieser Leseprobe nicht enthalten

Tabelle 4,2: Gefahrenpotentiale eines Brought-In-Systems (Untersehiede fett und blau)

aueh die Oberfläehe ausgelagert oder einzelne Anwendungen weisen eine von den Vorstellun­gen des Herstellers abweiehende Bedienoberfläehe auf.

Im Falle eines Zugriffs des Smartphones oder des Brought-In-Systems auf fahrzeugbezogene Dienste kommt ein höheres Gefahrenpotential für die physisehe Sieherheit dureh Malware hinzu, Gleiehzeitig können neben dem OEM aueh weitere Akteure, wie Versieherungen, App- Entwiekler, Mobilfunkanbieter und Betriebssystementwiekler Daten zu Fahrt, Fahrzeug und Fahrer sammeln und somit Datensehutz und -sieherheit gefährden.

Die größten Ähnliehkeiten zwisehen Embedded- und Brought-In-Systemen liegen bei den Gefahren der Fahrerablenkung: Anwendungen der Navigation und des Infotainments können sowohl mit als aueh ohne Smartphone visuelle, auditive, biomeehanisehe und kognitive Ab­lenkungsquellen darstellen (siehe 2,4,3 keine Ablenkung des Fahrers), Für solehe Systeme, die aueh die Bedienung des Smartphones trotz Ansehlusses an das Multimedia-System zu­lassen, kann für den Fahrer noeh eine weitere Ablenkungsursaehe entstehen. Ebenfalls kann ein Browser in beiden Fällen zum Einfallstor für Viren werden.

4.2 Gefahrenpotentiale beim Smartphone-Betriebssystem

Nachdem die Gefahrenpotentiale von Embedded- und Bronght-In-Systemen behandelt wur­den, soll in diesem Abschnitt analysiert werden, welche Sicherheitsvorkehrnngen die Betriebs­systeme iOS, Android, Windows Phone und QXX treffen und wo mögliche Schwachstellen liegen,

iPhone-Apps können ausschließlich im App Store hernntergeladen werden, wo laut Apple jede einzelne App untersucht und bestätigt wird, bevor sie angeboten werden kann |Stol4|, Daher gelten iPhones als am besten vor Malware geschützt. Allerdings ist nicht ersichtlich, wie detailliert die Prüfung stattfindet. Sollte trotzdem eine App schädliche Funktionalität anfweisen, kann diese per Fernlösehnng in einer Sandbox isoliert werden, „Unter iOS gibt es allerdings Prozesse des Betriebssystems, die mit Root-Reehten und Vollzngriff laufen. Das könnte eine Schwachstelle für künftige Hacker-Attacken sein“ |Dirl4|, Wenn ein iPhone- Besitzer die Voreinstellungen im iOS anfheben oder Apps ans anderen Märkten installieren möchte, kann er einen „Jailbreak“ durchführen |Zdzl2, S,12|, Damit wirken allerdings keine voreingestellten Sicherheitsmechanismen mehr.

Anders als bei iOS gilt bei Android die Empfehlung, ein Antivirns-Programm zu installie­ren |Hahl4|, sodass bereits zahlreiche Anbieter entsprechender Anwendungen zur Auswahl stehen. Dies liegt insbesondere daran, dass die Apps im Android Market nicht durch Google überprüft werden und auch von externen Seiten Apps heruntergeladen werden können. Die Verantwortung wird dadurch an den Benutzer übertragen, dass er über die Zugriffsrechte der App informiert wird und diesen bei der Installation zustimmt. Zu solchen Rechten zählen der Zugriff auf Kontaktlisten, soziale Netzwerke, Geo-Daten oder die Verbindung zum Internet, Der Verbraucher entscheidet entsprechend selbst, ob die Zugriffsrechte für die Anwendung plausibel erscheinen und dem Nutzen gerecht werden.

Ein Android-Gerät zu infizieren scheint einfach |Hahl4|: Man schreibt eine Malware-App beispielsweise mit einem Trojaner, programmiert eine einfache Anwendung dazu und lädt sie im Android Market hoch. Wird die Anwendung heruntergeladen, so erhält der Hacker einen Einblick in alle Prozesse des Gerätes, auf Passwörter oder gar Zahlungsinformationen, sofern der Besitzer sein Gerät für Online-Banking oder zum Bezahlen verwendet. In Anbetracht der Manipulationsgefahr auf dem Gerät, ist der Spielraum für schädlichen Code jedoch geringer, denn jede einzelne Anwendung und der Benutzer |Dirl4| können nicht auf das Betriebssystem voll zugreifen und sind bei den Kernel-Aufrufen beschränkt: Aufgrund von Virtualisierung kann eine App nur auf die Bereiche zugreifen, die anhand der Zugriffsrechte zugelassen sind, wobei der Benutzer selbst nicht alle Rechte geben kann (siehe Abschnitt 3,7), Im Fall einer Malware-App kann auch bei Android per Fernzugriff eine App gelöscht werden. Ähnlich zum „Jailbreak“ bei iOS, kann der Benutzer ein „Rooting“ durchführen, das ihm Administratorrechte verleiht und die Absicherung durch Virtualisierung entkräften kann. Dies muss allerdings aktiv durch den Besitzer verantwortet werden. Auf welchem Prinzip Rooting basiert, wird in Abschnitt 4,7 vorgestellt.

Während für iOS jede App überprüft wird und bei Android der Benutzer für das Gewäh­ren von Zugriffsrechten verantwortlich ist, bedient sich Windows Phone einer gemischten Strategie: Wie im App Store wird im Microsoft Marketplace jede App untersucht und nur solche können auf dem Betriebssystem installiert werden. Ähnlich zu Android jedoch befin­det sich jede App in einer eigenen Sandbox und jeder einzelne Zugriff auf Bereiche außerhalb der Kapselung erfordert eine Berechtigung durch den Benutzer, Zudem darf ein Windows

Abbildung in dieser Leseprobe nicht enthalten

Tabelle 4,3: Angreiferarten, ihre Kenntnisse, ihr Zugang und ihre Ziele (nach [ + , S.2])

Phone-Gerät nicht an andere Geräte angeschlossen werden und der Informationsaustausch erfolgt auf Basis kryptographischer Verfahren |Dirl4|,

Blackberrys Betriebssystem QXX, welches auch in Atomkraftwerken und Kampfflugzeugen eingesetzt wird, zeigt einen hohen Zuverlässigkeitsgrad |QXX14|, QXX könnte damit auch als sicheres Betriebssystem für die Automobilindustrie fungieren und Blackberry den Zugang mit eigenen Lösungen erleichtern |Dirl4|,

Zusammenfassend lässt sich formulieren, dass jedes Smartphone-Betriebssystem auf seine eigene Art und mit unterschiedlicher Priorität Sicherheit vor Malware und Datenmissbrauch zu gewährleisten versucht, aber Lücken im System nicht vollständig auszuschließen sind. Dies unterstützt die zuvor angedeutete These, dass in der Konsumelektronik traditionell keine so hohen Sicherheitsanforderungen respektiert werden wie in der Fahrzeugindustrie,

4.3 Perspektive eines Automobil-Hackers

Im Grundlagenkapitel 2 wurde ersichtlich, dass neue Marktteilnehmer aus der Mobilfunk­oder Konsumelektronikindustrie Daten über Fahrzeug, Fahrer und Fahrverhalten sammeln wollen, wodurch Datenschutz und Datensicherheit in Gefahr sind. Wissen über die Fahrzeug­architektur eines OEM, die Möglichkeit eines Angriffs und das legale oder illegale Sammeln von Daten stellen dabei eine Form ökonomischer Macht dar. Daher besitzen verschiedene Personengruppen ein Interesse daran, in ein Fahrzeug einzudringen, um es zu manipulieren und damit Macht zu erhalten.

Insbesondere für die physische Sicherheit besteht ein Risiko durch die in Tabelle 4,3 darge­stellten Intentionen zum Angriff auf eine Fahrzeugarchitektur, Während ein Autodieb un­bemerkt Besitz über das Fahrzeug ergreifen will, möchte ein OEM die Fahrzeugarchitektur seiner Konkurrenz untersuchen. Im Folgenden wird die Gruppe der Hacker näher betrachtet, die durch ausreichendes Wissen verknüpft mit verbrecherischen Absichten zu Kriminellen werden können. Da eine Verletzung der physischen Sicherheit die weitreichendsten Folgen haben kann und Gefahren für die physische Sicherheit automatisch mit Gefahren für HMI- Hoheit, keine Ablenkung des Fahrers und Datensicherheit einhergehen, wird der Schwerpunkt der Auseinandersetzung auf die physische Sicherheit gelegt.

In der Vergangenheit gab es bereits zahlreiche im Sinne der Wissenschaft oder im Auftrag von Unternehmen durchgeführte Hacker-Angriffe auf Fahrzeuge [ + ] und [ + ]■

Multimedia-Systeme stellen dafür das Hauptangriffsziel dar, um Zugang zur Fahrzeugar- ehitektur zu erhalten |VM1 , S,17|, Die Experten Charlie Miller und Chris Valasek, die Fahrzeuge verschiedener Hersteller und unterschiedlicher Baujahre auf die Vulnerabilität ge­genüber entfernten Hacker-Angriffen untersuchten, beschreiben das Vorgehen eines Hackers in drei Schritten, In jedem Schritt müssen entsprechende Schwachstellen der folgenden drei Architektureigenschaften ausgenutzt werden |V.\l 1 , S.51:

1, Angriffsfläche: Im ersten Schritt versucht ein Angreifer den Zugang auf das Fahrzeug zu erhalten, was nur über externe Schnittstellen realisierbar ist. Zu dieser Angriffsfläche zählen passive Anti-Diebstahl-Systeme, Reifendruckkontrollsysteme, Funkschliissel-Sys- teme, Bluetooth, Radio, Telematiksysteme, Autotelefon, Wi-Fi, Internet und Apps, Je nach Intention des Hackers könnten die beiden folgenden Schritte entfallen, beispiels­weise, wenn das Ziel, über ein Mikrophon die Geschehnisse im Fahrzeug abzuhören, erreicht wurde |V.\l 1 , S,5|,

2, Netzwerk-Architektur: Ist die Verbindung zu einem Steuergerät hergestellt, hängt es im zweiten Schritt von der Vernetzung dieses Steuergerätes mit anderen Teilen des Fahrzeugs ab. Die Vernetzungsstruktur entscheidet dabei, ob sicherheitskritische Steu­ergeräte manipuliert werden könnten, Separation von Netzwerken wird als notwendiges jedoch nicht hinreichendes Sicherheitskriterium befunden, während eine starke Vernet­zung der fahrzeuginternen Systeme als „leicht hackbar“ |V.\l 1 , S,93| gilt,

3, Cyberphysische Features: Im dritten Schritt ist eine Nachricht in das Netzwerk zu injizieren. Diese muss so beschaffen sein, dass sie über das Bussystem zu einem sicher­heitskritischen Steuergerät gelangt und von diesem auch als Befehl verstanden wird. Letzteres erfordert jedoch, dass das Steuergerät tatsächlich mechanische Funktionen ersetzt, über diesen Bus die Kommandos erhält und im System als „Feature“ betrach­tet wird |V.M 1 I. S.6|, was nicht immer zutrifft. Dabei kann sieh die Funktionalität der Steuergeräte für Lenkung oder Bremsen bei jedem OEM und jedem Modell unterschei­den.

Triviale Vorschläge für mehr Sicherheit sind daher die Reduktion der Angriffsfläche von außen, die Erhöhung der Komplexität einer nicht-authorisierten Datenübertragung, eine se­parierte Vernetzung innerhalb des Fahrzeugs und keine elektrische Steuerung von sicher­heitsrelevanten Funktionen wie Bremsen oder Lenken, Diese grundlegenden Ideen fließen in Kapitel 5 ein; die Schritte eines Angriffs werden bereits in der Gefahrenanalyse entlang der vier technischen Ebenen im Folgenden berücksichtigt.

4.4 Gefahren Ebene 1 - Physische Ebene

In Abschnitt 2,4 wurden vier allgemeine Sicherheitsanforderungen an ein Multimedia-System im Fahrzeug beschrieben: Physische Sicherheit, keine Ablenkung des Fahrers, HMI-Hoheit sowie Datenschutz und Datensicherheit. Damit diese übergreifenden Ansprüche erfüllt wer­den können, müssen sie auf alle vier in dieser wissenschaftlichen Arbeit beschriebenen Ebenen heruntergebrochen werden.

Die physische Ebene erfordert dabei Robustheit und die korrekte Ausführung der Mikrocon­troller. Ebenso ist für bestimmte Steuergeräte, Sensoren und Aktoren zu erwarten, dass sie bei Fehlfunktion eine Fehlermeldung generieren.

Eine Gefahrenquelle auf der physischen Ebene repräsentiert „X-by-Wire“, wodurch Fahren, Bremsen oder Lenken ohne mechanische Verbindungen möglich ist. Die Steuerung erfolgt dann über elektrische Leitungen und Servomotoren oder elektromechanische Aktoren. Soll­te es beim Einsatz dieser Technologien zum Ausfall der elektrischen Versorgung kommen, werden Lenken und Bremsen im schlechtesten Fall unmöglich |The02, S,14|,

Eine allgemeine Gefahr auf der physischen Ebene ist die Tatsache, dass die Steuergeräte, Sensoren und Aktoren im Regelfall von Zulieferern hergestellt werden, denen der OEM ver­trauen muss und denen er einen großen Einflussbereich bietet.

4.5 Gefahren Ebene 2 - Physische Datenübertragungs­ebene

Anhand der Grundlagen in Abschnitt 3.5 kristallisieren sieh vier Sicherheitsanforderungen an die Physische Datenübertragungsebene heraus:

1. Echtzeitfahigkeit: Besonders relevant für sicherheitskritische Steuergeräte und hoch- priore Anweisungen ist die Echtzeitfähigkeit, da zu spät oder gar nicht ankommende Nachrichten den Fahrtzustand gefährden können.

2. Hohe Datenübertragungrate: Die Anforderung nach einer schnellen Übertragung geht auch damit einher, dass kein Meldungsstau im seriellen Bussystem entstehen darf.

3. Hohe Datenübertragungssicherheit: Ebenso darf nur eine geringe Anzahl an Bit­übertragungsfehlern entstehen, die möglichst korrigierbar sind.

4. Hohe Verfügbarkeit: Gleichzeitig darf kein sequentieller Ausfall des Netzwerks durch den Ausfall eines Kommunikationsteilnehmers oder einer Verbindung eintreten.

Die Gefahren auf der physischen Datenübertragungsebene liegen infolgedessen darin, dass eine der Sicherheitsanforderungen nicht erfüllt wird.

Bei FlexRav beispielsweise wird die Echtzeitfähigkeit durch das zeitgesteuerte TDMA-Ver­fahren geregelt, während eine bedarfsorientierte Interaktion per CSMA/CA bei GAN Kolli­sionen erzeugen und somit die Echtzeitfähigkeit gefährden kann.

Inwiefern auch über Ethernet Daten in Echtzeit ausgetauscht werden können, gilt es zu untersuchen: „Wichtig ist besonders, dass der Prozessor von Geräten, bei denen Echtzeit­kommunikation eingerichtet wird, möglichst gering belastet wird. |,,,| Weniger relevant ist hingegen die Übertragungsgeschwindigkeit auf der Leitung“ |Kunl4|, Die hohe Datenrate bei 100 Mbit/s kann also Latenzzeiten verschiedener Funktionalitäten von Ethernet ausglei- ehen. Allerdings kann es unbemerkt zu Paketverlusten kommen, denn Ethernet wurde nicht nach Echtzeit-Anforderungen entwickelt |TEDR1 , S.381|. Zwar sind mit Ethernet auch 8 verschiedene Prioritätsstufen unterscheidbar, aber im Vergleich zu 2048 Stufen bei GAN ist die Priorisierung unpräzise |TEDR1 , S.381|. Nicht zuletzt spielen die Protokolle auf

höheren Schichten eine relevante Rolle: TCP stellt sicher, dass alle Pakete beim Empfän­ger ankommen, gefährdet jedoch die Geschwindigkeit; UDP hingegen sendet Pakete ohne Berücksichtigung von Empfangsbestätigungen |WHB12, S,58|, Es erscheint daher sinnvoll, eigene Protokolle für das Ethernet im Fahrzeug zu erstellen und die standardisierte Techno­logie nicht für sicherheitskritische Bereiche anzuwenden.

Im Hinblick auf die Topologie sind ebenfalls Gefahren zu verzeichnen: Die Stern-Topologie mit einem Switch im Zentrum, welche bei FlexRav zum Einsatz kommt, gilt als „fehlertole­rant“ [ + , S.80] und mit besonders geringen Latenzzeiten versehen, da zwischen den

Steuergeräten dann eine Punkt-zu-Punkt-Kommunikation erfolgt. Im Vergleich zu einer Li­nientopologie kann beim Stern der Ausfall einer Verbindung nicht zum Totalausfall führen [ + , S.80], jedoch wäre der Ausfall des zentralen Steuergerätes gefährlich. Der Master im LIX-Bus stellt eine ähnliche Gefahr dar und könnte das betroffene CAX-Steuergerät beeinflussen |WWP0 , S,7|,

Auf der physischen Datenübertragungsebene ist zudem die Gefahr durch Diagnose-Zugänge zur Fahrzeugarchitektur nicht zu vernachlässigen: Laut [ + , S.2] erlaubt On-Board.

Diagnosties (OBD) das Lesen und Schreiben von und auf das fahrzeuginterne Xetzwerk und die Installation von Software auf den Steuergeräten, Indem OBD vollen Zugriff auf zahlreiche Steuergeräte erlaubt, wird es zu einem der relevantesten physischen Angriffspunkte.

Xieht jedes Steuergerät und nicht jedes Bussystem ist gleich anfällig: FlexRav und LIX, die eine zeitgesteuerte Interaktionsstruktur aufweisen, erlauben dem Angreifer lediglich einen Manipulationsraum innerhalb der zeitlichen Ressourcen, die dem befallenen Steuergerät zu­gewiesen sind. Im bedarfsorientierten CAX-Xetzwerk hingegen kann der Angreifer hoeh- priore Xaehriehten versenden, ohne die genaue Struktur des Busses zu kennen, und somit den Versand vorgesehener Xaehriehten blockieren [ + , S.3], Gleichzeitig ist CAX mitnur 8 übertragbaren Bits nicht für kryptographisehe Methoden unter Berücksichtigung der Echtzeitfähigkeit geeignet. Es darf jedoch nicht unberücksichtigt bleiben, dass gerade ein Angriff auf das Zeitmanagement im FlexRay-Xetzwerk beispielsweise über den Bus-Wächter die Ressourcenzuweisung zum Absturz führen kann |WWP(U, S,7|, Eine ähnliche Herausfor­derung stellt sich bei MOST: Im ebenfalls zeitgesteuerten Xetzwerk können falsche „Timing Slots“ die Synchronisationsmechanismen stören oder unterbrechen |WWPR , S,7|.

4.6 Gefahren Ebene 3 - Software-Datenübertragungsebene

Drei Sicherheitsanforderungen an die Software-Datenübertragungsebene sind in Abschnitt 3.7 bereits vorgestellt worden: Vertraulichkeit - nur der Empfänger kann die Xaehrieht le­sen; Integritätsprüfung - Daten wurden nicht verändert; Authentifizierung - der Sender ist korrekt identifiziert. Hierbei ist zu beachten, dass verschiedene Konzepte für Informationssi­cherheit existieren: Eines der bekanntesten Konzepte ist die CIA-Triade mit den Elementen „Confidentiality“, „Integrity“ und „Availability“, Das Konzept der Parkerian Hexad fügt zu­sätzlich „Possession or Control“, „Authenticity“ und „Utility“ hinzu |BosO! , S.43 ff,|. Daneben ist im Fahrzeug jedoch auch die Echtzeitfähigkeit für diejenigen Systemparts zu gewährleis­ten, die auf der physischen Datenübertragungsebene echtzeitfähig sein müssen. Dies kann in einem Konflikt zur Kryptographie stehen, bei der möglichst hohe Komplexität erreicht wer­den soll. Ein kryptographisehes Verfahren, das die Echtzeitfähigkeit in einem kritischen Be­reich gefährden könnte, ist dementsprechend nicht einsetzbar. Allgemein kann für den Einsatz

kryptographiseher Verfahren im Fahrzeug ein Zielkonflikt zwischen RAM-Verbrauch, Schlüs­sellängen, Datendurchsatz, Codegröße, Flexibilität und Zuverlässigkeit festgestellt werden |W01 , S.136|.

Ein großes Sicherheitsrisiko birgt ebenfalls die Speicherung von Schlüsseln in der Hardware, Daher werden kryptographische Schlüssel oft in speziellen „Hardware Security Modules“ ge­speichert, die im Falle eines Aufbrechens des Behälters den Schlüssel löschen oder mit einer Säure unlesbar machen |PZH13, S,17:18|.

Für bestehende CAX-Xetwerke wurde gezeigt, dass die meisten krvptographischen Anfor­derungen aus IT-Sicht derzeit nicht erfüllt werden |HKD08, S.2411: Vertraulichkeit ist nicht gewährleistet, da bei CAX grundsätzlich alle Steuergeräte alle Xachrichten lesen können, was entsprechend auch einem Angreifer möglich ist, der in das Xetzwerk eingedrungen ist, Integrität wird durch die CRC-Checksum nicht hergestellt, weshalb Daten auf dem Weg zum Steuergerät unbemerkt verändert worden sein könnten, Authentifizierung soll ursprünglich über Xachrichten-IDs geschehen; jedoch kann ein Hacker eine Xachricht mit derselben ID versenden, die andere Steuergeräte regelmäßig erhalten. Ebenfalls wurde für einige Fahr­zeuge untersucht, dass der Angriff auf ein Steuergerät mit CAX-Anbindung ausreicht, um das gesamte Fahrzeug kontaktieren zu können [ + , S.6], Diese Einschränkungen und fehlende kryptographische Verfahren stellen die Sicherheit des CAX-Xetzwerkes innerhalb einer offenen Infrastruktur in Frage,

4.7 Gefahren Ebene 4 - Software-Ebene

Im Hinblick auf die Sicherheitsanforderungen an die Software-Ebene sind die Absicherung vor Schadprogrammen und die Programmierung möglichst sicherer Schnittstellen zu nennen. Zudem ist für die oberste Ebene eine Anpassung an sämtliche darunter liegende Ebenen und ihre Architektur zu berücksichtigen, da die Software letztendlich auf die entsprechenden Ressourcen zugreifen muss.

In Abschnitt 3,7,1 wird das Betriebssystem als Menge von Algorithmen beschrieben, welche für die Ressourcenallokation und den Zugriff der Software auf den Kernel über „Supervisor Calls“ verantwortlich ist. Wenn ein Anwendungsprogramm in Ring 3 einen Befehl in Ring 0 aufrufen möchte, ist an den Ring-Schnittstellen festzustellen, ob der Aufruf autorisiert ist. Aus diesem Grund kann die korrekte Behandlung von Calls nur erfolgen, wenn die Schnitt­stellen und ihre Puffer in realen Speichern sicher sind. Wenn es einem Angreifer gelingt, die Schnittstellen und die Puffer zu manipulieren, ist die Sicherheit gefährdet |YSDiSW0! , S,4|, Inwiefern eine solche Manipulation bei Virtualisierung angewandt werden kann, wird im Folgenden beschrieben,

„Da eine Virtuelle Maschine unabhängig vom Zustand der physischen Hardware den Anwen­dungen eine betriebssystemartige Umgebung ermöglicht, erfolgt eine Trennung zwischen phy­sischem und logischem Systemzustand, Diese Entkopplung birgt sowohl Sicherheitsvorteile, als auch Gefahren, die im Kontext der Virtualisierung neue Dimensionen annehmen“ |PZH13, S,17:l|, In den Abschnitten 3,7,2 und 3,7,3 der Grundlagen wird erläutert, dass durch Vir­tualisierung Anwendungen im User-Mode in Ring 3 vom direkten Zugriff auf Kernel-Befehle in Ring 0 abgeschottet werden und per Sandboxing unerlaubtes Ausbrechen aus Ring 3 de- tektiert und isoliert werden kann, Xiehtsdestotrotz wird in Abschnitt 4,2 beschrieben, wie in bestehenden Smartphone-Betriebssystemen der Benutzer Administratorrechte erhält und damit auch Sicherheitsvorkehrungen aushebeln kann.

Ein besonders hohes Sicherheitsrisiko entsteht dann, wenn nicht der Benutzer wissentlich, sondern ein Sehadprogramm ein Rooting durchführt und dadurch selbst unerkannt zum Administrator wird. Diese Malware wird als „Rootkit“ bezeichnet.

Als „Typ-3-Malware“ gehören Rootkits zu den gefährlichsten Schadcodes, da sie nicht in­nerhalb einer Virtuellen Maschine, sondern neben der gesamten Virtualisierungsarchitektur angreifen, Typ 0, Typ 1 und Typ 2 hingegen sind innerhalb der Virtualisierungsarchitektur beherbergt und dadurch dort detektierbar |RutO(, S.7 f,|. Zu Typ-O-Malware gehören bei­spielsweise die in Abschnitt 4,2 beschriebenen Mal-Ware-Apps, die unter Verantwortung des Nutzers im Android-App-Store heruntergeladen werden können. Im Hinblick auf die Typ- 3-Malware ist in Abbildung 4,1 zu erkennen, dass ein Rootkit die gesamte Architektur in einer Virtuellen Maschine kapselt und dabei selbst einen Hypervisor kreiert, der diese Vir­tuelle Maschine überwacht. Parallel erschafft es ein eigenes Betriebssystem, auf das weitere schädliche Programme geschleust werden |PZH13, S,17:20|, Solche Gefahren, die über eine Xetzwerkverbindung auf das System gelangen, können den Hypervisor, Software, das Be­triebssystem und alle Anwendungen angreifen |PZH1.‘ , S,17:10|, Beispielsweise kann durch das Klonen von Virtuellen Maschinen auf sensitive Daten zugegriffen werden, die gerade in der Virtuellen Maschine, in Puffern oder Zwischenspeichern verwendet werden |PZH13, S,17:22 f.|.

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 4,1: Injektion eines Rootkits und dessen Auswirkungen (nach |KC0(, S,19| und |RutO( , S.7 f,|)

Es lassen sieh zwei Arten von Rootkits unterscheiden: das Virtual Machine Based Rootkit (VMBR) und das Hardware Virtualization Based Rootkit (HVBR), Der Unterschied liegt darin, dass VMBR erst nach dem Xeustart des Gerätes, HVBR jedoch bereits zur Laufzeit das Zielbetriebssystem abkapseln kann |JC14, S,92|.

Im Gegensatz zu VMBR kann HVBR keine bereits virtualisierten Umgebungen in einer Vir­tuellen Maschine einschließen. Unter der Voraussetzung, dass ein Multimediasystem für das Fahrzeug in jedem Fall mit Virtualisierung arbeitet, ist diese Ausprägung des Schadpro­gramms irrelevant, sodass nur VMBR weiter betrachtet wird |JC1 , S,92|.

VMBR wiederum hat eigene Schwachstellen: Da es erst wirksam wird, nachdem ein Xeu­start des Systems stattgefunden hat, kann das Starten zur Detektion verwendet werden. Beispielsweise ist es dabei möglich zu überprüfen, ob als erstes das Host-Betriebssystem gestartet wird; im negativen Falle wird das Starten unterbunden und eine Fehlermeldung angezeigt |KC06, S,9|, Ein Fahrzeug deswegen möglicherweise aber nicht mehr verwenden zu können, wäre für den Benutzer ein großes Problem, Eine Alternative, um ein solches Rootkit detektieren und das Betriebssystem als erstes starten zu können, ist die Verwen­dung eines externen Mediums wie einer CD oder einem per USB angesehlossenen System, Für das Fahrzeug scheint dies jedoch besonders riskant. Eine Methode, die mehr Sicherheit zu garantieren scheint, kommt dem VMBR zuvor und lässt einen Hypervisor unterhalb des Betriebssystems laufen, das - mit der entsprechenden Funktionalität versehen - den Übergriff durch VMBR verhindern kann |JCU , S,94|, Insgesamt handelt es sieh bei diesem Sehadpro- gramm um einen Bereich der Cybersieherheit, in dem Sieherheitsexperten und Hacker stets in Konkurrenz stehen.

Im Hinblick auf die Sehnittstellenprogrammierung bestehen viele Gefahren für die physische Sicherheit des Fahrzeugs, Im Grundlagenkapitel wurde bereits erwähnt, dass eine Differen­zierung notwendig ist, wenn APIs betrachtet werden: Einerseits existieren APIs, welche vom Multimedia-System Dritt-Entwieklern angeboten werden. Andererseits gibt es auch APIs, welche beispielsweise von Soeial-Media-Seiten wie Faeebook oder Twitter für Entwickler al­ler Art angeboten werden. In beiden Fällen ist es möglich, dass zu viele Aufrufe einer API zu Denial-of-Serviee führen |SirU , S,3| oder über die Schnittstellen unsichere Zugriffe auf die Fahrzeugarehitektur ermöglicht werden. Letzteres ist beispielsweise mithilfe von „SQL Injec­tions“ möglich, wodurch Daten gelesen und verändert oder auch bestimmte Funktionalitäten von außen kontrolliert werden können. Einfache Gegenmaßnahmen sehen vor, dass die Daten so gespeichert werden, dass sie von außen nicht direkt verstanden werden können, dass nur geringfügige Zugriffsreehte ermöglicht und spezielle Firewalls eingesetzt werden |Infl3|.

Zusammenfassend lässt sieh formulieren, dass neben spezifischen Anforderungen auf allen vier technischen Ebenen die Anforderung nach der Echtzeitfähigkeit erfüllt sein muss. In diesem Kapitel kristallisiert sieh heraus, dass erstens PC-Welt und Konsumelektronik für sieh betrachtet bereits zahlreiche Gefahrenpotentiale bergen und zweitens ihre Kombination mit der Automobilarchitektur neue Sicherheitsrisiken repräsentiert. Welche Konzepte in der Forschung vorgeschlagen werden und wie die Konzeption einer sicheren Fahrzeugarehitektur dennoch erfolgen kann, wird im nachfolgenden Kapitel beschrieben.

Abbildung in dieser Leseprobe nicht enthalten

5. Konzepte und Vorschläge für eine sichere Fahrzeugarchitektur

Für die Konzeption von Mechanismen zur Sicherung von Informationen bestehen in der Com­puterwelt seit 1975 acht verschiedene Prinzipien, die befolgt werden können |SS7¡ , S,1282|:

1, Economy of mechanism: Halte die Sieherheitsarehitektur so einfach wie möglich. Dies erleichtert das Auffinden von Fehlern in Soft- und Hardware,

2, Fail-safe Defaults: Bestimmte Zugriffsreehte und Einstellungen sind von vornherein verwehrt. Erst nach einer expliziten Umstellung durch den Benutzer sind Einstellun­gen teilweise veränderbar. Die Voreinstellungen jedoch sollten die sicherste Variante darstellen,

3, Complete Mediation: Jeder Zugang zu jedem Objekt muss kontrolliert werden. Eine Kontrolle ist ebenfalls beim Initialisieren, Herunterfahren und Xeustarten erforderlich,

4, Open Design: Die Sieherheitsarehitektur darf nicht geheim sein. Allgemein darf ei­ne Architektur nicht dadurch gesichert werden, dass sie potentiellen Angreifern nicht bekannt ist,

5, Separation of Privilege: Der Zugang zu bestimmten Ressourcen darf nicht von einer einzigen Bedingung abhängen. Beispielsweise muss durch eine zweite oder dritte Partei eine Zugangsbestätigung erteilt werden,

6, Least Privilege: Eine Anwendung oder ein gewisser Bereich dürfen ausschließlich die Zugriffsmögliehkeiten besitzen, die sie tatsächlich benötigen,

7, Least Common Mechanism: Mechanismen und Wege zum Zugriff auf Ressourcen sollten nicht unter verschiedenen Anwendungen geteilt werden,

8, Psychological Acceptablity: Die Benutzung einer Anwendung muss für den User einfach sein. Daher darf ein Sieherheitsmeehanismus die Verwendung nicht verkompli­zieren.

Diese verschiedenen Prinzipien tauchen auch hinter jedem Konzept zur Sicherung eines Multimedia-Systems im Fahrzeug auf. Im Folgenden werden zunächst bestehende Konzepte auf den vier technischen Ebenen beschrieben. Im Anschluss werden drei eigene Konzeptions­Ansätze vorgestellt, die verschiedene zuvor erläuterte Konzepte aus Forschung und Industrie vereinen. Dabei wird stets auf die hier beschriebenen grundlegenden acht Design-Prinzipien nach Saltzer und Sehroeder verwiesen.

5.1 Konzepte Ebene 1 - Physische Ebene

Auf der physischen Ebene sind „Attack Detection“ bzw, „Intrusion Detection“ auf den Steu­ergeräten möglich.

Mit Intrusion Detection kann bei nach außen vernetzten Steuergeräten ähnlich einer Fire­wall ermittelt werden, ob der Xetzwerkknoten angegriffen wird. Dabei können einerseits mit programmierten oder selbst-lernenden Systemen Anomalien entdeckt werden. Andererseits dienen Status-Modellierung oder Experten-Systeme dazu, auf Basis bekannter Angriffsvorge­hensweisen fremdes Eindringen zu detektieren |AxeOO, S.6 f,|, Falls in einem Steuergerät auch Digitale Signaturen implementiert werden, kann das Steuergerät als „Gateway-Firewall“ be­trachtet werden. Die Kommunikationsregeln beruhen dann auf den Authorisierungen, die in den Zertifikaten der Steuergeräte-Controller beschrieben sind |WWP04, S,ll|.

Mithilfe von Attack Detection hingegen kann am Steuergerät bzw, auf einer Übertragungslei­tung untersucht werden, ob falsche Nachrichten beispielsweise durch Hacker gesendet werden. Im traditionellen Fahrzeugnetzwerk kann das Finden solcher Nachrichten über eine zu hohe Datenrate gemessen werden, die vom regulären Xaehriehtentransport abweicht |V.M 1 , S,91|.

Im Hinblick auf Standardisierungen ist an dieser Stelle auch die Herstellerinitiative Software (HIS) zu nennen, welche als Kooperation zwischen Audi, BMW, Daimler, Porsche und VW Standards für Software in elektronischen Steuergeräten schafft |Bell4|.

5.2 Konzepte Ebene 2 - Physische Datenübertragungs­ebene

Da keine konkreten Konzepte zur Veränderung der traditionellen Bussysteme CAN, LIN, FlexRay und MOST vorliegen, werden in diesem Abschnitt lediglich Konzepte für Fahrzeug­Ethornet behandelt.

In Abschnitt 3,5,3 wurde bereits erwähnt, dass der Trend zu Ethernet im Automobil durch die OPEN Alliance SIG unterstützt wird und in Zukunft Ethernet für kamerabasierte Komfort­Dienste und allgemeines „Audio Video Bridging“ (AVB) zu erwarten ist. Im Rahmen der Bemühungen der OPEN Alliance SIG wurde die Technologie „BroadR-Reaeh“ von Broad­com mit 100 Mbit/s Übertragungsrate vorgestellt und auf der physischen Ebene spezifi­ziert |OPE14a|, |Brol4|, jedoch bisher nicht als Industrie-Standard zertifiziert. Dabei erfolgt eine serviee-orientierte Kommunikation zwischen den Steuergeräten, wobei ihre Mikrokon­troller jeweils als Server bzw, Client dienen |ZP1 , S.6 ff,|. Die BroadR-Reaeh-Technologie erlaubt den Einsatz verschiedener Kabelarten sowie verschiedener Media-Aeeess-Controller- Sehnittstellen (MAC) über den IEEE-Ethernet-Standard 802,3 |ICS12|, Für das Fahrzeug wird bevorzugt ein Einzelpaar-Kabel verwendet |Rut08|, bei dem über die Quadraturam­plitudenmodulation (QAM) mit einer Bitübertragung gleieh mehrere Datenbits übertragen werden, indem Amplitude und Phase zur Informationsübermittlung genutzt werden. Insge­samt bedient sieh BroadR-Reaeh bestehender Ethernet-Standards, ist mit ihnen kompatibel und erlaubt hohe Datenraten.

Dass mit Ethernet die in Abschnitt 3,5,3 beschriebenen Kollisions-Domänen möglich sind, kann eine Trennung von Netzwerken innerhalb des Fahrzeuges erleichtern. Inwiefern mit IP und Ethernet eine sichere Middleware implementiert werden kann, wird im folgenden Abschnitt 5,3 beschrieben.

5.3 Konzepte Ebene 3 - Software-Datenübertragungsebene

Derzeit werden bereits kryptographisehe Verfahren verwendet, bevor den Prozess eines Firmware­Updates zu sichern. Diese sichern vor simplen Angriffen über die OBD-Zugriffsstelle ab [ + , S.3], Ein allgemeines Problem für den Einsatz krvptographischer Verfahren ist al­lerdings die Beschränkung der Rechenleistung von Steuergeräten [ + , S.8], wodurch die Echtzeitfähigkeit gefährdet ist [ + , S.94], Jedes Konzept für ein krvptographisches Verfahren im Fahrzeug muss auf Sicherheit, Buslast und Latenzzeit hin analysiert werden. Meist im Hinblick auf die Gefahren durch Car2X-Anwendungen wurden verschiedene Konzepte für die sichere interne Kommunikation vorgestellt: Manche Konzepte beruhen auf symmetrischen krvptographischen Verfahren [ + ] und [ + ], die meisten auf asymmetrischen Ver­fahren [ + ], Im Folgenden werden ausgewählte Projekte kurz vorgestellt.

- Innerhalb des EVITA-Projektes von 2008 bis 2011 wurden drei Arten von Hardware Security Modulen festgelegt. Die besonders sicherheitsrelevanten Bereiche werden mit asymmetrischen krvptographischen Verfahren und Hash-Funktionen gesichert, wäh­rend bei mittel oder gering sicherheitsrelevanten Modulen symmetrische Verfahren zum AEKH+ , S.4].

- In [ + ] wird ein Konzept für weniger sicherheitsrelevante Steuergeräte mit leichten Hardware Security Modules vorgestellt. Dabei werden die Xutzbits selbst symme­trisch verschlüsselt und der Schlüssel wiederum asymmetrisch verschlüsselt, was sich als hybrider Algorithmus beschreiben lässt. Allerdings werden hier keine Digitalen Si­gnaturen oder Zertifikate berücksichtigt. Die Verteilung der Schlüssel erfolgt über einen oder mehrere Schlüssel-Master auf einem oder mehreren Steuergeräten, sodass nicht global alle Schlüssel bekannt sind. Jeder symmetrische Schlüssel besitzt eine begrenzte Lebenszeit und wird nach einer Sessionlänge von 48 Stunden spätestens ausgetauscht. Damit das System auf CAX verwendet werden kann, wird ein zusätzliches Protokoll mit einem eigenen Header oben aufgesetzt,

- Das AUTOSAR-Konsortium hat die Standardschnittstelle „Crypto Abstraction Libra­ry“ entwickelt, mit der kryptographisehe Funktionen in Software- und/oder Hardware einheitlich verwendet werden können |AUT13|,

- In [ + ] wird ein einfaches symmetrisches und vor allem statisches Konzept prä­

sentiert: In einer nxn-Matrix werden die symmetrischen Schlüssel für jeweils alle nSteuergeräte in einem Schlüssel-Master gespeichert. Es dürfen keine weiteren Steuer­geräte hinzugefügt werden, weshalb das System als „Key Predistribution System“ be­zeichnet wird. Die Latenzzeit ist dadurch vergleichsweise gering,

• Ein asymmetrischer Ansatz unter anderem mit Elliptischer-Kurven-Kryptographie wird in [ + ] vorgestellt. Das Paper beschreibt, wie beispielsweise mit dem Anhängen

von Zertifikaten an jede zehnte Nachricht die Buslast und die Latenzzeiten gesenkt werden können. Welche Verfahren tatsächlich bereits eingesetzt werden, ist derzeit das Geheimnis der OEMs, aber es kann davon ausgegangen werden, dass in vereinzelten Bereichen nach innen und außen kryptographisehe Verfahren wie auch die Elliptisehe- Kurven-Krvptographie beispielsweise nach [ + ] verwendet werden. Ein wesentlicher Grund kann sein, dass mit kleineren Zahlen, also auch geringerer Leistung, eine genauso hohe kryptographisehe Sicherheit erreicht werden kann wie mit RSA,

Alles in allem bestehen verschiedene Konzepte zum Einsatz kryptographiseher Verfahren in der Fahrzeugarchitektur, die derzeit allerdings noch nicht flächendeckend umgesetzt werden, aber einen vermehrten Einsatz in der Zukunft vermuten lassen.

Im Rahmen des Projektes „Sicherheit in Eingebetteten IP-basierten Systemen“ (SEIS) des Bundesministeriums für Bildung und Forschung werden von verschiedenen Institutionen Konzepte mit dem Ziel ausgearbeitet, „das Internet Protokoll als bewährten Standard für die Kommunikation zwischen eingebetteten Systemen im Fahrzeug zu übertragen“ |BMB09|.

Seitens der BMW Forschung und Technik GmbH wurde eine umfassende IP-basierte Kom- munikations-Middleware für Fahrzeuge konzipiert und implementiert, die neben anderen Mechanismen auch ein modulares Security-Framework vorsieht |WecL , S,10|, Die Grundidee besteht darin, die im Fahrzeug traditionellen Gateways durch die IP-basierte Middleware zu ersetzen, um verschiedene Kommunikationsnetze zu koppeln. Im Gegensatz zu den Gateways soll die Middleware besonders anpassungsfähig und absicherbar sein |WWL , S,l|, Während Gateways jedes Paket von einem Bus zum anderen übersetzen müssen, können auf IP-Basis Pakete über Switches oder Router weitergeleitet werden [ + , S.2], Dies erfordert jedoch den Einsatz des Siebenschichtenmodells statt des traditionellen Dreischichtenmodells.

Wie auf der linken Seite der Abbildung 5,1 dargestellt, wird oberhalb einer Vermittlungs­und Transportschicht die IP-basierte Fahrzeug-Middleware auf den Schichten 5 bis 7 ein­gefügt, Auf welche Weise welche Steuergeräte-Arten miteinander kommunizieren, wird im Koordinationsmodell implementiert. Im rechten Bereich der Abbildung 5,1 ist die Architek­tur des Security-Frameworks zu erkennen: Es besteht aus Modulen, die jeweils eine Sicher­heitsfunktionalität umfassen; jedes Modul beinhaltet wiederum Security-Mechanismen, die über Plug-Ins austauschbar sind |Wecl4, S,109|, Jedes Modul stellt des Weiteren Security­Schnittstellen zur Verfügung, die innerhalb der Funktionsschnittstelle von den Anwendungen verwendet werden können. Möchte eine Anwendung auf bestimmte Bereiche zugreifen, so müssen entsprechende Security-Module verwendet werden.

Die Schichten 2 bis 4 können auf bestimmte Module im Security-Framework direkt zugrei­fen, während für bestimmte Kommunikationspartner - insbesondere bei Anwendungen - der Zugriff auf die Security-Mechanismen über den innerhalb der Middleware gelegenen Security- Stub verläuft. Über die Plug-Ins können die Security-Mechanismen flexibel erneuert werden, während die Schnittstelle für den Security-Stub gleich bleibt.

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 5,1: IP-basierte Kommunikations-Middleware mit modularem SeeurityWW11 Wecl4 BGJ + , S.3])

Die Kommunikationswege werden sehließlieh ähnlieh einem Handshake konfiguriert: In jedem Steuergerät liegen eigene Protokolle und Seeurity-Meehanismen vor, sodass für die Kommuni­kation zwisehen zwei Steuergeräten das sieherste Protokoll festgelegt werden muss, das beide implementieren |Weel· , S,107|, Im Regelfall werden diese Kommunikationswege statisch zu einem bestimmten Zeitpunkt konfiguriert. Lediglich bei Änderungen wie dem Hinzufügen von Konsumelektronik-Geräten oder dem Austausch von Plug-Ins werden die Kommunika­tionswege dynamisch geändert oder statisch vollständig rekonfiguriert. Diese Kommunika­tionswege zwisehen zwei Steuergeräten bestimmen, welche Seeurity-Meehanismen aus dem modularen Security-Framework zum Einsatz kommen.

Die auf der rechten Seite der Abbildung 5,1 dargestellte Security-Infrastruktur stammt von einer eigenen Arbeit des SEIS-Projektes und unterteilt drei Ebenen der Sicherheit mit je­weils zwei Security-Mechanismen [ + , S.3]: Die „Security Decision Management und Monitoring“-Ebene kümmert sich um Authorisierung und das Auffinden von Verstößen gegen die Sicherheitsbestimmungen, Vertraulichkeit, Integrität und Authentifizierung bei der inter­nen und externen Kommunikation werden hingegen über die Kommunikationsebene geregelt. Damit bei der Kommunikation auch kryptographische Verfahren greifen, ist die „Cryptogra­phic Processing“-Ebene für die sichere Speicherung von Schlüsseln und die Kontrolle der Vor- und Entsehliisselungsprozesse zuständig. Sie besitzt damit eine unterstützende Funk­tion für die Kommunikationsebene, Die Aufgaben der sechs Module werden im Folgenden kurz genauer vorgestellt [ + , S.4 ff,]:

- Intrusion Management Module: Je nach Sicherheitsrichtlinien, die im Policy Ma­nagement Module definiert sind, reagiert dieses Modul auf Verstöße beispielsweise durch die Isolation von Prozessen mit verdächtigem Verhalten, Die Daten können zen­tral über alle Steuergeräte gesammelt und so gefährliche Verhaltensmuster entdeckt werden, um Fahrer, OEM und andere Akteure zu alarmieren. Abhängig davon, ob das Steuergerät datenintensive Multimedia-Dienste oder sicherheitskritische Sensoren und Aktoren repräsentiert, wird das Intrusion Management anders gehandhabt.

- Secure Communication Module: Die Ausführung der zuvor genannten Protokolle wird in diesem Modul gesichert. Es bietet den Anwendungen außerdem eine API, mit denen bestimmte Kommunikationswege besonderen Sicherheitsanforderungen gerecht werden. Voreingestellt sind jedoch Protokolle, welche die vom Policy Management Mo­dule vorgegebenen Richtlinien einhalten. Wie in Abbildung 5,1 erkennbar, besitzt das Secure Communication Module die meisten Verbindungen zu anderen Modulen.

- Authentication Management Module: Dieses Modul beinhaltet Informationen über jedes interne und externe Gerät wie Prozessstatus, Protokolle und IDs, Damit kann es die Analysen des Intrusion-Managements unterstützen, aber auch Sender und Empfänger von Xaehriehten und Digitale Signaturen identifizieren.

- Key Management Module: Dieses Modul ermöglicht den Zugriff auf krvptographi- sehe Schlüssel und sichert die Schlüsselbits beispielsweise in einem Hardware Security Module ab,

- Crypto Service Module: Das Modul bietet Algorithmen zur Ver- und Entschlüs­selung, zur Erstellung und Prüfung Digitaler Signaturen und die Anwendung vieler weiterer kryptographiseher Verfahren,

Wie bereits angedeutet, arbeiten diese Module nicht unabhängig voneinander, sondern ko­operieren bei jedem Kommunikationsvorgang, Dieser Einsatz mehrerer Instanzen kann als Umsetzung des Prinzips „Seperation of Privilege“ interpretiert werden, da die Verantwortung auf mehrere Einheiten verteilt wird und dadurch auch mehrere Kontrollinstanzen vorliegen. Ob die Module auf jedem Steuergerät oder zentral implementiert werden, ist eine Frage der Umsetzung und Umsetzbarkeit, Eine zentrale Implementierung kann zwar leichter beschädigt werden, erlaubt jedoch flexiblere Updates.

Diese Architektur kann so eingesetzt werden, dass eine API der Middleware den App- Entwieklern über die Funktionsschnittstellen zur Verfügung steht. Dadurch kann auf dem Steuergerät, welches das Multimedia-System beherbergt, direkt auf die Middleware zugegrif­fen werden.

Ein weiteres Konzept innerhalb des SEIS-Projektes verwendet das zuvor beschriebene Kon­zept für interne Kommunikation zwischen Steuergeräten und fügt darauf aufbauend einen Security-Proxy hinzu, der die Kommunikation zu externen Konsumelektronik-Geräten wie Smartphones realisiert. Dabei besitzt jede Xaehrieht eines externen Gerätes, das mit dem Fahrzeug kommunizieren möchte, einen „Tag“, welcher Informationen über den Sicherheits­status des Gerätes und der Xaehrieht aufweist. Bevor der Inhalt der Xaehrieht im Fahrzeug ausgeführt wird, muss der Xaehriehten-Tag erst ausgewertet und der Kommunikationspro­zess gegenüber diesem Gerät entsprechend angepasst werden. Durch diese Überprüfung kann potentieller Sehad-Code vor der Ausführung gekapselt werden oder eine Xaehrieht wird erst gar nicht innerhalb des Fahrzeugs weitergeleitet, da bestimmte Kriterien nicht erfüllt sind I 3SHE13, S.68 ff.|.

5.4 Konzepte Ebene 4 - Software-Ebene

Wie in Abschnitt 4,3 angedeutet, erlaubt eine möglichst große Trennung in der Xetzwerk- Arehitektur des Fahrzeugs, dass selbst nach dem Befall eines Steuergerätes keine sicherheits­kritischen Funktionalitäten manipuliert werden können.

Auf der Software-Ebene erfordert dies eine Trennung in der Echtzeitumgebung, was mit Virtualisierung erreicht wird. Aus den im Grundlagenkapitel in Abschnitt 3,7,2 erläuterten Virtualisierungskonzepten gelangen die folgenden für ein sicherheitsrelevantes Konzept nicht in die nähere Betrachtung: Bei der OS-Virtualisierung kann ein Container in den Speicher­bereich eines anderen zugreifen, wodurch keine Sicherheit zu gewährleisten ist. Im Fall der Paravirtualisierung müssen Gastbetriebssysteme so angepasst werden, dass sie selbst mit dem Hypervisor kommunizieren, was gegen die Idee einer Standardisierung spricht und Kompati­bilitätsschwierigkeiten hervorrufen kann. Zudem kann die Vollvirtualisierung ohne Hardware­Assistenz von der mit Hardware-Assistenz abgelöst werden, damit Befehle nicht zusätzlich vom Hypervisor weitergeleitet werden müssen.

Hieraus folgt, dass Vollvirtualisierung mit Hardware-Assistenz, Hosted/Software-Virtuali­sierung und Hardware-Virtualisierung/Partitionierung als sinnvolle Lösungen übrig bleiben: Die Partitionierung bietet die meiste Sicherheit, da die Hardware für verschiedene Betriebs­systeme vollständig getrennt ist und somit kein schädlicher Code weitläufigen Zugriff auf andere Systeme erhält. Bei Vollvirtualisierung bzw, Software-Virtualisierung, welche sieh nur durch den Einsatz eines Typ-1- bzw, Typ-2-Hypervisors unterscheiden, ist die Rootkit- Gefahr präsent. Je nachdem, ob entsprechend der Hypervisor direkt auf der Hardware oder in einem Host-Betriebssystem agiert, müssten unterschiedliche Sicherheitsmechanismen ge­gen Rootkits implementiert werden: Beim Typ-2-Hypervisor könnte das Host-Betriebssystem als zusätzliche Überwachungsinstanz fungieren, aber auch unbemerkt eingekapselt werden. Der Typ-l-Hypervisor kann selbst der „Rootkit Detection“ dienen, jedoch könnte darüber ein weiterer Hypervisor zum Management der Virtuellen Maschinen eingesetzt werden, um operative von Sicherheits-Aufgaben zu trennen |JCl· , S,92|.

Insgesamt sind diese drei Ansätze dafür nutzbar, verschiedene Betriebssysteme nebeneinan­der laufen zu lassen, ohne den Zugriff eines Systems auf ein anderes zuzulassen. Auf dieser Basis kann ein Betriebssystem für OEM-eigene Anwendungen mit internem Zugriff in einem anderen Bereich agieren als das Betriebssystem mit externer Anbindung an das Smartphone, Ebenso lassen sieh auch die Betriebssysteme für Android Auto und Apple CarPlay in unter­schiedlichen Bereichen implementieren und je nach angeschlossenem Smartphone aufrufen.

Als Beispiel für eine solche Virtualisierungslösung mit mehreren Gastbetriebssystemen sei das Unternehmen OpenSynergy zu nennen: Der direkt auf der Hardware aufsitzende Hy­pervisor dieser Lösung koordiniert die voneinander unabhängig laufenden Betriebssysteme, welche Infotainment, Smartphone-Mirroring oder auch das Steuergeräte-Management dar­stellen können |Opel4b|, Eine solche mögliche Architektur ist in Abbildung 5,2 dargestellt.

Aus dem Blickwinkel der Forschung wurde dieser Ansatz ebenfalls im Projekt „Open vehicu­lar secure platform“ (Oversee) verfolgt, „Offen“ bedeutet in erster Linie, dass die Plattform die gleichzeitige Ausführung von OEM- und nieht-OEM-Anwendungen in eigenen Laufzeit­umgebungen ermöglicht. Erst im zweiten Schritt erlaubt diese Plattform beispielsweise die Open-Souree-Entwieklung von plattform- und fahrzeugunabhängigen Anwendungen auf Ba­sis einer öffentlich verfügbaren und standardisierten API [ + , S.3], Dies kann zusammenfassend als eine Form eines Hybrid-Systems betrachtet werden.

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 5,2: Partitionierung mit mehreren Betriebssystemen und Echtzeitumgebungen (nach |0pel4b|)

Sämtliche Konzepte, die auf unteren Ebenen greifen, müssen auch auf der Software-Ebene berücksichtigt werden: So gehört es ebenfalls zur Software-Ebene, ein Steuergerät als Firewall fungieren zu lassen, indem Filter und „Intrusion-Detection“ eingesetzt werden, Hersteller von Mikrokontrollern statten neue Steuergeräte außerdem mit kryptographisehen Modulen wie „Secure Hardware Extension“ (SHE) der Kooperation HIS aus, wodurch authentifizierte Boot-Prozesse einer Software-Manipulation Vorbeugen können [ + , S.3].

Nachdem bestehende Konzepte aus Forschung und Entwicklung beschrieben wurden, widmen sieh die folgenden Abschnitte eigenen Ansätzen zur Konzeption einer sicheren Fahrzeugar­chitektur, welche die bekannten Konzepte zusammenfügen.

5.5 Security-by-Ansatz

Der Security-by-Ansatz strebt ein System mit größtmöglicher Sicherheit an. Dabei folgt dieser Konzept-Ansatz der Überlegung, dass die meisten Sicherheitsmechanismen in der IT den folgenden drei Kategorien zuordenbar sind: „Security-by-Correctness“, „Security-by- Isolation“ oder „Security-by-Obscurity“|Rut06|. Wie ein Konzept unter Berücksichtigung die­ser Security-by-Perspektiven aussieht, wird in diesem Abschnitt dargestellt.

• Security-by-Correctness: Die Annahme lautet, dass vollkommen fehlerloser Code und das Fehlen jeglicher schädlicher Code-Teile die Sicherheit eines Programmes ge­währleisten, Für ein Fahrzeug-Multimedia-System bedeutet dies, dass Code unter größ­ter Sorgfalt geschrieben werden muss sowie zahlreiche Tests und Simulationen durchzu­führen sind. Daraus folgt, dass keine Programmierung durch Drittanbieter zugelassen werden darf, sofern der Code nicht als fehlerfrei eingeschätzt werden kann. Unterstützt wird dies durch das Prinzip „Economy of mechanism“, welches für eine einfache und übersichtliche Architektur plädiert. Die Security-by-Correctness-Perspektive ist aller­dings schwer zu realisieren, da Code letztlich von Menschen geschrieben wird und somit stets Fehler beinhalten kann. Im Hinblick auf Aktualisierung fallen auch Mechanismen zur Überprüfung des aktuellen Sicherheitsstatus beispielsweise vor einem Boot-Prozess

unter die notwendigen Aufgaben, Eine ständige Statusprüfung und Abfrage von Pass­wörtern entspricht wiederum dem Prinzip der „Complete Mediation“, Aus den zuvor beschriebenen Konzepten lassen sieh zudem Intrusion und Attack Detection sowie die Seeure-Hardware-Extension für diesen Bereich als passend definieren.

- Security-by-Isoiation: Diese Perspektive sieht vor, dass ein System so partitioniert wird, dass im Falle von Fehlfunktionen oder Viren in einer Partition die anderen Par­titionen nicht beeinträchtigt werden können. Entsprechend dem Prinzip „Least Com­mon Mechanism“ teilen verschiedene Anwendungen nur gemeinsame Ressourcen, wo dies erforderlich ist und die Sicherheit nicht gefährdet wird. Insbesondere Aktualisie­rung und Sandboxing basieren auf dem Prinzip der Isolation, welches davon ausgeht, dass eine absolute Korrektheit von Anwendungscode weder möglich noch durchgängig nötig ist. Indem ein Betriebssystem innerhalb eines Typ-l-Hypervisors liegt, wird ein höherer Isolationsgrad sowohl zwischen verschiedenen Betriebssystemen als auch zwi­schen Betriebssystem und Hardware erreicht |PZH1 , S,17:13|, Die Verwendung eines Typ-2-Hypervisors innerhalb eines Host-Betriebssystems stellt hingegen eine größere Angriffsfläche dar und sollte bei sieherheitskritisehen Anforderungen umgangen werden |PZHI , S,17:24 f,|. Ein Risiko besteht jedoch darin, dass die Korrektheit einer Vir- tualisierungsteehnologie wie dem Hypervisor nicht garantiert werden kann. Eine wei­tere Form von Isolation wird dadurch erreicht, dass die Angriffsfläche verringert wird, d.h, möglichst wenige Schnittstellen zur Fahrzeugumwelt vorhanden sind. Gleichzeitig sollte auch die interne Kommunikation im Fahrzeug getrennt und die Schnittstellen zwischen Netzwerken gering gehalten werden - wie bereits in Abschnitt 3,5 angedeu­tet, Genauso sollte auch der Endnutzer nach den Prinzipien „Fail-safe Defaults“ und „Least Privilege“ von möglichst vielen Gebrauehsfehlern isoliert werden, indem ihm nur Einstellungsmögliehkeiten zur Verfügung stehen, die er tatsächlich benötigt und die bereits optimal vorkonfiguriert sind.

- Security-by-Obscurity: „Security-bv-Obscurity“ oder auch „Security-by-Randomi- zation“ basiert ebenfalls auf der Idee, dass die absolute Korrektheit nicht realisierbar ist, aber ein Angriff so komplex und rechenintensiv wird, dass er sich für den An­greifer nicht lohnt. Identisch lautet auch die Maxime der Kryptographie, bei der Ver- und Entschlüsselung so vonstatten gehen, dass ein Angriff kaum durchführbar ist. Hardware-technisch erfordert dies eine sichere Lagerung kryptographiseher Schlüssel, Darüber hinaus kann der Schwierigkeitsgrad eines Angriffs auch dadurch erhöht wer­den, dass ein Fahrzeug eine möglichst wenig standardisierte und von anderen Fahrzeu­gen abweichende Architektur verzeichnet, denn für eine Standard-Architektur lassen sich schnellere und breiter anwendbare Angriffsmöglichkeiten konzipieren. Dieser Teil der „Security-by-Obscurity“-Perspektive ist jedoch insofern kritisch zu betrachten, als dass er dem Prinzip des „Open Designs“ grundlegend widerspricht. Dieses legt fest, dass eine Architektur nicht durch die Unbekanntheit ihrer Systematik abgesichert werden dürfe, Kryptographie hingegen ist mit dem Open-Design-Prinzip kompatibel.

Alles in allem resultiert eine Vorgehensweise nach dem Seeurity-by-Ansatz in der ausschließ­lichen Verwendung von Firmware und eines Embedded-Systems,

5.6 Standardisierungs-Ansatz

Beim Standardisierungs-Ansatz wird die Fahrzeug- und Multimedia-Architektur aus der Per­spektive betrachtet, dass möglichst viel Technologie standardisiert und somit von Automo­bilherstellern bzw, App-Entwieklern einheitlich implementiert wird. Das Ziel ist eine größt­mögliche Standardisierung unter den Automobilherstellern; gegenüber der Konsumelektronik wird jedoch eine festgelegte Distanz gewahrt.

Der Einsatz von Ethernet statt des MOST-Xetzes kann eine Standardisierungs-Maßnahme werden, sofern Steuergeräte-Lieferanten und OEMs sieh darauf einigen. Das vorgestellte Kon­zept der BroadR-Reaeh-Technologie kann als Basis für einen solchen Standard fungieren. Durch die Standardisierung und den Ersatz teurer optischer Übertragungsmedien würden die Kosten für das gesamte Fahrzeug sinken. Ein ähnlicher Effekt ließe sieh durch die ein­heitliche Vereinigung von Steuergeräten verzeichnen, wodurch zusätzlich das Gewicht des Fahrzeugs sinken würde.

Ein Mechanismus für Intrusion Detection an Steuergeräten, die von außen ansprechbar sind, ist empfehlenswert und wird vom Standard profitieren. Wie im Abschnitt zuvor jedoch erwähnt, sind Standard-Technologien besser dokumentiert und damit leichter angreifbar. An dieser Stelle ist die IP-basierte Middleware aus dem SEIS-Projekt mit dem modula­ren Security-Framework integrierbar. So können die Security-Mechanismen per Plug-In an die neuesten Gefahren durch Hackerangriffe angepasst werden. Mit welcher Frequenz und welchem Aufwand der Austausch erfolgt, ist allerdings unklar.

Für Anwendungsentwickler spielt die Standardisierung von APIs eine besonders große Rol­le, Sollte die Fahrzeug-Architektur nicht standardisiert sein, müssten die APIs trotzdem so allgemein aufgebaut sein, dass diese je nach Fahrzeug nicht angepasst werden müssen, son­dern die Anpassung auf tieferer Ebene erfolgt, Android, iOS und Windows Phone stellen im Sinne der Standardisierung ein Xegativbeispiel dar, da ein Programmierer die App für jede Plattform anpassen muss. Diese Gefahr könnte mit der Einführung von Android Auto und Apple CarPlay zur Realität werden.

Dem Standardisierungsansatz kommt „AUTomotive Open System ARchitecture“ (AUTO- SAR) entgegen, eine Entwicklungspartnerschaft aus OEMs, Steuergerätezulieferern und Her­stellern von Software und Mikrocontrollern. Sie verfolgt das Ziel, einheitliche, austauschbare und wiederverwendbare Software als Standard auf verschiedenen Steuergeräten einzusetzen. In diesem Sinne können auch verschiedenste Anwendungsarten auf einem Knoten mithilfe von OpenSynergy und OVERSEE kombiniert werden. Dadurch werden mehrere AUTOSAR- standardisierte Betriebssysteme und andere Umgebungen parallel einsetzbar.

Das Niveau der Standardisierung kann sehr unterschiedlich sein: Eine übergreifende Stan­dardisierung bedeutet eine sehr ähnliche Fahrzeugarchitektur bei allen OEMs, während eine spezifische Standardisierung lediglich gewisse Leitfäden setzt, beispielsweise für die APIs in der App-Programmierung, Obwohl mithilfe gewisser Leitfäden noch ein Security-bv-Ansatz umsetzbar ist, könnte eine übergreifende Standardisierung dem Flexibilitäts-Ansatz zuge­schrieben werden.

5.7 Flexibilitäts-Ansatz

Der Flexibilitäts-Ansatz fokussiert sieh auf eine größtmögliche Verknüpfung mit anderen Systemen, Dieser Ansatz betrachtet die Anforderungen aus der Perspektive des Endkonsu­menten, der eine flexible, kompatible und verbundene Lösung wünscht. Dahinter verbirgt sieh das Prinzip der „Psychological Acceptability“, das eine möglichst unkomplizierte Verwendung fordert. Im Vergleich zu den anderen beiden Ansätzen entspricht dies einer übergreifenden Vernetzungs-Lösung, die das Fahrzeug neben anderen Geräten als einen Bestandteil des Sys­tems registriert.

Diesem Blickwinkel entspricht die Internet-of-Things-Lösung des Webinos-Projekts am Fraun­hofer-Institut für offene Kommunikationssysteme |FSL , S,233|, Dabei sollen browserbasierte und plattformübergreifende Web-Techniken zur Verknüpfung zahlreicher elektronischer Ge­räte wie Computer, Fernseher, Smartphone und auch des Fahrzeugs eingesetzt werden. In der „Personal Zone“, einem zentralen Hub, sind alle Geräte registriert. Dort werden auch die Da- tensehutzriehtlinien und die Security-Mechanismen zur Datenübertragung festgehalten sowie die Schnittstellen zwischen Geräten realisiert.

Im Rahmen der Internet-of-Things-Entwicklungen kann ebenfalls das Konzept des Security­Proxys mit Tags für Nachrichten von äußeren Geräten innerhalb des Flexibilitäts-Ansatzes eingeordnet werden.

Ähnlich dem Webinos-Projekt wünscht sieh ein Kunde in Zukunft, mit oder ohne eigenes Smartphone in verschiedenen Fahrzeugen erkannt zu werden, sodass sieh das Multimedia­system und das gesamte Fahrzeug an den Fahrer anpasst.

Ein Kunde fordert ferner Kompatibilität des Multimedia-Systems ein: Es wäre ärgerlich, wenn ein Smartphone nicht das zum Fahrzeug passende Betriebssystem besitzt oder die Version eines Betriebssystems im Fahrzeug nicht mit einer Version im Smartphone oder Tablet vereinbar ist. Gleichzeitig möchte der Autofahrer keine häufigen Wartungen auf sieh nehmen müssen, um Updates oder die Anpassung von Security-Mechanismen durchzuführen, wie dies bei der Umsetzung des SEIS-Vorhabens nötig wäre.

Dass der Kunde in seinem Bestreben nach Flexibilität ebenfalls einen möglichst geringen Spritverbrauch wünscht, geht mit einer Reduktion des Gewichts einher. Damit lohnt sieh wiederum eine Vereinigung von Steuergeräten, Im Hinblick auf den Datenschutz möchte der Kunde sämtliche Privatsphäre-Einstellungen selbst regeln und überprüfen können, oh­ne jedoch ständig bestimmte Zugriffe manuell akzeptieren zu müssen. Gemäß dem Prinzip „Fail-safe Defaults“ sollen daher bereits voreingestellte Mechanismen für Gebrauchssicherheit sorgen, damit selbst der „dümmste anzunehmende User“ keinen Schaden anrichten kann.

6. Evaluation der Konzepte und der Vorgehensweise

In diesem Kapitel werden die im vorherigen Kapitel beschriebenen Ansätze und Konzepte evaluiert: Zunächst werden sie auf die Erfüllung der allgemeinen Sicherheitsanforderungen an die Fahrzeugarchitektur aus Abschnitt 2,4 geprüft. Im Anschluss wird anhand des 2-3-6- Konzepts bewertet, welche Rolle bei einem Ansatz der OEM innerhalb der Wertschöpfungs­kette einnimmt.

Im Allgemeinen lässt sieh für den OEM ein Zielkonflikt zwischen Kompatibilität, Sicher­heitsvorkehrungen, Open Design, Plattformunabhängigkeit und Datenkontrolle feststellen. Um abschließend die Vor- und Xachteile der drei Ansätze gegeneinander abzuwiegen, erfolgt ein Vergleich anhand des Ausmaßes der Zielerreichung.

6.1 Evaluation nach Sicherheitsanforderungen

Eine Übersieht über die grobe Tendenz, wie die Sicherheitsanforderungen bei den jeweili­gen Ansätzen zu evaluieren sind, ist in Tabelle 6,1 zusammengefasst. Diese Einschätzungen werden im Folgenden detailliert begründet.

Anhand der Tabelle ist bereits ersichtlich, dass für alle drei Ansätze die Anforderungen nach Datenschutz und Datensicherheit sowie keine Ablenkung des Fahrers besonders schwer umsetzbar sind.

Security-by-Ansatz

Innerhalb des Security-bv-Ansatzes kann im Vergleich zu den anderen Ansätzen die höchste physische Sicherheit erreicht werden, da die Angriffsfläche von außen möglichst gering ge­halten, das Durchdringen der Fahrzeugarchitektur für einen Hacker möglichst komplex und undurchsichtig gestaltet sowie sämtliche Anwendungen vom OEM erstellt werden, Xichts- destotrotz kann aufgrund der heute bereits standardisierten Schnittstellen zur Außenwelt,

Tabelle 6,1: Gewährleistung der Sieherheitsanforderungen bei versehiedenen Ansätzen

Abbildung in dieser Leseprobe nicht enthalten

wie das Abspielen einer CD, kein absoluter Schutz vor Angriffen auf die physische Sicherheit gewährleistet werden,

Da eine Verfolgung des Seeurity-by-Ansatzes direkt mit einem Embedded-System nach Ab­schnitt 2,5,2 einhergeht, ist die HMI-Hoheit für den OEM sichergestellt.

Durch die OEM-eigenen Apps ist die Ablenkung eines Fahrers, der an den App-Stil sei­nes Herstellers gewöhnt ist, als gering einzusehätzen. Dies liegt daran, dass der Fahrer mit der Zeit mit den Signalen, Anweisungen, Funktionalitäten und der Navigation des eigenen Multimediasystems vertraut wird. Allerdings fällt die Umstellung auf ein anderes System beim eventuellen Kauf eines Fahrzeugs anderer Hersteller umso schwerer, sodass es zu einer Fehlbedienung kommen kann.

Im Hinblick auf Datenschutz und Datensieherheit repräsentiert - wie in Abschnitt 4,1,1 analysiert - der OEM den einzigen Akteur, der Zugriff und Einfluss auf die Daten besitzt. Dies schützt die Privatsphäre des Kunden vor den anderen Akteuren, kann im Falle von Nachlässigkeit beim OEM jedoch auch zu Datensehutzskandalen führen, da er als einziger Verantwortung für Datenschutz und -Sicherheit trägt. Eine Ausnahme bildet die Verwendung externer APIs, beispielweise von Soeial-Media-Kanälen: Je nach Datensehutzeinstellungen können so auch diese Unternehmen Daten sammeln.

Standar disierungs-Ansatz

Beim Standardisierungs-Ansatz kann anders als beim Seeurity-by-Ansatz keine „Obscuri­ty“ durch unterschiedliche technologische Bedingungen erreicht werden. Im Gegenteil sollen Technologien, die bei versehiedenen OEMs zum Einsatz kommen, zueinander kompatibel sein. Als Konsequenz entstehen standardisierte Angriffsflächen am Fahrzeug, die umso ge­fährlicher für die physische Sicherheit werden, je größer das Wissen um die Standards wird. Umgekehrt führt dieses Know-How auch zur Entwicklung von Angriffsszenarien und Ver­teidigungsmechanismen. Durch eine vom Standard abweichende Implementierung, könnten auch eigene Fehler eingebaut und Updates auf Basis eines Standards verkompliziert werden, sodass man sieh eine Abweichung vom Standard „mehrmals überlegen sollte“ |SirU , S,13|.

Insgesamt wird durch die Öffnung der Fahrzeugarchitektur nach außen ein unvermeidlicher Wettbewerb zwischen Hacker-Angriffen und Angriffsschutz-Aufrüstungen in Bewegung ge­setzt, Beide Seiten sind stets bemüht, die Fehler der anderen Seite auszunutzen.

Im Hinblick auf die nicht-physischen Sicherheitsanforderungen, ist die Einhaltung davon abhängig, welche Bereiche standardisiert werden: Sofern eine standardisierte Oberfläche vor­gesehen ist, gibt der OEM die HMI-Hoheit ab. Sofern die Bedienung des Multimediasystems standardisiert und benutzerfreundlich ist, kann sich der Fahrer auch in verschiedenen Fahr­zeugen sicher zurechtfinden und wird nicht unerwartet abgelenkt. Je nachdem, ob Daten standardisiert verwaltet werden, ergibt sich auch eine entsprechende Gefahr für Datenschutz und -Sicherheit,

Flexibilitäts-Ansatz

Im Rahmen des Flexibilitäts-Ansatzes besteht aufgrund der übergreifenden Vernetzung die größte Gefahr für die physische Sicherheit.

Gleichzeitig liegt die HMI-Hoheit wohlmöglich nicht im Einflussgebiet des OEM, sondern in dem des umfassenden Systems.

Da mit Brought-In-Geräten und nachinstallierbaren Apps auch Anwendungen von Drittan- bietern verwendbar sind, könnte der Fahrer im Vergleich zu den anderen Ansätzen unter höherer Ablenkung leiden. Dies hängt von den individuellen Einstellungen und Anwendun­gen ab, die der Kunde selbst einrichtet.

Mit einer solchen flexiblen Lösung könnte auch der Kunde selbst die Verantwortung für den Datenschutz übernehmen, wie dies beispielsweise bei Android-Geräten der Fall ist. Dies wiederum stellt eine Abweichung vom „Fail-Safe-Defaults“-Prinzip dar.

6.2 Evaluation anhand des 2-3-6-Konzeptes

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 6,1: Einfluss des OEM bei verschiedenen Ansätzen anhand des 2-3-6-Konzepts (Einflussfelder sind in blau unterlegt)

Welche Felder nach dem 2-3-6-Konzept der OEM bei den drei verschiedenen Ansätzen ein­nimmt, wird in Abbildung 6,1 gezeigt. Eine ausführliche Beschreibung erfolgt in den folgen­den Abschnitten,

Dabei ist zu erwähnen, dass alle Felder eine unterschiedliche strategische Relevanz vorweisen. Es kann jedoch nicht eindeutig festgelegt werden, welche Felder unbedingt vom OEM belegt werden sollten. Die Felder „Markt gestalten“ und „Interface, Systeme“ interagieren direkt mit dem Kunden, Es kann daher vermutet werden, dass an dieser Stelle das höchste Um­satzpotential besteht. Allerdings könnte der OEM auch im Feld „Backendsysteme“ aus den Kundendaten Umsatz erzielen, wobei dies bisher nicht zu seinen Kernkompetenzen zählt. Die anderen drei Felder gehen für den OEM vermutlich eher mit Kosten einher. Eine pau­schale Beschreibung der Verdienstmöglichkeiten in den einzelnen Feldern ist allerdings nicht möglich, sondern vom konkreten Geschäftsmodell abhängig. In Form einer Make-or-Buy- Entscheidung muss der OEM für jedes einzelne Feld festlegen, ob er sieh diesen Arbeitspa­keten selbst annimmt oder sie an andere Akteure auslagert.

Security-by-Ansatz

Beim Security-by-Ansatz, der die Umsetzung eines Embedded-Systems darstellt, besitzt - wie in Abbildung 6,1 hervorgehoben - der OEM die Kontrolle über alle drei inhaltlichen Felder des 2-3-6-Konzeptes und zwei von drei Feldern des infrastrukturellen Zugangs zum Kunden, Lediglich den Transport der Daten kann der OEM nicht selbst verantworten, da er dann eigene Telefon- und Datennetze anbieten müsste. Durch eine geschlossene Architektur ist der OEM auf sein eigenes Know-How und seine Dienste beschränkt: Er hat zwar inhalt­lich und infrastrukturell den direkten Kontakt zum Kunden, kann ihm jedoch - ohne hohe Investitionen - nicht die Vorteile eines App-Stores mit Drittanbieter-Diensten bieten.

Standar disierungs-Ansatz

Der Standardisierungs-Ansatz ist weiterhin abhängig davon, welche Bereiche der Fahrzeug- und Multimedia-Architektur standardisiert werden.

Angenommen, die Programmierschnittstellen sind standardisiert, erlauben Anwendungen von Drittentwicklern und das Sammeln von Daten durch verschiedene Akteure, In diesem Fall sind - wie in Abbildung 6,1 dargestellt - die Inhaltsgestaltung und die Datenverwal­tung über Server nicht im alleinigen Einflussbereich des OEM, sondern werden von App- Entwicklern, Mobilfunkanbietern und Betriebssystem-Bereitstellern wie MirrorLink mitbe­stimmt, Sofern der OEM zusätzlich Kontrolle über die Plattform des Multimediasystems besitzt und beispielsweise jede App von Drittanbietern unter strengen Kontrollbedingungen zertifizieren muss, kann er die Felder „Inhalt verpacken“, „Markt gestalten“ und „Interface, Systeme“ überwachen.

Sofern jedoch auch die Plattform standardisiert wird, kann wie beim Flexibilitäts-Ansatz kein Feld mehr vom OEM allein verantwortet werden.

Insgesamt kann der Einflussbereich des OEM je nach Standardisierungsgrad und -maßnahmen zwischen der Ausprägung beim Security-by-Ansatz und der Ausprägung beim Flexibilitäts­Ansatz liegen.

Flexibilitäts-Ansatz

Im Hinblick auf den Flexibilitäts-Ansatz führt eine übergreifende Vernetzung und die da­durch bedingte Öffnung der Fahrzeugarchitektur dazu, dass der OEM in keinem Feld des 2-3-6-Konzeptes mehr den alleinigen Akteur repräsentiert.

Insbesondere besitzt dieser dann einen eingeschränkten Zugang zum Kunden über die Fel­der „Markt gestalten“ und „Interface, Systeme“, wodurch die HMI-Hoheit abgegeben und der Kunde daran gewöhnt wird, nicht mit dem OEM bezüglich des Multimedia-Systems zu interagieren.

Damit kann der OEM seine mehrjährigen Produktlebenszyklen beibehalten und die Verant­wortung, das Multimedia-System an die raschen Entwicklungen in der Konsumelektronik und Telekommunikation anzupassen, teilweise an die anderen Akteure übertragen.

6.3 Evaluation anhand der Zielkonflikte

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 6,2: Zielkonflikte bei verschiedenen Ansätzen (innen 0%, außen 100% erfüllt)

Aus der Evaluation nach Sicherheitsanforderungen und anhand des 2-3-6-Konzeptes geht folgende Beziehung hervor: Je mehr Schnittstellen nach außen bestehen, umso geringer sind die Sicherheit der Architektur und der Einfluss des OEM, Dieses Ergebnis würde eine Um­setzung des Security-bv-Ansatzes nahe legen. Allerdings verfolgt ein OEM mehr als nur diese zwei Ziele für ein Fahrzeug-Multimedia-System, Insgesamt fünf dieser übergreifenden Ziele werden im Folgenden näher betrachtet und dienen dazu, die Stärken und Schwächen der drei Ansätze zu verdeutlichen.

Diese fünf ausgesuchten Ziele werfen folgende Fragestellungen auf:

1, Kompatibilität: Ist das bestehende Multimedia-System mit anderen Geräten des Kunden kompatibel?

2, Sicherheitsvorkehrungen: Sind die bestmöglichen Sicherheitsvorkehrungen getrof­fen worden? Dieser Punkt fasst die Ergebnisse aus Tabelle 6,1 zusammen.

3, Open Design: Ist das Know-How über das System öffentlich zugänglich und damit von OEMs ähnlich umsetzbar?

4, Plattformunabhängigkeit: Ist die App-Entwieklung unabhängig von der Auto-Marke und dem System-Anbieter?

5, Datenkontrolle: Sind Daten über den Fahrer, das Fahrzeug und die Fahrt höchstens dem OEM zugänglich?

In Abbildung 6,2 ist in Form von Radar-Diagrammen dargestellt, inwieweit die drei Kon­zeptionsansätze die jeweiligen Ziele erreichen. Dabei bedeutet eine vom Mittelpunkt am weitesten entfernte Ausprägung, dass die oben formulierte Frage des entsprechenden Ziels vollständig bejaht werden kann. Ist ein Ziel nicht vollständig umgesetzt, erfolgen Abzüge bei der Beurteilung, Zum schnelleren Vergleich wurden die Ergebnisse der drei Ansätze im rechten Teil der Abbildung iibereinandergelegt. Im Folgenden wird jede einzelne Bewertung detailliert begründet,

Security-by-Ansatz

Bei einer Implementierung nach dem Seeurity-by-Ansatz ist keine Kompatibilität nötig, da grundsätzlich nur eigene Firmware verwendet wird, keine Smartphones ansehließbar sind und alle Apps selbst programmiert werden. Fraglich ist hierbei, ob sieh die Investition in die Entwicklung eines eigenen Systems und eigener Apps lohnt, obwohl sie nicht zu den Kernkompetenzen des OEM zählt. Bereits erfahrene System- und App-Entwiekler können schneller mehr Anwendungen fertigstellen. Umgekehrt lässt sieh aber auch argumentieren, dass für das Fahrzeug nicht so viele Dienste nötig sind wie für das Smartphone, Da zudem sämtliche Funktionalitäten sowieso an das Fahrzeug angepasst und auf eine möglichst sichere Bedienung überprüft werden müssen, kann das gesamte Arbeitspaket auch direkt vom OEM bearbeitet werden.

Wie zuvor erläutert, geht der Seeurity-by-Ansatz mit der höchsten Sicherheit einher. Aller­dings darf nicht unbeachtet bleiben, dass bereits standardisierte Schnittstellen nach außen bestehen und vollständige Sicherheit aufgrund menschlichen Versagens nie zu gewährleisten ist.

Da die Architektur gemäß Seeurity-by-Obseurity geheim gehalten wird, ist das Ziel einer Open-Design-Technologie verfehlt. Dieses Ziel bedeutet nicht, dass Betriebsgeheimnisse der Fahrzeughersteller offenzulegen sind, sondern lediglich, dass sieh verschiedene OEMs auf bestimmte Konzepte einigen und sie ähnlich Umsetzern Dass beim Seeurity-by-Ansatz jedoch Sicherheit durch das Geheimhalten der Technologie erreicht werden soll, widerspricht dem allgemeinen Open-Design-Prinzip nach Saltzer und Sehroeder,

Dies bedingt auch, dass das eigene System nicht in anderen Fahrzeugen umsetzbar und somit plattformabhängig ist.

Im Hinblick auf das Ziel der Datenkontrolle ist festzustellen, dass theoretisch höchstens der OEM auf Daten zu Fahrzeug, Fahrt und Fahrer zugreifen kann. Sofern der OEM damit wer­ben möchte, dass in seinen Fahrzeugen die Privatsphäre des Kunden unangetastet bleibt, kann er auf den Zugriff vollständig verzichten. Dies würde damit einhergehen, dass der Fahr­zeughersteller bisher auch nur geringe Kenntnisse im Big-Data-Bereieh besitzt und manche

Daten nicht sinnvoll verwenden kann. Darüber hinaus geht durch diese Beschränkung viel Potential für nene Applikationen verloren.

Standar disierungs-Ansatz

Xaeh dem Standardisierungs-Ansatz werden Standards nur unter OEMs vereinbart, jedoch wird eine gewisse Distanz zur Konsnmelektronik gewahrt. Dabei einigen sieh die Fahrzeugher­steller untereinander auf eine ähnliche Architektur, betrachten die Konsumelektronik jedoch lediglich als Mittel zum Zweck der Vernetzung, Ein aus gewissem Misstrauen resultierendes Fahrzeug-Multimedia-System könnte daher mit den mobilen Endgeräten des Fahrers inkom­patibel sein. Dieses Problem kann dadurch verstärkt werden, dass ein Fahrzeug mit über zehn Jahren Gebrauehsdauer nach kurzer Zeit kaum mit den neuesten Smartphone-Systemen mehr kompatibel sein könnte. Sofern jedoch unter allen Fahrzeugherstellern standardisierte APIs und Apps vorliegen, wird der OEM nicht davon abhängig, dass die Smartphone-Hersteller alle künftigen Modelle an das erste Fahrzeug-Multimedia-System anpassen.

Obwohl die Kompatibilität mit Konsumelektronik-Geräten beim Standardisierungs-Ansatz durch die tatsächlichen Standards bedingt ist, können die OEMs aufgrund einheitlicher Stan­dards in jedem Fall von gleichen Zulieferern profitieren. Dies ermöglicht, das neue System als ein reguläres Bauteil mit in den Produktionsplan aufzunehmen und dadurch die traditionelle Wertsehöpfungskette beizubehalten, Xiehtsdestotrotz ist gerade durch die Bekanntheit der Schnittstellen weniger Sicherheit zu erwarten als beim Seeurity-by-Ansatz.

Mithilfe offener Standards wird das Open-Design-Prinzip befolgt. Dadurch wird wiederum Plattformunabhängigkeit erreicht, da die Systeme auch bei anderen Fahrzeugen einsetzbar sind und Apps nur für eine Plattform programmiert werden müssen.

Beim Standardisierungs-Ansatz könnten die Daten zentral gesammelt, aber auch von Dritt- anbietern, Social Media oder Telekommunikations-Anbietern verwendet werden. Dies schränkt die Privatsphäre innerhalb des Fahrzeugs im Vergleich zum unvernetzten Automobil ein.

Flexibilitäts-Ansatz

Der Flexibilitäts-Ansatz strebt die größtmögliche Kompatibilität für den Endkunden an, indem alle Geräte verknüpft werden. Dies funktioniert jedoch nur, wenn sieh alle Fahrzeug- und Konsumelektronik-Hersteller einer Lösung ansehließen. Sofern ein Akteur nicht daran teilnimmt oder konkurrierende übergreifende Systeme - beispielsweise eines von Apple und eines von Google - bestehen, kann vollständige Kompatibilität nicht garantiert werden.

In Bezug auf die Sicherheit stellt die zentrale Vernetzung einen „Single Point of Failure“ dar, sodass die Manipulation eines zentralen Hubs sämtliche Geräte des Kunden beeinträchtigen kann.

Das Open-Design-Prinzip hingegen kann eingehalten werden, da eine Systematik, die sieh vieler Versehliisselungsmethoden bedient, nicht geheim gehalten werden muss. Sollten jedoch konkurrierende übergreifende Systeme bestehen, sind mehr Geheimnisse über die Funktio­nalitäten zu erwarten.

Die Plattformunabhängigkeit ist aufgrund ähnlicher Bedenken fraglich: Im Falle mehrerer Lösungen müssten möglicherweise auch die gleichen Apps für mehrere Plattformen entwor­fen werden, wie dies bereits für iOS, Android und Windows Phone erforderlich ist. Zudem müssten auch alle Fahrzeughersteller dieses übergreifende System akzeptieren. Im idealen Fall, dass nur eine Lösung existiert und sämtliche Akteure zustimmen, werden die Ziele nach Kompatibilität, Open Design und Plattformunabhängigkeit vollständig erreicht.

Das Ziel nach Wahrung des Datenschutzes ist jedoch umso mehr anzuzweifeln, je mehr Akteure beteiligt sind.

Insgesamt kann konstatiert werden, dass jeder Ansatz bestimmte Ziele anstrebt und dadurch auch andere Ziele erreicht, aber manche dafür vernachlässigt.

6.4 Evaluation der Vorgehens weise

Da diese wissenschaftliche Arbeit aus der Kooperation des Instituts für Informationswirt- sehaft und Marketing (IISM) am Karlsruher Institut für Technologie (KIT) mit der Unterneh­mensberatung Miesehke Hofmann und Partner (МНР) heraus entstanden ist, waren sowohl wissenschaftliche Anforderungen als auch unternehmerische Interessen zu wahren. Obwohl diese Arbeit explizit das Konzept einer sicheren Fahrzeugarehitektur erarbeiten soll, ohne auf bestehende Lösungen in der Industrie zu achten, wird die wirtschaftliche Betrachtungsweise keinesfalls vernachlässigt. So nimmt die Evaluation der eigenen drei Konzeptions-Ansätze anhand des 2-3-6-Konzeptes einen wohl verdienten Platz ein, denn neben Sieherheitsanfor- derungen ist die Wirtschaftlichkeit einer Technologie ausschlaggebend. Die fünf Ziele zur Abwägung der Konzeptionsansätze sind zwar nicht ganz disjunkt und erschöpfend, verdeut­lichen aber die sieh anbahnenden Kompromisse.

Die genaue Eingrenzung der Arbeit wurde im Laufe der Bearbeitung präzisiert. Die trotzdem seit Beginn unveränderten Forsehungsfragen konnten ausreichend beantwortet werden. Um die Arbeit für den Leser möglichst übersichtlich zu gestalten, wurde auf eine klare Struktur und die durchgängige Verwendung von Elementen aus den Grundlagenkapiteln geachtet. Zu den Letzteren zählen die fünf Dienstarten, vier Sieherheitsanforderungen, drei Systemtypen, vier technischen Ebenen und ab Kapitel 5 auch acht Konzeptionsprinzipien.

Im Rahmen weiterer geplanter Veröffentlichungen bei МНР zum Thema „Car Connectivi­ty“ können und sollten von anderen Studierenden die ausführlichen technischen und ökono­mischen Grundlagen in dieser Arbeit zur eigenen Vorbereitung verwendet werden. Da diese Arbeit öffentlich zugänglich ist, wurde eine OEM-neutrale Sichtweise auf Basis des aktuellen Forschungsstandes angestrebt.

In Kapitel 7 wird auf Nachfrage eine eigene Einschätzung der zukünftigen Entwicklungen beschrieben und eine Handlungsempfehlung für OEMs ausformuliert. Diese Beschreibung basiert auf der fundierten Auseinandersetzung innerhalb dieser Arbeit, repräsentiert jedoch eine subjektive Meinung,

7. Zusammenfassung und Ausblick auf weitere Forschung

Ziel dieser wissenschaftlichen Arbeit war die Entwicklung von Ansätzen zur Konzeption einer sicheren Fahrzeugarchitektur bei fortschreitender Vernetzung des Fahrzeugs mit Konsum­elektronik, Schwerpunkte waren dabei die Abwehr von Angriffen auf die physische Sicherheit sowie die wirtschaftlichen Auswirkungen der Ansätze.

Zur Erreichung dieses Zieles galt es, zu Beginn der Arbeit die Forschungsfragen aufzustellen, welche in den darauffolgenden Untersuchungen nach und nach implizit beantwortet wurden:

In Kapitel 2 wurde hierbei die Basis zur Beantwortung der ersten Forschungsfrage nach den Sicherheitsanforderungen der vernetzten Fahrzeugarchitektur gelegt: So wurde aufge­zeigt, dass aufgrund unterschiedlich langer Produktlebenszyklen eine Diskrepanz zwischen Fahrzeug- und Konsumelektronikindustrie besteht. Anschließend wurde die Verschmelzung beider Industrien in Form eines Fahrzeug-Multimedia-Systems untersucht. In diesem Rah­men wurde erläutert, wie die Wertschöpfungskette anhand des 2-3-6-Konzeptes aussieht, welche Dienstarten im Fahrzeug bestehen, welche übergreifenden Sicherheitsanforderungen für das Multimedia-System vorliegen und welche Systemarten zu unterscheiden sind. Parallel dazu erfolgte eine thematische Einordnung der Arbeit innerhalb verschiedener Aspekte.

Da für die zweite Forschungsfrage technisches Wissen vonnöten ist, wurden in Kapitel 3 die technischen Grundlagen der Fahrzeug- und Smartphone-Industrie betrachtet. Es wur­den dabei vier Ebenen unterschieden: Bei der physischen Ebene (1) wurden Grundlagen von Steuergeräten erläutert, wohingegen bei der physischen Datenübertragungsebene (2) der Fokus auf seriellen Bussystemen lag. Innerhalb der Software-Datenübertragungsebene (3) wiederum wurde Kryptographie behandelt, während auf der Software-Ebene (4) eine nähere Beschreibung von Virtualisierung und APIs erfolgte.

Bevor fundierte Konzeptionsansätze erstellt werden konnten, galt es darüber hinaus, die tech­nischen Gefahrenpotentiale auf diesen vier Ebenen zu beleuchten. Zusätzlich wurden Gefah­renpotentiale verschiedener Dienstarten und heute verwendeter Smartphone-Betriebssysteme analysiert.

Aufbauend auf den technischen Grundlagen und der Analyse der Gefahrenpotentiale wurde die zweite Forschungsfrage nach möglichen Anpassungen der Fahrzeugarchitektur angegangen: Dazu wurden in Kapitel 5 - erneut auf die vier Ebenen verteilt - bestehende Konzepte aus Forschung und Industrie beschrieben. Diese wurden im nächsten Schritt über alle Ebe­nen hinweg in drei verschiedenen Konzeptionsansätzen kombiniert. Gleichzeitig wurde auf die acht Design-Prinzipien zur Informationssicherung in der IT-Welt nach Saltzer und Schroeder verwiesen.

Um auch die dritte Forschungsfrage nach den Konsequenzen für die bestehende Wertschöp­fungskette zu beantworten, erfolgte eine Evaluation dieser drei Ansätze in Kapitel 6, Dabei wurden zunächst die übergreifenden Sicherheitsanforderungen aus dem Grundlagenkapitel als Evaluationsbasis herangezogen und danach die wirtschaftlichen Auswirkungen eines je­den Ansatzes mithilfe des 2-3-6-Konzeptes näher beschrieben. Um die Vor- und Nachteile gegeneinander abzuwiegen, wurden die Zielkonflikte jedes Ansatzes untersucht. Zudem wurde die eigene Vorgehensweise bei der Erstellung der Arbeit reflektiert.

Abschließend werden in diesem Kapitel die zuvor impliziten Antworten auf die Forschungs­fragen noch einmal explizit zusammengefasst, ein Ausblick auf weitere Forschung gegeben und eine eigene Einschätzung der zukünftigen Entwicklungen ausformuliert.

7.1 Beantwortung der Forschungsfragen

Forschungsfrage 1: Welche Sicherheitsanforderungen müssen Vernetzungs-Systeme im Fahrzeug erfüllen?

Für jedes technische Gerät wie ein Smartphone, ein Fahrzeug oder auch ein Multimedia­System gelten die Anforderungen nach Betriebssicherheit, Gebrauchssicherheit und Angriffs­schutz. Da in dieser Arbeit der Fokus auf Security und nicht auf Safety liegt, wurde in erster Linie der Angriffsschutz betrachtet.

Für das gesamte Fahrzeug wurden in Kapitel 2 vier Sicherheitsanforderungen identifiziert: (1) Physische Sicherheit von Mensch, Fahrzeug und Umgebung; (2) keine Ablenkung des Fahrers; (3) HMI-Hoheit des OEM und (4) Datenschutz und Datensicherheit. Während die ersten beiden das Leben der Insassen schützen sollen, indizieren die letzten beiden Anforde­rungen einen wirtschaftlichen Wettbewerb verschiedener Akteure um die Hoheit im Fahrzeug, Bei der Betrachtung der technischen Komponenten im Rahmen des Angriffsschutzes wurde besonders viel Wert auf die physische Sicherheit gelegt, da von außen gesteuerte Angriffe auf die physische Sicherheit - im Vergleich zu den anderen Sicherheitsanforderungen - die kurzfristig verheerendsten Folgen mit sieh bringen.

Um die physische Sicherheit gewährleisten zu können, müssen auf den vier technischen Ebe­nen eigene Anforderungen erfüllt werden, wobei die Echtzeitfähigkeit auf allen Ebenen re­levant ist. Wie in Kapitel 5 erläutert, sind für die physische Ebene außerdem Robustheit und die korrekte Ausführung der Mikrocontroller eine Grundvoraussetzung, Auf der physi­schen Datenübertragungsebene dürfen Bitübertragungsfehler, sequentielle Ausfälle und Mel­dungsstaus nicht toleriert werden. Auf der Software-Datenübertragungsebene hingegen gel­ten kryptographische Anforderungen wie Vertraulichkeit, Integritätsprüfung und Authenti- fizierung. Auf der Software-Ebene müssen schließlich Malware-Schutz, Überprüfungen und Tests sowie sichere Zugriffe auf die Architektur und Schnittstellen realisiert werden.

Forschungsfrage 2: Wie kann die Fahrzeugarchitektur angepasst wer­den, um den Sicherheitsanforderungen zu genügen?

Um den in Frage 1 beschriebenen Sicherheitsanforderungen Rechnung zu tragen, wurden in dieser Arbeit auf den vier technischen Ebenen in Kapitel 5 verschiedene Konzepte vorgestellt: Auf der physischen Ebene seien Intrusion Detection, Attack Detection, das Zusammenfas­sen von Steuergeräten sowie Firewalls an Gateways und Steuergeräten genannt genauso wie Hardware Security Modules beispielsweise zur Unterstützung kryptographischer Verfahren, Für die physische Datenübertragungsebene existieren Konzepte zur Verwendung von Ether­net für Multimedia-Informationen beispielsweise über BroadR-Reach oder mithilfe von Kol­lisionsdomänen, Auf der Software-Datenübertragungsebene hingegen wurden Konzepte für symmetrische, asymmetrische und hybride krvptographische Verfahren vorgestellt. Eben­so wurden Ausprägungen einer IP-basierten Kommunikations-Middleware mit einem über Plug-Ins geregelten Security-Framework oder auch einem Security-Proxy erläutert. Inner­halb der Software-Ebene wiederum wurden Formen von Partitionierung, Vollvirtualisierung mit Hardware-Assistenz und Hosted-Virtualisierung betrachtet, um beispielsweise mehre­re Umgebungen nebeneinander laufen zu lassen und mit einer Secure-Hardware-Extension Boot-Prozesse zu überwachen.

Darauf aufbauend wurden die folgenden drei Ansätze für die Konzeption einer sicheren Fahr­zeugarchitektur erstellt,

Der Security-by-Ansatz sieht die Sicherung der Fahrzeugarchitektur durch Security-by-Cor- reetness, Security-by-Isolation und Security-by-Obscurity vor und legt damit den größten Wert auf vollständige Absicherung, Security-by-Correctness bedeutet, dass sämtlicher Co­de und alle Funktionen so korrekt gestaltet werden, dass keine Sicherheitslücken auftreten, und eine formale Verifikation im Entwicklungsprozess eingebunden ist. Dies ist allerdings aufgrund menschlichen Versagens kaum realisierbar, Security-by-Isolation erwartet, dass be­stimmte Teile einer Architektur auch schädliches Verhalten aufweisen können und setzt damit auf die Isolation von Teilarchitekturen. Sollte ein Bereich befallen werden, entstehen keine negativen Auswirkungen auf andere Bereiche, Security-by-Obscurity stellt die Sicherheit ei­nes Systems durch Kryptographie und die Unbekanntheit der Architektur her. Insgesamt entsteht nach dem Security-by-Ansatz ein nach außen und innen isoliertes System, das die Tendenz zu einem reinen Embedded-System ohne Verwendung eines Smartphones besitzt.

Im Gegensatz zum Security-by-Ansatz dient der Flexibilitäts-Ansatz nicht dem Aufbau einer sicheren Festung, sondern folgt den Wünschen eines Endkonsumenten nach einer übergrei­fenden vernetzten Lösung, die das Fahrzeug als einen Bestandteil mit einbezieht. Solche Cloud- oder Internet-of-Things-Lösungen bieten dem Kunden größtmögliche Flexibilität, so­fern auch eine gewisse Kompatibilität gewährleistet werden kann. Allerdings stellt diese weite Öffnung der Fahrzeugarchitektur nach außen erhebliche Sicherheitsrisiken bereit.

Während der Security-by- und der Flexibilitäts-Ansatz zwei Extreme auf einer Skala darstel­len, welche die Öffnung der Fahrzeugarchitektur ausdrückt, nimmt der Standardisierungs­Ansatz eine moderate Position oder eine Position innerhalb des gesamten Spektrums ein. Je nachdem, welche Standards in der Fahrzeugindustrie durchgesetzt werden, ergibt sieh ei­ne entsprechende Öffnung oder auch Isolation gegenüber der Konsumelektronik- und Tele­kommunikations-Industrie.

Insgesamt sollten bei der Konzeption einer sicheren Fahrzeugarchitektur auch die acht Design­Prinzipien nach Saltzer und Sehroeder berücksichtigt werden, die in Kapitel 5 eingangs dar­gelegt werden.

Forschungsfrage 3: Wie wirkt sich ein Veränderungsansatz auf die Wertschöpfungskette aus?

Die drei Ansätze nehmen ähnliche Positionen auf einer Skala ein, welche den relativen Ein­fluss des OEM in der Wertschöpfungskette einer Fahrzeug-App beschreibt: Nach einer idea­lisierten Umsetzung des Security-bv-Ansatzes lässt der OEM anderen Akteuren nur einen geringen Spielraum, Beim Flexibilitäts-Ansatz hingegen ist der Einfluss des OEM als ver­schwindend gering einzustufen, Mithilfe des Standardisierungs-Ansatzes kann erneut eine Position zwischen dem Security-bv-Ansatz und dem Flexibilitäts-Ansatz eingenommen wer­den, wie in Kapitel 6 beschrieben wird. Je nachdem, welcher Ansatz verfolgt und welches Geschäftsmodell für die App-Entwicklung verwendet wird, muss der OEM für jedes Feld des 2-3-6-Konzepts eine Make-or-Buv-Entscheidung treffen.

Die Betrachtung der Wertschöpfungskette anhand einer Fahrzeug-App lässt Rückschlüsse auf die gesamte Fahrzeug-Wertschöpfungskette zu: Während nach dem Security-by-Ansatz die neuen Akteure nicht in die bestehende Wertschöpfungskette der Automobilindustrie auf­genommen werden, wird mit dem Flexibilitäts-Ansatz umgekehrt das Fahrzeug innerhalb übergreifender Wertschöpfungsketten eingebettet. Mit dem Standardisierungs-Ansatz hin­gegen kann industrieweit geregelt werden, ob ein fremder Akteur beispielsweise als neuer Zulieferer fungiert und somit einfach in die traditionelle Wertschöpfungskette aufgenommen wird.

Die Evaluation in Abschnitt 6,3 hat ergeben, dass bei jedem der drei Ansätze gewisse Ziele verfolgt und erreicht, jedoch dabei andere Ziele vernachlässigt werden: Beim Security-by- Ansatz wird das Ziel „Sicherheitsvorkehrungen“ anvisiert und dadurch auch Datenkontrolle realisiert. Allerdings leiden darunter die Kompatibilität mit Konsumelektronikgeräten, Open Design der Architektur und Plattformunabhängigkeit der App-Entwicklung. Im Gegensatz dazu strebt der Flexibilitäts-Ansatz Kompatibilität an und berücksichtigt dadurch auch die Ziele Open Design und Plattformunabhängigkeit, Die Ziele Sicherheitsvorkehrungen und Datenkontrolle sind jedoch am meisten gefährdet. Ein ähnlicher Zielkonflikt ist auch beim Standardisierungs-Ansatz zu beobachten: Während die Sicherheitsvorkehrungen und Daten­kontrolle in den Hintergrund treten, werden Open Design und Plattformunabhängigkeit voll umgesetzt. Das Erreichen der Kompatibilität ist jedoch von den genauen Standards abhän­gig-

7.2 Ausblick auf weitere Forschung

Diese Arbeit konzentriert sieh innerhalb der Dienstarten auf Navigation, Infotainment und Integrierte Dienste, innerhalb der Sicherheitsanforderungen auf Angriffsschutz und physische Sicherheit sowie auf die Perspektive des OEM, In allen diesen Bereichen lassen sieh jedoch andere Forschungsschwerpunkte setzen:

So spielt Forschung in der bereits seit Langem untersuchten Dienstart Car2X im Hinblick auf Autonomes Fahren genauso wie im neuen Bereich Big Data für die Zukunft in der Automobilindustrie eine wesentliche Rolle.

Neben Angriffsschutz bietet Gebrauchssicherheit im Kontext möglichst geringer Fahrerablen­kung auch ein interessantes Thema für Forschung und Entwicklung, Die Sicherheitsanforde­rung nach der HMI-Hoheit durch den OEM und ihre wirtschaftlichen Implikationen eignen sieh ebenfalls für wissenschaftliche Untersuchungen, Im Kontext der NSA-Affäre und aktu­ellen Datenschutzskandalen nimmt der Bereich Datenschutz und Datensicherheit im Fahr­zeug an Bedeutung zu. Unter diesem Aspekt könnten beispielsweise auch die Strategien von Android Auto und Apple CarPlay untersucht werden. Im Hinblick auf die Sicherheitsmaß­nahmen können insgesamt auch verschiedene Angriffsszenarien auf das vernetzte Fahrzeug entwickelt und analysiert werden.

Nicht nur die Perspektive neuer Akteure aus der Konsumelektronik-Industrie muss durch die Automobilindustrie betrachtet werden, sondern auch die Interessen der Telekommuni­kationsindustrie, der Versicherungen oder der Politik sind zu berücksichtigen. Die Verträge zur Nutzung von Telekommunikationsnetzen aber auch politische Bestimmungen wie Ab­lenkungsrichtlinien oder die Einführung von Hilfswarnsystemen wie eCall | !SEW13| sind relevante Themen für die Zukunft, Auch die Betrachtungsweisen von App-Entwicklern mit­samt ihrer Motivation und Rolle sind zu untersuchen.

Fahrzeug-Apps im Allgemeinen stellen einen neuen Markt dar und entsprechende Geschäfts­modelle sind betrachtenswert. Welche Rollen weiterhin Zulieferer, Händler und sogar auch Kunden innerhalb der Wertschöpfungskette einnehmen werden, zählt als weiteres Unter­suchungsfeld. Konzepte wie Car-Sharing oder andere Megatrends sind dabei einzukalkulie­ren, Im Hinblick auf E-Mobilität sind auch ganz eigene Sicherheitsanforderungen zu berück­sichtigen, da Gefahren durch Batteriebrand, Auflade-Plug-Ins oder Drive-by-Wire bestehen SLS+13

In dieser Arbeit wurden vier technische Ebenen der Fahrzeugarchitektur betrachtet. Für jede einzelne Ebene oder Teilbereiche davon ist weitere Forschung unabkömmlich - insbesondere für Kryptographie, Ethernet, Middleware-Lösungen, Virtualisierung und APIs,

7.3 Einschätzung zukünftiger Entwicklungen

Zum Abschluss wird in diesem Abschnitt eine eigene und subjektive Einschätzung zukünfti­ger Entwicklungen ausformuliert.

Zunächst ist anzumerken, dass hoher Handlungsbedarf besteht, die Sicherheitsarchitektur des Fahrzeugs an die Verschmelzung mit der Konsumelektronik anzupassen |BSEW13|.

Sicherlich besitzen Google und Apple eine eigene Vision von der Welt, die das Vordringen in das Automobil mit einbezieht |Frel4|, Sie könnten daher eine Lösung nach dem Flexibilitäts­Prinzip anstreben. Noch besitzen OEMs die Hoheit über die Sicherheit des Fahrzeugs und die Kundendaten, doch das könnte sieh ändern, je mehr mit Apple und Google kooperiert wird,

Standardisierungen in Vereinigungen wie OPEN Alliance SIG oder HIS mit eigener API und eigenen Applikationen sowie Firmware können hingegen einem Eingriff in das Fahrzeug durch neue Akteure entgegenwirken |Karl2|, Als positives Beispiel erscheint hierbei der OEM BMW, der mit eigenen Anwendungen ein ausgebautes Multimedia-System bietet. Insgesamt können eine Annäherung der OEMs und offene Standards nach dem Standardisierungs­Ansatz mehr Sicherheit gewährleisten als Seeurity-by-Obseurity - das Geheimhalten der Fahrzeugarchitektur.

Unter den Sicherheitsanforderungen scheint die Datensicherheit am meisten gefährdet, so­wohl bei Einbezug fremder Anbieter als auch durch den OEM selbst. Dass das Fahrzeug zur „Datenkrake“ wird, wie VW-Chef Martin Winterkorn anmerkt, ist kaum zu verhindern. Durch das Zurverfügungstellen der eigenen Daten wird jedoch der Kunde zu einem „Pro- sumenten“, der schnelle Stau- und Straßenlocherkennung ermöglicht, aber auch Fotos von der eigenen Fahrt versenden kann. Im Hinblick auf den Angriffsschutz wird ein Teufelskreis­lauf zwischen Hackern und Security-Mechanismen anlaufen |VM14|, Dies muss allerdings nicht negativ bewertet werden, da erfolgreiches Hacking den Fahrzeugentwicklern zeigt, an welchen Stellen Verbesserungen nötig sind. Dadurch werden auch die Fahrzeugarchitekturen immer sicherer und resistenter. Eine grundlegende Veränderung der Fahrzeugarchitektur weg von seriellen Bussystemen ist dabei auf lange Sicht nicht auszuschließen.

Zu den Entwicklungen, denen sich alle OEMs sicherlich in naher Zukunft annehmen werden, zählen Intrusion Detection, Kryptographie, Ethernet, das Zusammenführen von Steuergerä­ten wie auch Fail-safe Defaults zur Gebrauchssicherheit durch den Fahrer.

Vorstellbar ist die Vermarktung verschiedener Leistungspakete für unterschiedliche Zielgrup­pen: (1) reine Embedded-Systeme für Kunden, die kein Smartphone anschließen möchten; (2) smartphone-intensivere Systeme, die weniger Zugriff auf das Auto aber die Synchronisation mit dem Smartphone erlauben. Diese Form von Kundendiskriminierung ist insofern sinnvoll, als die Kunden jeder Automarke im Alltag unterschiedlich starke Vernetzung gewöhnt sind.

Durch die größere Verbreitung von Brought-In- oder Hybrid-Multimedia-Systemen im Fahr­zeug ist mit sinkenden Unfallzahlen zu rechnen, da mit dem Anschluss des Smartphones an das Fahrzeug und Sprachsteuerung weniger Ablenkung durch die Bedienung des Smart­phones zu erwarten ist. Gleichzeitig könnten die Unfälle aufgrund der Ablenkung durch das Multimedia-System selbst zunehmen. Als positiv einzuschätzen sind hingegen zukünfti­ge Anwendungen, welche beispielsweise die Müdigkeit des Fahrers sowie Betrunkenheit und Beeinträchtigung durch Drogen genau erfassen und Warnungen abgeben |MKW14|.

Insgesamt ist ein Trend hin zu Firewalls, physischer Xetzwerk-Trennung und starken Sicher­heitsprotokollen zu erwarten [ + ], Eine IP-basierte Middleware mit einem Security Framework wird in naher Zukunft nicht möglich sein. Dennoch ist eine Koexistenz serieller Bussysteme mit Ethernet und die Verwendung mehrerer Betriebssysteme und mehrerer Um­gebungen durch Virtualisierung innerhalb eines Hybrid-Systems wahrscheinlich |BSEW13|, Inwiefern der OEM neuen Umsatz mit Car Connectivity erzielen kann, hängt vom Geschäfts­modell und der Make-or-Buy-Entseheidung für jedes Feld des 2-3-6-Konzeptes ab.

Mit dem Seeurity-by-Ansatz schottet sich der OEM von der bestehenden Konsumelektro­nikindustrie ab. Es ist dabei fraglich, ob der OEM alleine dem Kunden genügend Anwen­dungen bieten kann, die sonst Drittanbieter für ihn hersteilen könnten. Im Gegensatz dazu veranlasst der Flexibilitäts-Ansatz eine Unterordnung des Fahrzeugs an übergreifende Ver­netzungssysteme, Dadurch sind Sicherheit und Datenschutz besonders gefährdet. Durch eine Orientierung am Standardisierungs-Ansatz hingegen können die OEMs untereinander Stan­dards und Vereinigungen bilden, um bewusste Schnittstellen und Kooperationen mit der Konsumelektronikindustrie zu vereinbaren.

Apvrille, L,, El Khayari, R,, Henniger, O,, Roudier, Y,, Schweppe, H,, Seu- dié, H,, Weyl, B, und Wolf, M, (2010) Secure automotive on-board electronics network architecture. In FISITA 2010 World Automotive. Congress, Budapest, Flungary, Band 8, Budapest, Ungarn,

Apple (2014) Apple CarPlay - Das beste iPhone Erlebnis auf vier Rädern, ht tp://www.apple.сот/de/ios/carplay/?cid=wwa-de-kwg-features-com,

Audi (2014) Audi connect, http://www.audi.de/de/brand/de/vorsprung_ durch_technik/content/2013/04/connect.htmlľcsref=sea_40338992663,

AUTOSAR (2013) Utilization of Crypto Services VI.0.0 Щ.1 Revi - Autosar Specification ID 602. AUTOSAR, London, England,

Axelsson, S, (2000) Intrusion detection systems: A survey and taxonomy. De­partment of Computer Engineering Chalmers University of Technology, Göte­borg, Sweden,

Bengel, G,, Baun, C,, Kunze, M, und Stueky, К, (2008) Masterkurs und Par­allele Verteilte Systeme - Grundlagen und Programmierung von Multicorepro­zessoren, Multiprozessoren, Cluster und Grid, 1. Auflage. Vieweg^Teubner, Wiesbaden,

Belsehner, R, (2014) Herstellerinitiative Software, http://www.automotive -his.de/,

Bouard, A,, Glas, B,, Jentzseh, A,, Kiening, A,, Kittel, T,, Stadler, F, und Weyl, B, (2012) Driving Automotive Middleware Towards a Secure IP-based Future, In 10th conference for Embedded Security in Cars (Escar’12), Berlin, Germany, URL https ://www.sec.in.tum.de/assets/staff/alexandre/Escar_Pape r_finai.pdf,

BMBF (2009) Sicherheit in eingebetteten IP-basierten Systemen (SEIS), ht

tp://www.pt-it.pt-dlr.de/de/2094,php,

BMW (2013) BMW Connected Drive, Vernetzt mit Ihrer Welt, http://www.bmw.de/de/topics/faszination-bmw/connecteddrive-20 13/ubersicht.html,

Bosworth, S, (2002) Computer Security Handbook - Toward a new framework for information ,security, f. Auflage. John Wiley & Sons, Ine,, Xew York, XY, USA.

Broadcom (2014) BroadR-Reach Physical Layer Transceiver Specification for Automotive Applications Version 3.0. Broadcom Corporation, London, Eng­land,

Bernhart, W,, Schlick, T,, Escobar, J.S, und Wang, W.L. (2013) Connected vehicles - Capturing the value of data. Roland Berger, Stuttgart,

Bonard, A,, Sehanda, J,, Herrscher, D, nnd Eckert, C, (2013) Automotive Proxy-Based Security Architecture for CE Device Integration, In Boreea, C,, Bellavista, P,, Giannelli, C,, Magedanz, T, nnd Schreiner, F, (Herausgeber) Mo­bile Wireless Middleware., Operating Systems, and Applications, Lecture Notes of the Institute for Computer Sciences, Social Informatics and Télécommuni­cations Engineering, Band 65, S, 62-76, Springer Berlin Heidelberg, Springer­Verlag GmbH, Heidelberg, Zweigniederlassung der Springer-Verlag GmbH, Ber­lin,

Bnehmann, J, (2008) Einführung in die Kryptographie, Band 3, Springer Berlin-Heidelberg, Springer-Verlag GmbH, Heidelberg, Zweigniederlassung der Springer-Verlag GmbH, Berlin,

Blake-Wilson, S,, Boiyard, X,, Gnpta, V,, Hawk, C, nnd Moeller, B, (2006) Elliptic Curve Cryptography Cipher Suites for Transport Layer Security an Rnhr-Uni Bochum - Network Working Group, http : //tools . ietf . org/pdf /rfc4492.pdf,

Cheekoway, S,, McCoy, D,, Kantor, В,, Anderson, D,, Shaeham, H,, Savage, S,, Koscher, K,, Czeskis, A,, Roesner, F,, Kohno, T, et al, (2011) Comprehensive Experimental Analyses of Automotive Attack Surfaces. University of California, Univeristy of Washington, San Diego, USA,

Coombs, W.T, (2007) Protecting Organization Reputations During a Crisis: The Development and application of Situational Crisis Communication Theory, In Coombs, W.T, (Herausgeber) Corporate Reputation Review, Band 103, S, 163-176, Paigrave Macmillan Ltd, Xew York, XY, USA,

Dirscherl, H.C, (2010) Smartphone Grundlagen - Android Runtime nnd Dal- vik Virtual Machine, http://www.pcwelt.de/ratgeber/Android-Runtime- und-Dalvik-Virtual-Machine-Smartphone-Grundlagen-1005304.html,

Dirscherl, H.C, (2014) So sicher sind iOS, Android und Windows Pho­ne, http://www.pcwelt.de/ratgeber/Sicherheit-So-sicher-sind-iOS- Android-und-Windows-Phone-7-1129236.html,

Eberspäeher (2014) Kurzeinführung automobiles Ethernet, http: //www.eberspaecher-electronics.com/unternehmen/kurzeinfuehru ng-automobiles-ethernet.html,

Eckert, C, (2013) IT-Sicherheit: Konzepte- Verfahren-Protokolle, 8. Auflage. Ol­denbourg Verlag, Darmstadt,

Ertel, W, (2012) Angewandte Kryptographie, f. Auflage. Carl Hanser Verlag GmbH Co KG, München,

EthorCar (2014) Forschungsprojekt Echtzeit-Ethernet Systeme für Automotive und Automation, http : //ethercar. org/,

Fuchs, S,, Dünnermann, J,, Witte, S, und Schmidt, H.P. (2014) Forschungs­bericht Echtzeit-Ethernet in der Automatisierungstechnik und im Automoti­veumfeld. Ostbayerische Technische Hochschule Amberg-Weiden und Institut für industrielle Informationstechnik Hochschule Ostwestfalen-Lippe, Arnberg­Weiden, Ostwestfalen-Lippe,

Fuß, P, und Forst, H, (2009) White Paper. Vernetzte Wertschöpfung. Die Auto­mobilbranche im Wandel - von der produzierenden zur Dienstleistungsindustrie. Telekom, Berlin,

Fuß, P, und Forst, H, (2012) Verbraucherumfrage Connected Car - das Auto der Zukunft,. Ernst&Young, Eschborn,

Formaestudio (2014) Rijndael Animation, http://www.formaestudio.eom/r ijndaelinspector/archivos/Rijndael_Animation_v4_eng.swf,

Freitag, M, (2014) Das digitale Risiko, Apples Angriff auf BMW, VW und Daimler, http ://www.manager-magazín.de/unternehmen/autоindus trie/apps-im-auto-das-digitale-risiko-a-994277.html,

Fuhrhop, C, und Steglieh, S, (2014) Von der Straße ins Internet, In Siebenpfeif­fer, W, (Herausgeber) Vernetztes Automobil, ATZ/MTZ-Fachbuch - Ausgabe 7, Dezember 2013, S, 230-237, Springer Fachmedien Wiesbaden, Wiesbaden,

Göbel, S, und Dienel, H, (2014) 41 Prozent der jungen Autofahrer nutzen ihr Handy am Steuer, https://www.cosmosdirekt.de/veroeffentlichungen/ handy-am-steuer-49286/,

Google (2014) Demnächst verfügbar: Android Auto - Unterwegs immer bestens informiert, http : //www. android, com/auto/,

Gruenweg, T, (2014) Autogramm VW Polo: Einstöpseln und schwups, http://www.Spiegel.de/auto/fahrberichte/vw-polo-volkswagen-hat- den-kleinwagen-renoviert-und-sparsamer-gemacht-a-963886.html,

Gandhewar, X, und Sheikh, R, (2010) Google Android: An emerging software platform for mobile devices. International Journal on Computer Science, and Engineering, 1(1), S, 12-17,

Hahn, S.H, (2014) Angriffsziel Smartphone, http://www.heute.de/angriff sziel-smartphone-handy-vor-schadsoftware-und-hacker-schuetzen-34 171494,4672.html.

Haken, K.L, (2013) Grundlagen der Kraftfahrzeugtechnik, 2. Auflage. Carl Han- ser Verlag GmbH Co KG, München,

Holle, J,, Groll, A,, Ruland, C,, Cankaya, H, und Wolf, M, (2011) Open Plat­forms on the Way to Automotive Practice. ITS European Congress, University of Siegen, escrypt GmbH, München,

Hillenbrand, M, (2011) Funktionale Sicherheit nach, ISO 26262 in der Konzept­phase der Entwicklung von Elektrik/Elektronik Architekturen von Fahrzeugen. KIT Scientific Publishing, Karlsruhe,

Hoppe, T,, Kiltz, S, und Dittmann, J, (2008) Security Threats to Automotive САХ Networks - Practical Examples and Selected Short-Term Countermeasu­res, In Harrison, M, nnd Snjan, M.A, (Herausgeber) Computer Safety, Reliabi­lity, and Security, Lecture. Notes in Computer Science, Band 5219, S, 235-248, Springer Berlin Heidelberg, Springer-Verlag GmbH, Heidelberg, Zweignieder­lassung der Springer-Verlag GmbH, Berlin,

Häekelmann, H,, Petzold, H, J, nnd Strahringer, S, (2000) Übertragnngsmedien, In Kommunikationssysteme - Technik und Anwendungen, Auflage 2000, S, 59­77, Springer, Heidelberg,

IEEE-Computer-Soeiety (2012) IEEE Standard for Ethernet 802.3. IEEE Com­puter Society, Xew York, XY, USA,

Informationsteehnik (2013) Schutz gegen SQL-Injeetion, https : //www,bsi.bund.de/DE/Themen/ITGrundschutz/ITGrundschutzKatalo ge/Inhalt/_content/m/m02/m02363.html,

Jithin, R, und Chandran, P, (2014) Virtual Machine Isolation, In Martí­nez Pérez, G,, Thampi, S,, Ko, R, und Shu, L, (Herausgeber) Recent, Trends in Computer Networks and Distributed Systems Security, Communications in Computer and Information Science, Band 420, S, 91-102, Springer Berlin Hei­delberg, Springer-Verlag GmbH, Heidelberg, Zweigniederlassung der Springer­Verlag GmbH, Berlin,

Jaramillo, D,, Furht, B, und Agarwal, A, (2014) Virtualization Techniques for Mobile Systems. Springer, Heidelberg,

Karas, J, (2012) Fast, 2025 - Massiver Wandel in der automobilen Wertseh,öp- fungsstruktur - Management, Summary. Oliver Wyman und Verband der Auto­mobilindustrie, Stuttgart,

King, S.T, und Chen, P.M, (2006) SubVirt: Implementing malware with vir­tual machines. In Security and Privacy, Auflage 2006 IEEE Symposium on Multimedia Systems and Applications, S, 14-25, IEEE, Xew York, XY, USA,

Koscher, К,, Czeskis, A,, Roesner, F,, Patel, S,, Kohno, T,, Cheekoway, S,, McCoy, D,, Kantor, В,, Anderson, D,, Shaeham, H, et al, (2010) Experimental security analysis of a modern automobile. In Security and Privacy (SP), 2010 IEEE Symposium on Security and Privacy, Auflage 2010, S, 447-462, IEEE, Oakland,

Kargl, F,, Papadimitratos, P,, Buttyan, L,, Muter, M,, Sehoeh, E,, Wieders- heim, B,, Thong, T.V., Calandriello, G,, Held, A,, Kung, A, et al, (2008) Secure vehicular communication systems: implementation, performance, and research challenges. Communications Magazine, IEEE, 46(11), S, 110-118,

Kroll, J, (2010) Das Who’s Who der Virtualisierungsteehniken, http://www. elektroniknet.de/embedded/software/artikel/26197/6/.

Kiiveler, G. und Sehwoeh, D. (2007) Ethernet-Netze, Band Informatik für Inge­nieure und Naturwissenschaftler 2: PC-und Mikrocomputertechnik, Rechner­netze. Springer Vieweg, Wiesbaden.

Kunbus (2014) Allgemeine Echtzeitkommunikation, http : //www. kunbus . de/ runtime-kommunikation-7-allgemeine-echtzeitkonmmnikation.html.

Kuri, J. (2014) Verkehrsunfälle: Zunehmende Smartphone-Xutzung am Steu­er. http://www.heise.de/newsticker/meldung/Verkehrsunfaelle-Zunehmende-Smartphone-Nutzung-am-Steuer-2123189.html.

Landau, S. (2000) Standing the test of time: The data encryption standard. Notices of AMS, 47(3), S. 341-349.

Little, A. (2013) Ericsson Mobility Report - On the pulse of the networked society. Ericsson, Stockholm, Sweden.

Lin, X., Lu, R,, Zhang, C,, Zhu, H,, Ho, P.H. und Shen, X. (2008) Security in vehicular ad hoe networks. Communications Magazine., IEEE, 46(4), S. 88-95.

Mandl, P. (2013) Betriebssystemvirtualisierung. In Grundkurs Betriebssysteme - Architekturen, Betriebsmittelverwaltung, Synchronisation, Prozesskommuni­kation, 3. Auflage, S. 289-310, Springer Fachmedien Wiesbaden, Wiesbaden.

Mayer, E. (2006) Serielle Bussysteme im Automobil - Teil 1: Architektur, Auf­gaben und Vorteile. In Bussysteme Basiswissen, S. 70-73, Elektronik automo­tive Edition 7.2006, Vector, München.

Madniek, S.E. und Donovan, J.J. (1974) Operating Systems. McGraw-Hill, Ine., Xew York, XY, USA, erste Auflage.

Mercedes (2014) Mercedes connect me. Zu Hause in der digitalen Welt, http ://www.mercedes-benz.de/content/gemany/mpc/mpc_germany_web site/de/home_mpc/passengercars/home/new_cars/models/c-class/s205 /facts/mercedesconnectme.html.

Müller, T,, Krug, S. und Wagner, C. (2014) Cebit Trends Smart Home und vernetztes Auto: IT-Experten äußern Sicherheitsbedenken, Verband der deutschen Internetwirtschaft e.V. http://www.eco.de/2014/pressemeldun gen/cebit-trends-smart-home-und-vernetztes-auto-it-experten-aeus sern-sicherheitsbedenken.html.

Mozer, T. (2013) Speech’s Evolving Role in Consumer Electronics... From Toys to Mobile. In Neustem, A. und Markowitz, J.A. (Herausgeber) Mobile Speech, and Advanced Natural Language Solutions, 1. Auflage, S. 23-34, Springer Xew York, New York, XY, USA.

Nelson, G. (2014) Google puts phones on lockdown - Xew tech will help cut down distracted driving, http://www.autonews.com/article/2014063 0/0EM06/306309969/google-puts-phones-on-lockdown.

Xeumann, A, (2009) The Market of Scientific and Technical Information, In Recommender Systems for Information Providers, 1. Auflage, Contributions to Management Science, S, 1-13, Physiea-Verlag HD, Heidelberg,

Obermann, K, und Horneffer, M, (2013) Datennetztechnologien für Next Gene­ration Networks - Ethernet, IP, MPLS und andere, 2. Auflage. Springer View­eg, Wiesbaden,

OPEXSIG (2014) About ОРЕХ Alliance, http://www.opensig.org/about/ about-open/,

OpenSynergy (2014) Infotainment Head Unit, http://www.opensynergy.co m/loesungen/infotainment-head-unit/.

International Standard Organization (2011) ISO 26262-1:2011 Road vehicles - Functional safety, http://www.iso.org/iso/catalogue_detailTcsnumbe r=43464,

Oguma, H,, Yoshioka, A,, Xishikawa, M,, Shigetomi, R,, Otsuka, A, und Imai,

H, (2008) Xew attestation based security architecture for in-vehicle communi­cation, In Global Telecommunications Conference, 2008. IEEE GLOBECOM 2008. IEEE, IEEE Catalog Number CFP08GLO, S. 1-6, IEEE, Xew Orleans, USA.

Pfitzmann, A, (2004) Why Safety and Security Should and Will Merge, In Hei- sel, M,, Liggesmeyer, P, und Wittmann, S, (Herausgeber) Computer Safety, Reliability, and Security, Lecture Notes in Computer Science, Band 3219, S, 1-2, Springer Berlin Heidelberg, Springer-Verlag GmbH, Heidelberg, Zweignie­derlassung der Springer-Verlag GmbH, Berlin,

Paulin, C.M., Hatton, M,, Bertehlsen, E,, Malhotra, A,, Würtenberger, M,, Butler, D,, Jones, M,, Bzeih, H,, Digman, U, Xollet, X,, Jagler, R, und Pearson,

I, (2013) Connected Car Branchenbericht 2013. Telefonica, London, England,

Pulathanelli, T, und Koch, D, (2014) Automobilgerechte App-Entwieklung, ATZelektronik - Springer Automotive Media, 9(1), S, 10-11,

Plöger, M,, Schütte, H, und Ferrara, F, (2004) Automatisierter Hil-Test im Entwicklungsprozess vernetzter, automotiver Elektroniksysteme, AUTOREG (YD! VI)E).

Pelosi, M,, Tatomireseu, A,, Alrabadi, O,X,, Tsakalaki, E, und Pedersen, G,F, (2013) Better but Worse, the Challenging Promise of f G Smartphones, In Vehi­cular Technology Conference. (VTC Fall), 2013 IEEE 78th, Accession Number I4024IIO. IEEE, Las Vegas, USA,

Pearce, M,, Zeadally, S, und Hunt, R, (2013) Virtualization: Issues, Security Threats, and Solutions, ACM Computing Surveys, 45(2), S, 17:1-17:39,

QXX (2014) QXX - Why do Automotive Manufacturers Choose QXX Softwa­re Systems? http://www.qnx.com/solutions/industries/automotive/?l ang=de.

Reif, K, (2012) Automobilelektronik - Eine Einführung für Ingenieure., f. Auf­lage. Vieweg^Teubner Verlag, Wiesbaden,

Reuters, M, (2014) VW-Chef zur Cebit-Eröffnung: Das Auto darf nicht zur Datenkrake werden, http ://www.feedfreakz.net/inc/redirect,php?id=6 04338&action=fnews,

Ren, J.F, und Landry, R, (1997) Flow control and congestion avoidance in swit­ched Ethernet LAXs, In Communications, 1997. ICC’97 Montreal, Towards the. Knowledge. Millennium. 1997 IEEE International Conference, on Communicati­ons, IEEE Catalog Number 97CH36067, Band 1, S, 508-512, IEEE, Xew York, XY, USA.

Ranney, T.A., Mazzae, E,, Garrott, R, und Goodman, M.J, (2000) XHTSA driver distraction research: Past, present, and future. In Driver Distraction Internet Forum, Band 2000, Rockville, USA,

Reinheit, S,, Schmidt, K,, Gesele, F,, Seid 1er. X, und Hardt, W, (2008) Xut- zung von FlexRay als zeitgesteuertes automobiles Bussystem im AUTOSAR- Umfeld, In Holleezek, P, und Vogel-Heuser, В, (Herausgeber) Mobilität und Ee.htze.it, Auflage. 2008, Informatik aktuell, S, 79-87, Springer Berlin Heidel­berg, Springer-Verlag GmbH, Heidelberg, Zweigniederlassung der Springer­Verlag GmbH, Berlin,

Rutkowska, J, (2006) Introducing stealth malware taxonomy, COSEINC Ad­vanced Malware. Labs, S, 1-9,

Rutkowska, J, (2008) The three approaches to computer security,

http://theinvisiblethings.blogspot.de/2008/09/three-approache s-to-computer-security.html,

Schulz, M, (2013) Logistikintegrie.rte. Produkte.ntwie.klung - Eine, zukunftsorien­tierte Analyse, am Beispiel der Automobilindustrie., 1. Auflage.. SpringerGabler, Wiesbaden,

Sheppard, T, (2014) Xew Faetory-Fit MirrorLink Solutions from Volks­wagen, Honda and Toyota on display at Mobile World Congress, http : //www. mirrorlink. com/sites/def ault/f iles/PRyo20CCCyo20MWCyo 2014y.20Boothy.20Finaiy.20FINAL.pdf.

Sheppard, T, (2014) Xew MirrorLink Factory-Equipped Vehicles to be Unveiled at Geneva Motor Show by PSA Peugeot Citroen - PSA Peugeot Citroen among the first automakers to offer leading ear-smartphone connectivity standard to the mass market, http://www.mirrorlink.com/sites/default/files/PRyo 20CCCy.20MWCy.202014y.20FINALy.202y.2020y.2014 .pdf.

Siriwardena, P, (2014) Advanced A PI-Security - Securing APIs with OAuth 2.0, 1. Auflage., Ope.nID Connect, JWS, and JWE. Apress, Mumbai, India,

Sagstetter, F,, Lukasiewyez, M,, Steinhorst, S,, Wolf, M,, Bouard, A,, Harris, W.R., Jha, S,, Peyrin, T,, Posehmann, A, und Chakraborty, S, (2013) Security Challenges in Automotive Hardware/Software Architecture Design, In Design,

Automation and Test in Europe (DATE 2013), 5. Auflage, S, 458-463, Mün­chen,

Sminkey, L, (2013) Global Status Report On Road Safety 2013 - Supporting a Decade of Action. World Health Organization, Department-of-Violenee-and- Injury-Prevention-and-Disability, Xew York, XY, USA,

Studnia, I., Xieomette, V., Alata, E,, Deswarte, Y,, Kaaniehe, M, und Laarou- ehi, Y, (2013) Survey on security threats and protection mechanisms in em­bedded automotive networks. In Dependable Systems and Networks Workshop (DSN-W), 2013 43rd Annual IEEE I El ľ Conference on Dependable Systems and Networks, S. 1-12, Xew York, XY, USA.

Sehweppe, H,, Roudier, Y,, Weyl, B,, Apvrille, L, und Scheuermann, D, (2011) Car2X Communication: Securing the Last Meter - A Cost-Effective Approach for Ensuring Trust in Car2X Applications Using In-Vehicle Symmetric Cryp­tography, In Vehicular Technology Conference (VTC Fall), 2011 IEEE, S, 1-5, Xew York, XY, USA.

Saltzer, J.H, und Sehroeder, M.D, (1975) The protection of information in computer systems, 1, Auflage, Proceedings of the IEEE, 63(9), S, 1278-1308,

Store, A,A, (2014) Xieht nur eine Million Apps, Eine Million großarti­ger Apps, http ://www.apple.com/de/iphone-5s/app-store/?cid=wwa-de -kwg-features-com,

Syska, A, (2006) Рока Yoke, In Produktionsmanagement, 1. Auflage, S, 102­104, Gabler, Wiesbaden,

Tamietti, M, (2012) Perspectives on In-Vehicle Infotainment Systems and Te­lematics - How will they figure in consumers! vehicle buying decisions ? Accen­ture, Xew York, XY, USA,

Thiele, D,, Ernst, R,, Diemer, J, und Richter, K, (2013) Gemeinsam echtzeit­fähige Ethernet-Architekturen im Fahrzeug schaffen, AT Z elektroník, 8(5), S, 380-385.

Theis, I, (2002) Das Steer-by-Wire System im Kraftfahrzeug œ Analyse der menschlichen Zuverlässigkeit. Dissertation, Lehrstuhl für Ergonomie an der Universität München, München,

Thurlow, A, (2014) Most drivers believe connected-car tech will improve safety, survey says, http://www.autonews.com/article/20140411/0EM06/ 140419956/most-drivers-believe-connected-car-tech-will-improve-s afety-survey#.

Vector-Academy (2014) Serielle Bussysteme im Kfz, https://elearning.ve ctor.com/vl_sbs_introduction_de.html.

Vector (2014) Car2X als Herausforderung der Automobilindustrie, https : //vector.com/vi_car2x_de.html.

Valasek, C, und Miller, C, (2014) A Survey of Remote Automotive Attack Sur­faces. Seribd, Washington, USA,

Weekemann, K, (2014) Domänenübergreifende. Anwendungskommunikation im IP-basie.rte.n Fahrze.ugbordne.tz. Fakultät für Mathematik, Lehrstuhl für Mobile und Verteilte Systeme an der Fakultät Informatik und Statistik der Ludwig- Maximilians-Universität Miinehen, Miinehen,

Weibel, P, (2004) Visionen der Mobilitätsgesellsehaft, In Auswirkungen der virtuellen Mobilität, 1. Auflage, S, 57-73, Springer, Wiesbaden,

Wenig, M, (2014) HUK-Coburg - Kosten für Telematik-Infrastruktur verhält­nismäßig hoeh, http ://www.Versicherungsbote.de/id/4804004/HUK-Cobu rg-Telematik-Kfz-Versicherung/,

Wey 1er, S, (2012) Wirkungen von Markenkrisen - Eine Analyse aus verhaltens­wissenschaftlicher Perspektive. Springer Gabler, Wiesbaden,

Watkins, L, und Gradman, L, (2011) Car Connectivity Consortium Unveils MirrorLink Roadmap, http : //www .mirrorlink. com/ sites/default/files /CCCy,20Summity,20Pressy,20Release_9_29_l 1. pdf.

Wagner, K.P., Hiittl, T, und Baekin, D, (2012) Einführung Wirtschaftsinfor­matik - IT-Grundwissen für Studium und Praxis, 1. Auflage. Springer Gabler, Wiesbaden,

Wieehmann, S, (2014) Car Connectivity Consortium - MirrorLink and the Connected Car, http://www.mirrorlink.com/sites/default/files/doc s/MirrorLink°/020 Introduction.pdf,

Wildt, P, und Meister, R, (2012) Das Smartphone als sichere Burg, In Vereins, S, und Linnhoff-Popien, C, (Herausgeber) Smart Mobile App.s, Xpert,press, S, 209-223, Springer Berlin Heidelberg, Springer-Verlag GmbH, Heidelberg, Zweigniederlassung der Springer-Verlag GmbH, Berlin,

Wolf, M, und Osterhues, A, (2014) Sichere Botschaften - Moderne Krypto­graphie zum Schutz von Steuergeräten, In Vernetztes Automobil, ATZ/MTZ­Faehbueh - 19, Ausgabe, S, 117-124, Springer Faehmedien Wiesbaden, Wies­baden,

Wallentowitz, H, und Reif, K, (2011) Handbuch Kraftfahrzeug elektroník - Grundlagen, Komponenten, Systeme, Anlagen, 2. Auflage. Vieweg^Teubner, Wiesbaden,

Weekemann, K, und Weyl, B, (2011) Aus der IT-Welt ins Auto - Sichere IP- basierte Kommunikation im Fahrzeug, http://www.elektroniknet.de/aut omotive/sonstiges/artikel/76639/7/,

Wolf, M,, Weimerskireh, A, und Paar, C, (2004) Security in automotive bus systems. In Proceedings of the Workshop on Embedded Security in Cars, Auflage 200f, Stuttgart,

|YSDiSW02| Yang-Seo, C,, Dong-il, S, und Sung-Won, S, (2002) A Xew Stack Buffer Over­flow Hacking Defense Technique with Memory Address Confirmation, In Kim, K, (Herausgeber) Information Security and Cryptology — ICISC 2001, Lec­ture Notes in Computer Science, Band 2288, S, 146-159, Springer Berlin Hei­delberg, Springer-Verlag GmbH, Heidelberg, Zweigniederlassung der Springer­Verlag GmbH, Berlin,

|Zdzl2| Zdziarski, J, (2012) Hacking and Securing iOS Applications, 1. Auflage. О Reilly Media, Inc,, Sebastopol, USA,

IZP131 Ziehensack, M, und Pallierer, R, (2013) Ethernet drives the evolution of

Automotive Communication Paradigms, http://standards.ieee.org/eve nts/automotive/10_Ziehensack_EB_Evolution_of_Comm_Paradigms_3rd_ Ethernet_Day.pdf,

IZS111 Zimmermann, W, und Sehmidgall, R, (2011) Bussysteme in der Fahrzeugtech­

nik: Protokolle., Standards und Softwarearchitektur; mit 103 Tabellen, 11. Auf­lage. Vieweg— Teubner, Wiesbaden,

[...]

---

^[1] In[For14] findet man eine Animation, welche die einzelnen Schritte des AES-Algorithmus veranschaulicht.