CAN Bus

CAN bus (Controller Area Network) is a message-based protocol originally developed by Bosch in the 1980s, designed to let multiple electronic control units (ECUs) within a vehicle communicate with each other over a single, simple pair of wires, without needing a dedicated connection between every individual pair of devices. It has since become the standard backbone protocol not just for the automotive industry, but for a wide range of embedded and industrial systems — aircraft, elevators, medical devices, and industrial machinery all commonly use CAN bus internally.

A modern car can easily contain 70 or more individual ECUs — controlling the engine, brakes, airbags, infotainment system, power windows, and dozens of other functions — and CAN bus is what allows all of them to share information (like current vehicle speed, or whether a door is open) without each one needing its own dedicated wiring to every other module.

How CAN bus works

A shared, broadcast bus

Unlike almost every other protocol covered on this site, CAN bus has no concept of a source or destination address at all. Every device (referred to as a node) is connected to the same shared pair of wires, and every message sent onto the bus is received by every single node simultaneously — a pure broadcast medium, rather than anything resembling the point-to-point or client/server communication seen elsewhere on this site.

Instead of addressing a message to a specific recipient, each CAN message carries an identifier, describing what kind of data the message contains (for example, “current engine RPM” or “brake pedal position”), rather than who it’s intended for. Any node on the bus that’s interested in that particular type of data simply listens for messages carrying that identifier and ignores everything else; there’s no equivalent of a message being addressed specifically to one node.

Arbitration and message priority

Because every node shares the same physical wires, CAN bus needs a way to handle two nodes attempting to transmit at the same time. It solves this using a clever electrical property of the bus itself, called arbitration.

Each message’s identifier also doubles as its priority — a lower numeric identifier value wins arbitration and is treated as higher priority. If two nodes begin transmitting simultaneously, they monitor the bus as they transmit; the moment a node sees the actual bus state differ from the bit it just tried to send, it recognises it has lost arbitration to a higher-priority message, and immediately stops transmitting, automatically retrying later. The higher-priority message continues sending completely uninterrupted, without needing to restart. This entire process happens automatically, at the electrical level, without any central controller coordinating it — a genuinely elegant design for guaranteeing that safety-critical messages (like a braking-related identifier) can never be delayed by a lower-priority one (like an infotainment update), even under heavy bus traffic.

The CAN frame

A standard CAN frame is deliberately compact, consisting mainly of:

  • Identifier: Determines both the message’s meaning and its arbitration priority, as described above.
  • Data field: Up to 8 bytes of actual payload data (a newer variant, CAN FD, extends this to up to 64 bytes).
  • CRC (Cyclic Redundancy Check): An error-detection value, allowing a receiving node to verify the message wasn’t corrupted in transit.
  • ACK slot: Any node that successfully received the message asserts a bit here, allowing the sender to confirm the message was received correctly by at least one other node on the bus.

OBD-II: a practical entry point to CAN bus

Every car sold in most major markets since the mid-2000s onward is required to include an OBD-II (On-Board Diagnostics) port, providing a standardised physical connector that gives direct access to the vehicle’s internal CAN bus, originally intended for mechanics and diagnostic equipment to read fault codes and sensor data.

Because OBD-II provides a direct, physical connection to the same CAN bus the vehicle’s own critical systems communicate over, it’s also the most common and accessible entry point for both legitimate CAN bus research and, as covered below, malicious tampering.

On Linux, the built-in SocketCAN framework, combined with tools from the can-utils package, allows a USB-to-CAN adapter connected via OBD-II to be treated much like a regular network interface:

candump can0

This displays every CAN frame currently passing across the bus in real time — identifier, data length, and payload — a direct, practical window into exactly what a vehicle’s internal systems are constantly saying to each other.

CAN bus and security

CAN bus’s design assumptions mirror Modbus’s almost exactly, for much the same historical reason: it was designed to run over a short, physically contained set of wires inside a single vehicle, where anyone with electrical access to the bus was already assumed to be a trusted mechanic or engineer, not a remote attacker.

CAN bus has no authentication and no encryption, by design. Just as covered on the Modbus page, any node that can physically (or, as covered below, remotely) reach the bus can transmit any message it likes, and every other node will treat it exactly the same as a message from a legitimate ECU. There is no way for a receiving node to verify which physical device actually sent a given identifier.

This makes message injection straightforward once bus access is achieved. An attacker with access to the CAN bus — whether through the OBD-II port directly, or through a compromised ECU elsewhere in the vehicle — can transmit forged messages carrying legitimate identifiers, and every genuine ECU listening for that identifier will act on the forged data exactly as it would on the real thing. Because arbitration is purely priority-based with no authentication involved, a forged high-priority message will even reliably win out over a genuine lower-priority one competing for the bus at the same instant.

I’ve written a few articles about how CAN bus can be the vulnerability which allows a modern vehicle to be stolen

The 2015 Jeep Cherokee remote hack remains the defining, widely-cited example of this risk. Security researchers Charlie Miller and Chris Valasek demonstrated that a vulnerability in a vehicle’s Internet-connected infotainment system (reachable remotely, over the cellular network, with no physical access to the car required at all) could be used as a stepping stone to gain access to the vehicle’s internal CAN bus. From there, they were able to remotely control functions including the vehicle’s steering, brakes, and transmission — while a journalist was actually driving the car on a public highway as part of the demonstration. The disclosure led to a recall of 1.4 million vehicles, and remains one of the most consequential and widely referenced pieces of automotive security research to date.

A video of this hack can be seen on YouTube

This illustrates a critical, recurring theme across this site’s ICS/embedded protocol coverage: a remote software vulnerability in one, seemingly unrelated system (an infotainment head unit) can become a bridge into a completely different, safety-critical system (the CAN bus controlling braking and steering) purely because that internal bus itself has no concept of authenticating who’s allowed to speak on it. Exactly the same fundamental pattern as the IT/OT convergence risk described on the Modbus page, just inside a single vehicle rather than across an industrial network.

Gateway ECUs are the primary modern defence. Because retrofitting authentication into the CAN protocol itself across an entire industry’s installed base isn’t practical, modern vehicle architectures increasingly rely on a dedicated gateway ECU, which sits between less-trusted subsystems (like the infotainment system) and safety-critical ones (like braking and steering), filtering and restricting which messages are allowed to cross between the two, rather than treating the whole vehicle as one single, flat, mutually-trusting bus the way early CAN bus vehicle designs did.

CAN FD and emerging standards like CAN bus with cryptographic authentication (e.g. AUTOSAR SecOC) exist to address this more fundamentally, adding message authentication codes to CAN frames so a receiving node can verify a message genuinely came from a legitimate source — but, much like Modbus/TCP Security, adoption is gradual, constrained by the cost sensitivity of automotive electronics and the enormous number of vehicles already on the road running the original, unauthenticated protocol.

Given all this, CAN bus stands as one of the clearest possible illustrations of a theme running throughout this site’s protocol coverage: a protocol built for a small, physically trusted environment can remain in near-universal use for decades after that original trust assumption has been completely overtaken by the reality of Internet-connected, remotely-reachable systems built on top of it.