WO2017024078A1 - A method for detecting, blocking and reporting cyber-attacks against automotive electronic control units - Google Patents
A method for detecting, blocking and reporting cyber-attacks against automotive electronic control units Download PDFInfo
- Publication number
- WO2017024078A1 WO2017024078A1 PCT/US2016/045431 US2016045431W WO2017024078A1 WO 2017024078 A1 WO2017024078 A1 WO 2017024078A1 US 2016045431 W US2016045431 W US 2016045431W WO 2017024078 A1 WO2017024078 A1 WO 2017024078A1
- Authority
- WO
- WIPO (PCT)
- Prior art keywords
- vehicle
- vehicle bus
- firewall
- electrical control
- control unit
- Prior art date
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/02—Network architectures or network communication protocols for network security for separating internal from external traffic, e.g. firewalls
- H04L63/0227—Filtering policies
- H04L63/0236—Filtering by address, protocol, port number or service, e.g. IP-address or URL
-
- B—PERFORMING OPERATIONS; TRANSPORTING
- B60—VEHICLES IN GENERAL
- B60R—VEHICLES, VEHICLE FITTINGS, OR VEHICLE PARTS, NOT OTHERWISE PROVIDED FOR
- B60R25/00—Fittings or systems for preventing or indicating unauthorised use or theft of vehicles
- B60R25/30—Detection related to theft or to other events relevant to anti-theft systems
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F21/00—Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
- G06F21/50—Monitoring users, programs or devices to maintain the integrity of platforms, e.g. of processors, firmware or operating systems
- G06F21/55—Detecting local intrusion or implementing counter-measures
- G06F21/554—Detecting local intrusion or implementing counter-measures involving event detection and direct action
-
- 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/02—Network architectures or network communication protocols for network security for separating internal from external traffic, e.g. firewalls
- H04L63/0209—Architectural arrangements, e.g. perimeter networks or demilitarized zones
-
- 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
- H04L63/1441—Countermeasures against malicious traffic
-
- 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
- H04L67/125—Protocols specially adapted for proprietary or special-purpose networking environments, e.g. medical networks, sensor networks, networks in vehicles or remote metering networks involving control of end-device applications over a network
-
- B—PERFORMING OPERATIONS; TRANSPORTING
- B60—VEHICLES IN GENERAL
- B60R—VEHICLES, VEHICLE FITTINGS, OR VEHICLE PARTS, NOT OTHERWISE PROVIDED FOR
- B60R2325/00—Indexing scheme relating to vehicle anti-theft devices
- B60R2325/10—Communication protocols, communication systems of vehicle anti-theft devices
- B60R2325/106—Internet
-
- B—PERFORMING OPERATIONS; TRANSPORTING
- B60—VEHICLES IN GENERAL
- B60R—VEHICLES, VEHICLE FITTINGS, OR VEHICLE PARTS, NOT OTHERWISE PROVIDED FOR
- B60R25/00—Fittings or systems for preventing or indicating unauthorised use or theft of vehicles
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F2221/00—Indexing scheme relating to security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
- G06F2221/21—Indexing scheme relating to G06F21/00 and subgroups addressing additional information or applications relating to security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
- G06F2221/2101—Auditing as a secondary aspect
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L12/00—Data switching networks
- H04L12/28—Data switching networks characterised by path configuration, e.g. LAN [Local Area Networks] or WAN [Wide Area Networks]
- H04L12/40—Bus networks
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L12/00—Data switching networks
- H04L12/66—Arrangements for connecting between networks having differing types of switching systems, e.g. gateways
-
- 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
- H04L63/1408—Network architectures or network communication protocols for network security for detecting or protecting against malicious traffic by monitoring network traffic
- H04L63/1425—Traffic logging, e.g. anomaly detection
Definitions
- This disclosure relates to automotive security, and more specifically, to devices, systems, and methods for protecting automotive electronic control units from cyber- attacks.
- This disclosure relates to automotive security, and more specifically, to devices, systems, and methods for protecting automotive electronic control units from cyber- attacks.
- An electronic control unit is a generic term for an embedded structure that controls one or more electrical structures or substructures within a transport vehicle. Due to the increasing complexity of automotive control schemes, to execute various vehicle control requirements ECUs must have the capability to connect to a number of external communication platforms. These external communication platforms include, for example, Wi-Fi, Ethernet, On- Board Diagnostics Generation Two (OBD-II), GPS, or Telematics. As each ECU in the automotive control scheme receives data packets from external communications platforms and internal sensors, it sends the data packets to a central network within the vehicle, composed of a vehicle bus or vehicle buses. Generally, automotive ECUs are composed of three main architectures.
- These architectures include (1) complex architectures, such as infotainment ECUs, (2) gateway architectures, which serve as a gateway between external communication platforms and the vehicle bus or vehicle buses, and (3) chain architectures, in which an automotive control scheme with multiple vehicle buses may forward data packets from one vehicle bus to another, for example an ECU forwarding data packets from a critical or operational vehicle bus to a non- critical vehicle bus.
- complex architectures such as infotainment ECUs
- gateway architectures which serve as a gateway between external communication platforms and the vehicle bus or vehicle buses
- chain architectures in which an automotive control scheme with multiple vehicle buses may forward data packets from one vehicle bus to another, for example an ECU forwarding data packets from a critical or operational vehicle bus to a non- critical vehicle bus.
- an automotive control scheme with multiple vehicle buses may forward data packets from one vehicle bus to another, for example an ECU forwarding data packets from a critical or operational vehicle bus to a non- critical vehicle bus.
- two or even all three of these architectures may be present, and
- a protection system used to protect automotive electronic control units from cyber-attacks.
- the presently disclosed protection system improves upon the prior art by adapting automobile ECU structures to relay data packets to the protection system, which is adapted to regulate and control these structures.
- the protection system disclosed herein uses a processing system to control the flow of data packets from various automotive components. Depending upon the state of the vehicle (be it driving, parked, etc.), or the desire of the user (to use an infotainment component, for example), the data packets allow the ECU to control certain automotive control schemes. If the software on the ECU is compromised by an attack, such as a cyber-attack, breach, or other malfunction, or if the automotive control scheme is targeted by an attack over one of the external communication platforms in communication with the ECUs, the presently disclosed protection system will identify the attack as the data packet containing the attack is passed through the vehicle bus firewall. The vehicle bus firewall will then look up and select a filtering rule based on the state of the vehicle and the data packet identity, blocking any attacks to the automotive control scheme.
- an attack such as a cyber-attack, breach, or other malfunction
- the automotive control scheme is targeted by an attack over one of the external communication platforms in communication with the ECUs
- the presently disclosed protection system will identify the attack as the data packet
- a system of one or more computers can be configured to perform particular operations or actions by virtue of having software, firmware, hardware, or a combination of each installed on the system.
- One or more computer programs can be configured to perform particular operations or actions by virtue of including instructions that, when executed by data processing apparatus, cause the apparatus to perform the actions.
- Example 1 relates to a method of protecting ECU signaling from cyber-attacks originating within complex ECU processing.
- Example 2 relates to a method of protecting single purpose ECU processing.
- Example 3 relates to a method of protecting ECU signaling using CAN bridge/firewall processing.
- Example 4 relates to a method of protecting ECU signaling from cyberattacks occurring via a Gateway ECU using CAN bus firewall processing.
- Example 5 relates to a method for logging event notifications by a CAN firewall.
- FIG. 14 Other embodiments include corresponding computer systems, apparatus, and computer programs recorded on one or more computer storage devices, each configured to perform the actions of the disclosed protection systems.
- FIG. 1 is a schematic overview of an automotive control scheme
- FIG. 2 is a schematic overview depicting automotive control scheme vulnerability prior to implementation of present invention
- FIG. 3 is a schematic overview depicting an automotive control scheme with protection system in place.
- FIG. 4 is a schematic of the two essential aspects of the protection system
- FIG. 5 is a schematic of an overview of a segregated vehicle bus protection system and method.
- FIG. 6 is a schematic of an overview of a secure gateway protection system and method.
- FIG. 7 is a schematic of an overview of a bidirectional filtering secure ECU protection system and method.
- FIG. 8 is a schematic of an overview of a hybrid gateway/firewall vehicle bus protection system and method.
- FIG. 9 is a schematic of an overview of an infotainment ECU system.
- FIG. 10 is a schematic of an overview of a single purpose ECU protection system and method.
- FIG. 11 is a schematic of an overview of a vehicle bus bridge ECU protection system and method.
- FIG. 12 is a schematic of an overview of an aftermarket ECU firewall.
- FIG. 13 is a schematic of an overview of an aftermarket add-on vehicle bus firewall.
- FIG. 14 is a schematic of an overview of a vehicle bus firewall filtering vehicle bus bridge program.
- FIG. 15 is a schematic of an overview of a vehicle bus firewall filtering for a complex ECU program.
- FIG. 16 is a schematic of an overview of a vehicle bus firewall filtering for a gateway ECU program.
- FIG. 17 is a schematic of an overview of a vehicle bus firewall single purpose
- FIG. 18 is a schematic of an overview of a message logging and reporting program.
- FIG. 19 is a schematic of an overview of an OBD-II MSG firewall program.
- the disclosed devices, systems, and methods relate to a protection system used to protect automotive electronic control units from cyber- attacks. Described herein are various embodiments relating to systems and methods for protecting various ECU processing functions. More specifically, the embodiments include methods, systems, and devices, for controlling the flow of the signals, or "messages" each ECU is allowed to send or to process. If the software on the ECU is compromised by an attack, such as a cyber-attack, breach, or other malfunction, the disclosed system will identify the attack as the data packet containing the attack is passed through the vehicle bus firewall. The vehicle bus firewall will look up and identify a filtering rule based on the data packet identity, and will block any attacks to the automotive control scheme. While multiple embodiments, including various gateway, firewall, and ECU devices, systems, and methods are described herein as "protection system," this is in no way intended to be restrictive.
- vehicle bus would be understood by a person of skill in the art to encompass any variety of vehicle bus systems.
- vehicle bus protocols may include, but are not limited to, CAN, LIN, and FlexRay.
- a typical automotive control scheme 400 uses ECU 402 and vehicle bus 404 communication as the primary communication method. These processes can comprise a variety of optional steps.
- the ECU 402 receives inputs 406.
- the ECU processes the data in data packets 408.
- the data packets 408 are sent to the vehicle bus 404.
- the vehicles bus 404 receives the data packets 408 and sends a vehicle bus message 410 to each ECU 402 based on the data packet 408 and the function performed by that ECU.
- Vehicle bus messages 410 do not contain any address information, so when the ECU 402 receives the message 410 there is no way to identify which ECU 402 the message 410 came from or which ECU 402 was supposed to receive the message.
- a valid driver action reference arrow A
- a message sent as the result of an attack reference arrow B
- some ECUs 402 receive inputs 406 from external communication platforms, for example an OBD-II ECU. Inputs 406 from external communication platforms are sometimes desirable, for example when performing diagnostics the OBD-II port must use the vehicle bus 404 to send messages 410 through the vehicle. In other situations, however, inputs 406 from external communications platforms can be an attack (here, reference arrow C) instead of a valid input 406. In these situations, it is desirable to block inputs 406 from external communication platforms. As shown in FIG. 3, the disclosed protection system 100 identifies these attacks (reference arrows B, C) and filters them (shown at reference arrow D), preventing the attack commands from being sent to other ECUs through vehicle bus messages 410.
- the vehicle bus firewall 412 will periodically send a vehicle bus message (reference arrow H) to ECUs 402 to determine the state of the vehicle.
- “periodically” might mean 1-10 times per second, and the ECUs send response messages (reference arrow I) to the vehicle bus firewall 412, which monitors the responses for updated vehicle status information.
- the vehicle status might include, but is not limited to, current vehicle speed, vehicle gear status, and braking status.
- the vehicle bus firewall may determine vehicle state by interpreting messages sent through the firewall by various ECUs.
- the ECUs 402 send all vehicle bus message responses (reference arrow L, FIG. 1 at 408) through vehicle bus firewall 412 before sending the approved messages (reference arrow N) to the vehicle bus 404.
- the vehicle bus firewall 10 has at least three vehicle bus filtering rules: BLOCK, ALLOW, and LOG.
- BLOCK vehicle bus filtering rules
- the vehicle bus firewall 412 will determine which one of the rules to apply based on the processing commands assigned to the firewall.
- the processing commands determine the vehicle bus filtering rules based on the vehicle status (called "context") and the message identity. If the filtering rule is BLOCK, the vehicle bus firewall 412 will prevent the message (FIG. 1 at 8) from being sent on to the vehicle bus 404 and a "message blocked" event will be logged.
- the vehicle bus firewall 412 will allow the message (FIG. 1 at 8) to be sent to the vehicle bus 404 and no event will be logged. If the filtering rule is LOG, the vehicle bus firewall 412 will allow the message (FIG. 1 at 8) to be sent to the vehicle bus 404 and a "message logged" event will be recorded.
- exemplary embodiments of the protection system 100 comprise a vehicle bus firewall 412 which will utilize a set of context-based vehicle filtering rules. These rules define an action for each unique context and vehicle bus message response (FIG. 1 at 8). An example of this processing command can be seen in Table 1.
- the expected vehicle bus response messages (FIG. 1 at 8) for a given context and identity can be defined during the engineering stage of the automobile and the information, in turn, can be used to program the processing commands.
- FIGS. 5-13 Exemplary configurations of the various components and filtering firewalls can be seen in FIGS. 5-13. Accordingly, the flow of information between various components of the vehicle's electronic system can be controlled and otherwise regulated, as is shown in FIGS. 14- 19.
- the critical and non-critical features are separated from one another by at least one firewall, the firewall being configured to have access to a library of rules and states, and further being configured to apply the rules to control access from a non-critical component to a critical one.
- the protection system is able to prevent the non-critical system from accessing critical features, such as the antilock brakes.
- the vehicle bus firewall in a single-purpose ECU typically performs two main actions. First, the vehicle bus firewall will periodically send a vehicle bus message to determine the state of the vehicle (for example 1-10 times per second). This can include current vehicle speed, and may include additional information such as vehicle gear status (e.g., park, drive, reverse, etc.). Additional information such as vehicle braking status may be included. This information can be recorded as the vehicle state.
- vehicle gear status e.g., park, drive, reverse, etc.
- Additional information such as vehicle braking status may be included. This information can be recorded as the vehicle state.
- a minimum of three states are maintained (stopped, parked and moving). Also, all vehicle bus messages to this ECU are passed through a vehicle bus firewall on the ECU receiving the message and before the messages are processed by the ECU.
- the vehicle bus firewall in these embodiments has at least three vehicle bus filtering actions. These three vehicle bus filtering actions are BLOCK, ALLOW, and LOG. The vehicle bus firewall will determine which one of these actions to perform based on the information the vehicle bus firewall is programmed to look up. Additionally, in various embodiments, the vehicle bus firewall has access to a library of rules, and looks up the vehicle bus filtering rule based on the state of the vehicle (context) and the message ID.
- the filtering rule action is BLOCK
- the vehicle bus firewall will require the message to NOT be processed by the ECU and a "message blocked" event will be logged.
- the filtering rule action is ALLOW
- the vehicle bus firewall will require the message to be processed by the ECU and no event will be logged.
- the filtering rule action is LOG, the vehicle bus firewall will require the message to be processed by the ECU and a "message logged" event will be logged.
- FIG. 1 Another variation of the protection system is vehicle bus bridge/firewall processing in embodiments where an ECU that is bridging vehicle bus traffic between two or more vehicle buses needs to perform bi-directional filtering based upon the vehicle state (context).
- different filtering rules are applied depending upon the direction of the traffic, such that there is a first set of filtering rules for vehicle bus messages being sent from the critical to the non-critical vehicle bus, and a second set of rules for non- critical to critical vehicle bus messages.
- the vehicle bus firewall will typically perform two main actions. First, the vehicle bus firewall will again periodically send a vehicle bus message to determine the state of the vehicle.
- This information will be recorded as the vehicle state, with a minimum of three states maintained (stopped, parked and moving).
- All vehicle bus messages to this ECU are passed through a vehicle bus firewall before being sent to the vehicle bus.
- the vehicle bus firewall in these embodiments has at least three CAN bus filtering actions. These three CAN bus filtering actions are BLOCK, ALLOW, and LOG. The CAN bus firewall will determine which one of these actions to perform based on the information the CAN bus firewall is programmed to look up.
- the vehicle bus firewall looks up the vehicle bus filtering rule based on the state of the vehicle (context) and the message ID and the direction of the message. If the filtering rule action is BLOCK, the vehicle bus firewall will require the message to NOT be sent on to the vehicle bus and a "message blocked" event will be logged. Alternately, if the filtering rule action is ALLOW, the vehicle bus firewall will require the message to be sent on the vehicle bus and no event will be logged. Finally, if the filtering rule action is LOG, the vehicle bus firewall will require the message to be sent on the vehicle bus and a "message logged" event will be logged.
- An ECU gateway provides communication from one or more external interfaces, such as cellular data, GPS, Wi-Fi, OBD-II, Ethernet, etc., to the vehicle. Some of the external communication interfaces require access to the vehicle bus to perform actions, such as remotely unlocking car doors via a telematics system, or to gather information, such as vehicle speed and mileage for fleet management systems. In these embodiments, different filtering rules are applied depending upon the interface that the message was received on (OBD-II port vs. Wi-Fi or cellular data). As such, the vehicle bus firewall in a vehicle bus gateway ECU will perform two main actions.
- the vehicle bus firewall will once again periodically send a vehicle bus message to determine the state of the vehicle, in a fashion similar to that described above with respect to other embodiments.
- all vehicle bus messages to this ECU are passed through the vehicle bus firewall before being sent to the vehicle bus.
- the vehicle bus firewall in these embodiments has at least three vehicle bus filtering actions. These three vehicle bus filtering actions are BLOCK, ALLOW, and LOG.
- the vehicle bus firewall will determine which one of these actions to perform based on the information the vehicle bus firewall is programmed to look up.
- the vehicle bus firewall looks up the vehicle bus filtering rule based on the state of the vehicle (context) and the message ID and the interface on which the message was received.
- the vehicle bus firewall will require the message to NOT be sent on the vehicle bus and a "message blocked" event will be logged.
- the filtering rule action is ALLOW, the vehicle bus firewall will require the message to be sent on the vehicle bus and no event will be logged.
- the filtering rule action is LOG, the vehicle bus firewall will require the message to be sent on the vehicle bus and a "message logged" event will be recorded.
- the protection system further addresses logging event notifications by a vehicle bus firewall.
- a vehicle bus firewall logs an event
- a new vehicle bus message type is generated to report this event.
- this event can be sent to a telematics unit that will forward the event to a telematics operations center. Additionally, this event can also be sent to the dashboard ECU which can signal the driver via a dashboard display. Further explanation of these various embodiments of the protection system are explained in detail in relation to the drawings.
- the system 100 differentiates between critical systems, examples of which include anti-lock brakes ECU 10, engine control ECU 12 and stability control ECU 14, and non-critical systems, examples of which are tire-pressure monitoring systems ECU ("TPMS") 16, infotainment ECU 18, telematics ECU 20 and diagnostics ECU 22.
- TPMS tire-pressure monitoring systems
- the critical system has a critical system vehicle bus 24 that is distinct from the non-critical system vehicle bus 26.
- these two vehicle buses 24 and 26 are in electronic communication via the vehicle bus firewall 28, such that they are only able to communicate with one another when the firewall permits.
- the protection system 100 uses a secure gateway ECU protection system.
- the secure gateway ECU protection system can include one or more outside system connection components, such as Wi-Fi 34, cellular data 36, GPS 38, Ethernet 40, and USB 42. These connection components are in electronic communication with the secure automotive gateway 44.
- This secure automotive gateway 44 is in electronic communication with the vehicle bus 46.
- the secure automotive gateway 44 determines, based on the vehicle bus filtering rules, when actions sent by the various types of connections are sent to the vehicle bus and when they are blocked.
- the protection system 100 features bidirectional filtering for secure ECU protection.
- the automotive system 100 might include, for example, an antilock brake ECU 50 and an infotainment ECU 52.
- these components are protected by one or more firewalls 54, 56, and in turn, the firewalls 54, 56 are in direct electronic communication with the vehicle bus 58.
- the firewalls 54, 56 determine when the signals from the ECUs 50, 52 are sent onto the vehicle bus , when they are blocked. Further, the firewalls 54, 56 determine when the signals from the vehicle bus 58 are sent to the ECUs 50, 52 and when they are blocked.
- the protection system 100 features a hybrid gateway/firewall vehicle bus protection system.
- this protection system includes one or more outside system connection components, such as Wi- Fi 62, cellular data 64, GPS 66, Ethernet 68, and USB 70. These components are in communication with the secure automotive gateway 72.
- the secure automotive gateway 72 is in communication with the vehicle bus for non-critical systems 74, which in turn is in communication with the firewall 76.
- the vehicle bus for non-critical systems 74 is in turn in communication with the vehicle bus for critical systems 78. This structure is beneficial because it adds additional protection between the non-critical vehicle bus 74 and the critical vehicle bus 78.
- the secure automotive gateway 72 determines, based on the vehicle bus filtering rules, when actions sent by the various types of connections are sent to the vehicle bus for non- critical systems 74, to the vehicle bus for critical systems 78, and when they are blocked.
- the firewall 76 only allows communication between the two vehicle buses 74, 78 when the programmed filtering rule is ALLOW.
- the protection system 100 might feature an infotainment ECU system.
- the protected memory space 82 contains the context-based vehicle bus filtering rules 84, which are in turn in communication with the vehicle bus firewall 86.
- the vehicle bus firewall 86 is in communication with the vehicle bus 88.
- the vehicle bus firewall 86 is additionally in communication with other infotainment apps, for example an audio player 90 or other infotainment apps 92. These apps are controlled through an external interface 94.
- the audio player 90 and other infotainment apps 92 provide the vehicle bus firewall 86 with appropriate information.
- the vehicle bus firewall 86 will perform the appropriate function and either send the information onto the vehicle bus 88 or block the information from being sent.
- the protected memory space 82 ensures that if an application, such as the audio player 90, is compromised by a cyber-attack, the compromised application cannot disrupt the processing of the vehicle bus firewall 86.
- the protection system 100 might comprise a single purpose ECU protection system.
- a single control function processing unit 102 is in communication with the vehicle bus firewall 104.
- the vehicle bus firewall 104 is additionally in communication with the context-based vehicle bus filtering rules 106 and the vehicle bus 108.
- the control function processing unit 102 then provides the vehicle bus firewall 104 the information needed to determine which vehicle bus filtering rule to apply, as given by the context-based vehicle bus filter rules 106.
- the vehicle bus firewall 104 then applies the appropriate vehicle bus filtering rule 106 and either passes the information onto the vehicle bus 108 to perform the appropriate function or blocks the information from being sent.
- the protection system 100 might feature a vehicle bus bridge ECU protection system.
- the two separate vehicle bus firewalls 112, 114 are in communication with each other.
- the first vehicle bus firewall 112 is governed by the first context-based vehicle bus filtering rules 116.
- the second vehicle bus firewall 114 is governed by the second context-based vehicle bus filtering rules 118.
- the first vehicle bus firewall 112 is in communication with the critical vehicle bus 120, and the second vehicle bus firewall 114 is in communication with the non- critical vehicle bus 122.
- the two firewall systems allow for multi-level protection based on the appropriate information contained in both firewalls 112, 114 and both context-based vehicle bus filtering rules 116, 118.
- the protection systems can then allow the first and second firewalls, 112 and 114, respectively, to determine which systems are critical, for example anti-lock brakes, and which systems are non-critical, for example satellite radio.
- the first vehicle bus firewall 112 if it is a critical system, the first vehicle bus firewall 112 will look up the necessary information based on vehicle state and message ID and then apply the appropriate vehicle bus filtering rule based on this determination. In further embodiments, this vehicle bus filtering rule the firewall will either send the information to the critical vehicle bus 120 or block the information from being sent.
- the second vehicle bus firewall 114 will perform the same process for non-critical systems based on the second context-based vehicle bus filtering rules 118.
- the protection system 100 may feature an aftermarket ECUfirewall.
- an external communication platform such as an OBD-II Interface 126, connected to an aftermarket ECU firewall 128 and then connected to an OBD-II port 130 that goes into the vehicle 132.
- the OBD-II port 130 is also connected to the OBD-II ECU 134, which is in communication with the vehicle's vehicle bus 136.
- the vehicle's vehicle bus 136 is optionally in further connected with numerous ECUs 138.
- the OBD-II port 130 is the physical component that allows external devices to be connected to a vehicle for the purpose of allowing service personnel to diagnose issues and extract information for servicing a vehicle.
- the aftermarket ECU firewall 128 provides protection from abuse of this OBD-II port capability.
- the aftermarket ECU firewall 128 is in communication with an OBD-II interface 126 that can be utilized by the external devices.
- the internal OBD-II ECU 134 and the other various ECUs 138 are protected from a cyber-attack through the OBD-II port by the aftermarket ECU firewall 128.
- the protection system could be implemented as an aftermarket add-on vehicle bus firewall embodiment.
- an external interface 142 might be in communication with an event log 144.
- the event log 144 could be in further communication with an OBD-II firewall 146.
- an OBD-II interface 148 could be in communication with an external OBD-II port 150, which in turn is communication with an OBD-II firewall 152.
- This OBD-II firewall 152 can be controlled by the OBD-II filtering rules 154.
- the OBD-II firewall 152 is in communication with an internal OBD-II port 156 connected to the vehicle 132.
- FIG. 13 shows a more detailed example of the protection system 100 in FIG. 12.
- FIG. 14 shows an exemplary embodiment of the protection system 100 featuring the process utilized by the vehicle bus firewall filtering vehicle bus bridge 162. This process is utilized in a number of disclosed embodiments, and specifically in the first and second vehicle bus firewalls 112 and 114 of FIG. 7.
- first bus 164 receives a vehicle bus message (block 168) or second bus 166 receiving a vehicle bus message (block 170).
- the process for CAN bus messages then flows to the block that extracts the identifier extension IDE bit from the CAN MSG header ("HDR") (block 172). Based on this extracted data, the process then asks whether the IDE bit is set (block 174). If the answer is yes, the process then extracts the 29-bit message ID from the CAN MSG HDR (block 176). If the answer is no, the process then extracts the 11 -bit message ID from the CAN MSG HDR (block 178). Regardless of which bit is extracted, in the case of CAN bus messages, or if the message is received on another type of vehicle bus the process the asks whether the message ID is in the set of messages with status information (block 180).
- the process uses the message ID, vehicle status and bus ID message received to look up the filtering action in the appropriate vehicle bus filtering table (block 184). Based on the result that is returned by the vehicle bus filtering table the filtering action is performed (block 186). If the filtering action is Log & Allow (block 188), the message is first logged (block 190) and then continues on the path described for the filtering result for Allow (block 192). If the filtering result is Block & Log (block 194) the message will be logged (block 196) and the process will begin again.
- the protection system 100 features the process utilized by the vehicle bus firewall filtering for a complex ECU 212, for example,, an infotainment ECU.
- the series of optional steps begins with one of the tasks 124, such as the audio player task, which attempts to send an internal message.
- the internal message is translated into a vehicle bus message of various possible vehicle bus messages that are to be transmitted onto the vehicle bus, which first encounters the vehicle bus firewall (such as the vehicle bus firewall 86 shown in FIG. 9).
- vehicle bus messages are received as a vehicle bus message on the vehicle bus (block 216).
- the task 214 message is reformatted into a vehicle bus message before it is received (block 216).
- the process then extracts the IDE bit from the CAN MSG HDR (block 218).
- the process then asks if the IDE bit is set (block 220). If the answer is yes, the process extracts a 29-bit MSG ID from the CAN MSG HDR (block 222). If the answer is no, the process extracts an 11-bit MSG ID from the CAN MSG HDR (block 224), or the appropriate message ID from the MSG HDR if the message is received on a different type of vehicle bus. Regardless of this choice, the process for these exemplary embodiments then uses the task ID, MSG ID and vehicle status to lookup the filtering action in the vehicle bus filtering table (block 226).
- the vehicle bus filtering table provides the firewall with three filtering actions (block 228). If the filtering action is Block & Log 230, then the message is logged (block 232). If the action is Log & Allow (block 234), then the message is logged (block 236) and then the message is sent on to the vehicle bus (block 238). If the action is Allow (block 240), then the message is sent on to the vehicle bus (block 238).
- the firewall is running two additional questions. The first question is whether the vehicle status has expired (block 244). If the answer is no then process delays for a predefined period before it then loops and asks the question again (block 244). If the answer is yes, a message is sent to request the vehicle status (block 246).
- the second question is whether there a vehicle status message (block 250). If the answer is no, the process loops until a vehicle bus message is received (block 252). If the answer is yes, then the vehicle status is updated (block 254) and the process is looped until a vehicle bus message is received (block 252). [059] Continuing with FIG. 16, in certain exemplary embodiments of the protection system 100, the process is utilized by the vehicle bus firewall filtering for a gateway ECU 260. The disclosed process is utilized by a number of disclosed embodiments, and specifically by firewall 76 in FIG. 8 and by firewall 44 in FIG. 6. These exemplary embodiments run the same process described for FIG. 15, but instead of tasks sending internal messages that are translated into vehicle bus messages, external communication platforms, such as WiFi or cellular data, are sending messages. Additionally, to receive a vehicle bus message (block 263) the gateway ECU reformats the interface 262 messages into vehicle bus messages when they are received (block 263).
- the process features the vehicle bus firewall for a single purpose ECU 266.
- the disclosed process is utilized by a number of disclosed embodiments, and specifically by vehicle bus firewall 104 in FIG. 10. These exemplary embodiments run a similar process as shown in FIG. 14, except there is only one bus 268. As a result, there is only one bus to receive the vehicle bus message (block 270) and no transmission on a second bus is necessary. Additionally, instead of forwarding the vehicle bus message, as in (block 198) in FIG. 14, the ECU accepts/processes the vehicle bus message (block 272).
- FIG. 18 is a further exemplary embodiment of the protection system 100 featuring the process utilized by the message logging and reporting system 276.
- the disclosed process is utilized in a number of disclosed embodiments, and specifically by first and second vehicle bus firewalls 112 and 114 in FIG. 11, vehicle bus firewall 104 in FIG. 10, and vehicle bus firewall 86 in FIG. 9.
- the firewall message and action are received and the action is chosen as described in FIGS. 14 and 15.
- the additional step is that the process logs and stores messages in the log (block 278), and sends them to the Telematics Operations Center (TOC) (block 286).
- TOC Telematics Operations Center
- the process then asks if it is a critical message (block 280).
- the protection system 100 features the process utilized by the OBD-II message firewall 292.
- the disclosed process is utilized in a number of disclosed embodiments, and specifically in the OBD-II firewall 152 in FIG. 13.
- exemplary embodiments utilize a series of optional steps by which a message is received on the external port (block 294).
- the message ID is then extracted (block 296).
- the process uses the message ID and vehicle status lookup filtering action in the OBD-II filtering table (block 298) to determine the filtering action (block 300). If the filtering action is Block & Log 310, the message is logged (block 312). If the action is Log & Allow (block 302), the message is logged (block 304) and then the process follows the same process as if the message were allowed (block 306). If the action is Allow (block 306), then the message is sent to the internal OBD-II Port (block 308). The process then asks if the vehicle status is expired (block 314).
- the process waits until another message is received on the external port (block 294). If the answer is yes, the process sends a status received message on the internal port (block 316) and then waits for the process to receive another message on the external port (block 294). At the same time, the process is continually running a question based on whether there is a vehicle status message (block 320). If the answer is yes, the vehicle status information is updated (block 322) and then the message is sent to the external port (block 324). If the answer is no, then the message is sent to the external port (block 324) without updated vehicle status information (block 322). Regardless of the action, the process then loops until a message is received on the internal port and this message is extracted (block 326). The question (block 320) is then asked again by the process.
Landscapes
- Engineering & Computer Science (AREA)
- Computer Security & Cryptography (AREA)
- Computer Hardware Design (AREA)
- Computing Systems (AREA)
- General Engineering & Computer Science (AREA)
- Computer Networks & Wireless Communication (AREA)
- Signal Processing (AREA)
- Software Systems (AREA)
- Theoretical Computer Science (AREA)
- Health & Medical Sciences (AREA)
- Medical Informatics (AREA)
- General Health & Medical Sciences (AREA)
- Physics & Mathematics (AREA)
- General Physics & Mathematics (AREA)
- Mechanical Engineering (AREA)
- Small-Scale Networks (AREA)
Abstract
The disclosed apparatus, systems and methods relate to protecting automotive electronic control units from cyber-attacks.
Description
A METHOD FOR DETECTING, BLOCKING AND REPORTING CYBER-ATTACKS AGAINST AUTOMOTIVE ELECTRONIC CONTROL UNITS
CROSS-REFERENCE TO RELATED APPLICATIONS )
[001 ] This application claims priority under 35 U.S.C. § 119(e) to United States Patent
Application 62/200,550, filed August 3, 2015 and entitled "A Method For Detecting, Blocking And Reporting Cyber-Attacks Against Automotive Electronic Control Units," which is incorporated herein in its entirety by this reference.
TECHNICAL FIELD
[002] This disclosure relates to automotive security, and more specifically, to devices, systems, and methods for protecting automotive electronic control units from cyber- attacks.
BACKGROUND
[003] This disclosure relates to automotive security, and more specifically, to devices, systems, and methods for protecting automotive electronic control units from cyber- attacks.
[004] An electronic control unit ("ECU") is a generic term for an embedded structure that controls one or more electrical structures or substructures within a transport vehicle. Due to the increasing complexity of automotive control schemes, to execute various vehicle control requirements ECUs must have the capability to connect to a number of external communication platforms. These external communication platforms include, for example, Wi-Fi, Ethernet, On- Board Diagnostics Generation Two (OBD-II), GPS, or Telematics. As each ECU in the automotive control scheme receives data packets from external communications platforms and internal sensors, it sends the data packets to a central network within the vehicle, composed of a vehicle bus or vehicle buses. Generally, automotive ECUs are composed of three main architectures. These architectures include (1) complex architectures, such as infotainment ECUs, (2) gateway architectures, which serve as a gateway between external communication platforms and the vehicle bus or vehicle buses, and (3) chain architectures, in which an automotive control scheme with multiple vehicle buses may forward data packets from one vehicle bus to another, for example an ECU forwarding data packets from a critical or operational vehicle bus to a non- critical vehicle bus. In a modern vehicle, two or even all three of these architectures may be
present, and the same automotive control scheme may contain two or more complex architectures.
[005] As a result of the nature of external communication platforms and the complexity of ECU architectures, automotive ECUs have become a target for cyber- attacks. Often, multiple supported external communication platforms are in communication with ECUs, which in turn have access to the central communications network within the automotive control scheme. While this interconnectivity produces desirable results for automobile consumers, it also creates a growing attack surface for hackers to exploit. The increasing vulnerability to attacks is further complicated by the complex ECU architectures, like infotainment ECUs. An infotainment ECU requires access to the vehicle bus to, for example, determine vehicle speed and thereby provide speed sensitive volume control, among other capabilities. Complex architectures use software systems such as Linux, Android and Java, which all provide rich attack vectors. Because the complex architectures provide direct access to the vehicle bus, a software vulnerability in the audio player of an infotainment ECU also creates the potential to use remote code execution to send attacks through the vehicle bus. This would allow hackers to exploit a variety of imperative functions within the automotive control scheme while the vehicle is in use, such as the antilock brakes or steering systems. Thus, there is a need in the art for improved methods and systems for protecting automotive ECUs from cyber- attacks.
BRIEF SUMMARY
[006] Disclosed herein is a protection system used to protect automotive electronic control units from cyber-attacks. The presently disclosed protection system improves upon the prior art by adapting automobile ECU structures to relay data packets to the protection system, which is adapted to regulate and control these structures.
[007] The protection system disclosed herein uses a processing system to control the flow of data packets from various automotive components. Depending upon the state of the vehicle (be it driving, parked, etc.), or the desire of the user (to use an infotainment component, for example), the data packets allow the ECU to control certain automotive control schemes. If the software on the ECU is compromised by an attack, such as a cyber-attack, breach, or other malfunction, or if the automotive control scheme is targeted by an attack over one of the external
communication platforms in communication with the ECUs, the presently disclosed protection system will identify the attack as the data packet containing the attack is passed through the vehicle bus firewall. The vehicle bus firewall will then look up and select a filtering rule based on the state of the vehicle and the data packet identity, blocking any attacks to the automotive control scheme.
[008] A system of one or more computers can be configured to perform particular operations or actions by virtue of having software, firmware, hardware, or a combination of each installed on the system. One or more computer programs can be configured to perform particular operations or actions by virtue of including instructions that, when executed by data processing apparatus, cause the apparatus to perform the actions.
[009] Example 1 relates to a method of protecting ECU signaling from cyber-attacks originating within complex ECU processing.
[010] Example 2 relates to a method of protecting single purpose ECU processing.
[011 ] Example 3 relates to a method of protecting ECU signaling using CAN bridge/firewall processing.
[012] Example 4 relates to a method of protecting ECU signaling from cyberattacks occurring via a Gateway ECU using CAN bus firewall processing.
[013] Example 5 relates to a method for logging event notifications by a CAN firewall.
[014] Other embodiments include corresponding computer systems, apparatus, and computer programs recorded on one or more computer storage devices, each configured to perform the actions of the disclosed protection systems.
[015] While multiple embodiments, including various gateway, firewall, and ECU devices, systems, and methods are described herein as a "protection system," this is in no way intended to be restrictive. Additionally, while multiple embodiments are disclosed, still other embodiments of the disclosure will become apparent to those skilled in the art from the following detailed description, which shows and describes illustrative embodiments of the disclosed apparatus, systems and methods. As will be realized, the disclosed apparatus, systems and methods are capable of modifications in various obvious aspects, all without departing from the spirit and scope of the disclosure. Accordingly, the drawings and detailed description are to be regarded as illustrative in nature and not restrictive.
BRIEF DESCRIPTION OF THE DRAWINGS
[016] FIG. 1 is a schematic overview of an automotive control scheme
[017] FIG. 2 is a schematic overview depicting automotive control scheme vulnerability prior to implementation of present invention
[018] FIG. 3 is a schematic overview depicting an automotive control scheme with protection system in place.
[019] FIG. 4 is a schematic of the two essential aspects of the protection system
[020] FIG. 5 is a schematic of an overview of a segregated vehicle bus protection system and method.
[021 ] FIG. 6 is a schematic of an overview of a secure gateway protection system and method.
[022] FIG. 7 is a schematic of an overview of a bidirectional filtering secure ECU protection system and method.
[023] FIG. 8 is a schematic of an overview of a hybrid gateway/firewall vehicle bus protection system and method.
[024] FIG. 9 is a schematic of an overview of an infotainment ECU system.
[025] FIG. 10 is a schematic of an overview of a single purpose ECU protection system and method.
[026] FIG. 11 is a schematic of an overview of a vehicle bus bridge ECU protection system and method.
[027] FIG. 12 is a schematic of an overview of an aftermarket ECU firewall.
[028] FIG. 13 is a schematic of an overview of an aftermarket add-on vehicle bus firewall.
[029] FIG. 14 is a schematic of an overview of a vehicle bus firewall filtering vehicle bus bridge program.
[030] FIG. 15 is a schematic of an overview of a vehicle bus firewall filtering for a complex ECU program.
[031 ] FIG. 16 is a schematic of an overview of a vehicle bus firewall filtering for a gateway ECU program.
[032] FIG. 17 is a schematic of an overview of a vehicle bus firewall single purpose
ECU program.
[033] FIG. 18 is a schematic of an overview of a message logging and reporting program.
[034] FIG. 19 is a schematic of an overview of an OBD-II MSG firewall program.
DETAILED DESCRIPTION
[035] The disclosed devices, systems, and methods relate to a protection system used to protect automotive electronic control units from cyber- attacks. Described herein are various embodiments relating to systems and methods for protecting various ECU processing functions. More specifically, the embodiments include methods, systems, and devices, for controlling the flow of the signals, or "messages" each ECU is allowed to send or to process. If the software on the ECU is compromised by an attack, such as a cyber-attack, breach, or other malfunction, the disclosed system will identify the attack as the data packet containing the attack is passed through the vehicle bus firewall. The vehicle bus firewall will look up and identify a filtering rule based on the data packet identity, and will block any attacks to the automotive control scheme. While multiple embodiments, including various gateway, firewall, and ECU devices, systems, and methods are described herein as "protection system," this is in no way intended to be restrictive.
[036] Additionally, in various embodiments the term "vehicle bus" would be understood by a person of skill in the art to encompass any variety of vehicle bus systems. For example, common vehicle bus protocols may include, but are not limited to, CAN, LIN, and FlexRay.
[037] As shown in FIG. 1, a typical automotive control scheme 400 uses ECU 402 and vehicle bus 404 communication as the primary communication method. These processes can comprise a variety of optional steps. First, the ECU 402 receives inputs 406. The ECU processes the data in data packets 408. The data packets 408 are sent to the vehicle bus 404. The vehicles bus 404 receives the data packets 408 and sends a vehicle bus message 410 to each ECU 402 based on the data packet 408 and the function performed by that ECU. Vehicle bus messages 410 do not contain any address information, so when the ECU 402 receives the message 410 there is
no way to identify which ECU 402 the message 410 came from or which ECU 402 was supposed to receive the message. As shown in FIG. 2, this creates a problem because the ECU 402 receiving the message 410 cannot distinguish between a message 410 that was the result of a valid data packet 408, created by a valid driver action (reference arrow A) (such as applying breaks), and a message sent as the result of an attack (reference arrow B).
[038] Additionally, some ECUs 402 receive inputs 406 from external communication platforms, for example an OBD-II ECU. Inputs 406 from external communication platforms are sometimes desirable, for example when performing diagnostics the OBD-II port must use the vehicle bus 404 to send messages 410 through the vehicle. In other situations, however, inputs 406 from external communications platforms can be an attack (here, reference arrow C) instead of a valid input 406. In these situations, it is desirable to block inputs 406 from external communication platforms. As shown in FIG. 3, the disclosed protection system 100 identifies these attacks (reference arrows B, C) and filters them (shown at reference arrow D), preventing the attack commands from being sent to other ECUs through vehicle bus messages 410.
[039] As shown in FIG. 4, in exemplary embodiments of the protection system 100 there are two essential aspects. First, the vehicle bus firewall 412 will periodically send a vehicle bus message (reference arrow H) to ECUs 402 to determine the state of the vehicle. In various embodiments, "periodically" might mean 1-10 times per second, and the ECUs send response messages (reference arrow I) to the vehicle bus firewall 412, which monitors the responses for updated vehicle status information. In certain embodiments, the vehicle status might include, but is not limited to, current vehicle speed, vehicle gear status, and braking status. In other embodiments, the vehicle bus firewall may determine vehicle state by interpreting messages sent through the firewall by various ECUs. Second, the ECUs 402 send all vehicle bus message responses (reference arrow L, FIG. 1 at 408) through vehicle bus firewall 412 before sending the approved messages (reference arrow N) to the vehicle bus 404. In exemplary embodiments, the vehicle bus firewall 10 has at least three vehicle bus filtering rules: BLOCK, ALLOW, and LOG. The vehicle bus firewall 412 will determine which one of the rules to apply based on the processing commands assigned to the firewall. The processing commands determine the vehicle bus filtering rules based on the vehicle status (called "context") and the message identity. If the filtering rule is BLOCK, the vehicle bus firewall 412 will prevent the message (FIG. 1 at 8) from being sent on to the vehicle bus 404 and a "message blocked" event will be logged. If the
filtering rule is ALLOW, the vehicle bus firewall 412 will allow the message (FIG. 1 at 8) to be sent to the vehicle bus 404 and no event will be logged. If the filtering rule is LOG, the vehicle bus firewall 412 will allow the message (FIG. 1 at 8) to be sent to the vehicle bus 404 and a "message logged" event will be recorded.
[040] Accordingly, exemplary embodiments of the protection system 100 comprise a vehicle bus firewall 412 which will utilize a set of context-based vehicle filtering rules. These rules define an action for each unique context and vehicle bus message response (FIG. 1 at 8). An example of this processing command can be seen in Table 1.
Table 1: Filtering rules based on context
[041 ] The expected vehicle bus response messages (FIG. 1 at 8) for a given context and identity can be defined during the engineering stage of the automobile and the information, in turn, can be used to program the processing commands.
[042] Exemplary configurations of the various components and filtering firewalls can be seen in FIGS. 5-13. Accordingly, the flow of information between various components of the vehicle's electronic system can be controlled and otherwise regulated, as is shown in FIGS. 14- 19. In each of these embodiments, the critical and non-critical features are separated from one another by at least one firewall, the firewall being configured to have access to a library of rules and states, and further being configured to apply the rules to control access from a non-critical component to a critical one. For example, should an infotainment system, such as a Wi-Fi connected audio player, be compromised by an attack, the protection system is able to prevent the non-critical system from accessing critical features, such as the antilock brakes.
[043] Various embodiments of the protection system address single purpose ECU processing. For single -purpose ECUs performing control functions, there is less concern about
vulnerabilities on the ECU being exploited by cyber-attacks causing malicious messages to be sent from the single purpose ECU to the other ECUs in the vehicle. Accordingly, the vehicle bus firewall in a single-purpose ECU typically performs two main actions. First, the vehicle bus firewall will periodically send a vehicle bus message to determine the state of the vehicle (for example 1-10 times per second). This can include current vehicle speed, and may include additional information such as vehicle gear status (e.g., park, drive, reverse, etc.). Additional information such as vehicle braking status may be included. This information can be recorded as the vehicle state. In exemplary embodiments, a minimum of three states are maintained (stopped, parked and moving). Also, all vehicle bus messages to this ECU are passed through a vehicle bus firewall on the ECU receiving the message and before the messages are processed by the ECU. The vehicle bus firewall in these embodiments has at least three vehicle bus filtering actions. These three vehicle bus filtering actions are BLOCK, ALLOW, and LOG. The vehicle bus firewall will determine which one of these actions to perform based on the information the vehicle bus firewall is programmed to look up. Additionally, in various embodiments, the vehicle bus firewall has access to a library of rules, and looks up the vehicle bus filtering rule based on the state of the vehicle (context) and the message ID. If the filtering rule action is BLOCK, the vehicle bus firewall will require the message to NOT be processed by the ECU and a "message blocked" event will be logged. Alternately, the filtering rule action is ALLOW, the vehicle bus firewall will require the message to be processed by the ECU and no event will be logged. Finally, if the filtering rule action is LOG, the vehicle bus firewall will require the message to be processed by the ECU and a "message logged" event will be logged.
[044] Another variation of the protection system is vehicle bus bridge/firewall processing in embodiments where an ECU that is bridging vehicle bus traffic between two or more vehicle buses needs to perform bi-directional filtering based upon the vehicle state (context). In these embodiments, different filtering rules are applied depending upon the direction of the traffic, such that there is a first set of filtering rules for vehicle bus messages being sent from the critical to the non-critical vehicle bus, and a second set of rules for non- critical to critical vehicle bus messages. In these embodiments, the vehicle bus firewall will typically perform two main actions. First, the vehicle bus firewall will again periodically send a vehicle bus message to determine the state of the vehicle. This will include, at a minimum, current vehicle speed, and may include additional information such as vehicle gear status (park,
drive, reverse, etc.). Additional information such as vehicle braking status may optionally be included. This information will be recorded as the vehicle state, with a minimum of three states maintained (stopped, parked and moving). Second, all vehicle bus messages to this ECU are passed through a vehicle bus firewall before being sent to the vehicle bus. The vehicle bus firewall in these embodiments has at least three CAN bus filtering actions. These three CAN bus filtering actions are BLOCK, ALLOW, and LOG. The CAN bus firewall will determine which one of these actions to perform based on the information the CAN bus firewall is programmed to look up. In these embodiments, the vehicle bus firewall looks up the vehicle bus filtering rule based on the state of the vehicle (context) and the message ID and the direction of the message. If the filtering rule action is BLOCK, the vehicle bus firewall will require the message to NOT be sent on to the vehicle bus and a "message blocked" event will be logged. Alternately, if the filtering rule action is ALLOW, the vehicle bus firewall will require the message to be sent on the vehicle bus and no event will be logged. Finally, if the filtering rule action is LOG, the vehicle bus firewall will require the message to be sent on the vehicle bus and a "message logged" event will be logged.
[045] Another aspect of the protection system relates to protecting ECU signaling from cyber-attacks occurring via a gateway architecture using vehicle bus firewall processing. An ECU gateway provides communication from one or more external interfaces, such as cellular data, GPS, Wi-Fi, OBD-II, Ethernet, etc., to the vehicle. Some of the external communication interfaces require access to the vehicle bus to perform actions, such as remotely unlocking car doors via a telematics system, or to gather information, such as vehicle speed and mileage for fleet management systems. In these embodiments, different filtering rules are applied depending upon the interface that the message was received on (OBD-II port vs. Wi-Fi or cellular data). As such, the vehicle bus firewall in a vehicle bus gateway ECU will perform two main actions. First, the vehicle bus firewall will once again periodically send a vehicle bus message to determine the state of the vehicle, in a fashion similar to that described above with respect to other embodiments. Second, all vehicle bus messages to this ECU are passed through the vehicle bus firewall before being sent to the vehicle bus. The vehicle bus firewall in these embodiments has at least three vehicle bus filtering actions. These three vehicle bus filtering actions are BLOCK, ALLOW, and LOG. The vehicle bus firewall will determine which one of these actions to perform based on the information the vehicle bus firewall is programmed to look up. The vehicle
bus firewall looks up the vehicle bus filtering rule based on the state of the vehicle (context) and the message ID and the interface on which the message was received. If the filtering rule action is BLOCK, the vehicle bus firewall will require the message to NOT be sent on the vehicle bus and a "message blocked" event will be logged. Alternately, if the filtering rule action is ALLOW, the vehicle bus firewall will require the message to be sent on the vehicle bus and no event will be logged. Finally, if the filtering rule action is LOG, the vehicle bus firewall will require the message to be sent on the vehicle bus and a "message logged" event will be recorded.
[046] In alternate embodiments, the protection system further addresses logging event notifications by a vehicle bus firewall. In these embodiments, when a vehicle bus firewall logs an event, a new vehicle bus message type is generated to report this event. In further embodiments this event can be sent to a telematics unit that will forward the event to a telematics operations center. Additionally, this event can also be sent to the dashboard ECU which can signal the driver via a dashboard display. Further explanation of these various embodiments of the protection system are explained in detail in relation to the drawings.
[047] In various embodiments, shown in FIG. 5, the system 100 differentiates between critical systems, examples of which include anti-lock brakes ECU 10, engine control ECU 12 and stability control ECU 14, and non-critical systems, examples of which are tire-pressure monitoring systems ECU ("TPMS") 16, infotainment ECU 18, telematics ECU 20 and diagnostics ECU 22. In certain embodiments, the critical system has a critical system vehicle bus 24 that is distinct from the non-critical system vehicle bus 26. In further embodiments, these two vehicle buses 24 and 26 are in electronic communication via the vehicle bus firewall 28, such that they are only able to communicate with one another when the firewall permits.
[048] In further embodiments, shown in FIG. 6, the protection system 100 uses a secure gateway ECU protection system. In exemplary embodiments, the secure gateway ECU protection system can include one or more outside system connection components, such as Wi-Fi 34, cellular data 36, GPS 38, Ethernet 40, and USB 42. These connection components are in electronic communication with the secure automotive gateway 44. This secure automotive gateway 44 is in electronic communication with the vehicle bus 46. The secure automotive gateway 44 determines, based on the vehicle bus filtering rules, when actions sent by the various types of connections are sent to the vehicle bus and when they are blocked.
[049] In certain embodiments, shown in FIG. 7,the protection system 100 features bidirectional filtering for secure ECU protection. In this embodiment, the automotive system 100 might include, for example, an antilock brake ECU 50 and an infotainment ECU 52. In these embodiments, these components are protected by one or more firewalls 54, 56, and in turn, the firewalls 54, 56 are in direct electronic communication with the vehicle bus 58. As in other embodiments, the firewalls 54, 56 determine when the signals from the ECUs 50, 52 are sent onto the vehicle bus , when they are blocked. Further, the firewalls 54, 56 determine when the signals from the vehicle bus 58 are sent to the ECUs 50, 52 and when they are blocked.
[050] Continuing on to FIG. 8, in various embodiments the protection system 100 features a hybrid gateway/firewall vehicle bus protection system. In exemplary embodiments, this protection system includes one or more outside system connection components, such as Wi- Fi 62, cellular data 64, GPS 66, Ethernet 68, and USB 70. These components are in communication with the secure automotive gateway 72. In turn, the secure automotive gateway 72 is in communication with the vehicle bus for non-critical systems 74, which in turn is in communication with the firewall 76. Finally, the vehicle bus for non-critical systems 74 is in turn in communication with the vehicle bus for critical systems 78. This structure is beneficial because it adds additional protection between the non-critical vehicle bus 74 and the critical vehicle bus 78. The secure automotive gateway 72 determines, based on the vehicle bus filtering rules, when actions sent by the various types of connections are sent to the vehicle bus for non- critical systems 74, to the vehicle bus for critical systems 78, and when they are blocked. The firewall 76 only allows communication between the two vehicle buses 74, 78 when the programmed filtering rule is ALLOW.
[051 ] In further embodiments, shown in FIG. 9, the protection system 100 might feature an infotainment ECU system. In exemplary embodiments, the protected memory space 82 contains the context-based vehicle bus filtering rules 84, which are in turn in communication with the vehicle bus firewall 86. Further, the vehicle bus firewall 86 is in communication with the vehicle bus 88. The vehicle bus firewall 86 is additionally in communication with other infotainment apps, for example an audio player 90 or other infotainment apps 92. These apps are controlled through an external interface 94. The audio player 90 and other infotainment apps 92 provide the vehicle bus firewall 86 with appropriate information. Based on the appropriate vehicle bus filtering rule determined by the context-based vehicle bus filtering rules 84, the
vehicle bus firewall 86 will perform the appropriate function and either send the information onto the vehicle bus 88 or block the information from being sent. In further embodiments, the protected memory space 82 ensures that if an application, such as the audio player 90, is compromised by a cyber-attack, the compromised application cannot disrupt the processing of the vehicle bus firewall 86.
[052] In certain embodiments, shown in FIG. 10, the protection system 100 might comprise a single purpose ECU protection system. In exemplary embodiments, a single control function processing unit 102 is in communication with the vehicle bus firewall 104. The vehicle bus firewall 104 is additionally in communication with the context-based vehicle bus filtering rules 106 and the vehicle bus 108. The control function processing unit 102 then provides the vehicle bus firewall 104 the information needed to determine which vehicle bus filtering rule to apply, as given by the context-based vehicle bus filter rules 106. The vehicle bus firewall 104 then applies the appropriate vehicle bus filtering rule 106 and either passes the information onto the vehicle bus 108 to perform the appropriate function or blocks the information from being sent.
[053] Continuing on to FIG. 11, in further embodiments the protection system 100 might feature a vehicle bus bridge ECU protection system. In exemplary embodiments the two separate vehicle bus firewalls 112, 114 are in communication with each other. The first vehicle bus firewall 112 is governed by the first context-based vehicle bus filtering rules 116. The second vehicle bus firewall 114 is governed by the second context-based vehicle bus filtering rules 118. Additionally, the first vehicle bus firewall 112 is in communication with the critical vehicle bus 120, and the second vehicle bus firewall 114 is in communication with the non- critical vehicle bus 122. In certain embodiments, the two firewall systems allow for multi-level protection based on the appropriate information contained in both firewalls 112, 114 and both context-based vehicle bus filtering rules 116, 118. The protection systems can then allow the first and second firewalls, 112 and 114, respectively, to determine which systems are critical, for example anti-lock brakes, and which systems are non-critical, for example satellite radio. In exemplary embodiments, if it is a critical system, the first vehicle bus firewall 112 will look up the necessary information based on vehicle state and message ID and then apply the appropriate vehicle bus filtering rule based on this determination. In further embodiments, this vehicle bus filtering rule the firewall will either send the information to the critical vehicle bus 120 or block
the information from being sent. The second vehicle bus firewall 114 will perform the same process for non-critical systems based on the second context-based vehicle bus filtering rules 118.
[054] In various embodiments, shown in FIG. 12, the protection system 100 may feature an aftermarket ECUfirewall. In exemplary embodiments, an external communication platform, such as an OBD-II Interface 126, connected to an aftermarket ECU firewall 128 and then connected to an OBD-II port 130 that goes into the vehicle 132. The OBD-II port 130 is also connected to the OBD-II ECU 134, which is in communication with the vehicle's vehicle bus 136. The vehicle's vehicle bus 136 is optionally in further connected with numerous ECUs 138. For example, the OBD-II port 130 is the physical component that allows external devices to be connected to a vehicle for the purpose of allowing service personnel to diagnose issues and extract information for servicing a vehicle. The aftermarket ECU firewall 128 provides protection from abuse of this OBD-II port capability. The aftermarket ECU firewall 128 is in communication with an OBD-II interface 126 that can be utilized by the external devices. The internal OBD-II ECU 134 and the other various ECUs 138 are protected from a cyber-attack through the OBD-II port by the aftermarket ECU firewall 128.
[055] In certain embodiments, shown in FIG. 13, the protection system could be implemented as an aftermarket add-on vehicle bus firewall embodiment. In exemplary embodiments, an external interface 142 might be in communication with an event log 144. The event log 144 could be in further communication with an OBD-II firewall 146. Additionally, an OBD-II interface 148 could be in communication with an external OBD-II port 150, which in turn is communication with an OBD-II firewall 152. This OBD-II firewall 152 can be controlled by the OBD-II filtering rules 154. Further, the OBD-II firewall 152 is in communication with an internal OBD-II port 156 connected to the vehicle 132. FIG. 13 shows a more detailed example of the protection system 100 in FIG. 12. In this example, the external interface 142, OBD-II interface 148, and OBD-II port 150 provide access for external devices to the internal OBD-II port 156, but are protected by the OBD-II firewall 152. The firewall 152 determines the appropriate filtering rules from the OBD-II filtering rules 154 and either sends the information onto the internal OBD-II port 156 connected to the vehicle or blocks the information and additionally logs the information in the event log 144.
[056] FIG. 14 shows an exemplary embodiment of the protection system 100 featuring the process utilized by the vehicle bus firewall filtering vehicle bus bridge 162. This process is utilized in a number of disclosed embodiments, and specifically in the first and second vehicle bus firewalls 112 and 114 of FIG. 7. In these exemplary embodiments, two separate vehicle buses are being operated: a first bus 164 and a second bus 166. In the disclosed embodiments the series of optional steps begins by either first bus 164 receiving a vehicle bus message (block 168) or second bus 166 receiving a vehicle bus message (block 170).
[057] Regardless of which bus receives the vehicle bus message, (block 168) or (block
170), the process for CAN bus messages, then flows to the block that extracts the identifier extension IDE bit from the CAN MSG header ("HDR") (block 172). Based on this extracted data, the process then asks whether the IDE bit is set (block 174). If the answer is yes, the process then extracts the 29-bit message ID from the CAN MSG HDR (block 176). If the answer is no, the process then extracts the 11 -bit message ID from the CAN MSG HDR (block 178). Regardless of which bit is extracted, in the case of CAN bus messages, or if the message is received on another type of vehicle bus the process the asks whether the message ID is in the set of messages with status information (block 180). If the answer is yes, the vehicle status based on the message contents is updated (block 182). If the answer is no, the process skips this step. Next, the process uses the message ID, vehicle status and bus ID message received to look up the filtering action in the appropriate vehicle bus filtering table (block 184). Based on the result that is returned by the vehicle bus filtering table the filtering action is performed (block 186). If the filtering action is Log & Allow (block 188), the message is first logged (block 190) and then continues on the path described for the filtering result for Allow (block 192). If the filtering result is Block & Log (block 194) the message will be logged (block 196) and the process will begin again. If the filtering result is Allow (block 192), the process will then determine whether the message was received on the first bust or the second bus (block 198). If the message was received on the first bus 164, the process will transmit the message of the second bus (block 200). If the message was received on the second bus 166 the process will transmit the message on the first bus (block 202). The process lastly asks whether the vehicle status value has expired (block 204). If the answer is no, the process will send a message to request the vehicle status (block 206), and then the process will begin again.
[058] Continuing with FIG. 15, in certain exemplary embodiments, the protection system 100 features the process utilized by the vehicle bus firewall filtering for a complex ECU 212, for example,, an infotainment ECU. This process is optionally used in a number of disclosed embodiments and specifically used in the vehicle bus firewall 86 in FIG. 9. In certain exemplary embodiments, the series of optional steps begins with one of the tasks 124, such as the audio player task, which attempts to send an internal message. The internal message is translated into a vehicle bus message of various possible vehicle bus messages that are to be transmitted onto the vehicle bus, which first encounters the vehicle bus firewall (such as the vehicle bus firewall 86 shown in FIG. 9). These vehicle bus messages are received as a vehicle bus message on the vehicle bus (block 216). In certain embodiments, the task 214 message is reformatted into a vehicle bus message before it is received (block 216). If the message is received on a CAN bus, the process then extracts the IDE bit from the CAN MSG HDR (block 218). The process then asks if the IDE bit is set (block 220). If the answer is yes, the process extracts a 29-bit MSG ID from the CAN MSG HDR (block 222). If the answer is no, the process extracts an 11-bit MSG ID from the CAN MSG HDR (block 224), or the appropriate message ID from the MSG HDR if the message is received on a different type of vehicle bus. Regardless of this choice, the process for these exemplary embodiments then uses the task ID, MSG ID and vehicle status to lookup the filtering action in the vehicle bus filtering table (block 226). In these exemplary embodiments, the vehicle bus filtering table provides the firewall with three filtering actions (block 228). If the filtering action is Block & Log 230, then the message is logged (block 232). If the action is Log & Allow (block 234), then the message is logged (block 236) and then the message is sent on to the vehicle bus (block 238). If the action is Allow (block 240), then the message is sent on to the vehicle bus (block 238). At the same time, the firewall is running two additional questions. The first question is whether the vehicle status has expired (block 244). If the answer is no then process delays for a predefined period before it then loops and asks the question again (block 244). If the answer is yes, a message is sent to request the vehicle status (block 246). The second question is whether there a vehicle status message (block 250). If the answer is no, the process loops until a vehicle bus message is received (block 252). If the answer is yes, then the vehicle status is updated (block 254) and the process is looped until a vehicle bus message is received (block 252).
[059] Continuing with FIG. 16, in certain exemplary embodiments of the protection system 100, the process is utilized by the vehicle bus firewall filtering for a gateway ECU 260. The disclosed process is utilized by a number of disclosed embodiments, and specifically by firewall 76 in FIG. 8 and by firewall 44 in FIG. 6. These exemplary embodiments run the same process described for FIG. 15, but instead of tasks sending internal messages that are translated into vehicle bus messages, external communication platforms, such as WiFi or cellular data, are sending messages. Additionally, to receive a vehicle bus message (block 263) the gateway ECU reformats the interface 262 messages into vehicle bus messages when they are received (block 263).
[060] Continuing to FIG. 17, in further exemplary embodiments of the protection system 100, the process features the vehicle bus firewall for a single purpose ECU 266. The disclosed process is utilized by a number of disclosed embodiments, and specifically by vehicle bus firewall 104 in FIG. 10. These exemplary embodiments run a similar process as shown in FIG. 14, except there is only one bus 268. As a result, there is only one bus to receive the vehicle bus message (block 270) and no transmission on a second bus is necessary. Additionally, instead of forwarding the vehicle bus message, as in (block 198) in FIG. 14, the ECU accepts/processes the vehicle bus message (block 272).
[061 ] FIG. 18 is a further exemplary embodiment of the protection system 100 featuring the process utilized by the message logging and reporting system 276. The disclosed process is utilized in a number of disclosed embodiments, and specifically by first and second vehicle bus firewalls 112 and 114 in FIG. 11, vehicle bus firewall 104 in FIG. 10, and vehicle bus firewall 86 in FIG. 9. In the series of optional steps of this embodiment, the firewall message and action are received and the action is chosen as described in FIGS. 14 and 15. The additional step is that the process logs and stores messages in the log (block 278), and sends them to the Telematics Operations Center (TOC) (block 286). The process then asks if it is a critical message (block 280). If the answer is yes, the event is sent to the dashboard ECU for display (block 282). If the answer is no, the process then asks if it is a warning message (block 284). If the answer is yes, the process then asks if the number of events is passed the warning threshold (block 288). If the answer is yes, the event is sent to the dashboard ECU for display (block 282). If the answer is no, no action is taken. The process restarts when another vehicle bus firewall message is received.
[062] Continuing with FIG. 19, in further exemplary embodiments the protection system 100 features the process utilized by the OBD-II message firewall 292. The disclosed process is utilized in a number of disclosed embodiments, and specifically in the OBD-II firewall 152 in FIG. 13. These exemplary embodiments utilize a series of optional steps by which a message is received on the external port (block 294). The message ID is then extracted (block 296). Next, the process uses the message ID and vehicle status lookup filtering action in the OBD-II filtering table (block 298) to determine the filtering action (block 300). If the filtering action is Block & Log 310, the message is logged (block 312). If the action is Log & Allow (block 302), the message is logged (block 304) and then the process follows the same process as if the message were allowed (block 306). If the action is Allow (block 306), then the message is sent to the internal OBD-II Port (block 308). The process then asks if the vehicle status is expired (block 314). If the answer if no, the process waits until another message is received on the external port (block 294). If the answer is yes, the process sends a status received message on the internal port (block 316) and then waits for the process to receive another message on the external port (block 294). At the same time, the process is continually running a question based on whether there is a vehicle status message (block 320). If the answer is yes, the vehicle status information is updated (block 322) and then the message is sent to the external port (block 324). If the answer is no, then the message is sent to the external port (block 324) without updated vehicle status information (block 322). Regardless of the action, the process then loops until a message is received on the internal port and this message is extracted (block 326). The question (block 320) is then asked again by the process.
[063] Although the disclosure has been described with reference to preferred embodiments, persons skilled in the art will recognize that changes may be made in form and detail without departing from the spirit and scope of the disclosed apparatus, systems and methods.
Claims
1. An automotive electrical control unit protection system, comprising:
a. one or more data inputs;
b. one or more automotive electronic control units, wherein the automotive electronic control units process the one or more data inputs into one or more data packets; c. one or more vehicle buses, wherein the one or more vehicle buses process the one or more data packets into one or more vehicle bus messages; and
d. one or more vehicle bus firewalls.
2. The automotive electrical control unit protection system of claim 1, wherein the one or more data inputs are sensor data inputs or external communication platform inputs.
3. The automotive electrical control unit protection system of claim 2, wherein the external communication platform inputs are selected from the group consisting of Wi-Fi, Ethernet, On- Board Diagnostics Generation Two (OBD-II), GPS, or Telematics.
4. The automotive electrical control unit protection system of claim 1, wherein the one or more automotive electrical control units comprise at least one of:
a. a complex architecture;
b. a gateway architecture; and/or
c. a chain architecture.
5. The automotive electrical control unit protection system of claim 1, wherein the one or more vehicle buses comprise one or more of:
a. a critical system vehicle bus; and/or
b. a non-critical system vehicle bus.
6. An automotive electrical control unit protection system, comprising:
a. sending periodic vehicle bus messages from one or more vehicle bus firewalls to determine vehicle status;
-22-
b. recording the vehicle status;
c. passing messages sent by one or more automotive electronic control units through the one or more vehicle bus firewalls before being passed onto one or more vehicle buses;
d. determining a filtering rule using the vehicle bus firewall based upon vehicle status and message ID based upon vehicle status and message ID and determining an action with the filtering rule; and
e. performing the action prescribed by the filtering rule.
7. The automotive electrical control unit protection system of claim 6, wherein the periodic vehicle bus messages are sent between every one to ten seconds.
8. The automotive electrical control unit protection system of claim 6, wherein the one or more automotive electrical control units comprise one or more of:
a. a complex architecture;
b. a gateway architecture; and/or
c. a chain architecture.
9. The automotive electrical control unit protection system of claim 6, wherein the one or more vehicle buses comprise one or more of:
a. a critical system vehicle bus; and/or
b. a non-critical system vehicle bus.
10. The automotive electrical control unit protection system of claim 6, wherein the filtering rule is selected from a group containing BLOCK, ALLOW, and LOG.
11. The automotive electrical control unit protection system of claim 10, wherein a control function processing unit teaches the one or more vehicle bus firewalls which filtering rule to apply.
-23-
12. The automotive electrical control unit protection system of claim 6, wherein the vehicle status includes a vehicle state and a message ID, and is used to determine which filtering rules to apply.
13. An automotive electrical control unit firewall, wherein the automotive electrical control unit firewall:
a. sends periodic vehicle bus messages from one or more vehicle bus firewalls to determine vehicle status;
b. records the vehicle status;
c. passes messages sent by one or more automotive electronic control units through the one or more vehicle bus firewalls before being passing them on to one or more vehicle buses;
d. determines the filtering rule using the vehicle bus firewall based upon vehicle status and message ID and determining an action with the filtering rule; and e. performs the action prescribed by the filtering rule.
14. The automotive electrical control unit firewall of claim 13, wherein the periodic vehicle bus messages are sent between every one to ten seconds.
15. The automotive electrical control unit firewall of claim 13, wherein the one or more automotive electrical control units comprise one or more of:
a. a complex architecture;
b. a gateway architecture; and/or
c. a chain architecture.
16. The automotive electrical control unit firewall of claim 13, wherein the one or more vehicle buses comprise one or more of:
a. a critical system vehicle bus; and/or
b. a non-critical system vehicle bus.
-24-
17. The automotive electrical control unit firewall of claim 13, wherein the filtering rule is selected from the group containing BLOCK, ALLOW, and LOG.
18. The automotive electrical control unit firewall of claim 17, wherein a control function processing unit teaches the one or more vehicle bus firewalls which filtering rule to apply.
19. The automotive electrical control unit firewall of claim 13, wherein the vehicle status includes a vehicle state and a message ID.
20. The automotive electrical control unit firewall of claim 19, wherein the automotive electrical control unit firewall protects automotive electrical control units from cyber-attacks.
-25-
Priority Applications (2)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
US15/746,079 US10666615B2 (en) | 2015-08-03 | 2016-08-03 | Method for detecting, blocking and reporting cyber-attacks against automotive electronic control units |
US16/881,147 US11411917B2 (en) | 2015-08-03 | 2020-05-22 | Method for detecting, blocking and reporting cyber-attacks against automotive electronic control units |
Applications Claiming Priority (2)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
US201562200550P | 2015-08-03 | 2015-08-03 | |
US62/200,550 | 2015-08-03 |
Related Child Applications (2)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
US15/746,079 A-371-Of-International US10666615B2 (en) | 2015-08-03 | 2016-08-03 | Method for detecting, blocking and reporting cyber-attacks against automotive electronic control units |
US16/881,147 Continuation US11411917B2 (en) | 2015-08-03 | 2020-05-22 | Method for detecting, blocking and reporting cyber-attacks against automotive electronic control units |
Publications (1)
Publication Number | Publication Date |
---|---|
WO2017024078A1 true WO2017024078A1 (en) | 2017-02-09 |
Family
ID=57943640
Family Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
PCT/US2016/045431 WO2017024078A1 (en) | 2015-08-03 | 2016-08-03 | A method for detecting, blocking and reporting cyber-attacks against automotive electronic control units |
Country Status (2)
Country | Link |
---|---|
US (2) | US10666615B2 (en) |
WO (1) | WO2017024078A1 (en) |
Cited By (11)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
CN108156021A (en) * | 2017-12-04 | 2018-06-12 | 中国第汽车股份有限公司 | A kind of design method of vehicle network topology |
DE102017203898A1 (en) | 2017-03-09 | 2018-09-13 | Siemens Aktiengesellschaft | Gateway device, communication method and communication system for a vehicle, in particular a rail vehicle |
DE102017204475A1 (en) * | 2017-03-17 | 2018-09-20 | Siemens Aktiengesellschaft | Communication method and communication system for a vehicle |
WO2019096643A1 (en) * | 2017-11-15 | 2019-05-23 | Siemens Mobility GmbH | System and method for the protected transmission of data |
EP3547191A1 (en) * | 2018-03-30 | 2019-10-02 | AO Kaspersky Lab | System and method of generating rules for blocking a computer attack on a vehicle |
CN110324301A (en) * | 2018-03-30 | 2019-10-11 | 卡巴斯基实验室股份制公司 | It generates for preventing the system and method to the rule of the computer attack of vehicle |
CN110519160A (en) * | 2019-08-15 | 2019-11-29 | 深圳市丰润达科技有限公司 | Things-internet gateway multimode communication means, device and computer readable storage medium |
CN111077873A (en) * | 2019-02-07 | 2020-04-28 | 卡巴斯基实验室股份公司 | System and method for controlling access to an information-physical system |
CN111327587A (en) * | 2018-12-17 | 2020-06-23 | 罗伯特·博世有限公司 | Method and device for operating a communication network |
US11005880B2 (en) * | 2018-03-30 | 2021-05-11 | AO Kaspersky Lab | System and method of blocking a computer attack on a means of transportation |
DE112017006948B4 (en) | 2017-02-28 | 2022-07-28 | Mitsubishi Electric Corporation | VEHICLE COMMUNICATIONS MONITORING EQUIPMENT, VEHICLE COMMUNICATIONS MONITORING METHOD AND VEHICLE COMMUNICATIONS MONITORING PROGRAM |
Families Citing this family (16)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
DE102016222740A1 (en) * | 2016-11-18 | 2018-05-24 | Continental Automotive Gmbh | Method for a communication network and electronic control unit |
US11329953B2 (en) * | 2017-03-09 | 2022-05-10 | Argus Cyber Security Ltd. | System and method for providing cyber security to an in-vehicle network |
US10764134B2 (en) * | 2018-06-22 | 2020-09-01 | Blackberry Limited | Configuring a firewall system in a vehicle network |
US11354406B2 (en) * | 2018-06-28 | 2022-06-07 | Intel Corporation | Physics-based approach for attack detection and localization in closed-loop controls for autonomous vehicles |
JP7067623B2 (en) * | 2018-08-01 | 2022-05-16 | 日本電気株式会社 | Switches, control devices, communication systems, communication control methods and programs |
RU2726884C1 (en) | 2019-02-07 | 2020-07-16 | Акционерное общество "Лаборатория Касперского" | System and method of controlling access to cyber physical system |
US20200274851A1 (en) * | 2019-02-22 | 2020-08-27 | Juniper Networks, Inc. | Full featured packet-based automotive network security gateway |
JP7215307B2 (en) * | 2019-04-10 | 2023-01-31 | トヨタ自動車株式会社 | Vehicle control interface and vehicle system |
IT201900007071A1 (en) * | 2019-05-21 | 2020-11-21 | Turrin Elettr S R L | SYSTEM FOR MONITORING THE FUNCTIONALITIES OF A VEHICLE |
JP7115442B2 (en) * | 2019-08-21 | 2022-08-09 | トヨタ自動車株式会社 | Determination device, determination system, program and determination method |
WO2021053517A1 (en) * | 2019-09-20 | 2021-03-25 | Martin Kuster | Automotive, naval, and aircraft bus-emulator |
US11538287B2 (en) | 2019-09-20 | 2022-12-27 | Sonatus, Inc. | System, method, and apparatus for managing vehicle data collection |
CN114651456A (en) | 2019-09-20 | 2022-06-21 | 桑纳特斯公司 | System, method and apparatus for off-vehicle communication control |
CN113060082B (en) * | 2020-01-02 | 2023-12-15 | 广州汽车集团股份有限公司 | Abnormality processing method and device for vehicle-mounted firewall, vehicle-mounted firewall and automobile |
DE102020201988A1 (en) | 2020-02-18 | 2021-08-19 | Robert Bosch Gesellschaft mit beschränkter Haftung | Device for processing data with at least two data interfaces and operating methods therefor |
DE102021117500A1 (en) * | 2021-07-07 | 2023-01-12 | Zf Cv Systems Global Gmbh | Device for secure communication between control devices in a vehicle, electronic processing unit and vehicle |
Citations (5)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US20130104186A1 (en) * | 2010-02-22 | 2013-04-25 | Continental Automotive Gmbh | System and method for preventing an attack on a networked vehicle |
US20130145482A1 (en) * | 2011-11-16 | 2013-06-06 | Flextronics Ap, Llc | Vehicle middleware |
US20140195808A1 (en) * | 2011-12-01 | 2014-07-10 | Victor B. Lortz | Secure message filtering to vehicle electronic control units with secure provisioning of message filtering rules |
US20150020152A1 (en) * | 2012-03-29 | 2015-01-15 | Arilou Information Security Technologies Ltd. | Security system and method for protecting a vehicle electronic system |
US20150113638A1 (en) * | 2013-10-23 | 2015-04-23 | Christopher Valasek | Electronic system for detecting and preventing compromise of vehicle electrical and control systems |
Family Cites Families (2)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US20110130906A1 (en) * | 2009-12-01 | 2011-06-02 | Ise Corporation | Location Based Vehicle Data Logging and Diagnostic System and Method |
KR102524204B1 (en) * | 2018-04-27 | 2023-04-24 | 한국전자통신연구원 | Apparatus and method for intrusion response in vehicle network |
-
2016
- 2016-08-03 WO PCT/US2016/045431 patent/WO2017024078A1/en active Application Filing
- 2016-08-03 US US15/746,079 patent/US10666615B2/en active Active
-
2020
- 2020-05-22 US US16/881,147 patent/US11411917B2/en active Active
Patent Citations (5)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US20130104186A1 (en) * | 2010-02-22 | 2013-04-25 | Continental Automotive Gmbh | System and method for preventing an attack on a networked vehicle |
US20130145482A1 (en) * | 2011-11-16 | 2013-06-06 | Flextronics Ap, Llc | Vehicle middleware |
US20140195808A1 (en) * | 2011-12-01 | 2014-07-10 | Victor B. Lortz | Secure message filtering to vehicle electronic control units with secure provisioning of message filtering rules |
US20150020152A1 (en) * | 2012-03-29 | 2015-01-15 | Arilou Information Security Technologies Ltd. | Security system and method for protecting a vehicle electronic system |
US20150113638A1 (en) * | 2013-10-23 | 2015-04-23 | Christopher Valasek | Electronic system for detecting and preventing compromise of vehicle electrical and control systems |
Cited By (17)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
DE112017006948B4 (en) | 2017-02-28 | 2022-07-28 | Mitsubishi Electric Corporation | VEHICLE COMMUNICATIONS MONITORING EQUIPMENT, VEHICLE COMMUNICATIONS MONITORING METHOD AND VEHICLE COMMUNICATIONS MONITORING PROGRAM |
DE102017203898A1 (en) | 2017-03-09 | 2018-09-13 | Siemens Aktiengesellschaft | Gateway device, communication method and communication system for a vehicle, in particular a rail vehicle |
DE102017204475A1 (en) * | 2017-03-17 | 2018-09-20 | Siemens Aktiengesellschaft | Communication method and communication system for a vehicle |
RU2734764C1 (en) * | 2017-11-15 | 2020-10-23 | Сименс Мобилити Гмбх | System and method of secure data transmission |
WO2019096643A1 (en) * | 2017-11-15 | 2019-05-23 | Siemens Mobility GmbH | System and method for the protected transmission of data |
US11916877B2 (en) | 2017-11-15 | 2024-02-27 | Siemens Mobility GmbH | System and method for the protected transmission of data |
CN108156021A (en) * | 2017-12-04 | 2018-06-12 | 中国第汽车股份有限公司 | A kind of design method of vehicle network topology |
CN108156021B (en) * | 2017-12-04 | 2021-02-05 | 中国第一汽车股份有限公司 | Design method of whole vehicle network topology |
US11005880B2 (en) * | 2018-03-30 | 2021-05-11 | AO Kaspersky Lab | System and method of blocking a computer attack on a means of transportation |
JP2019194830A (en) * | 2018-03-30 | 2019-11-07 | エーオー カスペルスキー ラボAO Kaspersky Lab | System and method of generating rules for blocking computer attack on vehicle |
US11277417B2 (en) | 2018-03-30 | 2022-03-15 | AO Kaspersky Lab | System and method of generating rules for blocking a computer attack on a vehicle |
CN110324301A (en) * | 2018-03-30 | 2019-10-11 | 卡巴斯基实验室股份制公司 | It generates for preventing the system and method to the rule of the computer attack of vehicle |
EP3547191A1 (en) * | 2018-03-30 | 2019-10-02 | AO Kaspersky Lab | System and method of generating rules for blocking a computer attack on a vehicle |
CN111327587A (en) * | 2018-12-17 | 2020-06-23 | 罗伯特·博世有限公司 | Method and device for operating a communication network |
CN111077873A (en) * | 2019-02-07 | 2020-04-28 | 卡巴斯基实验室股份公司 | System and method for controlling access to an information-physical system |
CN111077873B (en) * | 2019-02-07 | 2023-09-22 | 卡巴斯基实验室股份公司 | System and method for controlling access to an information-physical system |
CN110519160A (en) * | 2019-08-15 | 2019-11-29 | 深圳市丰润达科技有限公司 | Things-internet gateway multimode communication means, device and computer readable storage medium |
Also Published As
Publication number | Publication date |
---|---|
US20180205703A1 (en) | 2018-07-19 |
US10666615B2 (en) | 2020-05-26 |
US11411917B2 (en) | 2022-08-09 |
US20200287872A1 (en) | 2020-09-10 |
Similar Documents
Publication | Publication Date | Title |
---|---|---|
US11411917B2 (en) | Method for detecting, blocking and reporting cyber-attacks against automotive electronic control units | |
CN112204578B (en) | Detecting data anomalies on a data interface using machine learning | |
US11165851B2 (en) | System and method for providing security to a communication network | |
CN109076001B (en) | Frame transfer preventing device, frame transfer preventing method, and vehicle-mounted network system | |
JP6807906B2 (en) | Systems and methods to generate rules to prevent computer attacks on vehicles | |
US20190356687A1 (en) | Attack detection method, attack detection device and bus system for a motor vehicle | |
Carsten et al. | In-vehicle networks: Attacks, vulnerabilities, and proposed solutions | |
US11451579B2 (en) | System and method for protecting electronics systems of a vehicle from cyberattacks | |
US10326793B2 (en) | System and method for guarding a controller area network | |
US20190182267A1 (en) | Vehicle security manager | |
JP2022125099A (en) | Fraud detection server and method | |
Nilsson et al. | Vehicle ECU classification based on safety-security characteristics | |
US20150066239A1 (en) | Vehicle network monitoring method and apparatus | |
CN111466107A (en) | Ethernet profiling intrusion detection control logic and architecture for in-vehicle controllers | |
EP3547191B1 (en) | System and method of generating rules for blocking a computer attack on a vehicle | |
WO2021038869A1 (en) | Vehicle monitoring device and vehicle monitoring method | |
KR101966345B1 (en) | Method and System for detecting bypass hacking attacks based on the CAN protocol | |
CN112104608A (en) | Vehicle information safety protection method, system and storage medium | |
EP3547192B1 (en) | System and method of blocking a computer attack on a means of transportation | |
JP2022024266A (en) | Log analyzer | |
WO2021019636A1 (en) | Security device, incident handling method, program, and storage medium | |
Groza et al. | Designing security for in-vehicle networks: a Body Control Module (BCM) centered viewpoint | |
CN113783958A (en) | Gateway device, method and vehicle-mounted network system | |
Caberto et al. | A method of securing a vehicle’s controller area network | |
JP2023122636A (en) | Reduction in manipulation of vehicle software |
Legal Events
Date | Code | Title | Description |
---|---|---|---|
121 | Ep: the epo has been informed by wipo that ep was designated in this application |
Ref document number: 16833838 Country of ref document: EP Kind code of ref document: A1 |
|
NENP | Non-entry into the national phase |
Ref country code: DE |
|
122 | Ep: pct application non-entry in european phase |
Ref document number: 16833838 Country of ref document: EP Kind code of ref document: A1 |