Open search

Security column

Updates and outlook on securing CAN

Over the past years, Olaf Pfeiffer and Christian Keydel from Embedded Systems Academy (Emsa) have published several security-related CAN articles in the CAN Newsletter magazine. It’s now time for an up-to-date summary, review, and outlook.

(Photo: Fotolia)

To analyze the application-specific attack scenarios, systems with CAN-connected devices can be grouped as follows:

  • Private and locked: Only trusted persons have physical access to CAN wires and devices. There are no gateways to other networks.
  • Remotely accessible: The CAN network is connected to one or multiple gateways to other networks.
  • Time-limited physical access: An untrusted party can be expected to have physical access to CAN and devices for a limited time.
  • Unlimited physical access: An untrusted party can be expected to continuously have physical access to the system.

What measures should be taken?

The recommended security measures for the mentioned groups range from none for group 1 to state-of-the-art for group 4 which presents the toughest challenge. With virtually unlimited physical access, an untrusted party can go as far as using flash/code extraction services for MCUs (micro-controller unit) to obtain code and private keys. To thwart such attempts, users have to use a secure micro-controller with built-in encrypted key and code storage like the NXP LPC54Sxx series for example. Here, the encryption is based on a private PUF (Physical Unclonable Function) which uses physical properties that vary for each chip and can never be extracted, like contents of uninitialized SRAM.

Securing CAN communications is a viable option especially for group 2 and in combination with physical protection also group 3 applications. As shown in further articles, it needs only minimal resources to implement injection monitoring in combination with a secure heartbeat (see article “Scalable CAN security” in the CAN Newsletter magazine). However, due to the limited data size in CAN messages, individual message authentication often requires sending a second message with the authentication data.

With CAN FD, adding security becomes easier, as the payload and security record can often be combined in a single CAN FD data frame, avoiding the overhead of managing a second authentication message.

What can be expected in the future?

In the CAN in Automation CAN cyber security group it has become clear that where security is required, it should be added to all communication layers. To add message monitoring and flood protection to the CAN network, there are hardware solutions like NXPs TJA115x secure CAN/CAN FD transceiver family. Similar protection can be added in software to the lowest driver layers. Just above the data link layer, CANcrypt (FD) provides a secure grouping mechanism. For the Classic CANopen/CANopen FD and J1939 protocol layers, different security features can be implemented, including authenticated access for diagnostics or remote-control features. Reaching highest security levels will only be possible if the hardware supports securing the software and communications, using built-in features for the protection of stored code and keys.

You can find here the previous security-related articles from the company, published in 2018:


Publish date