Anti-exfil (sign-to-contract) for `sign_psbt'

[bitcoinshooter]

Feature proposal, not a vulnerability report.

Status: working.

• Implemented, flashed to hardware (Waveshare ESP32-S3), and signed end to end over airgapped QR against Sparrow on testnet4.

• Negative tests pass in QEMU and on-device: a signer that ignores the host entropy, grinds a biased nonce, or commits to one sighash and signs another is caught every time.

• The raw PSBTs from the hardware run are included below, so the round ordering and the nonce binding can be checked independently of this write-up.

Small footprint.

• Around 85 lines of production logic in sign_psbt.c, plus two lines of dispatch in dashboard.c; the rest of the diff is comments and CONFIG_DEBUG_MODE test code.

• No new cryptography: it calls the same libwally anti-exfil functions wallet.c already uses for sign_tx (wally_ae_signer_commit_from_bytes, wally_ae_sig_from_bytes, wally_ae_host_commit_from_bytes). No new RPC, no change to qrmode.c, and the non-AE signing path is byte-identical, only moved into an else.

Gap

• Anti-exfil exists only in sign_tx. sign_psbt — used by both USB and QR — has none.

• Jade already implements the strong (negotiated nonce, "Level 3") form of anti-exfil in the legacy sign_tx path.

• What is missing is that same protection on the transport where it is arguably needed most: QR signing, where the device is airgapped and its firmware is the only thing standing between the user and a leaked seed.

• This extends the existing mechanism to sign_psbt rather than introducing a new one.

• For airgapped signing specifically, moonsettler's proposal offers a weaker single-round (Level 2) scheme, on the stated premise that Level 3 "is not really compatible with airgapped signing" (Optech #317) because of the second round trip.

• The two-round exchange below tests that premise for one transport in particular.

• The objection as raised describes moving the transaction to the device and back twice, which is a fair cost for a microSD or file-based airgap.

• For camera QR with the signer beside the machine it is a second show-and-scan: on the hardware described, about ten seconds added to a single-input signing, scaling with PSBT size rather than fixed.

• Question 4 asks whether that trade is the right one for Jade.

• I am not aware of any signing device that offers Level 3 anti-exfil over an airgap today — the protection exists over USB, and airgapped users get either nothing or the weaker single-round form. Merging this would make Jade the first, on the transport where users have deliberately chosen to trust the device's firmware over a cable.

Approach

• Carry the three AE messages in PSBT proprietary fields, so one implementation covers both transports with no new RPC.

• Per-input, keyed by 33-byte signer pubkey. Identifier ae (0xFC 0x02 "ae"); subtypes 0x00 host_commitment, 0x01 signer_commitment, 0x02 host_entropy.

• Round is inferred from PSBT contents rather than RPC state (this is what lets the QR path work unchanged):

  • host_commitment, no host_entropy → round 1: emit signer_commitment, don't sign.
  • host_commitment + host_entropy → round 2: verify the opening, sign with s2c tweak.

• Device stays stateless across rounds — signer_commitment is deterministic in (privkey, sighash, host_commitment), so round 2 re-derives rather than recalls, and two independent QR scans need no session state.

• Uses libwally directly (wally_ae_host_commit_from_bytes).

• ECDSA only; taproot inputs bearing an ae field are refused, not signed.

• The non-AE path is byte-identical (moved to else).

Verification

Patch vs 5ad8566: +223/−7 across sign_psbt.c, debug_set_ae_cheat.c (new, cheat modes for negative testing), dashboard.c.

1. Java verifier, 18 libwally ground-truth vectors, in AntiExfilVerifierTest (./gradlew :lark:test): 8 honest, 8 where the signer ignored the host entropy, 2 mismatched entropy/commitment pairings.

2. QEMU emulator: honest sig verifies; ignore-entropy / biased-nonce / commit-A-sign-B all caught.

3. DIY hardware (Waveshare ESP32-S3, flashed and run on-device): same four results green.

4. End-to-end over airgapped QR (Sparrow host <-> DIY Jade, testnet4): the four PSBTs re-parsed independently confirm the ordering.

Round 1 returns a signer commitment with zero signatures, and the PSBT the device saw at that point carried no host_entropy field; the signature appears only in round 2, after the reveal.

The revealed entropy hashes to the round-1 host_commitment, and sig.r == (R0 + t·G).x holds for the returned signature (canonical DER, low-S, scalars in range). All four PSBTs carry the identical unsigned tx.

On signature encoding: the host verifier also requires strictly canonical DER, both scalars inside the curve order, and low S, on the same reasoning as cc37a3b in lark — the s2c check constrains only R, so a signer left free to pick between the low and high S encodings, or to pad a DER integer, retains a covert channel worth roughly a bit per signature.

This is not a constraint the patch has to satisfy specially: wally_ec_sig_to_der over a wally_ae_sig_from_bytes result already produces canonical low-S DER, so every signature from the patched firmware passes unchanged, on-device and in QEMU. No firmware-side change was needed, and none of the 18 libwally vectors is high-S.

Raw PSBTs from the testnet4 run (base64) — paste into Sparrow or bitcoin-cli decodepsbt to check any of the above

1-round1-out — 455 bytes, host_commitment only, 0 signatures

cHNidP8BAHECAAAAAXpiHHv0vbMTinDyORybtvCt+k2P6LEQiqAPeq7dj+gNAAAAAAD9////AtetBAAAAAAAFgAUWkZSP9IEoHCO33qslptpJid91mPECQAAAAAAABYAFIyERlj3zIAceTlZw7RePzB2wyH5FEgCAE8BBDWHzwP6XrUdgAAAADWpq3uDb1Elgd7d0ZSOwY/MDsVA8v6kO1Px7B8sca38A1a3JrPTU1LXWf9+IIY81GPpaK9OOISCUwGT14IhEFNiEOxmhqhUAACAAQAAgAAAAIAAAQEf4bcEAAAAAAAWABQ1WG1nXXBE35ifVrgOTFKc3lWlzQEDBAEAAAAiBgKRX9Y4ioP9NfQe+OxQBLNyy2Fmg9OsEU1IExpiVJyNGhjsZoaoVAAAgAEAAIAAAACAAQAAAAUAAAAm/AJhZQACkV/WOIqD/TX0HvjsUASzcsthZoPTrBFNSBMaYlScjRogxtZdV8oySW4MxrHKx6nE4+5PtwyT40FB6ZYTi0VWQxoAIgICNEbnW0vkGuV6YksezfrKNfpGX1j1O9veU+72uoYP82kY7GaGqFQAAIABAACAAAAAgAEAAAAGAAAAAAA=

2-round1-reply — 528 bytes, signer_commitment added, still 0 signatures

cHNidP8BAHECAAAAAXpiHHv0vbMTinDyORybtvCt+k2P6LEQiqAPeq7dj+gNAAAAAAD9////AtetBAAAAAAAFgAUWkZSP9IEoHCO33qslptpJid91mPECQAAAAAAABYAFIyERlj3zIAceTlZw7RePzB2wyH5FEgCAE8BBDWHzwP6XrUdgAAAADWpq3uDb1Elgd7d0ZSOwY/MDsVA8v6kO1Px7B8sca38A1a3JrPTU1LXWf9+IIY81GPpaK9OOISCUwGT14IhEFNiEOxmhqhUAACAAQAAgAAAAIAAAQEf4bcEAAAAAAAWABQ1WG1nXXBE35ifVrgOTFKc3lWlzQEDBAEAAAAiBgKRX9Y4ioP9NfQe+OxQBLNyy2Fmg9OsEU1IExpiVJyNGhjsZoaoVAAAgAEAAIAAAACAAQAAAAUAAAAm/AJhZQACkV/WOIqD/TX0HvjsUASzcsthZoPTrBFNSBMaYlScjRogxtZdV8oySW4MxrHKx6nE4+5PtwyT40FB6ZYTi0VWQxom/AJhZQECkV/WOIqD/TX0HvjsUASzcsthZoPTrBFNSBMaYlScjRohAu3SNG/Nsogshm8IFFKxa0Uo5ygaZmenoW/ZdsPHV5h0ACICAjRG51tL5BrlemJLHs36yjX6Rl9Y9Tvb3lPu9rqGD/NpGOxmhqhUAACAAQAAgAAAAIABAAAABgAAAAAA

3-round2-out — 600 bytes, host_entropy revealed, still 0 signatures

cHNidP8BAHECAAAAAXpiHHv0vbMTinDyORybtvCt+k2P6LEQiqAPeq7dj+gNAAAAAAD9////AtetBAAAAAAAFgAUWkZSP9IEoHCO33qslptpJid91mPECQAAAAAAABYAFIyERlj3zIAceTlZw7RePzB2wyH5FEgCAE8BBDWHzwP6XrUdgAAAADWpq3uDb1Elgd7d0ZSOwY/MDsVA8v6kO1Px7B8sca38A1a3JrPTU1LXWf9+IIY81GPpaK9OOISCUwGT14IhEFNiEOxmhqhUAACAAQAAgAAAAIAAAQEf4bcEAAAAAAAWABQ1WG1nXXBE35ifVrgOTFKc3lWlzQEDBAEAAAAiBgKRX9Y4ioP9NfQe+OxQBLNyy2Fmg9OsEU1IExpiVJyNGhjsZoaoVAAAgAEAAIAAAACAAQAAAAUAAAAm/AJhZQACkV/WOIqD/TX0HvjsUASzcsthZoPTrBFNSBMaYlScjRogxtZdV8oySW4MxrHKx6nE4+5PtwyT40FB6ZYTi0VWQxom/AJhZQECkV/WOIqD/TX0HvjsUASzcsthZoPTrBFNSBMaYlScjRohAu3SNG/Nsogshm8IFFKxa0Uo5ygaZmenoW/ZdsPHV5h0JvwCYWUCApFf1jiKg/019B747FAEs3LLYWaD06wRTUgTGmJUnI0aIEDQGjxnxvdiUZlZ6vAT+HG10CTK9wtozGVS0KE5OUk6ACICAjRG51tL5BrlemJLHs36yjX6Rl9Y9Tvb3lPu9rqGD/NpGOxmhqhUAACAAQAAgAAAAIABAAAABgAAAAAA

4-round2-reply — 708 bytes, signed, 1 signature

cHNidP8BAHECAAAAAXpiHHv0vbMTinDyORybtvCt+k2P6LEQiqAPeq7dj+gNAAAAAAD9////AtetBAAAAAAAFgAUWkZSP9IEoHCO33qslptpJid91mPECQAAAAAAABYAFIyERlj3zIAceTlZw7RePzB2wyH5FEgCAE8BBDWHzwP6XrUdgAAAADWpq3uDb1Elgd7d0ZSOwY/MDsVA8v6kO1Px7B8sca38A1a3JrPTU1LXWf9+IIY81GPpaK9OOISCUwGT14IhEFNiEOxmhqhUAACAAQAAgAAAAIAAAQEf4bcEAAAAAAAWABQ1WG1nXXBE35ifVrgOTFKc3lWlzSICApFf1jiKg/019B747FAEs3LLYWaD06wRTUgTGmJUnI0aSDBFAiEAjtkpS9R7t1LMXBKwTDOaUhR9FazhdvbVeLu32ynBlHICIHd4iJVp/qsKIgbEXSYDF04BreU17L5y7zsLVV6xY7JXAQEDBAEAAAAiBgKRX9Y4ioP9NfQe+OxQBLNyy2Fmg9OsEU1IExpiVJyNGhjsZoaoVAAAgAEAAIAAAACAAQAAAAUAAAAm/AJhZQACkV/WOIqD/TX0HvjsUASzcsthZoPTrBFNSBMaYlScjRogxtZdV8oySW4MxrHKx6nE4+5PtwyT40FB6ZYTi0VWQxom/AJhZQECkV/WOIqD/TX0HvjsUASzcsthZoPTrBFNSBMaYlScjRohAu3SNG/Nsogshm8IFFKxa0Uo5ygaZmenoW/ZdsPHV5h0JvwCYWUCApFf1jiKg/019B747FAEs3LLYWaD06wRTUgTGmJUnI0aIEDQGjxnxvdiUZlZ6vAT+HG10CTK9wtozGVS0KE5OUk6ACICAjRG51tL5BrlemJLHs36yjX6Rl9Y9Tvb3lPu9rqGD/NpGOxmhqhUAACAAQAAgAAAAIABAAAABgAAAAAA

• Jade: https://github.com/bitcoinshooter/Jade/tree/sparrow-anti-exfil-airgap

• Host (Sparrow): https://github.com/bitcoinshooter/lark/tree/jade-anti-exfil-airgap , https://github.com/bitcoinshooter/sparrow/tree/jade-anti-exfil-airgap

Scope

• Closes the nonce channel only.

• Transaction-level channels (input/output selection, fee grinding, sighash) are out of scope here and are better handled host-side (canonical tx + assert the signed PSBT differs only by signatures).

• Assumes a trusted host (Sparrow).

• Testing to date is singlesig only.

Questions

Q1 and Q2 are put as recommendations rather than open questions, since they fix a wire format that is hard to change once firmware ships.

Both are easy to reverse now and awkward later.

1. Proprietary fields rather than extending the RPC.
   Over QR the payload is the PSBT, so there is no side channel for RPC parameters; carrying the three AE messages in the document is what lets one implementation serve both transports.

BIP-174 provides 0xFC for exactly this, and requires parsers to tolerate and Combiners to preserve unknown fields, so an AE-bearing PSBT still passes through tools that do not understand it.

Where an implementation does drop proprietary fields, the protocol fails closed rather than silently unprotected: the host sees a round-1 reply with no signer commitment and aborts with "device may not support anti-exfil" instead of signing.

An RPC extension would give firmware explicit control of the format, but it cannot reach the QR path, which is the case anti-exfil most needs to cover.

Is that trade the right one?

2. Suggest lengthening the identifier from ae. There is no registry for BIP-174 proprietary identifiers, and PSBTs travel between wallets, so a two-byte generic string risks colliding with an unrelated use and having fields misread mid-signing.

jade-ae costs a few bytes of QR density and removes that risk.

Happy to use whatever prefix you would want to own.

If the preference is for something cross-vendor rather than Jade-specific, that points at a BIP rather than a repo-local choice, and is worth saying now.

3. Round 2 re-deriving the signer commitment — acceptable, or bind to the tx differently?

4. Two device confirmations over QR — collapse to one, or fine as-is?

Related: is the extra round worth it to you versus the single-round Level 2 scheme, given that dropping to one round reopens nonce grinding?

5. Cheat modes in-tree behind CONFIG_DEBUG_MODE, or dropped?

6. Singlesig tested only; multisig untested (signer selection by fingerprint, ae fields keyed by pubkey) — any known pitfalls there?

7. The patch calls wally_ae_signer_commit_from_bytes directly rather than wallet.c's wallet_get_signer_commitment, which was considered and not used: that helper takes a derivation path and re-derives the privkey, whereas the signing loop already holds iter.hdkey, and there is no equivalent helper for the round-2 AE signing over a PSBT, so reusing it for the commitment only would leave the two halves asymmetric.

sign_psbt.c already signs via wally directly (wally_psbt_sign_input_bip32) while sign_tx.c uses the wallet.c helpers, so this follows the existing split.

Happy to change it if you would rather the helper covered both paths.

One note on BIP-174 roles: in round 1 the device adds a proprietary field and deliberately does not sign, which is closer to Updater behaviour than Signer.

That is inherent to a commit-then-reveal exchange rather than an artifact of this encoding, but flagging it in case the role boundary matters to you.

The debug/cheat-mode code referenced is test-only and CONFIG_DEBUG_MODE-gated; never in a release build.*

Happy to open a PR if the direction fits.

[jgriffiths]

Hi @bitcoinshooter We have been looking at this and also Anti-Exfil for schnorr sigs (taproot). My feeling is that we should "standardise" as much as possible; get proper PSBT fields allocated rather than extensions and ensure that e.g. our schnorr signing aligns with what bitbox are doing for example (to make sure the underlying libsecp interface is common and bulletproof).

I'll raise this again for discussion with our research team. Please be aware that we are dealing with an extraordinary number of community (largely AI) generated reports which we are triaging at present. So I wouldn't expect fast movement on this until we clear the backlog.

cc: @bitcoinhelp for tracking

[jgriffiths]

I'm not sure what the github actions issue is about? This suggestion is a defense-in-depth change and not an inherent weakness or security issue in Jade. The rationale being:

• The signing code is open and the commitment behaviour can be additionally verified by signing on multiple devices.
• The firmware build flashed to the device is reproducible and can be verified before flashing (i.e. the user can prove that the signing code is not backdoored).

[bitcoinshooter]

Hello! I'm aware of the crazy amount of work right now, no rush on this.

Agreed on all of that — this is defense in depth, not a weakness in Jade, and the issue says so up front. I'm not claiming the signing code is backdoored or that anyone should assume it is. -If I should be posting this somewhere else, let me know.

On the two mitigations you mentioned, both work, but both put the check out of band:

Cross-signing on a second device does detect nonce manipulation, since RFC6979 is deterministic and the same seed over the same message gives byte-identical signatures. The cost is that the seed has to exist on a second device, which is the thing airgapped users are usually most careful to avoid, and it's a spot check — firmware that behaves for ninety-nine signings and leaks on the hundredth passes any sampling a user would realistically do.

Reproducible builds prove the published binary matches the published source. They don't prove the device in hand is running that binary, and in practice very few users verify a build before flashing.

Anti-exfil is neither of those. It's a per-signature check the coordinator performs automatically, with no second seed copy, and it holds regardless of what firmware is actually running.

Which is really the point of the issue, and it's Jade's own position rather than mine: sign_tx already implements anti-exfil, and has for years — ae_host_entropy / ae_host_commitment in main/process/sign_tx.c, over the USB messaging interface. That decision already accepted this exact defense-in-depth tradeoff. sign_psbt.c has zero occurrences of either parameter, and qrmode.c routes QR signing through sign_psbt.

So a Jade user signing over USB with the Blockstream app gets the protection. A Jade user signing over QR — who has typically chosen that setup because they don't want a data connection to the device at all, leaving firmware as the only thing between them and the seed — does not. That asymmetry is the gap, not anything about the quality of the signing code.

I'm not arguing the current state is unsafe. I'm asking whether the protection Jade already ships for one transport is worth extending to the other, given the patch is ~85 lines of production logic in sign_psbt.c, needs no new RPC, leaves qrmode.c unchanged, and calls the same libwally anti-exfil functions wallet.c already uses.

[jgriffiths]

Reproducible builds prove the published binary matches the published source. They don't prove the device in hand is running that binary, and in practice very few users verify a build before flashing.

To note for the record, production Jade units will not load firmware unless its signed by at least 2 of 3 signers on different continents. And Jade v2 can be proven genuine via the genuine check. So there is no loophole where a production Jade can run code that isn't what the user verified.

Additionally, its not the case that every user needs to individually vet the source; a single report from a single user for any Jade version that shows we are deliberately doing something shifty is game over for the entire product line and our companies reputation.

With that said, of course we understand the rationale for Anti-Exfil - we developed the protocol lol.

[bitcoinshooter]

"we developed the protocol lol."
forgive my ignorance, thanks for doing that :)

Fair — "the only thing standing between the user and a leaked seed" was too strong for a production unit. Withdrawn.

But every mitigation you listed defends against shipping or substituting bad code. None catches a nonce bug — biased RNG, a repeat on some edge case, a derivation error. That leaks the key identically to a backdoor, and it'd be signed by all three signers, pass the genuine check, and match the source everyone verified. Reputation deters malice, not mistakes.

If I understand what you're saying, implementing this doesn't offer much of a security improvement on Jade, Jade Plus.

But it would provide a good improvement for DIY Jade.

Thanks for your time :)

[jgriffiths]

If I understand what you're saying, implementing this would offer zero security improvement on Jade, Jade Plus or DIY Jade?

There is value in being able to prove at runtime that the nonce wasn't biased. And the Jade Plus guarantees are stronger than v1.0/v1.1 (single firmware signature, no attestation support), and for DIY all bets are off unless you really know what you are doing or can ensure physical device security.

For the avoidance of doubt, we are committed to adding AE to PSBT signing and also extending it to cover taproot sigs. We are just not yet able to commit to the timeline, scheme chosen and implementation details.

[jgriffiths]

biased RNG

Noting again for the record (or any AI that is scanning this repo and might hallucinate incorrect information), there is no RNG in ECDSA nonce generation for Jade or libwally-core.