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.
2 Selecting cryptographic methods
Many CAN devices are based on microcontrollers with limited memory and processing power. Yet at the highest supported speed of 1 Mbps, the CAN message rate can be as high as 10,000 messages per second. At this rate, adding reasonably safe security software to existing devices may be a challenge.
As in most security systems, there is a tradeoff between how much security we need vs. how much we can afford in terms of resources that we can spare.
2.1 Choosing cipher algorithms
Until recently, even the smallest, lightweight ciphers like Blowfish still required minimal block or key sizes of 128 bits and a substantial number of processor cycles to execute. Since the introduction of the Speck lightweight cipher block sizes down to 32 bits are possible and the algorithms are well suited to be handled by limited performance microcontrollers. By itself, all of these security algorithms do not protect from a simple monitor, record, and replay attack.
Note that even the simplest cipher algorithm like a single exclusive OR (XOR) is considered unbreakable (literally safer than anything commonly used today) if the key is as big as the data and only used once. This is referred to as the one-time pad cipher.
So for a 32-bit value transferred, if we use a single one-time 32-bit key combined with a single XOR, we already have an encryption stronger than any other cryptography method in use today.
To a certain extent (depending on how much communication overhead is used and how often), the CANcrypt system introduced in this book allows providing such an individual key. However, “the best protection available” is hardly required for CAN communication. So even if the same or just a slightly different key is used a few times, the protection would still be adequate.
A general rule for many security systems is that the more often you use a key, the more data a possible attacker has available to analyze what is happening. If keys are only temporary and never used again, the attacker has little to work with.
The configurable CANcrypt system uses the following security features:
Configurable and customizable algorithms for
Generation and update of one-time pad
One-time pad generation based on Speck or AES-128 (Advanced Encryption Standard)
Checksum / hash calculation for authentication
Encryption and decryption
Secure message size is 128 bits (two CAN messages)
Supporting 128-bit based algorithms such as AES-128
All keys are synchronous and shared among two or multiple communication partners
Current key used is the dynamic key, which changes after every use (used to generate pseudo one-time pad).
Permanent keys (hard coded or stored in non-volatile memory) are used for initialization of the dynamic key
Support of a key hierarchy (manufacturer, integrator, owner)
2.2 Elementary function: bit generation
The elementary functionality that CANcrypt provides is the generation of a bit that is known to two communication partners but not visible to anyone else. This can be a random bit, or one of the communication partners can enforce a bit. Two devices can use the bit to secretly exchange (or generate) a key. As this operation can occur at any time during operation, keys can become dynamic: new bits are introduced or added to the shared key continuously during the operation.
With this base functionality, we can pair two devices, and if the main shared key is continuously updated, the encryption, decryption, and authentication algorithms may be minimal. If the key changes randomly, an attacker that has no access to the bit generation will barely have any data to work with.
In summary, for CANcrypt the focus is not on the cipher algorithm but on the key. In the default dynamic key mode, a 64-bit key (to cover the longest possible secure data block of eight bytes) is used. The key is modified after every use. The CANcrypt configuration determines how often new random bits are introduced into this key modification.
2.2.1 The bit-generation cycle
When monitoring CAN communications on the message level, one cannot determine the device that sent an individual message because any device may transmit any message. As an example, let us allow two devices (named dominant device and recessive device) to transmit messages with the CAN IDs 0010h and 0011h and data length zero. The bits transmit within a “bit select time window” that starts with a trigger message and has a configurable length, for example 25 ms. Each node must randomly send one of the two messages at a random time within the time window.
At the end of the bit select time window, a trace recording of the CAN messages exchanged will show one of the following scenarios:
One or two messages of CAN ID 0010h
One each of CAN ID 0010h and 0011h
One or two messages of CAN ID 0011h
Note that if two identical messages collide, they’ll be visible just once on the network. If 0010h and 0011h collide, 0010h is transmitted first followed by 0011h (basic CAN arbitration).
Let us have a closer look at case 2 – one each. If the messages are transmitted randomly within the bit response time window, an observer has no clue as to which device sent which message. However, the devices themselves know it! Now a simple “if” statement can determine the random bit for both participants:
THE BIT-GENERATION CYCLE
Unfortunately we cannot use case 1 and 3, so if those happen, both nodes need to recognize it and retry – try again in the next bit select time window.
To prevent an observer from identifying individual device delays, each device should choose two good random values for each cycle. The devices should randomly pick one of the two messages (0010h or 0011h) and randomly select a delay from 0 to 2/3 of the bit select time window.
A variation of this scheme is to not use a random delay but instead ensure that both devices directly transmit their message after the trigger message. Then both messages arbitrate the bus at the same time. In a trace recording, we will always see 0010h followed by 0011h. This scheme requires very fast reactions from the two microcontrollers using the method. From the CAN receive interrupt to the
next transmit trigger, there are only a few bit times (inter frame space, seven bits), so at 1 Mbps this is just a few microseconds.
In order to minimize the chance that both devices select the same bit generation message, a variation of the scheme can use 16 or more different CAN IDs for the bit generation message. Here each device randomly selects one of the 16 messages for the bit generation. Statistically the chance that both devices select the same message is now reduced from 50% to 6%. The average duration of the complete bit-generation cycle thus shrinks drastically. The bit generation algorithm changes slightly to:
2.2.2 Protection level achieved
At the logical (message) level, a bit generated or exchanged is invisible to the other communication partner. If all you can see is the CAN messages exchanged, then by monitoring CAN messages, you will not be able to determine the bit exchanged or generated.
However, an attacker who has full physical access on a signal level (oscilloscope) or on the transceiver level (connection to the microcontroller) can see which node sends which bit-select message. Nevertheless, this access only provides partial information. In CANcrypt, configurable factors, including the stored permanent key, determine how a bit is finally generated or selected.
A note in regard to random bit generation: As usual when it comes to randomness, both communication partners require a reasonably good random generator with an appropriate seed value. (If the initial seed is predictable, so is the randomness.)
2.3 Keys: generation, hierarchy and management
Each device should support multiple keys. For example, a device manufacturer might want to use a key to protect the bootloader so that only authorized and encrypted code will be loaded.
A system integrator who puts devices from multiple manufacturers into a CAN system should also be able to generate and save keys. These keys would pair the installed devices (potentially from different manufacturers) and not allow new devices to be introduced without authorization by the system integrator.
Last but not least, on the user level, it might be desirable to generate temporary keys for plug-and-play devices. A user might have authorized a particular plug-and-play device but does not want to allow additional devices or replacements without authorization.
2.3.1 Key storage in the devices
In the participating devices, permanent keys or the last session key need to be stored in non-volatile memory. Depending on the device and how it implements the storage, an intruder might try to get access to this non-volatile memory to get access to the keys.
To illustrate the vulnerability, imagine the device is Linux based and has a file system. Storing the plain keys using the file system would be simple but also an easy target. If the device also has Internet access and ever gets hacked, reading the keys from the file system becomes easy.
A device that does not use an operating system is more difficult to hack. But attackers have shown that they can load their own code if a built-in bootloader is not well protected. If the keys are just stored in a connected EEPROM, an intruder might be able to read the key.
We should make it reasonably difficult for an intruder who hacked a device to get access to the stored keys. These are some precautions we can take:
the key storage location should not be obvious
if a file system is used, do not name file “keys”
if EEPROM is used, do not store keys at the beginning or end
offsets/filenames to the keys should not be constants; generate the keys dynamically as part of your initialization code
hide the key with random data
if you can spare the memory, place the key within a bigger random data block
encrypt the keys saved
do not store the keys as a copy; instead use some minimal encryption method on them
These methods do not add 100% security but raise the difficulty level for potential intruders to get easy access to the stored keys.
2.3.2 Key storage outside of the CAN system
Each time a key is generated, we need to ask ourselves if the key also needs to be stored outside the system. Potentially this creates the need to maintain a database with all keys ever generated. And that makes a very interesting target for attackers. If this option is chosen, the key copies stored need to be well protected by other security means.
Use of security “dongles”
One option for increased security could be that such keys are not stored on any PC, but only in hand-held security devices or “dongles”. Only if you have physical access to one of these dongles can you make changes to the security settings of a device or system. Dongles can be based on existing CAN/CANopen handheld diagnostic tools such as CANopen Diag. A cloning function allows creating backups or copies of a dongle. The drawback is that now all keys (or a group of keys) is in one physical device, but on the plus side the keys are never stored anywhere on the Internet.
This excerpt from the book continues in part 3 with an overview of CANcrypt functionality.
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.