Implementing Scalable CAN Security with CANcrypt - Introduction and rationale
Editor’s Note: Advanced vehicles present multiple threat surfaces and demonstrations of vulnerabilities continue to generate headlines. Among those vulnerabilities, the standard CAN bus has been a favorite point of entry, enabling access to the diverse digital control systems within newer vehicles. With the next generation of connected vehicles, the need for secure networking within vehicles becomes even more urgent as more diverse wireless connectivity options in vehicles present even more options for unauthorized access to vehicles and their control systems. In the book, Implementing Scalable CAN Security with CANcrypt, Olaf Pfeiffer offers a vitally needed improvement on the conventional CAN protocol.
This excerpt from the book provides an introduction to CAN security in four installments:
Adapted from Implementing Scalable CAN Security with CANcrypt, by Olaf Pfeiffer (Embedded Systems Academy), 2017.
When the Controller Area Network (CAN) was designed, security was not a requirement. The primary usage of CAN was considered closed; possible intruders or attackers would simply not get physical or remote access to the network. However, today it is more and more common that devices connected to a CAN system also have connections to other networks, including the Internet. Recent car hacks have shown that attackers may get access to CAN systems. Without strong security features, an attacker automatically gains full access to everything connected, allowing active control commands to be recorded and replayed.
In this book we examine which options developers of CAN based systems realistically can use to provide adequate security features.
What can we do...
without introducing heavy-weight security protocols?
to detect possibly injected messages?
without any hardware change?
with minimal software change and integration effort?
We introduce the open CANcrypt protocol and software interface, which provides a scalable and customizable CAN security system. Depending on the application requirements and resources available in the individual devices, various protection levels can be realized.
The CAN (Controller Area Network) is a 30-year-old communication technology that worked well for much of its history without any security features. So what changed that now some 30 years later we need to review the network’s security features?
The original use case for CAN systems was that of a closed network. The network would be deeply embedded in machinery without any connection to other networks or the Internet. In this case, any hacker attack would only be a physical attack – to get access to the CAN subsystem, a hacker would need physical access to the machine.
However, today the CAN subsystem is no longer self-contained. More and more often, bridges and gateways to other networking technologies are added, including connections to devices that have access to the Internet. Some examples of these devices are remote access devices for diagnostics or maintenance and multimedia servers like those in use in some automotive applications.
When we add devices that implement a gateway to the Internet or offer wireless communication options like Bluetooth and Wi-Fi, we also open a door for possible attacks to the CAN network.
Once a possible intruder is past the firewalls that limit access, there are typically no further hurdles as all communication is unprotected and in the case of CANopen or J1939, even well documented.
You should have a reasonably good understanding of how the Controller Area Network works before continuing reading. If you are unsure, we suggest reading (CiA 301, V4.2 2007) or one of the many online “Controller Area Network Primer” documents like this.
Embedded Systems programming knowledge is required as soon as you want to start implementing CANcrypt on microcontrollers. In this book you will find pseudo code as well as a description of the C functions that make up the user interface of CANcrypt.
1.3 What is at risk?
Some might ask what the specific security risk is. Here the popularity of CAN comes into play. These days almost everything with wheels uses CAN (including electric bikes). Maritime and avionic use is also common. You can find CAN in elevators, medical equipment (including surgery robots), and many industrial control processes. Various “car hacks” have been made public, including odometer manipulation and unlocking doors but also active control of steering and brakes.
CAN is also a popular communication channel for software updates. Often new software can be loaded into components of a system via a CAN channel. This ability is a hacker’s dream come true – being able to load software into a device with an embedded system that otherwise would not be accessible.
If these systems can be hacked, and hackers can both read and actively send commands/control, then we have to ask ourselves:
How many hackable vehicles, ships and planes are out there?
How many hackable elevators are out there?
How many hackable medical devices are there?
Is it possible to manipulate any of the above in a way that someone gets harmed and it is only recognized as “technical malfunction”? Today some of these questions might still sound like the topic for a Hollywood blockbuster. However, it makes one wonder how Edward Snowden would evaluate the likeliness of such scenarios. Maybe it has already been done and just not published.