Secure Boot is the means of validating the initial software that runs on an embedded device usually backed with a hardware trust. Ask me what’s hardware trust — a piece of code which is uniquely bound to the device by the manufacturer, eg. a PUF utility burned into the device at the time of manufacturing, or a one time programmable memory with access to writing a secret key. Note that the later method allows a secret to be inserted into a device after the manufacturing.
When a micro-controller or micro-processor resets, it jumps to the reset vector (address 0x0000) and starts executing the boot. The secure boot usually comprises of the following stages :
- One Time Programmable memory (OTP)
- Root of Trust (RoT)
- Bootloader
- Operating System(OS) Image — Linux, RTOS, etc.
OTP memory is written with a secret key that can be used to verify the bootloader. Once the bootloader image is created, it is cryptographically signed by the certificate authority. The certificate authority can be considered as the one that writes/develops the bootloader image. This provides the authenticity for the bootloader image that it is generated by a valid source. The public key which is used to sign the bootloader image, is then written to the one time programmable memory. In order to save memory, the better option is to write the hash of the public key to the OTP memory. Once the key is written to this area, it cannot be changed and stays till lifetime of the device. Hence this makes it secure.
The RoT is the first piece of code that executes, i.e. after the reset vector. This code is burnt into the ROM with minimal features like initializing the peripherals required for booting and loads(in RAM) the next software i.e. Bootloader required for secure booting.
The Bootloader then verifies its own signature with the OTP memory hash. If the signature verification is successful, the next stage of the bootloader i.e. loading of the operating system(Linux, RTOS) occurs.
Now this is the basic principle of secure boot. This can be extended now by verifying the boot image of the operating system. For this, the operating system image is cryptographically signed with another set of keys(different from that used to sign bootloader). The hash of the public key is embedded into the bootloader which is verified against the operating system image. If the signature verification is successful, the bootloader loads the OS image, else throws an error and resets.
Side Notes:
The implementation of secure boot is highly dependent on the SoC vendors. However, the method used is similar to the one mentioned above. In some cases, the bootloader is split into various stages to load/execute certain software image that needs to be loaded before the operating system(OS). In such a case further verification of these software is essential. An example is a hypervisor based system which loads different OSes, in this case the signature verification of hypervisor image is necessary.
The SoC vendor might provide hardware accelerators to verify the signature of various components in the secure boot process. This is done to speed up the booting process, as signature verification functions can take longer time due to complex mathematical calculations.
For a cryptographic signature, a pair of private and public key is required. The private key is used to sign the image/binary and a public key can then be used to verify the authenticity of the image. Public key is meant to be shared and needs no special security measure to be stored.
