Secure Boot Simplified

In the world of bootable devices like (PC, Mobile Phone, Automotive IVI etc.), Secure boot is a mechanism which is used by device OEMs ,primarily, to ensure that users are not able load and run any other software which is not given by the device OEMs themselves. This helps the OEMs (and operators) to lock the device to run their own software e.g. US operators give devices to their subscribers on a subsidized rates, and they do not want users to change the software and start using the device with some other operators.

Secure boot is designed to add cryptographic checks to each stage of the secure world boot process. This process is designed to verify and ensure the integrity of all the boot-loaders running on the device. In general there are various boot-loaders run on a device, and they get verified one after the other. The first boot-loader which runs on the device is called the Primary Boot Loader (PBL), and this gets verified with the help of a cryptographic key (OEM public key) which is stored in the device hardware itself. This key is commonly referred as base for Hardware Root of Trust.

Secure boot mechanism is achieved by utilizing the cryptographic support provided with the help of hardware as well as software. The cryptographic process of secure boot works on the principle of asymmetric key encryption algorithms like RSA and digital signature where OEM signs the boot-loader with its own private key, and during the boot process this signature gets validated using the public key present in the device itself. If the signature validation succeeds, boot process continues in a normal manner, and if it fails boot process shows and warning/error to user before proceeding further.

The complete process life cycle of the secure boot process is as follows:

Bootloader Image Signing Process

1. Generate the unsigned boot-loader image.
2. Generate a RSA private/public key pair
• The private key of this pair is kept in an extremely confidential storage at the OEMs geographical location. As this is the OEMs private key, and it will be used to sign the update packages (if OEMs updates the software later on), the access to this key is very much restricted to authorized people at the OEMs location as well
• The public key of the pair which is used as a root of trust need to be stored on-SoC ROM (chipset). The SoC ROM is the only component in the system that cannot be trivially modified or replaced by simple reprogramming attacks. But, On-SoC storage of the key for the root of trust can be problematic; embedding it in the on-SoC ROM implies that all devices use the same public keys because all the devices will be using the same chipset. This makes them vulnerable to class-break attacks if the public key is stolen or successfully reverse-engineered. On-SoC One-Time-Programmable (OTP) hardware, such as poly-silicon fuses, can be used to store unique values in each SoC during device manufacture. This enables a number of different key values to be stored in a single class of devices, reducing risk of class break attacks. As these fuses are one time programmable, OEM uses these during the device manufacture and stores their on public key (hash*)
• *Also, OTP memory can consume considerable silicon area, so the number of bits are that available is typically limited. A RSA public key is over 1024-bits long, which is typically too large to fit in the available OTP storage. However, as the public key is not confidential, it can be stored in off-SoC storage (or sent as part of the image as certificate itself), provided that a cryptographic hash of the public key is stored on-SoC in the OTP. The hash is much smaller than the public key itself (256-bits for a SHA256 hash), and can be used to authenticate the value of the public key at run-time.
• Note: It also seems to me that sometime even though the hash of public key is stored on the device OTP, public key itself is not stored on the device chipset. As public key is not confidential, it can also come as part of the image itself (as certificate), and can be verified using the hash in OTP at run time as well. I am not still sure about the mechanism followed by OEMs in general.
3. Create the hash of the unsigned image using e.g. SHA256.
4. Encrypt the hash from step 3 using the RSA private key of step 2.
5. Attach the encrypted hash (from step 4) to the end of the unsigned image – this is a signed image now.
6. Create the SHA256 hash of the public key from step 2
7. Store the public key hash on the OTP memory on the SoC by blowing the fuses.
8. Store the public key of the pair from step #2 to the off-SoC storage (or attach it as certificate to the image itself) on the device itself.

    Bootloader Image Verification Process

1. During the boot process, read the primary boot-loader signed image.
2. Now generate the SHA256 hash of the public key stored in the off-SoC storage (or using the certificate attached to the image itself) and compare it with the hash which is stored in the OTP area to validate the integrity of the stored OEM public key. 
3. If the public is validated successfully, this public key will be used to decrypt the encrypted hash attached to the image to verify the authenticity of the image sender ( as this is OEM public key, if the decryption happens successfully, we can claim that it is sent by the OEM itself)
4. Detach the encrypted SHA256 hash which is attached at the end of the image, and decrypt it using the public key which we validated above. 
5. After removing the encrypted hash, generate a new hash using the remaining boot-loader image from step 1.
6. Compare this decrypted hash (from step 4) with the hash generated using the image (step 5).
7. If the comparison passes, we can say that the bootloader image which is available on the device, and the one which was originally sent by the OEM are same (as the hashes are same). We can concluded that Primary Boot Loader is in its original unmodified state, and we can move to next step in the boot process. (Note that, if the hashes are not same that will primarily mean that either the bootloader image has been changed, or the private key which is used to sign the bootloader has is not the OEM private key itself).

The process mentioned above is used to verify the integrity on the first-level boot-loader, which subsequently, in the similar manner, verifies the integrity of subsequent levels like application boot-loader and eventually the kennel. Once the kernel is verified, and if dm-verity is enabled in the kernel, it can go and verify the integrity of the system image.