Embedded Systems Academy

Learn from Arm’s Christopher Seidl and NXP’s Kyle Dando as they explore how different software layers interact to create efficient industrial systems.

Chris Keydel from EmSA will talk about industrial networking with CANopen and how to integrate Micro CANopen Plus into your own application using Open-CMSIS-Packs.

Perfect for embedded software developers eager to expand their understanding of Open-CMSIS-Packs.

Register now and reserve your spot: https://okt.to/BdKjSE

NXP and EmSA are inviting you to the one hour seminar “Accelerate Development of Robust Network Communications with CANopen and CANopen FD” on Tuesday April 21st 2020. This webinar is a hands-on session about customized CANopen (FD) development on NXP MCUs.

In the hands-on part, we take the CANopen (FD) device/slave example included with the NXP MCUXpresso SDK and use the free CANopen Architect Mini software utility to modify and configure the CANopen (FD) communication of the device. Code modifications are made using the MCUXpresso SDK to support the custom generated CANopen (FD) object dictionary entries. Click here to register for this webinar.

The webinar requires some basic CANopen (FD) and MCUXpresso knowledge. See our courses at www.em-sa.com/video to learn the basics about these technologies.

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

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.

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.

Could Ransomware Go Embedded?

For criminal hackers, ransomware has become increasingly popular. Ransomware locks a PC or encrypts its data and ask for a ransom to be paid to the hackers to unlock the PC or decrypt the data.

To which extent are embedded systems vulnerable to similar attacks? How realistic is it that firmware update mechanisms are used by hackers to install foreign code? Although loading malicious code to deeply embedded systems might seem far-fetched, some of the Snowden documents have shown that this already happened to the firmware in disk drives. Also, the well-documented Jeep Cherokee attack in 2015 that allowed a remote operator to almost entirely remote control the vehicle shook the industry. A wake-up call?

The Challenges

For hackers, the challenging part is that even though there has been a development to use more off-the-shelf hardware reference designs and software, most Embedded Systems platforms are still different from each other. Different microcontrollers require different code, so that ransomware has to be tailor-made for a specific microcontroller. The bootloader mechanisms in place are also different which means hackers need to find exploits for every one they are trying to attack.

A hacker’s task would be to write an exploit that manages to replace the entire original code and includes an own, password-protected, bootloader. With payment of the ransom, the hacker would share details on how to use his bootloader. There would of course always be the risk that this feature was not tested well enough by the hacker and a restore was not possible at all. It can be assumed that far more effort would have gone into generating the exploit and replacement code than the unlocking and restoring procedure.

Note that many microcontrollers have a built-in on-chip bootloader that cannot be erased or disabled, so if such a bootloader is usable in a device, a device with ransomware could be re-programmed on-site by the manufacturer or a technician. However, that might still be impractical or expensive if, for example, a very large number of devices were affected and/or the devices were at very remote locations.

A theoretical Example

To pick a specific application example, let’s have a look at an elevator / lift system: It consists of multiple microcontroller systems that are interconnected for example by CAN or CANopen and let us further assume they also feature a CAN/CANopen based bootloader mechanism.

A hacker installing ransomware replacing the existing bootloader with their own would need to

1. get access to the system (either physical by installing a sniffer or remotely through a hacked PC that is connected to the system)
2. know which microcontrollers are used
3. know how the CAN/CANopen bootloader mechanism works (with some CANopen profiles, some details about it are standardized)

This information might be stored on multiple PCs: with the manufacturers, distributors, technicians or operators of the system. If one or multiple of those get hacked, an attacker might have all this information readily available. Note that the risk of a rogue or disgruntled employee with inside knowledge is often underestimated. The information above will typically be accessible by many people.

With this information, a hacker would be able to generate and load his own ransomware loader replacing the original code in all devices, which would disable the system. Now buttons, displays and controls would all stop working and every affected device / microcontroller would require a restore of its original firmware. If the affected devices still have an on-chip bootloader and if it can be activated, then a technician could manually update all affected devices. For large elevator systems with 20 or more floors and multiple shafts this task alone could take days.

How likely is such an attack?

The sophistication level required for the attack described above is quite high. Not only does it require “traditional” hacker knowledge but also in-depth knowledge of embedded systems. At this time it might be unattractive to most hackers as there are possibly still many “easier” targets out there. However, with enough resources thrown at the task, a determined hacker group could achieve the tasks listed above.

What are possible counter measures?

The most basic pre-requisite for an attack as described here is the knowledge about the specific microcontroller and bootloader mechanism used. This information can be obtained by either monitoring/tracing the CAN/CANopen communication during the firmware update process or by access to a computer that has this information stored. Protecting these in the first place has the highest priority.

The designer has to make sure that the firmware update process is not easy to reengineer just by monitoring the CAN/CANopen communication of a firmware update procedure. Things that we can often learn just by monitoring a firmware reprogramming cycle:

1. How is the bootloader activated? Often the activation happens through a specific read/write sequence.
   Counter measure: Only allow authorized partners to activate the bootloader, best by using encryption such as CANcrypt or at least a challenge/response mechanism that is not repetitive.
2. What file format is used? “.hex” or binary versions of it can easily be recognized.
   Counter measure: Use encryption or authentication methods to prohibit that “any” code can be loaded by your own bootloader.
3. What CRC is used? Often a standard-CRC stored at end of the file or loadable memory.
   Counter measure: If file format doesn’t use encryption, at least encrypt the CRC or better use a cryptographic hash function instead of a plain CRC.

These counter measures are fall-back safeguards to protect the system if a higher security level has failed before. A hacker should not get bootloader access to a deeply embedded system in the first place. Ensure that all remote-access options to the bootloader level are well-secured.

With about 900 exhibitors the Embedded World reached a size where it is impossible to “see it all”. Yes, you can still walk by all booths in a day, but you might easily miss hidden highlights. It was quite obvious that IoT – the Internet of Things – is a current hype. To me this is quite astonishing as already some 10+ years ago we built an “Embedded Internet Demo” – at that time based on a Philips 8051 with a dial-up modem connected. The main difference between now and then is that now smart phones are widely spread and we are “always online” and now can access our embedded devices “at any time”. Among the visitors one could recognize a lot of skepticism for what exactly we really need the IoT, other then it being hip and cool to be able to control “everything” with our smart phone.

An unusual approach to get remote access to embedded applications was shown by Raisonance (http://www.iotize.com) – they have a miniature NFC or Bluetooth module that connect to the JTAG/SWD debug port of an application. So it can be added to any application with debug port, sometimes even without the need to re-compile the code, if you have the knowledge where in memory the variables are that you want to have remote access to. A great tool to get started with IoT without requiring a re-design of existing hardware.

At the CiA (CAN in Automation) booth a CAN FD demo integrated devices and tools from multiple vendors. CAN FD (Flexible Data) allows higher bit rates and longer contents (up to 64 bytes) of the data frame. Especially bootloader applications and other software update features benefit from the higher data throughput. For such applications it seems to be possible to increase the effective data throughout 8 fold easily, potentially even more.

We at ESAcademy further enhanced our portfolio of CANopen Diag products. There is now a second hardware, based on PEAK’s mini Display, that offers a subset of the diagnostic features provided at a price point of well below 1000 Euro. The CANopen Test Machine System part of the CANopen Diag now allows to create tests based on MS Visio graphs. The transitions in a state diagram can be used to transmit or receive a CAN/CANopen message or to influence/set/test/query variables or timers. More details and examples will be published shortly.

Today we released a new version of our Micro CANopen source code. Updates and changes made include requirements from the latest CANopen conformance test as well as updates to the CiA 447 specific examples. Besides two bug fixes, the changes are:

Device switch themselves automatically to pre-operational when they detect a loss of a heartbeat that they are consuming. In the past this was application code specific, but as the conformance test requires it, we moved this function into the stack. In CiA 447 this is only done for the loss of the gateway’s heartbeat. Reaction to other heartbeat losses remains application code specific.

For CiA 447 devices, the shut down sequence is now also initiated if a gateway is not present. As before, devices wait for the next wake-up message before they try to communicate again.

Micro CANopen customers with a current maintenance and support contract may download this latest version from our servers as described on the delivery note for each product.

MicroCANopen Plus and MicroCANopen Plus Add-in Manager have been updated. The highlights in the new version of the embedded CANopen stack are:

• More clarity and easier maintenance in user-configurable files by dividing call back functions into multiple files
• More flexibility by adding many more data call backs for SDO accesses
• Framework support to guard Object Dictionary entries with auto-generated minimum and maximum values from EDS/DCF file

Customers with ongoing maintenance agreement with us are entitled to a free upgrade. In this case, please download the new version from

CANopenStore.com/support.php

using the activation code(s). For those projects using auto-generated code, also update CANopen Architect EDS to the latest version.

The process to update embedded firmware libraries that become part of a bigger project can be complicated. For that reason, we have developed tools and to ease this on-time task.

Contact us if you are interested in obtaining or need assistance in performing the update.