Implementing Scalable CAN Security with CANcrypt - CANcrypt attack vectors -

Implementing Scalable CAN Security with CANcrypt – CANcrypt attack vectors

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.

Adapted from Implementing Scalable CAN Security with CANcrypt, by Olaf Pfeiffer (Embedded Systems Academy), 2017.

4 CANcrypt attack vectors

In this chapter we examine the remaining attack vectors of CANcrypt.

4.1 Randomness

Wherever random numbers are used, a typical attack vector is to assume that the numbers are not random and to determine a pattern. The random numbers used by the paired devices must be “reasonably good”, and they must differ with every power cycle.

This might be a challenge for many microcontroller systems. The random functions provided by C compilers are typically not good enough to ensure “randomness”. If these are used, it is important to update the random seed used by this function as often as possible.

One possible option is to maintain and update a seed value that is constantly updated (using any arithmetic function) depending on inputs from A/D converters (especially highest resolution bits), high-resolution timers (measuring timestamps of CAN messages received).

Latest microcontrollers more and more often have a dedicated random number generator. Where available, these should be used.

4.2 Creation and storing of permanent keys

The phase where keys are stored permanently is crucial. Even if an intruder cannot see keys generated by the CANcrypt methods, a potential intruder present at this stage would be a security concern. So whenever initial pairing keys (no matter if by the manufacturer or system integrator) are generated and stored, extra precautions should be taken to ensure that no intruder is present.

The precautions can include verifying that only those devices that are physically connected to CAN are required for this process.

Some microcontrollers offer dedicated memory locations for storage of security information. Where available, this area should be used to store the key(s) with the highest priority.

If “regular” FLASH memory is used, ensure that the FLASH protection bits are set. Specific functionality of these depends on the manufacturer. Usually these can be configured in a way that only the code executed from the FLASH memory can read-access this memory. Where possible, protect the FLASH from being read from RAM and FLASH programming ports/interfaces.

4.3 Debug and bootloader interfaces

Microcontrollers with an enabled JTAG or SWD interface for debugging or an internal bootloader to reprogram the device can be very vulnerable to attacks. This is especially true when these accesses are also made available through other communication interfaces such as UART, USB, or even CAN. Using an appropriate debugger or programming tool, an intruder can manipulate memory contents and inject code.

For highest security, all such interfaces should be internally disabled. Bootloaders should only be enabled if they offer their own security levels such as protection from unauthorized activation and supporting flashing only of authorized files.

4.4 Read/write access to CAN system

This section summarizes attacks where the intruder has full CAN level access and can receive all messages and inject messages at will. The access could be through a physically connected sniffer or a remote access device.

In CAN networks, a typical attack involves recording messages and replaying them. If the messages exchanged after power up are always the same, an attacker could fake initial messages by replaying them. However, due to the dynamic, random key changes, a hacker would probably look at alternate methods first. Examples include trying to activate a boot loader or re-flashing a device with new code.

4.5 Ability to physically remove/replace devices

With physical removal, an attacker has the ability to reprogram (re-flash) a connected device.

If one of the paired or grouped devices is removed and replaced with a tampered device, the tampered device can participate in the key generation or grouping cycles. However, all pairing and grouping functions also use elements of a permanent key. With endless time and re-tries an attacker might be able to determine parts of the permanent key. To make this attack vector less attractive, CANcrypt uses incremental delays on pairing/grouping re-tries.

4.6 Signal level access to CAN and PCBs

The result that can be achieved with signal-level access heavily depends on many factors. With PCB access to a CAN transceiver, an attacker would be able to see the bit generation. If session pairing is used, the attacker can see all keys generated. If permanent pairing is used, an attacker would still be able to learn changes to the dynamic key over time and eventually have a copy of the dynamic key. Although this level of attack is theoretically possible, any active attack trying to manipulate or fake data would still be difficult as it would require hard, real-time reaction.

Note that this attack option is not available if the paired devices use controllers with integrated transceivers such as some of the NXP LPC11Cxx devices.

4.7 Summary

At this point we are not aware of any “promising” attack vectors on the CAN/CANopen level in a CANCrypt system. That includes remote access (for example through a hacked gateway) as well as direct access with a CAN sniffer utility.


Achieving Confidentiality Security Service for CAN.  Chavez, Rosete, Henriquez. 2005.  s.l. : Electronics, Communications and Computers, CONIELECOMP 2005, 2005.

CANAuth – A Simple, Backward Compatible Broadcast Authentication Protocol for CAN.  Anthony Van Herrewege, Dave Singelee, Ingrid Verbauwhede. 2011.  s.l. : ECRYPT Workshop on Lightweight Cryptography, 2011.

Checksum and CRC Data Integrity Techniques for Aviation.  Koopman, Philip. 2012.  s.l. : Electrical & Computer Engineering, 2012.

CiA 301. V4.2 2007.  CANopen Application layer and communication profile.  Nürnberg : CAN in Automation (CiA) e.V., V4.2 2007.

CiA 305. V2.2.17 2013.  CANopen Layer setting services (LSS) and protocols.  Nürnberg : CAN in Automation (CiA) e.V., V2.2.17 2013.

CiA 416. V2.0 2007.  Application Profile for Building door control.  Nürnberg : CAN in Automation (CiA) e.V., V2.0 2007.

CiA 447-1. V2.0 2012.  CANopen Application profile for special-purpose car add-on devices.  Nürnberg : CAN in Automation (CiA) e.V., V2.0 2012. Vol. 1: General Definitions.

Exploring Controller Area Networks.  Ian Foster, Karl Koscher. 2015.  6, s.l. : login, 2015, Vol. 40. 

Fast and Vulnerable: A Story of Telematic Failures.  I. Foster, A. Prudhomme, K. Koscher, S. Savage. 2015.  Washington, DC : Proceedings of the 9th USENIX Workshop on Offensive Technologies , 2015.

Koopman, Philip.  Best CRC Polynomials. [Online] Carnegie Mellon Univeristy.

Miller. 2015.  Remote Exploitation of an Unaltered Passenger Vehicle.  Las Vegas, NV : Black Hat USA, 2015.

Miller, Valasek. 2014.  A Survey of Remote Automotive Attack Surfaces.  Las Vegas, NY : Black Hat USA, 2014.

Pfeiffer, Ayre, Keydel. 2003.  Embedded Networking with CAN and CANopen.  San Jose : s.n., 2003.

Plug-and-secure communication for CAN.  Andreas Mueller, Timo Lothspeich, Robert Bosch GmbH. 2015.  Vienna : international CAN Conference, 2015.

Ray Baulieu, Douglas Shors, Jason Smith. 2013.  The SIMON and SPECK Families of Lightweight Block Ciphers.  s.l. : NSA, 2013. Cryptology ePrint Archive 2013/404.

Schmeh, Klaus.  Klausis Crypto Kolumne. [Online] krypto-kolumne/.

Smith, Craig. 2016.  The Car Hacker's Handbook: A Guide for the Penetration Tester.  s.l. : No Starch Press, 2016.

Voss, Wilfred. 2008.  A Comprehensible Guide to J1939.  s.l. : Copperhill Media, 2008.


Writing a technical book is seldom a single-person achievement. I hereby express my gratitude to everyone who contributed to this book. Some did this knowingly, others unknowingly. With his publications and talks, Klaus Schmeh (Schmeh) continuously keeps fuel- ing my interest in everything related to cryptography and has done so for many years. His works and examples are a reminder that cryptography comes in many varieties. The works of Ian Foster (Fast and Vulnerable: A Story of Telematic Failures, 2015) (Exploring Controller Area Networks, 2015), Charlie Miller (Miller, 2015), Chris Valasek (Miller, 2014), Craig Smith (Smith, 2016) and others have revealed various security vulnerabilities in systems using CAN. Their efforts have drastically in- creased the overall awareness for CAN-related security issues.

The NSA published the SPECK (Ray Baulieu, 2013) lightweight cipher in 2013. At first I was reluctant to use a NSA published cipher. However, until 2017 none of the many publications about it found any major caveat. A variation of SPECK is used for the default implementation of CANcrypt. However, just to be sure, its use in CANcrypt is on top of dynamically changing keys. An attacker who is able to determine a single dynamic key only has a few seconds (or milliseconds) to exploit it until the next key is used…

The CiA (CAN in Automation user’s group) maintains most CAN and CANopen related standards. Participating in many standardization meetings has taught me that occasionally one just has to “do it,” otherwise it might take years until first results are available.

My partners and colleagues Christian Keydel, Andrew Ayre and Ralf Kindermann offered continuous support and help with many of the technical aspects of the CANcrypt protocol as well as implementation-specific issues.

The lector for this book project has been Jan Axelson ( Jan is a known technology writer and was a perfect match for this project from the start.

And last, book projects commonly require unusual working hours. And those re- quire support and patience from the loved ones surrounding you. Leah, Magnus, Maria, thank you!

Olaf Pfeiffer February 2017

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.

Leave a Reply

This site uses Akismet to reduce spam. Learn how your comment data is processed.