CAN Bus

The CAN Bus Revolution

Before CAN, vehicles used thick bundles of individual wires, each sensor connected directly to controls. A luxury car could have over 2 kilometers of wiring with hundreds of individual conductors. CAN simplified this by creating a shared network where all ECUs could communicate over just two wires (CAN_H and CAN_L), reducing wiring weight by up to 50% and improving reliability through fewer connectors and splices.

Developed by Robert Bosch GmbH and introduced in the 1986 Mercedes-Benz S-Class, CAN bus was standardized as ISO 11898 in 1994. It has since been adopted in trucks, motorcycles, marine, medical devices, industrial automation, and aerospace. The protocol handles real-time control with guaranteed latency — critical for safety systems like ABS and airbag deployment.

How CAN Works

CAN uses a broadcast, multi-master serial bus — no central controller. Any ECU can transmit when the bus is idle. Messages (frames) have an identifier (11 bits for standard CAN, 29 bits for extended CAN) that determines priority. If two ECUs transmit simultaneously, the higher-priority message wins through non-destructive bitwise arbitration.

During arbitration, each transmitting ECU monitors the bus voltage. The dominant bit (logic 0) wins over the recessive bit (logic 1). The ECU transmitting the lower arbitration ID (more dominant bits) wins the bus, while the losing ECU backs off and retries after the current transmission completes. This is non-destructive— the winning message is not corrupted, unlike Ethernet's collision detection (CSMA/CD).

Arbitration Example:

  ECU A: ID 0x123 (binary: 0001 0010 0011)
  ECU B: ID 0x456 (binary: 0100 0101 0110)

  Bit 1: Both transmit dominant (0) ✓
  Bit 2: ECU A dominant, ECU B dominant ✓
  ...
  Bit 1: Both dominant ✓
  Bit 2: ECU A dominant (0), ECU B recessive (1)
  → ECU B detects conflict, stops transmitting
  → ECU A wins, message transmitted intact

  Lower ID = Higher Priority

Message Structure

Standard CAN 2.0A frames contain up to 8 bytes of data. The complete frame structure includes:

• Arbitration ID: 11-bit message identifier (0x000–0x7FF). Determines priority and meaning. E.g., 0x200 = engine RPM, 0x400 = wheel speed
• IDE (Identifier Extension): Distinguishes standard (11-bit) from extended (29-bit) frames. Standard = dominant (0), Extended = recessive (1)
• DLC (Data Length Code): 4-bit field indicating 0–8 bytes of data (CAN 2.0) or 0–64 bytes (CAN FD)
• Data: 0–8 bytes (standard) or 0–64 bytes (CAN FD) of payload. Byte order: little-endian. Signal encoding defined by DBC files (e.g., RPM = byte 0–1 × 0.25 + 0)
• CRC: 15-bit CRC for error detection. Polynomial: x¹⁵ + x¹⁴ + x¹⁰ + x⁸ + x⁷ + x⁴ + x³ + 1. Covers arbitration, control, and data fields
• ACK: 2-bit acknowledgment slot. Receiving ECUs acknowledge valid frames by pulling the bus dominant. If no ACK, the transmitter retransmits
• EOF: 7 recessive bits marking end of frame
• Interframe Space: 3 recessive bits (IFS) before next frame

CAN Bus Speeds and Networks

Modern vehicles typically have multiple CAN networks at different speeds, isolated by gateway ECUs:

• High-Speed CAN (500 kbps): Powertrain and safety systems. Engine control, transmission, ABS, airbags, stability control. Low latency (<1ms worst case for highest priority message)
• Mid-Speed CAN (250 kbps): Chassis systems. Steering, suspension, seat control
• Low-Speed CAN (125 kbps): Body controls. Window motors, door locks, mirrors, lighting, climate control. More tolerant of wiring faults (fault-tolerant CAN)
• LIN Bus (19.2 kbps): Low-speed sub-network for switches/sensors. Single-wire, master-slave. Used for seat motors, rain sensors, window switches
• FlexRay (10 Mbps): High-speed deterministic network. Time-triggered (TDMA) operation for drive-by-wire. Now declining as Automotive Ethernet gains adoption
• CAN FD (up to 8 Mbps): Flexible Data rate — switches to higher bit rate during data phase. Same arbitration at 500 kbps, then accelerates to 2–8 Mbps for the data portion. Backward compatible with CAN 2.0

CAN FD: Flexible Data Rate

CAN FD (ISO 11898-1:2015) addresses the 8-byte data limitation of classic CAN. During the data phase of the frame, the bus speed increases from 500 kbps to 2–8 Mbps, and the data field expands to 64 bytes. This increases effective throughput from ~470 kbps to over 6 Mbps — critical for ECU firmware updates (a 512 KB ECU flash takes 7 minutes on classic CAN but under 1 minute on CAN FD).

• BRS (Bit Rate Switch): Single bit in the control field. If dominant, the data phase uses the higher bit rate. If recessive, data phase uses the same rate as arbitration
• 64-byte payload: Reduces frame overhead. A 64-byte CAN FD frame carries 8× more data than classic CAN, reducing the number of frames needed per message
• CRC improvements: 17-bit or 21-bit CRC (vs 15-bit in classic CAN) with stuff-bit counter for enhanced error detection

CAN in Modern Vehicles

A typical modern vehicle contains 30–80 ECUs connected across 2–5 CAN networks. The powertrain CAN bus carries approximately 200–500 messages per second, with critical messages (engine RPM, wheel speed) at 10–100 Hz update rates. Total CAN bus utilization is typically 30–70% on high-speed buses.

The Hacking Attack Surface

Security researchers Charlie Miller and Chris Valasek famously demonstrated remote car hacking in 2015, remotely controlling a Jeep Cherokee via its Uconnect infotainment system, which connected to the CAN bus. They could disable brakes, steering, and engine control — all through the OBD-II port or any networked connection.

The CAN protocol's fundamental security weakness is the absence of any authentication mechanism. Every ECU on the bus is implicitly trusted. There is no encryption, no message authentication code (MAC), and no sequence numbering. An attacker who gains access to the CAN bus — via OBD-II, infotainment, Bluetooth, or cellular — can inject any CAN frame and it will be accepted by all ECUs on that bus.

CAN Security Solutions

• MAC (Message Authentication Codes): AUTOSAR SecOC adds a truncated MAC (typically 24-bit) to CAN frames. Requires shared secret keys and synchronized counters between sender and receiver ECUs. Adds 4–8 bytes overhead per frame
• Intrusion Detection: CAN IDs check, timing anomalies, and message frequency monitoring. Anomaly-based IDS detects unusual CAN traffic patterns (new IDs, unusual frequencies, unusual data values)
• Secure gateways: Gateway ECUs isolate powertrain CAN from infotainment CAN, filtering messages by ID and direction. Only authorized CAN IDs are forwarded between network segments
• ECU authentication: Each ECU signs messages with a private key stored in a hardware security module (HSM). Receiving ECUs verify signatures using the sender's public key. Prevents spoofing but adds latency
• Physical security: OBD-II port access monitoring, tamper detection, and physical locks. Some systems disable the OBD-II port when the vehicle is in motion