FIT Hashes Versus FIT Signatures: Match Integrity Checks to the Adversary
A hash comparison authenticates firmware only when the expected hash comes from an independently trusted source. If an adversary can replace both a FIT payload and its stored digest, a correct digest calculation can still accept the substituted pair. The algorithm may be working exactly as implemented while the product’s authenticity claim is unsupported.
This article pins U-Boot v2024.10 and focuses on reference provenance: who can change the bytes being checked and the value used to check them. It provides an unexecuted tamper matrix for approved test artifacts. It does not assess cryptographic strength, provision keys or claim complete secure-boot coverage.
1. State what the check is supposed to resist
Write the assumed actor capabilities before choosing the acceptance criterion. Accidental storage corruption, unauthorized writes to an update medium, a compromised signing service and modification of the verifier itself are different threats.
| Capability | Question for the current design | Required evidence |
|---|---|---|
| Payload changes accidentally; reference remains correct | Does a mismatch stop use of the payload? | Active digest comparison and propagated failure |
| Actor can change payload and co-located digest | What prevents a self-consistent replacement? | Independent authentication of expected identity |
| Actor can replace a supplied public key | Where is the trusted key policy anchored? | Protection outside the replaceable artifact |
| Actor can use an accepted signing key | Which incident controls remain effective? | Separate signing-authority and response assessment |
| Actor can replace executing verifier code | Who authenticates that earlier stage? | Separate preceding-stage trust evidence |
U-Boot’s FIT signature guide distinguishes corruption protection from image substitution. Use that distinction to label the deployed control honestly: an integrity-only check may satisfy a limited accidental-corruption requirement, but it should not be described as signer authentication.
2. Trace the expected digest’s provenance
Identify where the verifier obtains its expected value. Is it an image hash node in the same mutable FIT, metadata covered by an enforced configuration signature, or a separate protected release record? Draw the data path rather than relying on a checksum filename.
In v2024.10’s hash-checking function, the computed digest and stored digest are compared after algorithm and length checks. A match establishes consistency between those inputs. The function cannot infer that an untrusted stored value was authorized by the product owner.
Keeping a checksum file beside a downloadable image does not automatically create independent trust. If both objects are writable by the same unauthorized actor, they can remain mutually consistent after replacement. A protected expected digest can be a valid design element, but its delivery, update authority and binding to the intended device must be demonstrated.
3. Confirm that authentication is mandatory
A FIT containing a signature is different from a boot path requiring that signature. Inspect the final control-tree policy and consuming loader, using the actual build artifacts. Do not infer enforcement from a signing step in CI.
The tagged fit_image_verify_with_data() implementation first checks required image signatures. Its later optional-signature path can display failure without turning that optional failure into image rejection. Therefore a visible signature result must be interpreted with the required-key policy and returned status.
U-Boot’s verified-boot explanation makes protection of the verification key part of the trust boundary. An attacker-controlled key packaged with attacker-controlled content cannot independently establish authorization.
4. Use a three-way replacement matrix
Hold the loader and policy constant. Assume well-formed test containers, the intended digest algorithm, active hash checking and no hash-ignore behavior. The “required authentication” column additionally assumes the altered bytes or expected digest are inside the enforced authentication boundary.
| Fixture | Active hash comparison alone | Required authentication of covered content |
|---|---|---|
| Unchanged approved payload and metadata | Digest matches | Approved control should pass the scoped checks |
| Payload changed; old digest retained | Mismatch rejects | Covered-content validation rejects |
| Payload changed; stored digest recomputed; no new authorized signature | Digest can match | Reject through the enforced authentication boundary |
The third row is the decisive diagnostic. It distinguishes merely recalculating a public digest from verifying that an approved authority endorsed the expected content. It does not require defeating a hash algorithm or finding a collision.
Keep these fixtures in an isolated test corpus. Use inert payloads and approved recovery equipment if target execution is needed. Do not distribute a substituted package, alter production trust settings or overwrite live boot media to conduct the comparison.
5. Read the pattern of results
If payload-only alteration is rejected but the self-consistent replacement passes the relevant check, the result supports active integrity checking while leaving authenticity unproven. Investigate expected-value provenance and mandatory signature policy.
If both altered fixtures pass, first ask whether the intended bytes were checked at all. The wrong selected image, stale fixture, disabled validation or an unintended code path can invalidate the experiment. Do not conclude that the digest algorithm is weak from this observation.
If all fixtures fail, including the unchanged control, repair the baseline. A broken load address, unsupported format or missing key may prevent boot before the property under test is exercised.
If both altered cases reject at a parser error, the rejection is real but does not isolate authentication. Preserve structurally valid fixtures and attribute the failure to the expected checking stage.
6. Keep adjacent guarantees separate
Passing required signature verification does not select the correct hardware variant, reject every older approved release, protect later mutable boot arguments or prove runtime memory safety. Record those as separate acceptance requirements.
Likewise, a correctly signed configuration still needs actual payload hash verification. The digest and signature serve connected roles: the digest identifies content efficiently, and the enforced signature can authenticate the relevant identity or relationship under a protected key policy.
Hypothetical release-label misunderstanding
A release report says “secure FIT” because a payload-only corruption fixture failed. The same test plan never considered replacement of the stored digest. The team has evidence of one integrity check, but its report implies a stronger guarantee.
The corrected acceptance package records the actor capabilities, expected-digest provenance, required policy and all three fixture results. It names exactly which verifier path was tested. That evidence supports a bounded claim without treating a reassuring hash message as proof of firmware authorization.
