Patent Description:
From <CIT> there is already known an on-vehicle gateway interposed between a plurality of buses and adapted to perform appropriate control action in certain situations.

A method and system for providing virus detection is described in <CIT> entitled: "Method and system for virus detection using pattern matching techniques". An on-vehicle gateway that is interposed between a plurality of buses for transferring data, and that is capable of performing appropriate control according to situations, is described in European Patent Application <CIT>entitled: "On-vehicle gateway". (<NUM>) Data coming from one bus are analyzed to filter false data and unwanted data not to feed them to the other buses. (<NUM>) When the state of an on-vehicle device is inquired, it is controlled according to the state of an IG power source whether the inquiry is to be made to the device or the on-vehicle gateway answers the inquiry by proxy. (<NUM>) The response of the gateway is changed according to the place where a vehicle is traveling. For example, control is performed such that, while the vehicle is traveling on a local road, the transmission/reception of a mobile telephone is available by using a hands-free system, and that, while the vehicle is traveling on an expressway, the transmission! reception of a mobile telephone is unavailable even by using the hands-free system. (<NUM>) The response of the gateway is changed according to a driver. For example, if the years of driving experience of the driver is within one year, the gateway stops data transfer so that no television screen or navigation screen is displayed during driving, and that the transmission! reception of the telephone by the hands-free system is unavailable.

The term "Electronic Control Unit" (ECU) denotes herein any electronic system within a vehicle with processing capabilities (e.g. a radio system is an ECU while a wiper controlled by a relay is not). An electronic control unit is a type of electronic component within a vehicle electronic system.

Some ECUs include an external communication interface, i.e. an interface to communicate with components outside the vehicle's electronic system including outside the vehicle itself. ECU also stands for "Engine Control Unit" which is a special case of an Electronic Control Unit.

A bus (also referred to as communications bus) is a shared wired or wireless communication channel over which different components transfer data from one to another.

Controller Area Network (CAN or CAN bus) is a vehicle bus standard designed to allow electronic systems to communicate with each other within a vehicle without a host computer (no master required on the bus). ECUs in a vehicle usually communicate by accessing a CAN bus. CAN bus is also used in systems that are not a vehicle, such as Industrial Control Systems, and the invention encompasses uses of CAN bus or any similar bus in any system. For simplifying the description, most examples will refer to CAN bus and a vehicle.

Filter element denotes an element with two interfaces that upon receiving a message either discards it, changes it or passes it according to various conditions e.g. message ID value. The filter element is the part of the security system of the invention which is in charge of the logic of the filtering, e.g. classifying, analyzing and acting upon the messages received. The filter element can be either a hardware module, a software module, or a hardware and software module. The filter element may contain an additional logic module for supporting more actions, such as generating messages itself, maintaining an inner state, or any other action.

The term proxy element as referred to herein denotes an element with at least one communication interface that holds the current state according to past communication. The proxy element can send messages to its interface(s) according to its current state, the current input (e.g. a message) and the time (e.g. an independent process that sends keep-alive messages periodically). This element is usually used to allow two parties to communicate with each other indirectly.

An attack vector is a path or means by which an attacker can gain access to a computerized device in order to deliver a payload which will cause a malicious outcome. An automobile has numerous attack vectors, including supply chain, physical access to the automotive communication bus, physically replacing one of the vehicle's ECUs, using one of the ECUs' standard connections to the external world etc..

The disclosure assumes that most of the threats originate from ECU's connections to the external world. The disclosure assumes each of the ECUs, except the suggested security system (or device), is potentially vulnerable to attacks that might execute malicious code on it and may gain control over it. The attack on each ECU may be achieved using any of its data connections (physical or wireless).

Security system denotes a system (that may be implemented also as a device) for protecting an electronic component or bus within a vehicle electronic system or other industrial control system, embodiments of which are described in this disclosure. In some embodiments the security system is a stand-alone system as described in the STAND-ALONE SYSTEM and the GATEWAY SYSTEM sections. In some embodiments the security system is integrated inside another system as described in the INTEGRATED SYSTEM section. The security system can also be denoted by "communication filter/proxy".

Automobiles are becoming more sophisticated and increasingly use computerized technology (ECU - electronic control unit) to control critical functions and components such as brakes and airbags functionality. While the computerized technology enhances the performance of the vehicle, compromising the operation of one of these safety-critical ECUs may cause severe damage to the vehicle, its passengers and potentially even the surroundings if the vehicle is involved in an accident with other vehicle(s) or pedestrians.

These ECUs are usually connected via a non-secure manner such as through CAN bus. Taking control of the vehicle's communication bus can result in compromising the safety critical ECUs (see "<NPL>).

Some of the ECUs which are connected to the vehicle's communication bus have external connections, such as the telematics computer and the infotainment system. It is possible to compromise one of these ECUs using a cyber-attack. The compromised ECU serves as an entry point to deploy the aforementioned attack, see "Comprehensive Experimental Analyses of Automotive Attack Surfaces", Checkoway et al-. , (see www. org/pubs/cars-usenixsec2011.

<FIG> and <FIG> present a simple vehicle's communication network of the art consisting of a single bus.

<FIG> shows a vehicle electronic system <NUM> comprising a plurality of ECU's <NUM> connected to a vehicle communication bus <NUM>. The ECU's <NUM> communicate with each other over the communication bus <NUM>. A vehicle electronic system <NUM> may contain multiple communication buses <NUM>, each connected to one or more ECU's <NUM>.

<FIG> displays a more detailed view of a vehicle electronic system <NUM> comprising a plurality of ECU's with external connections <NUM>, safety critical ECU's <NUM> and other ECU's <NUM> (without external connection and non-safety critical).

ECU's with external connections <NUM> include (but are not limited to) telematics <NUM>, infotainment system <NUM>, Tire Pressure Monitoring System (TPMS) <NUM>, vehicle to vehicle (V2V) or vehicle to infrastructure (V2I) communication ECU <NUM> and any combination of ECUs with an external connection not specifically mentioned <NUM>.

Safety critical ECU's <NUM> include (but are not limited to) the engine control unit <NUM>, brake control module (ABS/ESC etc.) <NUM>, airbag control unit (ACU) <NUM>, transmission control unit (TCU) <NUM>, and any combination of safety critical ECUs not specifically mentioned <NUM>.

Other ECU's <NUM> denote the set of ECUs that do not have an external connection and are not safety critical, which include the convenience control unit (CCU) <NUM> and any combination of ECUs which fall under this category but are not specifically mentioned <NUM>. All the ECUs <NUM> communicate using the same shared communication bus <NUM>. There is an external connection to the electronic system <NUM> using the telematics ECU <NUM>. The telematics ECU <NUM> communicates using the illustrated wireless connection <NUM> with a wireless transceiver <NUM>.

A vehicle electronic system <NUM> can be attacked where an external communication source (transceiver) <NUM> establishes a communication line <NUM> to an ECU, in this example the Telematics ECU <NUM>.

Vehicle theft using CAN bus manipulation becomes more and more popular as seen in www. com/<NUM>/<NUM>/<NUM>/keyless-bmw-cars-prove-to-be-very-easy-to-steal/.

Another financial threat that worries OEMs and Tier-<NUM> suppliers is unauthorized ECU <NUM> replacement. The owner of a vehicle may replace an existing ECU <NUM> with an unauthentic/unoriginal one, for several reasons:.

The damage to the OEMs and Tier-<NUM> suppliers is both because their original equipment isn't bought, and because the unauthorized replacement might damage the vehicle which is still under warranty which they have to cover.

A vehicle's communication bus <NUM> is an internal communication network that interconnects components inside a vehicle. Examples of protocols include CAN, Local Interconnect Network (LIN), FlexRay, Vehicle Area Network (VAN) and others.

<FIG> and <FIG> present a simple vehicle's electronic system of the art consisting of a single bus.

<FIG> and <FIG> present a vehicle's electronic system of the art consisting of several buses <NUM> or bus segments <NUM>. Each bus segment <NUM> may consist of a different type of communication protocol or of the same communication protocol but possibly with a different configuration.

<FIG> illustrates an example of a vehicle's internal electronic system, comprising of several ECUs <NUM>, <NUM> and <NUM> connected to a slow communication bus <NUM> and several ECUs <NUM>, <NUM>, <NUM>, <NUM>, <NUM> and <NUM> connected to a fast communication bus <NUM>. A bridge or a gateway <NUM> connects the two buses <NUM> and <NUM>.

<FIG> is a more general example of the vehicle's internal electronic system <NUM> illustrated in <FIG>, where three communication busses <NUM> are connected by a gateway or bridge <NUM>. Each communication bus <NUM> has a set of ECUs <NUM> connected to it.

A gateway or bridge <NUM> connects several bus segments <NUM> and allows messages to pass between them. A bridge <NUM> is described, for example, in <CIT> entitled "BRIDGE MODULE". A gateway <NUM> is described, for example, in <CIT>, entitled "GATEWAY FOR DATA BUS SYSTEM".

Gateways and bridges <NUM> are designed to transfer messages between bus segments <NUM> in a reliable manner but are not designed from a cyber-security perspective. One perspective of cyber-security-directed design, as opposed to reliability-directed design, is message filtering. Usually a bridge or a gateway <NUM> will not discard messages out of the concern that these messages will be needed and their absence will cause harm. Some gateway <NUM> designs exhibit monitoring abilities of selected messages such the one described in <CIT>. When monitoring the communications, selected messages are sent to a monitoring interface (described below). The selective monitoring is often referred to as filtering; however this type of filtering does not interfere with the original communication.

A monitor is a device delivering messages being sent on a bus <NUM> (or their properties) to a diagnostic device. A monitor is either a standalone device or a module/part in another device such as a gateway <NUM>. A standalone monitor is described in <CIT>, entitled "DEVICE AND METHOD FOR DIAGNOSIS ON MULTI-CHANNEL-CAN-APPLICATION". Some of these monitors selectively monitor messages but do not intervene with the communication on the bus <NUM>.

Encryption is a common method to address authentication problems. Encryption methods for CAN bus <NUM> are described in <CIT>, entitled "SECURE COMMUNICATIONS BETWEEN AND VERIFICATION OF AUTHORIZED CAN DEVICES" and <CIT>, entitled "CONTROL AREA NETWORK DATA ENCRYPTION SYSTEM AND METHOD".

While encryption can be the basis for authentication, from a system perspective it is not a viable solution for the automotive environment. The automotive environment consists of many vendors and devices. These devices are usually simple and have little processing power.

For an effective encryption scheme, either a key exchange or specific preloaded keys are required. These are quite complicated processes given the limitations of the automotive industry and the devices described above.

The CAN bus <NUM> is usually quite slow and encryption demands additional bandwidth which may slow down the communication even further, and could impact overall system performance.

<FIG> is a schematic drawing of a Firewall integration of the art. A firewall is a device, or set of devices, designed to permit or deny network transmissions based upon a set of rules and is frequently used to protect networks from unauthorized access while permitting legitimate communications to pass.

<FIG> illustrates two networks A and B <NUM> separated by a firewall <NUM>. Each network <NUM> has at least one computer <NUM> connected to it.

A firewall <NUM> is usually designed for Internet Protocol (IP)-based networks <NUM> and uses the IP and Transmission Control Protocol (TCP) characteristics of the communication. Currently, there are no firewalls <NUM> intended for CAN bus <NUM>. CAN messages differ from IP messages in many aspects such as size, headers, content etc..

The assumptions of IT firewall <NUM> designers differ from the assumptions required in designing a protection for a safety critical system. A false positive or a false negative identification of a message in the IT arena usually does not have a direct physical impact (unlike the industrial control systems (ICS) arena where computers control physical processes such as temperature, pressure, engines etc.). An automotive involves human lives and ECUs <NUM> directly influence the automobile's functionality; therefore a traditional firewall <NUM> is not applicable in this case.

Firewall <NUM> implementation for a native CAN BUS communication bus <NUM> does not exist. In general, Industrial Control Systems (ICS) security solutions lack filters and firewalls <NUM> and usually exhibit a diode (one way communication) and network separation solution. These solutions are not viable for an automotive since an automotive requires two-way communications.

The invention is defined by the subject-matter of the independent claim.

In the following detailed description of various embodiments, reference is made to the accompanying drawings that form a part thereof, and in which are shown by way of illustration specific embodiments in which the invention may be practiced.

The figures described herein illustrate blocks. Each block can represent any combination of hardware, software and/or firmware which performs the functions as defined and explained herein.

Modern vehicles increasingly use more efficient computerized, electronic components and sub-systems instead of mechanical parts. Such systems are controlled by ECUs <NUM>, which are connected through one or more communication buses <NUM>. In case that more than one communication bus <NUM> exists, the buses <NUM> are usually connected using bridges or gateways <NUM>. Some of these ECUs <NUM> controlled systems are safety critical systems <NUM>, such as the engine control unit <NUM> or the brake control module <NUM>, and some are less critical or non-critical systems, such as infotainment systems <NUM> and wireless tire pressure sensors <NUM>. Some of the systems mentioned above are ECU's with external interfaces <NUM>, for example, the tire pressure sensors <NUM> communicate wirelessly with a receiver on the bus <NUM>, the radio <NUM> has wireless (radio, Radio Data System (RDS), etc.) and local (e.g. media files) interfaces and the telematics <NUM> (e.g. On-Star™) has a cellular interface <NUM>.

Though these interconnected computerized systems <NUM> offer the user increased performance of the vehicle and additional services, there is an inherit danger in such architecture wherein anyone who gets access to a communication bus <NUM> of the vehicle may maliciously interfere with the proper operation of the systems <NUM> communicating over the bus <NUM>, among them the safety critical systems <NUM>. There are many ways such attacks can be accomplished once access is gained to a communication bus <NUM>. Some examples include: attacking any system <NUM> directly; sending messages constantly over the bus <NUM> preventing others from communicating (denial of service); impersonating to other devices <NUM> sending false messages; sending messages that will have a harmful effect (press the brakes, disable the Anti-Lock Braking System <NUM>, etc.); sending messages to limit the functionality of a part <NUM> (limit speed etc.), etc. In today's vehicle architecture, there is no secured isolation between the safety critical systems <NUM> and the other systems <NUM> and <NUM>.

The present invention relates to a cyber-security-directed design which selectively intervenes in the communication path in order to prevent the arrival of malicious messages at ECUs <NUM> (in particular at the safety critical ECUs <NUM>). The security perspective suggests that more damage can be caused by passing a potentially unwanted message than by blocking or changing it. However, there may be reliability implications. In a cyber-security-directed design, reliability issues can be solved using methods described herein.

The security system of the invention includes a filter which prevents illegal messages sent by any system or device <NUM> communicating over the communications bus <NUM> from reaching their destination. The filter of the invention may, at its discretion according to preconfigured rules, change the content of the messages or limit the rate such messages can be delivered, by buffering the messages and sending them only in preconfigured intervals. The rules in the filter of the invention, which determine which messages are allowed and which are not allowed and the rate of the messages, can be configured using an external interface of the filter. The security system can be located, for example, between each system component which has an external interface <NUM> and the communication bus <NUM>, protecting the bus <NUM> and the electronic devices <NUM> connected to it from the component <NUM>.

The security system of the invention has at least two bus <NUM> interfaces and can filter messages in each direction. The filtering is done in any appropriate way, for instance, according to the message's properties (such as message headers, data, etc.) and/or according to inner state properties of the security system (such as the physical interface through which the message was sent, the timings, etc.) or any combination of the above.

In some embodiments, the security system has proxy capabilities. A proxy saves the state of the communication protocols over one or more of its physical interfaces. It also independently manages the communication protocol over each of its interfaces (such as sending keep-alive messages to the radio without involving other components <NUM>).

In some embodiments, the security system has gateway <NUM> capabilities. It can connect two or more communication buses <NUM> which may have different physical properties.

In some embodiments, the security system can save its configurations in a non-volatile memory, and the configurations and the non-volatile memory may be updated from an external source.

In some embodiments, the security system may save statistics, monitoring data etc. internally for later usage, for example, when such data is read externally later.

In some embodiments, the security system can internally update the non-volatile memory contents.

In some embodiments, the security system can be integrated inside current ECUs <NUM>, between the physical driver and the logical part of the ECU <NUM>, saving the need for additional physical interfaces for the security system. In other embodiments, the security system can be a stand-alone security system. The stand-alone security system of the invention can be coupled to a single ECU <NUM>, coupled to a plurality of ECU's <NUM> or not coupled to any ECU <NUM>.

In some embodiments, the security system can be integrated into a system containing one or more communication buses <NUM> and ECUs <NUM>. It can learn the communication properties of the different parts <NUM> of the system, build filtering rules in an autonomic fashion, and filter when the learning phase is over.

Some embodiments may include a combination of any of the aforementioned embodiments.

Other aspects of the currently disclosed subject matter will become apparent by consideration of the detailed description and the accompanying drawings.

There are several potential embodiments of the invention from a system integration point of view. In some embodiments, the security system will act as a protection system or device between at least two communication buses <NUM> or components <NUM>.

Attacking an automobile (without physically tampering or pre-installing a backdoor) requires logical access to its electronic components <NUM>. The suggested integration positions of the security system of the invention, according to some embodiments, prevent an improper logical access originating from external interfaces <NUM> from reaching safety critical components <NUM>. Therefore, the integration of the security system can protect from life threatening cyber-attacks. Assuming the security system is configured correctly, a potentially hermetic protection is achieved.

In some embodiments, when dealing with chip tuning, unauthorized ECU <NUM> replacement and vehicle theft, the security system of the invention can be coupled with ECUs <NUM> that need to be protected and/or authenticated (e.g. antitheft ECU <NUM>, immobilizer <NUM>, engine control unit <NUM>, etc.).

If the security system has a configuration port, in some embodiments the configuration port will not be connected to any untrusted communication buses <NUM>.

In some embodiments, the configuration port can be connected in-band, i.e. to one or more of the communication buses <NUM>, given it is protected in some manner. In some embodiments, this in-band configuration is optional and can be disabled after the initial configuration stage (e.g. during vehicle manufacturing or assembly) is completed. In some embodiments, special configuration messages sent over the communication bus <NUM>, will be transferred to the configuration interface for processing, and will cause a change in the configuration.

<FIG> illustrates stand-alone security system integration, according to some embodiments. <FIG> is an illustration of the electronic system <NUM> illustrated in <FIG> protected by standalone security systems (referred to as communication filter/proxy devices) <NUM> of the invention. All ECUs with external communication interfaces <NUM> are protected by stand-alone communication filter/proxy protection devices <NUM>. The ECUs <NUM> are connected to the security system <NUM> via an interface <NUM>. The interface <NUM> can be any communication interface including a communication bus <NUM>.

In some embodiments, the security system <NUM> is a stand-alone system or device. The security system <NUM> has at least two communication interfaces and may additionally have a configuration port.

In some embodiments, the security system <NUM> is placed between an ECU that has an external interface <NUM> (physical or wireless e.g. radio or telematics) and the communication bus <NUM>. Each ECU which has an external connection <NUM> may be serially connected to the security system <NUM> in order to protect other ECUs <NUM> from the communication originating from it.

In some embodiments, the security system <NUM> is integrated with ECUs that don't have an external interface <NUM> in order to deal with threats such as vehicle theft, chip tuning, unauthorized ECU <NUM> replacement etc..

In some embodiments, the power supply to the security system <NUM> is either external or originates from the communication interfaces (a dedicated line or bootstrapped from the communication bus <NUM>).

Optionally, the stand-alone security system <NUM> can electrically drive the communication bus <NUM> attached to it (e.g. provide negative voltage and termination on a CAN bus <NUM>). This option may be configurable for each of the communication ports, depending on the implementation. This option emulates the physical properties of the bus <NUM> towards any segment it is connected to. In case of retrofitting; it saves the need to install an additional physical driver to the bus <NUM>.

In some embodiments, this integration allows for the retrofitting of an automobile, without replacing existing ECUs <NUM>.

In some embodiments, when each security system <NUM> generally handles only one ECU <NUM>, its configuration and operation is rather simple, and it can be implemented with simple hardware architecture (compared to other alternatives).

In some embodiments, the security system either replaces an existing gateway/bridge <NUM>, as shown in <FIG>, or is integrated between a gateway/bridge <NUM> and one of their connected communication buses <NUM> as shown in <FIG>.

Optionally, the security system <NUM> can electrically drive the communication bus <NUM> similarly to the stand-alone security system or device <NUM> described above.

In some embodiments, if the security system <NUM> replaces an existing gateway/bridge <NUM>, it will also function as one (e.g. converting protocols, connecting the buses <NUM>).

In order for this type of integration to be effective, an appropriate architecture of the automobiles' communication buses <NUM> must be implemented. In some embodiments, the design may have to include a security system of the invention <NUM> in every path between a safety critical ECU <NUM> and an ECU with an external interface <NUM> (e.g. all the ECUs with an external connection <NUM> are connected to a single segment <NUM>, separated from the other ECUs <NUM> by a security system <NUM>).

In some embodiments, such integration allows for the retrofitting of an automobile without replacing existing ECUs <NUM>.

In some embodiments, each security system <NUM> has to handle the communication of several ECUs <NUM> connected to the bus. Therefore, the configuration and implementation is potentially more complex, and more complicated hardware is required. Such design may require an integration of a single security system <NUM>. On one hand, such a security system <NUM> may be more complex and expensive. On the other hand, it substitutes multiple simpler security systems <NUM>; therefore it may be financially worthwhile. Additionally, the design requires a single point of configuration which may become more convenient for design and maintenance.

In some embodiments, the security system <NUM> is integrated inside an ECU <NUM> as depicted in <FIG>. The security system <NUM> has at least two communication ports <NUM> and <NUM>, one <NUM> connected to the physical layer driver <NUM> and the other <NUM> connected to the rest of the ECU's logic <NUM> (e.g. ECU's controller) using its native physical layer (e.g. Complementary Metal Oxide (CMOS) or Transistor Transistor Logic (TTL)). The physical layer driver <NUM> is connected to the communication bus <NUM>.

In some embodiments, the integration of the security system <NUM> inside an existing ECU <NUM> will save many components (e.g. power supply, mechanical casing, physical drivers etc.) thus making the design cheaper and more robust.

In some embodiments, the security system <NUM> will be integrated in the same ECUs <NUM> (those with external interfaces <NUM>) and with the same configurations as in the case of a stand-alone security system <NUM>.

In some embodiments, integration will enable a supplier of ECUs <NUM> to integrate a security solution <NUM> done by a trusted 3rd party, thus providing a complete and secure ECU <NUM>.

In some embodiments, this solution will not allow for retrofitting into existing ECUs <NUM>. However, it will be viable for new designs. This solution embodies all of the advantages of the stand-alone security system <NUM>.

When referring to an ECU <NUM> coupled with a security system it may also refer to an ECU with an integrated security system as in the case of <NUM>.

For clarity reasons, the security system's <NUM> core which is responsible for the security aspects of the security system <NUM> (e.g. filtering or serving as a proxy) is referred to in some embodiments described herein as "filter element" or "proxy element". However, it is possible that an element designated as "filter element" may also provide proxy functionality, and/or an element designated as "proxy element" may also provide filter functionality. All these variations and combinations are encompassed by the present invention.

Additionally, for simplicity's sake the message flow is depicted in some embodiments herein as if a simple rule based filter is used, although a more complex rule based filter can be applied and is encompassed by the present invention. For example, multiple rules can be applied to the same message.

<FIG> illustrates the security system's <NUM> general overview, in which the filter/proxy element <NUM> (which functions as the message classification unit and the message analyzer unit) connects to two communication buses <NUM> using two message handlers <NUM>, according to some embodiments of the present invention. In some embodiments, the filter/proxy element <NUM> receives messages from one of these buses <NUM> through an input buffer <NUM> (of the message handler <NUM>), filters these messages, and sends the filtered messages through the appropriate output buffer <NUM> (of the message handler <NUM>), to the other communication bus <NUM>. The security system <NUM> can also serve as a filtering gateway between two different buses <NUM> and do any necessary conversions (such as protocol conversions) between the buses <NUM>, as seen in <FIG>.

In some embodiments, as seen in <FIG> the security system <NUM> can be configured by an external device (e.g. configuration / diagnostics computer) <NUM>, through an out of band (OOB) interface such as a serial connection (e.g. RS-<NUM>). The configuration affects the security system's <NUM> behavior, the messages it lets through, changes or blocks, and any other of its configurable properties. The new configuration can be saved so next time the security system <NUM> resets, the new configuration will run at startup.

The message handler <NUM> includes (<NUM>) a message receiving unit for receiving a message to its input buffer <NUM> from the communication bus <NUM>; and (<NUM>) a message transmission unit for transmitting a message from its output buffer <NUM> to the communication bus <NUM>.

<FIG> illustrates the security system's <NUM> top view in more detail than illustrated in <FIG>, according to some embodiments of the present invention. Messages arriving into message handler <NUM> (described in more detail in <FIG>, and also functions as the message receiving unit and the message transmission unit) through the physical interface I/O <NUM>, or any other interface of it, are sent to the proper interface. If sent to the configuration interface, it will be handled by the configuration, statistics and control module <NUM> which can handle it in any configured way (e.g. send it through the OOB interface I/O <NUM> out of the system for logging, inspection, or any other purpose). If the message is sent to the filter/proxy element <NUM>, it inspects it and decides whether to send it to the destination interface or not. If the message is to be sent to the destination interface by the filter/proxy element <NUM> (combined message classification unit and message analyzer unit), it is sent to the appropriate message handler <NUM>. The message handler <NUM>, handles the message in some embodiments as depicted in <FIG> and <FIG>, and sends it to the proper destination interface (e.g. physical interface I/O B <NUM>). The interfaces <NUM> between the message handlers <NUM> and the filter/proxy element <NUM> are named "proxy interface" and they fit both filters and/or proxies (they can also be referred to as "filter interface" or "filter and/or proxy interface").

Some embodiments of the described process are illustrated in <FIG>. In step <NUM>, a message is received in the message receiving unit of the message handler's <NUM> interface, e. g by its physical interface, and is sent to one or more of its interfaces in step <NUM>. If the message is to be sent to the physical interface, it's sent to its physical interface in step <NUM>. If the message is to be sent to the configuration interface <NUM>, it is handled by the configuration interface <NUM> according to its functionality, e.g. printed on the screen of the operator, written to a log, etc. in step <NUM>. If the message is to be sent to the filter/proxy interface <NUM>, it is sent to the appropriate filter element <NUM>, and is classified by its message classification unit in step <NUM>, which sends it to the filter element's message analyzer unit. The filter element <NUM> then checks the legality of the message (by the message analyzer) in step <NUM>. If the message is illegal, it will be discarded in step <NUM>. If the message is legal, it is sent to its destination (which can be the opposite message handler <NUM>) in step <NUM>.

<FIG> depicts the simple form of the message handler mechanism <NUM> each (filter/proxy element <NUM>) interface has, according to some embodiments of the present invention. In some embodiments, each message arriving from a physical interface <NUM> is processed by a message receiving unit of a message handler <NUM> and sent to the input buffer <NUM> of the filter/proxy element <NUM>. Each message which originates from another interface's message handler and is destined to interface <NUM> and allowed by the filter/proxy element <NUM> is sent to the appropriate output buffer <NUM>. From the output buffer <NUM> it is sent to the message transmission unit of the message handler <NUM> and sent out to the physical interface <NUM>. The message receiving unit and the message transmission unit can be either separate units, or integrated together into a message handler <NUM> for more efficient two-way communications with a communication bus <NUM>.

<FIG> describes a more complex form of the interface's message handler <NUM> than described in <FIG>, according to some embodiments of the present invention. Each message arriving from a physical interface I/O <NUM> to the physical interface <NUM> through the transceiver <NUM> goes into the routing component <NUM>. The routing component can determine the message's inner headers (such as message source or any other information about the message) and then decides towards which destination to send the message, according to its routing algorithm. The possible destinations include, but are not limited to, zero or more of the interfaces illustrated in the figure through their respective input buffers, such as: the physical interface <NUM>, the filter/proxy interface <NUM> or the configuration module interface <NUM>. There can be any number of other such interfaces as well. The message is sent to the proper interface which handles it. The routing component <NUM> can be configured through the configuration module <NUM> (the configuration dataflow is not explicitly drawn), to change its behavior, such as changing its routing tables or routing algorithm. Messages arriving from the filter/proxy element <NUM> through its I/O interface <NUM> are sent to the routing component which sends them to the proper interface as described above. Messages arriving at the configuration module interface <NUM> from the routing component are sent to the configuration module <NUM> through the configuration output buffer <NUM> and the external interface transceiver <NUM>. The external interface transceiver <NUM> can be implemented as a software and/or hardware module. In some embodiments, the external interface transceiver <NUM> is optional and can be omitted. The configuration module <NUM> handles messages in various ways, e.g. print on the operator screen (if such thing exists), and can be used for any purpose, e.g. inspection, sending messages, controlling or debugging the system. <FIG> describes the message flow in the interface's message handler <NUM>, according to some embodiments. A message is received by the message receiving unit in one of the message handler's interfaces in step <NUM>. The message headers of the message can then be determined in step <NUM>, and the message's appropriate routing is decided in step <NUM>. The message is then sent to its destination interface in step <NUM>. The classifier and analyzer are part of the filter/proxy element <NUM>, so only if the message is directed to the filter/proxy element <NUM> they will handle it. The other options routing a message are to the physical interface <NUM> or the configuration interface <NUM>. Since the classifier and analyzer are not part of the message handler, <NUM> they are not described here. The interface's message handler <NUM> may collect and save any statistics information about the system and the messages being sent to it or from it (e.g. the number of messages that were received from or sent to each interface).

In some embodiments, each filter element <NUM> is coupled with at least <NUM> such message handlers <NUM> and each proxy element <NUM> is coupled with at least one such message handler <NUM>, one for each interface that they are connected to.

The "configuration module" <NUM> denotes the "configuration, statistics and control module" <NUM> (some embodiments being illustrated in <FIG>).

In some embodiments, the configuration module <NUM> is connected to the Interface's messages handler <NUM> using two types of connections: a messages connection <NUM> and a configuration connection <NUM>. The configuration module <NUM> can send or receive messages to/from the interface's message handler <NUM> through the messages connection <NUM>. The configuration module <NUM> is connected to the filter/proxy element <NUM> using a configuration connection <NUM>. The configuration module <NUM> controls the configuration of the filter/proxy element <NUM> and the message handlers <NUM> through the configuration connection <NUM>, changing their behavior, logging their activities, and/or any other configurable change they support. This module <NUM> is controlled externally using an OOB interface (external interface I/O) <NUM>, which can be any data interface (e.g. Universal Asynchronous Receiver Transmitter (UART) interface). The configuration module <NUM> can also have a non-volatile memory <NUM> connected to it (e.g. flash memory). This memory <NUM> stores data which is used by the configuration module <NUM>. Such data can include, but is not limited to, different system configurations to be loaded into the system components (e.g. the filter elements <NUM> and the interfaces' message handlers <NUM>), and statistical information. It might also, but not necessarily, be possible to manipulate this memory <NUM>, through the OOB interface <NUM> or directly. Such manipulation may include, but is not limited to, deleting the memory, copying it, dumping it, copying new information into it, etc..

In some embodiments, the configuration module <NUM> can be connected in-band, i.e. to one or more of the communication buses <NUM>, given it is protected in some manner. In some embodiments, this in-band configuration is optional and can be disabled after the initial configuration stage (e.g. during vehicle manufacturing or assembly) is completed.

<FIG> illustrates a simple example of a filter/proxy element (combined message classification and message analyzer units) <NUM>, built from two interface filtering components <NUM>, according to some embodiments of the present invention. Each interface filter component <NUM> filters messages arriving from its input interface (message receiving unit) and sends them after filtering to its output interface (message transmission unit). A more detailed example of <NUM> is illustrated in <FIG>, according to some embodiments. A message arrives from the proxy interface input <NUM> of the message handler <NUM>, and goes into the rule selector <NUM> of the message classification unit (also referred to as classifier), which according to the message properties (such as headers, source, destination, data, or any other properties) sends it to the proper rule <NUM> in the message analyzer unit. If no proper rule is found, the rule selector rejects the message according to its policy (possible policies are described below). The appropriate rule <NUM> (of the plurality of rules <NUM>) which receives the message checks it more thoroughly and decides whether the message should be allowed or not, or should be modified. The action upon the result of a rule <NUM> is part of the message analyzer's unit. If the message should be allowed, the rule <NUM> passes the message to the proxy interface output <NUM> connected to the message transmission unit of the message handler <NUM>. If the message should be changed, the rule <NUM> (of the analyzer) can make the necessary changes and pass the message to the proxy interface output <NUM> connected to the message transmission unit. In some embodiments, if the message should not be allowed, the rule selector <NUM> is notified and it chooses the next proper rule <NUM> for the message or rejects the message according to its policy. If no more proper rules <NUM> are found, the rule selector <NUM> acts according to its policy in such case. The rule selector <NUM> policy may include, but is not limited to, discarding the message, notifying the sender, or performing any preconfigured action. A rule <NUM> can be of any type and can also be timing rule as will be described below. A rule <NUM> may require that a message is signed, that a message signature is verified, or conditional transmission of a message as described in the authentication module section below. It should be clear that the term rule <NUM> encompasses any combination of a plurality of rules <NUM>, thus more than a single rule <NUM> can apply to any one message. The number of rules <NUM> is not limited and can vary. In some embodiments, the configuration module <NUM> may also control the adding or removing of rules <NUM> dynamically. A rule <NUM> can contain any filtering logic to decide whether a message is legal or not. Such logic may include but is not limited to, properties of the message, message's headers, message's content, message length, the filter state, timings of the message or any other parameters or properties or any combination of these properties, in a whitelist or blacklist manner. An example of a filtering logic can be checking that the message destination is 'y', the ID of the message is between 'xx' to 'zz', the message data length is <NUM> and the first two bytes of the message are 'aa' and 'bb'.

<FIG> illustrates an example of the filter logic and the message flow described, according to some embodiments. The message is received in the proxy interface input in step <NUM> and is delivered to the message classification's unit rule selector <NUM>, which selects the next appropriate filter rule <NUM> to filter the message with in step <NUM>. If no appropriate rule <NUM> was found, the message can be discarded in step <NUM>. If a rule <NUM> was found, the message is checked by the rule <NUM> (by the message analyzer unit) for its legality according the rule <NUM> in step <NUM>. If the message is not legal according to the rule <NUM>, it returns to the rule selector <NUM> to select the next appropriate rule <NUM> in step <NUM>. In some embodiments, if the message is legal according to the rule <NUM>, it is sent to the proxy interface output <NUM> in step <NUM>.

<FIG> describes a timing rule <NUM>, which is a type of rule <NUM> that can be added to the rules <NUM> list (e.g. as rule <NUM>) in the filter element <NUM> described above, according to the present invention. The difference between a timing rule <NUM> and a regular rule <NUM> is that the timing rule <NUM> does not only filter the incoming messages, but it also applies rate limit according to a policy which can also include traffic shaping of the communication, for example, sending messages to the proxy interface <NUM> in predefined timings (leaky bucket), thus preventing denial of service (DOS) attacks. When the rule selector <NUM> sends the received message to a timing rule <NUM>, the filtering logic <NUM> works as in a regular rule <NUM>. In case the message is allowed, it is sent through interface <NUM> to the rule output buffer <NUM>, in which it is buffered and waiting to be sent to the proxy interface output <NUM>. When the right timing arrives, the timing function <NUM> checks whether there are messages waiting in the output buffer <NUM>, and if so, pulls a message out through interface <NUM> and sends it to the proxy interface output <NUM>. In case the message is illegal, the filtering logic <NUM> will reject the message. In any case, be it a legal or illegal message, the rule selector <NUM> can be notified of the operation's result.

<FIG> illustrates an example of the timing rule <NUM> logic and the message flow described, according to some embodiments. The message is received in the proxy interface input <NUM> in step <NUM> and is being filtered as in a regular (not timing) rule <NUM> in step <NUM>) If the message is illegal, it is discarded in step <NUM>. In case the message is legal it is stored in the output buffer of the timing rule <NUM> and waiting to be sent in step <NUM>. When the time arrives, the timing task of the rule <NUM> transfers the message waiting in the output buffer to the transmission unit to be sent to its destination in step <NUM>. The advantage of using a timing rule <NUM> is preventing DOS attacks. Examples of such DOS attacks include, but are not limited to, rapid message sending and planed timing of message sending. Additionally this type of rule can help deal with malfunctions sending many messages over the communication bus <NUM> which leads to DOS. Another advantage is the ability of such filter to bridge between two buses <NUM> with different capabilities of handling messages pace. This type of filter <NUM> is quite simple to configure compared to other stateful filters and can handle many threats.

<FIG> illustrates the proxy element <NUM> design, according to some embodiments of the present invention. The proxy element <NUM> is connected to one or more message handlers <NUM> through interfaces <NUM>. Each proxy element <NUM> is composed of link emulators (one for each interface) <NUM>, and one state filter and updater <NUM>. A proxy element <NUM> emulates the operation of one bus <NUM> segment towards the other without allowing direct communication between the segments. All the messages transferred towards any segment using a proxy element <NUM> are created by the proxy element <NUM> using its state machines and rules (unlike a conventional filter that allows messages that are not blocked to pass).

In some embodiments, it is possible to use a proxy element <NUM> connected only to one message handler <NUM>, in case there is a need to emulate a disconnected side as if it was connected. An example to such case can be assembling a radio which needs a connection to the vehicle without making the connection, by emulating such connection using a proxy element <NUM>.

<FIG> illustrates one embodiment of a Link Emulator <NUM> which emulates a communication protocol between two or more participants toward the participants that are connected to its emulated side (e.g. if TCP is the protocol, the emulator will send Ack (Acknowledge) messages for each message received), according to some embodiments. The link emulator <NUM> manages and saves a state of the communication (e.g. if TCP is the protocol, the emulator will save a window of the Acknowledged messages). The state that the link emulator stores may include any data and meta-data related to received and sent messages. The link emulator <NUM> can update the state filter and updater passively or actively with its current state. The communication will be affected by the link emulator's state, the received messages and the time.

In some embodiments, the link emulator <NUM> illustrated in <FIG> consists of a protocol abstraction layer/high level driver <NUM>, a state machine <NUM> and state/configuration data module <NUM>. A protocol abstraction layer <NUM> acts as an abstraction layer of the communication protocols the proxy element <NUM> handles. It communicates in a relatively simple manner with the state machine <NUM>, by sending messages metadata, status and commands through interface <NUM>. The state machine <NUM> implements the logic the link emulator <NUM> includes. The logic the state machine <NUM> implements includes, but is not limited to, updating the state, immediately responding to events etc. (e.g. upon receiving a TCP message it updates the window stored in <NUM>, changing the state and sends an Ack message through the protocol abstraction layer <NUM>). The state/configuration data module <NUM> stores the current state of the link emulator <NUM> and can be accessed both by the state machine <NUM> and the state filter and updater <NUM>. The state machine <NUM> and the state/configuration data <NUM> modules communicate by sending states to each other through the state interface <NUM>.

In some embodiments, the state filter and updater <NUM> reads the state from each link emulator <NUM> using the read-state link <NUM> passively or actively and according to the proxy logic it configures the state on each of the link emulators <NUM> through the configuration link <NUM>. In some embodiments, messages are never directly transferred between link emulators <NUM>; the only communication between link emulators <NUM> is by using a state update. The state filter <NUM> will enable only legitimate states to pass between link emulators <NUM>.

In some embodiments, the logic of the proxy element <NUM> is either hardcoded or configurable.

Existing conventional stateful filters have an internal state machine that tries to emulate the state of the transferred messages and when the state machine discovers an anomaly, messages are discarded. When the filter's state machine is different than the state machine used by the communicating parties an inconsistent state may occur between the filter and the communicating parties, allowing forbidden communication to pass (e.g. different TCP timeout configuration). In some embodiments, allowing only a state to pass between the link emulators and correctly designing the proxy, can solve the aforementioned problem.

A proxy application example according to some embodiments of the currently disclosed subject matter is now described:
A radio <NUM> often uses the vehicle's integrated display to display information (e.g. radio station frequency). The example assumes a normal radio-vehicle communication is between the radio and the display system. The display system sends its model type and repeatedly sends a keep-alive message. The radio <NUM> communicates with the display system, queries the model type and sends display data according to the display's capabilities.

A proxy element application <NUM>, as seen in <FIG>, consists of a link emulator <NUM> towards the vehicle <NUM>, a link emulator <NUM> toward the radio <NUM> and a state filter and updater <NUM>, according to some embodiments. The proxy element is only a part of the security system <NUM>, which was omitted from the figure for the sake of clarity.

The link emulator <NUM> towards the vehicle <NUM> is connected between the vehicle <NUM> and the state filter and updater <NUM>. It holds the formatted text (display data) <NUM> designated for the display and the display type (state) <NUM>. At startup, this link emulator towards the vehicle <NUM> queries the display system for its type, stores the information in <NUM> and sends it to the state filter and updater <NUM>. The link emulator towards the vehicle <NUM> is in operational mode if it holds a valid display data and a valid display type. When in operational mode the link emulator <NUM> sends messages containing display data on every display data change according to the display type.

The link emulator towards the radio <NUM> is connected between the radio <NUM> and the state filter and updater <NUM>. It contains the same type of registers as the link emulator toward the vehicle <NUM>. At startup, the link emulator <NUM> waits to receive a display type from the state filter and updater. Once the link emulator <NUM> has a valid display type in <NUM> it responds to queries for the display type received from the radio. The link emulator <NUM> sends repeated keep-alive messages to the radio. The link emulator <NUM> stores the data from the display messages received from the radio in the display data register <NUM>. If the display data register <NUM> is changed, the link emulator <NUM> sends the new state to the state filter and updater <NUM>.

The state filter and updater <NUM> receives the display type from the link emulator toward the vehicle <NUM>. If the display type is valid, the state filter and updater <NUM> sends it to the link emulator towards the radio <NUM>. The state filter and updater <NUM> receives the display data from the link emulator towards the radio <NUM>. If the display data is valid, it sends the data to the link emulator towards the vehicle <NUM>.

It must be understood that the rules <NUM> described above are merely an example of possible types of rules <NUM>, and rules <NUM> can also be any kind of other rules <NUM>, or any combination of them. There is a possibility to combine rules <NUM> in a row, such that the output message of one rule <NUM> will be sent as an input to the next rule <NUM>. A rule <NUM> can also change the message properties, content, or any other data related to the message, before sending it to its output interface <NUM>. Any person skilled in the art and reading the current specification will immediately be able to advise different types and combination of rules <NUM>, and all these rules <NUM> are encompassed by the present invention.

Some previously described embodiments related to protecting safety critical ECUs <NUM> which do not have any external communication interfaces. However, in embodiments where safety critical ECUs <NUM> have external communication interface(s) the security system <NUM> can also be used to protect ECUs <NUM> as described in this section.

In some embodiments, safety critical ECUs <NUM> have an external communication interface (e.g. some vehicle to vehicle (V2V) communication ECU are able to command the vehicle to brake). Such an ECU could send critical messages (i.e. having effect on the vehicle's behavior) and non-critical messages (e.g. traffic information). The non-critical messages can be filtered in the same manner as described in previous sections.

In some embodiments, some ECUs responsible for safety <NUM> (e.g. Electronic stability control (ESC) <NUM> or Mobileye) have the ability to supervise messages arriving from the driver (e.g. an ESC ECU monitors the brake pedal and prevents skidding because of braking). Such an ECU <NUM> can supervise specific critical messages, and prevent harm caused by these messages. These messages are denoted by ECM (external critical messages).

In some embodiments, the security system <NUM> can allow the relevant ECM (i.e. ECM supported by the critical external ECU) to pass towards the vehicle's inner bus <NUM> as long as these messages are supervised effectively by a safety ECU. In this manner critical and potentially lifesaving critical messages are supported securely by the vehicles electronic system <NUM>. Such a security system <NUM> can also be used in case there is no relevant safety ECU, but in such case it will be possible to attack the vehicle using the allowed critical messages.

In some embodiments where an ECU with an external communication has the ability to send critical messages to the communication bus <NUM>, the driver should have the ability to manually override or disable the messages from this ECU.

MODBUS is a protocol extensively used in industrial control systems. Similarly to CAN bus <NUM>, it is a simple protocol used by controllers. Additionally, several other control protocols with similar characteristics exist such as FlexRay, VAN bus, LIN bus etc. The embodiments described above for CAN bus can be applicable for other communication protocols, such as MODBUS, mutatis mutandis.

In some embodiments, the main difference between the implementation of a filter and/or proxy <NUM> for CAN bus <NUM> and any other protocol is the physical layer and the specific filter logic. Different protocols have different message characteristics thus requiring different type of filtering (e.g. a MODBUS filter takes a special notice to the function code field). The proxy logic may be different but the proxy concept is the same: The link emulator <NUM> has to handle communication with specific communication protocol (e.g. message handling and specific state machine <NUM> for the protocol). The state filter and updater <NUM> filters and updates the state as the CAN bus <NUM> proxy state filter and updater.

MODBUS is built as master-slave architecture, meaning there is one master and one or more slaves connected to the bus <NUM>. The master can send a request (e.g. read or write data command) to one or more slaves, and the relevant slaves should act according to the request and send their response to the master over the bus <NUM>.

In some embodiments, a proxy <NUM> protecting such communication bus <NUM> may save the sent request properties, and allow only the relevant response to pass towards the master (e.g. the request and response can be characterized by their function code).

In some embodiments, the said proxy <NUM> can also generate the received request and/or response by itself according to the messages it receives, and send the generated message instead of the original message.

In some embodiments, a proxy <NUM> may block requests originating from any components which should not function as the master on the bus.

In one embodiment of the present invention, the security system <NUM> also functions as an authentication unit. The authentication unit can be another module of the security system <NUM> of the invention.

The authentication unit of the invention is responsible for verifying that communication is performed with authentic counterparts inside or outside the vehicle's electronic system <NUM>. Authentication units can be integrated with ECU's <NUM> and in particular with ECU's <NUM> that don't have an external communication interface. For better security, an authentication unit can be coupled to every safety critical ECU <NUM>, every valuable ECU <NUM> and every ECU with an external communication interface <NUM>.

The authentication unit can employ one or more mechanisms for authentication of a communication source or destination. In some embodiments, authentication units can be the source or destination of messages. These mechanisms are, for example, authentication of a source or destination element (that sends or receives messages); conditional transmission of messages based on a successful authentication; and signature and/or signature verification of messages.

In some embodiments, the authentication unit can also encrypt and/or decrypt messages. This type of encryption can be used for secrecy, integrity, authenticity etc..

Authentication - any authentication unit (stand-alone or coupled to or integrated with an ECU <NUM>) can perform an authentication procedure with any other authentication unit (stand-alone or coupled to or integrated with an ECU <NUM>). In some embodiments, a stand-alone authentication unit can be coupled with a bus <NUM>. In some embodiments, a stand-alone authentication unit can be coupled with one or more ECU's <NUM>. In some embodiments, the authentication unit is integrated with one ECU <NUM> (i.e. the authentication unit is included inside the ECU <NUM> as part of the security system <NUM>). In some embodiments, the authentication unit is a stand-alone security system <NUM> that is not coupled with any ECU <NUM> when proving its existence itself is meaningful, for example, for proving that a general sub-system was provided by a valid supplier. In some embodiments, referring to authenticating an ECU <NUM> means authenticating the authentication unit coupled with it.

In some embodiments, each authentication unit is configured with a list of all the authentication units in the system <NUM> with which authentication is required. Each authentication unit can periodically initiate an authentication process with any other authentication unit. The period after which the authentication must be renewed can be fixed or variable per authentication unit. The authentication process can involve a challenge message from one authentication unit to another. The receiving authentication unit then responds to the challenge with a response (typically encrypted). The authentication unit that has sent the challenge message verifies the response and if correct, marks that authentication unit in the list as authenticated. If the response is not correct, the challenge may be repeated one or more times, after which that authentication unit will be marked in the list as unidentified (not authenticated).

The challenge and response messages flow between authentication units as regular messages in the vehicle electronic system. These messages are received by a receiving unit. The classification unit classifies them as challenge / response messages and sends them to the message analyzer unit which handles them.

The message analyzer unit is capable of initiating challenge messages when it is necessary to authenticate an ECU <NUM> before delivering a message to it or considering a message from it.

In some embodiments, the authentication process can also be initiated by an authentication unit, when the authentication unit or the ECU <NUM> to which it is coupled, are programmed to periodically authenticate ECU's <NUM> on its authentication list.

In some embodiments, the authentication process can be one-way or two-way. In a one-way authentication process, each authentication unit sends a challenge to the other. That is, authentication unit A challenges authentication unit B, and authentication unit B challenges authentication unit A. In a two-way authentication process, the challenge message sent by authentication unit A to authentication unit B is sufficient for authenticating authentication unit A, and authentication unit B does not need to issue its own challenge message to authentication unit A.

In some embodiments, the authentication process can be multi-way, that is authentication unit A broadcasts a challenge and/or response message that reaches a plurality of authentication units over one or more communication buses <NUM>.

Conditional Message Transmission Based on Authentication - the message analyzer unit can be configured to transmit a message only if an authentication requirement is fulfilled. Examples of authentication requirements include but are not limited to: that the source authentication unit is authenticated; that the destination ECU <NUM> is authenticated; that any other ECU <NUM> (not source or destination) is authenticated; that any combination of ECU's <NUM> are authenticated etc. The authentication requirement can be against the source, destination or any other ECU <NUM>.

When a message that requires authentication arrives to the message classification unit, the message is classified as requiring authentication against ECU X <NUM>, and the message is sent to the message analyzer unit. The message analyzer unit verifies if ECU X <NUM> is authenticated. If ECU X <NUM> is authenticated, the message analyzer unit continues to process the message. If ECU X <NUM> is not authenticated, the message analyzer unit can decide either to discard the message or to issue a challenge message to ECU X <NUM> to see if it authenticates itself.

It should be emphasized that the authentication requirement does not have to involve necessarily the source or destination ECU <NUM>. For example, when ECU <NUM> <NUM> sends a message to ECU <NUM> <NUM>, it may be required that ECU <NUM> <NUM> is authenticated with ECU <NUM> <NUM> before the message can be transmitted to ECU <NUM> <NUM>.

Signature and Verification - One of the actions that the message analyzer unit can perform relates to the signature of messages. When a message arrives with a signature, the analyzer unit can verify that signature is valid. The analyzer unit can also add a signature to a message before transferring it to the transmission unit.

<FIG> illustrates a basic one way communication filter/proxy security system <NUM>. A message received by the physical port input <NUM> is inserted into the message receiving unit in message handler <NUM>. The message receiving unit transmits the message through the proxy interface input <NUM> to the message classification unit (classifier) <NUM> in the one way filter/proxy element <NUM>. The classifier <NUM> classifies the message and sends the message and the message classification to the action selector <NUM> in the message analyzer unit <NUM>, which chooses the proper action according to the classification. The message analyzer unit <NUM> performs an action <NUM> (without loss of generality) on the message according the classification and sends a message (if needed) through the proxy interface output <NUM> to the message transmission unit <NUM>. The message transmission unit in the message handler <NUM> transmits the message to the physical port output <NUM>.

<FIG> illustrates one embodiment of the process of verifying / signing messages between communication filter/proxy (security systems) A and B <NUM>. A message is sent by an ECU A logic <NUM> to a communication filter/proxy A <NUM> (containing rules for an authentication unit <NUM>, which illustrates the group of rules <NUM> in charge of the authentication and signature processes). The ECU logic <NUM> is basically part of or all of the processing mechanisms of the ECU <NUM> except for the physical layer driver / transceiver <NUM> which is in charge of physically sending the communication signals to the outside world, which is a communication bus <NUM>. The message arrives to the classification unit <NUM> which classifies the message as "signature required against communication filter/proxy B" <NUM>. The analyzer unit <NUM> receives the message and proceeds to sign it against communication filter/proxy B <NUM>. The signature process involves modifying the original message by adding a signature to it (in a predetermined format). The analyzer unit <NUM> can further process the message (in addition to the signature) in accordance with the classification instructions received and general rules <NUM> of the analyzer <NUM>. The analyzer unit <NUM> will then send the message to the message transmission unit in the message handler <NUM> which will send the message to its destination <NUM>, which is a physical layer driver (port) of A.

The message will then arrive to its destination port <NUM> in ECU B <NUM>, and will be transferred to the receiving unit in the message handler <NUM> in communication filter/proxy B <NUM> and from there to the classification unit <NUM>. The classification unit <NUM> classifies the message as requiring signature verification against communication filter/proxy A <NUM>. When the analyzer unit <NUM> receives the message, it verifies that the signature is authentic. If the signature is verified, the original message is extracted from the signed message and transferred to the relevant message transmission unit in the message handler <NUM> which delivers the message to the logic <NUM> of B.

In some embodiments, if the signature verification has failed, the analyzer unit <NUM> will ignore (discard) the message and no further action will be taken on the message. In some embodiments, the result of the signature verification will be logged.

There can be many implementations of adding and verifying a signature and they are all encompassed by the present invention. One such example can be: calculating a hash value on the content of the message data, and then encrypting the result using a shared key between the parties. The signature is done by adding the encrypted result to the message, and the verification is done by doing that process and comparing the result to the embedded sent signature. If both results are equal - the message's signature is valid.

In some embodiments, one or more communication filter/proxy security systems <NUM> of the invention can be implemented outside the vehicle computerized system <NUM>.

In some embodiments, for efficiency considerations, the signature addition and/or verification does not need to occur with all messages, but only with messages that were classified as such by the classification unit.

The classification unit <NUM> takes into consideration the format requirements of each message, including maximum allowed length, so that when adding a signature the message is still valid and can be transmitted and read properly. The system should be consistent with the protocol even when modifying messages. That means that not all messages will be signed for example if the signature will make the message size exceed the protocol's limit.

Claim 1:
A method for filtering messages between first and second vehicle communication buses (<NUM>), each of the messages being associated with at least one message property, the method comprising:
receiving messages from, and transmitting messages to, the first vehicle communication bus using a first transceiver (<NUM>) that is coupled to a first physical port (<NUM>) that is connectable to the first vehicle communication bus; and
receiving messages from, and transmitting messages to, the second vehicle communication bus using a second transceiver (<NUM>) that is coupled to a second physical port (<NUM>) that is connectable to the second vehicle communication bus; and
filtering messages from the first to the second vehicle buses and from the second to the first vehicle buses according to a rule,
the method further comprising:
receiving and storing the rule associated with the at least one message property; and
executing software by a processor (<NUM>) for controlling the first and second transceivers,
wherein the filtering comprises, for each of the messages received from the first vehicle bus, passing or blocking the message to the second vehicle bus in response to the rule and the at least one message property,
wherein the filtering comprises, for each of the messages received from the second vehicle bus, passing or blocking the message to the first vehicle bus in response to the rule and the at least one message property,
characterized by the at least one message property being associated with a timing information, and
wherein the rule includes one or more timing values, and a specific received message is passed or blocked in response to comparing of the specific message timing information to the one or more rule timing values.