Secure Boot for Microcontrollers

Signing the software in the production process

Verifying the signature when starting the software

Successful verification can confirm the authorship (authentication) and guarantee the integrity of the software. Common signature methods are:

• SHA-256 hash algorithm (Secure Hash Algorithm) combined with RSA encryption (Rivest–Shamir–Adleman, prime factorization)
• SHA-256 hash algorithm combined with ECC encryption (Elliptic Curve Cryptography)
• DSA (Digital Signature Algorithm, discrete logarithm)
• ECDSA (Elliptic Curve Digital Signature Algorithm, elliptic curves)

The technical implementation of the trust check and which other functions are offered (e.g. revocable signing keys, protection against installation of old software (software downgrade/anti-rollback)) depends on the respective microcontroller manufacturer.

When do I Need Secure Boot?

Why is Secure Boot important for you? As a manufacturer you need or want to ensure that the device does what it was designed and tested to do. Reasons for this are: to comply with regulatory requirements (e.g. IEC 62443, EU Cybersecurity Act etc.), to avert warranty claims (e.g. ensuring correct operation, guaranteeing data integrity (information security) etc.) or to prevent reputational damage (e.g. by the devices becoming part of a botnet).

What is Needed for Secure Boot?

Secure Memory

The microcontroller must provide several features to enable Secure Boot. First, there must be secure memory in the microcontroller. This secure memory stores all the key information needed to verify the software signature. Depending on the implementation, the secure memory must be read-only or read-and-write protected.

It is important that the secure memory is located within the microcontroller and not added as an external device/ IC, e.g. Secure Element (SE), Trusted Platform Module (TPM) or secure storage. This is important because the authenticity of the SE or TPM devices cannot be guaranteed (e.g., the devices could be swapped on the PCB). This does not mean that SE and TPM circuits are insecure, it just means that Secure Boot is needed to operate these devices securely.

Secure Bootloader

Second, the microcontroller must have an immutable bootloader that verifies the signature of the software before handing over control to the software. This bootloader is often called a ROM bootloader because it resides in a read-only area of permanent memory (Flash).

These two functions together, secure key memory and secure bootloader, form the Root of Trust (RoT), or the root of security. Sometimes RoT is also called the Hardware Trust Anchor.

What Else is Needed?

Nothing. Nothing? The Secure Boot function is just the starting point for building a secure device. For a complete and secure system, more is required.

Do you need an Additional Bootloader?

If you want to be able to update your software, e.g. over the network or Over-the-Air (OTA), then you usually need another bootloader (2nd stage bootloader), e.g. u-boot for Linux systems or MCU Boot for microcontrollers.

The integrity of further boot data, e.g. a Linux device tree and/or a Linux root file system, must also be checked. In a system with u-boot, this check is done by the u-boot bootloader before it passes control to the Linux kernel. This creates a Chain of Trust in which each piece of software checks the following piece of software before passing control to it. At the end of such a chain is the certainty that only the intended and unmodified software is executed.

Secure Boot Chain

Can Secure Boot be Bypassed?

The Secure Boot process must not be compromised by using other ways to start an unchecked software. E.g. all debug interfaces (JTAG, SWD...) must be disabled or, if this is supported by the microcontroller, protected by encryption.

Furthermore, the ROM bootloader must be configured in such a way that it only executes signed software from the intended sources, i.e. it does not search all possible sources for a software and then starts it unchecked.

Which Organizational Measures are Necessary?

The creation and use of the key material for signing requires special attention. Where is the key material for signing stored (e.g. Hardware Security Module (HSM))? Who has access to the key material (e.g., processes, two-man rule)? How do the (intended) keys get into the microcontroller?

These are all delicate issues that affect your organization and your hardware manufacturers. Security depends on ensuring that only valid signing keys are stored on the microcontroller and that only authorized people can create signed software.

What are the Insights?

Security cannot be added after the fact. Without the right choice of the microcontroller, a secure device cannot be built. Also, features such as device provisioning over the Internet (IoT Device Provisioning) or secure storage of data (Secure Storage) are not possible without Secure Boot.

Start addressing security now. Satisfy today's and tomorrow's laws and regulations and, most importantly, maintain your reputation in the future. We are happy to support you!

Alois Cavelti

Do you have additional questions? Do you have a different opinion? If so, email me  or comment your thoughts below!