The signed bundle does not bind the FSBL — 'the bundle verified' says nothing about the trust root

[Nicola-Ceornea]

Surfaced by an audit agent during the 2026-09-23 boot-proof work; verified in source.

fwsign/src/subcommands/sign.rs:66-77 reads --fsbl only to hand it to artifact_key::verify_artifact_bytes, i.e. a vendor-key provenance check on retained ELF sections. No FSBL hash is placed in the manifest. fwsign inspect confirms the manifest carries secure_len, ns_len, secure_hash, ns_hash and vendor_fpr — and no FSBL field.

Why this is worth an issue rather than a shrug. Invariant #10 makes the FSBL the entire post-sale trust root: it measures the active slots and renders the fingerprint, and its immutability is supposed to come from WRP + RDP-2, not from the signed manifest. That is a coherent design. The problem is what it means for evidence:

• A bundle that verifies proves nothing about which FSBL is on the part. Any statement of the form "we flashed the signed bundle, therefore the FSBL was X" is unfounded.
• During the screen-unit run I claimed stage-marker was off in the flashed FSBL. That claim is true, but it is backed by a local chain I happened to build (nm on the ELF -> elf-to-bin of that same ELF -> round-trip re-hash of the composed blob -> CubeProgrammer verify), not by anything in the signed artifact. Someone repeating the run without that chain would have only operator testimony.
• The WRP/RDP-2 gates that are supposed to supply this property are all still OPEN (invariant S-4: OPTIGA pre-ship lower-severity items — close in the same hardening branch as S-1/S-2/S-3 #10 lists them).

Not proposing the FSBL be added to the manifest — that may be wrong, since the FSBL is the verifier and a self-referential binding buys little. What is needed is a decision, recorded: either the release flow emits an FSBL measurement receipt alongside the bundle, or the docs state plainly that FSBL identity is established only by WRP+RDP-2 and by out-of-band measurement, so nobody infers it from a bundle signature.

[Nicola-Ceornea]

Decision recorded, and the gap is now demonstrated rather than argued

Landed in 17dc2ec2.

Demonstration

Preparing the hw-sha256 boot proof (#758) I needed to run the FSBL against a signed bundle without the signing key. The gap made that trivial, which is the clearest statement of the problem:

A newly built FSBL — different bytes, different size, hardware SHA-256 instead of software, built today — was flashed alongside the unchanged Sept-23 signed bundle on bench board 002f0023 30465002 2033314c. It booted, verified both images against that three-day-old manifest, and branched:

 3 SlotAImagesOk    1
 5 Branching        0
10 ImgSecureCmp     1
11 ImgNsCmp         1
   19 of 19 stages, MISSING: none

Nothing in the signed artifact objected, because nothing in it describes the FSBL.

Confirmed in source

• Bundle contents: manifest.bin, secure.bin, nonsecure.bin, measurement.txt, pubkey.bin, release.json, erc7730-status.bin — no FSBL.
• signed_preimage(fw_version, secure_hash, nonsecure_hash) — no FSBL field.
• Draft 1.1's proposed PQFW_V6 preimage has no FSBL field either, so the planned replacement does not close this.
• fwsign sign --fsbl reads the ELF only for artifact_key::verify_artifact_bytes and discards it.

The decision

Your framing holds and I am not proposing a manifest change. The FSBL is the verifier; binding it inside the manifest it verifies is circular, since an attacker who replaces the FSBL replaces the check with it.

So: option (b), plus as much of (a) as can be done without touching the quarantined release path.

docs/security/measured-boot.md now states under "What this does NOT defend against" that no claim about which FSBL is installed may be derived from bundle verification, and names the only two things that do establish it until WRP + RDP-2 close:

1. out-of-band measurement (fwmeasure vs a reproducible build, or reading the boot fingerprint off the panel);
2. the vendor-key chain.

The part that was operator testimony is now a command

Your text: "Someone repeating the run without that chain would have only operator testimony." That is now tools/verify-fsbl-identity.sh, wired as make verify-fsbl-identity FSBL_ELF_IN=... BUNDLE_DIR=.... It extracts .pqsigner.vendor_pubkey from the ELF, hashes it, compares against vendor fpr in measurement.txt, and prints the FSBL's own 8 words for comparison against a reproducible build. Read-only.

Controls, exit codes measured directly rather than through a pipe:

input	exit
the real boot-proof FSBL	0	vendor key MATCHES
dev-fixture FSBL vs real-key bundle	1	MISMATCH
non-FSBL ELF (no section)	1	refuses

Live result: today's FSBL carries ed51cd8a7fe1c395..., hashing to af8824ff2aa1d515... — the bundle's vendor fpr. Same vendor, unknown identity, which is the whole point.

Still open

The script says so itself, at the top and again on success: it proves shared vendor provenance only. Two FSBLs under the same key are indistinguishable to it — exactly the case my demonstration exercised. Closing that needs the release-side FSBL measurement receipt this issue proposes, which I have not implemented: fwsign/release packaging is quarantined pending candidate approval, and fwsign/tests/* currently sits uncommitted in the working tree, so changing the bundle format now would collide with unreviewed work.

Leaving open for that receipt. The evidence rule and the vendor-key check are done.