Patent Description:
CAN is a two-wire, half-duplex, high-speed serial network typically used to provide communications between network nodes without loading down microcontrollers. CAN transceivers interface between the CAN protocol controller and the physical wires of the CAN bus lines. A transceiver is used by a microcontroller to send and receive data on a CAN bus. A typical transceiver normally provides a ISO <NUM> standard compliant communication over the CAN bus without scrutinizing the data content.

<CIT> discloses a data processing system that provides for active prevention of masquerading attacks comprising a microcontroller, a transceiver, and an active attack prevention module (AAPM) in communication with the microcontroller and the receiver. <CIT> discloses a communication control device with a communication unit for, upon connecting a bus with an engine ECU, transmitting a message to the bus upon receiving the message from the engine ECU and for transmitting a message to the engine ECU upon receiving the message from the bus; a transmission ID list holding unit for holding a transmission ID list, that is, a list of transmission IDs included in messages transmitted from the engine. <CIT> discloses a system and method for providing security to a network which may include maintaining, by a processor, a model of an expected behaviour of data communications over the in-vehicle communication network; receiving, by the processor, a message sent over the network; determining, by the controller, based on the model and based on a timing attribute of the message, whether or not the message complies with the model; and if the message does not comply with the model, then performing, by the processor, at least one action related to the message.

The present invention is defined in the appended independent claim <NUM> to which reference should be made.

So that the manner in which the above recited features of the present invention can be understood in detail, a more particular description of the invention, briefly summarized above, may be had by reference to embodiments, some of which are illustrated in the appended drawings. It is to be noted, however, that the appended drawings illustrate only typical embodiments of this invention and are therefore not to be considered limiting of its scope, for the invention may admit to other equally effective embodiments. Advantages of the subject matter claimed will become apparent to those skilled in the art upon reading this description in conjunction with the accompanying drawings, in which like reference numerals have been used to designate like elements, and in which:.

Note that figures are not drawn to scale. Not all components of the secure transceiver are shown. The omitted components are known to a person skilled in the art.

Controller Area Network (CAN) is a peer-to-peer network. Meaning that there is no master that controls when individual nodes have access to read and write data on the CAN bus. When a CAN node is ready to transmit data, it checks to see if the CAN bus is free and then simply writes a CAN frame onto the network. The CAN frames that are transmitted do not contain addresses of either the transmitting node or any of the intended receiving node(s). Instead, an arbitration ID that is unique throughout the network is contained in a data frame. All nodes on the CAN network receive every CAN frame that is transmitted by any node, and, depending on the message or arbitration identifier of the transmitted frame, each CAN node on the network decides whether to accept the frame for further processing.

If multiple nodes try to transmit messages onto the CAN bus at the same time, the node with the highest priority (lowest value of message or arbitration identifier) gets bus access. Lower-priority nodes (or messages) must wait until the bus becomes available before trying to transmit again.

CAN nodes (e.g., ECUs) use transceivers to interface with the CAN bus. The transceivers include an Rx port and a Tx port to enable communication with other CAN nodes through the CAN bus <NUM>. Transceivers normally provide a simple interface for mode control from a device/microcontroller in a network. A typical standard transceiver makes use of up to two dedicated mode control pins, and this means that there are usually not more than four different states of operation.

The CAN protocol specifies the structure of a CAN frame. The CAN frame includes:.

<FIG> depicts a controller area network (CAN) bus <NUM>. The CAN bus <NUM> includes terminating end resistors to suppress wave reflections. In some embodiments, a capacitor <NUM> may also be used at a terminating end. The CAN bus <NUM> includes a twisted wire pair <NUM>. The twisted wire pair <NUM> includes CANH and CANL wires. The CAN bus <NUM> may include a plurality of communication microcontrollers or electronic control units (ECUs) <NUM>-<NUM>. <NUM>-N coupled with the twisted wire pair through a plurality of secure transceivers <NUM>-<NUM>. The capacitor <NUM> is typically <NUM>. The value of the capacitor <NUM> may be increased to approximately 100nF. By increasing the value of the capacitor <NUM>, a signal voltage at CANL or CANH during intermittent opens is improved. In one example, the resistors coupled with the capacitor <NUM> are typically <NUM> ohm each (total <NUM> ohm at each end).

As shown, the communication nodes (ECUs) <NUM>-<NUM>. <NUM>-N are connected via an unshielded twisted pair <NUM>. Termination is implemented at the far left- and right-hand side of the CAN bus <NUM>. There are two options, either by using a single resistor as shown in the lefthand side of the CAN bus <NUM>, or via two resistors and the capacitor <NUM>, referred to as "split-termination" as shown on the right-hand side of the CAN bus <NUM>. The latter method is commonly used as it offers an additional low-pass filtering to improve EMC performance.

As shown in <FIG>, in normal operations (when no errors are present), the CAN bus <NUM> signals CANH and CANL are driven such that a differential voltage is generated (to send a dominant signal) or no differential signal is generated (to send a recessive bit). In some implementations, for a dominant bit ("<NUM>") the voltage at CANL is approximately <NUM>. 5V and the voltage at CANH is <NUM>. 5V and Vdiff represents a difference between the voltages at CANH and CANL. In some examples, Vdiff > <NUM>. 9V may be considered a dominant bit and Vdiff < <NUM> may be considered a recessive bit.

The communication nodes (e.g., ECUs <NUM>-<NUM>. <NUM>-N) on the CAN bus <NUM> that wish to send data on the CAN bus send a dominant SOF bit when the CAN bus <NUM> is idle (e.g., in the recessive state for a duration) to indicate that the nodes would like to send a data frame. Next, each node sends a message identifier. Note that the nodes are configured such that no two nodes can send a data frame including the same message identifier. The CAN protocol provides an <NUM>-bit message identifier. In another version of the CAN protocol, the message identifier is specified to include <NUM> bits. The relative priority of a message identifier is characterized by the value of the message identifier. A lower value message identifier has a higher priority. For example, the message identifier with the value <NUM> (0x647) will have a higher priority than the message identifier with the value <NUM> (0x6FF).

If the ECU <NUM>-<NUM> and the ECU <NUM>-N simultaneously send SOF bit and then start transmitting the message identifiers <NUM><NUM> and <NUM> respectively, on the fourth bit, the ECU <NUM>-<NUM> will win the arbitration because it will send a dominant bit, which will overwrite the recessive bit sent by the ECU <NUM>-N. The ECU <NUM>-<NUM> will read a dominant bit after sending a dominant bit on the CAN bus <NUM> and will continue to send further data bits whereas the ECU <NUM>-N will read a dominant bit after having sent a recessive bit (e.g., the fourth most significant bit in the above message identifier example) and will assume that it has lost the arbitration and will stop sending further data bits on the CAN bus <NUM>, and will wait for the CAN bus <NUM> to be free again before attempting to send the message, at which time, the process of arbitration will start again.

However, the above described process can only work if the ECU <NUM>-N honors the CAN protocol. If the ECU <NUM>-N is a malicious component that is maliciously programmed to interrupt the data transmission on the CAN bus <NUM>, the ECU <NUM>-N, after having lost the arbitration, may still flip a later bit sent by the ECU <NUM>-<NUM> on the CAN bus <NUM>. This can be done in the data phase (e.g. during the transmission of Data Field) of the CAN frame transmission to replace valid data being sent with malicious data. For example, when the ECU <NUM>-N detects that the ECU <NUM>-<NUM> has sent a recessive bit, the ECU <NUM>-N may send a dominant bit on the CAN bus <NUM> to overwrite the recessive bit sent by the ECU <NUM>-<NUM>. Because a dominant bit overwrites a recessive bit on the CAN bus <NUM>, the data being sent by the ECU <NUM>-<NUM> will no longer be a valid data. The ECU <NUM>-N may continue to repeat this malicious action to cause a failure of data communication on the CAN bus <NUM>. This failure may create a dangerous condition, for example, for a user of a vehicle. Suppose the ECU <NUM>-<NUM> was transmitting anti-lock braking data when the vehicle was skidding on an icy road, the failure of communication caused by malicious actions of the ECU <NUM>-N may pose a serious risk of harm.

Assuming again that the ECU <NUM>-N is a malicious ECU, the ECU <NUM>-N may continue to tamper the data of high priority messages to virtually hijack the CAN bus <NUM> by prohibiting other ECUs (e.g., the ECU <NUM>-<NUM>) from sending data on the CAN bus <NUM>.

<FIG> shows a transceiver <NUM>. Note that many components of the transceiver <NUM> have been omitted so as not to obfuscate the present disclosure. The transceiver <NUM> may replace the transceiver <NUM>-N in <FIG> (and of course any other transceiver on the CAN bus <NUM>) to make the CAN bus <NUM> shown in <FIG> a secure CAN bus. With the transceiver <NUM> monitoring the ECU <NUM>-N, the ECU <NUM>-N will no longer, after the first attempt, be able to maliciously interrupt the data communication on the CAN bus <NUM>.

The transceiver <NUM> includes a transmittter (TX) <NUM> and a receiver (RX) <NUM>. The transceiver <NUM> includes a microcontroller port <NUM> to send/receive data from a microcontroller or ECU. The transceiver <NUM> also includes a CAN bus port <NUM> to send/receive data to/from a CAN bus <NUM>. The data received from the CAN bus <NUM> is transmitted to the microcontroller to enable the microprocessor to functionally process the data. Similarly, when a data is received from the microprocessor, the received data is transmitted to the CAN bus <NUM>. The TX <NUM> translates the data received from the microprocessor in a signal that is compliant with CAN standards.

The transceiver <NUM> also includes a protocol decoder <NUM>. The protocol decoder <NUM> may be coupled to a on chip clock source <NUM> that provides a synchronization clock. A bit time settings module <NUM> may be included to initialize the protocol decoder <NUM>. The bit timing settings module <NUM> may also keep track of a current bit position in a data frame when the data frame is being processed by the protocol decoder <NUM>. The protocol decoder <NUM> includes a TXD traffic detection module <NUM> and a RXD traffic detection <NUM>. The TXD traffic detection module <NUM> monitors TXD line coupled to the microcontroller port <NUM> and the RXD traffic detection module <NUM> monitors RXD line coupled to the microcontroller port <NUM>. A violation detector <NUM> is included to identify any rule violations in the data being received or being transmitted through the microcontroller port <NUM>. The validation rules may be stored in a memory (not shown) in the protocol decoder. In one example, the validation rules are stored in a temper proof manner so that the validation rules cannot be maliciously altered. In some examples, the protocol decoder <NUM> may also include a processor (not shown). In other examples, the protocol decoder <NUM> may be implemented in hardware only.

In some examples, a RX switch <NUM> may be included to enable or disable RXD line and a TX switch <NUM> may be included to enable or disable TXD line. In some embodiments, the RX switch <NUM> is optional. In some embodiments, the RX switch <NUM> and the TX switch <NUM> may be controlled independently. In some other examples, the TX <NUM> includes an enable EN port to enable or disable the TX <NUM>. In some examples, if the TX <NUM> includes the EN input, the TX switch <NUM> may not be included. In some examples, a different control signal may drive the RX switch <NUM> based on monitoring of the RXD line.

The protocol decoder <NUM> monitors if the microcontroller connected to the microcontroller port <NUM> has won or lost arbitration. If the CAN frame is tempered by a malicious microcontroller (or host or ECU), a remote node on the CAN bus <NUM> will stop sending further data frame due to a bit error. Normally an error frame will be send on the first <NUM> bit occurrences by the remote node. For the next <NUM> bit occurrences the remote node will be error passive and will not send error frames and stops transmitting. This event may provide a malicious microcontroller coupled with the microcontroller port <NUM> sixteen chances to send the remainder of the data frame containing malicious data.

If the microcontroller has lost arbitration there should be no traffic on TXD except a possible error frame or an ACK to confirm the CAN frame is received. The violation detector <NUM> may disable the TX <NUM> so that a malicious microcontroller cannot send a data to hijack the communication on the CAN bus <NUM>. In another example, the violation detector <NUM> may turn the TX switch <NUM> off after the microcontroller sends ACK or error frame. In some embodiments, the TX switch <NUM> or EN signal may be activated only if the microcontroller attempts to send a data other than ACK or error frame. In some examples, if the TX switch <NUM> is turned off or the TX <NUM> is disabled, the TXD line remains disabled for a predetermined time period to stop the microcontroller from continuing to disrupt the communication.

If the TX <NUM> determines that the microcontroller coupled to the microcontroller port <NUM> has lost the arbitration and yet attempt to send a dominant bit, the protocol decoder <NUM> starts counting the number bits being sent. In some examples, the counting may include check the width of the dominant bit sent by the microcontroller. If the microcontroller continues to send more bits, the microcontroller may be sending a legitimate error message (<NUM>-bit long or more) and such messages are allowed to go to the CAN bus <NUM>. However, if the microcontroller stops sending more dominant bits, the protocol decoder <NUM> may send the remaining bits to indicate an error condition. If the microcontroller sends more than one error messages within a preselected time interval, the protocol decoder <NUM> may disable the TXD line or the TX <NUM> for a preselected time period to prevent the microcontroller from staging a denial of service attack. In some examples, if the protocol decoder <NUM> detects that the microcontroller coupled with the microcontroller port <NUM> is sending a message identifier that the microcontroller is not authorized to send, the protocol decoder <NUM> may disable the TXD line or the TX <NUM>. Similarly, in some examples, the protocol decoder <NUM> detects a message identifier that the microcontroller is not authorized to receive, the protocol decoder <NUM> may invalidate the received message to stop the message from being read by the microcontroller.

Typically, the microcontroller coupled with the microcontroller port <NUM> can read data being transmitted by a remote node on the CAN bus <NUM> that won the arbitration. The microcontroller may start sending data bits on to the CAN bus <NUM>. In one example, upon receiving the dominant bit, remote nodes may believe that the microcontroller coupled with the microcontroller port <NUM> has the control of the CAN bus <NUM> and then the malicious the microcontroller may send a complete CAN frame with a valid CRC to highjack the CAN bus <NUM>. In another example, because the dominant bit sent by the microcontroller will overwrite the recessive bit sent by the remote node, the CAN frame sent by the remote node will be corrupted. The protocol decoder <NUM> is configured to invalidate the data frame and at least temporarily disconnect, after the first attempt to corrupt the data, the microcontroller from either corrupting the data sent by the remote node or will prevent the malicious microcontroller coupled with the microcontroller port <NUM> from hijacking the CAN bus <NUM> after losing the arbitration. Note that in the description of <FIG>, the term "microcontroller" is being used for a local host that is coupled with the microcontroller port <NUM>. The remote node may also include an ECU or a microcontroller. However, the term "remote node" is being used for a combination of a remote microcontroller coupled to its own separate transceiver.

In some examples, if the dominant pulse is less than <NUM>-bits, the protocol decoder <NUM> is configured to extend the dominant pulse on the CAN bus <NUM> to a longer amount, e.g., <NUM> dominant bits. This can be used to distinguish a security error to the CAN bus <NUM> from a normal error.

Optionally, if the microcontroller stops sending further bits after sending a dominant bit, after losing the arbitration, the protocol decoder <NUM> may continue to send more bits, total six (or more depending on the implementation), to send a legitimate error message on the CAN bus <NUM>. The protocol decoder <NUM> may then disable the data transmission of the microcontroller for a preselected period (e.g., a few seconds) to prevent the microcontroller from staging a data interruption attack on the CAN bus <NUM>.

The violation detector <NUM> is configured to detect if a complete frame is received from the remote host and that the microcontroller coupled with the microcontroller port <NUM> sends an unallowed part of the frame. If an unallowed part of the frame is send by the microcontroller, the violation detector <NUM> is configured to disconnect the TXD line or disable the TX <NUM>. The violation detector <NUM> may also be configured to send an invalidation signal on the CAN bus <NUM> to invalidate the malicious frame sent by the microcontroller. The protocol decoder <NUM> may turn off the TX switch <NUM> and/or the RX switch <NUM> for a predetermined time. The protocol decoder <NUM> is configured to check if the whole frame is received properly according CAN standards.

In some examples, the transceiver <NUM> may not include any additional pins so that the transceiver <NUM> may be used as a "drop in" to replace a conventional transceiver. In the examples in which the protocol decoder <NUM> is implemented either fully or partially in software, the transceiver <NUM> may be configured to be programmed with additional data validation rules. In some examples, if the transceiver <NUM> is configurable to be programmed, a tamper proof security mechanism may be employed such that only authorized devices or entities may alter the existing programming stored in the transceiver <NUM>.

In some embodiments, the transceiver <NUM> may include a white list stored in the memory (not shown) that provides verification of the message identifiers that are allowed to pass through the transceiver <NUM> over to the CAN bus <NUM>. The message identifiers stored in the white list may be configured when the transceiver <NUM> is provisioned for the use. Prior to sending a message identifier to the CAN bus <NUM>, the protocol decoder <NUM> checks if the message identifier being checked is allowed to be sent to the CAN bus <NUM> by the microcontroller. If the white list does not include the message identifier, the data frame will rejected. In some examples, If the microcontroller is not supposed to receive and accept a certain message identifier, the protocol decoder <NUM> will invalidate the received message such that the received data frame does not reach the microcontroller. The white list may be stored in a temper proof memory such that it cannot be altered after being provisioned. User defined settings and data processing instructions may also be stored in the memory. For example, a user may alter the time period for which the microcontroller is disabled by the protocol decoder <NUM>.

Claim 1:
A transceiver (<NUM>) for sending and receiving data from a controller area network, CAN, bus (<NUM>), the transceiver includes a microcontroller port (<NUM>), a transmitter and a receiver,
wherein the transceiver is configured to receive a data frame from a microcontroller via the microcontroller port and to determine if the microcontroller is authorized to send a data field of the data frame based on a message identifier in the data frame,
and if the microcontroller is unauthorized to send the data field, the transceiver is configured to invalidate the data frame on a transmission line, which is connected between the microcontroller port and the transmitter, and disconnect the microcontroller from the CAN bus for a predetermined period;
wherein the transceiver is further configured to check during transmission of the data frame if the microcontroller had lost or won arbitration;
wherein the transceiver is further configured to generate and send an
invalidation signal on to the CAN bus to invalidate the data frame on the transmission line if the microcontroller sends the data frame after losing the arbitration;
wherein the transceiver further including a transmission line switch in the transmission line; and
wherein the transceiver is further configured to turn the transmission line switch off based on a detection of an unauthorized message identifier on the transmission line.