Method for protection of automotive components in intravehicle communication system

Methods and systems for mitigating cyber attacks on components of an automotive communication system are disclosed. These methods and systems comprise elements of hardware and software for receiving a frame; determining whether the frame potentially affects correct operation of an automotive component; and, taking protective action.

TECHNICAL FIELD OF THE INVENTION

The present invention relates to methods and systems for prevention of malicious or unintentional disruption of automotive components that are connected to an intra vehicular communication system.

BACKGROUND

The automotive industry is using networks to connect together devices and microcontrollers inside vehicles. These networks may utilize, for example, CANbus, Ethernet, and the like.

On such networks, some nodes can control physical components through actuators or other means, while other nodes only need to receive sensor feedback and possibly present this information to end users. Examples of nodes in such a networked automotive environment potentially include: engine control unit, battery control unit, transmission control unit, air bag control unit, in car entertainment system and the like.

This heterogeneous environment can create serious security risks. A malicious party may potentially compromise one of these components by using one of the external interfaces exposed by the vehicle. Once such a component is compromised, an attacker can use it as a stepping stone to other attack components. An attacker can thus compromise critical vehicle components such as the locking system, the braking system and the engine.

By compromising critical vehicle components, an attacker can potentially steal the car, cause serious damage to the car or its surroundings and even cause serious injury or death.

SUMMARY OF THE INVENTION

The present invention provides methods and systems for receiving a frame; determining whether the frame potentially affects correct operation of an automotive component; and taking protective action.

This document references terms that are used consistently or interchangeably herein. These terms, including variations thereof, are as follows:

A “computer” includes machines, computers and computing or computer systems (for example, physically separate locations or devices), servers, computer and computerized devices, processors, processing systems, computing cores (for example, shared devices), and similar systems, workstations, modules and combinations of the aforementioned. The aforementioned “computer” may be in various types, such as a personal computer (e.g., laptop, desktop, tablet computer), or any type of computing device, including mobile devices that can be readily transported from one location to another location e.g., smartphone, personal digital assistant (PDA), mobile telephone or cellular telephone).

A “server” is typically a remote computer or remote computer system, or computer program therein, in accordance with the “computer” defined above, that is accessible over a communications medium, such as a communications network or other computer network, including the Internet. A “server” provides services to, or performs functions for, other computer programs (and their users), in the same or other computers. A server may also include a virtual machine, a software based emulation of a computer.

An “application”, includes executable software, and optionally, any graphical user interfaces (GUI), through which certain functionality may be implemented.

DETAILED DESCRIPTION OF THE INVENTION

The present invention may be embodied in a system, method or computer program product. Accordingly, aspects of the present invention may take the form of an entirely hardware embodiment, an entirely software embodiment (including firmware, resident software, micro-code) or an embodiment combining software and hardware aspects that may all generally be referred to herein as a “circuit,” “module” or “system.” Furthermore, aspects of the present invention may take the form of a computer program product embodied in one or more non-transitory computer readable (storage) medium(s) having computer readable program code embodied thereon.

Embodiments of the present invention provide for an in-vehicle protection system which is linked to a frame-switching device which receives and forwards every frame sent and received across the automotive communication network. In such an embodiment, upon encountering a suspicious frame the protection device may, for example, block frames in switching devices or raise notifications to an administrator.

However the invention may also be embodied, for example, in a passive monitoring device that is attached to the shared media bus or switched Ethernet that comprises the automotive communication network. In such an embodiment, the protection device may, for example, be unable to block frames, but may instead, for example, raise notifications to an administrator.

Alternatively, the invention may be embodied, for example, in a distributed fashion in multiple instances linked to frame-switching devices and/or passive monitors. In such an embodiment, the protection device may, for example, block frames in switching devices, and may, for example, raise notifications to an administrator from both the switching devices and passive monitors. In such embodiments, there may, for example, be information that is shared between the instances in a central data repository.

Reference is now made toFIG. 1, which shows an exemplary system environment including a plurality of automotive components110each equipped with an Ethernet Network Interface Controller (NIC)115linked by an Ethernet Cable120to a Network Interface Controller (NIC)130located on the in-vehicle protection appliance140. Each NIC of the in-vehicle protection appliance140is, for example, linked to an Ethernet switch180via an Ethernet connector160.

Alternatively, the in-vehicle protection appliance may, tar example, be collocated within an Ethernet switch, so that the uplink ports150and the swath ports170are replaced by a software interface. In this case, frames travel, for example, between the in-vehicle protection device and the switch over a software interface.

An exemplary internal architecture of the in-vehicle protection appliance140is shown inFIG. 2. The in-vehicle protection appliance140includes a central processing unit (CPU)202formed of one or more processors, electronically connected, including in electronic and/or data communication with input interfaces210, uplink interfaces260, access control module220, protocol monitor modules230, load monitor module240, pattern matching module250, input source address policy database223, component access policy database225, protocol weakness repository instances235, load monitor configuration245, pattern database255, protocol state database233and management module270.

A frame exemplary enters the in-vehicle protection appliance on a particular port, is processed by a series of processing modules, and transmitted on the corresponding uplink port.

The Central Processing Unit (CPU)202is formed of one or more processors, including physical or virtual microprocessors, for performing the in-vehicle protection appliance140functions and operations detailed herein, including controlling the memory204, storage206, input interfaces210, uplink interfaces260, access control modules220, protocol monitor instance modules230, load monitor modules240, pattern matching modules250, input source address policy database223, component access policy database225, protocol weakness repository instances235, load monitor configuration245, pattern database255, and management module270along with the processes shown inFIGS. 3 and 4. The processors are, for example, conventional processors, such as those used in servers, computers, and other computerized devices. For example, the processors may include x86 Processors from AMD and Intel, Xeon® and Pentium® processors from Intel, as well as any combinations thereof.

The memory220is any conventional memory media. The memory220stores machine executable instructions associated with the operation of the components, including, input interfaces210, uplink interfaces260, access control modules220, protocol monitor instance modules230, load monitor modules240, pattern matching modules250, input source address policy database223, component access policy database225, protocol weakness repository instances235, load monitor configuration245, pattern database255, and management module270and all instructions for executing the processes ofFIG. 4detailed herein. The processors of the CPU202, memory204, and storage206although each shown as a single component for representative purposes, may be multiple components, and may be outside of the in-vehicle protection appliance140, and linked to an input interface210or uplink interface270.

The input interface210is, for example, a physical, virtual, or logical data link for communication with components in the automotive (potentially including gateways for communication beyond the automotive). Similarly, the uplink interface260is, for example, a physical, virtual, or logical data link for communication with, for example, an ethernet switch or, for example, another device responsible for delivering frames to an intended destination.

The Access Control Module220evaluates whether a received frame should be permitted ingress into the system. The module exemplary evaluates two separate criteria. First the Access Control Module220checks, for example, whether the originating address of the frame is known to be associated with the input port on which the frame was received. If the originating address of the frame is not known to be associated with the input port, it may be the case that a compromised node or an external attacker is attempting a cyber-attack using a forged originating address, and the incoming frame is then, for example, discarded by the Access Control Module220.

The originating address may be, for example, an Ethernet address, an Internet Protocol (IP) address or the like. To make the determination of whether the originating address is known to be associated with the input port, the module uses, for example, the Input Port Source Address Policy database223. The Input Port Source Address Policy database223is configured, for example, by the Management Module270. Alternatively, whether a source address is associated with a particular input port may be determined by, for example, consultation with a server elsewhere on the network. Alternatively, whether a source address is associated with a particular input port may be determined by, for example, observing frame traffic for an amount of time after system initialization.

Additionally the Access Control Module220checks, for example, whether the automotive component originating the communication is permitted by policy to communicate with the target automotive component. For example, policy might entitle the vehicle monitoring system to communicate with the braking system, but may prohibit the infotainment system from doing so. In this case, if the infotainment system attempts to communicate with the braking system it may be an indication of a cyber attack or security compromise, and the incoming frame is then, for example, discarded by the Access Control Module220.

The originating address and destination address of the frames may be, for example, an Ethernet address, an Internet Protocol (IP) address or the like. To make the determination of whether the originating address is permitted by policy to communicate with the destination address, the module uses, for example, the Component Access Policy database225. The Component Access Policy database225is configured, for example, by the Management Module270. Alternatively, whether a source address is permitted to send frames to a particular destination address may be determined by, for example, consultation with a server elsewhere on the network.

There are, for example, zero or more protocol monitor modules230. Each instance of a protocol monitor module230is associated with, for example, a stateful or session-oriented higher-layer protocol such as Transmission Control Protocol (TCP) or Hyper Text Transfer Protocol (HTTP). The specific Protocol Monitor Module instance that is invoked corresponds to the higher-level protocol that is carried in the frame. This protocol may be, for example, Transmission Control Protocol, Session Control. Transmission Control Protocol, or the like. This protocol may also be, for example, a hierarchy of protocols such as Hyper Text Transport Protocol (HTTP) over TCP, or the like. The identification of the protocol is performed, for example, by performing deep packet inspection (DPI) on the fields of the frame.

The Protocol Monitor Module instance230first evaluates a received frame to determine, for example, whether the frame constitutes an attempt to disrupt the operation of the specific protocol. Subsequently, the Protocol Monitor Module instance230evaluates, for example, whether the frame attempts to exploit a vulnerability of the protocol implementation on a receiving node. For awareness of the protocol implementation vulnerabilities, the protocol monitor instance230consults, for example, the Protocol Vulnerabilities Repository instance235associated with the particular protocol. Additionally, the protocol monitor instance230updates the protocol state database233according to the content of the received frame. The process of the Protocol Monitor Module instance230is shown in detail inFIG. 4.

The Load Monitor Module240, monitors the rate of frame arrival towards, for example, a particular destination address associated with a specific automotive component. If the frame arrival rate (calculated, for example, in frames per 10 milliseconds) exceeds, for example, a specific threshold, then the frame is deemed to comprise a cyber-attack. The frame arrival rate threshold is set, for example, by the management module270. The Load Monitor Module240maintains information relating to the ongoing monitoring of frame arrivals to different destinations in the Load Monitor State database245. The process of the Load Monitor Module240is shown in detail inFIG. 5.

The Pattern Matching Module250ensures that the frame does not contain specific bit patterns that are, for example, known to be associated with cyber-attacks. The Pattern database255, for example, contains a list of these patterns and is configured, for example, by the management module270. The process of the Pattern Matching Module250is shown in detail inFIG. 6

The Management Module270enables configuration of the other elements of the in-vehicle protection appliance140. The management module270may, for example, provide a graphical user interface and enable configuration of the features described herein. Alternatively, the Management Module270may, for example, provide a programming interface to an automated management system.

The process executed by the Component Access Policy module is illustrated inFIG. 3. At block310, the process receives a frame from, for example, a particular physical port. At block320, the process, for example, retrieves a list of source addresses (for example Ethernet source addresses) that are, for example, known to legitimately appear on frames arriving at the port. This list is stored, for example, in the Component Access Policy database225and is configured, for example, by the Management Module270.

At block330, the source address (for example an Ethernet address) is extracted from the frame. At block340, the process determines whether the frame's address appears in the list of source addresses known to be legitimate for receipt on the input port. If, for example, the address does not appear on the list, control moves to block350, and the frame is treated as suspicious (triggering, for example, blocking of the frame, or notification of a suspicious event).

If the address appeared on the list of legitimate addresses, then at block360the destination address (for example, an Ethernet address) is extracted from the frame. At block370, the process determines whether, for example, the component denoted by the frame source address is permitted by policy to send data to the component denoted by the frame destination address. The process accomplishes this determination by, for example, consulting a matrix located in, for example, the Component Access Policy database225which indicates which specific components are permitted to send data to which specific other components. This matrix in the Component Access Policy database225is, for example, configured by the Management Module270to denote which components are expected to legitimately communicate. For example, it may be the case that a vehicle's management console can legitimately access a camera, but that the braking system should not access the camera.

If the communication between components is legitimate, control moves to block380and the frame is not suspicious. If, however, the communication between components is not legitimate, control moves to block350, the frame is treated as suspicious, and, for example, a protective measure ensues.

The process executed by a protocol-specific Protocol Monitor Module instance is exemplary illustrated inFIG. 4. In block430, evaluates whether the frame conforms to the context-independent requirements of the frame's higher-level protocol. For example, a protocol monitor module for the TCP protocol may check, for example, that the flags field does not simultaneously specify two contradictory flag bits (such as SYN and FIN). If the frame does not conform to this protocol correctness check, in block4490the frame is regarded as suspicious, and, for example, protective action ensues.

Next, for example, the process begins to check for discrepancies that depend on the session context. In block.440, the process selects, for example, a control block containing session-specific state information. In the case of the TCP protocol, for example, the session may be identified by source address, destination address, source port, and destination port; and session-specific information may include, for example, current TCP sequence number and TCP receive window size. This control block resides, for example, in memory204.

In block450, the process selects, for example, a list of known protocol vulnerabilities for the specific protocol. The list is stored, for example, in the protocol vulnerabilities repository instance235and is configured by, for example, the management module270. Each element of the list comprises, for example, a list of frame fields and associated values (possibly including masks or wildcards), as well as zero or more session state variables with associated values (possibly including masks or wildcards). Each entry in the list thus denotes, for example, a weakness in either the protocol or in the implementation of the protocol that must be mitigated.

In block460, the process checks if there are entries remaining in the list. In block470, the process selects the next entry from the list. In block480, the processes evaluates whether the frame matches the vulnerability specified in the entry of the vulnerability list i.e. whether the frame fields and session control block fields match the values specified with the vulnerabilities table entry structure. If there is a match, then the frame is suspicious and, for example, protective actions are taken. If there is no match, then control returns to block460and the next vulnerability entry is selected. When the vulnerability entries are exhausted, then control moves to block495and the frame is deemed non-suspicious. In block498, the session control structure is updated to reflect the changes to session state resulting from the new frame.

This method for identification of protocol weaknesses is an example only. Alternatively, an embodiment may, for example, hardcode the protocol weaknesses into software, so that no database is needed.

The process executed by the Load Monitor Module is illustrated inFIG. 5. In block510, the process selects, for example, a destination-specific load control block. The load control block resides, for example, in memory204, and includes information on load such as, for example, average frames per second received, average frame interarrival time, or the like.

In block520, the process updates the information in the load control block to reflect the receipt of the latest frame. If the load, measured for example in frames-per-10-milliseconds exceeds a specific threshold, then in block550the frame is regarded as suspicious and, for example, protective action ensues. If the threshold is not exceeded, then control moves to block540and the frame is regarded as non-suspicious.

The process executed by the Pattern Detection Module is illustrated inFIG. 6. In block610, the process selects, for example, the most recently updated list of bit patterns that are indicative of a suspicious frame. This list resides, for example, in the Pattern Database255. In block620, the process checks if entries reside in the list. If so, then at block640the next entry is selected, and at block650the process searches for the bit pattern in the newly received frame. If the pattern is detected, then at block660the frame is regarded as suspicious and, for example, protective action ensues. If the pattern is not detected, control returns to block620. When the list of bit patterns is completed, control moves to block630and the frame is not regarded as suspicious.

The invention has been described in detail for an embodiment that performs a series of processes to identify a suspicious frame and enable a protective action in response. It will be understood that an embodiment may, for example, omit one or more of these processes, or, for example, perform the processes in a different order from the order described herein. Similarly it will be understood that an embodiment may, for example, separate the processes described herein into smaller processes, or combine these subprocesses in manner different from the combinations described herein

As will be understood with reference to the paragraphs and the referenced drawings, provided above, various embodiments of computer-implemented methods are provided herein, some of which can be performed by various embodiments of apparatuses and systems described herein and some of which can be performed according to instructions stored in non-transitory computer-readable storage media described herein. Still, some embodiments of computer-implemented methods provided herein can be performed by other apparatuses or systems and can be performed according to instructions stored in computer-readable storage media other than that described herein, as will become apparent to those having skill in the art with reference to the embodiments described herein. Any reference to systems and computer-readable storage media with respect to the following computer-implemented methods is provided for explanatory purposes, and is not intended to limit any of such systems and any of such non-transitory computer-readable storage media with regard to embodiments of computer-implemented methods described above. Likewise, any reference to the following computer-implemented methods with respect to systems and computer-readable storage media is provided for explanatory purposes, and is not intended to limit any of such computer-implemented methods disclosed herein.

As used herein, the singular form “an” and “the” include plural references unless the context clearly dictates otherwise.

The above-described processes including portions thereof can be performed by software, hardware and combinations thereof. These processes and portions thereof can be performed by computers, computer-type devices, workstations, processors, micro-processors, other electronic searching tools and memory and other non-transitory storage-type devices associated therewith. The processes and portions thereof can also be embodied in programmable non-transitory storage media, for example, compact discs (CDs) or other discs including magnetic, optical, etc., readable by a machine or the like, or other computer usable storage media, including magnetic, optical, or semiconductor storage, or other source of electronic signals.

The processes (methods) and systems, including components thereof, herein have been described with exemplary reference to specific hardware and software. The processes (methods) have been described as exemplary, whereby specific steps and their order can be omitted and/or changed by persons of ordinary skill in the art to reduce these embodiments to practice without undue experimentation. The processes (methods) and systems have been described in a manner sufficient to enable persons of ordinary skill in the art to readily adapt other hardware and software as may be needed to reduce any of the embodiments to practice without undue experimentation and using conventional techniques.