Implementing Scalable CAN Security with CANcrypt - CANcrypt attack vectors

August 27, 2017

ESA_Olaf-August 27, 2017

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.

Continue reading on page two >>

 

< Previous
Page 1 of 2
Next >

Loading comments...