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.
1.4 Usage with I2 C, RS-485 and others
Many of the methods introduced in this book can also be applied to other lightweight embedded networking technologies. However, one of the central elements of CANcrypt is the bit-generation cycle. Here two nodes can gener- ate or exchange a bit without other nodes being able to detect which bit was generated or exchanged. For this method to work, a shared transmission medium is required (not dedicated transmit and receive lines). The shared medium could be a single shared wire or pair of wires, as in RS-485, or the I2 C data line in multi-master mode.
If we see enough requests, we will adapt CANcrypt to other suitable communication technologies in the future.
1.5 Definitions and Terminology
Cancrypt uses data types as defined in CANopen. Here are some of the common terms used:
Each device has a unique address. This is comparable to the node ID in some network technologies. CANcrypt supports up to 14 devices using the addresses 1 to 14.
bit-generation cycle (or bit claiming)
Two nodes can exchange a bit without others on the network being able to detect the bit value. This process, which requires multiple messages, is the bit-generation cycle.
CAN message ID
Each message has a unique identifier called the CAN message ID, typically 11 bits, sometimes 29 bits (referred to as an extended identifier).
configurator, CANcrypt configurator
The configurator actively configures individual devices for functions such as key generation, assignment, storage, and erase. The configurator is not required during regular operation and has the CANcrypt address 15.
device, CANcrypt device
A system may have up to 14 devices capable of processing CANcrypt messages.
Each device or configurator maintains an internal error counter. The count is incremented with every suspicious system behavior, including errors. If the error counter reaches a specified value, secure communication is halted.
Every active device is in a group where all devices share a common dynamic key and communicate with each other securely. Messages are authenticated and optionally encrypted and decrypted based on the group key.
index, to data object
All parameters are addressable using an index and sub-index value. This addressing method is adapted from CANopen and other networking technologies.
INTEGERxx, data type
INTEGERxx is the notation for a signed integer value where “xx” indicates the number of bits used by the data type. CANcrypt uses “little endian” notation.
A dynamic key is the base for all cryptographic functions. This key gets updated frequently and synchronously by all active devices.
Implementing of a key hierarchy is recommended to enable a device to have multiple keys with different levels of authority. For example, a manufacturer key might give access to a bootloader, while a system builder key might give access to system configurations.
As soon as keys get permanently stored in devices, key management is required to determine when each key is generated and by whom. CANcrypt supports multiple models of key management.
At least one key must be permanently stored in each device. If a device supports storing multiple keys in a hierarchy, the term permanent key refers to the stored key that is currently in use.
CANcrypt transmits each secure message paired with a preamble message that announces the secure message that follows. The secure message contains all of the data in the original (unsecure) message, possibly encrypted.
The message table is shared by all active devices. It lists all CAN messages that require security handling. A device that receives a CAN message listed in this table may pass the message to the application only if the message was received with the matching preamble and signature.
one-time pad, pseudo
For all encryptions and authentications a pseudo one-time pad is used. This one-time pad is available to all grouped or paired devices so that it can be used like a synchronous key.
Two active devices may get paired to have an individual secure communication channel. Messages are authenticated and optionally encrypted and decrypted based on the pairing key.
The preamble is a CAN message that announces the secure message that follows. The preamble contains control data as well as a signature that covers the control data and the secure message.
STRING4, data type
STRING4 is the notation for a string segment containing four ASCII characters. The string is zero-terminated. All unused bytes of this string are set to zero.
sub-index, to data object
All CANcrypt parameters are addressable via index and sub-index values. This method to address data is adapted from CANopen and other networking technologies.
UNSIGNEDxx, data type
UNSIGNEDxx is the notation for an unsigned integer value where “xx” indicates the number of bits used by the data type. CANcrypt uses “little endian” notation.
This excerpt from the book continues in part 2 with a discussion of cryptographic methods.
Copyright © 2017 Embedded Systems Academy Inc . All rights reserved.
Printed with permission from Embedded Systems Academy Inc . Copyright 2017.
Olaf Pfeiffer studied technical computer science at the Cooperative University in Karlsruhe. He is one of the founders of the Embedded Systems Academy. Together with his partners, he wrote the books Embedded Networking with CAN and CANopen and Implementing Scalable CAN Security with CANcrypt. He is a regular speaker at the international CAN Conferences and other events. Olaf is chairman of the CiA 447 standardization group that defines how CANopen is used in special purpose vehicles (including police cars, taxis) and for automotive accessories.