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 current status of the EU Cyber Resilience Act (CRA) is that manufacturers of devices with digital elements or any software have until 2027 to comply with the outlined rules and regulations. These include compliance issues like overall risk assessment, documentation and incident reporting – which have a huge organizational impact. Technology details mentioned in the CRA are limited, so there is some interpretation as to what it all means for embedded systems and fieldbus communication. When it comes to specifics, the annex talks about how to treat data in transit:

Text excerpts from Annex I, 1. (3) (c) and (d) (emphasis ours):

• Products shall protect the confidentiality of stored, transmitted or otherwise processed data, personal or other, such as by encrypting relevant data at rest or in transit by state of the art mechanisms.
• Products shall protect the integrity of stored, transmitted or otherwise processed data, personal or other, commands, programs and configuration against any manipulation or modification not authorised by the user, as well as report on corruptions.

In other words:

• When communicating or storing (to non-volatile memory) relevant data then encrypt it.
• When communicating or storing (to non-volatile memory) any data then authenticate it.

There is not much room for exceptions here, discussing what is relevant might be challenging. If it is not relevant, then why communicate or store it in the first place?

There might be some relief in Annex I, 1. (1) which says:

• Products shall be designed, developed and produced in such a way that they ensure an appropriate level of cybersecurity based on the risks.

This can be a way out for some applications if in the risk assessment a security expert can show that there is no risk in not protecting certain data. Nevertheless, the security assessment must also reflect the following two statements:

1. Apply security-by-design to the entire lifecycle (min 5 years), from development process to production, deployment, and use/maintenance.
2. Products integrated in or connected to a larger electronic information system can serve as an attack vector for malicious actors.

These two statements have a huge impact on all microcontroller communication like plain UART, RS-485, CAN or other fieldbuses. The second statement boils down to not making a difference between important and lesser important communication. Even the lesser important communication may serve as an attack vector to the system.

The first statement requires layered security mechanisms given that protecting a single aspect won’t be sufficient. Taking CAN as an example, let us have a look at the known three stages of most common attacks on CAN systems:

1. Get access to the CAN communication.
   For example by accessing the CAN wires or hijacking a device (or interface to another network) already connected.
2. Monitor the CAN communication to learn from it.
   The attacker learns which CAN frames are used for what.
3. Inject or replay CAN communication to maliciously trigger behaviour.
   The attacker “takes over” certain aspects of the system.

By protecting any one of these three stages, the attacker’s success can be thwarted, and the system might seem “secure”. However, what if in the foreseeable future an attacker finds a way around that single protection? Security-by-design requires that we pay attention to all possible stages of an attack and do not focus on a single point of potential failure.

In any future risk assessment of a system using any form of communication (fieldbus or application specific communications), manufacturers will need to show which steps they took to protect all aspects:

1. Which steps were taken to minimize physical access?
   How easy is it to access the network wires? Can diagnostic ports be protected? Which interfaces to other networks are there? How are they protected?
2. Which steps were taken to keep communication confidential?
   To prevent attackers from learning anything about the system, encrypt all relevant communication.
3. Which steps were taken to ensure communication integrity?
   To prevent attackers from manipulating frames, authenticate all relevant communication.

In summary, to be EU Cyber Resilience Act compliant, a lot of the future fieldbus communication needs to be both authenticated and encrypted. To simplify the risk assessment and documentation, this should be done for all communication. Otherwise, manufacturers need to be prepared to have a security expert document every unprotected communication as to why this specific data set is irrelevant enough so that even if read or manipulated it won’t possibly constitute a cybersecurity risk.

Follow this blog and/or our LinkedIn page to learn about latest related developments including our upcoming security solutions for CAN, CAN FD, CANopen and CANopen FD.

This year, Nuremberg’s doors open for the Embedded World (#ew24) from April 9th to April 11th. From EmSA, Peter, Chris and Olaf will be at the event all three days. If you want to talk to us about topics like CAN, CANopen, J1939 and CAN security, meet us at the booth of Peak-System, hall 1, booth 304.

As every year, the conference also features a CAN session. This year it is session “SESSION 2.2 CONNECTIVITY SOLUTIONS | CAN” (April 9th, starting at 1:45PM) with the following presentations:

Thilo Schuhmann: Standardized Cybersecurity in CAN-Based Systems

This paper concentrates on cybersecurity requirements specific to embedded systems employing Controller Area Network (CAN) communication, encompassing CAN, CAN FD, and the emerging CAN XL. Our primary focus lies on CAN XL, which incorporates CANsec, a data link layer add-on facilitating message authentication and encryption,in the data plane. In the control plane the specification of the CANsec Key Agreement protocol (CKA) is defining for key exchange and agreement mechanisms to allow broadcast communication for the authenticated and encrypted messages.

Reiner Zitzmann: Improved Network Start-up for Dynamically Changing Embedded CAN Systems

Controller Area Network (CAN) networks often serves as the conduit for data exchange; on the very deeply embedded level. Devices, connected to these embedded networks may be dynamically added or removed, by the end user. Thus these devices need to show a certain degree of plug and play behavior. Host controllers must have the ability to rapidly identify these devices. Unlike current implementations, the enhanced Layer Setting Services (LSS) enable CAN/CANopen devices to convey their identity to the host controller or LSS manager. This eliminates the need for laborious searches to determine the presence and type of newly added devices. The presentation shows the functioning of the improved Layer Setting Services, and practical use cases.

Olaf Pfeiffer: Collaborative Design of Security Measures for CAN and CANopen Systems

The rise of connected devices in the embedded world has intensified the need for strong security measures, especially in Controller Area Network (CAN) and CANopen systems. These technologies are crucial in a wide range of applications such as industrial automation, automotive systems, and medical equipment. Given the limited resources available in CAN protocols, security often becomes a challenging aspect to address effectively. This paper presents a joint project between Hochschule Offenburg and Embedded Systems Academy, focusing on overcoming these security challenges.
We argue that collaboration among multiple partners is essential for the design and implementation of effective, robust security measures. Our proposed security framework brings together expertise from various stakeholders to identify vulnerabilities, assess potential threats, and formulate countermeasures. A significant aspect of our project is the aim to standardize these security measures through the CAN in Automation (CiA) organization. This makes the security framework transparent and open for public review.
The framework is optimized for CANopen but can also be used by CAN, CAN FD, CANopen FD and other higher-layer protocols.
This paper will outline the architecture of our security framework, showing its applicability to a broader range of CAN or CANopen based applications.

You can’t make it to Nuremberg?

For the latest news and developments in CAN, CANopen and CAN Security, follow us here: https://www.linkedin.com/company/embedded-systems-academy/

For more info on these topics, also see our video collection at https://www.em-sa.com/video

We are pleased to announce the recent establishment of the Embedded Systems Academy LinkedIn page. This platform will function as a continuous source for updates, technical discussions, and detailed articles focusing on CAN, CANopen, and J1939 technologies, our main areas of expertise. The materials presented there will offer a more detailed analysis compared to the posts on this blog.

The first series of articles is developed to provide professionals in the field of embedded communication systems with valuable insights and knowledge. It includes application articles that demonstrate the application of CANopen in areas such as warehouse logistics and emergency response vehicles.

Additionally, we have a series of four articles that examine the requirements for building embedded networks capable of handling diverse real-time communication demands. This series discusses the various real-time requirements of different applications, offering guidelines on how to effectively employ CAN or CANopen to address these unique cases. This series is called Balancing Speed and Priority: Crafting Embedded Networks for Diverse Real-Time Communication Demands.

We invite you to follow our LinkedIn page to stay updated on the latest technical advancements and insights in the industry.

Thank you for your support!

February 24, 2020 – Embedded Systems Academy (EmSA) and NXP® Semiconductors announce the integration of the free-to-use EmSA Micro CANopen libraries into the NXP MCUXpresso Software Development Kit (SDK) for developing with NXP’s microcontrollers (MCU) and crossovers based on Arm® Cortex®-M.

For years, many MCUs have been equipped with the Controller Area Network (CAN) interfaces including CAN FD. These interfaces are optimized for embedded communication and make it easy to transmit and receive single messages.

“To take full advantage of the capabilities of such interfaces, middleware communication protocols are required,” says Olaf Pfeiffer, General Manager of EmSA. “One of the most
popular protocols for embedded CAN applications is CANopen, for which EmSA has delivered its Micro CANopen software for more than 20 years, and remains highly used among embedded developers.”

Free-to-use versions of EmSA’s Micro CANopen library are now fully integrated into the MCUXpresso SDK for a selection of NXP LPC MCUs and i.MX RT crossover MCUs.

“This integration further simplifies the process of prototyping and integrating sophisticated and reliable communication into embedded systems.” said Brendon Slade, director of MCU ecosystem for Edge Processing at NXP Semiconductors. “For most systems, the libraries can be used in production without further licensing.”

One of the first adopters is PEAK-System Technik: Their industrial I/O module PCAN-MicroMod FD is based on NXP’s LPC54000 MCU series and uses a variation o

f EmSA’s Micro CANopen libraries. “Using a proven CANopen (FD) protocol implementation for our I/O devices greatly reduced our development time and opens up additional use-cases for our customers.”, says Uwe Wilhelm, General Manager of PEAK-System Technik.

For more information about the NXP microcontrollers currently supported by EmSA’s free to use CANopen libraries and video tutorials, visit www.em-sa.com/nxp

About MCUXpresso SDK
Available in downloads based on user selections of MCU, evaluation board and optional software components, the MCUXpresso SDK merges customization and quality in a suite of production-grade runtime software. Complete with pre-integrated RTOS middleware, stacks and middleware, reference software, and MISRA-compliant drivers analyzed with Coverity® static analysis tools, it’s the ultimate software framework and reference solution for application development with NXP MCUs and crossover MCUs based on ARM® Cortex®-M cores.

About Embedded Systems Academy
Embedded Systems Academy (EmSA) is an NXP gold partner and has locations in Barsinghausen, Germany and San Jose, California. EmSA provides tools, training and services for planning, implementing, debugging, commissioning and testing of embedded networking technologies including CAN, CAN FD, CANopen, CANopen FD, CiA447, J1939 and others. EmSA’s tutors Olaf Pfeiffer, Christian Keydel and Andrew Ayre published two books about CAN, CANopen and security on CAN systems. They regularly publish related articles and papers for various international conferences.

Contact
Embedded Systems Academy GmbH
Olaf Pfeiffer
info@esacademy.de

Over the last years we published more than 50 articles, papers, books, webinars and we also continuously updated our training materials. However, some of the training material and especially scientific papers only reach a small percentage of the embedded community. Therefore we decided to publish more free educational videos to reach more of you. As a start we created several playlists on our EmSA Youtube channel. These include:

• CANopen FD Intro:
  Introductory videos to CANopen FD, also covering some basics like an introduction to the CANopen Object Dictionary concept
• CAN (FD) Security:
  Video collection about CAN and CAN FD security challenges and solutions
• MCUXpresso Middleware:
  Video collection about NXP’s MCUXpresso and CANopen libraries included

We plan to publish more videos in the upcoming month, further focusing on CAN, CAN FD, CANopen, CANopen FD topics including introductory videos as well as in-depth technology classes.

Please subscribe to the channel to stay informed about new videos published.

Our authors Christian Keydel and Olaf Pfeiffer published an article in the current CAN newsletter, summarizing the current status of CAN security specifications.

Please follow the link above for more details.

Excerpt:

End of June 2019, the CiA association hold a phone conference for safety and security issues. Holger Zeltwanger gave the participants an update regarding “base documents”. When defining security solutions for Classical CAN, CAN FD, or CAN XL systems, it would be preferable to not start from scratch defining security basics for embedded systems or embedded communication systems. Unfortunately, the current draft of ISO 21434 “Road Vehicles – Cybersecurity engineering” does not seem to be suitable, as it is very generic and not yet completed. It is more of a guideline what designers and developers need to keep in mind when designing a “secured” vehicle.

Another document suggested is the “Baseline Security Recommendations for IoT” by the European Union Agency for Cybersecurity. Until the next meeting, CiA will review and report, if that document is suitable to be referred to also by CiA documents. CAN XL is still in an early specification phase and the related special interest group, recognizing the possibility for security features in hardware to be part of future CAN XL controllers, therefore suggested adding security features to CAN XL first. One of the discussed options is a blacklist/whitelist scheme like the one implemented by the NXP secure CAN transceiver family. Such a scheme can eliminate several potential attack vectors at once if all participants in a CAN (XL) network actively support it. Once we see which security features made it into the CAN XL specification (and hardware), we can review if any of these can still be applied to CAN FD, too, for example on the transceiver level.

However, potential CAN controller specific hardware security features will most likely not be suitable to migrate back into CAN FD, so protocol based security solutions are still required.

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.”

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.