Embedded Systems Academy

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.

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.