U-Boot keeps the public key in the device tree it uses for configuration, and checks signed FIT images against it when they load. The key is public, so secrecy is not the issue. Tamper resistance is. If someone can replace the key, verification is meaningless, so it should sit in read-only memory or similar.
How it fits together
The U-Boot documentation describes verified boot as a way to verify all software loaded during boot so the machine runs only authorised code. A private key known only to the signer signs the image. The related public key verifies it, and the page notes the public key can be shared without weakening verification.
FIT, the flattened image tree format, is a device tree containing images and already includes hashes. Signatures extend that, which is why adding them is relatively simple.
The key location
The public key lives in U-Boot's control device tree, in a standard place. When a FIT image is loaded, it is checked against that key. The page says multiple keys and signatures are supported.
Why tampering with it is fatal
The documentation says it is critical that the public key is secure and cannot be tampered with, and suggests read-only memory or on-chip crypto. If an attacker can rewrite the key in flash, they can install their own key and sign whatever they like. The signature check passes, and nothing looks wrong.
This is the same weak point that applies to every root of trust. The check is only as strong as the place that holds the trusted key.
Chaining keys
The documentation describes a master key that verifies a first stage image holding a secondary public key. That second key verifies later stages, and it recommends a different key at each stage. The benefit is limiting exposure. A key used often, for example in a build pipeline for application images, can be different from the one that guards the earliest stage.
A checklist
- Store the verifying key where it cannot be rewritten after manufacturing, if your hardware allows.
- Keep signing private keys offline or in protected hardware, away from general build servers.
- Use separate keys per stage and per product line.
- Plan rotation before you need it. If the key is fixed in silicon, rotation may mean a hardware revision.
- Test that an image signed with the wrong key is rejected.
Does verification stop downgrades?
The U-Boot page does not cover rollback protection in this context. Treat that as a separate design item and see the security counter post.
Quick check
Is the public key a secret?
No. The U-Boot documentation says it can be shared without weakening verification. It must be protected from modification.
Why use different keys at each stage?
It limits the impact if one key is exposed. The documentation recommends a different key at each stage when chaining.
Where Safeguard fits
Safeguard works on the software supply chain around your firmware: SBOM and dependency scanning, policies and gates that can block a release, and compliance evidence. It does not sign images or run your bootloader. You can try a free scan at gold.safeguard.sh/scan.
Sources
Last reviewed: 19 October 2026.
