DE102010008816A1

DE102010008816A1 - Verfahren zur Online-Kommunikation

Info

Publication number: DE102010008816A1
Application number: DE102010008816A
Authority: DE
Inventors: Roland 85622 Dietz; Rainer Dr. 85435 Falk; Hans-Joachim 80337 Hof; Franz 93152 Stadler
Original assignee: Continental Automotive GmbH
Current assignee: Continental Automotive GmbH
Priority date: 2010-02-22
Filing date: 2010-02-22
Publication date: 2011-08-25
Also published as: WO2011101414A1; US9843926B2; CN102893574A; CN102893574B; EP2540053A1; US20130104186A1

Abstract

Die Erfindung betrifft ein System zur Verhinderung eines Angriffs auf ein vernetztes Fahrzeug über eine drahtlose Kommunikationseinrichtung eines Fahrzeugs. Das System weist ein drahtloses Datenverkehrsnetz und eine Sicherheitsstatus-Ermittlungs-Einrichtung, um in Abhängigkeit eines ermittelten Sicherheitsstatus den Zugang zum drahtlosen Datenverkehrsnetz zu regeln, wobei der Sicherheitsstatus auf einer Evaluierung einer aktuellen Konfiguration des Fahrzeugs und/oder von Log-Daten des Fahrzeugs und/oder auf einer verstrichenen Zeit seit einem Update einer betreffenden Software basiert, auf. Weiterhin weist das System eine Kommunikationseinrichtung geeignet zur Verbindung mit dem drahtlosen Datenverkehrsnetz und eine Zugangskontrolleinrichtung zur Regelung des Netzzugangs zum drahtlosen Datenverkehrsnetz, welche mit der Sicherheitsstatus-Ermittlungs-Einrichtung verbindbar ist, auf. Weiterhin betrifft die Erfindung auch ein Verfahren für ein System zur Verhinderung eines Angriffs auf ein vernetztes Fahrzeug über eine drahtlose Kommunikationseinrichtung eines Fahrzeugs, wobei ein Sicherheitsstatus ermittelt wird, wobei der Sicherheitsstatus auf einer Evaluierung einer aktuellen Konfiguration des Fahrzeugs und/oder von Log-Daten des Fahrzeugs und/oder auf einer verstrichenen Zeit seit einem Update einer betreffenden Software basiert. Weiterhin weist das Verfahren die Bestimmung eines Netzzugangsregelsatzes für den Zugang zum Datenverkehrsnetz auf Basis des ermittelten Sicherheitsstatus auf, der anschließend aktiviert wird.

Description

Die Erfindung betrifft ein System zur Verhinderung eines Angriffs auf ein vernetztes Fahrzeug über eine drahtlose Kommunikationseinrichtung eines Fahrzeugs gemäß dem Oberbegriff des Patentanspruchs 1 sowie ein entsprechendes Verfahren.
Stand der Technik
Fahrzeuge wandeln sich zu immer komplexeren Systemen, die unterschiedliche Arten von Inhalten, z. B. aktuelle Wetter- und Verkehrsdaten, Musik, Filme, Point-of-Interest-Information, Software-Updates oder Remote Diagnose über eine oder mehrere drahtlose Anbindungen aus einem oder mehreren Datennetzen laden können.
Für die drahtlose Anbindung kann in Fahrzeugen eine Kommunikationsschnittstelle (Communication Box, ComBox) eingebaut sein, die einen oder mehrere Funkstandards (z. B. GSM/GPRS, EDGE, UMTS, HSDPA, LTE, WLAN, WiMAX, ...) unterstützt. So kann das Fahrzeug bzw. können Komponenten des Fahrzeugs, wie z. B. ein Infotainment-System, mit Infrastruktur-Servern, anderer Fahrzeuge (Car-2-Car-Kommunikation) oder am Straßenrand aufgestellten Funkbaken (Road Side Units) kommunizieren und von diesen Inhalte laden.
Durch diese Drahtlos-Kommunikation werden Fahrzeuge zur nicht vertrauenswürdigen Außenwelt hin geöffnet und sind so auch Angriffen über die Kommunikationsschnittstelle ausgesetzt.
Deshalb benötigen vernetzte Fahrzeuge Schutzmaßnahmen, die Angriffe über die Kommunikationsschnittstelle auf das Fahrzeug verhindern.
Aus dem Stand der Technik sind Vorrichtungen bekannt, die Verbindungen von außen entgegennehmen, an interne Steuergeräte weiterleiten, eine kryptographische Kommunikation durchführen können und die von außen programmierbar sind.
Bei Abruf von Daten aus dem Fahrzeug heraus sind diese Vorrichtungen jedoch nicht geeignet Schutz zu bieten.
Weiterhin sind Systeme bekannt, die Online einen Updatestatus ermitteln. Diese Systeme ermitteln jedoch einen Updatestatus erst nachdem bereits eine Verbindung aufgebaut ist und sind prinzipiell nicht geeignet, den Zugriff auf Inhalte aus dem Fahrzeug heraus zu unterbinden bevor der Updatestatus überprüft ist.
Aufgabe
Aufgabe der vorliegenden Erfindung ist daher, ein System und ein Verfahren bereitzustellen, das geeignet ist, einen Angriff auf ein vernetztes Fahrzeug über eine drahtlose Kommunikationseinrichtung zu verhindern und dabei einen oder mehrere Nachteile aus dem Stand der Technik zu beheben.
Erfindungsgemäß wird ein System zur Verhinderung eines Angriffs auf ein vernetztes Fahrzeug über eine drahtlose Kommunikationseinrichtung eines Fahrzeugs zur Verfügung gestellt.
Dieses System umfasst ein drahtloses Datenverkehrsnetz, eine Sicherheitsstatus-Ermittlungs-Einrichtung, um in Abhängigkeit eines ermittelten Sicherheitsstatus den Zugang zum drahtlosen Datenverkehrsnetz zu regeln, wobei der Sicherheitsstatus auf einer Evaluierung einer aktuellen Konfiguration des Fahrzeugs und/oder von Log-Daten des Fahrzeugs und/oder auf einer verstrichenen Zeit seit einem Update einer betreffenden Software basiert. Weiterhin weist das System eine Kommunikationseinrichtung geeignet zur Verbindung mit dem drahtlosen Datenverkehrsnetz und eine Zugangskontrolleinrichtung zur Regelung des Netzzugangs zum drahtlosen Datenverkehrsnetz, welche mit der Sicherheitsstatus-Ermittlungseinrichtung verbindbar ist, auf.
Weiterhin betrifft die Erfindung auch ein Verfahren für ein System zur Verhinderung eines Angriffs auf ein vernetztes Fahrzeug über eine drahtlose Kommunikationseinrichtung eines Fahrzeugs, wobei ein Sicherheitsstatus ermittelt wird, der auf einer Evaluierung einer aktuellen Konfiguration des Fahrzeugs und/oder von Log-Daten des Fahrzeugs und/oder auf einer verstrichenen Zeit seit einem Update einer betreffenden Software basiert. Weiterhin weist das Verfahren die Bestimmung eines Netzzugangsregelsatzes für den Zugang zum Datenverkehrsnetz auf Basis des ermittelten Sicherheitsstatus auf, der anschließend aktiviert wird.
Fortbildungen des erfindungsgemäßen Systems gemäß Anspruch 1 und eines erfindungsgemäßen Verfahrens gemäß Anspruch 9 sind Gegenstand der jeweiligen abhängigen Ansprüche.
Die Erfindung wird nachfolgend in beispielhafter Weise anhand der Zeichnung erläutert. Die Erfindung ist jedoch nicht auf das dargestellte Ausführungsbeispiel beschränkt. In diesen Abbildungen zeigt:
1 eine schematische Darstellung einer Ausführungsform eines erfindungsgemäßen Systems,
2 einen Ausschnitt einer möglichen Anordnung von erfindungsgemäßen Komponenten bezogen auf ein fahrzeuginternes Bussystem,
3 ein beispielhaftes erfindungsgemäßes Verfahren entsprechend einer ersten Ausführungsform,
4 ein weiteres beispielhaftes erfindungsgemäßes Verfahren entsprechend einer zweiten Ausführungsform,
5 ein weiteres beispielhaftes erfindungsgemäßes Verfahren entsprechend einer dritten Ausführungsform,
6 ein weiteres beispielhaftes erfindungsgemäßes Verfahren entsprechend einer vierten Ausführungsform,
7 einen erfindungsgemäßen Nachrichtenfluss gemäß einer Ausführungsform der Erfindung,
8 eine schematische Darstellung einer weiteren Ausführungsform eines erfindungsgemäßen Systems.
1 zeigt ein Fahrzeug, das über eine On-Board-Unit (OBU) verfügt, die über eine Kommunikationseinrichtung unter Verwendung unterschiedlicher Mobilfunksysteme, z. B. UMTS, LTE, GPRS, WiMAX, WLan, mit Infrastrukturservern in einem beispielhaften Datennetz kommunizieren kann.
Ein beispielhafter Infrastrukturserver kann z. B. ein Download-Server (DL) sein, der Downloads z. B. für Musik anbietet.
Ein anderer Infrastrukturserver kann z. B. ein Vehicle Management Server (VM) sein, der das Fahrzeug konfiguriert und überwacht, z. B. zur Diagnose oder dem Einspielen von Software-Updates.
Noch ein anderer Infrastrukturserver kann ein Vehicle Online Services Server (VOS) sein, der Online-Dienste, z. B. aktuelle Wetter- und Verkehrsinformation, bereitstellt.
Weiterhin kann ein Vehicle Security Status Evaluation Server (VSSES) vorgesehen sein, der einem Fahrzeug Information über dessen Sicherheits-Status bereitstellt.
Außerdem kann das Fahrzeug bzw. die OBU mit anderen Fahrzeugen bzw. OBUs über Car-2-Car-Kommunikation (C2C) oder mit einer fest installierten Road Side Unit (RSU) kommunizieren.
2 zeigt einen Ausschnitt einer möglichen Anordnung von erfindungsgemäßen Komponenten bezogen auf ein fahrzeuginternes Bussystem.
An eine beispielhafte Kommunikationseinrichtung (ComBox) sind Sendeempfangseinheiten angeschlossen, um unterschiedliche Funksysteme (UMTS, HSDPA, WLAN, Broadcast, WAVE (C2C)) verwenden zu können.
Über einen beispielhaften Ethernet-Fahrzeugbus ist ein Infotainment-System mit einer beispielhaften Head Unit, sowie beispielhaft mit zwei Einheiten für die hinteren Sitzplätze, sogenanntem Rear Seat Entertainment (RSE1, RSE2), angebunden. Statt Ethernet könnte hier auch z. B. MOST, Flexray oder jeder andere geeignete Bus eingesetzt werden.
Über ein Gateway (GW) sind zwei Steuergeräte ECU1, ECU2 verbunden, die über ein anderes Protokoll, z. B. das CAN-Protokoll, kommunizieren können.
Die ComBox kann eine Network Access Enforcement Engine (NASE) aufweisen, die die Kommunikation zwischen „außen” und „innen” beschränkt bzw. beeinflusst. Dies erfolgt entsprechend eines aktuellen Netzzugangsregelsatzes (AOAP = Active OTA Access Policy. Dieser Netzzugangsregelsatz (AOAP) wird ausgewählt bzw. definiert durch eine Netzzugangsregelsatz-Auswahlfunktion (NAPS) (Network Access Policy Selection), welche abhängig sein kann vom Ergebnis der Sicherheits-Selbst-Evaluierung (SSE). Weiterhin kann der Netzzugangsregelsatz auch von weiteren Parametern abhängen.
Die ComBox kann eine Netzzugangs-Enforcement-Einheit (Network Access Control Policy Enforcement Unit) enthalten, die den Netzwerkverkehr von/nach „außen”, d. h. zu den Sendeempfangseinheiten, beschränkt bzw. beeinflusst. Sie kann eine Evaluierung des Sicherheitsstatus durchführen und kann einen Sicherheitsregelsatz ermitteln, den sie aktivieren und durchsetzen kann. Weiterhin kann sie optional auch die Konfiguration von Netzwerkkommunikationsfiltern (Firewall-Funktionen) weiterer Komponenten des Fahrzeugs über ein Steuerkommando ändern. Insbesondere kann sie ein Netzwerkkommunikationsfilter des Gateways (GW), einer Einheit des Infotainment-Systems (HU, RSE1, RSE2) oder eines Funkmoduls entsprechend ändern.
3 zeigt ein beispielhaftes erfindungsgemäßes Verfahren entsprechend einer ersten Ausführungsform. Hierbei wird das Verfahren in Schritt 100 gestartet. Der Ablauf des Verfahrens kann durch zahlreiche Ereignisse gestartet werden. So kann z. B. vorgesehen sein, dass bei Einschalten der Zündung, bei Starten des Fahrzeugmotors, bei Einschalten/Aktivieren des Infotainmentsystems, bei einem Verbindungsaufbau (Aktivierung der ComBox), oder aber auch nach einer Konfigurationsänderung/Software-Update oder auch regelmäßig, z. B. zeitgesteuert (z. B. jede Stunde) das Verfahrens gestartet wird.
Anschließend wird der aktuelle Fahrzeug-Security-Status in einem Schritt 300 ermittelt. Auf Basis des ermittelten Fahrzeug-Security-Status wird in Schritt 400 ein Netzzugangsregelsatz bestimmt, der in Schritt 900 aktiviert wird. Anschließend terminiert das Verfahren in Schritt 1000.
In dem vorbeschriebenen Verfahren können alle Schritte autonom im Fahrzeug ablaufen und in entsprechender Weise in der ComBox bzw. der OBU angeordnet sein.
Hierdurch wird ermöglicht, dass bereits vor Aufbau einer Kommunikation und somit bevor eine potenzielle Gefahrenquelle kontaktiert wird, die Sicherheit überprüft wird und Kommunikation im Zweifelsfall erst gar nicht zugelassen wird.
In einer weiter bevorzugten Ausführungsform kann unmittelbar nach dem Start in Schritt 100 in einem hier nicht dargestellten Schritt 200 explizit ein Netzwerkzugangs-Regelsatz „NULL”/„CLOSED”/„DENY ALL” aktiviert werden, um jegliche OTA-Kommunikation vor der Aktivierung des ermittelten Netzwerkzugangs-Regelsatzes in Schritt 300 zu unterbinden.
4 zeigt ein beispielhaftes erfindungsgemäßes Verfahren entsprechend einer zweiten Ausführungsform. Hierbei wird das Verfahren in Schritt 100 gestartet.
In einem Schritt 500 wird ein initialer Netzzugangsregelsatz aktiviert. Danach werden die aktuelle Konfiguration des Fahrzeugs und/oder Log-Daten des Fahrzeugs und/oder die verstrichene Zeit seit einem Update einer betreffenden Software an einen Evaluierungsserver (VSSES) zur Ermittlung des Sicherheitsstatus in einem Schritt 600 übertragen. Das Ergebnis der Ermittlung des Sicherheitsstatus wird in Schritt 700 empfangen, woraufhin in einem Schritt 800 ein geeigneter Netzzugangsregelsatz bestimmt wird. Der bestimmte Netzzugangsregelsatz wird dann in Schritt 900 aktiviert. Anschließend terminiert das Verfahren in Schritt 1000.
In dieser Variante findet eine Evaluierung auf einem externen Server statt. Somit kann das Verfahren als Server-assisted Evaluation bezeichnet werden.
Nur falls die lokale Sicherheitsstatus-Überprüfung als Ergebnis ein Mindestmaß an Sicherheit im Ergebnis ermittelt, wird mit der Server-assisted Security Evaluation fortgefahren.
5 zeigt noch ein weiteres beispielhaftes erfindungsgemäßes Verfahren entsprechend einer dritten Ausführungsform. Hierbei wird das Verfahren in Schritt 100 gestartet.
Unmittelbar nach dem Start kann in Schritt 200 explizit ein Netzwerkzugangs-Regelsatz „NULL”/„CLOSED”/„DENY ALL” aktiviert werden, um jegliche OTA-Kommunikation vor der Aktivierung des ermittelten Netzwerkzugangs-Regelsatzes vorerst zu unterbinden. Anschließend wird der aktuelle Fahrzeug-Security-Status in einem Schritt 300 ermittelt.
Auf Basis des ermittelten Fahrzeug-Security-Status wird in Schritt 400 ermittelt, ob Mindestanforderungen an die Sicherheit erfüllt sind. Sind die Anforderungen nicht erfüllt, so terminiert das Verfahren in Schritt 1000.
Für den Fall, dass die Mindestanforderungen erfüllt sind, fährt das Verfahren wie zuvor in Bezug auf 4 beschrieben fort, d. h., in einem Schritt 500 wird ein initialer Netzzugangsregelsatz aktiviert.
Danach werden aktuellen Konfiguration des Fahrzeugs und/oder von Log-Daten des Fahrzeugs und/oder auf einer verstrichenen Zeit seit einem Update einer betreffenden Software an einen Evaluierungsserver (VSSES) zur Ermittlung des Sicherheitsstatus in einem Schritt 600 übertragen. Das Ergebnis der Ermittlung des Sicherheitsstatus wird in Schritt 700 empfangen, woraufhin in einem Schritt 800 ein geeigneter Netzzugangsregelsatz bestimmt wird. Der bestimmte Netzzugangsregelsatz wird dann in Schritt 900 aktiviert. Anschließend terminiert das Verfahren in Schritt 1000.
Diese Ausführungsform kann als mehrstufige Abfrage des Sicherheitsstatus bezeichnet werden, wobei sowohl Evaluierung autonom im Fahrzeug ablaufen und entsprechender Weise in der ComBox bzw. der OBU angeordnet sein können als auch eine Evaluierung auf einem externen Server stattfinden kann.
6 zeigt noch ein beispielhaftes erfindungsgemäßes Verfahren entsprechend einer vierten Ausführungsform. Hierbei wird das Verfahren in Schritt 100 gestartet.
Unmittelbar nach dem Start kann in Schritt 200 explizit ein Netzwerkzugangs-Regelsatz „NULL”/„CLOSED”/„DENY ALL” aktiviert werden, um jegliche OTA-Kommunikation vor der Aktivierung des ermittelten Netzwerkzugangs-Regelsatzes vorerst zu unterbinden.
Anschließend wird der aktuelle Fahrzeug-Security-Status in einem Schritt 300 ermittelt.
Auf Basis des ermittelten Fahrzeug-Security-Status wird in Schritt 400 ermittelt, ob Anforderungen an die Sicherheit erfüllt sind. Sind die Anforderungen erfüllt, so wird in einem Schritt 900a ein Netzwerkzugangs-Regelsatz aktiviert, der die OTA-Kommunikation aktiviert. Anschließend terminiert das Verfahren in Schritt 1000.
Wird jedoch in Schritt 400 festgestellt, dass die Anforderungen nicht erfüllt sind, so wird eine Server-assisted Evaluation eingeleitet. Diese startet durch eine Aktivierung eines initialen Netzzugangsregelsatz in Schritt 500. Danach werden die aktuelle Konfiguration des Fahrzeugs und/oder Log-Daten des Fahrzeugs und/oder die verstrichene Zeit seit einem Up-date einer betreffenden Software an einen Evaluierungsserver (VSSES) zur Ermittlung des Sicherheitsstatus in einem Schritt 600 übertragen. Das Ergebnis der Ermittlung des Sicherheitsstatus wird in Schritt 700 empfangen.
In Schritt 800 wird überprüft, ob das empfangene Evaluierungsergebnis ausreicht, d. h. es wird bestimmt, welcher Netzwerkzugangs-Regelsatz aktiviert wird. Reicht das Evaluierungsergebnis aus, das System als sicher zu bezeichnen, so wird in Schritt 900a ein Netzwerkzugangs-Regelsatz aktiviert, der die OTA-Kommunikation aktiviert. Anschließend terminiert das Verfahren in Schritt 1000.
Reicht das Evaluierungsergebnis nicht aus, das System als sicher zu bezeichnen, so wird in Schritt 900b explizit ein Netzwerkzugangs-Regelsatz „NULL”/„CLOSED”/„DENY ALL” aktiviert werden, um jegliche OTA-Kommunikation vor der Aktivierung des ermittelten Netzwerkzugangs-Regelsatzes vorerst zu unterbinden. Anschließend terminiert das Verfahren in Schritt 1000.
Das heißt, der Server wird nur angefragt, falls sich das Fahrzeug selbst „nicht sicher” ist, ob es sich in einem sicheren Sicherheitsstatus befindet.
7 stellt einen erfindungsgemäßen Nachrichtenfluss gemäß einer Ausführungsform der Erfindung dar. Hier wird im Fahrzeug, z. B. in der OBU oder einer ComBox, in einem ersten Schritt 2100 eine Fahrzeug-Konfiguration ermittelt. Anschließend wird im Fahrzeug die Kommunikationsschnittstelle in einem weiteren Schritt 2200 aktiviert. Nun kann in einem weiteren Schritt 2300 eine Authentifizierung gegenüber einem VSSES oder ganz allgemein gegenüber einer Sicherheitsstatus-Ermittlungs-Einrichtung (SEE) stattfinden. Diese Kommunikation kann mehrere Nachrichten beinhalten, die zwischen der Kommunikationsschnittstelle und der Sicherheitsstatus-Ermittlungs-Einrichtung ausgetauscht werden. Nachdem diese erfolgt ist kann in einem weiteren Schritt 2400 die Ermittlung eines Sicherheitsstatus aktiviert werden, indem eine entsprechende Anforderung an den SEE gesendet wird. Diese Anforderung kann bereits als Parameter eine aktuelle Konfiguration des Fahrzeugs und/oder Log-Daten des Fahrzeugs und/oder eine verstrichene Zeit seit einem Update einer betreffenden Software beinhalten. Natürlich ist es auch möglich, diese Parameter in einer oder mehreren getrennten Nachrichten zur Verfügung zu stellen.
Anschließend evaluiert die SEE auf Basis der erhaltenen Parameter eine Konfiguration, d. h. einen Sicherheitsstatus, und stellt diesen in einem weiteren Schritt 26000 dem Fahrzeug zur Verfügung.
Das Fahrzeug kann nun durch eine geeignete Einrichtung, z. B. eine Zugangskontrolleinrichtung, einen entsprechenden Netzzugangsregelsatz für den Zugang zum Datenverkehrsnetz aktivieren.
In einer weiteren besonderen Ausführungsform kann die Fahrzeugkonfigurationsinformation beim Vehicle Security Status Evaluation Server (VSSES) bereits vorhanden sein, bzw. von einem Vehicle Manager abgefragt werden. In dieser Ausführungsform ist es nicht erforderlich, die Parameter einer aktuelle Konfiguration des Fahrzeugs und/oder Log-Daten des Fahrzeugs und/oder einer verstrichene Zeit seit einem Update einer betreffenden Software zu übertragen, sondern es genügt, stattdessen eine Fahrzeugidentifizierungsinformation zu übertragen. Wiederum kann diese Information zugleich mit der Anfrage oder aber in einer getrennten Nachricht an die SEE übermittelt werden.
8 zeigt eine schematische Darstellung einer weiteren Ausführungsform eines erfindungsgemäßen Systems. In dieser wird angenommen, dass ein Fahrzeug über eine On-Board-Unit OBU verfügt, die über eine Kommunikationseinrichtung unter Verwendung unterschiedlicher Mobilfunksysteme mit Infrastrukturservern kommuniziert.
Typischerweise ist der Vehicle Manager VM mit einer Fahrzeugdatenbank VDB verbunden oder weist diese auf. In dieser Datenbank werden für von Vehicle Manager verwaltete Fahrzeuge Konfigurationsinformationen gespeichert.
In dieser Ausführungsform kann die Kommunikation oder Teile der Kommunikation über einen Trusted Vehicle Online Communication Proxy (TVOCP) erfolgen. Dargestellt durch eine schwarze Linie ist eine Kommunikationsbeziehung (z. B. http) zwischen dem Fahrzeug und einem Vehicle Online Service (VOS). Diese Kommunikation kann zwischen dem Fahrzeug und dem TVOCP eingetunnelt werden, indem z. B. ein VPN vom Fahrzeug zum TVOCP aufgebaut wird. In einer alternativen Ausführungsform kann bei HTTP der TVOCP als HTTP-Proxy realisiert sein. Dann muss keine Eintunnelung erfolgen, sondern HTTP-Anfragen können auch direkt vom Fahrzeug an den TVOCP gesendet werden, der sie – ggf. modifiziert – an einen Zielserver, z. B. einen VOS, weiterleitet. Die Antwort auf eine solche Anfrage kann entsprechend vom Zielserver VOS an den TVOCP übertragen werden, der sie – ggf. wieder modifiziert – an das Fahrzeug weiterleiten kann.
Beim Aufbau des Tunnels kann sich das Fahrzeug gegenüber dem TVOCP authentifizieren. Der TVOCP kann dann von der Fahrzeugdatenbank VDB die aktuelle Konfiguration des Fahrzeugs abfragen. Diese Konfiguration wird analysiert, um zu ermitteln, ob z. B. aktuelle Securitypatches eingespielt sind. Abhängig davon wird ein Netzzugangsregelsatz oder werden mehrere Netzzugangsregelsätze für dieses Fahrzeug durchgesetzt.
Kennzeichnend ist, dass jegliche Kommunikation oder ein Teil der Kommunikation zwischen Fahrzeug und einem Zielserver über den TVOCP geleitet wird, so dass dort der Datenverkehr untersucht werden kann und potentiell gefährliche oder unerwünschte Kommunikation geblockt werden kann, bevor sie das Fahrzeug erreicht.
Dieser TVOCP setzt auf Basis der Evaluierung, z. B. abhängig vom Typ des Fahrzeugs und der Konfiguration des Fahrzeugs, definierte Netzzugangsregeln (Network Access Policy) durch, d. h., nur diejenige Kommunikation, die durch die definierten Netzzugangsregeln erlaubt ist, wird ermöglicht. Andere Kommunikation wird blockiert.
Die Basis für die Evaluierung erhält der TVOCP auf folgende beispielhafte Arten:

– Direkt übertragen aus dem Fahrzeug (speziell Fahrzeug-Identifizierung/Fahrzeug-Authentifizierung), z. B. wenn das Fahrzeug einen Tunnel zum TVOCP aufbaut (IPSec, SSL/TLS) und sich das Fahrzeug authentisiert. Optional kann bereits hier das Fahrzeug weitere Information über sich (Hersteller, Baureihe, Fahrgestellnummer/VIN, Konfigurationsinformation) übertragen.
– Die Information über das Fahrzeug kann durch den TVOCP von einer Datenbank abgefragt werden; insbesondere kann Information von einem Vehicle Manager (VM) bzw. von der Datenbank (VDB), die der VM benutzt, um Konfigurationsinformation eines Fahrzeugs zu speichern, abgefragt werden. Hier ist insbesondere Information über den Software-Stand eines bestimmten Fahrzeugs verfügbar. So kann insbesondere berücksichtigt werden, ob aktuelle Software-Updates (kritische Security-Updates) eingespielt sind. Gegebenenfalls kann der VM vom TVOCP angestoßen werden, die aktuelle Konfiguration vom Fahrzeug abzufragen.
– Ein TVOCP kann ein Fahrzeug auch aktiv scannen, um Informationen über das Fahrzeug zu erhalten.

Abhängig von diesen Parametern kann eine Netzzugangsregel vom TVOCP bestimmt werden, die bei der folgenden Kommunikation des Fahrzeugs durchgesetzt wird.
Wenn eine Kommunikation gesperrt wird, so kann optional eine Umleitung erfolgen auf einen anderen Server, bzw. der TVOCP antwortet vertretungsweise. Eine HTTP-Anfrage des Fahrzeugs kann beispielweise vom TVOCP abgefangen und eine HTTP-REDIRECT-Nachricht an das Fahrzeug übertragen werden, die den Fahrzeug-Client auf einen anderen HTTP-Server umleitet. Dort kann dann z. B. eine Web-Seite in HTML angezeigt werden, die den Fahrer informiert, dass der Zugriff gesperrt wurde und warum.
Weiterhin kann durch den TVOCP eine Information an das Fahrzeug übertragen werden, dass das Fahrzeug den VM-Server kontaktieren soll. Dies kann beispielsweise erfolgen, indem ein spezieller HTTP-Header in eine HTTP-Response, die an das Fahrzeug übertragen wird, eingefügt wird. Dadurch kann dann der VM-Server z. B. verfügbare Software-Updates an das Fahrzeug übertragen.
Weiterhin kann vom TVOCP eine Information an den VM-Server übertragen werden, dass das Fahrzeug gerade online ist. Bei anstehenden Updates kann der VM-Server eine Management-Sitzung mit dem Fahrzeug initiieren, z. B. durch Senden einer Trigger-SMS-Nachricht.
Es ist dem Fachmann ohne weiteres ersichtlich, dass die vorgenannten Ausführungsformen miteinander kombinierbar sind und z. B. pro Anwendung oder verwendetem Protokoll erneut und getrennt durchgeführt werden kann, wobei unterschiedliche Netzzugangsregelsätze für unterschiedliche Anwendungen und unterschiedliche Herangehensweisen zur Ermittlung des Sicherheitsstatus nebeneinander bestehen können.
Zusammenfassend lässt sich über alle Ausführungsbeispiele festhalten, dass es mittels der Erfindung möglich ist, eine Evaluation autonom durch das Fahrzeug vorzunehmen, oder aber die Evaluation durch einen Server unterstützt wird (Server-assisted Evaluation), oder aber beide zuvor genannten Möglichkeiten kombiniert werden.
Bei einer autonomen Evaluierung kann die Evaluierungs-Funktion die aktuelle Konfiguration des Fahrzeugs und/oder der Log-Daten und/oder der Information, wie lange das letzte Update zurückliegt bzw. wann zuletzt auf Updates überprüft wurde bzw. ob anstehende Updates auch geladen und installiert wurden, überprüfen.
Updates können beispielsweise durch eine Werkstatt eingespielt werden. Dies kann z. B. über einen Werkstatt-Tester geschehen, der über eine Diagnoseschnittstelle mit dem Fahrzeug verbunden ist.
Alternativ können Updates auch durch den Benutzer selbst vorgenommen werden, z. B. mittels Update-Medium, z. B. CD/DVD, USB-Stick, Speicherkarte, etc., oder indem Updates von einem Update-Server über die Funkkommunikationsschnittstelle geladen werden (OTA Self Update).
Bei einem OTA Self Update kommuniziert das Fahrzeug mit einem Vehicle Management Server(VM), um Information über bereitgestellte Updates zu erhalten und sie ggf. zu laden und zu installieren.
Abhängig vom ermittelten Evaluierungs-Ergebnis können dann Netzzugangsregeln ermittelt werden und diese zur Durchsetzung aktiviert werden.
Beispielsweise können zwei Netzzugangsregelsätze definiert sein (UNRESTRICTED, RESTRICTED). Falls das Ergebnis der Evaluierung ist, dass das Fahrzeug sich in einem sicheren Konfigurationsstand befindet (z. B. anstehende sicherheitskritische Updates wurden innerhalb der letzten 7 Tage geprüft und installiert), so wird der Netzzugangsregelsatz UNRESTRICTED aktiviert (ermöglicht z. B. freien, direkten Internet-Zugang). Andernfalls wird der Netzzugangsregelsatz RESTRICTED aktiviert, bei dem nur noch auf vertrauenswürdige Web-Services, die direkt vom Fahrzeughersteller angeboten werden, zugegriffen werden kann.
Bei einer durch einen Server unterstützten Evaluierung (Server-assisted Evaluation) kann das Fahrzeug Parameter an einen Vehicle Security Status Evaluation Server (VSSES) oder allgemein eine Sicherheitsstatus-Ermittlungs-Einrichtung (SEE) übertragen und erhält als Antwort ein Evaluierungs-Ergebnis zurück.
Die übertragenen Parameter können umfassen:

– Identifizierung des Fahrzeugs (z. B. Fahrgestellnummer, Vehicle Identifier VIN),
– Fahrzeug-Typinformation (Hersteller, Modell, Baujahr, verbautes Zubehör),
– Konfigurationsinformation (verbaute Komponenten, Software-Stand),
– Log-Information (Logging-Daten des Fahrzeugs, auch in Verbindung mit dem jeweilig verwendeten Fahrzeugschlüssel, speziell bezülich OTA-Kommunikation, die so auf dem Server ausgewertet werden können).

Es ist insbesondere ausreichend, lediglich eine Fahrzeug-Identifizierungsinformation zu übertragen, wenn in einem Server (VM) in einer Datenbank (VDB) Information über die aktuelle Konfiguration dieses Fahrzeugs gespeichert ist und durch den VSSES abfragbar ist. Dies ist z. B. der Fall, wenn die Fahrzeugkonfiguration z. B. mithilfe des OMA (Open Mobile Alliance) DM Protokolls OTA verwaltet wird. Falls die Information nicht in einer Datenbank hinterlegt ist, kann die Information direkt vom Fahrzeug an den VSSES übertragen werden.
Das Evaluierungs-Ergebnis kann aufweisen:

– Flag (secure yes/no),
– Wert (z. B. 0, 1, 2, ..., 9),
– Identifier (Policy-Identifier direkt oder Mapping),
– bereitgestellte Sicherheitsupdates, ggf. mit Information über ihre Kritikalität bzw. der betroffenen Funktionalität,
– Netzzugangsregeln.

Abhängig vom empfangenen Evaluierungs-Ergebnis konfiguriert das Fahrzeug Netzzugangsregeln und setzt diese durch.
Bei dem Vehicle Security Status Evaluation Server (VSSES) handelt es sich beispielsweise um einen Server des Fahrzeugherstellers oder eines Kommunikations-Anbieters. Zwischen Server und Fahrzeug findet eine Authentisierung statt. Die Kommunikation kann z. B. mittels IPSec-, SSL- oder TLS-Protokoll geschützt sein. Die Information kann z. B. über HTTP, SOAP, OMA DM, SyncML, SNMP erfolgen.
Obwohl der VSSES als selbständige Einheit beschrieben ist, kann diese auch in anderen Einheiten enthalten sein. So kann der VSSES z. B. Teil eines VM Servers sein, der ggf. Updates bereitstellt.
Wie bereits ausgeführt können einige Netzzugangsregelsätze vordefiniert sein, z. B.:

– UNRESTRICTED: beliebige Kommunikation zugelassen (auch direkt ohne über eine Proxy);
– UNRESTRICTED INFRASTRUCTRE: beliebige Kommunikation mit Infrastrukturdiensten zulassen (auch direkt), aber nicht Fahrzeug-zu-Fahrzeug-Kommunikation;
– MANAGED INFRASTRUCTURE: beliebige Kommunikation mit Infrastrukturdiensten zulassen (auch direkt), dabei aber nur von einem bekannten Infrastruktur-Operator betriebene Mobilfunknetze verwenden (also z. B. nur GPRS, UMTS/HSDPA über Vodafone, T-Mobile oder Orange, aber nicht WLAN);
– TUNNEL: Kommunikation tunneln zu Trusted Gateway (Datenverkehr wird eingetunnelt und zu VPN-Server gesendet, wo er analysiert und gefiltert werden kann, bevor er z. B. zu einem Internet-Server weitergeleitet wird; nur eingetunnelter Datenverkehr, der von diesem Server stammt, wird weiter bearbeitet);
– TRUSTED SERVER: nur Kommunikation mit Online-Diensten möglich, die von einem Server angeboten werden, der auf einer konfigurierten Whitelist des Fahrzeugs verzeichnet ist (z. B. http://*.bmw.de; https://*.bmw.de; http://*.bmw.com; https://*.bmw.com);
– NULL/CLOSED/DENY ALL: keine OTA-Kommunikation möglich.

Alternativ oder ergänzend kann ein Netzzugangsregelsatz auch vom Vehicle Security Status Evaluation Server (VSSES) oder einem anderen Server bereitgestellt werden.
Es können auch feingranulare Netzzugangsregelsätze definiert werden: Es kann z. B. ein Content-Filtering vorgenommen werden, um für das Auto gefährliche Inhalte zu filtern. Zum Beispiel werden Flash-Content oder JavaScripts auf Webseiten nur dann durchgelassen, wenn ein bestimmtes Fahrzeug die aktuellen Security-Patche für die entsprechenden Anzeigeprogramme geladen hat.
Der Inhalt eines Netzzugangsregelsatzes kann z. B. die Verwendung einer Firewall und eines VPN vorschreiben.
Ein Netzzugangsregelsatzes besteht aus Regeln. Diese beschreiben, welche Art von Netzwerkverkehr auf welche Weise zu behandeln ist, insbesondere ob er

– zugelassen ist, d. h. weiterbearbeitet wird und ggf. an die Ziel-Steuergeräte im Fahrzeug weitergeleitet wird (Allow);
– einzutunneln ist (tunnel; encapsulate), d. h. über einen VPN-Tunnel zu übertragen ist;
– auszutunneln ist (detunnel; decapsulate), d. h. über einen VPN-Tunnel empfangene Daten auszupacken, bevor sie weiter bearbeitet bzw. an das Ziel-Steuergerät weitergeleitet werden;
– zu verwerfen ist (discard).

Außerdem können für zugelassenen Datenverkehr gewisse Beschränkungen auferlegt werden, insbesondere Einschränkungen bezüglich der maximalen Datenrate, um z. B. die Überlastung von Zielkomponenten zu verhindern.
Mögliche Filterkriterien weisen auf:

– Fahrzeug: Fahrzeughersteller, Modell, Version/Baujahr, verbautes Zubehör (speziell Version des eingebauten Infotainment-Systems);
– Richtung (inbound zum Fahrzeug, outbound vom Fahrzeug);
– Zielkomponente im Fahrzeug (d. h. an welches Steuergerät werden die Daten weitergeleitet bzw. von welchem Steuergerät stammen sie);
– OTA-Schnittstelle (GPRS, UMTS, WLAN, ...);
– aktueller OTA-Netzwerkbetreiber (z. B. T-Mobile, Vodafone, unbekannt) und Land (Deutschland, Frankreich, ...);
– IP-Adresse (Sender, Empfänger);
– Herkunftsland IP-Adresse (gewisse Länder können gesperrt werden);
– Protokoll (z. B. TCP, UDP);
– Portnummer;
– URL Filter;
– Kommunikation verschlüsselt (z. B. SSL, TLS) oder unverschlüsselt;
– dedizierte Filter für bekannte Angriffe, speziell Denial of Service (DoS) (z. B. Ping-Paket mit bestimmter Länge);
– Tunnel direkt empfangener Daten über Trusted Server.

Neben reiner Netzwerkkommunikation können sich Netzzugangsregelsätze auch auf Inhalt, den sogenannten Content, beziehen (Web-Seiten, Multimedia-Dateien, Programmcode):

– Nutzbare Multimedia-Formate (z. B. könnten CDs und WAV-Files immer abspielbar sein, während MP3 und Videos nicht mehr abspielbar sind);
– Unterstützte Browser-Plug-Ins, z. B. für Flash-Animationen;
– Kriterien zur Zuordnung von Online-Inhalten (Web-Seiten) zu Security-Zonen (Eine Security Zone z. B. bei Microsofts Internet Explorer definiert, welche Möglichkeiten Web-Inhalte von Web-Sites dieser Zone gewährt werden, z. B. ob Nutzung von JavaScript möglich ist.). Die Zuordnung erfolgt anhand der URL, von der eine Web-Seite bzw. allgemein ein Online-Inhalt geladen wird.
– die mit einer Security-Zone verbundenen Berechtigungen (für Online-Inhalte);
– Berechtigungen für ausgeführten Programmcode: Im Stand der Technik ist Code Access Security bekannt, z. B. bei der Microsoft Common Language Runtime oder dem Java Runtime Environment. Dabei werden Programmcode Zugriffsrechte abhängig von seinem Ursprung gewährt (d. h. abhängig davon, wer ihn signiert hat bzw. von wo er geladen wurde). Neu werden nun abhängig von der Sicherheitsevaluierung die Berechtigungen, die einem bestimmten Code eingeräumt werden, gesetzt; bzw. es wird abhängig vom Evaluierungsergebnis definiert, ob ein bestimmter Code überhaupt ausgeführt werden kann. Zum Beispiel kann auf diese Weise die Ausführung von Untrusted Code/Downloaded 3rd Party Code verhindert werden, wenn der Patchstatus der Fahrzeugkomponente nicht aktuell ist.

Der ausgewählte Netzzugangsregelsatz wird vorzugsweise von der Kommunikationseinheit des Fahrzeugs durchgesetzt. Alternativ kann dies auch von einer separaten, vorgeschalteten Sicherheitskommunikationseinheit erfolgen.
In einer Variante kann darüber hinaus auch Fahrzeug-intern im Bord-Netz durch Zugangskontrolleinrichtung (Fahrzeugbus-Gateways, Steuergeräte) eine Filterung der Kommunikation erfolgen. Die Kommunikationseinheit bzw. die Sicherheitskommunikationseinheit kann dazu eine Information an diese Zugangskontrolleinrichtung über den Fahrzeug-Sicherheitsstatus übertragen (Indikator, Filterregeln), wodurch diese ihre Netzzugangsregeln entsprechend anpassen. Die jeweilige Komponente kann jedoch auch individuell das beschriebene Verfahren durchführen.
Um eine Sperrung zu vermeiden sollte der Benutzer vorzugsweise einen Hinweis erhalten, rechtzeitig bzw. möglichst bald Security-Patche einzuspielen, um weiterhin sämtliche Dienste nutzen zu können.
Bei eingeschränktem Zugang sind die Kommunikations-Möglichkeiten beschränkt und deshalb evtl. nicht alle Dienste nutzbar. Jedoch soll es vorzugsweise immer noch möglich sein, erforderliche Softwareupdates einzuspielen. Der Benutzer kann darauf hingewiesen werden, dass für eine entsprechende Dienstnutzung ein Software-Update nötig ist.
Mittels der Erfindung kann ein Fahrzeug relativ frei direkt kommunizieren, soweit dies gefahrlos möglich ist. Werden jedoch Angriffe erkannt, oder sind die Schutzmaßnahmen des Fahrzeugs veraltet oder nicht mehr ausreichend wirksam, können Gefährdungen, z. B. Manipulation an Fahrzeugkomponenten per Onlineverbindungen, durch entsprechende Selbstschutzmaßnahmen vermieden werden. Wenn aus Sicherheitsgründen erforderlich, werden durch die genannten Schutzmechanismen Online-Services eingeschränkt oder ganz unterbunden.
Fahrzeugkomponenten erhalten nur bei aktuellem Sicherheitsupdatestand der Software vollen Zugang nach außen, da sie dann die dadurch auftretenden Angriffe aus dem Netz abwehren können. So ist in ein zuverlässiger Fahrzeugbetrieb gewährleistet.
Bezugszeichenliste

OBU

On-Board-Unit

DL

Download-Server

VM

Vehicle Management Server

VOS

Vehicle Online Services Server

VSSES

Vehicle Security Status Evaluation Server

RSU

Road Side Unit

C2C

Car-2-Car-Kommunikation

ComBox

Communication-Unit

RSE1,

RSE2 Rear Seat Entertainment

GW

Gateway

NASE

Network Access Enforcement Engine

AOAP

active OTA access policy, aktueller Netzzugangsregelsatz

NAPS

Network Access Policy Selection, Netzzugangsregelsatz-Auswahlfunktion

SEE

Sicherheitsstatus-Ermittlungs-Einrichtung

SSE

Sicherheits-Selbst-Evaluierung

ECU1, ECU2

Steuergeräte

TVOCP

Trusted Vehicle Onlince Communication Proxy

VDB

Vehicle Database

Claims

System zur Verhinderung eines Angriffs auf ein vernetztes Fahrzeug über eine drahtlose Kommunikationseinrichtung eines Fahrzeugs, umfassend: – ein drahtloses Datenverkehrsnetz, – eine Sicherheitsstatus-Ermittlungs-Einrichtung, um in Abhängigkeit eines ermittelten Sicherheitsstatus den Zugang zum drahtlosen Datenverkehrsnetz zu regeln, – wobei der Sicherheitsstatus auf einer Evaluierung einer aktuellen Konfiguration des Fahrzeugs und/oder von Log-Daten des Fahrzeugs und/oder auf einer verstrichenen Zeit seit einem Update einer betreffenden Software basiert, – eine Kommunikationseinrichtung geeignet zur Verbindung mit dem drahtlosen Datenverkehrsnetz, – eine Zugangskontrolleinrichtung zur Regelung des Netzzugangs zum drahtlosen Datenverkehrsnetz, welche mit der Sicherheitsstatus-Ermittlungs-Einrichtung verbindbar ist.
System nach Anspruch 1, wobei die Sicherheitsstatus-Ermittlungs-Einrichtung im Fahrzeug angeordnet ist, und eine Evaluierung des Sicherheitsstatus autonom durchführbar ist.
System nach Anspruch 1, wobei die Sicherheitsstatus-Ermittlungs-Einrichtung im Datenverkehrsnetz angeordnet ist.
System nach einem der Ansprüche 1 bis 3, wobei die Zugangskontrolleinrichtung im Fahrzeug angeordnet ist.
System nach einem der Ansprüche 1 bis 3, wobei die Zugangskontrolleinrichtung im Datenverkehrsnetz angeordnet ist.
System nach einem der Ansprüche 1 bis 5, wobei die Regelung des Netzzugangs zum drahtlosen Datenverkehrsnetz durch Netzzugangsregelsätze regelbar ist, wobei die Netzzugangsregelsätze zum drahtlosen Datenverkehrsnetz nach Art einer Verbindung, nach Art von Filterkriterien und/oder nach Art von Content auswählbar sind.
System nach einem der Ansprüche 1 bis 6, wobei die Regelung des Netzzugangs weiterhin beinhaltet festzulegen, ob der Zugang verschlüsselt oder getunnelt zu erfolgen hat.
System nach einem der Ansprüche 1 bis 7, wobei die Evaluierung des Sicherheitsstatus weiterhin aufweist: Erkennen, dass eine Fahrzeugkomponente einen Angriff oder eine Fehlfunktion im Rahmen des Netzzuganges erkannt hat.
Verfahren für ein System zur Verhinderung eines Angriffs auf ein vernetztes Fahrzeug über eine drahtlose Kommunikationseinrichtung eines Fahrzeugs, das System aufweisend: – ein drahtloses Datenverkehrsnetz, – eine Sicherheitsstatus-Ermittlungs-Einrichtung, – eine Kommunikationseinrichtung geeignet zur Verbindung mit dem drahtlosen Datenverkehrsnetz und – eine Zugangskontrolleinrichtung aufweisend die Schritte: – Ermitteln eines Sicherheitsstatus, wobei der Sicherheitsstatus auf einer Evaluierung einer aktuellen Konfiguration des Fahrzeugs und/oder von Log-Daten des Fahrzeugs und/oder auf einer verstrichenen Zeit seit einem Update einer betreffenden Software basiert, – auf Basis des ermittelten Sicherheitsstatus Bestimmen eines Netzzugangsregelsatzes für den Zugang zum Datenverkehrsnetz, – aktivieren des bestimmten Netzzugangsregelsatzes.
Verfahren nach Anspruch 9, weiterhin aufweisend die Schritte: – Aktivieren eines initialen Netzzugangsregelsatzes, – Übertragen von aktuellen Konfiguration des Fahrzeugs und/oder von Log-Daten des Fahrzeugs und/oder auf einer verstrichenen Zeit seit einem Update einer betreffenden Software an einen Evaluierungsserver zur Ermittlung des Sicherheitsstatus, – Übertragen des ermittelten Sicherheitsstatus.
Verfahren nach Anspruch 10, wobei ein Sicherheitsstatus sowohl lokal als auch remote ermittelt wird.