Is secure boot on the main application processor enough?

TL;DR

• Secure Boot ensures only authentic firmware runs on a device but isn’t foolproof against all attacks.
• Sub-systems often lack Secure Boot capabilities, limiting protection for non-critical processors.
• Focus on Secure Boot for the main processor; it provides adequate security in most 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.

How does secure boot work?

Secure boot works together with firmware signing to ensure that a device can only run authentic firmware. A weakness or vulnerability in one of these two mechanisms should not result in complete compromise of the device.

What about firmware signing?

Some argue that firmware signing is ineffective against physical attacks against a device. Whilst secure boot does protect against some physical attacks, such as direct replacement of firmware in external 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.

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 bootUSB peripherals for example. These small microcontrollers can’t execute the cryptographic algorithms required.

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.

It is suggested that a safety case methodology is used 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 gain assurance around the trustworthiness of systems.