WO2011101414A1 - System und verfahren zur verhinderung eines angriffs auf ein vernetztes fahrzeug - Google Patents

System und verfahren zur verhinderung eines angriffs auf ein vernetztes fahrzeug Download PDF

Info

Publication number
WO2011101414A1
WO2011101414A1 PCT/EP2011/052362 EP2011052362W WO2011101414A1 WO 2011101414 A1 WO2011101414 A1 WO 2011101414A1 EP 2011052362 W EP2011052362 W EP 2011052362W WO 2011101414 A1 WO2011101414 A1 WO 2011101414A1
Authority
WO
WIPO (PCT)
Prior art keywords
vehicle
security status
network
network access
evaluation
Prior art date
Application number
PCT/EP2011/052362
Other languages
English (en)
French (fr)
Inventor
Roland Dietz
Rainer Falk
Hans-Joachim Hof
Franz Stadler
Original Assignee
Continental Automotive Gmbh
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Continental Automotive Gmbh filed Critical Continental Automotive Gmbh
Priority to US13/580,658 priority Critical patent/US9843926B2/en
Priority to EP11703708A priority patent/EP2540053A1/de
Priority to CN201180010608.7A priority patent/CN102893574B/zh
Publication of WO2011101414A1 publication Critical patent/WO2011101414A1/de

Links

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/10—Network architectures or network communication protocols for network security for controlling access to devices or network resources
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/14—Network architectures or network communication protocols for network security for detecting or protecting against malicious traffic
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W12/00—Security arrangements; Authentication; Protecting privacy or anonymity
    • H04W12/08—Access security
    • H04W12/088—Access security using filters or firewalls
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W12/00—Security arrangements; Authentication; Protecting privacy or anonymity
    • H04W12/12—Detection or prevention of fraud
    • H04W12/126—Anti-theft arrangements, e.g. protection against subscriber identity module [SIM] cloning
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/01—Protocols
    • H04L67/12—Protocols specially adapted for proprietary or special-purpose networking environments, e.g. medical networks, sensor networks, networks in vehicles or remote metering networks
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W4/00—Services specially adapted for wireless communication networks; Facilities therefor
    • H04W4/30—Services specially adapted for particular environments, situations or purposes
    • H04W4/40—Services specially adapted for particular environments, situations or purposes for vehicles, e.g. vehicle-to-pedestrians [V2P]
    • H04W4/44—Services specially adapted for particular environments, situations or purposes for vehicles, e.g. vehicle-to-pedestrians [V2P] for communication between vehicles and infrastructures, e.g. vehicle-to-cloud [V2C] or vehicle-to-home [V2H]

Definitions

  • the invention relates to a system for preventing an attack on a networked vehicle via a wireless communication device of a vehicle according to the preamble of patent claim 1 and a corresponding method.
  • 15 wireless connections can load from one or more data networks.
  • a communication interface (Communication Box, ComBox) can be installed in vehicles
  • radio standards eg GSM / GPRS
  • EDGE UMTS
  • HSDPA High Speed Downlink Packet Access
  • LTE Long Term Evolution
  • WLAN Wireless Local Area Network
  • WiMAX WiMAX
  • Radio beacons Road Side Units
  • the object of the present invention is therefore to provide a system and a method which is suitable for preventing an attack on a networked vehicle via a wireless communication device and thereby solving one or more disadvantages of the prior art.
  • a system for preventing an attack on a networked vehicle via a wireless communication device of a vehicle comprises a wireless traffic network, a security status determination device for regulating access to the wireless traffic network in dependence on a determined security status, the security status being based on an evaluation of a current configuration of the vehicle and / or log data of the vehicle and / or. or based on an elapsed time since an update of a related software.
  • the system has a communication device suitable for connection to the wireless traffic network and an access control device for regulating network access to the wireless traffic network, which is connectable to the security status determination device on.
  • the invention also relates to a method for a system for preventing an attack on a networked vehicle via a wireless communication device of a vehicle, wherein a safety status is determined based on an evaluation of a current configuration of the vehicle and / or log data of the vehicle and / or based on an elapsed time since an update of any relevant software. Furthermore, the method has the determination of a network access rule set for access to the data traffic network on the basis of the determined security status, which is subsequently activated.
  • FIG. 1 is a schematic representation of an embodiment of a system according to the invention
  • 5 shows a further exemplary method according to the invention according to a third embodiment
  • 6 shows a further exemplary method according to the invention according to a fourth embodiment
  • Fig. 8 is a schematic representation of another imple mentation of a system according to the invention.
  • FIG. 1 shows a vehicle having an on-board unit (OBU), which is connected via a communication device using different mobile radio systems, eg. UMTS, LTE, GPRS, WiMAX, WLan, can communicate with infrastructure servers in an exemplary data network.
  • OBU on-board unit
  • An exemplary infrastructure server may e.g. B. a download server (DL), the downloads z. B. for music offers.
  • Another InfrastructureServer can, for.
  • a vehicle management server (VM) that configures and monitors the vehicle, e.g. For example, to diagnose or import software updates.
  • Yet another Infrastructure Server may be a Vehicle Online Services Server (VOS) that provides online services, e.g. B. current weather and traffic information provides.
  • VOS Vehicle Online Services Server
  • VSSES Vehicle Security Status Evaluation Server
  • the vehicle or the OBU can communicate with other vehicles or OBUs via car-2-car communication (C2C) or with a permanently installed road side unit (RSU).
  • Figure 2 shows a section of a possible arrangement of components according to the invention with respect to an in-vehicle bus system.
  • Transceiver units are connected to an exemplary communication device (ComBox) in order to be able to use different radio systems (UMTS, HSDPA, WLAN, broadcast, WAVE (C2C)).
  • UMTS UMTS, HSDPA, WLAN, broadcast, WAVE (C2C)
  • UMTS exemplary communication device
  • HSDPA High Speed Downlink Packet Access
  • WLAN Wireless Fidelity
  • WAVE WAVE
  • an exemplary Ethernet vehicle bus an infotainment system with an exemplary head unit, as well as by way of example with two units for the rear seats, so-called rear seat entertainment (RSE1, RSE2), is connected.
  • RSE1, RSE2 rear seat entertainment
  • Ethernet could also z.
  • a gateway Via a gateway (GW) two ECUs ECU1, ECU2 are connected via another protocol, eg.
  • the CAN protocol can communicate.
  • NAEE Network Access Enforcement Engine
  • This network access policy set (AOAP) is selected or defined by a Network Access Policy Selection (NAPS) selection function, which may be dependent on the result of the security self-evaluation (SSE).
  • SSE security self-evaluation
  • the network access rule set can also depend on further parameters.
  • the ComBox may include a Network Access Control Policy Enforcement Unit that restricts network traffic from / to "outside," ie, to the transceiver units, and may perform an evaluation of security status determine a security rule set that you activate and enforce can put. Furthermore, it can optionally also change the configuration of network communication filters (firewall functions) of other components of the vehicle via a control command. In particular, it can change a network communication filter of the gateway (GW), a unit of the infotainment system (HU, RSE1, RSE2) or a radio module accordingly.
  • GW network communication filter of the gateway
  • HU infotainment system
  • RSE1 infotainment system
  • RSE2 infotainment system
  • FIG. 3 shows an exemplary method according to the invention according to a first embodiment.
  • the method is started in step 100.
  • the process can be started by numerous events. So z. B. be provided that when you turn on the ignition, when you start the vehicle engine, when you turn on / activate the infotainment system when connecting (activation of the ComBox), or even after a configuration change / software update or even regularly, for. B. Scheduled (eg every hour) the process is started.
  • step 300 the current vehicle security status is determined in a step 300.
  • a network access rule set is determined in step 400, which is activated in step 900.
  • step 1000 the method terminates in step 1000.
  • all steps can proceed autonomously in the vehicle and be arranged in a corresponding manner in the ComBox or the OBU.
  • a network access rule set "NULL” / "CLOSED” / "DENY ALL” can be explicitly activated immediately after the start in step 100 in a step 200, not illustrated here, in order to eliminate any OTA Prevent communication prior to activation of the determined network access rule set in step 300.
  • FIG. 4 shows an exemplary method according to the invention according to a second embodiment. In this case, the method is started in step 100.
  • step 500 an initial network access rule set is activated. Thereafter, the current configuration of the vehicle and / or log data of the vehicle and / or the elapsed time since an update of a respective software to an evaluation server (VSSES) for determining the security status are transmitted in a step 600.
  • the result of the determination of the security status is received in step 700, whereupon in a step 800 a suitable network access rule set is determined.
  • the particular network access policy set is then activated in step 900. Subsequently, the method terminates in step 1000.
  • an evaluation takes place on an external server.
  • the method may be referred to as server-assisted evaluation.
  • FIG. 5 shows yet another exemplary method according to the invention according to a third embodiment.
  • the method is started in step 100.
  • a network access rule set "NULL” / "CLOSED” / "DENY ALL” can be explicitly activated in step 200 in order to prevent any OTA communication for the time being before the activated network access rule set is activated
  • Current vehicle security status determined in a step 300.
  • step 500 an initial network access rule set is activated.
  • step 600 Thereafter, current configuration of the vehicle and / or log data of the vehicle and / or an elapsed time since an update of a respective software is transmitted to an evaluation server (VSSES) for determining the safety status in a step 600.
  • VSSES evaluation server
  • the result of the determination of the security status is received in step 700, whereupon in a step 800 a suitable network access rule set is determined.
  • the particular network access rule set is then activated in step 900. Subsequently, the method terminates in step 1000.
  • This embodiment can be referred to as a multi-level query of the security status, wherein both evaluation can run autonomously in the vehicle and can be arranged in the ComBox or the OBU in the same way as well as an evaluation can take place on an external server.
  • FIG. 6 also shows an exemplary method according to the invention according to a fourth embodiment. In this case, the method is started in step 100.
  • a network access rule set "NULL” / "CLOSED” / "DENY ALL” can be explicitly activated in step 200 in order to prevent any OTA communication for the time being before the activation of the determined network access rule set. Subsequently, the current vehicle security status is determined in a step 300.
  • step 400 On the basis of the determined vehicle security status, it is determined in step 400 whether safety requirements have been met. If the requirements are met, in a step 900a a network access rule set is activated which activates the OTA communication. Subsequently, the method terminates in step 1000.
  • a server-assisted evaluation is initiated. This starts by activating an initial network access rule set in step 500. Thereafter, the current configuration of the vehicle and / or log data of the vehicle and / or the elapsed time since an update of a relevant software to an evaluation server (VSSES) to determine the security status in transmitted to a step 600. The result of the determination of the security status is received in step 700.
  • VSSES evaluation server
  • step 800 it is checked whether the received evaluation result is sufficient, ie it is determined which network access rule set is activated. If the result of the evaluation is sufficient to designate the system as safe, then in step 900a a network access rule set is activated which activates the OTA communication. Thereafter, the method terminates in step 1000. If the evaluation result is not sufficient to designate the system as secure, a network access rule set "NULL” / "CLOSED” / "DENY ALL" is explicitly activated in step 900b in order to eliminate any OTA To prevent communication from activating the determined network access rule set for the time being, the method then terminates in step 1000. That is, the server is requested only if the vehicle itself is "not secure,” if it is in a secure security status.
  • Figure 7 illustrates a message flow according to the invention, in accordance with an embodiment of the invention.
  • a vehicle configuration is determined in a first step 2100.
  • the communication interface is activated in the vehicle in a further step 2200.
  • This communication may include a plurality of messages exchanged between the communication interface and the security status determination device 14.
  • the determination may be made a security status can be activated by an appropriate e request is sent to the SEE.
  • This requirement can already include as parameters a current configuration of the vehicle and / or log data of the vehicle and / or an elapsed time since an update of the relevant software.
  • the SEE evaluates a configuration based on the obtained parameters, i. H. a security status, and provides this in a further step 26000 the vehicle.
  • the vehicle can now by a suitable device, for.
  • an access control device can activate a corresponding network access rule set for access to the data traffic network.
  • the vehicle configuration information can already be present in the Vehicle Security Status Evaluation Server (VSSES) or can be queried by a vehicle manager.
  • VSSES Vehicle Security Status Evaluation Server
  • FIG. 8 shows a schematic representation of a further embodiment of a system according to the invention. It is assumed that a vehicle has an on-board unit OBU which communicates with infrastructure servers via a communication device using different mobile radio systems.
  • OBU on-board unit
  • the Vehicle Manager VM is connected to or has a vehicle database VDB.
  • This database stores configuration information for vehicles managed by Vehicle Manager.
  • the communication or parts of the communication can take place via a Trusted Vehicle Online Communication Proxy (TVOCP).
  • TVOCP Trusted Vehicle Online Communication Proxy
  • VOS vehicle online service
  • This communication can be tunnelled between the vehicle and the TVOCP by, for. B. a VPN from the vehicle to the TVOCP is established.
  • the HTTPOCP can be implemented as an HTTP proxy for HTTP. Then no tunneling must be done, but HTTP requests can also be sent directly from the vehicle to the TVOCP, which - if necessary modified - to a destination server, eg. B. one VOS, forwards. The response to such a request can be transmitted from the target server VOS to the TVOCP, which can forward it - possibly modified again - to the vehicle.
  • the vehicle can authenticate itself to the TVOCP.
  • the TVOCP can then query the current configuration of the vehicle from the vehicle database VDB. This configuration is analyzed to determine whether B. current security patches are recorded. Depending on this, a network access rule set or several network access rule sets will be enforced for this vehicle.
  • This TVOCP is based on the evaluation, eg. Depending on the type of vehicle and the configuration of the vehicle, defined network access policy, d. That is, only the communication that is allowed by the defined network access rules is enabled. Other communication is blocked.
  • the vehicle can already transmit further information about itself (manufacturer, series, chassis number / VIN, configuration information).
  • the information about the vehicle can be requested by the TVOCP from a database;
  • information may be requested from a vehicle manager (VM) or from the database (VDB) used by the VM to store configuration information of a vehicle.
  • VM vehicle manager
  • VDB database
  • information about the software status of a particular vehicle is available here. In particular, it can be considered whether current software updates (critical security updates) have been recorded. If necessary, the VM can be triggered by the TVOCP to query the current configuration from the vehicle.
  • a TVOCP can also actively scan a vehicle to obtain information about the vehicle.
  • a network access rule can be determined by the TVOCP, which is enforced in the following communication of the vehicle.
  • a communication can optionally be redirected to another server, or the TVOCP responds proxy.
  • an HTTP request from the vehicle may be intercepted by the TVOCP and an HTTP REDIRECT message transmitted to the vehicle redirecting the vehicle client to another HTTP server. There can then z.
  • a web page may be displayed in HTML that informs the driver that the access has been blocked and why.
  • information can be transmitted to the vehicle by the TVOCP that the vehicle should contact the VM server. This can be done, for example, by inserting a special HTTP header into an HTTP response that is transmitted to the vehicle. This allows the VM server z. For example, transfer available software updates to the vehicle.
  • the TVOCP can transmit information to the VM server that the vehicle is currently online. For pending updates, the VM server can initiate a management session with the vehicle. By sending a trigger SMS message.
  • each application or protocol used may be re-and separate, with different network access policy sets for different applications and different approaches to security status detection coexisting.
  • the evaluation function can load the current configuration of the vehicle and / or the log data and / or the information about how long ago the last update was or when the last update was checked or if pending updates are also loaded and have been installed, check.
  • Updates can for example be played by a workshop. This can be z. B. via a workshop tester, which is connected via a diagnostic interface with the vehicle.
  • updates can also be made by the user himself, for. B. by means of update medium, z. CD / DVD, USB stick, memory card, etc., or by updating from one Update server via the radio communication interfaces are loaded (OTA Seif Update).
  • the vehicle communicates with a Vehicle Management Server (VM) to receive information about deployed updates and, if necessary, to load and install them.
  • VM Vehicle Management Server
  • network access rules can then be determined and activated for enforcement.
  • two network access rule sets can be defined (UNRESTRICTED, RESTRICTED). If the result of the evaluation is that the vehicle is in a safe configuration status (eg pending safety-critical updates have been checked and installed within the last 7 days), then the network access rule set UNRESTRICTED is activated (enables, for example, free , direct internet access). Otherwise, the network access rule set RESTRICTED is activated, in which only trusted web services offered directly by the vehicle manufacturer can be accessed.
  • the vehicle may transmit parameters to a Vehicle Security Status Evaluation Server (VSSES) or, more generally, a Security Status Investigation Facility (SEE) and in return receive an evaluation result ,
  • VSSES Vehicle Security Status Evaluation Server
  • SEE Security Status Investigation Facility
  • the transmitted parameters may include:
  • Identification of the vehicle eg VIN, VIN
  • Vehicle type information (manufacturer, model, year of manufacture, installed accessories), - configuration information (built-in components, software version),
  • VDB a database
  • OMA Open Mobile Al- liance
  • the evaluation result may include:
  • the Vehicle Security Status Evaluation Server is, for example, a server of the vehicle manufacturer or of a communications provider. Authentication takes place between server and vehicle.
  • the communication can z. B. be protected by IPSec, SSL or TLS protocol.
  • the information can z. Via HTTP, SOAP, OMA DM, SyncML, SNMP.
  • the VSSES is described as a self-contained unit, it may be included in other units. So the VSSES z. For example, it could be part of a VM server that might provide updates.
  • Some network access rule sets may be predefined, e.g. B .:
  • INFRASTRUCTRE allow any communication with infrastructure services (also direct), but not vehicle-to-vehicle communication;
  • - MANAGED INFRASTRUCTURE allow any (even direct) communication with infrastructure services, but only use mobile networks operated by a known infrastructure operator (eg only GPRS, UMTS / HSDPA via Vodafone, T-Mobile or Orange, but not WLAN);
  • a known infrastructure operator eg only GPRS, UMTS / HSDPA via Vodafone, T-Mobile or Orange, but not WLAN;
  • - TUNNEL Communication tunnels to Trusted Gateway (traffic is tunneled and sent to VPN servers where it can be parsed and filtered before being forwarded to, for example, an Internet server; Server is coming, will be further processed);
  • a network access rule set can also be provided by the Vehicle Security Status Evaluation Server (VSSES) or another server. It can also be fine granular network access rule sets are defined: It can, for. For example, content filtering can be performed to filter dangerous content for the car. For example, game, Flash content or JavaScripts on web pages are only allowed to pass if a particular vehicle has loaded the current security patches for the corresponding display programs.
  • VSSES Vehicle Security Status Evaluation Server
  • content filtering can be performed to filter dangerous content for the car.
  • game, Flash content or JavaScripts on web pages are only allowed to pass if a particular vehicle has loaded the current security patches for the corresponding display programs.
  • the content of a network access rule set may, for. For example, you may require the use of a firewall and a VPN.
  • a network access rule set consists of rules. These describe what type of network traffic is to be handled and how it is handled
  • - tunneling is (tunnel; encapsulate), d. H. is to be transmitted via a VPN tunnel;
  • restrictions may be imposed on permitted traffic, in particular restrictions on the maximum data rate, e.g. B. to prevent the overload of target components.
  • Possible filter criteria include:
  • Vehicle Manufacturer Vehicle Manufacturer, Model, Version / Year,
  • Target component in the vehicle ie to which control unit the data are forwarded or from which control unit they originate
  • - OTA interface GPRS, UMTS, WLAN, ...
  • - current OTA network operators eg T-Mobile, Vodafone, unknown
  • country Germany, France, ...
  • Protocol e.g., TCP, UDP
  • DoS denial of service
  • network access rules can also refer to content, the so-called content (web pages, multimedia files, program code):
  • Code Access Security is known, eg. For example, the Microsoft Common Language Runtime or the Java Runtime Environment.
  • Program code is granted access rights depending on its origin (ie depending on who signed it or from where it was loaded).
  • New Now, depending on the security evaluation, the entitlements granted to a particular code are set; or it is defined depending on the evaluation result whether a specific code can be executed at all. For example, in this way the execution of Untrusted Code / Downloaded 3rd Party Code can be prevented if the patch status of the vehicle component is not up-to-date.
  • the selected network access rule set is preferably enforced by the communication unit of the vehicle. Alternatively, this can also be done by a separate, upstream Si cherheitskommunikationsaku.
  • vehicle internal i board network by access control device (vehicle bus gate ways, control devices) filtering the communication.
  • the communication unit or the security communication unit can transmit information to this access control device via the vehicle security status (indicator, filter rules), thereby adapting its network access rules accordingly.
  • the respective component can also individually perform the described method.
  • the user should preferably receive an indication to install security patches in time or as soon as possible in order to be able to continue to use all services.
  • Vehicle components receive full access to the outside only at the current security update status of the software, since they can then fend off the attacks that occur from the network. This ensures reliable vehicle operation.

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

Beschreibung
SYSTEM UND VERFAHREN ZUR VERHINDERUNG EINES ANGRIFFS AUF EIN VERNETZTES FAHRZEUG
5 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.
10 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
15 drahtlose Anbindungen aus einem oder mehreren Datennetzen laden können.
Für die drahtlose Anbindung kann in Fahrzeugen eine Kommunikationsschnittstelle ( Communication Box, ComBox) eingebaut
20 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
25 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
30 Angriffen über die Kommunikationsschnittstelle ausgesetzt.
Deshalb benötigen vernetzte Fahrzeuge Schutzmaßnahmen, die
Angriffe über die Kommunikations schnittsteile auf das Fahrzeug verhindern.
35
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 Vor- richtungen 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 Sicherheits Status 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 Datenver- kehrsnetz 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:
Fig. 1 eine schematische Darstellung einer Ausführungsform eines erfindungsgemäßen Systems,
Fig. 2 einen Ausschnitt einer möglichen Anordnung von er findungsgemäßen Komponenten bezogen auf ein fahrzeuginternes Bussystem,
Fig. 3 ein beispielhaftes erfindungsgemäßes Verfahren ent sprechend einer ersten Ausführungsform,
Fig. 4 ein weiteres beispielhaftes erfindungsgemäßes Verfahren entsprechend einer zweiten Ausführungsform,
Fig. 5 ein weiteres beispielhaftes erfindungsgemäßes Verfahren entsprechend einer dritten Ausführungsform, Fig. 6 ein weiteres beispielhaftes erfindungsgemäßes Verfahren entsprechend einer vierten Ausführungsform,
Fig. 7 einen erfindungsgemäßen Nachrichtenfluss gemäß ei ner Ausführungsform der Erfindung,
Fig. 8 eine schematische Darstellung einer weiteren Aus führungsform eines erfindungsgemäßen Systems.
Figur 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. Figur 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 Info- tainment-System mit einer beispielhaften Head Unit, sowie beispielhaft mit zwei Einheiten für die hinteren Sitzplätze, sogenanntem Rear Seat Entertainment (RSEl, RSE2), angebunden. Statt Ethernet könnte hier auch z. B. MOST, Flexray oder je- der andere geeignete Bus eingesetzt werden.
Über ein Gateway (GW) sind zwei Steuergeräte ECUl, ECU2 verbunden, die über ein anderes Protokoll, z. B. das CAN-Proto- koll, kommunizieren können.
Die ComBox kann eine Network Access Enforcement Engine (NAEE) 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-Auswahlfunk- tion (NAPS) (Network Access Policy Selection), welche abhängig sein kann vom Ergebnis der Sicherheits-Selbst-Evaluierung (SSE). Weiterhin kann der Netzzugangsregelsatz auch von wei- teren 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 Sendeempfangs- einheiten, beschränkt bzw. beeinflusst. Sie kann eine Evaluierung des Sicherheitsstatus durchführen und kann einen Sicherheitsregelsatz ermitteln, den sie aktivieren und durch- setzen kann. Weiterhin kann sie optional auch die Konfiguration von Netzwerkkommunikationsfiltern (Firewall-Funktionen) weiterer Komponenten des Fahrzeugs über ein Steuerkommando ändern. Insbesondere kann sie ein Netzwerkkommunikationsfil- ter des Gateways (GW), einer Einheit des Infotainment-Systems (HU, RSEl, RSE2) oder eines Funkmoduls entsprechend ändern.
Figur 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 Fahr- zeug-Security-Status wird in Schritt 400 ein Netzzugangsre- gelsatz 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 Kom- munikation 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.
Figur 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 Fahr- zeugs und/oder Log-Daten des Fahrzeugs und/oder die verstrichene Zeit seit einem Update einer betreffenden Software an einen Evaluierungs Server (VSSES) zur Ermittlung des Sicherheitsstatus in einem Schritt 600 übertragen. Das Ergebnis der Ermittlung des Sicherheitsstatus wird in Schritt 700 empfan- gen, 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 Sicherheits Status-Überprüfung als Ergeb- nis ein Mindestmaß an Sicherheit im Ergebnis ermittelt, wird mit der Server-assisted Security Evaluation fortgefahren.
Figur 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 Akti- vierung 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 Figur 4 beschrieben fort, d. h., in einem Schritt 500 wird ein initialer Netz zugangsregelsatz 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 Sicherheitssta- tus in einem Schritt 600 übertragen. Das Ergebnis der Ermittlung des Sicherheitsstatus wird in Schritt 700 empfangen, woraufhin in einem Schritt 800 ein geeigneter Netzzugangsre- gelsatz bestimmt wird. Der bestimmte Netz zugangsregelsatz 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.
Figur 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 Akti- vierung 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-as sisted 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 Update einer betreffenden Software an einen Evaluierungsserver (VSSES) zur Ermittlung des Sicherheitsstatus in einem Schritt 600 übertragen. Das Ergebnis der Ermittlung des Sicherheits- Status 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 Evaluie- rungsergebnis 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 Sicherheits Status befindet. Figur 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 ei- nem 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 Kommunikati- onsschnittstelle und der Sicherheits status-Ermittlungs-Ein- richtung 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 be- reits 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 stel- len.
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 Netzzu- gangsregelsatz für den Zugang zum Datenverkehrsnetz aktivie- ren. 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.
Figur. 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 Communi- cation 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 Netzzu- gangsregelsä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 Netz zugangsregeln 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 Konfigurationsinforma- tion 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 Fahr- zeug ü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 Fahr- zeug ü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 ge- trennt durchgeführt werden kann, wobei unterschiedliche Netz- zugangsregelsä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 (Serverassisted Evaluation), oder aber beide zuvor genannten Mög- lichkeiten 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 Up- date 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 einge- spielt 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 vor- genommen werden, z. B. mittels Update-Medium, z. B. CD/DVD, USB-Stick, Speicherkarte, etc., oder indem Updates von einem Update-Server über die Funkkommunikations schnittsteile geladen werden (OTA Seif Update) .
Bei einem OTA Seif 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 Netz zugangsregeln ermittelt werden und diese zur Durchsetzung aktiviert werden.
Beispielsweise können zwei Netzzugangsregelsätze definiert sein (UNRESTRICTED, RESTRICTED) . Falls das Ergebnis der Eva- luierung 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-Zu- gang) . 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 (Ser- ver-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üglich OTA-Kommunikation, die so auf dem Server ausgewertet werden können) .
Es ist insbesondere ausreichend, lediglich eine Fahrzeug- Identifizierungsinformation zu übertragen, wenn in einem Ser- ver (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 Al- liance) DM Protokolls OTA verwaltet wird. Falls die Informa- tion 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 Netz zugangsregelsä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 eingetun- nelter Datenverkehr, der von diesem Server stammt, wird weiter bearbeitet) ;
- TRUSTED SERVER: nur Kommunikation mit Online-Diensten mög- lieh, 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 Bei- spiel 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 (Al- low) ;
- 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 Info- tainment-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 unver- schlü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 Netz zugangsre- gelsä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 Be rechtigungen, 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üh rung 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 Si cherheitskommunikationseinheit erfolgen .
In einer Variante kann darüber hinaus auch Fahrzeug-intern i Bord-Netz durch Zugangskontrolleinrichtung (Fahrzeugbus-Gate ways, Steuergeräte) eine Filterung der Kommunikation erfolgen. Die Kommunikationseinheit bzw. die Sicherheitskommunika tionseinheit kann dazu eine Information an diese Zugangskontrolleinrichtung über den Fahrzeug-Sicherheits Status übertra gen (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 vorzugswei se 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, er forderliche 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ön- nen 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ährleis- tet.

Claims

System zur Verhinderung eines Angriffs auf ein vernetz- tes Fahrzeug über eine drahtlose Kommunikationseinrichtung eines Fahrzeugs, umfassend:
- ein drahtloses Datenverkehrsnetz,
- eine Sicherheitsstatus-Ermittlungs-Einrichtung, um in Abhängigkeit eines ermittelten Sicherheits Status 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 Sicherheits status-Ermittlungs-Einrichtung verbindbar ist.
System nach Anspruch 1, wobei die Sicherheits status- Ermittlungs-Einrichtung im Fahrzeug angeordnet ist, und eine Evaluierung des Sicherheitsstatus autonom durchführbar ist.
System nach Anspruch 1, wobei die Sicherheits status- Ermittlungs-Einrichtung im Datenverkehrsnetz angeordnet ist .
System nach einem der Ansprüche 1 bis 3, wobei die Zugangskontrolleinrichtung im Fahrzeug angeordnet ist.
5. 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 Sicherheits Status .
Verfahren nach Anspruch 10, wobei ein Sicherheitsstatus sowohl lokal als auch remote ermittelt wird.
PCT/EP2011/052362 2010-02-22 2011-02-17 System und verfahren zur verhinderung eines angriffs auf ein vernetztes fahrzeug WO2011101414A1 (de)

Priority Applications (3)

Application Number Priority Date Filing Date Title
US13/580,658 US9843926B2 (en) 2010-02-22 2011-02-17 System and method for preventing an attack on a networked vehicle
EP11703708A EP2540053A1 (de) 2010-02-22 2011-02-17 System und verfahren zur verhinderung eines angriffs auf ein vernetztes fahrzeug
CN201180010608.7A CN102893574B (zh) 2010-02-22 2011-02-17 防止攻击联网车辆的系统和方法

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
DE102010008816.1 2010-02-22
DE102010008816A DE102010008816A1 (de) 2010-02-22 2010-02-22 Verfahren zur Online-Kommunikation

Publications (1)

Publication Number Publication Date
WO2011101414A1 true WO2011101414A1 (de) 2011-08-25

Family

ID=43904033

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/EP2011/052362 WO2011101414A1 (de) 2010-02-22 2011-02-17 System und verfahren zur verhinderung eines angriffs auf ein vernetztes fahrzeug

Country Status (5)

Country Link
US (1) US9843926B2 (de)
EP (1) EP2540053A1 (de)
CN (1) CN102893574B (de)
DE (1) DE102010008816A1 (de)
WO (1) WO2011101414A1 (de)

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN105704102A (zh) * 2014-11-26 2016-06-22 广州汽车集团股份有限公司 车辆网络访问控制方法及装置

Families Citing this family (34)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2012043167A1 (ja) * 2010-09-27 2012-04-05 日本電気株式会社 情報処理システム、車両のチェック方法、及び、車両のチェックプログラム
DE102012208205A1 (de) * 2012-05-16 2013-11-21 Bayerische Motoren Werke Aktiengesellschaft Datenlogging bzw. Stimulation in Automotiven Ethernet Netzwerken unter Verwendung der Fahrzeug-Infrastruktur
DE102013202064A1 (de) * 2013-02-08 2014-08-14 Bayerische Motoren Werke Aktiengesellschaft Verfahren und Vorrichtung zum Verbinden eines Diagnosegeräts mit einem Steuergerät in einem Kraftfahrzeug
DE102013003040B4 (de) 2013-02-22 2015-11-12 Audi Ag Kraftfahrzeug mit nachträglich per Anwendungsprogramm veränderbarem Fahrverhalten sowie Verfahren hierzu
US20140380296A1 (en) * 2013-06-20 2014-12-25 General Motors Llc Re-programming vehicle modules
EP3014853B1 (de) * 2013-06-25 2019-09-11 Fedex Corporation Transportkommunikationsverwaltung
US10885010B2 (en) 2013-12-18 2021-01-05 Federal Express Corporation Methods and systems for data structure optimization
US10140109B2 (en) * 2014-02-25 2018-11-27 Ford Global Technologies, Llc Silent in-vehicle software updates
WO2015159520A1 (ja) 2014-04-17 2015-10-22 パナソニック インテレクチュアル プロパティ コーポレーション オブ アメリカ 車載ネットワークシステム、不正検知電子制御ユニット及び不正検知方法
DE102014226831A1 (de) * 2014-12-22 2016-06-23 Continental Automotive Gmbh Vorrichtung zur Steuerung der drahtlosen Kommunikation eines Kraftfahrzeugs
WO2017024078A1 (en) * 2015-08-03 2017-02-09 Icon Labs A method for detecting, blocking and reporting cyber-attacks against automotive electronic control units
US10412088B2 (en) 2015-11-09 2019-09-10 Silvercar, Inc. Vehicle access systems and methods
DE102016201307A1 (de) * 2016-01-28 2017-08-03 Robert Bosch Gmbh Verfahren zum Melden eines Defekts eines Kraftfahrzeugs
DE102016204999A1 (de) * 2016-03-24 2017-09-28 Volkswagen Aktiengesellschaft Verfahren zur Überwachung der Sicherheit von Kommunikationsverbindungen eines Fahrzeugs
DE102016205002A1 (de) * 2016-03-24 2017-09-28 Volkswagen Aktiengesellschaft Verfahren zum Verwalten von gesammelten Fahrzeugdaten
DE102016205132A1 (de) * 2016-03-29 2017-10-05 Robert Bosch Gmbh Vorrichtung und Verfahren zur Filterung eines Datentransfers, sowie ein Gateway-Steuergerät
JP6485429B2 (ja) * 2016-11-04 2019-03-20 トヨタ自動車株式会社 車載ネットワークシステム
EP3382976A1 (de) * 2017-03-30 2018-10-03 Siemens Aktiengesellschaft Schutzeinrichtung, verfahren und gerät enthalten eine schutzeinrichtung zum schutz eines mit dem gerät verbundenen kommunikationsnetzwerks
DE102017208712A1 (de) * 2017-05-23 2018-11-29 Siemens Aktiengesellschaft Kommunikationsanordnung sowie Verfahren zu deren Betrieb
US10625754B2 (en) * 2017-08-10 2020-04-21 Sumitomo Electric Industries, Ltd. Control apparatus, control method, and computer program
US10679493B2 (en) * 2017-09-18 2020-06-09 International Business Machines Corporation Cognitive-based incident response
US10802483B2 (en) * 2017-10-19 2020-10-13 International Business Machines Corporation Emergency public deactivation of autonomous vehicles
DE102017219770B4 (de) 2017-11-07 2019-06-19 Continental Automotive Gmbh Verfahren zum Betreiben einer Ethernet-Kommunikationseinrichtung und Ethernet-Kommunikationseinrichtung
JP6552674B1 (ja) * 2018-04-27 2019-07-31 三菱電機株式会社 検査システム
DE102018130588B4 (de) * 2018-11-30 2020-12-03 DE-CIX Management GmbH Computerimplementiertes Verfahren zur Abwehr oder Abmilderung von DDoS-Angriffen auf IT-Infrastrukturen
CN110290496A (zh) * 2019-06-17 2019-09-27 高新兴物联科技有限公司 一种v2x升级系统及升级方法
DE102019120331A1 (de) * 2019-07-26 2021-01-28 itemis France SAS Datenübertragung zu einem IOT-Gerät
FR3101745A1 (fr) * 2019-10-08 2021-04-09 Psa Automobiles Sa Procédé d’accès à un service connecté depuis un véhicule automobile
US11704106B2 (en) * 2019-11-08 2023-07-18 Toyota Jidosha Kabushiki Kaisha Program update system and vehicle management server
DE102020216065A1 (de) 2019-12-20 2021-06-24 Robert Bosch Gesellschaft mit beschränkter Haftung Vorrichtung mit einer Schnittstelle und Verfahren zum Betreiben einer Vorrichtung mit einer Schnittstelle
DE102019220450A1 (de) * 2019-12-20 2021-06-24 Robert Bosch Gmbh Vorrichtung mit einer Schnittstelle und Verfahren zum Betreiben einer Vorrichtung mit einer Schnittstelle
EP3869471A1 (de) * 2020-02-24 2021-08-25 Continental Automotive GmbH Kommunikationsverfahren mit einem server und einer vielzahl von bordeinheiten und bordeinheit
GB2602369B (en) * 2020-12-23 2023-04-19 Motional Ad Llc Security gateway
CN114973700B (zh) * 2022-05-18 2024-03-26 浙江嘉兴数字城市实验室有限公司 一种基于车路协同应用的信号机网联安全装置及工作方法

Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2001026338A2 (en) * 1999-10-06 2001-04-12 Sensoria Corporation Apparatus for remote access of vehicle components
FR2880225A1 (fr) * 2004-12-23 2006-06-30 Toplica Petkovic Dispositif d'aide a la prevention des accidents de la circulation lies a l'utilisation du telephone portable
US20090212928A1 (en) * 2005-06-15 2009-08-27 Volkswagen Ag Method and Device for Secure Communication of a Component of a Vehicle with an External Communication Partner via a Wireless Communication Link

Family Cites Families (28)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US6144859A (en) * 1993-08-27 2000-11-07 Aeris Communications, Inc. Wireless cellular communicator system and apparatus
US6052646A (en) * 1998-04-15 2000-04-18 Magellan Dis, Inc. Vehicle navigation system with improved powerup performance
US6647270B1 (en) * 1999-09-10 2003-11-11 Richard B. Himmelstein Vehicletalk
US6389337B1 (en) * 2000-04-24 2002-05-14 H. Brock Kolls Transacting e-commerce and conducting e-business related to identifying and procuring automotive service and vehicle replacement parts
JP2002127873A (ja) * 2000-10-27 2002-05-09 Auto Network Gijutsu Kenkyusho:Kk 自動車盗難防止用照合システム
US7987510B2 (en) * 2001-03-28 2011-07-26 Rovi Solutions Corporation Self-protecting digital content
US7061367B2 (en) * 2002-04-30 2006-06-13 General Electric Company Managing access to physical assets
US6832141B2 (en) * 2002-10-25 2004-12-14 Davis Instruments Module for monitoring vehicle operation through onboard diagnostic port
US20040263316A1 (en) * 2003-06-24 2004-12-30 Case, Llc Reprogrammable vehicle access control system
US7355299B2 (en) * 2003-07-29 2008-04-08 Lear Corporation Non-ignition switch vehicle ignition enabling system
US7716726B2 (en) 2004-02-13 2010-05-11 Microsoft Corporation System and method for protecting a computing device from computer exploits delivered over a networked environment in a secured communication
JP4270031B2 (ja) * 2004-06-09 2009-05-27 株式会社デンソー 車載用情報登録・開示システム、車載装置および携帯機器
US7418317B2 (en) * 2005-03-10 2008-08-26 Aai Corporation System and method for controlling and communicating with a vehicle
US20060224305A1 (en) * 2005-04-01 2006-10-05 Siemens Vdo Automotive Corporation Vehicle unit for controlling communications between a vehicle and a wireless device
EP1873650A4 (de) * 2005-04-21 2010-11-10 Mitsubishi Electric Corp Computer, verfahren zur regelung des zugangs zu computerbetriebsmitteln und zugangssteuerprogramm
JP5162103B2 (ja) * 2006-05-15 2013-03-13 トヨタ自動車株式会社 支援制御装置
US20080027602A1 (en) * 2006-05-30 2008-01-31 Yeap Tet H System and method for deterring theft of vehicles and other products having integral computer means
DE102006042974B4 (de) * 2006-09-13 2009-07-23 Continental Automotive Gmbh Verfahren zur Zugangssteuerung zu einem Fahrzeug
US8274377B2 (en) * 2007-01-10 2012-09-25 Decision Sciences International Corporation Information collecting and decision making via tiered information network systems
JP5138949B2 (ja) * 2007-02-07 2013-02-06 日立オートモティブシステムズ株式会社 車載ゲートウェイ装置
US8319605B2 (en) * 2007-06-19 2012-11-27 Magna Electronics, Inc. Remote vehicle control system utilizing multiple antennas
US7970381B2 (en) 2007-08-13 2011-06-28 General Motors Llc Method of authenticating a short message service (sms) message
DE102007044398B4 (de) * 2007-09-18 2012-10-04 Continental Automotive Gmbh Diebstahlschutzsystem für ein Fahrzeug und Verfahren zum Betreiben eines Diebstahlschutzsystems
JP2009163430A (ja) * 2007-12-28 2009-07-23 Sony Corp セキュリティ機能搭載車載機器及び車載機器のセキュリティ機能制御方法
CN101262333B (zh) 2008-04-21 2010-06-02 上海大学 一种车辆网络中节点间的安全通信方法
US20090300365A1 (en) * 2008-05-30 2009-12-03 Robert Karmes Vehicle Diagnostic System Security with Memory Card
US8370644B2 (en) * 2008-05-30 2013-02-05 Spansion Llc Instant hardware erase for content reset and pseudo-random number generation
US20100087981A1 (en) * 2008-10-02 2010-04-08 Daniel Guadalupe Orozco-Perez Versatile vehicular care assistant system and method

Patent Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2001026338A2 (en) * 1999-10-06 2001-04-12 Sensoria Corporation Apparatus for remote access of vehicle components
FR2880225A1 (fr) * 2004-12-23 2006-06-30 Toplica Petkovic Dispositif d'aide a la prevention des accidents de la circulation lies a l'utilisation du telephone portable
US20090212928A1 (en) * 2005-06-15 2009-08-27 Volkswagen Ag Method and Device for Secure Communication of a Component of a Vehicle with an External Communication Partner via a Wireless Communication Link

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN105704102A (zh) * 2014-11-26 2016-06-22 广州汽车集团股份有限公司 车辆网络访问控制方法及装置

Also Published As

Publication number Publication date
DE102010008816A1 (de) 2011-08-25
CN102893574B (zh) 2018-05-18
US9843926B2 (en) 2017-12-12
EP2540053A1 (de) 2013-01-02
US20130104186A1 (en) 2013-04-25
CN102893574A (zh) 2013-01-23

Similar Documents

Publication Publication Date Title
WO2011101414A1 (de) System und verfahren zur verhinderung eines angriffs auf ein vernetztes fahrzeug
WO2006133774A1 (de) Verfahren und vorrichtung zum sicheren kommunizieren einer komponente eines fahrzeugs über eine drahtlose kommunikationsverbindung mit einem externen kommunikationspartner
DE112019000485T5 (de) System und verfahren zum bereitstellen der sicherheit für einfahrzeuginternes netzwerk
EP1518383A1 (de) Verfahren und vorrichtung zum senden und/oder zum empfang von informationen in verbindung mit einem fahrzeug
WO2014044348A1 (de) Teilnehmeridentitätsmodul zum authentisieren eines teilnehmers an einem kommunikationsnetzwerk
DE102017119373A1 (de) Aktualisierung der servers der netzwerkadresse der mobilvorrichtung
EP2529529A1 (de) Verfahren zum gesicherten download von verteilten downloadsourcen
DE102018131480A1 (de) System und verfahren zum leiten einer vernetzten vorrichtung zu einer fahrzeugintern gespeicherten landing-page basierend auf einem verfügbaren guthaben oder einem datensaldo
WO2017162395A1 (de) Verfahren zur überwachung der sicherheit von kommunikationsverbindungen eines fahrzeugs
DE102016222741A1 (de) Verfahren für ein Kommunikationsnetzwerk und elektronische Kontrolleinheit
DE102014206545A1 (de) Verfahren, Kommunikationssystem und Daten-Zugangsknoten zur Übermittlung von Daten
WO2017167490A1 (de) Reduzieren einer angriffsmöglichkeit auf eine schwachstelle eines gerätes über eine netzwerkzugangsstelle
DE102016008957B4 (de) Direkter Zugriff auf Bussignale in einem Kraftfahrzeug
EP3895406B1 (de) Verfahren zum betreiben eines datennetzwerks eines kraftfahrzeugs und kraftfahrzeug mit einem entsprechend betreibbaren datennetzwerk
DE102020119153A1 (de) Fahrzeugcomputersystem
EP1473614A2 (de) Computersystem für ein Fahrzeug und Verfahren zum Kontrollieren des Datenverkehrs in einem solchen Computersystem
DE102019201133B4 (de) Kraftfahrzeug
DE102019220157A1 (de) Verfahren zur Sicherheitsüberprüfung, Sicherheitsüberprüfungsvorrichtung, Informationssystem für ein Kraftfahrzeug, Kraftfahrzeug
DE102021207870A1 (de) Verfahren und Recheneinheit zum Verwalten von Diagnoseanfragen in einem Netzwerk
DE102019220164A1 (de) Verfahren zur Sicherheitsüberprüfung, Sicherheitsüberprüfungsvorrichtung, Informationssystem, Kraftfahrzeug
WO2015124240A1 (de) System und verfahren für einen datenaustausch zwischen mindestens einem fahrzeug und mindestens einem mobilen endgerät
DE102023106929A1 (de) Fahrzeugvariantenbewusste dienste
EP4250146A1 (de) Interaktion physischer entitäten
DE102022113106A1 (de) Datenschutzkonfiguration in einem Datensystem für Fahrzeuge
WO2021197822A1 (de) Verfahren zur behandlung einer anomalie von daten, insbesondere bei einem kraftfahrzeug

Legal Events

Date Code Title Description
WWE Wipo information: entry into national phase

Ref document number: 201180010608.7

Country of ref document: CN

121 Ep: the epo has been informed by wipo that ep was designated in this application

Ref document number: 11703708

Country of ref document: EP

Kind code of ref document: A1

REEP Request for entry into the european phase

Ref document number: 2011703708

Country of ref document: EP

WWE Wipo information: entry into national phase

Ref document number: 2011703708

Country of ref document: EP

NENP Non-entry into the national phase

Ref country code: DE

WWE Wipo information: entry into national phase

Ref document number: 13580658

Country of ref document: US