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.

Together with the Institute of Reliable Embedded Systems and Communication Electronics (ivESK, Prof. Sikora of Offenburg University), the Embedded Systems Academy has been awarded a research grant for a collaborative project focusing on embedded network security. The project is dedicated to developing a security framework for small-packet networks, with a specific emphasis on CAN and CANopen systems.

The initiative, internally referred to as “Inter-Layer Multi-Participant Security for Small-Packet Networks,” can be integrated within existing network layer protocols and offers multi-party security. It is adaptable to various small-packet network protocols used in embedded systems. Beyond CAN, CAN FD, CANopen and CANopen FD, it can also be used for I2C or RS-485 based systems. The project aims to combine established security mechanisms in a novel way and adapt them suitable for deeply embedded systems, devices and networks, where resources, such as memory, computing power, data rates and frame length are very much constraint.

The project’s goal is to ensure that the results are openly available and can be reused by the Special Interest Group “Safety/Security” within CiA (CAN in Automation).

We plan to regularly publish updates on our project’s progress. A first presentation is scheduled for the embedded world Conference in Nuremberg: On April 9th, 2024, we will present the paper “Collaborative Design of Security Measures for CAN and CANopen Systems” in the connectivity track, session 2.2 on CAN. If you are interested in contributing to the specification process or in beta-testing early implementations, please feel free to contact us (contact form on this web page or mail to info@esacademy.de).

This Project is supported by the Federal Ministry for Economic Affairs and Climate Action (BMWK) on the basis of a decision by the German Bundestag.

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.

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.

A summary of the technical features used by CANcrypt

By Olaf Pfeiffer, Embedded Systems Academy GmbH, 26th of February 2016

At the Embedded World 2016 in Nuremberg, Embedded Systems Academy GmbH announced their book “Implementing Scalable CAN Security with CANcrypt”. The corresponding CANcrypt demo code will be published using an open license. At the Embedded World we have seen a lot of interest in the technical details. For those who do not want to wait until the publication of the book this article summarizes the key technical features of CANcrypt (also see our CANcrypt.eu web page for more information).

Core Functionality of CANcrypt

CANcrypt provides the following services:

• Pairing: dynamic generation of a random key that is only known by the paired devices; optionally, one device can enforce a preset key to the other.
  • generate and exchange keys
  • optional storing of keys in non-volatile memory for permanent pairing
  • support of a key hierarchy when multiple keys are stored
  • maintain dynamically changing key (pseudo one-time pad)
  • dynamic key updated using shared random bit
• Grouping: multiple devices share a common dynamic key
  • originally assigned through pairing
  • maintain dynamically changing key (pseudo one-time pad)
  • dynamic key cyclically updated by all grouped devices
• Safety communication: any secure communication uses a preamble message
  • messages received are only accepted and passed on to application if together with the preamble the authentication and decryption is verified successfully
  • preamble identifies message CAN ID, security features used, has a counter and a signature
  • secure messages must be received within 10ms after the preamble to be valid

CAN message IDs required:

• one CAN ID for each participating device
• used for preamble and control messages
• a CAN ID pair used for the random bit generation cycle

Cipher methods used

CANcrypt keys are symmetrical and dynamic, they are continuously updated. From the dynamic key and a message counter a pseudo one-time pad is generated that is used for the simple, customizable encryption.

If the secure pairing is only active for two nodes, a random bit generation cycle is used continuously in the background to introduce new bits to the dynamic key. If multiple nodes are paired, then the dynamic key update information is sent via an encrypted message.

The system pairing process is started using a CANcrypt configurator device. This can be done by a system builder or integrator once the CAN system is installed. It must happen in a secure environment. The keys generated at that time are stored locally in the devices connected – there is no need to keep any further copy of this key outside the system, minimizing the effort placed on key management. The keys cannot be duplicated. If a new device is added (or one exchanged), all keys need to be erased and newly generated.

As stored keys in each device make up a hierarchy, we can guarantee that erasing and regenerating keys can only happen when the configurator used is logged-in to the system based on a key high enough in the hierarchy to allow erasing and re-paring.

Operating principle for random bit generation

Bit generation cycle

Solely by monitoring CAN messages, one cannot identify the device that sent any individual message, because at that level, any device can transmit any message. As an example, let us allow two devices (named initiator and responder) to transmit messages with the CAN IDs 0010h and 0011h (and data length zero) within a “bit select time window”. Each node shall then randomly choose and send one of the two messages at a random time within the time window.

At the end of the bit select time window, a trace recording will show one of the following scenarios:

1. One or two messages of CAN ID 0010h
2. One each of CAN ID 0010h and 0011h
3. One or two messages of CAN ID 0011h

Let us have a closer look at case 2 – one each. If these are transmitted randomly within the bit response time window, then an observer has no way to identify which device sent which message. However, the devices themselves know it and use this information to derive a bit from it.

Unfortunately we cannot use case 1 and 3, so if those happen, both nodes need to recognize it and re-try, using another next bit select time window.

Note 1: If one device wants to enforce a specific bit to the other, it may generate a “flip bit” message at the end of the cycle to indicate to the other device that this bit needs to be flipped.

Note 2: A variation of this scheme is to not use a random delay, but instead ensure that both devices transmit their message immediately after the trigger message. Then both messages arbitrate the bus at the same time and in a trace recording we will always see 0010h followed by 0011h.

Potential attacks: As usual, a denial-of-service kind of attack is always possible. By injecting messages an attacker can break the cycle, the devices would not be able to exchange a key in the first place. If an attacker has full physical access (oscilloscope, transceiver), he can determine which node sent which message. However, there is still some effort required to recognize which bits were actually generated (as participating devices can change interpretation). Last but not least anything “random” is always an attack vector. The participating devices need a reasonably good random number generator.

Nuremberg, 22nd of February 2016: Embedded Systems Academy announces their new book “Implementing Scalable CAN Security with CANcrypt”. You can meet the authors at the Embedded World 2016 from February 23rd to 25th in hall 1, booth 620 – the booth of our partner PEAK-System.

The book covers authentication and encryption for CANopen and other Controller Area Network protocols and will be published in Q2/2016. The introduced CANcrypt system by ESAcademy adds multiple levels of security to CAN. CANcrypt supports the grouping of multiple devices and the encrypted and authenticated communication between them. The CANcrypt security layer sits between CAN driver and higher layers and is therefore independent of higher-layer protocols or applications used.

The required system resources are minimal compared to traditional cryptography methods and can be scaled to the application’s security requirements. A key hierarchy enables implementing of smart, simplified key management that supports manufacturers, system builders/integrators and owners.

Demo and example code will be published using the BSD license.
For more information see www.cancrypt.net

It is a busy start into 2016 with several new products and the Embedded World 2016 coming up next week.

New product – CANopen Logxaminer
Last year, we spent a lot of time helping clients to evaluate long CAN trace recordings and searching for misbehaviour of CANopen devices as well as manually generating statistics about such behaviour. In order to simplify such trace evaluations we wrote a dedicated utility that evaluates CANopen trace recordings. It supports common file formats used by recording tools from PEAK, Vector and ESAcademy.

For more information about the CANopen Logxaminer, follow the link.

New book about CAN security
Within Q2/2016 we will publish a new book, this time about CAN security. Recent publicized hacks show that CAN/CANopen are quite vulnerable, once an intruder/attacker has access to the network. Our new book introduces a scalable method that addresses both authentication and encryption, is independent of the protocol used and free sample code will be provided. A more detailed announcement will be published in our blog at www.esacademy.com/blog next week.

New 2016 price list
Our new 2016 price list is now valid, for current prices visit our CANopen online stores in Europe or USA. Prices have been lowered for the low-level entry version of our CANopen Magic tool as well as for the CANopen Magic high-end version including DLL access for custom test tool developments.

Next week’s Embedded World 2016
This years show in Nuremberg from February 23rd to 25th has almost 1000 exhibitors. For a complete list see
www.embedded-world.de/en/ausstellerprodukte/exhibitorlist

You can meet Chris or me (Olaf) from ESAcademy at the PEAK system booth. Hall 1, booth 620.

If you can not make it to the show and are still interested in selected news and updates, follow Olaf at twitter.com/ESA_Olaf or re-visit our blog after the show for a summary of impressions.

Looking forward to seeing some of you in Nuremberg

Olaf Pfeiffer