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 for Microcontrollers - How does this Work?
