If you already feel that you know what Secure Boot is and how it is handled you can skip this primer and go straight for the juicy bits where I discuss keys in a historical perspective, handling keys as a secret, production of devices and, what I learned implementing it at Westermo: (gah not completed yet, please check in later)

Secure Boot 101

The reason to opt for secure boot

1. It ensures the authenticity of the software run on the product
2. Provides security that only software from known sources can be installed

Before we dive into the implementation we did at Westermo there are basically two cryptographic concepts you need to know about to understand how it all works.

1. Public Key Cryptography (a.k.a. asymmetric cryptography). This handles encryption of data. This consists of two keys. One private and one public. By the names you can conclude that the private one you keep secret (private) and known only to you and the public key is exactly that, publicly known.
2. Hash Functions. These mathematical functions are one way and for a given input always produce the same output. You can not from the output deduct the input. These are used to control the integrity of data.

This shows on a conceptual level how this is used to verify the integrity or source of software. In this case the firmware for many of our products at Westermo (WeOS).

 

The steps are as follows:

1. A hash is calculated on the software. This is done by a hashing algorithm such as SHA-256 and is performed on for example the executable. This hash is called a Digest.
2. The Digest is then encrypted with the private key you have.
3. The software, encrypted Digest and Public Key is then distributed to the users.
4. The user calculates a hash on the software received with the same hashing algorithm and decrypts the encrypted Digest with the Public Key.
5. The user compares the two Digest. If they are the same we can conclude that the software is authentic and safe to use.

In a secure boot scenario this is of course done programmatically in the product at boot. This can technically of course be implemented several ways. The picture shows an overview how keys are handled in trust chain at Westermo.

 

1. The signing process describe above is employed and the private keys mentioned above are used to create signatures for the different bits of software needed for the product to run, the bootloader, the firmware and on top of that other applications that are sometimes allowed.
2. The public key is burnt into the HW (TPM och Secure Zone etc.) in production. In this case our own production facility in Sweden.
3. When the product is powered on the HW verifies the signature of the bootloader and if correct continues boot. If there is no match you have a very nice bookend (bricked unit).
4. The bootloader verifies the signature of WeOS (the operating system, Linux based) and starts the booting of it.
5. WeOS in turn verifies the signature of any other application that is run within its context. For instance container application.

This is in essence all what secure boot is but obviously there is a million and one technical aspects and considerations while implementing this but now I think you have at least some understanding of why secure boot is a good thing for security and also how it is implemented.