Implementing Scalable CAN Security with CANcrypt - Crypto methods
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.