Hacking the CAN Bus
  • Jan 30, 2018
  • 5 minutes read

adel ben

Introduction

Without a doubt, as we have achieved greater technological advancement, vehicles have switched gears from a luxury to a necessity. As of 2015, over 263 million vehicles are registered in the United States1 according to Statistica, and 91% of people over the age of 16 have a driver’s license.

With so many cars on the road, it is especially important that we secure this critical infrastructure from cyber attack. So far researchers have demonstrated remote attacks which allow malicious actors to brake, steer, and disable the engine, showcasing a harrowing reality. The source of these attacks reside on a physical medium called the “CAN bus” which we are going to thoroughly examine. This post is the start of a multi-page series on:

  1. An Introduction to CAN
  2. Examples of attacks on vehicles.
  3. Reading CAN Traffic from your vehicle.
  4. The future for securing against these attacks.

What is CAN? A Brief Introduction

CAN is an acronym that stands for Controller Area Network. It is a serverless, bus network which allows microcontollers to communicate with each other. For example, CAN is the medium which allows the engine to report its revolutions per minute and engine load to the transmission, which tells other electronic components to switch gears.

Devised in 1983, CAN was invented by Robert Bosch GmbH, a German automobile component company. Originally invented for specific use in vehicles, CAN sought to address a number of growing concerns in the automobile industry. These include:

  1. The amount of wiring involved with point to point communication
  2. Lack of a unified communication standard
  3. Increasingly complex wiring harnesses due to a growing number of electronic components

CAN addressed all of these concerns and more, becoming both a revolutionary invention and a mandated standard in the United States and Europe. CAN made the process simple and easy - if you have to add another microcontroller (also named an Electronic Control Unit, or ECU) then all you have to do is to connect it to the CAN bus, compared to wiring it to each and every module it would need to communicate with.

The CAN bus system does have it’s faults however - and they can be quite dire. Let’s take a look why.

Technical Specifications

The technical specifications of CAN are important to understand the current vulnerabilities that exist within the standard. Below described are:

  1. The Physical Wiring
  2. What Messages Look Like
  3. CAN’s Primary Fault

Physical Wiring Layer

CAN data is transmitted over a shielded twisted pair, between 0V and 5V. One wire is designated as “CAN High” and the other “CAN Low”. The method of transmitting data across these is what is called “differential voltage”.

For example, when a “1” bit transmission is sent across the bus, CAN High’s voltage is at 5V, while CAN Low’s wire is at 0V. A “0” bit transmission is denoted by both wires being at 2.5V.

Fig 1. Differential voltage in CAN - From Wikipedia


This differential signaling offers what is called fault tolerance, or the signal’s hardiness against interference. If only one wire was used to transfer CAN data, more errors would occur and transmission speeds would slow down due to the number of messages needing to be resent. CAN transmission speeds operate anywhere from 100 kbit/s to 1 Mbit/s. In passenger vehicles, the transmission speed, or baud rate is 500 kbit/s while heavy duty trucks and construction equipment use a slower 250 kbit/s.

Fig 2. An example diagram showing microcontollers on the same CAN bus - From Wikipedia

What Does CAN Messages Look Like?

Answering the question “What does a CAN message look like?” is difficult given that the CAN 2.0 specification is over 70 pages long. Messages are primarily separated into two parts - an identification portion and a data portion. The identification number is an 11 bit number (29 bits for heavy duty tractor trailers) and the data portion is 64 bits, or 8 bytes.

For example, here is a message which transmits a vehicle’s accelerometer data:

Message ID: 0x213

Data: ffff00000011ff41

Notice that the message ID fits within 11 bits, and the data portion within 8 bytes. A vehicle’s accelerator is important because it can be used as one component to determine whether or not a crash has occurred.

CAN’s Primary Fault

CAN’s primary fault stems from two areas:

  1. Because CAN is a bus type network, all Electronic Control Units on the bus can see every message on the bus.
  2. CAN messages are not authenticated in any way - no microcontroller verifies that the message it received came from its expected sender.

Therefore any messages that are sent across the bus can be forged. This presents a major problem for both automobile manufactures and consumers. In today’s modern world, using CAN in such an unsecured manner for critical applications is not only dangerous but reckless. Therefore it is especially important that we take the time to consider the cost benefit scenarios that are involved with implementing better systems. In the last few years several attempts have been made to secure the standard, but unfortunately there will be some time before a unified security standard is adopted.

  • security