The most common form of messaging inside automotive vehicles is performed over the CAN protocol. It is robust, resilient, and efficient to implement.
In this blog post, we will delve deeper into the protocol in order to understand more precisely how it works. Later in another post, we will describe the security of this protocol and what we look for during penetration tests. So let us begin.
The CAN Bus – How Did It Come About?
Vehicles were becoming increasingly electrical by the early 80s. As these electrical systems grew, so did the amount of components and the complexity of communications. This required more wiring and resources to make these systems work, so there was a need to optimize their development and make communications between devices more efficient without all the wiring involved.
Around the same time, researchers at Bosch wanted to find a serial bus communications method that could fill this need. So, they developed and released version 1.0 of the CAN bus protocol in 1986.
Once Intel and Philips introduced CAN controller chips a year later, CAN developed into the most widely used automotive messaging protocol. Other milestones include:
- 1991: The CAN 2.0 standard was established and split into two parts: CAN 2.0A (with an 11-bit identifier) and CAN 2.0B (with a 29-bit identifier).
- 1993: The International Organization for Standardization (ISO) adopted CAN as an international standard (ISO 11898).
- 2003: Introduction of CAN FD (Flexible Data-rate), an extension of the original CAN protocol that allows for higher data rates and larger payloads.
How Does It Work?
Before we get into the protocol itself, it makes sense to understand how CAN works physically and how signals are sent over the wire.
CAN bus signals are electrical signals translated to binary data that travel over two twisted wires. One wire is called ‘CAN high’ and the other ‘CAN low.’ When the bus is on, it typically operates with both wires transmitting around a voltage of 2.5V. This is its natural state and is called the recessive state. This state is signified by the bit value 1. However, sending the value 0 requires a transition of the bus to the dominant state. CAN high sends a voltage about 1.25V above. CAN low sends about 1.25V below the standard baseline voltage. It is due to this divergence of voltages that this form of signaling is called ‘differential signaling.’
The CAN Protocol and Its Packet Structure
Now that we know how CAN works physically, we can advance to the protocol and its composition.
The electrical transmissions of signals representing binary data must naturally be translated into packets that adhere to the structure of the CAN protocol.
CAN packets, or frames as they are also called, have the following components:
- SOF: This is called the ‘Start of Frame’ and when set to 0, tells the CAN bus to expect a message.
- ID: This is the identifier to send the message. Usually 11 bits but in extended mode is 29 bits. Lower values receive higher priority.
- RTR: The Remote Transmission Request to indicate whether a node needs to transmit or receive data.
- Control: The Control contains the Identifier Extension Bit (IDE) which is set to 0 for 11 bit IDs and 1 for 29 bit IDs. Also included is the Data Length Code (DLC) that specifies the length of the data in the packet.
- Data: This is the payload to be sent. The maximum is 8 bytes per frame. However, with CAN-FD this increases to 64 bytes.
- CRC: The Cyclic Redundancy Check for data protection and integrity
- ACK: The ACK bits acknowledge that the node has successfully received the data
- EOF: The End of Frame
In short, there are 4 types of CAN frames:
- Data frames: these are messages that intend to send data to a particular node on the CAN bus
- Error frames: these frames indicate an error in the communications and will contain an error flag and error delimiter superimposed into the frame.
- Remote frames: This will have the RTR field set to recessive 1 and contains a request for data from a node.
- Overload frames: In the case the CAN needs an additional delay before sending data or the CAN requires extra time for data processing.
Network Arbitration
Since all nodes on the bus share the same physical connection, there is a danger that message collisions could occur as nodes compete for access. The consequences of these collisions could lead to delays or damage to the messages.
To avoid the extra resources necessary to repair the damage from the collisions, CAN utilizes IDs that implement a priority system. Messages with the highest priority will have the lowest numerical IDs. Messages, for example, with the ID 0x0000 will have automatic priority over all other messages and will be sent first. Messages with higher IDs will wait for that message to be delivered. Once their turn arrives, their messages will enter the bus.
This system seems logical. Not only because it avoids collisions but also takes care that messages that should have higher priority, such as messages concerning the brakes or engine, get to their destination ahead of messages of less importance.
The State of CAN…
With the ever-increasing amounts of data traffic over both the wire and the air, the original conception of the CAN protocol is not sufficient enough to handle the increasing amounts of data and the speeds modern systems now require. The CAN protocol is also, by nature, not very secure. Data is not transmitted encrypted, the bus can easily be sniffed, and there are no natural protections against any forms of injection attacks.
To improve the rates and amount of data transmission, CAN-FD was developed which increases the data payload up to 64 bytes per message.
Driven by increased regulations, companies have also improved the security of their ECUs with methods such as data encryption, SecOC, and intrusion detection systems.
In some systems, this may not be enough. Manufacturers are turning to automotive ethernet because of its capability to deal with higher loads, increased speed of transmission, and customizable security features that could be added, such as authentication over TLS.
Despite its limitations, it appears as if CAN will not go away anytime soon. However, it is important the manufacturers stay on top of developments in the industry to make sure their systems are both optimized and secure.