Embedded Systems Academy

The CANgineBerry (www.cangineberry.com) is a smart coprocessor module for the Raspberry Pi®, other popular embedded microprocessor systems or a PC. It allows offloading CANopen tasks from the main system while communicating with it though a regular serial port which greatly simplifies application development. Firmware for different purposes can be programmed through the same interface. New releases for the CANopen Device and Manager application firmware are now further enhancing the functionality of the CANgineBerry.

The CANopenIA-BEDS (V1.5) firmware for CANopen devices now also supports the tunneling of plain-CAN messages for special cases where CANopen is not used or the network needs custom messages. It also adds CANcrypt to support secure and authenticated CANopen communication between up to 15 participants. Lastly, it now supports an advanced manual triggering for Transmit Process Data Objects (TPDOs) where the host application can decide when exactly to trigger the transmission of a TPDO in addition to the standard fully-automatic mode, .

The CANopenIA-MGR (V1.7) firmware implements a self-configuring CANopen controller/manager. It contiuously monitors the network for new CANopen nodes and scans their configuration in order to set up automatic PDO handling. Also here, the new version implements advanced manual triggering options for TPDOs. For example, when the application wants to write data to a remote CANopen node’s Object Dictionary (OD) entry, the default behavior is that the controller automatically decides which transport — PDO or Service Data Object (SDO) — to use, depending on whether that OD entry is part of a PDO or not. In some cases, more control is desirable, though, so now the application can disable the automatic handling and manually select SDO vs. PDO as well as manually trigger TPDO transmissions.

The latest CANgineBerry software and firmware is available here: [CANgineBerry.com]

The CANgineBerry is available here: [US] [UK] [EU] [DE]

With every start of a new year, those preparing for the Embedded World and its conference in Nuremburg get busy – so do we. This year our tutors and partners present several papers, mostly around CAN (FD), CANopen (FD) and security issues. Over the last year it became clear that in embedded communication there are a variety of attack vectors as illustrated in the figure right. For protection, security is required on multiple levels, preferably at every network layer.

Find some recommended classes below. The full program is available here.

Tuesday 26th, from Communication – CAN

09:30 – 10:00 / Troubleshooting in Embedded Networks Based on CANopen FD
Reiner Zitzmann, CAN in Automation

10:00 – 10:30 / Automated Node ID Assignment in CAN and CAN(FD) Networks
Christian Keydel & Olaf Pfeiffer, Embedded Systems Academy

10:30 – 11:00 / Signal Improvement Concept for CAN FD Networks
Yao Yao, CAN in Automation

Tuesday 26th, from HW-based Security

12:00 – 12:30 / Extend MCU Security Capabilities Beyond Trusted Execution with Hardware Crypto Acceleration and Asset Protection
Saurin Choksi, NXP Semiconductors

15:00 – 15:30 / Methods for Provisioning Security Features in a Cortex-M33 based MCU Using A Physically Unclonable Function
Rob Cosaro, NXP Semiconductors

Wednesday 27th, from Architectures & Hacking

16:30 – 17:00 / Securing all Network Layers of CAN (FD) Communication
Olaf Pfeiffer, Embedded Systems Academy
Andreas Walz, Offenburg Univeristy

Meet us at Embedded World

During the show, you will find our tutors either at the CiA booth (hall 1, booth 630) with the CANopen FD Demonstrator or at the NXP booth (hall 4A, booth 220) featuring a Multi-Layer CANopen FD Security Demonstrator.

Over the past year, our authors Christian Keydel and Olaf Pfeiffer have published several security- related CAN articles in the CAN newsletter. It’s now time for an up-to-date summary, review and outlook.

How do we address security?

To analyze the application-specific attack scenarios, we can group systems with CAN-connected devices 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 bus 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 the CAN bus 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 to obtain code and private keys. To thwart such attempts, you will have to use a secure microcontroller 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 we’ve shown, it needs only minimal resources to implement injection monitoring in combination with a secure heartbeat (see article “Scalable CAN security”). 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 we expect in the future?

In the new CiA 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 bus, 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 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.

Today, Embedded Systems Academy published the first release of a free CANcrypt FD implementation for the NXP LPC54618 microcon-troller. CANcrypt FD is a security middleware, providing authentication and encryption for CAN FD. It uses an 8-byte security record, embedded in the 64-byte data field of CAN FD frames. The cipher to use is configurable – the examples use SPECK-64, XTEA-64 and AES-128.

The base security mechanism in CANcrypt FD is a secure heartbeat that cyclically generates a dynamic, shared key among the grouped devices. The device address / ID has now 8 bits, up from 4. While still only up to 15 devices can actively participate in the key generation, another up to 239 devices can passively update their keys to transmit and receive secure messages.

A new feature is the active initial grouping cycle. Similar to the pairing process, this mode allows the automatic grouping of devices during a first-time power-up of the network. The devices participating in the grouping process generate/negotiate a group key that is then kept in local non-volatile memory.

For more details, see our article No excuses for not securing your CAN FD communication in the current September 2018 CAN Newsletter or download the CANcryptFD NXP LPC54618 example implementation including documentation.

At the upcoming CiA cyber security workshop (Nuremberg, May 2nd) our engineers participate with two presentations. We inform participants about the most common attack vectors used on CAN (FD) systems and some of the basic protection mechanisms already available today. In a second part we will outline CANcrypt based mechanisms and how they can easily be used to implement a generic security layer. This layer can be used in between the CAN Data Link Layer and the higher protocol layers like J1939 or CANopen.

The cyber security workshop is free for CiA members. To register, visit the CiA web pages.

Some people try to push easily-available “Internet-proven security mechanisms” also into embedded networks like CAN and CANopen. However, in embedded systems security is never about a single network, one needs to look at the entire picture.

We have started a series of articles about embedded security issues with a focus on CAN and CANopen networks in the CAN newsletter. In the current article we are having a closer look at taxi fare calculation as one example for an attractive hacking target. How can you be sure that you are not overcharged? What would be required to make taxi fare manipulations really difficult?

Tampering with the underlying CAN/CANopen communication is just one of several attack vectors available here. Besides manipulating the wheel with the sensor – knowing that a 3% change in diameter can result in a 10% variance in the fare calculation – there is also the sealed meter. But these days, technology like 3D printers and sophisticated electronics are also easily being used by the “bad guys”. From the article:

“Think about the manipulations already performed today to banking machines. Additional keyboards and card readers can be tacked-on to banking machines in a way that users don’t recognize the difference. In the same way a meter-like display could be designed to clip onto or fully around an existing meter. The original meter “vanishes” inside a fake meter that can display whatever the taxi driver would like it to display.”

Browse the current CAN Newsletter: March 2018

Read the full article here: Security expectations vs.limitations (pdf)

Today, EmSA released a software update for both the freely downloadable and the commercial version of CANcrypt. The update implements multiple recommendations from a security assessment.

As part of the NXP secure bootloader project, the experts at MathEmbedded did a security assessment of CANcrypt. The 43-page report examined possible attack vectors and potential weaknesses. Even to the original release the report stated: “We have not identified a straightforward attack that would allow an unauthorized attacker to easily accomplish all the steps [above].” But the latest update now fixes the discovered weaknesses or adds security notes and comments for application-specific configurations that need less security.

Just in time for the Embedded World 2018 in Nuremberg we can now show a first CANcrypt adaptation to CANopen FD. As CANopen FD already provides a direct, flexible communication method with USDO (Universal Service Data Object) supporting both broadcast and point-to-point communication, the easiest way to port the CANcrypt control messages to CANopen FD is to turn them into CANopen FD objects in the Object Dictionary. The CANcrypt control messages thus are “tunneled” through CANopen using dedicated Objects and USDO services. This allows implementing the CANcrypt grouping mechanism (similar to pairing, but for multiple devices). Authenticated messages are then exchanged based on a dynamically changing key. Each data transfer includes a random value that is used to continuously update the dynamic key.

Visit the CiA (CAN in Automation) at the Embedded World 2018 (hall 1, booth 1-630) to see the CANopen FD demonstrator and to learn more about CANcrypt. To download the free evaluation software or learn more about CANcrypt, visit our web pages for download and CANcrypt.net.

Meltdown and Spectre are considered by many to be the biggest security flaws in the history of computing, both in terms of numbers of affected devices (billions) and time they have been laying dormant (20 years). Whenever security issues like these that affect PCs and mobile devices become public, we take a look at how they might affect Embedded Systems as well. An inconvenient truth in our industry is that software in Embedded Systems does not get updated, to put it mildly, as often as regular desktop PCs. Sometimes that means “never”. That is why even “ancient” attack vectors like the WannaCry and its descendants such as Petya and NotPetya ramsomware can still cause major damage in various systems, even months or years after the underlying security issues have been made public.

The core issue behind Meltdown and Spectre is that parts of a memory protection and isolation system are being compromised on a hardware level. Such isolation is meant to ensure that one task or program can not access the memory used by another task or program and potentially spy out sensitive information. The “good news” for most older chips and many embedded microcontroller devices first: They often don’t have a vulnerable memory isolation logic (involving out-of-order or speculative code execution) in the first place. It is actually worse: The memory in most lower-end embedded chips is wide open to all running tasks. While some microcontrollers do provide an MPU (Memory Protection Unit, see ARM Community for an example), it is often limited in terms of number of memory areas, sizes and number of levels/tasks supported. From our experience it is safe to say that a large number of embedded applications doesn’t make use of it at all. And when an MPU is used, then the primary goal is often to protect code against memory-crossing bugs to make it safer against failure, but not attacks. With these types of systems, once a hacker manages to execute some code on an embedded device, this code should be assumed to immediately have access to all resources of the chip, including the memory.

This looks like a devastating assessment from a security standpoint, however, injecting code into an embedded microcontroller is not easy. Many such systems do not use an operating system at all, have no command line or only a very limited user interface without the option to load and start a piece of code. Typically the only way to inject code is through a bootloader or a debug interface, if at all. It is up to the system designers, sometimes the factory programming and the program running on an embedded microcontroller to disable casual access to these functions.

We know that for many designers of embedded systems, the time they can spend on security issues is limited. If you are part of this group, you may use the publicity around Meltdown and Spectre to justify some extra time to review potentially vulnerabilities to attacks that are based on the same principle: to load or inject malicious code that spies out or manipulates data in your embedded system.

For such a review, first look for all options how code could be injected into your system or altered. Could an attacker make use of any of the provided bootloader mechanisms or the debug interface? If you can’t disable all of these because you need to be able to update “legitimate” code, then authentication is mandatory and encryption during transmission highly recommended. Preferably implement different layers of authentication, for example one to access the interface to update code and another one to protect the code itself. For an example see the secure secondary bootloader we implemented for NXP. Also, review if your microcontroller has a MPU or similar and how you can make best use of it not only to protect the system from buggy code but also from intentional attacks.

Visit us in Nuremberg for the 28th international exhibition for Electric Automation, Systems and Components, the “sps ipc drives 2017”. The show is open from November 28th to 30th, 2017. Our software and solutions are shown on two displays at the NXP booth and the CiA (CAN in Automation) booth.

Our display at the NXP booth (Hall 10.1, Booth 325) focuses on CAN FD and security. The new features of CAN FD (bigger message frames, higher bit rate) are used to implement a more efficient and secure bootloader based on CANcrypt and AES based authentication and encryption. Join us for an informal lunch & learn session about CAN FD on Tuesday or Wednesday starting at noon (for about 45min) in the NXP on-site meeting room. Seats are limited, please register here to join.

Our display at the CiA booth (Hall 2, Booth 300) focuses on CANopen FD. A multi vendor demo setup shows one of the many new features available with CANopen FD: segmented broadcast. This transfer mode supports sharing data blocks (for example tables with data of drive acceleration ramps) instantly among multiple participants. In the demo, the data exchange is visualized using graphics, which are shared among multiple nodes.

Contact us, if you still need tickets for the event or if you would like to set an appointment to discuss your CAN FD / CANopen FD / CAN security requirements.

The CiA (CAN in Automation) user’s group released the presentation videos of the iCC 2017. Besides the keynote by Holger Zeltwanger there are three more presentations that we would like to highlight here in our blog:

Andrew Ayre and Olaf Pfeiffer (both ESAcademy): Automated trace analysis for testing of CANopen devices

This paper presents a summary of the debug information extractable from CANopen trace recordings. The functionality described in this paper are implemented in our Logxaminer software.

Olaf Pfeiffer (ESAcademy): Scalable security for CAN, CANopen, and other CAN protocols

This paper describes the main functionality of the CANcrypt security framework described in our book “Implementing Scalable CAN Security with CANcrypt”.

Bernhard Floeth (Opel) and Olaf Pfeiffer (ESAcademy): Using an enhanced condensed device configuration file format for CANopen boot-loading and/or device testing

This paper presents the enhanced CDCF player integrated in our free CANopen File Player and CANopen Diag projects. It supports spreadsheet based (.csv) Object Dictionary access with active flow control.

For a complete list of all available videos, go to: www.can-cia.org/services/conferences/icc