Hash Agility in Firmware Manifests: Plan How Devices Reject Unknown Digest Schemes
Do not assume that adding a second digest preserves compatibility with a verifier that understands only the first. Inspect how the exact format combines checks. In the U-Boot v2024.10 FIT path examined here, every enforced hash node must pass; a supported hash does not rescue an additional unsupported one.
This guide builds an algorithm-capability decision table for that implementation. It assumes the intended boot route requires authentication, image hash verification runs, and no hash node is marked for ignoring. It does not describe arbitrary manifest negotiation, recommend an algorithm, or claim that any target tests were executed.
1. Separate three capabilities
Record the container/parser format, payload-digest algorithms and signature-verification algorithms independently for each bootloader binary. A device may parse the container while lacking a requested digest implementation. It may calculate that digest yet reject the signature scheme used to authorize the configuration.
Record the actual consuming stage. Host signing tools, an earlier boot stage and the final U-Boot binary can have different build-time capabilities. Successful artifact generation proves only that the producer handled its inputs.
RFC 9124 section 3.13 describes one or more payload digests, with multiple-digest support optional. This information model does not prescribe the FIT implementation’s selection or failure behavior. Determine that from the exact consumer.
2. Identify conjunction rather than negotiation
In the pinned FIT implementation, fit_image_verify_with_data() visits hash-named subnodes and fails when an enforced hash check fails. The helper rejects unsupported algorithms, incorrect digest lengths and digest mismatches. It does not choose whichever supported hash happens to succeed.
The same source has an ignore mechanism, which is outside this article’s enforced-hash profile. Do not treat that mechanism as a migration workaround. Establish the actual policy and node treatment before applying the matrix.
This distinction changes the release question from “does the image contain a digest the device knows?” to “can this device satisfy every required check on this image?” A positive answer to the first question is insufficient.
3. Build a capability matrix for actual binaries
Use symbolic schemes A and B until the product’s approved algorithm identifiers, lengths and compiled implementations have been recorded. The following table is a hypothetical hash-gate model, with valid digests and all other required checks assumed satisfiable.
| Enforced hashes in artifact | Older verifier: A only | Newer verifier: A and B |
|---|---|---|
| A | Hash gate can pass | Hash gate can pass |
| B | Unsupported scheme fails | Hash gate can pass |
| A and B | B still causes failure | Both must pass |
| Unknown scheme C | Fails | Fails |
| Correct A, incorrect B | Cannot satisfy B | B mismatch fails despite A |
These are source-derived expectations, not observed results. “Can pass” refers only to the scoped hash gate. Required signature authorization, image selection, parser validity, rollback policy and board suitability remain separate obligations.
Add the final binary identifier and evidence reference to each real matrix column. Do not combine devices merely because their product names match: a downstream configuration may remove an algorithm or change the verification route.
4. Keep the authentication envelope valid
The configuration-signing implementation adds all hash nodes of a selected image to its included-node list. Changing protected hash metadata therefore requires a newly authorized artifact under the applicable signing policy.
A test that edits a protected algorithm name without preserving a valid authentication envelope may fail at configuration-signature verification first. That is useful evidence of tamper refusal, but it does not establish how an authenticated unsupported digest is handled.
Design the unsupported-scheme fixture through an isolated, approved fixture producer or a scoped consumer harness. Keep synthetic identities and inert payloads. Record whether the relevant hash dispatch was reached; do not weaken a production trust policy to manufacture the observation.
5. Choose a transition from the matrix
If the installed cohort understands only A, an A-and-B artifact is not automatically a backward-compatible bridge. Its eligibility must follow the whole enforced-check set.
Maintain a clearly identified compatible artifact for the cohort when permitted by the product’s security requirements, or first qualify an authorized verifier change that supports the intended new checks. The product must separately approve its recovery and deployment sequence; this digest analysis does not supply that authorization.
Distinguish technical capability from allowed policy. A newer verifier may still implement A for compatibility while the release policy disallows new A-only artifacts. Conversely, removing A from the binary can invalidate previously retained recovery artifacts. Record both capabilities and policy requirements rather than treating support as permission.
6. Interpret the proposed negative controls
- Use a valid, approved A-only artifact as the older verifier’s positive control.
- Use an authorized A-and-B artifact to establish whether B is independently enforced.
- Keep a supported scheme with the wrong value separate from an unknown scheme identifier.
- Include a malformed digest-length case and record the actual failure stage.
- Repeat the relevant checks for every consuming boot stage and recovery artifact.
These fixtures were not executed. If a fixture fails before hash processing, report that earlier result and leave the digest-capability conclusion unresolved. If the boot route never invokes the expected verification, the matrix’s assumptions are unmet.
Hypothetical dual-hash rollout
A fictional team adds B beside A because it expects older devices to select A. Its source review instead finds all-hash enforcement. The team removes the proposed universal-compatibility claim before release and separates artifact eligibility by verified capability.
The useful result is the corrected release decision, not a suggestion to bypass B or ignore an error. Preserve the exact verifier hashes, authenticated artifact identities, algorithm lists, stage observations and remaining qualification gaps. Recheck the table whenever a build, format or required-policy change alters those inputs.
