Is secure boot on the main application processor enough?

TL;DR

• Secure boot ensures only authentic firmware can run on a device and should form part of a layered defence strategy.
• Sub-systems often lack secure boot capabilities, limiting protection for non-critical processors.
• Focus on secure boot for the main processor; it can provide adequate security in many cases.
• Use safety case methodologies to justify exceptions for lower-risk processors.

Is secure boot enough on its own?

The basics

Connected embedded devices often contain many processors. Alongside the main application processor it is common to find other sub-systems:

• A secondary microcontroller providing lower level safety or gateway functionality.
• Communications processors in peripherals such as Wi-Fi modules, BLE modules, and cellular modems.
• Lightweight or application specific processors, such as those in USB peripherals, SSDs etc.

All of three of these sub-systems can have programmable firmware, and this is where secure boot steps in. It’s a mechanism that checks the authenticity of the firmware running on a processor each time it boots.

Firmware signing checks the authenticity of firmware updates as they are applied. Secure boot and firmware signing go hand-in-hand to prevent malicious software running on your devices. A weakness or vulnerability in one of these two mechanisms should not result in complete compromise of the device.

How does secure boot and firmware signing work?

Public-key cryptography is used to digitally sign the firmware that runs on the device. A public key, stored in a read-only form on the device, is used to check that signature each time the device boots. Without access to the private key, it should not be possible to sign a firmware.

Crucially, the processor must have support for secure boot for it to be used. There has to be somewhere to store the public key, and an immutable boot loader must validate the firmware. This is commonly termed a “root of trust”.

In reality, it’s more complex than that – often involving multiple stages of validation, with each type of processor having a slightly different implementation.

Firmware signing also uses public key cryptography to validate that an update is genuine. This is performed during the firmware update process.

Are there any weaknesses?

Some argue that firmware signing is ineffective against physical attacks against a device. With direct access to flash memory, an attacker can replace the firmware with one of their own, bypassing the checks carried out during a firmware update. This is where secure boot should step in.

Whilst secure boot does protect against this direct replacement of firmware in flash memory, it is not effective against everything. A dedicated attacker can replace the processor with one of their own that does not perform secure boot.

From the perspective of remote attacks, if there is an issue in the firmware signing, hopefully secure boot will provide defence-in-depth.

Ideally, each individual processor in a device would be able to perform secure boot, but often this is not the case. Some processors do not support secure boot. It’s common to find that smaller microcontrollers lack secure boot, and that third parties have not implemented it for modules they sell.

The great unknown

To further complicate things, hardware modules containing various processors are often an unknown quantity. There’s no documentation or visibility of the internals. It’s sometimes not even known how many processors are in a module.

Often, the main application processor orchestrates firmware updates for other sub-systems in the device. This includes:

• Downloading updates over a secure channel
• Storing firmware updates locally
• Validating the authenticity of updates using firmware signing
• Pushing the update out to various sub-systems

If the main application processor performs secure boot and checks the authenticity of its own firmware before performing the updates of sub-systems, there is a high level of confidence that the whole process is secure.

The impact of a compromised firmware for one of these sub-systems is often limited. An attacker who deploys a malicious firmware update to an BLE module is unlikely to be able to compromise the main application processor or connected mobile devices. Probably, they will only be able to perform a denial-of-service by stopping the device from working.

Don’t let the perfect be the enemy of the good

While having secure boot on all processors is desirable, it should not be a concrete requirement for all devices. For many classes of device, performing secure boot on the main application processor will provide an adequate level of security.

Use a safety case methodology to justify situations where secure boot is not implemented on all processors in a device. It’s a methodology used in the safety and automotive spaces to justify that a system is acceptably safe for use under certain conditions. Structured arguments are used to document outstanding risks and state that a risk may be acceptable.

We’ve helped several clients write documentation to provide to regulators to justify non-ideal aspects of their systems. Being open and pragmatic about your risk management – even if there are outstanding risks – is a good way to reassure others that you are doing things the right way.