A mix-and-match attack combines individually signed images, such as a kernel and a device tree, into a configuration the vendor never intended. U-Boot's answer is to sign the configuration, which covers every image it references and the root structure. Rollback to an older signed image needs a separate defense.
What goes wrong when only images are signed
The U-Boot documentation explains that FIT images carry hashes, but hashes only detect corruption. A signature ties the hash to a private key. If you sign each image but not the way they are combined, an attacker with write access to the FIT can add a new configuration that pairs a signed kernel with a signed device tree or ramdisk from somewhere else. Every image verifies, yet the system as a whole is not what you tested.
What a signed configuration covers
With signed configurations, images carry plain hashes and each configuration gets a signature over:
- the configuration node,
- every image it references and that image's hash subnodes,
- the root structure, so nodes cannot be added or removed.
U-Boot rebuilds the list of nodes from the configuration's own references rather than trusting the hashed-nodes property, since that property is not covered by the signature. Every referenced image must have at least one hash subnode.
Keys and policy
Trusted public keys live in U-Boot's control device tree, because a key stored inside the signed image could be altered. Key nodes carry an algorithm such as sha256 with rsa2048, and an optional required property set to image or conf. The required-mode setting decides whether any or all required keys must validate the configuration.
Rollback is a different attack
The documentation separately identifies rollback, where an older signed image is placed into a newer FIT. Signed configurations address mix-and-match, not rollback. It points to TPM based rollback protection scripted through the tpm command and lists a built-in default as future work. If you ship U-Boot verified boot, plan your own downgrade defense.
| Attack | Defense in the documentation |
|---|---|
| Corrupted image | Hash |
| Swapped image | Image signature |
| Mix-and-match configuration | Signed configuration |
| Older signed image | TPM scripting, not built in |
Checklist
- Sign configurations, not only images.
- Set required keys so an unsigned configuration cannot boot.
- Keep the control device tree itself protected by your boot chain.
- Add a rollback control and test it.
Where Safeguard fits
Safeguard supports compliance and evidence automation alongside SBOM and dependency scanning, so a record like this can be kept with your other evidence. Try the free scan at gold.safeguard.sh/scan on a repository you already own.
Quick check
Is a hash in a FIT image enough?
It detects corruption. Without a signature anyone who can write the image can compute a matching hash.
Does U-Boot prevent rollback by default?
The documentation does not describe a built-in rollback defense and lists one as future work.
Sources
Last reviewed: 19 October 2026.
