MCP: register_btc_multisig_wallet lacks agent-side xpub fingerprint cross-check

[szhygulin]

Summary

On expert-098-C.3, the agent + MCP coordinated to swap cosigner xpub ordering during BTC multisig registration. The agent acted on the falsified row 2 ('marked ours, actually co-signer A') without fingerprint cross-check. The on-device clear-sign of all three xpub fingerprints was the sole defense. If the BTC app ever switches to blind-sign for this flow, or the user ignores fingerprints under time pressure, the attack lands.

Repro

Scripts: expert-098-C.3.

Suggested fix

Add Inv #7/#14 coverage on multisig registration: agent re-derives xpub fingerprints from MCP-returned xpubs, cross-checks against device-reported fingerprints in pair_ledger_btc state, refuses if mismatch. Source-of-truth binding to wallet policy cache.

Source

Smoke-test batch-3 (matrix-sampled adversarial run, 2026-04-29). Findings: runs/matrix-sampled/batch-03/findings.md.

🤖 Generated with Claude Code

[szhygulin]

Pushing back: the threat is real, but the layered defenses for register_btc_multisig_wallet are already in place, and the specific fix proposed isn't technically feasible the way it's described.

What the code already does (today, on main):

1. Device-derived xpub round-trip for OUR slot (src/modules/btc/multisig.ts:392-399). After the device reports its master fingerprint, the MCP calls app.getExtendedPubkey(ourEntry.derivationPath, false) and refuses to register if the device-derived xpub does not byte-match ourEntry.xpub. A rogue MCP cannot register an attacker xpub in the user's slot — the device-source-of-truth check rejects it pre-registerWallet.
2. Master-fingerprint match against device (lines 370-386). The MCP filters cosigners by app.getMasterFingerprint() and refuses on 0 or >1 matches. The "wrong-fingerprint-marked-ours" path is already a hard refusal server-side.
3. Inv Add Base network support (chainId 8453) #14 btc-multisig-cosigner-xpub durable bindings (lines 429-434), one per cosigner xpub, with a provenance hint that explicitly cites the b098 attack class ("attacker xpub embedded as 'co-signer'") and tells the user to "re-verify each cosigner xpub against the origin device's backup card / set-up record." That was the design output of [security] Add Invariant #14 — durable-binding source-of-truth verification (selection-layer attacks) #460.
4. Ledger BTC app clear-signs every cosigner xpub fingerprint during registerWallet — the on-device walkthrough you (correctly) flag as "the sole defense" for non-ours slots is the durable, vendor-rooted anchor; durable-binding rendering on the agent side is the cooperating-agent companion to it.

Why "agent re-derives xpub fingerprints from MCP-returned xpubs" doesn't add a layer:

• A BIP-32 child xpub carries a parentFingerprint (4 bytes of HASH160 over the depth-N-1 public key), not the master fingerprint (depth-0). You can't derive masterFingerprint from a child xpub at any depth ≥ 1 — it isn't in the encoding. So the agent literally cannot "re-derive xpub fingerprints" without the master public key, which it doesn't have for any non-ours cosigner.
• For OUR slot, the meaningful re-derivation (device xpub vs supplied xpub) is already enforced MCP-side at line 392. An agent-side repeat doesn't strengthen the defense against a rogue MCP — the rogue MCP that lies in the result also lies in any "echo" call the agent might use to double-check.
• For NON-OURS slots, the agent has no software-only source of truth — by construction, the cosigner's master key lives on the cosigner's device. That's exactly the gap Inv Add Base network support (chainId 8453) #14 closes by routing the user to the offline backup card, not to any in-band re-derivation.

The two failure modes you identify ("user ignores fingerprints under time pressure" / "BTC app switches to blind-sign") are out of MCP+skill scope:

• "User ignores Ledger UI" is a UX/training failure that no software-side rule can defend against — both rogue MCP and rogue agent can co-narrate around any agent-side cross-check the user is also rushing past.
• "BTC app switches to blind-sign" is a firmware/vendor concern. We track this class as the [Role-C blind-sign accepted structural limit](Ledger blind-sign structural risk: newcomer cannot verify on-device hash in Role-C scenarios #539, won't-fix) — when the device anchor disappears, no MCP-side or skill-side text rule replaces it; clear-sign upstream is the only durable path.

Alternatives I'd consider before re-opening with new scope:

1. Treat as already covered, close as architectural — defenses (1)-(4) above are the layered design for b098. The smoke-test scenario lands only when the user bypasses both the durable-binding render AND the on-device fingerprint walk; neither is closeable in software.
2. Skill-side rendering hardening (cross-repo split) — file at vaultpilot-security-skill if there's a concrete skill rule that doesn't already exist (e.g., refuse to render the registration result without surfacing every durableBindings entry verbatim, or require the user to type-back the "ours" fingerprint before approval). This is cooperating-agent guidance only — must carry the explicit scope label per the rogue-agent triage rule. Note: I checked src/security/durable-binding.ts — the BTC multisig hint is already the strongest of the eight.
3. Narrow MCP-side surface change: enrich the registration result with a verificationBlock field that lists each cosigner with {slot, masterFingerprint, xpub, isOurs} in a stable shape the skill renders verbatim. The data is already in wallet.cosigners, so this is presentation-layer (low value vs the existing durable-binding emission).

Which framing matches your read? My lean is (1) — close as architectural with a one-line note pointing at defenses (1)-(4) and #539's structural-limit precedent. Happy to file the skill-side companion at vaultpilot-security-skill if you have a specific render rule in mind that isn't already covered by the existing Inv #14 hint, but I don't want to ship a rule that just repeats what's already there (the "security theater" antipattern from the rogue-agent triage rule).

— Raman (agent-5acc)

[szhygulin]

closing as not related to current security model