RSS Feed

Embedded Systems Blog

Security column: Updates and Outlook 2018/2019

November 21st, 2018 No comments

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.

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

CANcrypt FD security for NXP LPC54618 now available

September 4th, 2018 No comments

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.

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.

 

CANcrypt Update: Better Security and CANopen FD support, shown at Embedded World 2018

February 20th, 2018 No comments

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.

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.

First Secure CANcrypt CAN FD Bootloader available

July 19th, 2017 No comments

Today, the Embedded Systems Academy announces the availability of its secure CANcrypt CAN FD bootloader for the NXP LPC54618 microcontroller. The binary version is available as free download and may be used without limitations. For programming, the FlashMagic software (www.flashmagictool.com) and a PEAK PCAN-USB FD interface (www.peak-system.com) is required.

The security system is based on two symmetric keys, separating the code protection (happening at the manufacturer) from the download process done by a system integrator or service technician. The code file is AES-GCM (128-bit key) protected, offering both encryption and authentication. The local CAN FD connection (between service host and bootloader) is CANcrypt protected (128-bit key, authentication and partial encryption).

On the host side, the update process is fully integrated into the existing FlashMagic software that handles Flash programming for all NXP LPC microcontroller families.

Secure Bootloader Components

The figure illustrates the components of the system. The bootloader and the initial two keys (code protection, connection) are programmed into the LPC54618 device in a trustworthy manufacturer environment.

For a code update, the manufacturer creates a secure update file based on the first, code protection key. The file is encrypted and can be passed to the service technician through an unsecured channel such as email or web download. FlashMagic includes a minimal CANcrypt configurator, allowing the technician to initiate the code update using the second, CANcrypt connection key.

The secure bootloader does not by default disable the on-chip bootloaders and debug access by SWD to ensure that the default implementation can not accidentally lock a device. However, if all of these recovery methods are disabled, either during production or through a programmed application, then the secure bootloader remains the only method for code updates. In this configuration, once the CANcrypt connection key is lost, no further updates will ever be possible.

In addition to this free binary loader, ESAcademy offers a commercial version including all sources. This version offers more configuration options, such as customizing the CAN-FD bit rates (default is 500kbps/2000kbps) and security methods.

The security experts at MathEmbedded are in the process of reviewing the project. Once completed, we will publish the results here.

Download link: LPC54618_secure_CANFD_bootloader_V100.zip

MD5: 28a896e17a9a57b938337095fbd35372
SHA256: eb6d22e9390e0d1a79f04a81f926bcd98d496dd65f03535298e1ebf050e4729c

Secure CANcrypt CAN FD Bootloader for NXP LPC546xx

June 15th, 2017 No comments

Together with NXP, the Embedded Systems Academy implements a secure CAN FD bootloader based on the CANcrypt security protocols. The bootloader will be available to users of the LPC546xx as free download. It is a “secondary bootloader”, meaning that it only provides security for the added bootloading channel, in this case the CAN FD interface. Someone with physical access to the LPC546xx will always be able to use the primary, on-chip bootloader to re-flash the device with any code.

The security system of the bootloader uses two security levels, each based on a symmetric key (default 128bit, up to 1024bit optional).

  1. On the CAN FD communication level, the CANcrypt protocol (www.cancrypt.eu) is used to ensure that only an authorized communication partner can activate the bootloader, erase the flash memory and send new code to the LPC546xx. The CANcrypt connection key used for this level is generated by the system builder or integrator that initially assembles the entire system.
  2. On the file transfer level, the file containing the new code to be loaded is encrypted using an encryption and authentication method based on a code protection key that gets programmed into the LPC546xx at the same time when the bootloader is installed (typically at manufacturer end-of-line assembly and test).
Secure bootloader security levels

Figure: Secure bootloader security levels

These two levels ensure a separation of the security features between manufacturer and system integrator/builder or service technician. Only an authorized technician will be able to connect his diagnostic device or software to the bootloader. But at this security level alone it will not be possible to generate authorized firmware, that requires an additional key only known to the manufacturer.

If you want to learn more about this bootloader, register now for the webinar (Thursday, June 29, 5:00 PM – 6:00 PM CEST) on the NXP website at: http://www.nxp.com/support/training-events/online-academy/lpc54000-series-online-training:LPC54000-Series-Online-Training

The version for free download is a binary only and will use a pre-selected cipher algorithms, fixed default configuration for parameters like CAN FD bit rates, CAN IDs and timings and timeouts used. The full source code is available from Embedded Systems Academy, giving users full control over all configurations and cipher algorithms used.

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.

Commercial CANcrypt Software Solution now available

April 19th, 2017 No comments

The Embedded Systems Academy now has the commercial version of CANcrypt available. It includes the hardcover, full-color version of the book and examples for both, the pairing and grouping modes. Demo implementations are provided for various NXP LPC processors (LPC23xx, LPC17xx and LPC11Cxx), the STM32F0xx as well as for the PEAK PCAN basic library supporting PEAK CAN interfaces.

The pairing demo shows how a 128bit key is securely transmitted from one device to another. The grouping demo shows secure communication between three devices. Here security is based on a session key that is continuously updated and gets saved when ungrouping. You can find more information including the software manual and the license information in our online store at www.esacademystore.eu/CANcrypt-Commercial/en.

Categories: CAN, Security Tags: , ,

News from iCC17 & EW17, CANcrypt released

March 20th, 2017 No comments

The last two weeks were very exciting for us: We held several papers at the International CAN Conference and Embedded World (both in Nuremberg, Germany), participated in the first CANopen FD demonstrator at both events – with the new NXP LPC54618 – and finally released our book “Implementing scalable CAN security with CANcrypt”.

The CANopen FD demonstrator at the CiA (CAN in Automation) booth showed one of the new features of CANopen FD: segmented broadcast of larger data blocks with “Universal Service Data Objects” (USDOs). This feature can be used to broadcast images, configuration tables or even firmware updates. Here, any participant could be commanded to broadcast an image to all other participants. Such use cases were almost unthinkable with classic CANopen communication.

At Embedded World, PHYTEC showed a Nano Dimension 3D printer for PCBs. Prototyping your printed circuit boards just became a lot easier and faster. The circuits are printed with a highly conductive ink. It looks like the machine can directly produce boards from Gerber files.

At the NXP booth, one of the demos featured the NXP LPC54618 microcontroller with two CAN FD interfaces. The “FD” (Flexible Data rate) allows the data portion of a CAN message to be transmitted at higher bit rates. So far, classical CAN was limited to 1 Mbps. With currently available transceivers the data rate can now be up to 5 Mbps. Also in CAN FD, the maximum payload for each message is 64 bytes compared to eight bytes in traditional CAN. The demo compared different firmware download speeds. Using CAN FD, updates can now be transferred multiple times faster than before.

The release of our book about CANcrypt (www.cancrypt.eu) stirred a lot of interest and we had many engaged discussions, also with some security experts. CANcrypt is a security framework and the security level actually used is configurable. As usually, there is a trade-off: the more security you require, the more resources both in CPU time as well as in memory space you need. For a configuration on the upper end of security, proven encryption methods like AES-128 can be used. It will be interesting to see if the lower-end lightweight “Speck” cipher reaches adequate security levels, too.

A first potential weak spot in one of the initial published configurations (user section, where user’s are setting up their own security configuration) was already discovered and is currently improved. The encryption of the secure heartbeat accidentally used only limited parts of the shared dynamic key, reducing the effective key to 32-bit. However, CANcrypt supports key sizes of up to 1024-bit. The next release will use a demo where a larger key is applied properly.

To learn about our bounty program, stay tuned by joining our mailing list or following us on twitter . Within the next few weeks we will start such a program to encourage others to search for possible flaws in the CANcrypt implementation.