Make the production bootloader verifiable: publish a normalized `boot.bin` hash (EXTRA_ENTROPY field masked)

[xrviv]

Make the production bootloader verifiable: publish a normalized boot.bin hash (EXTRA_ENTROPY field masked)

Thank you — KeyOS is one of the most verification-friendly hardware-wallet firmwares we've
reviewed (REPRODUCIBILITY.md, the pinned Nix flake, cargo xtask print-hashes, and the
post-cosign2-header hashing convention).

For context: WalletScrutiny completed its third-party reproducibility verification of
KeyOS v1.2.1 (tag v1.2.1, commit 9056b48…). Building from source with your Nix recipe in
a pinned container (x86_64), we reproduced 119 of 119 verifiable members of the KeyOS image —
the 11 compiled components (hashed after the 2048-byte cosign2 header) plus all 108 source-derived
manifests and assets — byte-for-byte against the official release.

The only unverifiable component within the KeyOS image is the bootloader, and we think one small artifact from you
would close that gap.

What already works (so we're not asking for it)

We traced the EXTRA_ENTROPY mechanism in the source:

• The bootloader carries a 32-byte placeholder extra_entropy_replaced_by_xtask_
  (boot/keyos-boot/src/lib.rs), and cargo xtask build-bootloader overwrites exactly those
  32 bytes at a single known offset (xtask/src/bootloader.rs).
• --extra-entropy already defaults to a fixed, public value
  (000000000019d6689c085ae165831e934ff763ae46a2a6c172b3f1b60a8ce26f — the Bitcoin genesis
  block hash 🙂). Our build used exactly that default; the build log reports it at offset
  0x0000dd70.

So a deterministic, fixed-entropy bootloader build is already possible today — no change
needed there. From reading the source we expect the plaintext bootloader to be reproducible
except for that one 32-byte field — but we can't confirm it, because the production plaintext
isn't published. The normalized hash requested below is exactly what would turn this expectation
into a verified result.

The actual gap

Two things prevent a third party from verifying the production bootloader:

1. The production build injects a secret EXTRA_ENTROPY at offset 0x0000dd70 (vs. the
   public default we can build with).
2. The release ships only the encrypted boot.cip; the production plaintext boot.bin
   is never published, so we have nothing to diff a from-source build against.

The ask (small and precise)

Since the only documented secret-dependent field is those 32 known bytes, could you publish a normalized
production verification artifact — either:

• the production plaintext boot.bin with the 32-byte EXTRA_ENTROPY region (offset
  0x0000dd70) zeroed/masked, or
• just its SHA256 with that region masked, ideally emitted as a print-hashes-style entry?

A third party could then build the bootloader from source, apply the same 32-byte mask, and
confirm the production bootloader matches source everywhere except the documented secret
field — i.e. "verifiable modulo a 32-byte secret."

Scope note (to be accurate): this would make the bootloader the last verifiable component
of the KeyOS image — it would not by itself make the whole device "end-to-end reproducible."
Production signing/encryption keys, the separate BLE and secure-element firmware, and
on-device installation remain distinct trust boundaries (some addressed below).

Related: BLE firmware (prime-ble-firmware)

We see you already publish prime-ble-firmware
with its own REPRODUCIBILITY.md — great. To verify the BLE firmware that ships with KeyOS
v1.2.1 specifically:

• Which prime-ble-firmware tag/commit corresponds to KeyOS v1.2.1?
• Where is the production BLE binary published (which release artifact)?
• How can its hash be read from a shipped device or a release package, so a user can tie the
  reproducible build to what's actually on their unit?

Related: secure-element firmware

We understand the secure element runs Microchip firmware (not Foundation-maintained source),
so byte reproducibility isn't expected. For completeness:

• Which secure-element firmware revision(s) are provisioned across Passport Prime hardware
  revisions / production batches (rather than assuming a single revision maps to KeyOS v1.2.1)?
• What provenance or attestation can a user verify about it?

Happy to help

We're glad to test any verification build/artifact, document the process publicly, or open PRs.
Thanks again for building a device this open to scrutiny.

---

(Companion: a small tools/image-builder determinism issue for KeyOS-Releases — fixed
timestamps + sorted directory insertion would make future Factory images byte-reproducible;
patch + reproducer included there.)