CAN fault confinement: It is a feature not a flaw!

The CiA Managing Director, Holger Zeltwanger, responses to the accusations that the CAN error detection and fault confinement has some cyber security weaknesses.

“In the last couple of weeks, several publications reported about a supposed vulnerability of the CAN data link layer. Most of them referenced a research study made at the Politecnico di Milano. The researchers added an electronic circuitry to the network, which transmits permanently (artificial) error frames. If the transmitting node detects these error frames, it aborts the transmission of the current message and tries to retransmit it. This is a feature of the CAN protocol. But the re-transmission fails also, due to the permanently transmitted “artificial” error frames. As a consequence, there is no normal communication possible and the connected CAN nodes are going bus-off due to the CAN fault confinement functionality. The researchers call this a successful denial-of-service attack. They regarded this as a weakness of the CAN error handling and fault confinement function.

It is correct that this is a successful denial-of-service attack. Nevertheless, the attacker needs physical access to the network, to install the add-on electronics. By the way, all communication systems with shared media can be attacked successfully, if an attacker has physical access to the media. If an attacker has access to wired communication systems, the cutting of the bus-lines is sufficient to achieve a successful denial-of-service attack. In case of a wireless media, any enough noise producing equipment can lead to a successful denial-of-service attack. In all these attacks, the communication is not functioning properly anymore.

If somebody has access to a vehicle, he or she can perform any kind of denial-of-service attack – even flatting the tires can be regarded as such an attack. To avoid denial-of-service attacks, the owner needs to park the vehicle in a secure area – in a garage, for example. Such kinds of attack are just affecting a single vehicle. Even worse are attacks on the entire fleet. They can be achieved by means of remote attacks to the CAN-based in-vehicle networks. Remote attacks can be performed by any external interface of any electronic control unit (ECU) connected to the CAN-based in-vehicle networks.

The attacker can download a mal-software, which causes the ECU to send frequently the highest prior CAN message (identifier with the value 0), for example. No other ECU with lower-prior CAN messages will win bus arbitration. This is also a successful denial-of-service attack. This bit-wise, non-destructive arbitration method is not a weakness of the CAN protocol, it is a useful feature to design event-driven communication systems.

In order to avoid such remote attacks, all external interfaces of all CAN-connected ECUs need to be secured against unauthorized access. This includes in particular the OBDII interface, which garages use for diagnostic purposes and to download software to the ECUs. This CAN interface is standardized internationally in the ISO 15765 series. It is under review. Security mechanisms will be introduced with the next version.

Modern micro-controllers have many interfaces. Some micro-controllers provide even JTAG functionality on the CAN interface. Of course, this interface also needs to be secured, in order to avoid cyber attacks. It is always necessary to consider the entire thing. Single item approaches can fail. An example: Even if you secure the OBDII interface, it can be possible that an attack is successful. This can happen, when the very same interface is used logically for other purposes, which are not secure. All implemented security mechanisms must be evaluated. Simple approaches such as an 8-bit password can be attacked successfully by a brut-force method sending 256 messages. If such an approach is used on the OBDII interface in parallel to the secured ISO 15765 communication, the strong security mechanisms can be bypassed.

To summarize: Error handling and fault confinement are useful features of the CAN protocol. They avoid that a single ECU can blog unintendedly the entire network. Also the bus arbitration method used by the CAN protocol is not a flaw. Of course, the user needs to protect its vehicle against unauthorized access. Additionally, the OEM has to implement security mechanisms against remote attacks in all physical and logical interfaces of the networked ECUs.”

Holger Zeltwanger