“Enrolling my own keys” on a Raspberry Pi 5 does not work like UEFI Secure Boot key enrollment. There is no key-management menu, no PK/KEK/db variable store, and no way to add a second trusted key later. The documented procedure is one-time-programmable (OTP) fuse provisioning plus a signed EEPROM configuration block and a signed boot image. The Raspberry Pi usbboot secure-boot documentation states the constraint plainly: “Once secure-boot has been enabled by programming the one-time programmable (OTP) fuses, it cannot be disabled and a different key cannot be programmed” (usbboot, docs/secure-boot.md). The quickstart repeats it: “Enabling signed boot modifies the OTP memory and is irreversible” (secure-boot-example/README.md).
That single fact reframes the compliance question. The interesting audit question is not whether the device booted code the vendor authorized. It is whether the vendor discharged the license obligations attached to that code. Those are separate controls, and the Pi 5 boot flow makes the boundary between them unusually visible.
The documented chain of trust, stage by stage
The Raspberry Pi secure-boot overview describes a four-stage chain. I am quoting the vendor text rather than paraphrasing because the exact verbs matter for an audit record:
- BootROM loads the second-stage
bootsysfrom SPI flash and verifies it is signed by a valid Raspberry Pi BootROM key. The BootROM is fused into the silicon and is the immutable root of trust. - bootsys “loads the customer’s public key from EEPROM and checks it against the customer key hash stored in OTP, previously written via rpiboot.”
- bootmain loads
boot.imgandboot.sigfrom SD, eMMC, USB, NVMe, or network, then “verifies that the hash of boot.img matches boot.sig and that the RSA signature in boot.sig can be validated using the customer’s public key.” - bootmain uses the verified ramdisk to load the GPU firmware (
start.elf) and start the operating system. With secure boot enabled, firmware only loads files from the verified ramdisk.
All four steps are from the same usbboot secure-boot document. The failure behavior is documented in the quickstart: “If the boot.sig signature does not match boot.img, the bootloader will refuse to load the OS” (secure-boot-example/README.md).
Two details in that chain deserve emphasis for anyone building an evidence file. First, the customer public key lives in the EEPROM image, not in OTP. OTP holds a hash of that key. The rpi-eeprom README describes the tooling: rpi-eeprom-config can “embed a signed config block plus RSA public key for signed-boot (--config, --digest, --pubkey)” (rpi-eeprom README). Second, the signature format is specified: rpi-eeprom-digest generates “.sig files (SHA256 + timestamp, plus an optional RSA PKCS#1 v1.5 signature for signed-boot)” used for both bootconf.sig (the bootloader’s own configuration block) and boot.sig (the OS payload). The key length is fixed at 2048 bits RSA.
The Pi 5 difference: counter-signature gates firmware updates
On BCM2711 boards (Pi 4, Pi 400, CM4), the boot ROM only checks that bootsys is signed by Raspberry Pi’s key. On BCM2712 boards (Pi 5, Pi 500, CM5), the rule changes: “when secure-boot is enabled, the boot ROM requires bootsys to be signed by Raspberry Pi’s private key and counter-signed with the customer’s private key” (usbboot secure-boot.md). The rpi-eeprom README describes the corresponding tool: on BCM2712, tools/rpi-sign-bootcode -c 2712 “counter-signs the Raspberry-Pi-signed bootcode / bootsys with the customer key — required by the BCM2712 ROM when secure-boot is enabled” (rpi-eeprom README).
The vendor documentation frames the purpose as authorizing specific bootloader firmware versions: “a firmware update cannot be installed unless the customer signs it.” For a compliance record, that has a concrete consequence. The customer’s signing-key custody and the provenance of each counter-signed bootsys become part of the same evidence trail as the source offer. If you cannot show which firmware revision you counter-signed, you cannot show which bootloader binary you distributed.
What the verified boot flow does not cover
The same document is explicit about the limits, and these are the parts most often glossed over in product briefs:
- No full-disk encryption in ROM or firmware. “There is no support in the ROM or firmware for full-disk encryption. Instead, we recommend storing the root filesystem within a LUKS container that is mounted by scripts within initramfs.”
- No secure hardware enclave. “Raspberry Pi computers do not have a secure hardware enclave, and within the secure-boot OS image this key is accessible to any process with access to
/dev/vcio(vcmailbox).” - Supervisor mode can reach OTP directly. “It is not possible to prevent code running in ARM supervisor mode (e.g. kernel code) from accessing OTP hardware directly.”
These are threat-model boundaries, not defects. They tell an auditor which secrets can be treated as device-bound and which cannot. An OTP-derived key on a Pi 5 is not equivalent to a TPM-sealed key, and the vendor documentation says so. I could not confirm any additional hardware-isolation claims because the Raspberry Pi security-architecture documentation page failed to retrieve during research; treat any such claim as unverified until you have the primary page in hand.
The audit surface: boot.img is a bounded artifact
Here is where secure boot becomes useful to a license auditor rather than just a security engineer. The documentation requires a self-contained ramdisk: “Secure-boot requires a self-contained ramdisk (boot.img) FAT image containing the GPU firmware, kernel and any other dependencies that would normally be loaded from the boot partition” (usbboot secure-boot.md). The documented contents are:
config.txt- Device tree and overlay files
- GPU firmware (
start.elfandfixup.dat) - Linux kernel image
- Linux initramfs containing the application, or scripts to mount/create an encrypted filesystem
That list is finite. On a conventional Pi boot partition, the auditor has to sweep an open-ended FAT filesystem and reason about which files the firmware actually loads. With secure boot, the firmware loads only from the verified ramdisk, so the boot-path license inventory collapses to the contents of one image plus the EEPROM configuration block. The quickstart even shows how to enumerate it: mount boot.img with losetup and list the tree (secure-boot-example/README.md).
This is my recommendation, not a vendor claim: treat boot.img as the unit of license review for the boot path. For each component, record the upstream project, the license identified in the source, and the corresponding source-offer obligation. The kernel, the device tree files, start.elf/fixup.dat, and the initramfs userspace each carry different obligations, and the initramfs is where BusyBox-class GPLv2 components typically appear. The documented enforcement history — BusyBox litigation, FSF v. Cisco, SFC v. Vizio, gpl-violations.org v. D-Link — is a reminder that the initramfs and firmware blobs are exactly where source offers go missing.
SPDX and SBOM: the manifest is a separate control
An SPDX document is a structured inventory, not a signature. The SPDX specification is an international open standard, ISO/IEC 5962:2021, with version 3.0 current (spdx.dev specifications page). Nothing in the Pi 5 verified boot flow generates, signs, or validates an SPDX document. A device can pass every signature check and still ship without a source offer or a license manifest. The two controls answer different questions:
- Secure boot answers: did this device run code the key holder authorized?
- License compliance answers: did the distributor provide the corresponding source and notices for that code?
Neither implies the other. A signed boot.img containing a GPLv2 kernel proves the kernel was authorized to run; it proves nothing about whether the kernel source was offered. Conversely, a complete SPDX manifest proves nothing about whether the device booted the code the manifest describes.
A practical audit checklist
The following is method, not a claim about any specific product:
- Capture the provisioning state. Record whether OTP fuses are programmed, whether the EEPROM config block is signed, and which public key hash is in OTP. The
rpi-eeprom-configtool can extract the configuration block from an EEPROM image for inspection. - Enumerate
boot.img. Mount the image read-only and list every file. Map each to an upstream project and license. Flag any component whose source is not in your source archive. - Verify the signature chain. Confirm
boot.sigvalidates against the customer public key usingrpi-eeprom-digest -v, and confirm the public key in the EEPROM matches the OTP hash. - Record the counter-signed
bootsysrevision. On BCM2712, log which Raspberry Pi bootloader revision you counter-signed and when. That binary is part of what you distributed. - Cross-check the SPDX manifest against the enumerated contents. The manifest should describe the same components the image contains. A manifest that lists the kernel but omits the initramfs userspace is incomplete.
- Store the signing-key custody record with the compliance file. The private key is not in the OS image, per the documentation, but the fact of who held it and when it signed each artifact belongs in the same evidence set as the source offer.
Frequently asked questions
Can I enroll a second key on a Pi 5 after enabling secure boot?
No. The documentation states that once OTP fuses are programmed, secure boot cannot be disabled and a different key cannot be programmed. Plan key custody before provisioning.
Does secure boot encrypt my root filesystem?
No. The ROM and firmware have no full-disk encryption support. The documented approach is a LUKS container mounted by initramfs scripts, with the passphrase optionally derived from an OTP key.
Does a valid boot.sig mean my GPL obligations are met?
No. The signature proves the image was authorized by the key holder. Source-offer and notice obligations are separate and must be evidenced separately.
What happens if boot.sig does not match boot.img?
The bootloader refuses to load the OS, per the quickstart documentation.
Is the OTP-derived key protected by a hardware enclave?
No. The documentation states there is no secure hardware enclave, and the key is accessible to any process with /dev/vcio access within the secure-boot OS image.
The Pi 5 secure boot flow is a well-documented chain of trust with clear, stated limits. For a compliance engineer, its most useful property is that it makes the boot path a bounded artifact. That artifact is where the license audit should start — and the signature check is where it should not stop.