Embedded Systems Academy

The EU Cyber Resilience Act does not make an exception for a device because it speaks CAN rather than Ethernet. If you build or integrate industrial control units on CAN or CAN FD, you now have to show that your product resists tampering, updates itself safely, and manages its keys with care. We have gathered what that takes into a new and free reference at https://cansecurity.net/.

The pressure comes from regulation: the Cyber Resilience Act and the Machinery Regulation turn security into a legal obligation for products with digital elements, and IEC 62443 sets the technical bar an assessor will measure you against. On some CAN nodes based on constraint microcontrollers, clearing that bar is an engineering problem rather than a checkbox.

The reference works through that problem in the order an engineer meets it. It names the threats a broadcast bus exposes, walks a risk assessment built on CVSS v4.0 and IEC 62443-3-2, and catalogs the controls that fit a fieldbus: bus-load monitoring, local injection detection, cryptographic frame security, anomaly and event monitoring, secure object access for CANopen, zoning and
segmentation, and an authenticated secure bootloader. A separate section covers key management, from the choice between symmetric and asymmetric keys through per-device diversification, the manufacturer-to-integrator-to-operator handover, and the point where a minimal public-key infrastructure is enough.

A few resources stand on their own. There is a Cyber Resilience Act Annex I requirements matrix and an IEC 62443 SL2 component-requirements table, a maintained list of CAN FD microcontrollers that pair the interface with on-chip security such as a true random number generator, secure key storage or cryptographic accelerators. Plus a set of measured benchmarks showing what SHA-256, HKDF, AES-128-GCM, Ed25519, and X25519 cost in flash, RAM, stack and time on real parts. When a datasheet claims a hardware accelerator, the benchmark page shows what improvements you can expect.

Take a look at https://cansecurity.net/ and tell us what you are missing. We will keep adding to it.

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.