In-field firmware updates are an increasingly popular feature in microcontroller-based (MCU-based) applications. These updates enable new firmware images to be downloaded onto a device’s memory, providing an effective way for product manufacturers to offer services and support to products that are already deployed in the field. The Internet of Things (IoT) era is driving increased connectivity in the embedded world, making this one of the most crucial features for today’s connected products, so long as they are secure.

IoT developers often consider faster time-to-market and lower product maintenance costs when deploying firmware update mechanisms, as the capability allows them to stage feature roll-outs, enable/disable features or functionality on devices in the field, fix firmware bugs after a product has been released, reduce the need for expensive technical support, and enable better overall end user experiences. However, if proper security measures are not in place, this feature may be misused and the consequences of a successful exploitation can be disastrous, ranging from intellectual property (IP) theft and product cloning all the way to unauthorized control of the deployed system. For example, a successful exploitation of firmware update mechanisms that do not support verifying a new firmware image’s authenticity in a hospital drug pump can lead to a hacker tampering with the dosages of drugs delivered to patients.

Firmware updates and their vulnerabilities

Figure 1 shows a typical firmware update process. The steps include:

1. The product manufacturer creates and loads an initial firmware image into the device in a trusted environment.
2. The product is deployed with the initial firmware into the field.
3. When a firmware update is required, the product manufacturer creates a new firmware image.
4. The manufacturer sends the new firmware image to the end user/technician or to the product directly through an untrusted communication channel.
5. The new firmware is loaded onto the device in the field.

[Figure 1 | Shown here is a typical firmware update process.]

In Figure 1 potential security threats are apparent during the “transport” phase when new firmware is transferred via an untrusted communication channel, or during the “firmware loading” phase when the new firmware is downloaded onto the device in the field.

The new firmware image being downloaded to the device corresponds to the IP of the product manufacturer and the target asset. Threats to this asset include:

1. Reverse engineering of the firmware binary image into assembly or a higher level engineering language to analyze its functionality and contents.
2. Product cloning where a firmware image from the product manufacturer is loaded onto a device that is not authorized.
3. Alteration of the firmware distributed by the product manufacturer.

1. Loading an unauthorized firmware image onto the device, which may correspond to an older firmware version from the product manufacturer with known bugs or code created by an unauthorized party, or firmware not intended for the specific device (firmware downgrading).
2. Interrupting the firmware update process such that the firmware is only partially updated, resulting in a device being unavailable for service.

It is evident that the aforementioned threats can have disastrous consequences for the product manufacturer, service provider, and end user, thus indicating an intense need for embedded designers to strongly consider measures that increase the overall security of the firmware update mechanism.

Secure firmware update considerations for design engineers

Figure 2 shows an example representation of network-connected systems. In this case, the new firmware image is transferred either from the product manufacturer (e.g., a new feature roll-out or firmware bug fix) or the service provider (e.g., to enable/disable features or services in a product) to the end nodes over local or wide area networks (LANs/WANs), and may involve authentication from end user applications (e.g., via mobile devices and web applications) to perform the firmware update.

[Figure 2 | A secure firmware update includes security measures dictated by the interface protocols used for network communications, as well as application-level security that ensures firmware images are secured before data enters the network.]

Embedded systems engineers designing firmware update capabilities for IoT systems need to not only understand the assets that need to be protected and the potential threats, but also the capabilities and limitations of their system, especially as they pertain to cost, performance, or power consumption in constrained systems. As a starting point, an effective security solution that incorporates the right combination of cryptographic algorithms and protocol-level measures must be considered.

Cryptographic algorithms provide a means of protecting the privacy of content while ensuring its authenticity and integrity. Not all cryptographic algorithms are the same, but they are based on four cryptographic primitives that handle one or more components of the confidentiality, integrity, and authenticity (CIA) triad. These primitives are:

Encryption and decryption: Encryption is the process by which data (plaintext) is transformed into something random and meaningless (ciphertext), while decryption performs the opposite job. These primitives provide both confidentiality and authenticity, and are used to prevent the reverse engineering of firmware.

One-way functions: Functions such as hash are mathematical algorithms that are easy to calculate in one direction but difficult in the other. They are used to obtain a digital “fingerprint” that ensures the integrity of firmware before it is transported into the field.

Digital signatures: Used to detect if a message was altered after it was signed, thus providing not only integrity but also authentication. These make use of public-key cryptography to generate a signature that can only be properly decrypted using the manufacturer’s public key.

Message authentication code (MAC): Similar to a digital signature except that it uses symmetric keys to encrypt and decrypt a hash generated by the manufacturer. If the hash value decrypted by the receiver matches the hash value calculated for the message, then the message is valid. In this way, MACs provide both authenticity and integrity.

Some factors that influence the selection of cryptographic algorithms include performance requirements, the security needs of the system, memory footprint, energy consumption, and reliability and acceptance of the algorithm by the security community (such as organizations like the National Institute of Standards and Technology (NIST)).

In addition to cryptographic algorithms, protocol-level measures against threats such as firmware downgrading should be considered. As mentioned previously, firmware downgrading is an attack in which an older defective firmware image (encrypted or not) is re-sent to a device in order to revert it to a vulnerable state. A version check of both the firmware and keys can ensure that only new versions are programmed during an update.

An attacker can also interrupt a firmware update process using several methods (power loss, physical connection failure, bits flipped during transmission, etc.). This can lead to a device executing an incomplete or invalid firmware image, rendering it useless or in a compromised state. In order to address this scenario, firmware update mechanisms need to ensure that an incomplete or corrupted image is not executed, and if necessary, should revert the system to a valid, previously used image.

Cryptographic bootloaders for connected embedded systems

Firmware updates are typically handled by the device bootloader. A bootloader is a piece of code that resides on device memory and has the ability to reprogram the application memory space. However, finding or creating an embedded bootloader with the security required for network-connected systems can be challenging. For example, a system may need the ability to update cryptographic keys, so cryptographic functions and a bootloader protocol should support upgrading keys and increased network security during the firmware update process. The bootloader protocol should also accommodate verifying firmware update versions and packet tracking to check if all packets of a specific firmware update image were received.

As discussed, the selection of a cryptographic algorithm is critical because it not only sets the level of security of the system, but it also impacts its performance, memory footprint, and power consumption. With this in mind, AES-CCM represents an optimal solution for embedded bootloaders. AES-CCM is a cryptographic bootloader (Crypto-Bootloader) built on two cryptographic primitives: AES Counter Mode (AES-CTR) for encryption and cipher block chaining message authentication code (CBC-MAC) for integrity and authenticity verification. Due to the low overhead provided by AES-CCM, it provides a perfect balance between increased security and low memory footprint, high throughput, and efficient power consumption (Figure 3).

[Figure 3 | The AES-CCM algorithm is used to encrypt firmware data such as the firmware version number, packet number, and total number of packets. This information is fed into the algorithm along with a symmetric data encryption key to encrypt the data and generate an encrypted MAC tag, which represent part of Texas Instruments’ Crypto-Bootloader core command.]

The selection of an MCU implementing the bootloader should not be overlooked, either. Designers should consider MCUs with features like hardware encryption engines, a memory protection unit (MPU), low-power peripherals, and memory technologies that allow fast read/write cycles for increased throughput. The MSP430FR5969 MCU from Texas Instruments is an example of such an MCU that integrates an AES-256 co-processor to accelerate encryption algorithms, MPU and MPU-IP encapsulation (MPU-IPE) modules to enable increased protection and encapsulation of memory regions, as well as up to 64 KB of FRAM memory for high performance and ultra-low power consumption. The Crypto-Bootloader solution implemented on MSP430FR5969 devices encapsulates most of the security features and considerations outlined here (Figure 4).

[Figure 4 | MSP430FR5969 MCUs integrate a Crypto-Bootloader, as well as MPU/MPU-IPE modules and an AES-256 security co-processor.]

Securing firmware for the Internet of Things

In summary, increasingly network embedded products are creating the potential for advanced security threats, making in-field firmware updates more vulnerable to remote attacks and exploitations. Therefore, it is important for embedded designers to consider securing their firmware update mechanisms through solutions that provide the right level of security while balancing the cost, power, and performance constraints of IoT products.

Bhargavi Nisarga is a Systems Engineer at Texas Instruments.

Luis Reynoso is a Systems Applications Engineer at Texas Instruments.

Texas Instruments

www.ti.com

@TXInstruments

LinkedIn: www.linkedin.com/company/1397

Facebook: www.facebook.com/texasinstruments

Google+: plus.google.com/u/0/+TexasInstruments