CANopen and CANopen FD Firmware for PCAN-MicroMod FD (software only)

Challenges and solutions

CAN messages contain payloads of only a few bytes and need to be processed in real-time by occasionally tiny microcontrollers with little resources and that don't have any security hardware features.

The CANcrypt system adds different levels of security features to CAN. The basic functionality provided supports the grouping of multiple devices and supports authenticated communication between them based on a secure heartbeat. The required system resources are not only minimal in comparison to traditional cryptography methods, they can also be scaled towards the application's security requirements. On the higher end, CANcrypt supports AES-128 based encryption and authentication.

A key hierarchy allows the implementation of a smart, simplified key management supporting manufacturers, system builders/integrators and owners.

The CANcrypt system is protocol independent and can be used with CANopen or other higher-layer CAN protocols. Up to 15 devices can participate in the secure communication. A manager / configurator is only required for the generation and exchange of keys, but not during regular operation.

Limitations and levels of CAN security

Looking at CAN/CANopen systems we can identify three threat levels. These apply to most applications including automotive, industrial, medical and other machinery. These are:

• Unlimited physical access
• Sniffer access
• Remote access

If an intruder has "unlimited physical access to the entire network including device PCBs", then security options available are very limited. Having potential access to all debug ports of the microcontrollers of a system provides many other attack vectors besides CAN. This aspect is not covered by CANcrypt.

Once an intruder has direct bus access to a CAN/CANopen system, he has read access to ALL communication on the network. If he has write access, then "denial of service" style attacks (swamping the bus with messages so that nothing else gets through) are easy and cannot be prevented.

The last attack vector becomes more and more popular: remote access through some device that is a gateway to other networks. Remote diagnostics or other kind of remote access becomes more and more common, also increasing the security risk.

A manufacturer of a system using CAN/CANopen might not be fully capable of prohibiting a remote access device. Maybe such a remote access device is added by some technician or system integrator after delivery and initial installation.

Choosing cipher algorithms

Since the security algorithms are required to perform in real-time even on the smallest of microcontrollers, CANcrypt puts the emphasis on using "one-time pads". One time used random keys. True one-time pads provide the highest level of security. They are more secure than any commonly used encryption methods on the Internet.

However, how much security is really required? In CANcrypt "pseudo one-time pads" are used. The quality of the one-time pad is configurable. All parameters for performance and security can be finely tuned in the CANcrypt configuration. The default demo implementation uses variations of the Speck Cipher or AES-128.

CANcrypt key generation and shared dynamic keys

For key generation, CANcrypt uses a method that allows two devices to exchange a bit not visible to other CAN devices. This allows generating pairing keys that only the two participants know. This feature is key (no pun intended) to make the approach work and exchange keys between devices.

The base security functionality of CANcrypt is a mechanism to maintain a symmetric dynamic key shared among the grouped or paired devices. This key is initialized based on a permanent key from the key hierarchy and then modified frequently. Depending on configuration this can happen multiple times per second. In Pairing mode, update happens by introducing single random bits, in grouping mode, encrypted random data is shared and added via the secure heartbeat. The picture to the right illustrates how the shared random data is used to update the shared key.

Key hierarchy and management

Secured embedded systems require some sort of a key management system. When keys are installed, who installs which keys and how much "authority" does each key have?

In CANcrypt, the suggested method is to keep the number of key copies required outside the system to a minimum. At some point a pairing process is started generating keys – and these are only stored locally.

If at a later point devices need to be added or exchanged, a next higher authorized key is used to erase the existing pairing information and start a new pairing process.

The secure CANcrypt Heartbeat

If authentication is the primary requirement, then the secure Heartbeat functionality is all that is required. In this mode, all CANcrypt devices continuously monitor the network for injected messages. As long as a device can transmit it's messages OK and does not detect injection activity, it produces a secure heartbeat. As long as the secure heartbeats are present, the communication is authentic. Devices detect injected messages, by monitoring the communication for their "own" used CAN transmit CAN IDs. If a message is received that uses a CAN ID used by this node, then this is considered an injected message.

The core of the secure heartbeat is a 32bit signature containing three random bytes and a checksum byte. All 32bits are encrypted based on the current shared dynamic key. Receivers decrypt the signature and verify the checksum to verify authenticity.

Secure messaging

All secure CANcrypt communication uses a preamble message announcing the data message to follow. The data message may be partially or fully encrypted. A signature in the preamble ensures authenticity. Messages received are only accepted (passed on to application) if together with the preamble the authentication and decryption is successful.

Code integration

The CANcrypt functionality is mostly integrated into the "driver" level like the CAN receive interrupt and the software transmit mechanism (typically some FIFO).

During the initialization of CANcrypt, the application passes a list of CAN message IDs that require protection. The CANcrypt driver then "catches" all these messages coming in or out and applies the configured security features. The messages are only passed on to other layers of the communication protocol if the device is securely paired with its communication partners and the configured ciphering and authentication mechanisms have been applied.