CAN (Controller-Area-Network) is and will remain for some years to come the most prevalent vehicle bus for connecting safety critical systems in connected vehicles.
Developed by Bosch & Intel in the late 80s CAN was a great way of saving weight and sensor duplication in vehicles, at the time, becoming increasingly reliant upon electronic controls.
Take for example ECUs such as Anti-lock braking (ABS) and Engine Management Systems (EMS). Back when vehicles still had speedometer cables it made sense to pass a message representing vehicle_speed from the ABS to the EMS. After all the ABS had the best sensor.
CAN [ISO-11898] is a multi-master, priority based, serial bus consisting of twisted-pair cable. Its use of differential signalling affords noise immunity and ensures robust messaging even at low battery voltages.
Maximum transfer rates, for optimal integrity and synchronization depend on bus length. Automotive applications use bus speeds classified as low-medium [125-250 kbit/s ,L<500m]) and high [500 kbit/s - 1 Mbit/s ,L<40m].
Messages consist of data frames which include an (8 byte) payload and a (11-29 Bit) identifier or CAN ID.
example
One byte. 8 bits (0..7)
Max value 255d, 11111111b, 0xFF,
Byte as Fuel Delivery
Max Fuel Delivery 63.75 mg/stroke.
Fuel Delivery = 63.75/255 = 0.25 mg/stroke per bit.
EG 0x01 = 0.25 mg/stroke
Byte as Engine Speed
Max Engine Speed 5100 RPM.
Speed =5100/255 = 20 RPM/bit.
Besides the basic data frame, remote frames handle requests for specific identifiers, error frames transmit node errors and overload frames manage delays between frames.
In order to have such systems interact nodes publish or subscribe to messages broadcast on the CAN bus with identifiers.
The overall structure of the messages to be exchanged between nodes, and the translation of that data to meaningful information, is customarily pre-defined in a (de-facto proprietary standard) symbolic CAN [.dbc] database.
CAN, like Ethernet, combines collision sense multiple access / collision detect (CSMA/CD) rules with non-destructive bit-wise arbitration (NDA) whereby nodes may detect bus availability and reconcile messages collisions.
CAN relies fundamentally on bit-wise arbitration that enforces a binary model of dominant (0) and recessive (1) bits. If two messages are sent at the same time the dominant bit will win (IE logical AND). So crucially CAN's address structure confers precedence whereby a message with the lower numerical address has priority.
There were good reasons why CAN took off. It was relatively easy to hook up to. And it suited suppliers to engineer distinct control modules that allowed for interoperability and collaborative development whilst protecting IPR.
Vehicle systems remain quite functionally organised. Powertrain, chassis, transmissions, etc. each 'functional' department having it's own expertise, suppliers and tools.
Today vehicles have multiple CAN (and other) buses, operating at different speeds, connecting an array of controllers in the powertrain, safety, chassis, comfort 'domains' via a range of application layer protocols (some less obscure than others).
CAN's intrinsic utility has led to it's adoption in every vehicle sector and many outside. These include; machine tools, lifts, robots, aeroplanes, trains, military vehicles, ships, trains, aeroplanes and bicycles.
The problem is that advances in embedded vehicle control systems have been driven by seemingly competing imperatives. Lower emissions, improved fuel economy, improved performance, cheaper to buy, cheaper to operate, longer service intervals.
However the resulting topology makes systems integration troublesome and the validation of cross functional controls incredibly complex.
So CAN started out great, essentially P2P, but as vehicle controls grew more complex, more 'distributed' we added more buses and more protocols and and ever more complexity.
CAN originally was - quite P2P - Maybe we forgot that!.
Beneath the IPK (Instrument Pack) and IVI (infotainment) systems visible to drivers are a plethora of interconnected devices. EMS (Engine Management), SS (Stop-Start), ACM (Exhaust after-treatment), TCU (Transmission Control), DSC (Dynamic Stability), EPB (Electronic Park Brake), BMS (Battery Management), BCM (Body Control) and PATS (Anti-Theft) - just in a basic vehicle.
The Body Control Module often mediates both high and low speed CAN networks, LIN, etc. and must concur key-relay energisation with the EMS before and engine can start. Without authorisation from the PATS (Anti-theft) module and the proximity of a driver-key (RFID tag) the EMS will not energise the fuel injectors.
Cruise or active speed limiter requests from the steering wheel are relayed (via LIN) to the central BCM and re-transmitted over CAN to the EMS.
Stop-start systems rely on data obtained from sub-networks such as; ignition relay status, pedal position, battery state-of-charge, gear and clutch position, bonnet status, driver-in-seat, etc. to operate safely. Systems such as Start-Stop in particular increase vehicle attack surfaces considerably since the safety algorithm relies heavily on distributed sensing.
Problems with CAN
Many of Miller & Valsek's attacks exploit CAN's inherent open design. CAN's broadcast nature and lack of message authentication make it susceptible to node spoofing and replay attacks.
CAN is fault tolerant and ensures network wide data consistency, error detection and auto retransmission allowing nodes to shut off if necessary.
In each CAN frame a (CRC) Cyclic Redundancy Check is transmitted to allow all nodes to check message receipt, raise an error if a mismatch occurs, set flag bits and request re-transmission.
Basic counters can detect problematic devices and disable their right to raise errors. So even with broken nodes raising errors, messages will eventually be transmitted. But if there is an error flag and then the node that raised the error cannot be authenticated anyway. The CAN protocol does not specify a field to authenticate the sender.
This lack of message authentication means messages that can be forged. There is little to stop a bad actor from disrupting sensor (or SW function) inputs by broadcasting messages with the same ID thereby masquerading as the good node.
CAN's broadcast nature means the But that does not mean that devices with CAN nodes cannot interact, or have a form of dialogue. They do. Take communications between the EMS, DSC or automatic transmission for example. It's just that the conversation is in plain sight on the whole bus.
Because CAN has no access restrictions and uses bitwise arbitration to confer message priority any 'rogue' nodes can mount DoS (Denial-of-Service) attacks by flooding the bus with messages with high priority Id's. Triggering errors or forcing some node to go 'bus off'.
Whilst messaging with CAN is time deterministic. Replay attacks are possible because there is no provision for 'network time' or the age/expiry of transmitted messages. Essentially no message time-stamping or any form of network consensus about the order of events.
An attacker might disrupt sensor (or SW function) inputs by broadcasting messages with the same CAN ID. Or in a similar fashion to a DoS (Denial-of-Service) attack, cause the ECU to go 'bus off' by flooding it with higher transmission rate, higher priority messages.
Miller & Valasek illustrated, any device with a CAN protocol stack who's firmware can be 'got at' can re-programmed to become hostile. It's straightforward to record bus data, modify and retransmit it back onto the same bus, perhaps with malicious intent. IE to impersonate a good actor on the network.
Fixing CAN
Since CAN's creation there have been many attempts to improve it's basic design.
The CAN specification covers the OSI model - physical layer (Level 1) and data link layer (Level 2) with provision for an application layer (Level 7) for HLPs (Higher Level Protocols).
HLPs include for example on-board-diagnostics EG OBDII development EG ASAM-MCD and sector specific solutions such as SAE-J1939 which is commonly used in trucks and buses.
Given the safety-critical nature of automotive control systems and the 'hard real-time' nature of CAN bus itself research has mainly focused on implementing security mechanisms at the application layer.
In the next post we shall review some of these ...