Secure Firmware Updates (Part I)

When a machine, e.g. a printing machine, is connected to the Internet, this enables remote diagnostics and remote control. This in turn allows to react faster when a problem occurs, downtime can be reduced or even prevented completely thanks to predictive maintenance. A gateway is used to connect the machine to the Internet - and potentially misused by attackers to get access to the machine (visualized by the shark in the simple Internet of Things model shown below).

So security of the machine is clearly depending on how well security of the gateway is implemented, and therefore on the protocol stack of the gateway - e.g. see the Heartbleed vulnerability in the case of OpenSSL. There exist higher-quality implementations of TLS, but even in these products security holes are found from time to time, and thus they must be updated when fixes become available.

This means that a firmware update mechanism for such gateways - or for any other IoT devices on the Internet - is necessary. Of course, there are also other reasons why firmware updates are desirable: for distributing bug fixes or new functionality. The more powerful and complex IoT devices are, the more pronounced this need tends to be. Also, the time-to-market pressure of more agile and "lean" processes mean that features that are not currently critical can be deferred to later firmware updates - which is only practical if firmware updates can be easily distributed and installed "in the field" without having to physically send service technicians to the gateways.

Unfortunately, the possibility for in-field firmware updates first of all increases the attack surface drastically. A firmware update mechanism must therefore be carefully secured itself.

Security is a system quality - it cannot be achieved by only looking at individual system elements. The chain is only as strong as its weakest link. So we need to look at an overall threat model that shows the identified threats and also contains an estimate of the risks that they cause, and a systematic discussion of possible mitigations. For this process, e.g. Microsoft's Security Development Lifecycle (SDL) can be used.

Regarding firmware updates, we may have to meet security-related requirements like these:

1. Make sure that a firmware update reaches its target devices within a given time frame (availability).
2. Prevent firmware updates from being reverse engineered (confidentiality, e.g. protection of intellectual property).
3. Make sure that firmware updates have not been tampered with (integrity, e.g. protection against viruses).
4. Make sure that only firmware updates from a trusted source are installed (authenticity of source of firmware updates, e.g. protection against trojans).
5. Make sure that firmware updates are only installed on legitimate target devices (authenticity of destination of firmware updates, e.g. protection against cloning or overproduction).
6. Minimize damage if a firmware update from a trusted source contains vulnerabilities anyway (e.g. backdoors, introduced accidentally or maliciously).

For the discussion of firmware updates, we extend our simple IoT model with the channels that can be used to transport firmware updates:

We have added a developer (or more likely an entire development and deployment organization) to the model. In the simplest case, a developer may directly copy a firmware update via Internet to a gateway. However, for handling many gateways, or because of operational processes, updates are usually distributed indirectly, e.g. using a cloud service. Sometimes, updates should be possible even if there is currently no connection to the Internet. For example, a service technician could carry a USB stick with a firmware update.

Basically there are three kinds of system elements that can be attacked in this model: the channels through which the updates are distributed, the endpoints of the channels, and the ports that connect channels to endpoints. (Sensors and actuators may also be attacked, e.g. by covering a camera - however, this is not relevant regarding firmware updates.)

In the second part of this blog post, I'll discuss ways for addressing these threats.

Cuno Pfister, Oberon microsystems AG