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.
3 CANcrypt functionality
The first proof-of-concept implementations of CANcrypt were done on multiple NXP LPC17xx devices and a PC with a PEAK PCAN driver interface. Demo code is available for download at www.esacademy.com/cancrypt.
With CANcrypt, we offer a framework to handle both authentication and encryption of CAN messages. As there is some message overhead, the CANcrypt security features should be used only by a limited number of devices (the current version supports up to 15 devices) and only for selected messages (selected by CAN message ID). Depending on the chosen security level, encryption may be used not only on entire messages but also on selected bytes.
Security features are based on shared symmetric keys. There is a group key for all devices participating in the secure communication and a pairing key for secure channels between two devices. The secure pairing channel has a higher security level for use in system configuration or especially sensitive point-to-point connections such as bootloader communication.
The CANcrypt pairing mode connects a CANcrypt configurator with a CANcrypt device and provides a secure communication channel supporting both authentication and encryption.
Secure messages are transmitted in pairs, first a preamble message that contains security configuration details and a signature followed by the message with the data.
The dynamic pairing key used between paired devices is continuously updated by introducing new bits generated as described in section (2.2.1 “The bit-generation cycle”). The update frequency is configurable.
SECURE CHANNELS IN A CAN SYSTEM
The CANcrypt grouping mode establishes a group of secure devices. In this mode, every device produces a secure heartbeat. The dynamic grouping key is updated based on random values in the heartbeats. No other messages use security features.
All grouped devices monitor the network for manipulations (injections, collisions in the data field) and stop producing the secure heartbeat on detecting such a manipulation.
Receiving a secure heartbeat indicates that all previous messages from the transmitting device are authentic – otherwise the device would not have produced the secure heartbeat.
Note: due to application specific delays in drivers and buffers it might be necessary to wait for two following secure heartbeats before considering a message authenticated.
AUTHENTICATED GROUPING IN A CAN SYSTEM
3.2 Basic functionality
In this section, we outline the basic functionality provided by CANcrypt. This includes generation and updates of keys, generation of the one-time pad, and the generation and evaluation of the secure message pair.
3.2.1 Key management and key hierarchy
Security systems require keys. Security keys require management. Who keeps a copy of which key where? Does a manufacturer need to keep a copy of each individual key of every product ever produced? Which keys does a system builder or integrator need access to?
To support multiple keys at different security levels (for example for the manufacturer, system integrator, and owner of a system), CANcrypt implements a key hierarchy of up to six keys. Each of these keys has a key ID, and the higher the value for a key ID, the higher the security level.
Keys can never be read from a CANcrypt device. They can only be erased or newly generated. To erase a key, a configurator must establish a direct secure connection (active pairing) to a single device based on one of the stored keys. Once the devices are paired, the configurator can erase keys of the same or lower hierarchy level only.
In summary: once a key is generated and saved, it can only be erased and regenerated if paired based on a key of the same or higher security level.
KEY SELECTION FROM KEY HIERARCHY
The pairing process requires one permanent key and may also involve an optional serial number as illustrated in the figure above, “Key selection from key hierarchy”. This method allows a manufacturer to use the same base key in multiple devices. As pairing (establishing a secure channel) may also involve the serial number, a service or maintenance login could still be device specific.
3.2.2 Updating the shared dynamic keys
The dynamic key gets continuously updated following a fixed time scheme. Depending on the configuration, typical update cycle times are 500 ms, 1 s, or 2 s.
For a single pair of devices, a single new bit is generated randomly, imitated by the configurator. With multiple devices, the secure heartbeat is used to introduce new random values to by all participants.
DYNAMIC KEY GENERATION WITH SHARED RANDOM NUMBERS
As part of the secure heartbeat, all participating (grouped) devices exchange encrypted random numbers. These shared random numbers are used to generate a new synchronized shared key as illustrated in the figure above. Up to 15 devices can actively participate in this mechanism.
This dynamic key is re-generated with every secure heartbeat cycle.
In paired mode (only two devices involved), the random-bit-generation cycle is used to introduce new bits to the shared dynamic key.
ADDING A NEW BIT TO THE DYNAMIC KEY
The new bit or bits get shifted into the dynamic key (shift right). This is done in parallel by both paired devices as illustrated in the figure above, “Adding a new bit to the dynamic key”. The figure below, “New bit is shifted in”, shows the new dynamic key now used by the devices. This updated key is now used for future pseudo one-time pad generations until a new bit gets introduced.
NEW BIT IS SHIFTED IN
Even if the key update is executed by all CANcrypt devices in parallel, a secure message might still be received using the previous key. Therefore all devices must keep a copy of the previous dynamic key to decrypt and authorize messages that still use the previous key until the key update has been executed by all nodes.
3.2.3 One-time pad generation
Besides the shared dynamic key, devices also share the permanent key and a message counter (not secret) as illustrated in the figure below, “Shared parameters for pseudo one-time pad generation”. The message counter is part of every secure message pair and is transmitted with the preamble message.
The dynamic one-time pad is regenerated with each transmit or receive of a secured message. The value is based on the current dynamic key, but the bits are rotated and mixed depending on a combination of the current transmit message counter and the permanent key. This method ensures that the dynamic one-time pad’s bits experience a significant change between each use. Each device needs to maintain two message counters, one for transmit and one for receive, to be able to create the corresponding dynamic one-time pad.
SHARED PARAMETERS FOR PSEUDO ONE-TIME PAD GENERATION
In an advanced custom version of CANcrypt additional inputs can be used for the generation of the one-time pad. This can involve decrypted data from previously received messages, for example from the secure heartbeats. Instead of lightweight Speck bit mixup function, the more advanced AES-128 or AES-256 algorithm can be used to create the one-time pad.
ADVANCED ONE-TIME PAD GENERATION
3.2.4 Generating an initializer for the CANcrypt checksum
CANcrypt uses checksums for the secure message table (containing configuration data), the secure heartbeat and secure messages. The checksum for the message table is calculated with an initializer of FFFFh.
As the other checksums only cover a limited number of bytes, they must not use a simple initializer like zero or FFFFh. The default CANcrypt configuration is that the initializer for these checksums is taken from a combination of the permanent key and the dynamic one-time pad. This ensures that the initializer varies from message to message.
For advanced use, the function generating the initializer can be customized, or a completely different scheme like a security hash function or a safety protocol usable checksum may be implemented.
GENERATION OF CANCRYPT CHECKSUM INITIALIZER
3.2.5 Transmitting the CANcrypt Secure Heartbeat
The secure heartbeat consists of five bytes. The first byte is the heartbeat status byte indicating if the device is actively paired and the communication is still authenticated. The following three bytes are random numbers. The last byte is a checksum of the status byte and the three random bytes.
Before transmitting, the last four bytes (random number and checksum) are encrypted based on the current dynamic key.
SECURE HEARTBEAT GENERATION
The timing for the secure heartbeat is controlled by the detection of other secure heartbeats and an event and an inhibit time as defined in CANopen.
On receiving a secure heartbeat, a CANcrypt device participates in the heartbeat cycle by transmitting its own secure heartbeat and resetting its internal timer. Any device detecting an expiration of the event time starts the next secure heartbeat cycle by transmitting its own secure heartbeat.
Any device may start the next heartbeat cycle earlier. For example, a device might want to have a received message authenticated as fast as possible. However, the device must wait until the inhibit time has passed before initiating a new cycle. This delay ensures that the CAN bus is not flooded with heartbeat cycles.
3.2.6 Receiving a CANcrypt Secure Heartbeat
On receiving a secure heartbeat, a device first decrypts the last four bytes based on the current shared dynamic key. Then the device calculates the checksum of the status byte and the random bytes. If the calculated checksum matches the transmitted checksum, the heartbeat is considered authenticated.
SECURE HEARTBEAT VERIFICATION
On receiving a secure heartbeat, a device determines if the local inhibit time has expired – if the time since the last transmission is greater than the inhibit time. If so, the device transmits its own next secure heartbeat.
3.2.7 Transmitting a secured message
The secure transmit handler checks if a message to be transmitted is in the global configuration list for secure messages.
GENERATING THE PREAMBLE
If the message to be transmitted is in the list of secure messages, a preamble message is generated. The message contains control bytes including the CAN message ID to follow and the current transmit message counter.
Then the 16-bit signature is generated by calculating a checksum and encrypting it (the method is configurable; the default is an exclusive OR). Encryption happens based on the dynamic pseudo one-time pad.
ENCRYPTING TRANSMIT DATA
If encryption for the data is used, then the data bytes requiring it are encrypted (configurable, default is exclusive OR), also based on the pseudo one-time pad. Both messages are transmitted back-to-back on the CAN system.
3.2.8 Receiving a secured message
On the receiving side, if a message is received that is listed in the secure message list, the preamble is received first and stored in a buffer. The reception starts a 10 ms timeout. A preamble that is received without a message following within 10 ms is considered an error, and a security error counter gets incremented. The included message sequence counter is checked. The counter contains information about the dynamic update cycle and can be used to determine if the current (latest, newest) dynamic key or the previous one gets used.
RECEIVING PREAMBLE AND SECURED MESSAGE
Once the secured message is received, the local pseudo one-time pad is generated using the message sequence counter from the preamble. If parts of the message are encrypted, they are now decrypted.
Next, the signature needs to be verified. To do that, the checksum is rebuilt on the preamble controls and the message data. The signature received with the preamble is decrypted and the two are compared. If they match, the message is considered authenticated.
A secure message received is passed on to the application or protocols above the CANcrypt handler only if authentication was successful. Otherwise the message does not get passed on and is “invisible” to a device.
AUTHENTICATION BY RECEIVER
3.2.9 Multi message stream with epilog message
There might be situations where larger data blocks are transmitted with back-to-back messages. To optimize these transfers (by not requiring a preamble with every message), CANcrypt supports message sequence handling for up to eight messages.
If the control/request byte in the preamble specifies that multiple messages are part of the sequence, the signature of the preamble is not used. Instead an epilog message is inserted at the end of the sequence. The format of the epilog is identical to the preamble and contains the signature for all messages transferred with the sequence.
3.2.10 Transmitting an advanced secured message
In advanced mode, the generation of a secure message can be based on AES-128 encryption. As unused bytes are filled with random data, the total message size (consisting of the preamble and data message) is exactly 128 bits. The following figures illustrate the processes involved for encryption and decryption.
GENERATING THE PREAMBLE – AES-128 VERSION
Unused bytes in the data message are filled with random values. The preamble and data message are each eight bytes.
ENCRYPTING TRANSMIT DATA – AES-128 VERSION
Then both the preamble and data message are AES-128 encrypted using the current dynamic one-time pad.
This excerpt from the book continues in part 4 with a discussion of remaining CANcrypt attack vectors.
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.