Embedded Systems Academy

In a blog entry from last year, we announced a “Two-year project for security of CANopen and other small-packet networks.” It is now time to give you an update on where we are with our SPsec (Securing Small-Packet Networks) project.

It comes as no surprise that adding security to small-packet networks like CAN, I2C, LIN, Modbus, and other fieldbuses is a challenge. The small-packet sizes offer only limited space for security information like an authentication tag and often, these networks are handled by microcontrollers with limited computational and memory resources. We are now aiming at protecting all communication in such a network when our initial goal was to protect only selected communication channels. The reason here is that for many industrial applications, recent acts and regulations like the European Cyber Resilience Act (CRA) will require security-by-design in the near future. For several use cases, they will also request that all data at rest and in motion is both authenticated and encrypted.

We defined the following SPsec key points and cryptographic primitives:

• Minimal hardware requirements of participating MCUs
• Cryptographic functions used
• Point-to-point security for configurations or communications with an limited amount of communication channels
• Time-based rolling key derivation for automated refreshing of keys
• Group security for multicast network technologies like CAN

For more detailed information see our white paper “Cybersecurity Primitives for Small-Packet Networks“.

Our first proof-of-concept implementation will be based on the PCAN-Router FD from PEAK-System. These devices have two CAN (or CAN FD) interfaces from which we use one for unprotected communication from a host system. The router implements a SPsec sub layer and uses the second interface for the secure communication. This allows for easy test and debugging, as there will be one CAN bus with the protected and one with the unprotected communication allowing a direct comparison.

Later the SPsec sub layer will be added to our Micro CANopen source code and integrated into various CANopen or CANopen FD devices for further testing.

Stay informed by following this blog or our linkedin page for up-to-date developments.

The popular CANopen Analysis software CANopen Magic and CANopen Logxaminer by Embedded Systems Academy have received a major update. The latest enhancement is a charting module that draws process data plots over time. In CANopen Magic, the data is captured from a live CANopen system whereas in CANopen Logxaminer it is done in post-analysis from a trace recording.

The process data charts are updated dynamically with each corresponding PDO, SDO or USDO on the network. A broad selection of triggering, filtering, scaling and measurement options allow to fine-tune the charts to the task at hand. Configurable colours and shading for each data source complete the customization options.

CANopen Magic generates process data information automatically from the EDS (Electronic Datasheet Files) files of the CANopen nodes connected to the network, making setting up charts from process data easy.

In summary, the added charting module significantly improves the build-in data analysis capabilities of CANopen Magic and CANopen Logxaminer. The charting module is now available in the CANopen Magic Professional and Ultimate editions. Get your trial here: Try CANopen Magic!

The off-the-shelf I/O module PCAN-MicroMod FD DR CANopen from PEAK-System takes advantage of protocol stack from Embedded System Academy

The I/O device for DIN rail PCAN-MicroMod FD DR CANopen Digital 1 passed both the official CiA (CAN in Automation) conformance tests for CANopen® and for CANopen FD®. The device firmware is based on the Micro CANopen Plus protocol stack by Embedded Systems Academy (EmSA), gaining easyness stepping through the conformance tests.

The device is one of the first industrial off-the-shelf I/O devices available that offer both conformance-tested CANopen® and CANopen FD® interfaces. The configuration is simplified, 4 dials are used to make the settings, which are documented directly on the housing. No further configuration software is required.

All other products from the PCAN-MicroMod FD line can load the Micro CANopen Plus protocol stack as an option. There are further aluminum-housed I/O modules supporting analog inputs and outputs, as well as PWM or frequency outputs, and a System on Module solution (SoM) to integrate customized I/O with CAN/CAN FD, CANopen, and CANopen FD operating modes.

CANopen EDS/XDD files are available for download for all PCAN-MicroMod FD products documenting the CANopen or CANopen FD functionality. Furthermore, the PCAN-MicroMod FD Evaluation Board includes a free CANopen FD license.

See the PCAN-MicroMod FD devices capable of CANopen and CANopen FD in our canopenstore.eu

Our CANopen and CANopen FD software is now available for the entire PCAN-MicroMod FD product line from PEAK-System Technik GmbH. The PCAN-MicroMod FD product line consists of several digital and analog I/O modules with housing and an embedded module suitable for integration into custom hardware developments.

PEAK offers these modules with “direct CAN (FD)” support. A configuration utility provided can assign inputs and outputs to CAN (FD) messages. That same configuration utility can now also be used to load and activate our CANopen or CANopen FD software. The activation process requires an activation code. The activation code is part of the delivery, when buying the devices from EmSA’s online store.

Once CANopen (FD) is loaded and activated, the devices implement the CANopen (FD) device profile for generic I/O devices. In CANopen FD mode, the dual bitrate of CAN FD is supported, allowing transmission rates in the data phase of up to 5Mbps.

Our YouTube channel now features a new PEAK hardware playlist. The first videos added today, show the CANopen software installation and activation process. Future videos will give further configuration examples.

The latest release of the MCUXpresso Software Development Kit from NXP now also includes a free version of the EmSA’s Micro CANopen FD library. The library is available for various microcontrollers of the LPC54xxx and LPC55xxx families. Support for the i.MX RT family will be added later this year.

The CANopen FD libraries are separated by support for devices and managers. The examples implement a generic input and output device as well as a minimal manager and control application. The libraries are fully functional besides a limitation on the number of PDOs and node IDs supported. The licence allows developers to integrate these libraries into commercial projects.

For more details on the CANopen FD libraries in MCUXpresso SDK, watch the introductory video by NXP:

Our youtube playlist “MCUXpresso Middleware course” now features a total of nine videos, including some in-depth tutorial on how to use the CANopen and CANopen FD libraries of the MCUXpresso SDK.

For more information about our CANopen and CANopen FD libraries for NXP, visit our dedicated web page at www.em-sa.com/nxp

EmSA is pleased to announce the release of version 10 of CANopen Magic. This version adds some exciting new features.

• Initial support for CiA-454 EnergyBus, including high-level message interpretation
• Simplified read and write windows with easy switching to advanced versions
• J1939 trace interpretation script
• User interface improvements

Users on a maintenance contract can obtain the new release as usual. To try out CANopen Magic with a fully-operational trial visit http://www.canopenmagic.com.

Darmstadt and Hannover, June 12th, 2019. PEAK-System Technik GmbH (www.peak-system.com) and Embedded Systems Academy GmbH (www.esacademy.de) have deepened their partnership to provide common CANopen, CANopen FD, and J1939 solutions. For more than 15 years, Embedded Systems Academy GmbH (EmSA) has offered numerous CANopen software products including monitors, analyzers, simulators, configurators, and protocol stacks for the CAN (Controller Area Network) hardware of PEAK-System Technik GmbH (PEAK). Building on that partnership, PEAK has now become a shareholder and partner of EmSA.

“By formally joining the PEAK Group of companies, we can now more easily share resources and are better positioned to streamline development processes that involve both CAN hardware and software,” says Olaf Pfeiffer, General Manager of Embedded Systems Academy GmbH.
Current projects of PEAK and EmSA include CANopen (FD) generic input and output devices, CANopen (FD) protocol libraries, security options for CAN and diagnostics and test systems for CANopen (FD) and J1939.

“The deepened partnership with EmSA will provide our hardware customers with a variety of easy-to-use software products for CANopen, CANopen FD, and J1939 applications,” says Uwe Wilhelm, General Manager of PEAK-System Technik GmbH. “We’ll announce our new joint CANopen and CANopen FD solutions on our websites and blogs over the coming months.”

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]

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.