As a reminder, secure boot is a verification mechanism that ensures only trusted software can run on your board, whether it’s a Raspberry Pi or any other hardware.
It relies on a copy of a public key embedded in the System on Chip (SoC) to authenticate the next bootloader signature via the ROM code.
Raspberry Pi 4: key steps for implementing secure bootBecause every board is unique, the process of enabling secure boot varies from one device to another. The Raspberry Pi documentation provides the necessary guidance to activate this feature on your specific board.
SpecificitiesUnlike many other platforms, secure boot is not enabled by default on the Raspberry Pi 4, and the verification sequence starts with the GPU. It uses a proprietary Raspberry Pi EEPROM binary to authenticate the next boot stage.
Another specificity is that the Device Tree Blobs (DTBs) are not included in the FIT image; instead, they reside in the bootloader partition. As a result, they must be authenticated before U‑Boot is executed.
Let’s now walk through each step of the Raspberry Pi secure boot implementation process together.
Overview of the secure boot processThe secure boot process begins with the loading of ‘bootsys’, a component embedded in the EEPROM binary. Its signature is verified against the Raspberry Pi’s proprietary keys stored on the board.
Once validated, ‘bootsys’ retrieves the public key from the EEPROM binary (our public key) and compares its hash to the one fused into the One-Time Programmable (OTP) memory. If the hash matches, the EEPROM configuration is authenticated using its signature. At this point, ‘bootmain’ is considered trusted and proceeds to load the BL3 stage, which resides in ‘boot.img’. BL3’s signature, signed with the user’s key, is verified before execution.
Finally, BL3 (that we decided to implement as U-Boot in our Welma Yocto configuration) completes the secure boot process. This final stage is machine-agnostic in order to compatibility across different hardware configurations.
You can see the Raspberry Pi secure boot process in this image:
To generate a secure‑boot–compatible Yocto image for the Raspberry Pi 4, you can start from the Welma Yocto Linux pre‑configuration. Simply add WELMA_SECURE_BOOT = "1" to your local.conf file. This setting adjusts the build process so it produces all the required secure‑boot artifacts.
Unlike the standard Raspberry Pi boot flow, which uses start.elf, configuration files, and a DTB with overlays, secure boot introduces a different structure. First, the customer’s key must be embedded into the DTB. This key is then provided to the initramfs to maintain the secure boot chain.
Next, all boot‑related components must be bundled into a single file called boot.img, following the format expected by the secure bootloader. Raspberry Pi provides dedicated utility scripts for this purpose in their GitHub repository.
After generating the secure boot image, it must be cryptographically signed using the customer‑specific key so that the bootloader can verify its integrity and origin. This signing step produces two artifacts: boot.img and its accompanying signature file, boot.sig.
Both files need to be placed in the boot partition of the SD card, which must use the vFAT filesystem for the Raspberry Pi firmware to recognize them.
Once these files are in place, the system is prepared to start the secure boot sequence.
2. Create and sign the BL2 bootloaderTo build a secure bootloader for the Raspberry Pi 4, you’ll once again rely on the Raspberry Pi GitHub repository. It includes the rpi‑eeprom tools, which provide access to different firmware versions along with the scripts needed to configure them.
To enable secure boot in the BL2 stage, update the boot.conf file by setting SIGNED_BOOT=1. It’s important to note that this step does not lock the device or program the OTP fuses. As a result, secure boot is not fully enforced yet, a malicious actor could still overwrite the bootloader and inject their own key.
Once the configuration is ready, sign the boot.conf file with your customer key.
Then apply the configurationusing the rpi-eeprom-config script. This generates a customized bootloader binary, pieeprom.bin, derived from the original firmware.
To deploy the updated bootloader onto the Raspberry Pi 4, you must prepare an SD card containing the generated pieeprom.bin file, its associated SHA‑256 hash, and the recovery.bin file.
When this SD card is inserted and the board is powered on, the Raspberry Pi 4 automatically enters its update routine and writes the new bootloader to the device.
The final step is to verify that the system boots correctly. Once everything is confirmed, you can fuse the OTP to permanently enable secure boot and lock the device against unauthorized modifications.
3. Fuse the OTP and lock down the boardTo permanently activate secure boot on the Raspberry Pi 4, the One‑Time‑Programmable (OTP) memory must be fused.
This step requires the rpiboot tool provided in the Raspberry Pi usbboot project. Because the Raspberry Pi 4B does not expose RPIBOOT mode by default, you first need to assign a GPIO line that will enable it.
The process begins by wiping the contents of the EEPROM. This is done by preparing an SD card that includes a config.txt file containing erase_eeprom=1. Booting from this card clears the EEPROM and makes it possible to configure which GPIO pin will be used to invoke RPIBOOT.
Raspberry Pi documentation typically suggests GPIO 8 for this purpose.
After choosing the pin, add program_rpiboot_gpio=8 to config.txt and invoke rpiboot -d. so that the current directory is used as the temporary boot source.
Once the GPIO assignment is in place, bridging that pin with a jumper (as illustrated in the reference diagram) forces the system to bypass the normal EEPROM boot path and start up in RPIBOOT mode instead.
Now, with RPIBOOT active, you can write the hash of your public key into the OTP. To do so, add program_pubkey=1 to config.txt and run rpiboot -d. again. This fuses the public key hash into the OTP and completes the secure boot setup.
Our Raspberry Pi 4 now have secure boot fully enabled!






Comments