Sicheres Internet im Fahrzeug. Gründe für Internet im Fahrzeug

Transkript

1 Sicheres Internet im Fahrzeug Gründe für Internet im Fahrzeug Aktuell verfügbare Angebote Selten hat eine Technologie unser Leben so verändert wie das Internet. Für viele ist das Internet aus dem täglichen Leben nicht mehr wegzudenken. So sind heute neben der Informationsbeschaffung über Suchmaschinen und der internetbasierten Kommunikation ( , VoIP), auch die Abwicklung privater und geschäftlicher Transaktionen oder die Nutzung von Kapazitäten zur Datenspeicherung im Internet eine Selbstverständlichkeit. Wie stark uns das Internet im privaten und beruflichen Umfeld prägt und beeinflusst, wird uns meist erst dann bewusst, wenn der gewünschte Dienst nicht mehr zur Verfügung steht. Ein weiterer prägender Trend des 21. Jahrhunderts ergibt sich primär aus der gesamtwirtschaftlichen Entwicklung am Arbeitsmarkt und der anhaltenden Globalisierung. Gemeint ist hiermit das hohe Maß an Mobilität, dass im beruflichen Alltag gefordert wird und für die wie kein anderes Beispiel das Automobil steht. Während die Anbieter von mobilen Diensten vor der Herausforderung stehen, den Nutzern diese Dienste zukünftig möglichst orts-, zeit- und endgeräteunabhängig anzubieten und verfügbar zu halten, muss sich auch die Automobilindustrie mit offenen Zugängen und dem Einzug der Internettechnologien ins Fahrzeug beschäftigen. Auch wenn die Automobilindustrie im Streben nach Innovation die Nutzung von Online-Technologien bereits heute in einigen aktuellen Fahrzeugen möglich macht (z.b. Informationsdienste, Notruf- oder Pannenhilfe), erfolgt dies doch in einem sehr eingeschränkten Maße (Closed User Group bzw. über den Fahrzeughersteller kanalisiert). Im folgerichtigen Zusammenwachsen der Trends wird der Ruf der Anwender nach uneingeschränkter Nutzung von Internet Diensten im Fahrzeug nun immer lauter, was auch durch verschiedene Trendanalysen/Studien untermauert wird. Unterstützt werden die damit zusammenhängenden Bestrebungen durch mögliche neue Kundenanwendungen wie beispielsweise eine WLAN-basierte Übertragung von mp3-dateien vom PC eines Fahrers direkt in das Fahrzeug. Hinzu kommt die nachdrücklicher werdende Forderung der Kunden, im Lebenszyklus ihres Fahrzeugs verschiedene mobile Endgeräte (z.b. ipod) im Fahrzeug anbinden zu können. Neben den Endkunden-spezifischen Aspekten, gibt es aber auch eine Reihe von herstellereigenen Faktoren, die für die Etablierung eines offenen Zugangs zum Fahrzeug und die stärkere Nutzung von Internet-Technologien sprechen und Gegenstand reger Entwicklungs- und Forschungstätigkeit sind. Zu nennen sind hier beispielsweise Fernwartungskonzepte, die eine Diagnose und in Zukunft evtl. sogar eine Programmierung von Fahrzeugen im Feld ermöglichen. Im Dunstkreis dieses Wartungsthemas ist bei den Fahrzeugherstellern auch die Integration von mobilen Endgeräten der Kunden angesiedelt, was den vorab bereits erwähnten Kundenwunsch herstellerseitig reflektiert. Der Fahrzeughersteller steht hierbei vor der Herausforderung, die verschiedenen Unwägbarkeiten meistern zu müssen, die sich aus den unterschiedlichen Lebenszyklen von Fahrzeugen und mobilen Endgeräten ergebenden. So müssen während des Lebenszyklus eines Fahrzeuges bei jedem neuen Release des mobilen Endgerätes neue Treiberbzw. neue Firmware-Versionen in das Fahrzeug eingespielt werden. Sofern der Fahrzeughersteller die Verantwortung für deren fehlerfreie Funktion übernimmt, müsste jede neue Softwareversion die komplexen Test- und Freigabeprozesse beim Hersteller durchlaufen, was im Hinblick auf den Zeitfaktor für diese Prozesse und die Kurzlebigkeit von Endgeräte- bzw. Softwareversionen nicht praktikabel erscheint. Durch die Vielzahl möglicher Endgeräte und deren Softwareversionen ist es deshalb in Zukunft denkbar, dass der entsprechende Code nicht mehr unter Kontrolle des jeweiligen Fahrzeugherstellers steht und der Vorgang des Einspielens auch durch den Endkunden selbst oder Dritte vorgenommen wird. In einem solchen Fall wäre ein offener aber abgesicherter Zugang im Fahrzeug unerlässlich. Letztendlich sprechen auch neue Telematikanwendungen für einen Online-Zugang zum Fahrzeug. Szenarien wie die Fahrzeug-zu-Fahrzeug Kommunikation (Car-to-Car) oder die Kommunikation zwischen Fahrzeugen und fest verbauter Infrastruktur an den Straßen (Car-to-Infrastructure) sollen durch eine optimierte Verkehrslenkung und rechtzeitige Gefahrenmeldung zu einem besseren Verkehrsfluss und vor allem zu einer Reduzierung von Verkehrsunfällen beitragen. Vor diesem Hintergrund liegt der offene Zugang zum Fahrzeug im Interesse von Fahrer, Automobilindustrie,

2 Diensteanbietern und der Politik, wie die Forderung der EU nach Halbierung der Verkehrstoten bis 2010 zeigt. In diesem Zusammenhang ist es für zukünftige Design-Entscheidungen im Hinblick auf Online- Zugänge in den Fahrzeugen realistisch anzunehmen, dass beliebige Internet-Dienste genutzt werden, die nicht ausschließlich von oder über einen Fahrzeughersteller angeboten werden. Unabhängig von den möglichen Anwendungen und den jeweiligen Interessensgruppen zeichnet sich jedoch heute bereits ab, dass für die Umsetzung der Anwendungsszenarien, nicht zuletzt aus Kostenbzw. Effizienzgründen, vor allem standardisierte drahtlose Zugangstechnologien zum Einsatz kommen. Neben den bereits teilweise im Fahrzeug verfügbaren Technologien wie UMTS oder WLAN, wird hierfür künftig auch das Internetprotokoll TCP / IP stark an Bedeutung gewinnen. Dabei sind im Kontext der Dienste-Bereitstellung Betreibermodelle absehbar, bei denen die erforderlichen Dienste- /Content-Server nicht mehr unter der Hoheit eines Herstellers stehen, sondern von unabhängigen Dritten betrieben werden. Im Extremfall sind dann sogar ausführbare Programme wie die oben erwähnte Treiber-Software nicht mehr unter der alleinigen Kontrolle der Fahrzeughersteller. Auch diese Entwicklung spricht klar für einen offenen Zugang und die künftige Nutzung von Internettechnologien im Fahrzeug. Nicht zuletzt für die neuen Telematikanwendungen (z.b. lokale Gefahrenwarnung) ist ein standardisierter, d.h. herstellerunabhängiger Zugang zum Fahrzeug notwendig; diese benötigen für ihre Wirksamkeit eine kritische Fahrzeug-Dichte, wofür eine spontane und herstellerunabhängige Kommunikation zwischen den Fahrzeugen erforderlich ist. Die aufgezeigten Entwicklungstrends erfordern auch künftig Standard-Schnittstellen und -Protokolle, über die die Fahrzeuge ansprechbar sind, wodurch der Intranet-Ansatz, bei dem Fahrzeuge im globalen Internet nicht sichtbar werden, immer unwahrscheinlicher wird. Im Gegenteil, die Fahrzeuge werden Teil des globalen Internets und sind dadurch potentiell für die bekannten Internet-Angriffe wie DoS (Denial of Service), Viren und Trojaner etc. anfällig. Bedrohungen bei der Benutzung des Internets im Fahrzeug Angriffe auf Übertragungsebene Auf Grund der künftig möglichen und bereits in der Entwicklung befindlichen Anwendungen, kann davon ausgegangen werden, dass die Fahrzeuge als Teil des globalen Internets zukünftig auch verstärkt online sind, d.h. sie sind immer und für jedermann über das Internet-Protokoll TCP/IP erreichbar. Besonders bei den auf einer Car-to-Car Kommunikation basierenden Szenarien muss davon ausgegangen werden, dass Fahrzeuge eingehende Verbindungen auch von Absendern akzeptieren, die dem Hersteller des Fahrzeugs per se nicht bekannt sind. Wäre das nicht der Fall, könnten zwischen Fahrzeugen verschiedener Hersteller keine Fahrsicherheitsdaten ausgetauscht werden. Wichtig in diesem Zusammenhang ist die Tatsache, dass bei dieser Kommunikation eine physikalische Verbindung aufgebaut wird, die Ressourcen des Prozessors im Empfangssteuergerät bindet, wodurch sogenannte Denial-of-Service Attacken auf das Fahrzeug denkbar sind. Bei einer solchen Attacke versucht der Angreifer aus dem Internet heraus, die Prozessoren des Steuergeräts, das die Internetkommunikation verwaltet, durch eine Vielzahl von Anfragen komplett auszulasten. Im besten Fall wird dadurch die Rechenleistung des Steuergeräts derartig ausgereizt, dass die eigentliche Applikation auf dem Steuergerät, z.b. die Anzeige von Wegstrecken für den Fahrer, nicht mehr ausgeführt werden kann. Eine erfolgreiche Denial-of-Service Attacke kann aber auch zum kompletten Absturz bzw. Ausfall des Steuergerätes führen und dadurch sogar weitere Funktionen im Bordnetz eines Fahrzeugs beeinträchtigen. In einem solchen Fall könnten sogar fahrrelevante Funktionen des Fahrzeugs betroffen sein. Angriffe dieser Art sind also immer möglich, wenn das Fahrzeug eingehende Verbindungsanfragen akzeptiert und bearbeitet. Da diese Verbindungsanfragen noch vor einem möglichen Authentisierungsvorgang der eingehenden Verbindung bearbeitet werden, können sichere Internet-Protokolle wie z.b. HTTPS oder IPsec eine Denial-of-Service Attacke nicht grundsätzlich verhindern. Natürlich ist es nach wie vor unerlässlich, eingehende Verbindungen auch zu authentisieren, aber es sind zusätzliche Sicherungsmechanismen auf Übertragungsebene notwendig, um ein Fahrzeug wirkungsvoll vor Denial-of-Service Angriffen aus dem Internet zu schützen.

3 Beispiel: Es wird von einem fiktiven Zugangs-Steuergerät im Fahrzeug ausgegangen, dass über einen GPRS- Baustein verfügt, der die physikalische Verbindung ins Internet aufbaut. Über diesen Baustein sollen authentische HTTPS-Zugriffe von einer Applikation auf das Internet möglich sein, wie die nachfolgende Abbildung verdeutlicht: Abb. 1: GPRS Verbindung in ein Steuergerät im Fahrzeug HTTPS bedeutet, dass die Verbindung authentisch und verschlüsselt ist. Im nachfolgenden Bild wird nun eine Denial-of-Service Attacke dargestellt, die von einer Vielzahl von Rechnern aus dem Internet durchgeführt wird. Es handelt sich demnach um eine sogenannte Distributed Denial-of-Service Attacke, die das Zugangssteuergerät mit besonders vielen Daten beschickt, so dass durch die riesige Anzahl von Verbindungsanfragen trotz Verschlüsselung und Authentizität der HTTPS-Stack im besten Falle keine Nutzdaten mehr durchlässt, im schlimmeren Fall aber abstürzt und die darüber liegende Internet Applikation ebenfalls beeinflusst. Im Extremfall ist das Zugangs-Steuergerät insgesamt nicht mehr funktionstüchtig und kann auch nicht mehr gestartet werden.

4 Abb. 2: Wirkungsweise einer Distributed Denial-of-Service Attacke On-Board Attacken auf Applikationsebene Im skizzierten Angriff auf Übertragungsebene findet der Inhalt der transportierten Daten keine Beachtung. So kann auf diesen Übertragungsschichten nicht entschieden werden, ob es sich bei den übertragenen Daten um korrekte Steuergeräte-Daten des Fahrzeugherstellers (z.b. für eine Fernwartungsmaßnahme) oder um manipulierte Daten bzw. bösartigen Code handelt, der das Steuergerät veranlasst, außerhalb der spezifizierten Grenzen zu operieren. Beim Vernetzungsgrad aktueller Bordnetzarchitekturen kann ein solches Fehlverhalten potentiell auch fahrsicherheitskritische Fahrzeugdomänen beeinträchtigen. Die fatalen Folgen einer solchen Beeinträchtigung reichen von einer Imageschädigung beim Fahrzeughersteller bis hin zur Gefährdung der Insassen. Sofern aus dem freien Internet Programme heruntergeladen und in das Fahrzeug eingebracht werden (z.b. Endgeräte-Treiber), können solche Veränderungen durch so genannte Malware wie etwa Viren hervorgerufen werden. Wie ihre biologischen Pendants benötigen Viren eine sogenannte Wirtssoftware, von der sie ausgeführt werden, um z.b. andere Programme zu verändern und damit ihre schadhafte Wirkung zu entfalten. Eine verwandte Art von Schadprogrammen sind die sogenannten Würmer, die vom Effekt her mit den Viren vergleichbar sind, sich aber aktiv verbreiten können, während Viren darauf angewiesen sind, dass die infizierten Daten vom Nutzer aktiv weitergeschickt werden. In der klassischen PC-Welt versucht man dieser Schädlinge durch Anti-Viren-Programme Herr zu werden, indem regelmäßig aktualisierte Programm-Versionen der Anti-Viren-Programme aus dem

5 Internet heruntergeladen werden, die eine Art Whitelist der bekannten Viren enthalten, gegen die die Dateien des jeweiligen Rechners geprüft werden. Die Wirksamkeit dieser Maßnahmen hängt wesentlich von der Aktualität der Liste der bekannten Viren ab. Tritt ein neuer Virus auf, der nicht auf dieser Liste auftaucht, so wird dieser nicht erkannt. Im Automobil-Umfeld ist somit auch schon der größte Nachteil eines solchen Verfahrens benannt: Da Fahrzeuge auch in absehbarer Zukunft nicht garantiert zu jedem Zeitpunkt im Lifecycle online sein werden, ist die Aktualität einer potentiellen Anti-Viren-Software im Fahrzeug nicht gewährleistet. Offline-Zeiten die das rechtzeitige Einspielen einer neuen Version des Virenschutzes verhindern, können beispielsweise bei Tunneldurchfahrten, in ländlichen Gebieten oder bei Garagenaufenthalten mit fehlender Abdeckung geeigneter Kommunikationsnetze und bei Batterieausfällen entstehen. Somit wird der Ansatz, das Fahrzeug über Online-Update-Mechanismen zu schützen fragwürdig. Eine weitere Frage, auf die ein Ansatz mit Anti-Viren-Software keine schlüssige Antwort bietet, ist die Tatsache, dass die Anti-Viren-Software selbst Ziel einer Manipulation werden kann und der Schutz somit ausgehebelt werden kann. Beispiel Virenattacke: Als Grundlage wird ein fiktives Steuergerät gewählt, das im Wesentlichen aus einem Micro-Controller und einem Speicherbereich zur Speicherung der Applikationsprogramme besteht. Es wird davon ausgegangen, dass auf dem Steuergerät eine Internet-Applikation läuft, die es dem Benutzer erlaubt, ausführbare Inhalte aus dem Internet zu laden und zur Ausführung zu bringen. Darüber hinaus steuert das Steuergerät die Lautstärkenregelung des Fahrzeugs. Die Kommunikation mit anderen Fahrzeug- Komponenten erfolgt über den MOST-Bus. Die Architektur des Steuergerätes lässt sich dann wie folgt charakterisieren: Abb. 3: Beispiel-Architektur für ein Internet-fähiges Steuergerät In diesem Szenario könnte sich eine Virus-Attacke folgendermaßen darstellen: Der Fahrer lädt eine infizierte Datei in das Internet-Programm. Durch die Ausführung dieser Datei wird die Audio- Applikation im Code-Speicher dahingehend verändert, dass die Standard-Lautstärke auf Maximum gesetzt wird. Beim nächsten Start des Fahrzeugs wird der Fahrer durch ein überlautes Radio beeinträchtigt. Die Manipulation stellt sich also wie folgt dar:

6 Abb. 4: Beeinträchtigung der Lautstärkenregelung durch eine Virus-Attacke Hier nutzt der Virus also die Möglichkeit aus, dass vom SG veränderte Programme gestartet werden. Eine weitere bekannte Art von Internet-Angriffen sind sogenannte Buffer-Overflow-Attacken. Diese nutzen Programmierfehler, um eigenen Programmcode in die Laufzeitumgebung des angegriffenen Objektes (hier: Steuergerät) zu schreiben. Hierbei macht der Angreifer sich zunutze, dass es Fehler im Programm zulassen, Datenmengen in Speicherbereiche zu schreiben, die kleiner sind als die Größe der zu schreibenden Daten. Dadurch werden angrenzende Speicherbereiche des Steuergeräts überschrieben. Somit ist der Angreifer in der Lage, in diesen angrenzenden Speicher eigenen ausführbaren Code einzubringen, und diesen vom Prozessor ausführen zu lassen. Dies kann etwa passieren, wenn Daten online in das Fahrzeug eingebracht und in einen Buffer geschrieben werden, um dann weiter bearbeitet zu werden, z.b. wenn Bilddateien in Fahrzeuge geladen werden. Es könnte sich potentiell aber auch um eine überlange Nachricht im Rahmen einer Car-to-Car Kommunikation handeln. Selbst wenn solche Nachrichten geschützt sind, z.b. über eine digitale Signatur, könnte bösartiger Programmcode im Anschluss an die digitale Signatur angehängt und mit diesem die

7 entsprechenden Speicherbereiche in der Laufzeitumgebung überschreiben werden. Auf diese Weise wäre es denkbar, eine Hintertür auf einem Steuergerät zur Ausführung zu bringen, die sensible Fahrzeugdaten oder gar Daten des Fahrers zum Angreifer überträgt. Im Gegensatz zu der Abwehr von Angriffen durch Viren, bei der das Problem vor allem in der nicht permanent aufrechtzuerhaltenden Online-Erreichbarkeit des Fahrzeugs liegt, basiert bei dieser Art von Angriffen der Schwachpunkt der Abwehr im unvorhersehbaren Zeitpunkt von Werkstatt-Aufenthalten der Fahrzeuge. Ist nämlich eine Sicherheitslücke erst einmal erkannt, so kann diese nur durch das Einspielen eines Patches behoben werden. Jeder, der mit einem Windows-Betriebssystem arbeitet und den automatischen Update-Service über das Internet nutzt, ist mit diesem Vorgang vertraut. Der Rechner zeigt immer wieder an, dass neue Dateien aus dem Internet zum Download bereitstehen, die die bestehenden Programm-Dateien ersetzen und so die identifizierten Lücken schließen. Bei einem Fahrzeug hingegen kann nicht sichergestellt werden, dass Fahrzeuge rechtzeitig in die Werkstatt gebracht werden, damit die Schwachstellen in den Programmen durch eine Neuprogrammierung des Fahrzeugs behoben werden können. Falls dies aber unter allen Umständen notwendig sein sollte, ist eine teure und ggf. imagewirksame Rückrufaktion für die betroffenen Fahrzeuge notwendig. Bei Fahrzeugen mit einer Fernwartungsschnittstelle liegt die Schwachstelle weniger in dem unvorhersehbaren Zeitpunkt des nächsten Werkstatt-Aufenthaltes, wohl aber in der Verfügbarkeit der Online-Verbindung.

8 Beispiel Bufferoverflow: Am Beispiel der obigen fiktiven SG-Architektur kann auch die Arbeitsweise eines Buffer Overflow Angriffs illustriert werden. Hierbei wird angenommen, dass die Internet-Applikation eine Programmierlücke enthält, die es erlaubt, dass zu lange Daten in Speicherbereiche der Laufzeitumgebung z.b. des Programm-Stacks des Micro-Controllers geschrieben und dort ausgeführt werden. Der Buffer Overflow soll in diesem Beispiel Code enthalten, der es ermöglicht, MOST-Befehle über den MOST-Treiber der Kommunikationsschicht des Steuergeräts abzusetzen. Falls das gelingt wäre der Angreifer in der Lage, den MOST-Ring mit Nachrichten zu fluten, und somit wiederum eine Denial-of-Service Attacke auf die Busse zu fahren und so MOST-Steuergeräte eventuell zum Absturz zu bringen, oder gezielt MOST- Steuergeräte durch unsinnige Befehle zu stören. Dies wird in der nachfolgenden Graphik dargestellt: Abb. 5: Beispiel für eine Buffer-Overflow-Attacke In diesem Fall ist also der Angreifer in der Lage - Eine Veränderung des Programmablaufs eines Steuergeräts zu initiieren - den Unerlaubten Zugriff auf Ressourcen eines Steuergerätes zu erlangen. Um die skizzierten Risiken der Manipulation von Steuergeräten zu reduzieren, sind also Lösungen notwendig, die nicht auf einer ständigen Verfügbarkeit von Online-Zugängen und einer über diese Kanäle stets verfügbaren aktuellen Datenbasis beruhen. Unter Berücksichtigung ihrer Wirkweise wurden von secunet Merkmale für die relevanten Angriffsszenarien abgeleitet und unter Einbeziehung der Spezifika der Automobilbranche ein Verfahren entwickelt, wie diese Angriffe auf Basis dieser Merkmale erkannt und neutralisiert werden können.

9 Verfahren zur Lösung dieser Probleme Designprinzipien Aufgrund der oben geschilderten Problematik einer 100-prozentigen Erreichbarkeit eines Fahrzeugs zur Aktualisierung von notwendigen Anti-Viren Programmen bzw. zum Einspielen von Patches zur Beseitigung von Sicherheitslücken wurde von der secunet der Ansatz gewählt, mögliche Angriffe vor Ort im Fahrzeug zu erkennen und ihre Auswirkungen durch entsprechende Schutzmaßnahmen im Fahrzeug zu neutralisieren. Auf diese Weise kann zwar nicht verhindert werden, dass Angriffe vom Grundsatz her stattfinden, bei geeigneter Wahl der Maßnahmen wird jedoch sichergestellt, dass das oberste Sicherheitsziel in einem Fahrzeug durchgesetzt werden kann: die Unversehrtheit der Fahrfunktionen und die Sicherheit der Insassen. Um darüber hinaus auszuschließen, dass die gewählten Schutzmaßnahmen durch einen der geschilderten Angriffe auf die Software eines Steuergeräts ausgeschaltet werden, ist die Einbeziehung einer sicheren Hardware in das Design der Mechanismen unabdingbar. Schutz vor Angriffen auf Übertragungsebene In diesen Bereich fallen die erwähnten Denial-of-Service Attacken. Diese beziehen sich auf die Verfügbarkeit der Internet-Verbindung bzw. der Applikationen eines Steuergerätes, die diese Verbindung nutzen. Vor diesem Hintergrund hat die Secunet unter Nutzung einer sogenannten Secure Communication Unit (SCU) ein Verfahren entwickelt, um in erster Linie performante und ausfallsichere Kommunikationsverbindungen vom und ins Fahrzeug aufzubauen und zu verwalten, ohne dabei den sicheren Betrieb der Applikationen des Fahrzeugs zu beeinträchtigen. Module für die Authentifizierung der Verbindung sind ebenfalls enthalten. Um die Wirkweise der SCU zu verdeutlichen wird das oben bereits beschriebene Szenario eines Internetzugangs angenommen. Die ursprünglich angenommene Steuergeräte Architektur (siehe Abb. 1) wird nun wie nachfolgend abgebildet um die SCU erweitert. Abb. 6: Beispiel-Architektur eines Steuergeräts mit Secure Communication Unit (SCU)

10 Der Software-HTTPS-Stack in der ursprünglichen Architektur wird also im Wesentlichen durch die SCU ersetzt, die als eigener Hardware-Baustein innerhalb des Steuergeräts realisiert ist. Damit wird zunächst einmal sichergestellt, dass Software-Angriffe die Funktion der Hardware-basierten SCU nicht beeinträchtigen können. Die Verwaltung der SCU Ressourcen übernimmt das sogenannte Koordinationsmodul. Dieses Koordinationsmodul kann über ein Mikrokern basiertes Betriebssystem realisiert werden. In dieser Ausprägung ist das Koordinationsmodul für die eindeutige Zuweisung und Verwaltung der Speicherbereiche zur Ausführung der angeschlossenen Module (hier: HTTPS- und IPC-Modul, vgl. unten) verantwortlich. Das Koordinationsmodul stellt sicher, dass die zugewiesenen Speicherbereiche zur Laufzeit der Module von diesen nicht verlassen werden. Zudem regelt das Koordinationsmodul in dieser Form die Kommunikation zwischen allen angeschlossenen Modulen und kapselt im Kompromittierungsfall das kompromittierte Modul gegen die restlichen, Module ab, um einen beeinflussungsfreien Betrieb zwischen den Modulen zu gewährleisten. Für die Beispielarchitektur bedeutet das konkret, dass das HTTPS-Modul mit dem IPC Modul lediglich über das Kommunikations-Modul Informationen austauschen kann. Das HTTPS-Modul realisiert dabei den HTTPS-Kommunikationsstack und sowie den physikalischen Zugang zum GPRS-Modul. Zudem kommuniziert es via Kommunikationsmodul mit dem Verschlüsselungs-Modul, das als Krypto-Co- Prozessor realisiert sein kann. Das IPC Modul hat lediglich zur Aufgabe, die Inter-Prozessor- Kommunikation (IPC) zwischen dem Hardware-Baustein SCU und dem Hauptprozessor des Zugangs- Steuergeräts zu realisieren. Insbesondere wird also der Datenstrom aus dem Internet an die Internet- Applikation weitergeleitet. Der Nutzen der aufgezeigten Architektur besteht nun darin, dass bei Kompromittierung bzw. Ausfall des HTTPS-Moduls, der Kern (Koordinationsmodul) und die restlichen Module normal weiterarbeiten. Im schlimmsten Fall sind dann die Auswirkungen eines DoS-Angriffs wie folgt dargestellt:

11 Abb. 7: Abwehr von Distributed-Denial-of-Service Angriffen. Bei einer erfolgreichen Denial-of-Service Attacke fällt also lediglich das HTTPS-Modul aus. Vom Grundsatz her ist es jedoch möglich, dass das HTTPS-Modul vom Koordinations-Modul wieder gestartet werden kann. Eine Auswirkung auf die Applikation des Zugangssteuergeräts ist durch die Architektur und Funktion des Koordinationsmoduls ausgeschlossen, ebenso wie ein Absturz des

12 gesamten Steuergeräts. Daneben bietet das als Krypto-Co-Prozessor realisierte Verschlüsselungsmodul deutliche Geschwindigkeitsvorteile, nicht zuletzt beim Verbindungsaufbau, da die rechenintensiven Krypto-Operationen von einer dafür optimierten Hardware durchgeführt werden können. On-Board-sicherheit auf Applikationsebene Während also eine SCU für eine sichere Verbindung sorgt, ist damit noch nicht das Problem gelöst, dass die über die Internet-Verbindung eingebrachten Daten manipulierten bzw. bösartigen Code enthalten. Wie oben dargestellt handelt es sich hierbei um Angriffe, die im Wesentlichen durch die folgenden Muster gekennzeichnet sind: - Veränderung und Hinzufügen von Dateien - Veränderung des Programmablaufs eines Steuergeräts - Unerlaubter Zugriff auf Ressourcen eines Steuergerätes, z.b. Zugriff auf MOST-Schnittstellen zum Versenden von Busnachrichten Vor diesem Hintergrund hat die secunet ein Verfahren entwickelt, welches durch eine zweite, ebenfalls in Hardware umgesetzte Instanz im Steuergerät verkörpert wird - die sogenannte Protection Unit (PU).

13 Abb. 8: Prinzipielle Architektur der Protection Unit (PU) Hauptaufgabe einer PU ist die Überwachung der Laufzeitumgebung eines Steuergeräts und der statischen Programmspeicher. Herzstück der Protection Unit ist dabei die Überwachungslogik. Diese realisiert eine Schnittstelle zum Micro-Controller eines Steuergeräts, um kontinuierlich die Laufzeitumgebung des entsprechenden Micro-Controllers zu prüfen. Hierzu verfügt die Überwachungslogik über die entsprechenden Informationen, um z.b. zu überprüfen, ob die Adressbereiche der Internet-Applikation eingehalten werden. Auf diese Weise kann dann ein Buffer Overflow entdeckt werden, der diese Adress- / Speicherbereiche verlässt. Ebenso kann die Überwachungslogik die Verwendung von bestimmten Ressourcen z.b. der MOST-Schnittstelle überwachen. Daneben prüft die Überwachungslogik auch permanent die Integrität der statisch im Code-Speicher abgelegten Applikationen. Insbesondere hier bedient sich die PU der Krypto-Unit, die Signaturen über diese Speicherbereiche prüft. Dies kann eine kyptographische Checksumme über Speicherbereiche oder die digitale Signatur von Applikationen sein. Hat die Überwachungslogik nun ein von der Spezifikation abweichendes Verhalten erkannt, so wird die Schutzlogik davon benachrichtigt. Je nach Art des erkannten Fehlverhaltens werden von der

14 Schutzlogik die entsprechenden Maßnahmen initiiert. So kann die Schutzlogik z.b. den oben geschilderten Zugriff unterbinden, indem die Ausführung der Internet-Applikation gestoppt wird. Dazu ist ein Eingriff der PU in den Programmablauf des Micro-Controllers notwendig. Darüber hinaus, kann das Steuergerät in einen definierten Zustand versetzt werden, um eine Wiederholung des erkannten Fehlers zu vermeiden. Dieser definierte Zustand wird als Notlaufeigenschaft bezeichnet. Dabei handelt es sich um eine Applikation, die den Betrieb des Steuergeräts in einem definierten Zustand aufrecht erhält und dadurch sicherstellt, dass die Fahreigenschaften und damit die Sicherheit für die Insassen gewährleistet ist. Je nach Art des erkannten Fehlverhaltens können unterschiedliche Notlaufeigenschaften aktiviert werden. Diese reichen beispielsweise vom Neustart (Reset) des Steuergeräts auf dem die bösartigen Applikationen zur Laufzeit vorhanden sind und dem Löschen dieser Daten, bis hin zur Überführung des Steuergerätes in einen Basisbetrieb, z.b. Anzeigen eines Logos und Programmierbarkeit des SG zur Fehlerbeseitigung in einer Werkstatt. Die Wirkweise der Überwachungslogik für die oben genannten Beispiele einer Viren- bzw. Buffer-Overflow-Attacke ist in der nachfolgenden Abbildung dargestellt. Die rot markierten Stellen zeigen, dass die Überwachungslogik hier das Fehlverhalten bzw. die Änderungen erkennt und die Schutzlogik die implementierten Maßnahmen aktiviert.

15 Abb. 9: Erkennung der Angriffsmuster durch die Überwachungslogik der PU Generell detektiert also die Überwachungslogik ein Fehlverhalten und meldet dies der Schutzlogik, die das Steuergerät in einen definierten Zustand versetzt (z.b. Zustand der Original-Software oder Notlaufeigenschaft), was einen ggf. über kryptographische Mechanismen abgesicherten Neustart einschließt. Hierdurch soll sichergestellt werden, dass zumindest grundlegende Eigenschaften eines Steuergeräts erhalten bleiben (z.b. Gateway-Funktionalität innerhalb des Bordnetzes). Es wird also unspezifiziertes Verhalten erkannt. Auf diese Weise werden die Fahrzeug-Domänen von den Infotainment Domänen soweit wie möglich voneinander abgeschottet. Mögliche Erweiterungen der SCU bzw. PU In den obigen Abschnitten wurden die Grundfunktionen der SCU und der PU als Einheiten innerhalb eines Steuergeräts dargestellt. Dabei wäre die SCU auch als eigenes Steuergerät denkbar, welches

16 Verbindungen entgegen nimmt und diese über die Busse an die entsprechenden Steuergeräte weiterleitet. In einem solchen Fall müsste die SCU um CAN-, MOST- oder Flexray-Treiber erweitert werden. Um die SCU im Bedarfsfall programmierbar zu machen, z.b. um aktualisierte CAN-Treiber einzuspielen, ist es vom Konzept der SCU vorgesehen, dass nach erfolgreicher Autorisierung von außen auf die SCU zugegriffen werden kann. Für die Autorisierung kann die in der Verschlüsselungseinheit enthaltene Kryptographie herangezogen werden. Noch augenfälliger wird das Erfordernis der Programmierbarkeit bei der PU. Hier basiert die Erkennung von Fehlverhalten eines Steuergeräts auf gewissen Heuristiken zur Erkennung eines Angriffs. Diese Heuristiken können sich im Laufe der Zeit ändern, und müssen somit von dazu berechtigen Tools oder Hintergrundsystemen nachgeladen werden können. Speziell im Fall der PU kann es zu Diagnose- Zwecken sinnvoll sein, ein Logging der Fehlerfälle einzusetzen. Dazu sind entsprechende Speicher vorzuhalten, die dann von autorisierten Mitarbeitern eines Fahrzeugherstellers ausgelesen werden können. Ausblick Bei den oben beschriebenen Ansätzen zur SCU und der PU handelt es sich um Konzepte, bei deren Umsetzung ein genau abgestimmtes Zusammenspiel von Hardware- und Software-Architekturen notwendig ist. In diesem Zusammenhang spielen neben Mikrokern basierten embedded Betriebsystemen, auch Sandbox-Verfahren und Virtualisierungstechniken zur Separierung der Applikationen untereinander eine große Rolle. Zu prüfen ist hierbei, inwieweit solche Ansätze von dezidierter Hardware unterstützt werden können. Die Palette reicht hier von speziellen ASICS über IP- Core gestützte Co-Prozessor-Ansätze bis hin zu Einbeziehung von FPGA-Bausteinen. Die letzteren bieten Aussicht auf eine, durch den Fahrzeughersteller im Feld konfigurierbare Hardware. Solche Bausteine würden es prinzipiell zulassen, dass die oben erwähnten Heuristiken zur Erkennung von Angriffen performant in Harware realisiert werden können und andererseits geänderte Erkennungsalgorithmen, z.b. aufgrund neuer Erkenntnisse zur Erkennung von Angriffen, in die FPGA-Bausteine nachgeladen werden können. Bei der Auswahl der Hardware werden neben Performance auch Sicherheitsaspekte eine große Rolle spielen. Wie sicher sollen kryptografische Geheimnisse zur Authentisierung, Verschlüsselung und Autorisierung z.b. von Wartungszugriffen auf die Bausteine bzw. Steuergeräte sein? Werden Sicherheitsniveaus benötigt, wie man sie von Smart- Cards kennt, oder kommen auf Grund der spezifischen Anforderungen der Automobilbranche aus Security-Sicht schlankere Methoden zum Einsatz? Hier wird in Zukunft ein spannender Dialog mit Halbleiterherstellern und Fahrzeugherstellern hinsichtlich Prozessor-Roadmaps und Steuergeräte- Architekturen notwendig sein, um eine sichere und performante Plattform zu schaffen, die dem Kostendruck und den Verfügbarkeitsanforderungen der Automobilindustrie Rechnung trägt. Im Gegenzug entsteht eine Steuergeräte-Generation, die den Fahrzeughersteller in die Lage versetzt, mit den Mitteln der modernen Informationstechnologien seinen Kunden völlig neue Erlebniswelten um das Automobil herum zu schaffen und dennoch keine Abstriche bei der Sicherstellung der Fahreigenschaften machen zu müssen.