CAN Bus

What is the CAN bus?

The CAN bus is a serial fieldbus on which every connected node can send, and every node receives every frame. A frame carries an identifier (11 bits, or 29 bits in the extended format), a data field of up to 8 bytes in classic CAN and 64 bytes in CAN FD, a CRC and an acknowledgement bit. There are no addresses: the identifier says what the message is, for example wheel speed, and also decides who wins when two nodes transmit at the same time, because a lower identifier has priority in the bitwise arbitration. Error handling is built in: nodes count transmit and receive errors and take themselves off the bus (bus-off) when the counters run too high.

A vehicle has several CAN segments (powertrain, chassis, body, diagnostics) joined by a gateway ECU.

Where is it defined?

ISO 11898-1 defines the data link layer and the physical coding sub-layer, including classic CAN, CAN FD and, in the 2024 edition, CAN XL with data fields of up to 2048 bytes. ISO 11898-2 defines the high-speed physical layer, the two-wire differential bus most vehicles use. Higher layers are separate standards: ISO 15765-2 (ISO-TP) segments larger messages for diagnostics, ISO 14229 (UDS) defines the diagnostic services, SAE J1939 and CANopen cover commercial vehicles and machinery.

Security is defined outside the ISO 11898 series. AUTOSAR’s Secure Onboard Communication (SecOC) specifies how a message authentication code and a freshness value are attached to a message so that a receiver can verify sender and recency. UN Regulation No 155 lists threats to vehicle communication channels in its Annex 5, among them spoofing and injection of messages and manipulation of in-vehicle data, and expects the manufacturer to mitigate them.

What it means in practice

Every ECU penetration test and every fuzzing campaign we run touches CAN, because it is where the ECU meets the rest of the vehicle. Three points are decisive for the security of a CAN architecture:

• Who can reach the bus. The bus trusts every node, so the real question is which ECUs with external interfaces sit on which segment and how well the gateway filters between segments. A telematics unit on the same segment as the brakes is an architecture finding before any frame is sent.
• Which messages are authenticated. SecOC with proper key management protects the signals that matter for safety. A frequent gap is that SecOC is configured but the receiver does not reject messages with a failed check, or the freshness counter is managed in a way that allows replay.
• What the diagnostic channel exposes. UDS over CAN is the one protocol that is meant to write to the ECU. Its access control, and the sessions in which it is reachable, decide what a node on the bus can do to the firmware.

In fuzzing we target the ISO-TP segmentation, the signal decoding and the gateway routing, and watch for resets, error frames and nodes that go bus-off. On power-electronics ECUs such as DC/DC converters and on-board chargers this has repeatedly shown robustness issues that functional testing with valid frames never reaches. AutoST, our test suite, automates this kind of CAN and UDS testing with reset detection.

Common misunderstandings

Encrypting CAN frames is rarely the answer: the payload is too small, the latency budget too tight, and confidentiality is not the problem, authenticity is. A CAN intrusion detection system detects anomalies but does not stop a single well-formed malicious frame. And “the bus is inside the car” was a security argument only as long as no ECU had a modem.