RSS Feed

Embedded Systems Blog

Cyber security workshop for CAN (FD) at CiA

April 16th, 2018 No comments

At the upcoming CiA cyber security workshop (Nuremberg, May 2nd) our engineers participate with two presentations. We inform participants about the most common attack vectors used on CAN (FD) systems and some of the basic protection mechanisms already available today. In a second part we will outline CANcrypt based mechanisms and how they can easily be used to implement a generic security layer. This layer can be used in between the CAN Data Link Layer and the higher protocol layers like J1939 or CANopen.

The cyber security workshop is free for CiA members. To register, visit the CiA web pages.

 

Active CAN/CANopen “shield” CANgineBerry

April 10th, 2018 No comments

The new CANgineBerry is an active CAN interface with a Cortex-M0 microcontroller and various firmware options. At launch, two options are available: One for a CANopen Controller / Manager and one for a configurable CANopen slave device.

The CANopen Controller scans the network for connected slave devices within less than 50 ms after power-up, sets up process data handling, starts the network and continues monitoring it. Once the host that CANgineBerry is connected to is up and running as well, it can immediately start using the CANopen network and access any device.

The second firmware option is implementing a CANopen slave device which is fully configurable with node ID and with an Object Dictionary that the user creates with the provided CANopen Architect software (evaluation version is sufficient for this use).

The CANgineBerry’s host can be a Raspberry Pi®, another embedded computing systems or even a PC. The communication to the host system uses a regular serial channel (TTL-UART), so no special driver is required as UART support is typically part of all operating systems. The communication between host and CANgineBerry and the API is designed to serve the application. For example, heartbeats are automatically monitored but the host is only informed about changes in the heartbeat status (like “activated” or “lost”) but not about every individual heartbeat message.

This architecture of CANgineBerry addresses the shortcomings of many “CAN shields” that are passive, have no own intelligence and require the host computer to handle all CAN communication message by message. In worst case, a CAN system can have more than ten thousand individual messages per second. Sometimes the real-time requirements are below 10 ms for some responses which is not realistically achievable with a Linux or Windows® based host and a passive approach.

Summary of firmware options currently available or under development:

  • CANopen self-configuring Controller / Manager
  • CANopen slave device (configurable via EDS, Electronic Data Sheet)
  • Lawicel CAN-RS232 protocol
  • CANcrypt (secure CAN communication) for the above versions
  • CiA 447 – automotive add-on electronics
  • J1939 gateway

For more information about the CANgineBerry, current firmware options and availability, visit www.CANgineBerry.com

CAN Security Expectations vs. Limitations

February 25th, 2018 No comments

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)

CANopen Magic now supports CANopen FD

December 11th, 2017 No comments

It was a lengthy process. Along with other experts we from Embedded Systems Academy participated in the CANopen FD definition group for more than 2 years now. Initially some only wanted a few changes. However as CAN FD is not backward compatible to CAN (classic CAN controllers produce error frames when they see a CAN FD message) the majority saw the chance to “dump complete backward compatibility” and add new and advanced features. The previous SDO communication (request-response scheme between one master and multiple devices) was replaced with the USDO communication – the Universal Service Data Object.

A first version of the definition of CANopen FD (CiA 1301) was released by the CiA in October this year. It is available from the CiA on request (www.can-cia.org/services/publications/). Some of the new features include:

  • TPDOs can now have up to 64 bytes of data (previous 8)
  • Full USDO mesh definition – every node can send client requests to every other node
  • USDO communication may be a broadcast to all nodes

The USDO service allows any device to send service requests to any other device, without the need for a master or manager to be involved. This greatly improves plug-and-play support and self-configuring systems, as now each device independently can analyse its surroundings: which devices are on this network and what kind of communication objects do they have available.

We at Embedded Systems Academy are now adding CANopen FD support to all our CANopen products. The first line of products supporting CANopen FD is our CANopen Magic software for the analysis and test of networks. As of the latest release (V9.0) all CANopen Magic products support both CANopen and CANopen FD. For CANopen FD an appropriate CAN FD interface must be connected. All of our current tests have been made with the PCAN-USB FD and PCAN-USB Pro FD interfaces from PEAK System.

We are currently in the process of contacting all current CANopen Magic users to inform them about their upgrade options. If you are using CANopen Magic and have not yet received an email from us about your upgrade options, please contact us.

CAN and CANopen FD at ‘sps ipc drives 2017’

November 6th, 2017 No comments

Visit us in Nuremberg for the 28th international exhibition for Electric Automation, Systems and Components, the “sps ipc drives 2017”. The show is open from November 28th to 30th, 2017. Our software and solutions are shown on two displays at the NXP booth and the CiA (CAN in Automation) booth.

Our display at the NXP booth (Hall 10.1, Booth 325) focuses on CAN FD and security. The new features of CAN FD (bigger message frames, higher bit rate) are used to implement a more efficient and secure bootloader based on CANcrypt and AES based authentication and encryption. Join us for an informal lunch & learn session about CAN FD on Tuesday or Wednesday starting at noon (for about 45min) in the NXP on-site meeting room. Seats are limited, please register here to join.

Our display at the CiA booth (Hall 2, Booth 300) focuses on CANopen FD. A multi vendor demo setup shows one of the many new features available with CANopen FD: segmented broadcast. This transfer mode supports sharing data blocks (for example tables with data of drive acceleration ramps) instantly among multiple participants. In the demo, the data exchange is visualized using graphics, which are shared among multiple nodes.

Contact us, if you still need tickets for the event or if you would like to set an appointment to discuss your CAN FD / CANopen FD / CAN security requirements.

International CAN Conference (iCC) 2017 Videos Released

October 5th, 2017 No comments

The CiA (CAN in Automation) user’s group released the presentation videos of the iCC 2017. Besides the keynote by Holger Zeltwanger there are three more presentations that we would like to highlight here in our blog:

Andrew Ayre and Olaf Pfeiffer (both ESAcademy): Automated trace analysis for testing of CANopen devices

This paper presents a summary of the debug information extractable from CANopen trace recordings. The functionality described in this paper are implemented in our Logxaminer software.

 

Olaf Pfeiffer (ESAcademy): Scalable security for CAN, CANopen, and other CAN protocols

This paper describes the main functionality of the CANcrypt security framework described in our book “Implementing Scalable CAN Security with CANcrypt”.

 

Bernhard Floeth (Opel) and Olaf Pfeiffer (ESAcademy): Using an enhanced condensed device configuration file format for CANopen boot-loading and/or device testing

This paper presents the enhanced CDCF player integrated in our free CANopen File Player and CANopen Diag projects. It supports spreadsheet based (.csv) Object Dictionary access with active flow control.

 

For a complete list of all available videos, go to: www.can-cia.org/services/conferences/icc

Could Ransomware Go Embedded?

May 23rd, 2017 No comments

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.

Upcoming conferences and presentations

January 16th, 2017 No comments

This spring, the tutors of ESAcademy present five CAN and CANopen related papers at the 16th international CAN Conference and the Embedded World Conference 2017.

16th iCC, 7th to 8th March 2017 in Nuremberg
www.can-cia.org/services/conferences/icc/icc-2017/

Bernhard Floeth (Opel) and Olaf Pfeiffer (ESAcademy):
Using an enhanced condensed device configuration file format for CANopen boot-loading and/or device testing
This paper presents the enhanced CDCF player integrated in our free CANopen File Player and CANopen Diag projects. It supports spreadsheet based (.csv) Object Dictionary access with active flow control. (Tuesday, March 07, 2017, Session II)

Andrew Ayre (ESAcademy):
Automated trace analysis for testing of CANopen devices
This paper presents a summary of the debug information extractable from CANopen trace recordings. The functionality described in this paper are implemented in our Logxaminer software. (Wednesday, March 08, 2017, Session VII)

Olaf Pfeiffer (ESAcademy) and Christian Keydel (ESAcademy):
Scalable security for CAN, CANopen, and other CAN protocols
This paper describes the main functionality of the CANcrypt security framework described in our book “Implementing Scalable
CAN Security with CANcrypt”. (Wednesday, March 08, 2017, Session VIII)

Meet our tutors at our tabletop display table at the conference.

Embedded World Conference 2017, 14th to 16th March 2017, Nuremberg
www.embedded-world.eu/program.html

Christian Keydel (ESAcademy):
Secure CANopen (FD) Bootloading
This paper shows how to adapt the security mechanisms introduced by CANcrypt to CANopen, CAN (FD) and bootloading. (THURSDAY, MARCH 16, 2017, Session 25/I)

Olaf Pfeiffer (ESAcademy):
CiA 447, the CANopen Standard for After-Market Automotive Applications
This paper summarizes the key features of the CANopen application profile CiA 447. These include wake-up and sleep mechanisms as well as plug-and play functionality. (THURSDAY, MARCH 16, 2017, Session 25/II)

Meet our tutors at the PEAK System booth (Hall 1, Booth 1-483)

We look forward to meeting you

Categories: CAN, CANopen, Security Tags: , , ,

CANopen Architect Professional Released

December 6th, 2016 No comments

We have released a new version of CANopen Architect, aimed at advanced users. The new Professional version builds upon the features found in the Standard version adding new functionality for quicker data entry and ideal for developers of CANopen products.

The Professional version can export Electronic Data Sheets as Word documents, allowing automatic generation of product manuals and internal documentation. Enter a descriptive text for each entry, choose the export options and save. The output can be used as a standalone manual or can be copied and pasted into an existing manual. Options are provided for using a template document and styling headings and tables.

A user-friendly PDO configuration window has been added. The new window allows quick and easy PDO creating and editing at a higher level than Object Dictionary entries. Mappings can be changed and reviewed without worrying about needing to keep the various underlying Object Dictionary entries consistent. Users of our CANopen Magic configuration and analysis tool will find the new window immediately familiar.

The new version provides an integrated command line interface allowing power users to quickly create and manipulate large amounts of PDOs. Commands can be placed into files and executed in a single step. Multiple commands for a variety of situations are provided and will be added to from time to time.

For details of the new features and to try the evaluation version please visit the CANopen Architect website.

Existing users of CANopen Magic Standard are able to upgrade. Please contact us for pricing.

Book announcement: Implementing Scalable CAN Security with CANcrypt

February 22nd, 2016 1 comment

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