feat(keepkey): on-device dice entropy on ResetDevice, with tests

[BitHighlander]

Adds the diceEntropy flag to core.ResetDevice so a host can ask the device to collect dice rolls with its own button and fold them into the internal entropy before the seed is committed. The rolls never reach the host — that is the point: desktop-entered dice only help while the device's own randomness stays secret, so they are no defence against a compromised host combined with a weak device RNG.

The vault's create-wallet flow needs this; without it the dice step cannot ship.

The property that matters

Not that the flag can be set, but that ResetDevice.dice_entropy stays absent unless requested. The field only exists in firmware >= 7.15.0, and older firmware rejects a message carrying an unknown field — so setting it unconditionally would break wallet creation on every device already in the field.

reset-dice-entropy.test.ts pins that with five cases: set-when-requested, absent-when-omitted, absent-when-explicitly-false, a wire-format round trip (present-but-false is not the same as absent), and that the other reset fields still populate alongside it.

These were verified to fail for the right reason: replacing the guard with an unconditional setDiceEntropy(!!msg.diceEntropy) turns three of them red.

device-protocol pin

The feature branch pinned @keepkey/device-protocol at BitHighlander/device-protocol#dice-entropy-v1, which would have put a personal fork in the dependency chain of a published package. That is unnecessary — the same commit is already merged into keepkey/device-protocol on up/release-protocol, the branch the vault tracks — so this pins its current tip fbb483f1 on the canonical repo instead.

Also included

da50506b derives BIP-86 account xpubs with SPENDADDRESS. fsm_msgGetPublicKey picks xpub version bytes from the script type and only recognises SPENDADDRESS / SPENDP2SHWITNESS / SPENDWITNESS, so sending SPENDTAPROOT fails outright and BTC account discovery dropped Taproot entirely. P2TR is still sent on address and signing requests, where firmware does handle it. Ships with its own coverage in taproot.test.ts.

Testing

Full hdwallet-keepkey suite: 13 suites, 96 tests, all passing on the canonical device-protocol package.

[vercel]

The latest updates on your projects. Learn more about Vercel for GitHub.

Project	Deployment	Actions	Updated (UTC)
hdwallet-sandbox	Ready	Preview	Aug 11, 2026 12:50am

[BitHighlander]

Confirmed and fixed in b1b1420. Thanks — the premise the original guard rested on was simply wrong, and the consequence is worse than the comment implied.

Verified the claim

lib/transport/pb_decode.c:904 is /* No match found, skip data */ pb_skip_field(...). I checked the v7.14.1 tag directly rather than trusting current develop, and it is identical there — line 904, same skip. Unknown fields are skipped, not rejected.

So reset({ diceEntropy: true }) against pre-7.15 firmware succeeded, the device ignored the field, and the caller got an ordinary RNG-only seed believing dice rolls had been folded in. Silent downgrade of an explicitly requested security property, no error anywhere. The original comment asserting old firmware "would reject an unknown one" was the load-bearing mistake.

Fix

• supportsDiceEntropy() — public capability check, semver.gte(fw, "v7.15.0"), following the existing ethSupportsEIP1559() pattern, so callers can hide the option up front rather than discovering the problem at reset time.
• reset() throws before any transport.call, naming the offending version so the caller learns why instead of guessing.
• Fails closed: an unreadable/absent firmware version reports false. Assuming support when we cannot tell is the same bug in a different costume.

Coverage for the downgrade path

Four new cases, and the one that matters asserts no ResetDevice was sent — throwing after a successful reset would still have created the RNG-only wallet:

• throws instead of resetting when firmware predates v7.15.0, and nothing is sent
• names the offending firmware version in the error
• fails closed when the firmware version is unreadable
• still resets normally on old firmware when dice is not requested — the gate must not become a general old-firmware block

Plus a supportsDiceEntropy() truth table including the no-version case.

I verified these fail for the right reason: removing the gate restores the exact reviewed vulnerability and turns those three red while the other twelve stay green. 13 suites / 106 tests pass overall.

On the vault

You are right that it gates its UI — create-briefing routes past both security steps when diceSupported is false, so diceEntropy stays false on old firmware, and that gate fails closed on an unknown version. It was never exposed. But its comment carried the same false "older devices reject the unknown field" rationale, which invited someone to delete the gate as redundant; I corrected that separately so the gate reads as load-bearing.