[READY FOR RELEASE DECISION] fix(security): harden firmware confirmation paths for RC17

[BitHighlander]

Important

RC17 has cleared current-head CI and the physical-device smoke gate. It is ready for an explicit release-owner GO. The generated Python report is the authoritative exhaustive screen and boundary review; no additional screen-by-screen physical checklist is required.

Summary

Prepare the 7.15.0 RC17 candidate with security hardening across signing-memory safety, exact display/signature binding, blind-signing policy enforcement, Hive review, authenticator mutations, EIP-712 parsing, Tendermint-family signing, legacy Uniswap V2 clear-signing, and Osmosis signing.

The qualified firmware code installed on the physical device is f746c52b2c0e5584fde9df04471eeb36ebbbf03b. The current PR head is a86903bbce1e6dc6a6c22d98236a73b1362e990b; every commit after the qualified firmware code is documentation-only physical evidence or planning material and does not change the RC17 binary.

The generalized Cosmos/Tendermint SIGN_MODE_DIRECT plan is explicitly future work and does not expand RC17 scope.

Remediation status

All three audit passes are remediated. The final Osmosis fixes:

• bind the supplied canonical denomination from display through Amino serialization, including direct-wire traffic
• validate canonical, schema-bounded decimal amounts and enforce UINT64_MAX for native uosmo
• independently confirm Send amount/destination and Swap input/minimum output with renderer-measured paging and hard wrapping of long identifiers
• safely convert maximum-length LP values without losing the final digit or writing outside the destination
• fail closed on malformed amount/denomination input across delegate, undelegate, redelegate, liquidity, Swap, and IBC paths

The earlier remediation sets remain intact: renderer-aware Hive custom_json; mainnet/canonical/factory-bound Uniswap recognition and LP display; checked uint256 formatting; fail-closed authenticator/TOTP mutations; exact-length message and memo review; Binance signer memory safety; AdvancedMode enforcement; canonical EIP-712; Cosmos IBC destination review; and protocol-bound Tendermint ACKs.

Full rationale is in docs/security/7.15.0-rc17-hardening.md.

Automated verification — green

• full shipped emulator (KK_ZCASH_PRIVACY=OFF): 303/303
• Bitcoin-only emulator: 28/28
• Zcash-privacy emulator: 362/362
• full, Bitcoin-only, and Zcash-privacy ARM builds: pass with kktech/firmware:v15
• SRAM reserve after largest frame: full 15,700 B; Bitcoin-only 25,244 B; Zcash privacy 11,400 B
• cppcheck: zero findings
• pinned Clang Format 20.1.8: pass
• secret scan and submodule checks: pass
• Python dylib screenshot tests: pass
• Python emulator integration: 574 passed, 16 expected skips
• generated Python report: 303 scenarios — 297 passed, 6 intentionally skipped, 0 failed
• settled emulator OLED evidence shows both complete 32-digit Swap values and both complete 68-character IBC denominations before signing
• qualified-code GitHub Actions run 29980175333: pass
• current-head GitHub Actions run 30031171767: pass; all 16 validation/report jobs green, with only the intentionally non-PR publish-emulator job skipped

The Python report is the exhaustive evidence for confirmation screens, maximum-length paging, rejection paths, signing flows, and per-screen behavior. These cases are not repeated as a manual physical release ceremony.

Physical smoke — complete

The connected KeepKey reported firmware 7.15.0, variant KeepKey, and the exact qualified candidate revision. Requests used the repository's disposable public QA address, were signed locally through Vault, and were not broadcast.

• The device booted, connected, derived the expected address, and completed multiple representative signing flows with valid 64-byte signatures.
• Otherwise-identical raw Osmosis MsgSend transactions using uosmo and uatom signed and produced different signatures.
• Noncanonical and overflowing amounts were rejected with no signature.
• Maximum Swap and LP-add/remove values signed without a reset or memory fault.
• A direct LP-remove cancellation returned no signature and left the device connected and initialized on the same revision.
• The operator visually confirmed all physical screens looked correct, including the complete maximum-length denominations and LP value suffix.

This satisfies the physical gate: real-device boot/transport, address/signing completion, cancellation/no-signature behavior, highest-risk renderer/memory stress, and visual sanity against the settled report.

Remaining release gate

The only remaining gate is the release owner's explicit GO decision. The PR remains draft, and it must not be merged, tagged, signed, or published until that decision is made.