The development of the boot process
The booting of a chip is a critical weak point in establishing a Hardware Root of Trust for a device’s security architecture. When a secure booting procedure is not adopted, the entire secure boundary of a device can be easily compromised, leaving the chip vulnerable to attack.
We are now entering the 3rd generation of boot processes. The 1st generation, or the conventional booting process, had the boot code stored without any security protocols in place. The 2nd generation introduced a basic level of protection, by encrypting the boot code. The global key, for decryption, is then injected to protect the firmware. However, the boot code remains externally stored, requiring key management protocols to ensure that the global key is not compromised. The key injection process is typically done during the CP/FT phase, requiring a secure room and multiple extra security procedures. Between the external key management and injection costs, this can result in up to an extra $2 per unit, added on top of continually rising chip production costs.
Secure booting represents a generational shift in the approach to chip security by dissecting the process into multiple stages and bringing some of the boot code into the SoC. This allows the system to verify the authenticity of the code stored in the flash memory during the booting stage.
The Secure Boot Flow procedure
The Secure boot flow begins with the first boot code, which is typically stored in the SoC’s ROM. This procedure allows the verification of the first boot code from within the chip, removing the need for any key injection and establishing an inborn root key. This can be used for decryption purposes during the following stage in the protocol.
The Secure boot flow begins with the first boot code, which is typically stored in the SoCs ROM. This procedure allows the verification of the first boot code from within the chip, removing the need for any key injection and establishing an inborn root key. This can be used for decryption purposes during the following stage in the protocol.
The next phase of the Secure Boot Flow usually stores the boot code in OTP non-volatile memory, allowing the programming to be completed separately from the chip’s fabrication. This phased procedure of key generation, followed by decryption and verification, extends from hardware to firmware to the operating system and then, in turn, through the installation of each application.
Phasing the Secure Boot Flow procedure allows each stage’s authentication to be verified in a chain through each of the previous steps, with the chain of trust extending right back to the initial Hardware Root key.