Four major design considerations in secure boot for IoT applications

Secure boot, the first line of defense against security breaches in embedded systems, verifies the pre-boot authentication of system firmware using a root-of-trust service and thus safeguards code and data to prevent malicious activities. It’s a critical security measure to protect connected devices like the Internet of Things (IoT) endpoints because most security breaches such as hacking and reverse engineering start with code boot.

Secure boot, the very first code that MCUs execute after the power-up or hard reset, even before the BIOS and OS run, verifies the software authenticity by showing the exact same image of the original firmware.

Figure 1: This is how secure boot works on the OEM side of connected designs in embedded systems such as smart meters, factory and building automation, and smart locks. Image: Microchip

Figure 2: This is how secure boot looks like after the system is deployed with a security-centric MCU that compares digest and verifies sign. Image: Microchip

Below are four basic design considerations that embedded engineers may contemplate to build an efficient secure boot mechanism and make sure that the boot code hasn’t been compromised.

Coding best practices

For a start, application code, developed either by in-house designers or third-party vendors, should follow the embedded security policies to ensure that only approved firmware is used. And that the application code is signed and verified before execution.

Security MCUs

Embedded designers develop a secure bootloader and application code to ensure that the application is signed and verified before the execution. However, a connected design’s identity, signed certificates, and security keys are not protected in common MCUs.

Figure 3: Here is a step-by-step view (bottom) of how a security MCU validates the authenticity and integrity of an embedded design before code execution to ensure that invalid and malicious code cannot be run. Image: Microchip

A secure MCU (Figure 3) with the hardware root of trust features an isolated security enclave for key storage, and that facilitates authentication to safeguard the secure boot operations. It ensures that a system-critical command is from a known source, and it has the authorization to make the given change.

Boot speed

The security-centric MCUs, offering hardware cryptographic cipher suites, also reduce the compute overhead compared to software-based solutions. They can run secure boot quickly and at lower cost and power consumption as compared to software solutions. The software-based solutions running hash algorithms are usually more time-consuming.

Firmware updates

The combination of secure boot and secure firmware updates adds a new dimension to the security feature set of MCUs. An MCU equipped with a security feature set can also verify that the firmware update hasn’t been corrupted and that it comes from a trusted source.

Additionally, it creates multiple layers of security in embedded designs and thus lowers the risk of security breaches. It’s worth mentioning here that some secure boot mechanisms, such as the ones that lock flash memory or use one-time programmable (OTP) memory, can also close the door for engineering updates in the future.