Don’t leave security to chance

Introduction

The online, always-on world of today is a delight for adversaries. It gives them a global playground of devices to try to compromise. The security of an embedded device is paramount to stop hackers from gaining control of it.  Even worse, an adversary may mount a more damaging attack on the device’s connected systems.

Remote attacks, however, are only one vector that an adversary has in their armoury. Local attacks on the physical hardware device are another way of obtaining secret information. These attacks include access to system authentication passwords and even the intellectual property of the application code itself.

This article reviews the basic concepts for provisioning a robust and reliable embedded security regime in an embedded microcontroller. We examine security principles and provide a deeper understanding of the attack surfaces and vectors adversaries use.

Figure 1: In an IoT deployment, a single compromised or unsecured device opens up the whole system to an adversary. (Source: STMicroelectronics)

Provisioning security must never be underestimated, no matter how much complexity it adds to an embedded system. Also, it is not just about securing cryptographic keys and embedded firmware, but also personally identifiable data.

Should an adversary gain access to a device’s firmware, they can potentially reverse engineer the code. With an insight into how the code works, an adversary can uncover further vulnerabilities and has the opportunity to inject malicious code. Access to a single unsecured connected IoT device can compromise a whole IoT deployment - see Figure 1.

What needs protecting

Before we start investigating security techniques, let’s review and classify what we need to protect. Hackers can target three different aspects of an IoT device. A target is an IoT device that needs to be protected. An asset is what the target contains that requires protection. Figure 2 identifies the assets that need securing and the associated risks within each target should it become compromised. When it comes to implementing embedded security techniques, this classification method helps select the correct security approach to use.

Figure 2: The classification of targets, assets, and associated risks help determine which security methods to implement. (Source: STMicroelectronics)

Types of attack

The attacks on an IoT device can come from various sources, broadly categorised into either software or hardware-based. Attacks on the software running on a device can occur either locally or via a network connection. Hardware attack types are further sub-divided into those that are non-invasive or invasive.

A non-invasive attack is performed locally and only in some cases requires an electrical connection to the main PCB of the IoT device. However, an invasive hardware attack involves physical and electrical access to the device’s microcontroller. Mounting an invasive attack is typically the most expensive route for an adversary and involves specialist knowledge. Figure 3 illustrates the three attack types highlighted above, together with a review of the techniques and reasons why an adversary would use them.

Figure 3: Attack types and costs. (Source: STMicroelectronics)

Software attacks tend to be the most common and involve exploiting firmware bugs, known protocol weaknesses, through the device’s communication channels. The costs associated with conducting such attacks may also be relatively low and easily achieved since executed remotely. Knowledge of device vulnerabilities may also be shared and communicated within the hacker community.

Security in practice

From a device manufacturer perspective, an understanding of device security drivers helps ascertain the security functions needed—the three scenarios outlined below highlight some of the security functions required for each. The following section explains numerous security functions and their implementation.

Scenario one

Consider a company selling firmware where the primary source of revenue comes from royalty payments. The firmware produced by the company is a precious intellectual property (IP) asset, one that needs protection. Customers use the firmware alongside their application code. From the company perspective, the firmware needs to be securely isolated from the customer’s code.

The company issues firmware updates from time to time, so there is a requirement for secure installation and update of firmware. In this scenario, the security functions required include isolation, software IP protection, and Secure firmware install and update routines.

Scenario two

The IndustrialAdvantage company sells expensive production control equipment and wishes to offer a firmware update service to its customers. There is a requirement to maintain that only IndustrialAdvantage firmware runs on the supplied equipment.

The firmware update process needs to be diligently handled, with authenticity checks carried out throughout the process. Ensuring that only IndustrialAdvantage firmware is running on equipment can be fulfilled by a secure boot function. A secure install and update function takes care of the integrity and authenticity checks. 

Scenario three

The devices manufactured by Consumer Tech collects user data as part of a more extensive system. The company is mindful of maintaining compliance with consumer data regulations, such as GDPR, at all times. Consumer Tech also desires to ensure that their device behaviour is robust and that only Consumer Tech firmware runs on the device.

During device communication with the host system, there is a possibility of exposing user data, the use of cryptographic techniques, device identification, and authentication can prevent exposure of personally identifiable information. Platform integrity is maintained using a secure boot function.

Provisioning a security framework

For the embedded developer, access to a comprehensive and robust set of security functions for a device’s microcontroller platform is paramount. An example is the ‘STM32Trust’ ecosystem for the STM32 series of microcontrollers from STMicroelectronics - see Figure 4.

Figure 4: STM32Trust security function ecosystem. (Source: STMicroelectronics)

The security functions of STM32Trust used on the STM32L4, and STML5 series of microcontrollers, certified to Arm PSA Level 2, and SESIP Level 3. The security functions are either embedded in the microcontroller silicon or available as firmware and are device-dependent.

For the rest of this article, we will focus on two essential security functions provided by STM32Trust and highlighted in the earlier scenarios; secure boot (SB) and Secure install/update (SBSFU).

Secure boot

The basic principle behind a secure boot is that on device reset, secure boot code executes and verifies that the application firmware is authentic before deciding to launch it or not. Secure boot relies on two parameters.

Firstly, the secure boot code is the only code executed at reset. Secondly, the boot code is immutable - meaning it is unable to be modified in any way. The boot code address is unique, preventing access to an alternative firmware address at reset. Together, these two aspects create a root of trust for the device. See Figure 5.

Figure 5: The basic principle of a secure boot function. (Source: STMicroelectronics)

Integrity and authenticity checks of the application firmware, compared to a signature, are made. The integrity check compares a hash, sometimes termed a digest, generated from the application code against a supplied reference. The authenticity checked against a signature computed from the generated hash value and a private key. The signature then verified using an associated public key.

The reference hash value and the signature value always need to be provided with the firmware. These are typically stored in a container, either called metadata or a header - see Figure 6. The metadata does not need encryption because of the method of generation. Should an attempt to use malicious firmware be made, there is no way to make the firmware hash match the reference. Figure 6 illustrates the metadata signature’s construction, using the hashed firmware digest and the private key.

Figure 6: Generating the metadata signature. (Source: STMicroelectronics)

In Figure 7, the secure boot code uses the metadata signature to confirm the application firmware’s integrity and authenticity status. If the signature verification process verifies valid firmware, the boot process advances to load the application code. Discrepancies with the application firmware or the signature result in the boot process failing.

Figure 7: Validating the application firmware using the metadata signature before loading the application. (Source: STMicroelectronics)

Secure firmware update

• The identified critical steps in a firmware update process are:
• creation of the application firmware update,
• generation of the associate metadata,
• transmitting it to the target device,
• the metadata is used by the secure boot function to check the application firmware integrity and authenticity,
• if the checks pass, the Secure Boot process installs the new firmware.

The new metadata signature is created in the same way as the technique explained for secure boot. For many remote connected IoT/IIoT devices, the simplest transfer method is via an over-the-air (OTA) update. Devices without an internet connection need a local connection; examples include using a UART, SPI, USB, or microSD card.

The new application firmware, written to flash memory on the target device using a loader program. The loader is typically included in either the secure boot code or within the application firmware. The new firmware needs to be stored locally while the current firmware is still running.

Figure 8 illustrates the process of a remote firmware update. There is a requirement for two memory ‘slots’ for both the current firmware and the updated version.

Figure 8: Remote firmware update example. (Source: STMicroelectronics)

The final stage of the update process involves checking the new application firmware. If the metadata check passes, the exchange of the latest and existing application firmware takes place. The update is now complete.

Conclusion

Embedded device security is no longer optional. Every device needs protection against malicious attacks and potential vulnerabilities. Device security starts at boot, so incorporating security functions such as secure boot and secure firmware install & update is vital.

STM32Trust provides all the security functions an embedded developer needs to safeguard their device and comply with legislation.