Re: [bitcoin-dev] Proposal: Bitcoin Secure Multisig Setup

[Robert Spigler via bitcoin-dev]

I don't quite understand your NACK.

The following are measures you say we should take as best practices, which I 
believe are all implemented:

>A) We should accept that users must to backup their multisig account maps 
>(descriptor with only xpubs) along with their cosigner key material to be able 
>to recover funds.

BSMS requires that the descriptor persist in storage and be able to be 
displayed when requested by the user. It is already industry standard that the 
same apply to cosigner key material. Backing up both is good practice. (My BIP 
for a new key hierarchy enforces this as well 
(https://github.com/bitcoin/bips/pull/1089))

>B) Cosigner wallets and transaction coordinator services should not share the 
>master xpub
Again, check out my updated hierarchy for multisignature wallets, which 
enforces this and works very well with BSMS.

>C) In many current wallets, the master xpub fingerprint is required
I am confused by this - the descriptor language standardizes the master xpub 
fingerprint in the key origin information?

>E) Transaction coordinators should send the cosigner "policy"
There is no cosigner "policy" in this standard, but the same checks are 
implemented (N unique key records, key is included in descriptor, plus valid 
MAC, valid signatures, valid checksum, etc).

>F) Transaction coordinators should also send the final "account map" to all 
>the cosigner wallets
This is done

Robert Spigler

Personal Fingerprint: BF0D 3C08 A439 5AC6 11C1 5395 B70B 4A77 F850 548F

‐‐‐ Original Message ‐‐‐
On Monday, April 12, 2021 2:45 PM, Christopher Allen via bitcoin-dev 
 wrote:

> Though I am ACK on that we need to solve the problem of xpub privacy and 
> reuse, I'm NACK on this solution. It is currently too complex and doesn't 
> really solve the problem.
>
> I believe that the ultimate solution will be some form of multi-round 
> cryptographic commitment scheme, and as musig threshold signatures with 
> Taproot/Schnoor also require multi-round scheme, we should start thinking now 
> about how maybe we can leverage that work to address this problem as well. 
> However, I'm not a cryptographer and don't have a specific solution in this 
> area to offer.
>
> In the meantime, there are some possible measures we can take as new best 
> practices. This is not a formal list, and I'm open to other suggestions, but 
> each are currently relatively easy and are functional with some existing 
> wallets that CAN support state. Let us get it right with stateful wallets, 
> then we can return back to better best practices for stateless wallets like 
> Trezor, Ledger, etc.
>
> A) We should accept that users must to backup their multisig account maps 
> (descriptor with only xpubs) along with their cosigner key material to be 
> able to recover funds. In the Airgap Community we make this very easy with a 
> simple UR code that works efficiently as a QR. I personally keep multiple 
> copies of this account map in multiple locations, as it is less of a risk 
> (mostly privacy) if one of the locations is compromised.
>
> B) Cosigner wallets and transaction coordinator services should not share the 
> master xpub, only the derived co-signer xpubs required for that specific 
> account. Currently too many libraries, wallets and coordinators only function 
> if they get the master xpub — these should be updated to not require them.
>
> C) In many current wallets, the master xpub fingerprint is required — that 
> master fingerprint is also a privacy risk and should not be used. For 
> instance, the current practice of offering what the Airgap Community calls a 
> `crypto-hdkey` [604b93f2/48'/1'/0'/2'] with the master fingerprint root, 
> could instead be to only offer a single parent fingerprint [f93749a7/2'] from 
> that grandparent master key. Thus different fingerprints can be offered for 
> each account, and only the signer knows the actual master fingerprint and its 
> children.
>
> D) Given C, when creating a new multisig account, a transaction coordinator 
> may request a specific master fingerprint and/or a fixed 48' derivation xpub 
> from a cosigner wallet, but these are only hints. If it gets back a different 
> fingerprint or derivation, it should accept it. In the case of the Airgap 
> Community's specifications, in our "crypto-request" we actually specifically 
> allow for wildcard requests which makes this easy and explicit. Yes, only 
> stateful signers can know to return an xpub something other than the 
> fingerprint and m/48'/1'/0'/2' default, but a transaction coordinator should 
> accept it if it receives it.
>
> E) Transaction coordinators should send the cosigner "policy" (basically the 
> multisign descriptor without any keys in it) along with any request to derive 
> a new xpub for that new account. Stateful wallets can use this policy to know 
> later if they are asked to sign a PSBT that does not match this policy.
>
> F) Transaction coordinators should also send the final "account 

Re: [bitcoin-dev] Proposal: Bitcoin Secure Multisig Setup

[Christopher Allen via bitcoin-dev]

Though I am ACK on that we need to solve the problem of xpub privacy and
reuse, I'm NACK on this solution. It is currently too complex and doesn't
really solve the problem.

I believe that the ultimate solution will be some form of multi-round
cryptographic commitment scheme, and as musig threshold signatures with
Taproot/Schnoor also require multi-round scheme, we should start thinking
now about how maybe we can leverage that work to address this problem as
well. However, I'm not a cryptographer and don't have a specific solution
in this area to offer.

In the meantime, there are some possible measures we can take as new best
practices. This is not a formal list, and I'm open to other suggestions,
but each are currently relatively easy and are functional with some
existing wallets that CAN support state. Let us get it right with stateful
wallets, then we can return back to better best practices for stateless
wallets like Trezor, Ledger, etc.

A) We should accept that users must to backup their multisig account maps
(descriptor with only xpubs) along with their cosigner key material to be
able to recover funds. In the Airgap Community we make this very easy with
a simple UR code that works efficiently as a QR. I personally keep multiple
copies of this account map in multiple locations, as it is less of a risk
(mostly privacy) if one of the locations is compromised.

B) Cosigner wallets and transaction coordinator services should not share
the master xpub, only the derived co-signer xpubs required for that
specific account. Currently too many libraries, wallets and coordinators
only function if they get the master xpub — these should be updated to not
require them.

C) In many current wallets, the master xpub fingerprint is required — that
master fingerprint is also a privacy risk and should not be used. For
instance, the current practice of offering what the Airgap Community calls
a `crypto-hdkey` [604b93f2/48'/1'/0'/2'] with the master fingerprint root,
could instead be to only offer a single parent fingerprint [f93749a7/2']
from that grandparent master key. Thus different fingerprints can be
offered for each account, and only the signer knows the actual master
fingerprint and its children.

D) Given C, when creating a new multisig account, a transaction coordinator
may request a specific master fingerprint and/or a fixed 48' derivation
xpub from a cosigner wallet, but these are only hints. If it gets back a
different fingerprint or derivation, it should accept it. In the case of
the Airgap Community's specifications, in our "crypto-request" we actually
specifically allow for wildcard requests which makes this easy and
explicit. Yes, only stateful signers can know to return an xpub something
other than the fingerprint  and m/48'/1'/0'/2' default, but a transaction
coordinator should accept it if it receives it.

E) Transaction coordinators should send the cosigner "policy" (basically
the multisign descriptor without any keys in it) along with any request to
derive a new xpub for that new account. Stateful wallets can use this
policy to know later if they are asked to sign a PSBT that does not match
this policy.

F) Transaction coordinators should also send the final "account map" to all
the cosigner wallets as a best practice as well. This would replace the
temporary "policy" in D. If a PSBT request to sign using a key doesn't
match the original account map, the cosigner wallet can reject it.

These best practices don't solve the problem with stateless wallets like
Trezor, but they are possible now with the new generation of multisig
hardware and software wallets, such as Foundation Devices, CoboVault,
Sparrow, Bluwallet and my Gordian reference wallet tools. We have available
NOW working interoperable specifications, reference code, and example apps
that support these best practices, and some are already supported by
multiple wallets in the Airgapped Wallet Community hosted by Blockchain
Commons at https://github.com/blockchainCommons/airgapped-Wallet-Community.

I've put a copy of this rough proposal in our Airgapped Wallet Community
discussion area if you have suggestions or alternative best practices.

[Initial proposal for best practice to avoid XPUB reuse in multisig account
creation](
https://github.com/BlockchainCommons/Airgapped-Wallet-Community/discussions/53
)

-- Christopher Allen, Blockchain Commons
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] Proposal: Bitcoin Secure Multisig Setup

[Hugo Nguyen via bitcoin-dev]

Hello Salvatore,

On Mon, Apr 12, 2021 at 8:03 AM Salvatore Ingala 
wrote:

> Hi Hugo,
>
> First of all, thank you for the impressive work on leading the
> standardization efforts!
>
> I believe one ought to more clearly distinguish the "Signer" (as in: one
> of the parties in the multisig setup), from the "*Signing device*" (which
> is likely a hardware wallet).
>

Actually, in the current spec, a "Signer" is *any software/hardware that
possesses the private keys and can sign using those keys* -- it doesn't
have to be hardware. "Signer" does not mean the human user. I will clarify
the definition and clear up any ambiguous language in the spec. Thanks for
bringing this to my attention!


> BSMS defines a "Signer" as "a participating member in the multisig",
> therefore a person/entity who is likely using both a hardware wallet and
> some BSMS-friendly software wallet (e.g. the next version of Specter
> Desktop).
>

As mentioned above, "Signer" does not refer to the user or any entity that
does not have the private keys / signing capability.


> It is therefore relevant to discuss which parts of the BSMS mechanism are
> implemented in the Signer's software wallet, and which should be in the
> Signer's hardware wallet.
> From the discussion, it appears to me that different people might have
> different expectations on what the signing device/HWW should do, so I would
> like to comment on this point specifically (while I reckon that it mostly
> falls within the realm of concerns #4 and #5 of the motivation paragraph,
> which are explicitly left out of scope).
>
> I fully agree that a *Signer* must persist the full wallet's description,
> and should also create physical backups which include the full descriptor
> and the cosigner's information. I would disagree, however, if any standards
> were to force *hardware wallets* to persist any substantial amount of
> state other than the seed, as I believe that it gives no substantial
> advantage over externally stored signed data for many use cases.
>
> The following is the *wallet registration flow* I am currently working on
> (in the context of adding support to multisig wallets at Ledger). The goal
> is to allow a *Signer* (the person) to persist a multisig setup in its
> storage, while achieving a similar level of security you would have if you
> were storing it on the hardware wallet itself (note that the following flow
> would happen as part of Round 2):
>
> 1) The desktop wallet of the requests the HWW to register a new multisig
> wallet. The request includes the full multisig wallet description, and some
> extra metadata (e.g.: a name to be associated to this multisig wallet).
> 2) The HWW validates the wallet and verifies it with the user with the
> trusted screen (as per BSMS Round 2); on confirmation, it returns a wallet
> id (which is a vendor-specific hash of all the wallet description +
> metadata) and signature
> 3) The desktop wallet stores the full wallet description/id/signature.
> (Optionally, a backup could be stored elsewhere).
>

> Whenever an operation related to the multisig wallet is required
> (verifying a receiving address, or signing a spending transaction), the HWW
> first receives and verifies all the data stored at step 3 above (without
> any user interaction). Then it proceeds exactly the same way as if it had
> always stored the multisig wallet in their own storage.
>

Now that we're clear on definitions, then it should become obvious that
redefining the "Coordinator-Signer" pair as "a Signer" does not address the
underlying problem. (What you call "the desktop wallet" here is a
Coordinator, not a Signer).

As long as the Signer does not own up the task of storing the wallet
configuration, it must rely indefinitely on others for critical data when
working in a multisig wallet, as I have explained in my last email.

Best,
Hugo


>
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] Proposal: Bitcoin Secure Multisig Setup

[Salvatore Ingala via bitcoin-dev]

Hi Hugo,

First of all, thank you for the impressive work on leading the
standardization efforts!

I believe one ought to more clearly distinguish the "Signer" (as in: one of
the parties in the multisig setup), from the "*Signing device*" (which is
likely a hardware wallet). BSMS defines a "Signer" as "a participating
member in the multisig",  therefore a person/entity who is likely using
both a hardware wallet and some BSMS-friendly software wallet (e.g. the
next version of Specter Desktop). It is therefore relevant to discuss which
parts of the BSMS mechanism are implemented in the Signer's software
wallet, and which should be in the Signer's hardware wallet.
>From the discussion, it appears to me that different people might have
different expectations on what the signing device/HWW should do, so I would
like to comment on this point specifically (while I reckon that it mostly
falls within the realm of concerns #4 and #5 of the motivation paragraph,
which are explicitly left out of scope).

I fully agree that a *Signer* must persist the full wallet's description,
and should also create physical backups which include the full descriptor
and the cosigner's information. I would disagree, however, if any standards
were to force *hardware wallets* to persist any substantial amount of state
other than the seed, as I believe that it gives no substantial advantage
over externally stored signed data for many use cases.

The following is the *wallet registration flow* I am currently working on
(in the context of adding support to multisig wallets at Ledger). The goal
is to allow a *Signer* (the person) to persist a multisig setup in its
storage, while achieving a similar level of security you would have if you
were storing it on the hardware wallet itself (note that the following flow
would happen as part of Round 2):

1) The desktop wallet of the requests the HWW to register a new multisig
wallet. The request includes the full multisig wallet description, and some
extra metadata (e.g.: a name to be associated to this multisig wallet).
2) The HWW validates the wallet and verifies it with the user with the
trusted screen (as per BSMS Round 2); on confirmation, it returns a wallet
id (which is a vendor-specific hash of all the wallet description +
metadata) and signature
3) The desktop wallet stores the full wallet description/id/signature.
(Optionally, a backup could be stored elsewhere).

Whenever an operation related to the multisig wallet is required (verifying
a receiving address, or signing a spending transaction), the HWW first
receives and verifies all the data stored at step 3 above (without any user
interaction). Then it proceeds exactly the same way as if it had always
stored the multisig wallet in their own storage. I think this is basically
the same flow Michael Flaxman is suggesting here:
https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2021-April/018775.html

(Note that none of this is flow specific to Multisig wallet, as the same
flow would be unchanged for any arbitrary supported script that needs to be
"registered" on a stateless device, and can be generalized for MPC
protocols)

The only caveat I can think of is that the script registration is never
revocable if a signing key derived from the seed is used in step (2), which
might or might not be desirable. One could instead prefer to use a
different signing key that is destroyed if the device is wiped, which would
therefore need to be stored on the device. Note that the only thing that is
lost is the on-device multisig wallet registration, which could easily be
repeated from a backup.


On Sun, 11 Apr 2021 at 19:11, Hugo Nguyen via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:

> I reiterate that I strongly disagree that going stateless is the direction
> we want to pursue when it comes to multisig.
>
> In a multisig or any type of MPC smart contract, any Signer in the
> contract must know who the other co-Signers are at all times. You can
> choose to do this verification once at setup and persist this info on the
> Signer, or you'd have to re-do the verification for every single
> transaction. There is no other choice.
>

>
Signing the descriptor record is insufficient, while also introducing a
> great deal of complexity. Here are the problems:
> 1) The signature needs to be stored somewhere. Who stores it if it's not
> the Signer itself? What if it gets lost? (If the Signer stores its own
> signature, then the scheme is no longer stateless. You might as well store
> the full descriptor).
>

In the flow I describe above, the desktop wallet would indeed store the
signed descriptor record and wallet metadata. So yes, the *Signer* as in *the
party in the protocol* stores it, but not the signing device*. *The same
method could be used to store state temporarily between round 1 and 2,
where the only *state* on the hardware wallet would be the TOKEN, while
everything else is stored (encrypted and signed) on the Signer's desktop.

Re: [bitcoin-dev] Proposal: Bitcoin Secure Multisig Setup

[Hugo Nguyen via bitcoin-dev]

Hi Michael,
Comments inline.

On Sat, Apr 10, 2021 at 7:34 PM Michael.flaxman <
michael.flax...@protonmail.com> wrote:

> Hi Hugo,
>
> I appreciate the effort you and everyone else is making to improve
> multisig in bitcoin!
>

Thanks.


> I like that this BIP gets rid of SLIP132 version bytes, as those have been
> de-facto deprecated in favor of output descriptors for some time. Having a
> standard for how to communicate descriptor records (BSMS 1.0) also seems
> like a nice positive.
>
> The most commonly raised issues from the 10x security guide
>  are about how to properly verify that all
> hardware wallets are participants in the user's multisig quorum (and with
> the correct m-of-n). This shows up in two big ways:
>
>1. The O(n^2) xpub validation problem creates a bad UX and is hard for
>non-advanced users.
>2. The risk for stateless hardware wallets (like Trezor) to have their
>xpubs swapped out by a compromised Coordinator.
>
> Unfortunately, this BIP does not improve either of these issues, while
> adding considerable complexity.
>
> *1. O(n^2) Xpub Validation*
>
> The proposed use of an output descriptor checksum has an obvious 40-bit
> MITM collision attack. A compromised Coordinator could trick a Signer into
> displaying an attacker's receive address, despite a correctly functioning
> Signers and the user properly validating the checksum (github link
> ).
>
> Using a checksum with much higher entropy would reduce xpub validation to
> O(n) and create a very nice UX for signers. This would be a huge win for
> multisig! Instead, the recommended solution from the BIP is to validate all
> the key records manually, which is how multisig is currently done and what
> we desperately want to move away from. With a proper checksum, there’s no
> reason for a user to ever see an xpub.
>
> Users should not be shown a checksum and asked to validate it in meatspace
> (across Signers) if an attacker’s address could still be substituted!
> Validating a single address across devices does solve this problem, but if
> you’re going to validate an address there’s no reason to display the
> checksum at all. However, validating an address is confusing to non-experts:
>
>- Is it a wallet ID or a bitcoin address?
>- Am I supposed to send funds to this address?
>
> If creating a new checksum standard for the descriptor record is
> undesirable, we could use a child address (from an unhardened BIP32 path)
> and encode that in some way for end-users to verify it matches across all
> Signers. It would be strongly preferable for the encoding to be an
> unambiguously different format from a bitcoin address / BIP39 seed phrase,
> so that it’s clear it’s just a wallet ID. One non-ideal but simple solution
> is to use a hash function (i.e. dsha256) to calculate the digest of the
> child address, and display this in hexadecimal format. While hexadecimal is
> non-ideal for manual verification, it is already trivial for any bitcoin
> library to perform these steps.
>

As I have responded to your previous comment about the same on Github (
https://github.com/nunchuk-io/bips/pull/1), I do see the value of a
longer checksum.

There are trade-offs when it comes to designing checksum. Mainly complexity
and size. At one end of the spectrum you can have a single-byte XOR
checksum. At the other end you can have something like HMAC-SHA256 (which
we are using in the proposal to calculate the MACs for the key and
descriptor records). And then there's everything in between. But we should
know that nothing comes for free.

It's a good topic that warrants further discussion.

Confirming a single address is a promising direction, since it's something
the user should do anyway prior to using the wallet. Currently the proposal
recommends that the Signers show a preview of the first address(es) upon
wallet creation. But we can elevate this and make it a mandatory part of
the spec: have all Signers confirm that they have the same 1st receive
address. If we go with this approach, the checksum can stay as-is, and only
there for error detection. (We get the checksum for free with the
descriptor language anyway, so there's no reason to remove it).

Also nice to see that you have come around and agree that moving away from
manual inspection is desirable.


> *2. Allow Support for Stateless Wallets*
>
> The current BIP states:
>
> * "If all checks pass, the Signer must persist the descriptor record in
> its storage."*
>
> While persistence has a lot of benefits, it is not a feature of the most
> sold multisig hardware wallet: Trezor. A simple solution here is to have
> each Signer sign the entire descriptor record at the end of round 2, not
> just its own key record in round 1. Then the data can be stored anywhere
> (including on the Signer itself) and played back to each Signer for
> validation when needed. The end-user would have no idea 

Re: [bitcoin-dev] Proposal: Bitcoin Secure Multisig Setup

[Michael.flaxman via bitcoin-dev]

Hi Hugo,

I appreciate the effort you and everyone else is making to improve multisig in 
bitcoin!

I like that this BIP gets rid of SLIP132 version bytes, as those have been 
de-facto deprecated in favor of output descriptors for some time. Having a 
standard for how to communicate descriptor records (BSMS 1.0) also seems like a 
nice positive.

The most commonly raised issues from [the 10x security 
guide](https://btcguide.github.io/) are about how to properly verify that all 
hardware wallets are participants in the user's multisig quorum (and with the 
correct m-of-n). This shows up in two big ways:

- The O(n^2) xpub validation problem creates a bad UX and is hard for 
non-advanced users.
- The risk for stateless hardware wallets (like Trezor) to have their xpubs 
swapped out by a compromised Coordinator.

Unfortunately, this BIP does not improve either of these issues, while adding 
considerable complexity.

1. O(n^2) Xpub Validation

The proposed use of an output descriptor checksum has an obvious 40-bit MITM 
collision attack. A compromised Coordinator could trick a Signer into 
displaying an attacker's receive address, despite a correctly functioning 
Signers and the user properly validating the checksum ([github 
link](https://github.com/nunchuk-io/bips/pull/1/#issuecomment-801629857)).

Using a checksum with much higher entropy would reduce xpub validation to O(n) 
and create a very nice UX for signers. This would be a huge win for multisig! 
Instead, the recommended solution from the BIP is to validate all the key 
records manually, which is how multisig is currently done and what we 
desperately want to move away from. With a proper checksum, there’s no reason 
for a user to ever see an xpub.

Users should not be shown a checksum and asked to validate it in meatspace 
(across Signers) if an attacker’s address could still be substituted! 
Validating a single address across devices does solve this problem, but if 
you’re going to validate an address there’s no reason to display the checksum 
at all. However, validating an address is confusing to non-experts:

- Is it a wallet ID or a bitcoin address?

- Am I supposed to send funds to this address?

If creating a new checksum standard for the descriptor record is undesirable, 
we could use a child address (from an unhardened BIP32 path) and encode that in 
some way for end-users to verify it matches across all Signers. It would be 
strongly preferable for the encoding to be an unambiguously different format 
from a bitcoin address / BIP39 seed phrase, so that it’s clear it’s just a 
wallet ID. One non-ideal but simple solution is to use a hash function (i.e. 
dsha256) to calculate the digest of the child address, and display this in 
hexadecimal format. While hexadecimal is non-ideal for manual verification, it 
is already trivial for any bitcoin library to perform these steps.

2. Allow Support for Stateless Wallets

The current BIP states:

"If all checks pass, the Signer must persist the descriptor record in its 
storage."

While persistence has a lot of benefits, it is not a feature of the most sold 
multisig hardware wallet: Trezor. A simple solution here is to have each Signer 
sign the entire descriptor record at the end of round 2, not just its own key 
record in round 1. Then the data can be stored anywhere (including on the 
Signer itself) and played back to each Signer for validation when needed. The 
end-user would have no idea this was happening, but the device could refuse to 
display information it hasn’t fully validated (or at least add a warning 
message). Even a device with persistent storage would be better served using a 
signature, so that an evil maid couldn't tamper with the device (say in the 
no-encryption case for simplicity).

This existing vulnerability in stateless wallets is particularly bad for hosted 
multisig services like Casa/Unchained, where the service might control m-1 
keys. It’s far easier for a hosted service to potentially trick non-expert 
users into displaying an attacker's receive address on their stateless Signer.

For example, assume the user is doing 2-of-3 multisig, where the Coordinator 
(service) controls 1 key. Here is how the Coordinator could trick their 
end-users:

- Coordinator swaps out 1 of the end-user’s xpubs, going from a 2-of-3 where 
the end-user has 2 seeds to a 2-of-3 where the Coordinator has 2 seeds.

- The end-user logs into the service to get a new receive address, and the 
service (Coordinator) displays malicious receive address X (as part of a 
2-of-3).

- The end user connects stateless Signer 1 to the service (Coordinator), which 
under-the-hood gives stateless Signer 1 proof that it is included in this 
2-of-3. Stateless singer 1 displays malicious receive address X!

- The end-user doesn't verify the address on Signer 2, as many users 
unfortunately don't -- perhaps it is in a far away location and the end-user 
(incorrectly) thinks that it’s already been validated in 2 p

Re: [bitcoin-dev] Proposal: Bitcoin Secure Multisig Setup

[Robert Spigler via bitcoin-dev]

Hi Sjors,

Thanks for your comments.

>Chicken-egg problem

I agree with Hugo's detailed response here.

>Losing multisig setup context (in the event of a fire where you only recover 
>your steel engraved mnemonic(s), but no longer have the wallet descriptors.)

Devices need to persist the descriptor, if they currently can't, they don't 
comply with this standard and they can't be used securely for multisig. There's 
no reasons the master seed and descriptor both can't be backed up outside of 
each device. I can't see a scenario where it would be possible to recover only 
the seed. (I don't know yet how Core will decide how to best backup this info, 
seeing as BIP39 was rejected).

>BIP48

I agree with Hugo that BIP48 is redundant with descriptors, please see 
https://github.com/bitcoin/bips/pull/1089 for a proposed updated hierarchy for 
multisignature wallets.

>An encryption convention for the descriptor data

I understand this concern. Like you mentioned previously, I too often set up 
multisignature wallets for clients where they are actually owned by the single 
party. A concern is that while the backup location owners cannot spend (due to 
the M-of-N restriction), they can view the wallet balance/history. As Hugo 
mentioned, you can apply any encryption you want after the setup, so a solution 
may be to use Shamir Secret Sharing (Blockchain Commons has done a lot of work 
on that here: 
https://github.com/BlockchainCommons/Airgapped-Wallet-Community/discussions/37#discussioncomment-287993)

>Plain text vs binary

I too favor plain text

Robert Spigler
Personal Fingerprint: BF0D 3C08 A439 5AC6 11C1 5395 B70B 4A77 F850 548F

‐‐‐ Original Message ‐‐‐
On Friday, April 9, 2021 11:33 AM, Sjors Provoost via bitcoin-dev 
 wrote:

> Thanks for the detailed response. Just 1 thing I needed to clarify:
>
>>> To the list of concerns at the top of the BIP, I would add one: losing 
>>> multisig setup context. E.g. in the event of a fire where you only recover 
>>> your steel engraved mnemonic(s), but no longer have the wallet descriptors.
>>
>> Good point.
>>
>>> If you still have all devices and know (or guess) the threshold then BIP48 
>>> and sorted_multi descriptors will save you. But if you have a 2-of-3 setup 
>>> and lost 1 device then without the metadata your coins are lost. In a 
>>> future with musig(?) and miniscript increasingly the setup data is just as 
>>> critical as the seeds.
>>
>> How so? Each signer device should ideally have a copy of the multisig 
>> configuration. If you lose 1 device in a 2-of-3, you can still spend from 
>> the wallet? Unless I'm missing something here.
>
> I was thinking about a scenario where all devices are destroyed. All you have 
> left are the mnemonics. But indeed if at least one of your devices is still 
> intact AND it has the configuration, you're also good.
>
> But there are plenty of devices out there that can't do this. Those devices 
> can still be useful, even if they can't fully check everything.
>
> Sjors___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] Proposal: Bitcoin Secure Multisig Setup

[Erik Aronesty via bitcoin-dev]

here's what we do for multisig:

- each member generates their own public/private key pair first and
publishes the pair to all other members
- members are then verified using a secondary channel, like a phone
call ... where the H128(pubk) is turned into BIP-words for
manual/visual verification
- multi-round DKG is used with appropriate commitments and
verification of components  (nice article:
https://link.springer.com/content/pdf/10.1007/s00145-006-0347-3.pdf)

without that, there's simply no guarantee that you're not
communicating with an attacker during setup.

On Tue, Feb 9, 2021 at 2:53 AM Hugo Nguyen via bitcoin-dev
 wrote:
>
> Hi all,
> I would like to propose a new BIP for Secure Multisig Setup.
> This proposal has taken inputs from folks at Coldcard, Shift Crypto and Cobo 
> -- listed below as co-authors.
>
> This was inspired by my own experience working with hardware wallets on the 
> market, as well as existing research into the challenges of multisig.
>
> Cheers,
> Hugo
>
> 
>   BIP: To be determined
>   Layer: Applications
>   Title: Bitcoin Secure Multisig Setup (BSMS)
>   Author: Hugo Nguyen , Peter Gray , 
> Marko Bencun , Aaron Chen , 
> Rodolfo Novak 
>   Comments-Summary: No comments yet.
>   Comments-URI:
>   Status: Proposed
>   Type: Standards Track
>   Created: 2020-11-10
>   License: BSD-2-Clause
> 
>
> ==Introduction==
>
> ===Abstract===
>
> This document proposes a mechanism to set up multisig wallets securely.
>
> ===Copyright===
>
> This BIP is licensed under the 2-clause BSD license.
>
> ===Motivation===
>
> The Bitcoin multisig experience has been greatly streamlined under 
> [https://github.com/bitcoin/bips/blob/master/bip-0174.mediawiki BIP-0174 
> (Partially Signed Bitcoin Transaction)]. However, what is still missing is a 
> standardized process for setting up multisig wallets securely across 
> different vendors.
>
> There are a number of concerns when it comes to setting up a multisig wallet:
>
> # Whether the multisig configuration, such as Signer membership, script type, 
> derivation paths and number of signatures required, is correct and not 
> tampered with.
> # Whether Signer persists the multisig configuration in their respective 
> storage, and under what format.
> # Whether Signer's storage is tamper-proof.
> # Whether Signer subsequently uses the multisig configuration to generate and 
> verify receive and change addresses.
>
> An attacker who can modify the multisig configuration can steal or hold funds 
> to ransom by duping the user into sending funds to the wrong address.
>
> This proposal seeks to address concerns #1 and #2: to mitigate the risk of 
> tampering during the initial setup phase, and to define an interoperable 
> multisig configuration format.
>
> Concerns #3 and #4 should be handled by Signers and is out of scope of this 
> proposal.
>
> ==Specification==
>
> ===Prerequisites===
> This proposal assumes the parties in the multisig support 
> [https://github.com/bitcoin/bips/blob/master/bip-0032.mediawiki BIP32], 
> [https://github.com/bitcoin/bitcoin/blob/master/doc/descriptors.md the 
> descriptor language] and encryption.
>
> ==Roles==
> ===Coordinator===
>
> The Coordinator initiates the multisig setup. The Coordinator determines what 
> type of multisig is used and how many members and signatures are needed. If 
> encryption is enabled, the Coordinator generates a secret token, to be shared 
> among the parties for secure communication. The Coordinator gathers 
> information from the Signers to generate a descriptor record. The Coordinator 
> distributes the descriptor record back to the Signers.
>
> ===Signer===
>
> The Signer is a participating member in the multisig. Its responsibilities 
> include providing its XPUB to the Coordinator, verifying that its XPUB is 
> included in the descriptor record and persisting the descriptor record in its 
> storage.
>
> ==Setup Process==
>
> ===Round 1===
>
> Coordinator
>
> * The Coordinator creates a multisig wallet creation session. The Coordinator 
> determines the type of multisig script used and the signing configuration 
> (M and N).
> * If encryption is enabled, the Coordinator also generates a secret token, 
> hereby denoted TOKEN.
> * TOKEN is in ASCII format and must have a minimum of 8 characters. TOKEN 
> should expire after some time period determined by the Coordinator, e.g., 24 
> hours.
> * TOKEN acts as an encryption key among the parties. The method of encryption 
> is AES, CTR mode. The encryption key can be calculated by performing a double 
> hash operation on the TOKEN: ENCRYPTION_KEY = SHA256(SHA256(TOKEN)).
> * A TOKEN value of -1 means that encryption is disabled and all the 
> encryption/decryption steps below can be skipped.
> * The Coordinator shares the TOKEN with all participating Signers over a 
> secure channel.
>
> Signer
>
> * The Signer generates a key record by prompting the user for the TOKEN and a 
> derivation path.
> * The first line in the 

Re: [bitcoin-dev] Proposal: Bitcoin Secure Multisig Setup

[Sjors Provoost via bitcoin-dev]

Thanks for the detailed response. Just 1 thing I needed to clarify:

> To the list of concerns at the top of the BIP, I would add one: losing 
> multisig setup context. E.g. in the event of a fire where you only recover 
> your steel engraved mnemonic(s), but no longer have the wallet descriptors.
> 
> Good point.
> 
> 
> If you still have all devices and know (or guess) the threshold then BIP48 
> and sorted_multi descriptors will save you. But if you have a 2-of-3 setup 
> and lost 1 device then without the metadata your coins are lost. In a future 
> with musig(?) and miniscript increasingly the setup data is just as critical 
> as the seeds.
> 
> How so? Each signer device should ideally have a copy of the multisig 
> configuration. If you lose 1 device in a 2-of-3, you can still spend from the 
> wallet? Unless I'm missing something here.

I was thinking about a scenario where all devices are destroyed. All you have 
left are the mnemonics. But indeed if at least one of your devices is still 
intact AND it has the configuration, you're also good.

But there are plenty of devices out there that can't do this. Those devices can 
still be useful, even if they can't fully check everything.

Sjors


signature.asc
Description: Message signed with OpenPGP
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] Proposal: Bitcoin Secure Multisig Setup

[Hugo Nguyen via bitcoin-dev]

(Continue off last email: also keep in mind, that just like BIP174,
Coordinator and Signer are abstract roles. This means in theory a Signer
can be the Coordinator too. The same criteria for trust applies equally to
a Signer and a Coordinator.)

The use case I personally find most interesting is not a multi-party setup,
> but rather just combining a bunch of my own devices. Those might even be in
> the same room during the setup, only to be moved to my moon base later.
>

And that's fair. Both use cases (local and remote multisig) are valid and
currently being used. But IMO a standard should accommodate both.


> To the list of concerns at the top of the BIP, I would add one: losing
> multisig setup context. E.g. in the event of a fire where you only recover
> your steel engraved mnemonic(s), but no longer have the wallet descriptors.
>

Good point.


>
> If you still have all devices and know (or guess) the threshold then BIP48
> and sorted_multi descriptors will save you. But if you have a 2-of-3 setup
> and lost 1 device then without the metadata your coins are lost. In a
> future with musig(?) and miniscript increasingly the setup data is just as
> critical as the seeds.
>

How so? Each signer device should ideally have a copy of the multisig
configuration. If you lose 1 device in a 2-of-3, you can still spend from
the wallet? Unless I'm missing something here.


> A future standard (or extension of this one) should recommend an
> encryption convention for the descriptor data, ideally such that with *any*
> of the seeds you can decrypt a file that contains the full setup. That file
> could then just float redundantly around the internet and pieces of paper
> in various locations, without compromising privacy.
>

Post-wallet-creation, each Signer can apply extra encryption on top of BSMS
for the persistence of the configuration file any way it wants :) It
doesn't contradict with the current spec.


> The proposed encryption system doesn't help with that though, because it's
> based on entropy from the Coordinator, rather than from the signers.
>

They are for different purposes. The TOKEN-based encryption is only needed
temporarily for the setup.


> Smaller suggestions:
> * link to this new mail thread in the BIP
>

Will do.


> * use magic bytes so .bsms so operating systems like Android / iOs can
> open the right app for them
> * don't use separate file extensions for encrypted vs unencrypted content,
> just indicate somehow that a given field is encrypted
> * although plain text files are handy for debugging, I think a binary
> format like PSBT is much powerful. Any device that can parse and write
> binary PSBT should be able to implement a similar parser / writer for a
> binary .bsms format.
>

Will consider these points, but I prefer plaintext for wallet
configuration. Human readability for the wallet configuration is a pro not
a con IMO. Also helps when backing up.


> * BIP48 and sorted_multi descriptors are useful in a loss-of-metadata
> scenario. The BIP uses both in the examples, but doesn't explictly endorse
> these derivations. It also contradicts them: "If the Signer chooses the
> path, it should try to avoid reusing XPUBs for different wallets.". Maybe
> this is out of scope.
>* one way to resolve xpub reuse would be to make the "BIP48" path a
> function of the co-signer fingerprints and wallet threshold, but this
> requires an extra communication round
>

We discussed this in the linked PR (
https://github.com/nunchuk-io/bips/pull/1), and decided that enforcing
against path reuse is out-of-scope. We give examples of sorted_multi and
multi because different vendors support different things.


> * there should be a way for signers to communicate their capabilities,
> perhaps with a different xpub for each potential scheme. E.g. there's m/48'
> native SegWit now, MuSig and/or or Tapleaf based multisig in the future, or
> even generic Miniscript support.
>

I considered Signers signaling capabilities (for a different reason), but
opted against it because it further complicates the scheme. Also BIP48-like
proposals are made redundant with the use of output descriptors.


> * the idea of only storing the receive descriptor, not the change
> descriptor, is fine by me, though I'd prefer an extension to the descriptor
> format to deal with this
>

That's not quite accurate. The spec stores the top-level descriptor
(XPUB/*) along with the path restrictions (/0/*,/1/*), not the receive
descriptor.

 The path restrictions would allow you to extend on the spec. There's also
a VERSION field.

Best,
Hugo


>
> Sjors
>
> > Op 5 apr. 2021, om 09:02 heeft Hugo Nguyen via bitcoin-dev <
> bitcoin-dev@lists.linuxfoundation.org> het volgende geschreven:
> >
> > Hi all,
> >
> > Please find below the complete draft of the Bitcoin Secure Multisig
> Setup (BSMS) BIP. The spec has gone through a number of important updates
> in the last month or so. Thanks everyone who has participated in the review
> process.

Re: [bitcoin-dev] Proposal: Bitcoin Secure Multisig Setup

[Hugo Nguyen via bitcoin-dev]

Hi Sjors
Thanks for the feedback!

The first step is for the Coordinator to generate a TOKEN, presumably using
> its own entropy. But IIUC anyone who intercepts that token can decrypt any
> future step in the setup process. This suggests a chicken-egg problem where
> you need some pre-existing secure communications channel.
>

The exchange of the TOKEN is frequently mistaken as the chicken-and-egg
problem, but it is not so.

To understand why this isn't chicken-and-egg, and why the TOKEN actually
adds value, consider *the scale of the communication operation needed to
exchange the TOKEN*, and *the scale of the communication operation needed
to gather data for the creation of the multisig wallet *(with or without
the TOKEN):

1) The TOKEN itself is a single piece of data that is 64- or 96-bit. It is
small enough to be easily exchanged (even memorized) and entered into
various devices. It requires only a single round of communication, but can
protect as many rounds of communication as needed.

2) The data needed to create the multisig wallet, on the other hand, are
quite involving:
(a) Each Signer needs to share its XPUB, which cannot be memorized
(b) The XPUBs also come with their own metadata
(c) The creation of the wallet requires at least two rounds of
communications since the Signers need to voluntarily share their XPUBs
first, only then can a Coordinator combine the XPUBs into a single multisig
script and pass back the configuration to the Signers. (Note that without a
Coordinator, you'll need O(N^2) rounds of communication).
(d) Because Signers are typically off-line cold storage, the paths between
the Signers / the Signers <> Coordinator likely involve multiple hops
through various media, such as unsecure USB connection. This is the way
most multisig solutions are currently being implemented. It means the XPUBs
and the multisig configuration are vulnerable to leaking and/or
modifications.

Note that (d) is especially problematic for remote multisig setups. The
more remote, the more potential hops along the way, the more problematic.

So you can see that *the TOKEN ultimately reduces the problem of sharing a
large amount of sensitive data back and forth, to the sharing of a single,
small piece of data upfront.* An added advantage of this approach is that
if the parties fail to establish a shared TOKEN, the scheme fails with no
harm done.

The Coordinator, on the other hand, adds value by solving the O(n^2)
communication problem. Some minimal amount of trust is needed for the
Coordinator, but this can be greatly mitigated by a number of ways that we
have defined in the spec, such as:
* Signers must check that their XPUBs are included in the final descriptor
* Signers must display to the user the multisig configuration: M/N,
relative position(s) of XPUBs, etc.
* Signers must display the full descriptor upon user request for manual
inspection - this one is important because it means that the new scheme
cannot be worse than the status quo.
* Signers are recommended to display a preview of the first receive
address(es).

All in all, the Coordinator's role helps ease the setup process, while its
ability to pull off any shenanigans is greatly limited.

Best,
Hugo
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] Proposal: Bitcoin Secure Multisig Setup

[Sjors Provoost via bitcoin-dev]

Hi all,

First of all thanks for your continued work on standardising multisig setup.

The use case I personally find most interesting is not a multi-party setup, but 
rather just combining a bunch of my own devices. Those might even be in the 
same room during the setup, only to be moved to my moon base later.

This means I've paid less attention to the encryption scheme, so I might set 
TOKEN=0, but nevertheless I am skeptical about it. The first step is for the 
Coordinator to generate a TOKEN, presumably using its own entropy. But IIUC 
anyone who intercepts that token can decrypt any future step in the setup 
process. This suggests a chicken-egg problem where you need some pre-existing 
secure communications channel.

To the list of concerns at the top of the BIP, I would add one: losing multisig 
setup context. E.g. in the event of a fire where you only recover your steel 
engraved mnemonic(s), but no longer have the wallet descriptors.

If you still have all devices and know (or guess) the threshold then BIP48 and 
sorted_multi descriptors will save you. But if you have a 2-of-3 setup and lost 
1 device then without the metadata your coins are lost. In a future with 
musig(?) and miniscript increasingly the setup data is just as critical as the 
seeds.

A future standard (or extension of this one) should recommend an encryption 
convention for the descriptor data, ideally such that with *any* of the seeds 
you can decrypt a file that contains the full setup. That file could then just 
float redundantly around the internet and pieces of paper in various locations, 
without compromising privacy.

The proposed encryption system doesn't help with that though, because it's 
based on entropy from the Coordinator, rather than from the signers.


Smaller suggestions:
* link to this new mail thread in the BIP
* use magic bytes so .bsms so operating systems like Android / iOs can open the 
right app for them
* don't use separate file extensions for encrypted vs unencrypted content, just 
indicate somehow that a given field is encrypted
* although plain text files are handy for debugging, I think a binary format 
like PSBT is much powerful. Any device that can parse and write binary PSBT 
should be able to implement a similar parser / writer for a binary .bsms format.
* BIP48 and sorted_multi descriptors are useful in a loss-of-metadata scenario. 
The BIP uses both in the examples, but doesn't explictly endorse these 
derivations. It also contradicts them: "If the Signer chooses the path, it 
should try to avoid reusing XPUBs for different wallets.". Maybe this is out of 
scope.
   * one way to resolve xpub reuse would be to make the "BIP48" path a function 
of the co-signer fingerprints and wallet threshold, but this requires an extra 
communication round
* there should be a way for signers to communicate their capabilities, perhaps 
with a different xpub for each potential scheme. E.g. there's m/48' native 
SegWit now, MuSig and/or or Tapleaf based multisig in the future, or even 
generic Miniscript support.
* the idea of only storing the receive descriptor, not the change descriptor, 
is fine by me, though I'd prefer an extension to the descriptor format to deal 
with this

Sjors

> Op 5 apr. 2021, om 09:02 heeft Hugo Nguyen via bitcoin-dev 
>  het volgende geschreven:
> 
> Hi all,
> 
> Please find below the complete draft of the Bitcoin Secure Multisig Setup 
> (BSMS) BIP. The spec has gone through a number of important updates in the 
> last month or so. Thanks everyone who has participated in the review process.
> 
> As a PR: https://github.com/bitcoin/bips/pull/1097



signature.asc
Description: Message signed with OpenPGP
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] Proposal: Bitcoin Secure Multisig Setup

[Hugo Nguyen via bitcoin-dev]

Hi all,

Please find below the complete draft of the Bitcoin Secure Multisig Setup
(BSMS) BIP. The spec has gone through a number of important updates in the
last month or so. Thanks everyone who has participated in the review
process.

As a PR: https://github.com/bitcoin/bips/pull/1097

A few notes:
* PBKDF2-SHA512 was chosen instead of PBKDF2-SHA256 for the key derivation
function, due to widespread existing hardware support for PBKDF2-SHA512
* Only one descriptor is stored in the multisig configuration - this
simplifies wallet setup and recovery
(For the full review and relevant discussions, please check out
https://github.com/nunchuk-io/bips/pull/1).

Best,
Hugo


  BIP: To be determined
  Layer: Applications
  Title: Bitcoin Secure Multisig Setup (BSMS)
  Author: Hugo Nguyen , Peter Gray , Marko Bencun , Aaron Chen
, Rodolfo Novak 
  Comments-Summary: No comments yet.
  Comments-URI:
  Status: Proposed
  Type: Standards Track
  Created: 2020-11-10
  License: BSD-2-Clause


==Introduction==

===Abstract===

This document proposes a mechanism to set up multisig wallets securely.

===Copyright===

This BIP is licensed under the 2-clause BSD license.

===Motivation===

The Bitcoin multisig experience has been greatly streamlined under
[https://github.com/bitcoin/bips/blob/master/bip-0174.mediawiki
BIP-0174
(Partially Signed Bitcoin Transaction)]. However, what is still
missing is a standardized process for setting up multisig wallets
securely across different vendors.

There are a number of concerns when it comes to setting up a multisig wallet:

# Whether the multisig configuration, such as Signer membership,
script type, derivation paths and number of signatures required, is
correct and not tampered with.
# Whether the keys or the multisig configuration are leaked during the setup.
# Whether the Signer persists the multisig configuration in their
respective storage, and under what format.
# Whether the Signer's storage is tamper-proof.
# Whether the Signer subsequently uses the multisig configuration to
generate and verify receive and change addresses.

An attacker who can modify the multisig configuration can steal or
hold funds for ransom by duping the user into sending funds to the
wrong address. An attacker who cannot modify the configuration but can
learn about the keys and/or the configuration can monitor transactions
in the wallet, resulting in loss of privacy.

This proposal seeks to address concerns #1, #2 and #3: to mitigate the
risk of tampering during the initial setup phase, and to define an
interoperable multisig configuration format.

Concerns #4 and #5 should be handled by Signers and are out of scope
of this proposal.

==Specification==

===Prerequisites===
This proposal assumes the parties in the multisig support
[https://github.com/bitcoin/bips/blob/master/bip-0032.mediawiki
BIP-0032], [https://github.com/bitcoin/bips/blob/master/bip-0322.mediawiki
BIP-0322], [https://github.com/bitcoin/bitcoin/blob/master/doc/descriptors.md
the descriptor language] and [https://tools.ietf.org/html/rfc3686 AES
encryption].

===File Extension===
All descriptor and key records should have a .bsms file
extension. Encrypted data should have a .dat extension.

===Roles===
Coordinator

The Coordinator initiates the multisig setup. The Coordinator
determines what type of multisig is used and the exact policy script.
If encryption is enabled, the Coordinator also distributes a shared
secret or shared secrets to the parties involved for secure
communication. The Coordinator gathers information from the Signers to
generate a descriptor record. The Coordinator distributes the
descriptor record back to the Signers.

Signer

The Signer is a participating member in the multisig. Its
responsibilities include providing its key record -- which contains an
Extended Public Key (XPUB) -- to the Coordinator, verifying that its
XPUB is included in the descriptor record and persisting the
descriptor record in its storage.

===Setup Process===

Round 1

=Coordinator=

* The Coordinator creates a new multisig wallet creation session. The
Coordinator constructs the multisig script and its policy parameters,
such as the required number of signatures and the total number of
Signers (M and N).
* The session should expire after some time period determined by the
Coordinator, e.g., 24 hours. The timeout allows the encryption key to
have lower entropy.
* If encryption is enabled, the Coordinator distributes a secret
TOKEN to each Signer over a secure channel. The Signer can
use the TOKEN to derive an ENCRYPTION_KEY. Refer to
the Encryption section below for details on the TOKEN, the
key derivation function and the encryption scheme. Depending on the
use case, the Coordinator can decide whether to share one common
TOKEN for all Signers, or to have one per Signer.
* If encryption is disabled, the TOKEN is set to 0,
and all the encryption/decryption steps below can be skipped.

=Signer=

* The Si

Re: [bitcoin-dev] Proposal: Bitcoin Secure Multisig Setup

[Hugo Nguyen via bitcoin-dev]

I would also like to add 2 notes for those who are concerned about the
potential complexity that comes with encryption - which is understandable:

1. As mentioned elsewhere in the thread, I've made the encryption aspect
entirely optional. In scenarios where encryption is an overkill -- such as
when you're setting things up under an environment you control 100% -- you
can turn encryption off, and things are unchanged from the way they are
now. The "session" would be unencrypted and XPUBs and descriptor records
are simply shared in plaintext.

2. Multisig setup is a one-time operation! After the multisig wallet has
been set up and registered with the Signers, you don't have to worry about
sharing XPUBs ever again (not even in PSBTs which is an additional benefit
of the stateful registration approach). I believe this one-time cost is
worth it if the amount of funds you are securing are significant, e.g., few
millions of dollars or even billions of dollars. But it's important that we
have this extra level of security if necessary IMHO.

Best,
Hugo

On Mon, Feb 15, 2021 at 6:19 AM Hugo Nguyen  wrote:

> Hi Craig,
> Thanks for the feedback! Sharing my comments inline.
>
> On Mon, Feb 15, 2021 at 5:53 AM Craig Raw  wrote:
>
>> Hi all,
>>
>> Hugo and I have discussed off-list, and I have two concerns with this
>> proposal:
>>
>> 1. I believe adding the TOKEN and encryption to the exchange adds
>> complexity to already notoriously complex multisig, without adding much in
>> the way of security.
>>
>
> I disagree that this doesn't add security. This proposal was inspired by a
> real vulnerability we discovered in the wild while experimenting with HWWs,
> and during that process I noticed that there is little in the way of a an
> attacker to pull off a MITM attack, where he/she can intercept and tamper
> with the multisig configuration file, potentially swapping in their own
> XPUBs. This is especially important for remote multisig setups - which is
> not common now but I imagine will be a lot more common in the future.
>
> This is because the shared secret (TOKEN) must still be shared securely,
>> and if you have established an (off-protocol) secure channel to do this,
>> why not just share the actual multisig configuration data directly in that
>> channel?
>
>
> Because multisig is inherently an interactive process. If we can create
> the multisig configuration in one shot for everybody, you're correct that
> this is not necessary! But the fact that multisig is by nature interactive
> and requires a few rounds of communication (since it needs each Signer to
> voluntarily share its XPUB before a wallet can be created) makes this
> necessary IMO.
>
> If you are able to do so, you retain the advantage of being able to
>> inspect the data directly.
>
>
> Note that some manual inspection is still part of the proposal. But
> instead of exclusively relying on manual inspection (which is error-prone,
> and also doesn't scale very well for a large number of signers), we
> strengthen this process by automating some of the checks and making it
> harder to tamper with.
>
>
>>
>> 2. Asking the user to enter the derivation into the Signer also adds (IMO
>> unnecessary) complexity to the multisig setup process. A different way of
>> doing it, which is specified in the UR crypto-account format linked to
>> previously, has the Signer provide as many common derivations (along with
>> their xpubs) as it can support for a given BIP44 account number. This has
>> the dual advantage of making things simpler for the user (they only have to
>> provide an optional account number) and increasing the standardisation on
>> common derivation paths. On receiving these derivation/xpub pairs, the
>> Coordinator can simply pick the appropriate one.
>>
>
> Note that in the updated proposal, I added the option of the Signer
> automatically filling in the derivation paths on behalf of the user (and
> also should take care not to reuse XPUBs). Perhaps this can be made the
> default behavior.
>
> Best,
> Hugo
>
>
>>
>> These concerns noted, I agree it's a good idea to have Signers save the
>> multisig configuration as proposed, and it would be great to have
>> standardisation in hww import and export formats (not just for multisig).
>> On that note, I'd love to see greater adoption of the efficient UR2.0
>> standard and associated formats for airgapped data transmission using QR
>> codes.
>>
>> Craig
>>
>>
>> On Mon, Feb 15, 2021 at 11:13 AM Hugo Nguyen via bitcoin-dev <
>> bitcoin-dev@lists.linuxfoundation.org> wrote:
>>
>>> Hi all,
>>> I have updated the proposal based on further feedback. The new spec is
>>> included at the bottom.
>>>
>>> I have also created a public Github PR to make it easier to comment on
>>> the text of the spec itself: https://github.com/nunchuk-io/bips/pull/1 .
>>>
>>> Could someone please let me know what else needs to be done before a BIP
>>> number can be assigned?
>>>
>>>
>>> === Quick summary of changes from last update =

Re: [bitcoin-dev] Proposal: Bitcoin Secure Multisig Setup

[Hugo Nguyen via bitcoin-dev]

Hi Craig,
Thanks for the feedback! Sharing my comments inline.

On Mon, Feb 15, 2021 at 5:53 AM Craig Raw  wrote:

> Hi all,
>
> Hugo and I have discussed off-list, and I have two concerns with this
> proposal:
>
> 1. I believe adding the TOKEN and encryption to the exchange adds
> complexity to already notoriously complex multisig, without adding much in
> the way of security.
>

I disagree that this doesn't add security. This proposal was inspired by a
real vulnerability we discovered in the wild while experimenting with HWWs,
and during that process I noticed that there is little in the way of a an
attacker to pull off a MITM attack, where he/she can intercept and tamper
with the multisig configuration file, potentially swapping in their own
XPUBs. This is especially important for remote multisig setups - which is
not common now but I imagine will be a lot more common in the future.

This is because the shared secret (TOKEN) must still be shared securely,
> and if you have established an (off-protocol) secure channel to do this,
> why not just share the actual multisig configuration data directly in that
> channel?


Because multisig is inherently an interactive process. If we can create the
multisig configuration in one shot for everybody, you're correct that this
is not necessary! But the fact that multisig is by nature interactive and
requires a few rounds of communication (since it needs each Signer to
voluntarily share its XPUB before a wallet can be created) makes this
necessary IMO.

If you are able to do so, you retain the advantage of being able to inspect
> the data directly.


Note that some manual inspection is still part of the proposal. But instead
of exclusively relying on manual inspection (which is error-prone, and also
doesn't scale very well for a large number of signers), we strengthen this
process by automating some of the checks and making it harder to tamper
with.


>
> 2. Asking the user to enter the derivation into the Signer also adds (IMO
> unnecessary) complexity to the multisig setup process. A different way of
> doing it, which is specified in the UR crypto-account format linked to
> previously, has the Signer provide as many common derivations (along with
> their xpubs) as it can support for a given BIP44 account number. This has
> the dual advantage of making things simpler for the user (they only have to
> provide an optional account number) and increasing the standardisation on
> common derivation paths. On receiving these derivation/xpub pairs, the
> Coordinator can simply pick the appropriate one.
>

Note that in the updated proposal, I added the option of the Signer
automatically filling in the derivation paths on behalf of the user (and
also should take care not to reuse XPUBs). Perhaps this can be made the
default behavior.

Best,
Hugo


>
> These concerns noted, I agree it's a good idea to have Signers save the
> multisig configuration as proposed, and it would be great to have
> standardisation in hww import and export formats (not just for multisig).
> On that note, I'd love to see greater adoption of the efficient UR2.0
> standard and associated formats for airgapped data transmission using QR
> codes.
>
> Craig
>
>
> On Mon, Feb 15, 2021 at 11:13 AM Hugo Nguyen via bitcoin-dev <
> bitcoin-dev@lists.linuxfoundation.org> wrote:
>
>> Hi all,
>> I have updated the proposal based on further feedback. The new spec is
>> included at the bottom.
>>
>> I have also created a public Github PR to make it easier to comment on
>> the text of the spec itself: https://github.com/nunchuk-io/bips/pull/1 .
>>
>> Could someone please let me know what else needs to be done before a BIP
>> number can be assigned?
>>
>>
>> === Quick summary of changes from last update ===
>>
>> 1. Define encryption modes
>>
>> # NO_ENCRYPTION: Encryption is disabled.
>> # STANDARD : the TOKEN is a 64-bit nonce.
>> # EXTENDED : the TOKEN is a 128-bit nonce.
>>
>> 2. Define signature algorithm
>>
>> Follow BIP-0322, legacy format allowed.
>>
>> 3. Multiple TOKENs (optional)
>>
>> Also add an option where the Coordinator can choose to use one common
>> TOKEN for all Signers, or use one per Signer.
>>
>> === End of summary ===
>>
>>
>> Cheers,
>> Hugo
>>
>>
>> 
>>   BIP: To be determined
>>   Layer: Applications
>>   Title: Bitcoin Secure Multisig Setup (BSMS)
>>   Author: Hugo Nguyen , Peter Gray > coinkite.com>, Marko Bencun , Pavol Rusnak <
>> st...@satoshilabs.com>, Aaron Chen , Rodolfo
>> Novak 
>>   Comments-Summary: No comments yet.
>>   Comments-URI:
>>   Status: Proposed
>>   Type: Standards Track
>>   Created: 2020-11-10
>>   License: BSD-2-Clause
>> 
>>
>> ==Introduction==
>>
>> ===Abstract===
>>
>> This document proposes a mechanism to set up multisig wallets securely.
>>
>> ===Copyright===
>>
>> This BIP is licensed under the 2-clause BSD license.
>>
>> ===Motivation===
>>
>> The Bitcoin multisig experience has been greatly streamlined under [
>> https://github.com/bitcoin/bips/blob/master/

Re: [bitcoin-dev] Proposal: Bitcoin Secure Multisig Setup

[Craig Raw via bitcoin-dev]

Hi all,

Hugo and I have discussed off-list, and I have two concerns with this
proposal:

1. I believe adding the TOKEN and encryption to the exchange adds
complexity to already notoriously complex multisig, without adding much in
the way of security. This is because the shared secret (TOKEN) must still
be shared securely, and if you have established an (off-protocol) secure
channel to do this, why not just share the actual multisig configuration
data directly in that channel? If you are able to do so, you retain the
advantage of being able to inspect the data directly.

2. Asking the user to enter the derivation into the Signer also adds (IMO
unnecessary) complexity to the multisig setup process. A different way of
doing it, which is specified in the UR crypto-account format linked to
previously, has the Signer provide as many common derivations (along with
their xpubs) as it can support for a given BIP44 account number. This has
the dual advantage of making things simpler for the user (they only have to
provide an optional account number) and increasing the standardisation on
common derivation paths. On receiving these derivation/xpub pairs, the
Coordinator can simply pick the appropriate one.

These concerns noted, I agree it's a good idea to have Signers save the
multisig configuration as proposed, and it would be great to have
standardisation in hww import and export formats (not just for multisig).
On that note, I'd love to see greater adoption of the efficient UR2.0
standard and associated formats for airgapped data transmission using QR
codes.

Craig


On Mon, Feb 15, 2021 at 11:13 AM Hugo Nguyen via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:

> Hi all,
> I have updated the proposal based on further feedback. The new spec is
> included at the bottom.
>
> I have also created a public Github PR to make it easier to comment on the
> text of the spec itself: https://github.com/nunchuk-io/bips/pull/1 .
>
> Could someone please let me know what else needs to be done before a BIP
> number can be assigned?
>
>
> === Quick summary of changes from last update ===
>
> 1. Define encryption modes
>
> # NO_ENCRYPTION: Encryption is disabled.
> # STANDARD : the TOKEN is a 64-bit nonce.
> # EXTENDED : the TOKEN is a 128-bit nonce.
>
> 2. Define signature algorithm
>
> Follow BIP-0322, legacy format allowed.
>
> 3. Multiple TOKENs (optional)
>
> Also add an option where the Coordinator can choose to use one common
> TOKEN for all Signers, or use one per Signer.
>
> === End of summary ===
>
>
> Cheers,
> Hugo
>
>
> 
>   BIP: To be determined
>   Layer: Applications
>   Title: Bitcoin Secure Multisig Setup (BSMS)
>   Author: Hugo Nguyen , Peter Gray  coinkite.com>, Marko Bencun , Pavol Rusnak <
> st...@satoshilabs.com>, Aaron Chen , Rodolfo
> Novak 
>   Comments-Summary: No comments yet.
>   Comments-URI:
>   Status: Proposed
>   Type: Standards Track
>   Created: 2020-11-10
>   License: BSD-2-Clause
> 
>
> ==Introduction==
>
> ===Abstract===
>
> This document proposes a mechanism to set up multisig wallets securely.
>
> ===Copyright===
>
> This BIP is licensed under the 2-clause BSD license.
>
> ===Motivation===
>
> The Bitcoin multisig experience has been greatly streamlined under [
> https://github.com/bitcoin/bips/blob/master/bip-0174.mediawiki BIP-0174
> (Partially Signed Bitcoin Transaction)]. However, what is still missing is
> a standardized process for setting up multisig wallets securely across
> different vendors.
>
> There are a number of concerns when it comes to setting up a multisig
> wallet:
>
> # Whether the multisig configuration, such as Signer membership, script
> type, derivation paths and number of signatures required, is correct and
> not tampered with.
> # Whether Signer persists the multisig configuration in their respective
> storage, and under what format.
> # Whether Signer's storage is tamper-proof.
> # Whether Signer subsequently uses the multisig configuration to generate
> and verify receive and change addresses.
>
> An attacker who can modify the multisig configuration can steal or hold
> funds to ransom by duping the user into sending funds to the wrong address.
>
> This proposal seeks to address concerns #1 and #2: to mitigate the risk of
> tampering during the initial setup phase, and to define an interoperable
> multisig configuration format.
>
> Concerns #3 and #4 should be handled by Signers and is out of scope of
> this proposal.
>
> ==Specification==
>
> ===Prerequisites===
> This proposal assumes the parties in the multisig support [
> https://github.com/bitcoin/bips/blob/master/bip-0032.mediawiki BIP-0032],
> [https://github.com/bitcoin/bitcoin/blob/master/doc/descriptors.md the
> descriptor language] and encryption.
>
> ===Roles===
> Coordinator
>
> The Coordinator initiates the multisig setup. The Coordinator determines
> what type of multisig is used and the exact policy script. If encryption is
> enabled, the Coordinator also distributes a shared

Re: [bitcoin-dev] Proposal: Bitcoin Secure Multisig Setup

[Hugo Nguyen via bitcoin-dev]

Hi all,
I have updated the proposal based on further feedback. The new spec is
included at the bottom.

I have also created a public Github PR to make it easier to comment on the
text of the spec itself: https://github.com/nunchuk-io/bips/pull/1 .

Could someone please let me know what else needs to be done before a BIP
number can be assigned?


=== Quick summary of changes from last update ===

1. Define encryption modes

# NO_ENCRYPTION: Encryption is disabled.
# STANDARD : the TOKEN is a 64-bit nonce.
# EXTENDED : the TOKEN is a 128-bit nonce.

2. Define signature algorithm

Follow BIP-0322, legacy format allowed.

3. Multiple TOKENs (optional)

Also add an option where the Coordinator can choose to use one common TOKEN
for all Signers, or use one per Signer.

=== End of summary ===


Cheers,
Hugo



  BIP: To be determined
  Layer: Applications
  Title: Bitcoin Secure Multisig Setup (BSMS)
  Author: Hugo Nguyen , Peter Gray , Marko Bencun , Pavol Rusnak <
st...@satoshilabs.com>, Aaron Chen , Rodolfo
Novak 
  Comments-Summary: No comments yet.
  Comments-URI:
  Status: Proposed
  Type: Standards Track
  Created: 2020-11-10
  License: BSD-2-Clause


==Introduction==

===Abstract===

This document proposes a mechanism to set up multisig wallets securely.

===Copyright===

This BIP is licensed under the 2-clause BSD license.

===Motivation===

The Bitcoin multisig experience has been greatly streamlined under [
https://github.com/bitcoin/bips/blob/master/bip-0174.mediawiki BIP-0174
(Partially Signed Bitcoin Transaction)]. However, what is still missing is
a standardized process for setting up multisig wallets securely across
different vendors.

There are a number of concerns when it comes to setting up a multisig
wallet:

# Whether the multisig configuration, such as Signer membership, script
type, derivation paths and number of signatures required, is correct and
not tampered with.
# Whether Signer persists the multisig configuration in their respective
storage, and under what format.
# Whether Signer's storage is tamper-proof.
# Whether Signer subsequently uses the multisig configuration to generate
and verify receive and change addresses.

An attacker who can modify the multisig configuration can steal or hold
funds to ransom by duping the user into sending funds to the wrong address.

This proposal seeks to address concerns #1 and #2: to mitigate the risk of
tampering during the initial setup phase, and to define an interoperable
multisig configuration format.

Concerns #3 and #4 should be handled by Signers and is out of scope of this
proposal.

==Specification==

===Prerequisites===
This proposal assumes the parties in the multisig support [
https://github.com/bitcoin/bips/blob/master/bip-0032.mediawiki BIP-0032], [
https://github.com/bitcoin/bitcoin/blob/master/doc/descriptors.md the
descriptor language] and encryption.

===Roles===
Coordinator

The Coordinator initiates the multisig setup. The Coordinator determines
what type of multisig is used and the exact policy script. If encryption is
enabled, the Coordinator also distributes a shared secret or shared secrets
to the parties involved for secure communication. The Coordinator gathers
information from the Signers to generate a descriptor record. The
Coordinator distributes the descriptor record back to the Signers.

Signer

The Signer is a participating member in the multisig. Its responsibilities
include providing its key record -- which contains an Extended Public Key
(XPUB) -- to the Coordinator, verifying that its XPUB is included in the
descriptor record and persisting the descriptor record in its storage.

===Setup Process===

Round 1

=Coordinator=

* The Coordinator creates a multisig wallet creation session. The
Coordinator constructs the multisig script and its policy parameters, such
as the total number of signers and the required number of signatures
(M and N).
* The session should expire after some time period determined by the
Coordinator, e.g., 24 hours.
* If encryption is enabled, the Coordinator distributes a secret
TOKEN to each Signer over a secure channel. The Signer can use the
TOKEN to derive an ENCRYPTION_KEY. Refer to the
Encryption section below for details on the TOKEN, the key
derivation function and the encryption scheme. Depending on the use case,
the Coordinator can decide whether to share one common TOKEN for
all Signers, or to have one per Signer.
* If encryption is disabled, TOKEN is set to 0, and all
the encryption/decryption steps below can be skipped.

=Signer=

* The Signer initiates a new secure multisig setup session by setting the
TOKEN. The Signer derives an ENCRYPTION_KEY from the
TOKEN. The Signer can keep the session open until a different
value for the TOKEN is set.
* The Signer generates a key record by prompting the user for a multisig
derivation path and retrieves the XPUB at that derivation path. Optionally,
the Signer can choose a path on behalf of the user

Re: [bitcoin-dev] Proposal: Bitcoin Secure Multisig Setup

[Dmitry Petukhov via bitcoin-dev]

After off-list discussion with Hugo, I'm convinced that
adding a requirement for signers to derive participant ids is
unnecessary complication that only buys slight convenience for
coordinator, and this is not a net positive tradeoff.

And since the coordinator can choose to generate unique TOKEN per
participant without participants even knowing about this, there's
probably no reason to mention this possibility in the spec, either.

В Sun, 14 Feb 2021 11:37:52 +0100
Dmitry Petukhov  wrote:

> I think that it is better to issue individual TOKEN for each
> participant. Otherwise it will be possible for one participant to
> attack another (intercept and replace their xpub sent to the
> coordinator).
> 
> It will also be convenient to have a public 'participant id', derived
> from the token. It can be derived from the same token, but with
> different (but fixed) `Pwd`. With unique token per participant, such
> derivation will uniquely identify each participant, so the coordinator
> won't need to try all the tokens to decrypt the data.
> 
> It will also be easier to deal with more elaborate setups where the
> position of the xpub in the descriptor does matter - for example, with
> miniscript-extended descriptors. With a descriptor template such as
> 
> `wsh(or(multi(2, , , ), older(1000, ))`
> 
> The coordinator will be able to store the map between the participant
> labels (Alice, Bob, Carol, Dylan) and their participant ids (and the
> TOKENs). When the data from Alice comes with participant id attached,
> the coordinator will immediately know which TOKEN to use, and which
> place in the descriptor the xpub should be put in.
> 
> Of course this is all possible without 'participant id' derived from
> token, as long as there's unique TOKEN per participant - the
> coordinator can always try all the tokens to decrypt the data from
> participant. But implementors will likely invent their own ways to
> introduce 'participant id' anyway, as this is more convenient, and it
> might make sense to have this standardized, for interoperability. 
> 
> В Fri, 12 Feb 2021 09:54:57 -0800
> Hugo Nguyen  wrote:
> 
> > On Fri, Feb 12, 2021 at 9:36 AM Dmitry Petukhov 
> > wrote:
> >   
> > > If HUMAN_READABLE_TITLE is the additional secret, the user would
> > > need to enter it on the device in addition to the nonce, wouldn't
> > > it defeat the advantage in UX that was gained by using
> > > (relatively) short nonce ?
> > >
> > > Is 64 bit nonce not enough ?
> > >
> > >
> > Good question. If we don't need the extra entropy, we can fix
> > the HUMAN_READABLE_TITLE string.
> > 
> > Something like "No SPOF". (No Single Point Of Failure).
> > 
> > 
> >   
> > > It seems that to crack this with fixed Pwd and 64 bit nonce, the
> > > attacker will need to be about 10^15 more powerful than 80Mhz MCU:
> > > (2^64)/(0.3*10^15)/3600 = 17 hours. I don't know if 10^15 is
> > > realistic scale. Average desktop cpu seems to be about 10^3 more
> > > powerful than the mentioned MCU for this task.
> > >
> > > Maybe for the UX it would be better to choose the number of rounds
> > > to use in PBKDF2, instead of using variable Pwd. Number of rounds
> > > will be easier to enter on the device (or just choose it from a
> > > set of pre-defined values). The more money is at stake, the higher
> > > number of rounds could the coordinator choose (taking into account
> > > the characteristics of the participant devices)
> > >
> >   
> > > Or simply allow bigger entropy (more than 6 mnemonic words), if
> > > the coordinator feels that 64 bit of entropy is not enough.
> > 
> > 
> > That could work. Allowing variable iteration count is probably
> > better UX-wise.
> > 
> > Best,
> > Hugo
> > 
> >   
> > >
> > > В Fri, 12 Feb 2021 08:55:55 -0800
> > > Hugo Nguyen  wrote:
> > >
> > > > Thanks everyone who has provided inputs so far!
> > > >
> > > > This is the new proposal for the encryption aspect of the
> > > > scheme, based on all the feedback.
> > > >
> > > > The key derivation function would be PBKDF2, with PRF = SHA512.
> > > > This should be readily available on today's hardware already, as
> > > > they are used for BIP39.
> > > >
> > > > DK = PBKDF2(PRF, Password, Salt, c, dkLen)
> > > > PRF = SHA512
> > > > Pwd = HUMAN_READABLE_TITLE
> > > > Salt = NONCE
> > > > c = 2048
> > > > dkLen = 256
> > > >
> > > > HUMAN_READABLE_TITLE is in ASCII format, minimum length = 8,
> > > > maximum length = 20.
> > > > NONCE is a 64-bit number.
> > > >
> > > > Reason for going with SHA512 is due to legacy support on some
> > > > hardware. c=2048 also mimics BIP39. It takes about ~3 seconds to
> > > > derive the encryption key on a 80Mhz MCU. We feel like this is a
> > > > good enough tradeoff for this use case. The assumption here is
> > > > that the secure session is only needed temporarily for a few
> > > > hours, maybe up to one day.
> > > >
> > > > The Coordinator and Signers agree and exchange these 2 secrets
> > > > prior to the setup. The NONCE can

Re: [bitcoin-dev] Proposal: Bitcoin Secure Multisig Setup

[Dmitry Petukhov via bitcoin-dev]

I think that it is better to issue individual TOKEN for each
participant. Otherwise it will be possible for one participant to
attack another (intercept and replace their xpub sent to the
coordinator).

It will also be convenient to have a public 'participant id', derived
from the token. It can be derived from the same token, but with
different (but fixed) `Pwd`. With unique token per participant, such
derivation will uniquely identify each participant, so the coordinator
won't need to try all the tokens to decrypt the data.

It will also be easier to deal with more elaborate setups where the
position of the xpub in the descriptor does matter - for example, with
miniscript-extended descriptors. With a descriptor template such as

`wsh(or(multi(2, , , ), older(1000, ))`

The coordinator will be able to store the map between the participant
labels (Alice, Bob, Carol, Dylan) and their participant ids (and the
TOKENs). When the data from Alice comes with participant id attached,
the coordinator will immediately know which TOKEN to use, and which
place in the descriptor the xpub should be put in.

Of course this is all possible without 'participant id' derived from
token, as long as there's unique TOKEN per participant - the coordinator
can always try all the tokens to decrypt the data from participant. But
implementors will likely invent their own ways to introduce
'participant id' anyway, as this is more convenient, and it might make
sense to have this standardized, for interoperability. 

В Fri, 12 Feb 2021 09:54:57 -0800
Hugo Nguyen  wrote:

> On Fri, Feb 12, 2021 at 9:36 AM Dmitry Petukhov 
> wrote:
> 
> > If HUMAN_READABLE_TITLE is the additional secret, the user would
> > need to enter it on the device in addition to the nonce, wouldn't
> > it defeat the advantage in UX that was gained by using (relatively)
> > short nonce ?
> >
> > Is 64 bit nonce not enough ?
> >
> >  
> Good question. If we don't need the extra entropy, we can fix
> the HUMAN_READABLE_TITLE string.
> 
> Something like "No SPOF". (No Single Point Of Failure).
> 
> 
> 
> > It seems that to crack this with fixed Pwd and 64 bit nonce, the
> > attacker will need to be about 10^15 more powerful than 80Mhz MCU:
> > (2^64)/(0.3*10^15)/3600 = 17 hours. I don't know if 10^15 is
> > realistic scale. Average desktop cpu seems to be about 10^3 more
> > powerful than the mentioned MCU for this task.
> >
> > Maybe for the UX it would be better to choose the number of rounds
> > to use in PBKDF2, instead of using variable Pwd. Number of rounds
> > will be easier to enter on the device (or just choose it from a set
> > of pre-defined values). The more money is at stake, the higher
> > number of rounds could the coordinator choose (taking into account
> > the characteristics of the participant devices)
> >  
> 
> > Or simply allow bigger entropy (more than 6 mnemonic words), if
> > the coordinator feels that 64 bit of entropy is not enough.  
> 
> 
> That could work. Allowing variable iteration count is probably better
> UX-wise.
> 
> Best,
> Hugo
> 
> 
> >
> > В Fri, 12 Feb 2021 08:55:55 -0800
> > Hugo Nguyen  wrote:
> >  
> > > Thanks everyone who has provided inputs so far!
> > >
> > > This is the new proposal for the encryption aspect of the scheme,
> > > based on all the feedback.
> > >
> > > The key derivation function would be PBKDF2, with PRF = SHA512.
> > > This should be readily available on today's hardware already, as
> > > they are used for BIP39.
> > >
> > > DK = PBKDF2(PRF, Password, Salt, c, dkLen)
> > > PRF = SHA512
> > > Pwd = HUMAN_READABLE_TITLE
> > > Salt = NONCE
> > > c = 2048
> > > dkLen = 256
> > >
> > > HUMAN_READABLE_TITLE is in ASCII format, minimum length = 8,
> > > maximum length = 20.
> > > NONCE is a 64-bit number.
> > >
> > > Reason for going with SHA512 is due to legacy support on some
> > > hardware. c=2048 also mimics BIP39. It takes about ~3 seconds to
> > > derive the encryption key on a 80Mhz MCU. We feel like this is a
> > > good enough tradeoff for this use case. The assumption here is
> > > that the secure session is only needed temporarily for a few
> > > hours, maybe up to one day.
> > >
> > > The Coordinator and Signers agree and exchange these 2 secrets
> > > prior to the setup. The NONCE can be converted to either:
> > > (a) a 6-word phrase using BIP39 wordlist
> > > (b) a 20-digit decimal number
> > > (c) a QR code
> > >
> > > Depending on the vendor. This flexibility in the data format
> > > allows each vendor to customize the UX based on their respective
> > > device capabilities.
> > >
> > > Best,
> > > Hugo
> > >
> > > On Thu, Feb 11, 2021 at 8:25 AM Dmitry Petukhov via bitcoin-dev <
> > > bitcoin-dev@lists.linuxfoundation.org> wrote:
> > >  
> > > > В Thu, 11 Feb 2021 05:45:33 -0800
> > > > Hugo Nguyen via bitcoin-dev
> > > >  wrote:
> > > >  
> > > > > > > ENCRYPTION_KEY = SHA256(SHA256(TOKEN))  
> > > > > >
> > > > > > This scheme might be vulnerable to rainbow table attack.
> > > > > >  
> > > > >

Re: [bitcoin-dev] Proposal: Bitcoin Secure Multisig Setup

[Hugo Nguyen via bitcoin-dev]

On Fri, Feb 12, 2021 at 9:36 AM Dmitry Petukhov  wrote:

> If HUMAN_READABLE_TITLE is the additional secret, the user would need
> to enter it on the device in addition to the nonce, wouldn't it defeat
> the advantage in UX that was gained by using (relatively) short nonce ?
>
> Is 64 bit nonce not enough ?
>
>
Good question. If we don't need the extra entropy, we can fix
the HUMAN_READABLE_TITLE string.

Something like "No SPOF". (No Single Point Of Failure).



> It seems that to crack this with fixed Pwd and 64 bit nonce, the
> attacker will need to be about 10^15 more powerful than 80Mhz MCU:
> (2^64)/(0.3*10^15)/3600 = 17 hours. I don't know if 10^15 is realistic
> scale. Average desktop cpu seems to be about 10^3 more powerful than
> the mentioned MCU for this task.
>
> Maybe for the UX it would be better to choose the number of rounds to
> use in PBKDF2, instead of using variable Pwd. Number of rounds will be
> easier to enter on the device (or just choose it from a set of
> pre-defined values). The more money is at stake, the higher number of
> rounds could the coordinator choose (taking into account the
> characteristics of the participant devices)
>

> Or simply allow bigger entropy (more than 6 mnemonic words), if
> the coordinator feels that 64 bit of entropy is not enough.


That could work. Allowing variable iteration count is probably better
UX-wise.

Best,
Hugo


>
> В Fri, 12 Feb 2021 08:55:55 -0800
> Hugo Nguyen  wrote:
>
> > Thanks everyone who has provided inputs so far!
> >
> > This is the new proposal for the encryption aspect of the scheme,
> > based on all the feedback.
> >
> > The key derivation function would be PBKDF2, with PRF = SHA512. This
> > should be readily available on today's hardware already, as they are
> > used for BIP39.
> >
> > DK = PBKDF2(PRF, Password, Salt, c, dkLen)
> > PRF = SHA512
> > Pwd = HUMAN_READABLE_TITLE
> > Salt = NONCE
> > c = 2048
> > dkLen = 256
> >
> > HUMAN_READABLE_TITLE is in ASCII format, minimum length = 8, maximum
> > length = 20.
> > NONCE is a 64-bit number.
> >
> > Reason for going with SHA512 is due to legacy support on some
> > hardware. c=2048 also mimics BIP39. It takes about ~3 seconds to
> > derive the encryption key on a 80Mhz MCU. We feel like this is a good
> > enough tradeoff for this use case. The assumption here is that the
> > secure session is only needed temporarily for a few hours, maybe up
> > to one day.
> >
> > The Coordinator and Signers agree and exchange these 2 secrets prior
> > to the setup. The NONCE can be converted to either:
> > (a) a 6-word phrase using BIP39 wordlist
> > (b) a 20-digit decimal number
> > (c) a QR code
> >
> > Depending on the vendor. This flexibility in the data format allows
> > each vendor to customize the UX based on their respective device
> > capabilities.
> >
> > Best,
> > Hugo
> >
> > On Thu, Feb 11, 2021 at 8:25 AM Dmitry Petukhov via bitcoin-dev <
> > bitcoin-dev@lists.linuxfoundation.org> wrote:
> >
> > > В Thu, 11 Feb 2021 05:45:33 -0800
> > > Hugo Nguyen via bitcoin-dev 
> > > wrote:
> > >
> > > > > > ENCRYPTION_KEY = SHA256(SHA256(TOKEN))
> > > > >
> > > > > This scheme might be vulnerable to rainbow table attack.
> > > > >
> > > >
> > > > Thank you for pointing this out! Incidentally, Dmitry Petukhov
> > > > also told me the same privately.
> > >
> > > My thought was that if TOKEN has the characteristics of a password
> > > (short ASCII string), then it would be better to use key derivation
> > > function designed for passwords, like PBKDF2.
> > >
> > > The counter-argument to this is that this adds another code
> > > dependency for vendors, if the device firmware does not already
> > > have the required key derivation function.
> > >
> > > Maybe this could be solved by going into opposite direction - make
> > > the "token" even longer, use the mnemoic.
> > >
> > > The issue is that entering long data of the shared key into the
> > > device manually is difficult UX-wise.
> > >
> > > Hww vendors that allow to enter custom keys into their device
> > > already have to face this issue, and those who allow to enter
> > > custom keys via mnemonic probably tackled this somehow.
> > >
> > > Maybe the shared key for multisig setup can be entered in the same
> > > way ? (with maybe additional visual check via some fingerprint).
> > >
> > > Although we would then have another issue of potential confusion
> > > between two procedures (entering the main key and entering the
> > > shared key for multisig setup), and the measures has to be taken to
> > > prevent such confusion.
> > >
> > > The approaches can be combined - specify a key derivation function
> > > suitable for passwords; via secure channel, share a password and/or
> > > the derived key. If hww supports derivation function, it can derive
> > > the key from password. If hww supports only keys, the key can be
> > > entered raw or via mnemonic.
> > > ___
> > > bitcoin-dev mailing list
> > > 

Re: [bitcoin-dev] Proposal: Bitcoin Secure Multisig Setup

[Dmitry Petukhov via bitcoin-dev]

If HUMAN_READABLE_TITLE is the additional secret, the user would need
to enter it on the device in addition to the nonce, wouldn't it defeat
the advantage in UX that was gained by using (relatively) short nonce ?

Is 64 bit nonce not enough ?

It seems that to crack this with fixed Pwd and 64 bit nonce, the
attacker will need to be about 10^15 more powerful than 80Mhz MCU:
(2^64)/(0.3*10^15)/3600 = 17 hours. I don't know if 10^15 is realistic
scale. Average desktop cpu seems to be about 10^3 more powerful than
the mentioned MCU for this task.

Maybe for the UX it would be better to choose the number of rounds to
use in PBKDF2, instead of using variable Pwd. Number of rounds will be
easier to enter on the device (or just choose it from a set of
pre-defined values). The more money is at stake, the higher number of
rounds could the coordinator choose (taking into account the
characteristics of the participant devices)

В Fri, 12 Feb 2021 08:55:55 -0800
Hugo Nguyen  wrote:

> Thanks everyone who has provided inputs so far!
> 
> This is the new proposal for the encryption aspect of the scheme,
> based on all the feedback.
> 
> The key derivation function would be PBKDF2, with PRF = SHA512. This
> should be readily available on today's hardware already, as they are
> used for BIP39.
> 
> DK = PBKDF2(PRF, Password, Salt, c, dkLen)
> PRF = SHA512
> Pwd = HUMAN_READABLE_TITLE
> Salt = NONCE
> c = 2048
> dkLen = 256
> 
> HUMAN_READABLE_TITLE is in ASCII format, minimum length = 8, maximum
> length = 20.
> NONCE is a 64-bit number.
> 
> Reason for going with SHA512 is due to legacy support on some
> hardware. c=2048 also mimics BIP39. It takes about ~3 seconds to
> derive the encryption key on a 80Mhz MCU. We feel like this is a good
> enough tradeoff for this use case. The assumption here is that the
> secure session is only needed temporarily for a few hours, maybe up
> to one day.
> 
> The Coordinator and Signers agree and exchange these 2 secrets prior
> to the setup. The NONCE can be converted to either:
> (a) a 6-word phrase using BIP39 wordlist
> (b) a 20-digit decimal number
> (c) a QR code
> 
> Depending on the vendor. This flexibility in the data format allows
> each vendor to customize the UX based on their respective device
> capabilities.
> 
> Best,
> Hugo
> 
> On Thu, Feb 11, 2021 at 8:25 AM Dmitry Petukhov via bitcoin-dev <
> bitcoin-dev@lists.linuxfoundation.org> wrote:
> 
> > В Thu, 11 Feb 2021 05:45:33 -0800
> > Hugo Nguyen via bitcoin-dev 
> > wrote:
> >  
> > > > > ENCRYPTION_KEY = SHA256(SHA256(TOKEN))  
> > > >
> > > > This scheme might be vulnerable to rainbow table attack.
> > > >  
> > >
> > > Thank you for pointing this out! Incidentally, Dmitry Petukhov
> > > also told me the same privately.  
> >
> > My thought was that if TOKEN has the characteristics of a password
> > (short ASCII string), then it would be better to use key derivation
> > function designed for passwords, like PBKDF2.
> >
> > The counter-argument to this is that this adds another code
> > dependency for vendors, if the device firmware does not already
> > have the required key derivation function.
> >
> > Maybe this could be solved by going into opposite direction - make
> > the "token" even longer, use the mnemoic.
> >
> > The issue is that entering long data of the shared key into the
> > device manually is difficult UX-wise.
> >
> > Hww vendors that allow to enter custom keys into their device
> > already have to face this issue, and those who allow to enter
> > custom keys via mnemonic probably tackled this somehow.
> >
> > Maybe the shared key for multisig setup can be entered in the same
> > way ? (with maybe additional visual check via some fingerprint).
> >
> > Although we would then have another issue of potential confusion
> > between two procedures (entering the main key and entering the
> > shared key for multisig setup), and the measures has to be taken to
> > prevent such confusion.
> >
> > The approaches can be combined - specify a key derivation function
> > suitable for passwords; via secure channel, share a password and/or
> > the derived key. If hww supports derivation function, it can derive
> > the key from password. If hww supports only keys, the key can be
> > entered raw or via mnemonic.
> > ___
> > bitcoin-dev mailing list
> > bitcoin-dev@lists.linuxfoundation.org
> > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
> >  

___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] Proposal: Bitcoin Secure Multisig Setup

[Dmitry Petukhov via bitcoin-dev]

В Fri, 12 Feb 2021 18:42:31 +0100
Dmitry Petukhov  wrote:

> Maybe for the UX it would be better to choose the number of rounds to
> use in PBKDF2, instead of using variable Pwd. Number of rounds will be
> easier to enter on the device (or just choose it from a set of
> pre-defined values). The more money is at stake, the higher number of
> rounds could the coordinator choose (taking into account the
> characteristics of the participant devices)

Or simply allow bigger entropy (more than 6 mnemonic words), if
the coordinator feels that 64 bit of entropy is not enough.
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] Proposal: Bitcoin Secure Multisig Setup

[Hugo Nguyen via bitcoin-dev]

Thanks everyone who has provided inputs so far!

This is the new proposal for the encryption aspect of the scheme, based on
all the feedback.

The key derivation function would be PBKDF2, with PRF = SHA512. This should
be readily available on today's hardware already, as they are used for
BIP39.

DK = PBKDF2(PRF, Password, Salt, c, dkLen)
PRF = SHA512
Pwd = HUMAN_READABLE_TITLE
Salt = NONCE
c = 2048
dkLen = 256

HUMAN_READABLE_TITLE is in ASCII format, minimum length = 8, maximum length
= 20.
NONCE is a 64-bit number.

Reason for going with SHA512 is due to legacy support on some hardware.
c=2048 also mimics BIP39. It takes about ~3 seconds to derive
the encryption key on a 80Mhz MCU. We feel like this is a good enough
tradeoff for this use case. The assumption here is that the secure session
is only needed temporarily for a few hours, maybe up to one day.

The Coordinator and Signers agree and exchange these 2 secrets prior to the
setup. The NONCE can be converted to either:
(a) a 6-word phrase using BIP39 wordlist
(b) a 20-digit decimal number
(c) a QR code

Depending on the vendor. This flexibility in the data format allows each
vendor to customize the UX based on their respective device capabilities.

Best,
Hugo

On Thu, Feb 11, 2021 at 8:25 AM Dmitry Petukhov via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:

> В Thu, 11 Feb 2021 05:45:33 -0800
> Hugo Nguyen via bitcoin-dev 
> wrote:
>
> > > > ENCRYPTION_KEY = SHA256(SHA256(TOKEN))
> > >
> > > This scheme might be vulnerable to rainbow table attack.
> > >
> >
> > Thank you for pointing this out! Incidentally, Dmitry Petukhov also
> > told me the same privately.
>
> My thought was that if TOKEN has the characteristics of a password
> (short ASCII string), then it would be better to use key derivation
> function designed for passwords, like PBKDF2.
>
> The counter-argument to this is that this adds another code dependency
> for vendors, if the device firmware does not already have the required
> key derivation function.
>
> Maybe this could be solved by going into opposite direction - make the
> "token" even longer, use the mnemoic.
>
> The issue is that entering long data of the shared key into the device
> manually is difficult UX-wise.
>
> Hww vendors that allow to enter custom keys into their device already
> have to face this issue, and those who allow to enter custom keys via
> mnemonic probably tackled this somehow.
>
> Maybe the shared key for multisig setup can be entered in the same way
> ? (with maybe additional visual check via some fingerprint).
>
> Although we would then have another issue of potential confusion
> between two procedures (entering the main key and entering the shared
> key for multisig setup), and the measures has to be taken to prevent
> such confusion.
>
> The approaches can be combined - specify a key derivation function
> suitable for passwords; via secure channel, share a password and/or the
> derived key. If hww supports derivation function, it can derive the key
> from password. If hww supports only keys, the key can be entered raw or
> via mnemonic.
> ___
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] Proposal: Bitcoin Secure Multisig Setup

[Peter D. Gray via bitcoin-dev]

Hard no to this idea:

On Thu, Feb 11, 2021 at 02:29:46PM -0800, Christopher Allen proposed:
...
> /48'/0'/0'/3'/PBKDF(complex string)'

As someone who has helped people find UTXO at key paths they didn't
know/want, this is a terrible idea. Key derivation paths should be
small, sequential integers, so they can be searched in reasonable time.

Of course when things are working it doesn't matter, but the stakes
can be very high when they stop working.

This is true for multisig and single signer.

---
Peter D. Gray  ||  Founder, Coinkite  ||  Twitter: @dochex  ||  GPG: A3A31BAD 
5A2A5B10

On Thu, Feb 11, 2021 at 02:29:46PM -0800, Christopher Allen wrote:
> I think the key issue here is avoiding xpub key reuse in multisig. Not only
> in the future with Schnorr, but we need it today!
> 
> Current common practice by hardware wallets is the 48'/0'/0'/2' derivation
> for segwit multsig ( e.g.
> [90081696/48'/0'/0'/2']xpub6DYLEkDfCdHzh5FHGHDJksQvFqu6kYANa1sfo6fA8n5ZWkSwyCRVVzyq9LY2eNGB6T9BKDeGJp2ZarjRZHd7WB95nSaFEDhFMK6zSV6D49b
> ) is the only one used for ALL multisigs offered by that hardware wallet.
> 
> As Pieter said, leveraging a HD path parameters can help, but we need a
> better, less reusable path for the index.
> 
> I personally suggest a simpler solution, which is to create an index using
> a PBKDF of the Account Policy (a descriptor with all xpubs and keys
> removed), plus optional notes. (BTW, I think double sha256 or HMAC is
> overkill).
> 
> Example: for the reference bit descriptor that might result in:
> 
> ```
> wsh(sortedmulti(2,xpub661MyMwAqRbcFW31YEwpkMuc5THy2PSt5bDMsktWQcFF8syAmRUapSCGu8ED9W6oDMSgv6Zz8idoc4a6mr8BDzTJY47LJhkJ8UB7WEGuduB/1/0/*,xpub69H7F5d8KSRgmmdJg2KhpAK8SR3DjMwAdkxj3ZuxV27CprR9LgpeyGmXUbC6wb7ERfvrnKZjXoUmmDznezpbZb7ap6r1D3tgFxHmwMkQTPH/0/0/*))
> ```
> 
> What Blockchain Commons (and the Airgapped Wallet Community) call a policy
> map would be
> 
> ```
> wsh(sortedmulti(1,,,))
> ```
> 
> A PBKDF of that as would be unique for all 2 of 3 segwig transactions. With
> the addition of the addition of the Policy Map creators optional note, it
> would be truly unique. The Policy Map and/or PBKDF are small and could
> easily added to existing APIs.
> 
> So for legacy hardware, we can use existing 48' subtree, but 3' as the
> format for this form (2' is segwit), then the desktop can just ask for the
> /48'/0'/0'/3'/PBKDF' when it requests a new xpub from the hardware token.
> More sophisticated Airgapped apps you can send
> "wsh(sortedmulti(1,,,))"+label and let the cosigner app do the PBKDF, and
> optionally allow it return something different in a full keyset (i.e.
> "[90081696/48'/0'/0'/3'/af3948cg…'/]xpub6DYLEk…", and then the requesting
> app, knowing that it is different from the PBKDF can know what to do if it
> needs to what to ask for in the future.
> 
> The other advantage of this technique is that the cosigner app can know
> what policy it is participating in, before the descriptor is completed. It
> may decide it doesn't want to participate in some funky 4:9 with a weird
> script, and not return an xpub at all.
> 
> Long term I think a commitment scheme should be used, so that you don't
> reveal what xpub you offered until all the parties xpubs are shared, but as
> Pieter said, we can do that at the same time we do the musig. But we need
> to prevent xpub reuse NOW, and I think my proposal easy and could the job.
> 
> -- Christopher Allen, Blockchain Commons




signature.asc
Description: PGP signature
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] Proposal: Bitcoin Secure Multisig Setup

[Hugo Nguyen via bitcoin-dev]

On Thu, Feb 11, 2021 at 3:05 PM Christopher Allen via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:

> What Blockchain Commons (and the Airgapped Wallet Community) call a policy
> map would be
>
> ```
> wsh(sortedmulti(1,,,))
> ```
>
> A PBKDF of that as would be unique for all 2 of 3 segwig transactions.
> With the addition of the addition of the Policy Map creators optional note,
> it would be truly unique. The Policy Map and/or PBKDF are small and could
> easily added to existing APIs.
>
> So for legacy hardware, we can use existing 48' subtree, but 3' as the
> format for this form (2' is segwit), then the desktop can just ask for the
> /48'/0'/0'/3'/PBKDF' when it requests a new xpub from the hardware token.
> More sophisticated Airgapped apps you can send
> "wsh(sortedmulti(1,,,))"+label and let the cosigner app do the PBKDF, and
> optionally allow it return something different in a full keyset (i.e.
> "[90081696/48'/0'/0'/3'/af3948cg…'/]xpub6DYLEk…", and then the requesting
> app, knowing that it is different from the PBKDF can know what to do if it
> needs to what to ask for in the future.
>

Thanks Christopher, very interesting ideas... A couple of thoughts:
1/ Generating the path index using the policy is clever. However, I think
it has 2 problems. Number #1 is with the above scheme now you have a hard
dependency on (policy map + note) - losing (policy map + note) means that
you will lose access to PBKDF', and hence the funds permanently. At least
with the current soluttions, you can look up what the most common
derivation paths and indices are to recover funds in the worst case.
2/ Number #2 is that this wouldn't necessarily prevent XPUB reuse. It seems
like the above scheme depends on (a) the Coordinator keeping track
accurately of all the existing PBKDF-ed indices and (b) the Signer
truthfully gives the XPUB at the path that the Coordinator asks for. In
reality, neither of these conditions can be guaranteed. For example, the
Signer could lie about the XPUB at /48'/0'/0'/3'/PBKDF' when it just keeps
reusing the XPUB at /48'/0'/0'/2'
3/ Preventing XPUB reuse is an interesting problem, but IMHO it is beyond
the scope of the current proposal. Maybe worth a separate BIP?

Best,
Hugo



On Thu, Feb 11, 2021 at 3:05 PM Christopher Allen via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:

> I think the key issue here is avoiding xpub key reuse in multisig. Not
> only in the future with Schnorr, but we need it today!
>
> Current common practice by hardware wallets is the 48'/0'/0'/2' derivation
> for segwit multsig ( e.g.
> [90081696/48'/0'/0'/2']xpub6DYLEkDfCdHzh5FHGHDJksQvFqu6kYANa1sfo6fA8n5ZWkSwyCRVVzyq9LY2eNGB6T9BKDeGJp2ZarjRZHd7WB95nSaFEDhFMK6zSV6D49b
> ) is the only one used for ALL multisigs offered by that hardware wallet.
>
> As Pieter said, leveraging a HD path parameters can help, but we need a
> better, less reusable path for the index.
>
> I personally suggest a simpler solution, which is to create an index using
> a PBKDF of the Account Policy (a descriptor with all xpubs and keys
> removed), plus optional notes. (BTW, I think double sha256 or HMAC is
> overkill).
>
> Example: for the reference bit descriptor that might result in:
>
> ```
>
> wsh(sortedmulti(2,xpub661MyMwAqRbcFW31YEwpkMuc5THy2PSt5bDMsktWQcFF8syAmRUapSCGu8ED9W6oDMSgv6Zz8idoc4a6mr8BDzTJY47LJhkJ8UB7WEGuduB/1/0/*,xpub69H7F5d8KSRgmmdJg2KhpAK8SR3DjMwAdkxj3ZuxV27CprR9LgpeyGmXUbC6wb7ERfvrnKZjXoUmmDznezpbZb7ap6r1D3tgFxHmwMkQTPH/0/0/*))
> ```
>
> What Blockchain Commons (and the Airgapped Wallet Community) call a policy
> map would be
>
> ```
> wsh(sortedmulti(1,,,))
> ```
>
> A PBKDF of that as would be unique for all 2 of 3 segwig transactions.
> With the addition of the addition of the Policy Map creators optional note,
> it would be truly unique. The Policy Map and/or PBKDF are small and could
> easily added to existing APIs.
>
> So for legacy hardware, we can use existing 48' subtree, but 3' as the
> format for this form (2' is segwit), then the desktop can just ask for the
> /48'/0'/0'/3'/PBKDF' when it requests a new xpub from the hardware token.
> More sophisticated Airgapped apps you can send
> "wsh(sortedmulti(1,,,))"+label and let the cosigner app do the PBKDF, and
> optionally allow it return something different in a full keyset (i.e.
> "[90081696/48'/0'/0'/3'/af3948cg…'/]xpub6DYLEk…", and then the requesting
> app, knowing that it is different from the PBKDF can know what to do if it
> needs to what to ask for in the future.
>
> The other advantage of this technique is that the cosigner app can know
> what policy it is participating in, before the descriptor is completed. It
> may decide it doesn't want to participate in some funky 4:9 with a weird
> script, and not return an xpub at all.
>
> Long term I think a commitment scheme should be used, so that you don't
> reveal what xpub you offered until all the parties xpubs are shared, but as
> Pieter said, we can do that at the same time we do t

Re: [bitcoin-dev] Proposal: Bitcoin Secure Multisig Setup

[Christopher Allen via bitcoin-dev]

I think the key issue here is avoiding xpub key reuse in multisig. Not only
in the future with Schnorr, but we need it today!

Current common practice by hardware wallets is the 48'/0'/0'/2' derivation
for segwit multsig ( e.g.
[90081696/48'/0'/0'/2']xpub6DYLEkDfCdHzh5FHGHDJksQvFqu6kYANa1sfo6fA8n5ZWkSwyCRVVzyq9LY2eNGB6T9BKDeGJp2ZarjRZHd7WB95nSaFEDhFMK6zSV6D49b
) is the only one used for ALL multisigs offered by that hardware wallet.

As Pieter said, leveraging a HD path parameters can help, but we need a
better, less reusable path for the index.

I personally suggest a simpler solution, which is to create an index using
a PBKDF of the Account Policy (a descriptor with all xpubs and keys
removed), plus optional notes. (BTW, I think double sha256 or HMAC is
overkill).

Example: for the reference bit descriptor that might result in:

```
wsh(sortedmulti(2,xpub661MyMwAqRbcFW31YEwpkMuc5THy2PSt5bDMsktWQcFF8syAmRUapSCGu8ED9W6oDMSgv6Zz8idoc4a6mr8BDzTJY47LJhkJ8UB7WEGuduB/1/0/*,xpub69H7F5d8KSRgmmdJg2KhpAK8SR3DjMwAdkxj3ZuxV27CprR9LgpeyGmXUbC6wb7ERfvrnKZjXoUmmDznezpbZb7ap6r1D3tgFxHmwMkQTPH/0/0/*))
```

What Blockchain Commons (and the Airgapped Wallet Community) call a policy
map would be

```
wsh(sortedmulti(1,,,))
```

A PBKDF of that as would be unique for all 2 of 3 segwig transactions. With
the addition of the addition of the Policy Map creators optional note, it
would be truly unique. The Policy Map and/or PBKDF are small and could
easily added to existing APIs.

So for legacy hardware, we can use existing 48' subtree, but 3' as the
format for this form (2' is segwit), then the desktop can just ask for the
/48'/0'/0'/3'/PBKDF' when it requests a new xpub from the hardware token.
More sophisticated Airgapped apps you can send
"wsh(sortedmulti(1,,,))"+label and let the cosigner app do the PBKDF, and
optionally allow it return something different in a full keyset (i.e.
"[90081696/48'/0'/0'/3'/af3948cg…'/]xpub6DYLEk…", and then the requesting
app, knowing that it is different from the PBKDF can know what to do if it
needs to what to ask for in the future.

The other advantage of this technique is that the cosigner app can know
what policy it is participating in, before the descriptor is completed. It
may decide it doesn't want to participate in some funky 4:9 with a weird
script, and not return an xpub at all.

Long term I think a commitment scheme should be used, so that you don't
reveal what xpub you offered until all the parties xpubs are shared, but as
Pieter said, we can do that at the same time we do the musig. But we need
to prevent xpub reuse NOW, and I think my proposal easy and could the job.

-- Christopher Allen, Blockchain Commons
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] Proposal: Bitcoin Secure Multisig Setup

[Hugo Nguyen via bitcoin-dev]

*BIP39 seed words list.

On Thu, Feb 11, 2021 at 11:11 AM Hugo Nguyen  wrote:

> Hi Pavol,
>
> On Thu, Feb 11, 2021 at 8:25 AM Dmitry Petukhov via bitcoin-dev <
> bitcoin-dev@lists.linuxfoundation.org> wrote:
>
>> В Thu, 11 Feb 2021 05:45:33 -0800
>> Hugo Nguyen via bitcoin-dev 
>> wrote:
>>
>> > > > ENCRYPTION_KEY = SHA256(SHA256(TOKEN))
>> > >
>> > > This scheme might be vulnerable to rainbow table attack.
>> > >
>> >
>> > Thank you for pointing this out! Incidentally, Dmitry Petukhov also
>> > told me the same privately.
>>
>> My thought was that if TOKEN has the characteristics of a password
>> (short ASCII string), then it would be better to use key derivation
>> function designed for passwords, like PBKDF2.
>>
>> The counter-argument to this is that this adds another code dependency
>> for vendors, if the device firmware does not already have the required
>> key derivation function.
>>
>> Maybe this could be solved by going into opposite direction - make the
>> "token" even longer, use the mnemoic.
>>
>> The issue is that entering long data of the shared key into the device
>> manually is difficult UX-wise.
>>
>> Hww vendors that allow to enter custom keys into their device already
>> have to face this issue, and those who allow to enter custom keys via
>> mnemonic probably tackled this somehow.
>>
>> Maybe the shared key for multisig setup can be entered in the same way
>> ? (with maybe additional visual check via some fingerprint).
>>
>
> You just gave me a great idea! We can reuse the BIP32 seed words list!
> Perhaps the encryption key can just be 6 words, but it'll be derived the
> same way. BIP39 also uses PBKDF2 as a key derivation function, so it
> matches with what you described here.
>
> And all HWW should have this functionality already.
>
> Best,
> Hugo
>
>
>>
>> Although we would then have another issue of potential confusion
>> between two procedures (entering the main key and entering the shared
>> key for multisig setup), and the measures has to be taken to prevent
>> such confusion.
>>
>> The approaches can be combined - specify a key derivation function
>> suitable for passwords; via secure channel, share a password and/or the
>> derived key. If hww supports derivation function, it can derive the key
>> from password. If hww supports only keys, the key can be entered raw or
>> via mnemonic.
>> ___
>> bitcoin-dev mailing list
>> bitcoin-dev@lists.linuxfoundation.org
>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>>
>
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] Proposal: Bitcoin Secure Multisig Setup

[Hugo Nguyen via bitcoin-dev]

Hi Pavol,

On Thu, Feb 11, 2021 at 8:25 AM Dmitry Petukhov via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:

> В Thu, 11 Feb 2021 05:45:33 -0800
> Hugo Nguyen via bitcoin-dev 
> wrote:
>
> > > > ENCRYPTION_KEY = SHA256(SHA256(TOKEN))
> > >
> > > This scheme might be vulnerable to rainbow table attack.
> > >
> >
> > Thank you for pointing this out! Incidentally, Dmitry Petukhov also
> > told me the same privately.
>
> My thought was that if TOKEN has the characteristics of a password
> (short ASCII string), then it would be better to use key derivation
> function designed for passwords, like PBKDF2.
>
> The counter-argument to this is that this adds another code dependency
> for vendors, if the device firmware does not already have the required
> key derivation function.
>
> Maybe this could be solved by going into opposite direction - make the
> "token" even longer, use the mnemoic.
>
> The issue is that entering long data of the shared key into the device
> manually is difficult UX-wise.
>
> Hww vendors that allow to enter custom keys into their device already
> have to face this issue, and those who allow to enter custom keys via
> mnemonic probably tackled this somehow.
>
> Maybe the shared key for multisig setup can be entered in the same way
> ? (with maybe additional visual check via some fingerprint).
>

You just gave me a great idea! We can reuse the BIP32 seed words list!
Perhaps the encryption key can just be 6 words, but it'll be derived the
same way. BIP39 also uses PBKDF2 as a key derivation function, so it
matches with what you described here.

And all HWW should have this functionality already.

Best,
Hugo


>
> Although we would then have another issue of potential confusion
> between two procedures (entering the main key and entering the shared
> key for multisig setup), and the measures has to be taken to prevent
> such confusion.
>
> The approaches can be combined - specify a key derivation function
> suitable for passwords; via secure channel, share a password and/or the
> derived key. If hww supports derivation function, it can derive the key
> from password. If hww supports only keys, the key can be entered raw or
> via mnemonic.
> ___
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] Proposal: Bitcoin Secure Multisig Setup

[Dmitry Petukhov via bitcoin-dev]

В Thu, 11 Feb 2021 05:45:33 -0800
Hugo Nguyen via bitcoin-dev 
wrote:

> > > ENCRYPTION_KEY = SHA256(SHA256(TOKEN))  
> >
> > This scheme might be vulnerable to rainbow table attack.
> >  
> 
> Thank you for pointing this out! Incidentally, Dmitry Petukhov also
> told me the same privately.

My thought was that if TOKEN has the characteristics of a password
(short ASCII string), then it would be better to use key derivation
function designed for passwords, like PBKDF2.

The counter-argument to this is that this adds another code dependency
for vendors, if the device firmware does not already have the required
key derivation function.

Maybe this could be solved by going into opposite direction - make the
"token" even longer, use the mnemoic.

The issue is that entering long data of the shared key into the device
manually is difficult UX-wise.

Hww vendors that allow to enter custom keys into their device already
have to face this issue, and those who allow to enter custom keys via
mnemonic probably tackled this somehow.

Maybe the shared key for multisig setup can be entered in the same way
? (with maybe additional visual check via some fingerprint).

Although we would then have another issue of potential confusion
between two procedures (entering the main key and entering the shared
key for multisig setup), and the measures has to be taken to prevent
such confusion.

The approaches can be combined - specify a key derivation function
suitable for passwords; via secure channel, share a password and/or the
derived key. If hww supports derivation function, it can derive the key
from password. If hww supports only keys, the key can be entered raw or
via mnemonic.
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] Proposal: Bitcoin Secure Multisig Setup

[Hugo Nguyen via bitcoin-dev]

Hi Pavol,

On Thu, Feb 11, 2021 at 5:25 AM Pavol Rusnak  wrote:

> > ENCRYPTION_KEY = SHA256(SHA256(TOKEN))
>
> This scheme might be vulnerable to rainbow table attack.
>

Thank you for pointing this out! Incidentally, Dmitry Petukhov also told me
the same privately.


>
> The following scheme might be more secure:
>
> DESCRIPTION = ASCII description provided by user
> NONCE = 256-bit random number
> ENCRYPTION_KEY = hmac-sha256(key=NONCE, msg=DESCRIPTION)
>
> Coordinator distributes DESCRIPTION (fka TOKEN) together with NONCE to
> the signers.
>

This does seem to add a lot more entropy. The challenge is to balance the
security requirement with UX. In the absence of some handshake protocol to
exchange the shared secrets (DESCRIPTION / NONCE) , the user will have to
enter these manually on the devices. I'll think about this some more.


>
> Also, is there any reason why you'd want to disable encryption? Why not
> keep that as mandatory?
>

Making it mandatory would be nice, but IMHO not all use cases might require
encryption. For example, if you are setting up the multisig locally under a
safe environment you control, encryption might be an overkill.

Best,
Hugo



>
>
> On Tue, 9 Feb 2021 at 12:39, Hugo Nguyen via bitcoin-dev <
> bitcoin-dev@lists.linuxfoundation.org> wrote:
>
>>
>>
>> On Tue, Feb 9, 2021 at 2:19 AM Christopher Allen <
>> christoph...@lifewithalacrity.com> wrote:
>>
>>>
>>>
>>> On Tue, Feb 9, 2021 at 2:06 AM Hugo Nguyen  wrote:
>>>

 I don't think reusing XPUBs inside different multisig wallets is a good
 idea... For starters, loss of privacy in one wallet will immediately affect
 privacy of other wallets. I think multisig wallets should be completely
 firewalled from each other. That means one unique XPUB per wallet. This is
 what we have been doing with the Nunchuk wallet.

>>>
>>> To be clear, I have stated repeatedly that xpub reuse into multisig is a
>>> poor practice. However, finding a trustless solution when a wallet is
>>> airgapped with no network, or is stateless like Trezor, is quite hard.
>>>
>>> The challenge also includes how does an airgapped or stateless wallet
>>> know that it is talking to the same process on the other side that that it
>>> gave the xpub to in the first place. Without state to allow for a
>>> commitment, or at least a TOFU, a cosigner who thought he was part of a 3
>>> of 5 could discover that he instead is in a 2 of 3, or in a script with an
>>> OR, as some form of scam.
>>>
>>
>> The shared secret approach that I mentioned in the proposal actually can
>> help you here. The TOKEN doubles as a session ID - thereby establishing a
>> common state on both sides.
>>
>> Best,
>> Hugo
>>
>>
>>>
>>> — Christopher Allen
>>>
 ___
>> bitcoin-dev mailing list
>> bitcoin-dev@lists.linuxfoundation.org
>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>>
>
>
> --
> Best Regards / S pozdravom,
>
> Pavol "stick" Rusnak
> CTO, SatoshiLabs
>
>
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] Proposal: Bitcoin Secure Multisig Setup

[Pavol Rusnak via bitcoin-dev]

> ENCRYPTION_KEY = SHA256(SHA256(TOKEN))

This scheme might be vulnerable to rainbow table attack.

The following scheme might be more secure:

DESCRIPTION = ASCII description provided by user
NONCE = 256-bit random number
ENCRYPTION_KEY = hmac-sha256(key=NONCE, msg=DESCRIPTION)

Coordinator distributes DESCRIPTION (fka TOKEN) together with NONCE to the
signers.

Also, is there any reason why you'd want to disable encryption? Why not
keep that as mandatory?


On Tue, 9 Feb 2021 at 12:39, Hugo Nguyen via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:

>
>
> On Tue, Feb 9, 2021 at 2:19 AM Christopher Allen <
> christoph...@lifewithalacrity.com> wrote:
>
>>
>>
>> On Tue, Feb 9, 2021 at 2:06 AM Hugo Nguyen  wrote:
>>
>>>
>>> I don't think reusing XPUBs inside different multisig wallets is a good
>>> idea... For starters, loss of privacy in one wallet will immediately affect
>>> privacy of other wallets. I think multisig wallets should be completely
>>> firewalled from each other. That means one unique XPUB per wallet. This is
>>> what we have been doing with the Nunchuk wallet.
>>>
>>
>> To be clear, I have stated repeatedly that xpub reuse into multisig is a
>> poor practice. However, finding a trustless solution when a wallet is
>> airgapped with no network, or is stateless like Trezor, is quite hard.
>>
>> The challenge also includes how does an airgapped or stateless wallet
>> know that it is talking to the same process on the other side that that it
>> gave the xpub to in the first place. Without state to allow for a
>> commitment, or at least a TOFU, a cosigner who thought he was part of a 3
>> of 5 could discover that he instead is in a 2 of 3, or in a script with an
>> OR, as some form of scam.
>>
>
> The shared secret approach that I mentioned in the proposal actually can
> help you here. The TOKEN doubles as a session ID - thereby establishing a
> common state on both sides.
>
> Best,
> Hugo
>
>
>>
>> — Christopher Allen
>>
>>> ___
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>


-- 
Best Regards / S pozdravom,

Pavol "stick" Rusnak
CTO, SatoshiLabs
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] Proposal: Bitcoin Secure Multisig Setup

[Hugo Nguyen via bitcoin-dev]

Hi Craig,
Comments inline.

On Tue, Feb 9, 2021 at 1:17 AM Craig Raw  wrote:

> Hi Hugo,
>
> Thanks for raising this again - I'll note there has already been much
> discussion on this topic. With respect to your "two layers of protection":
>
> > The Coordinator shares the TOKEN with all participating Signers over a
> secure channel.
>
> What secure channel do you propose? Currently, with the default of a
> software wallet coordinator talking to hardware wallets, we have USB, file
> (microSD), and QR as communication channels. It's unclear to me why the
> token and encryption process is necessary - in fact it's easier to verify
> what is going on using clear text, and the majority of setups will be
> locally done with the reasonable assumption of a secure environment. When
> the setup is remote, it's simpler to just transmit the key information over
> the secure channel which presumably already has encryption.
>
>
In short, a shared secret (the TOKEN) is needed because without it you
cannot guarantee that the devices you are connecting to are legitimate
members of the multisig wallet. Yes, the connection between the coordinator
and each device could be secure - but a malicious actor can establish a
secure channel just as well as a good one. You are correct that this is
less of an issue for local setups, but this is especially important for
distributed multisig - where you cannot physically see what's on the other
side.

I would love to remove the shared secret/encryption aspect out of the
proposal, but so far I haven't found any way around this issue, aside from
establishing a shared secret prior to setting up the wallet...

I also realized that supporting this could be a big ask for vendors, so
I've made this part of the proposal optional.

Another note here is that right after I posted the proposal (classic...), I
also realized there could be another optimization: the secure session
established by the shared secret can remain open indefinitely on the device
side - until a different TOKEN is entered. That way the user needs to enter
the TOKEN only once, saving us one interaction.


> > The second one is through the descriptor checksum and visual inspection
> of the descriptor itself.
>
> This is a reasonable suggestion, although it's worth noting that support
> for storing multisig setups on hardware wallets varies. Coldcard supports
> this through importing of a proprietary .txt format file (which has been
> adopted by a number of other vendors). Trezor and Ledger (AFAIK) do not
> however store multisig setups, which could make this step confusing. With
> that said, the use of an output descriptor is certainly a more standardised
> approach, albeit one without the wallet name included. By the use of the
> singular, I assume you mean a descriptor without the /0/* or /1/* suffix
> (which I think is a good idea).
>
>
I'm aware that Trezor and Ledger currently cannot support this. But IMHO
lack of support on some devices shouldn't prevent us from setting a good
standard here. Cosigner registration on the device is crucial, as you don't
have to rely on everything being included in the PSBT (which also adds
mental overhead as the user has to verify each and every transaction).

Yes, descriptor without the /0/* and /1/* - Thanks for clarifying. Will
update the proposal.



> WRT to QR codes, using the BCR UR2.0 standard you linked to is IMO the
> right approach. I'll link directly to the two BCR UR2.0 formats here which
> are relevant:
>
> 1. For sharing the sharing the BIP44 account information from the signers
> to the coordinator, the crypto-account format: [
> https://github.com/BlockchainCommons/Research/blob/master/papers/bcr-2020-015-account.md
> ]
> 2. For sharing the output descriptor from the coordinator to the signers,
> the crypto-output format: [
> https://github.com/BlockchainCommons/Research/blob/master/papers/bcr-2020-010-output-desc.md
> ]
>
>
Thanks, will update!


> Craig
>
>
>
> On Tue, Feb 9, 2021 at 9:53 AM Hugo Nguyen via bitcoin-dev <
> bitcoin-dev@lists.linuxfoundation.org> wrote:
>
>> Hi all,
>> I would like to propose a new BIP for Secure Multisig Setup.
>> This proposal has taken inputs from folks at Coldcard, Shift Crypto and
>> Cobo -- listed below as co-authors.
>>
>> This was inspired by my own experience working with hardware wallets on
>> the market, as well as existing research into the challenges of multisig.
>>
>> Cheers,
>> Hugo
>>
>> 
>>   BIP: To be determined
>>   Layer: Applications
>>   Title: Bitcoin Secure Multisig Setup (BSMS)
>>   Author: Hugo Nguyen , Peter Gray ,
>> Marko Bencun , Aaron Chen ,
>> Rodolfo Novak 
>>   Comments-Summary: No comments yet.
>>   Comments-URI:
>>   Status: Proposed
>>   Type: Standards Track
>>   Created: 2020-11-10
>>   License: BSD-2-Clause
>> 
>>
>> ==Introduction==
>>
>> ===Abstract===
>>
>> This document proposes a mechanism to set up multisig wallets securely.
>>
>> ===Copyright===
>>
>> This BIP is licensed under the 2-clause BSD l

Re: [bitcoin-dev] Proposal: Bitcoin Secure Multisig Setup

[Hugo Nguyen via bitcoin-dev]

On Tue, Feb 9, 2021 at 2:19 AM Christopher Allen <
christoph...@lifewithalacrity.com> wrote:

>
>
> On Tue, Feb 9, 2021 at 2:06 AM Hugo Nguyen  wrote:
>
>>
>> I don't think reusing XPUBs inside different multisig wallets is a good
>> idea... For starters, loss of privacy in one wallet will immediately affect
>> privacy of other wallets. I think multisig wallets should be completely
>> firewalled from each other. That means one unique XPUB per wallet. This is
>> what we have been doing with the Nunchuk wallet.
>>
>
> To be clear, I have stated repeatedly that xpub reuse into multisig is a
> poor practice. However, finding a trustless solution when a wallet is
> airgapped with no network, or is stateless like Trezor, is quite hard.
>
> The challenge also includes how does an airgapped or stateless wallet know
> that it is talking to the same process on the other side that that it gave
> the xpub to in the first place. Without state to allow for a commitment, or
> at least a TOFU, a cosigner who thought he was part of a 3 of 5 could
> discover that he instead is in a 2 of 3, or in a script with an OR, as some
> form of scam.
>

The shared secret approach that I mentioned in the proposal actually can
help you here. The TOKEN doubles as a session ID - thereby establishing a
common state on both sides.

Best,
Hugo


>
> — Christopher Allen
>
>>
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] Proposal: Bitcoin Secure Multisig Setup

[Hugo Nguyen via bitcoin-dev]

Hi Christopher,
Comments inline.

On Tue, Feb 9, 2021 at 1:31 AM Christopher Allen <
christoph...@lifewithalacrity.com> wrote:

> In the Airgapped Wallet Community we also have been investigating
> solutions, in particular as current common practice is is reuse the same
> xpub for all multisigs, for instance [90081696/48'/0'/0'/2']
> xpub6DYLEkDfCdHzh5FHGHDJksQvFqu6kYANa1sfo6fA8n5ZWkSwyCRVVzyq9LY2eNGB6T9BKDeGJp2ZarjRZHd7WB95nSaFEDhFMK6zSV6D49b
>
>
I don't think reusing XPUBs inside different multisig wallets is a good
idea... For starters, loss of privacy in one wallet will immediately affect
privacy of other wallets. I think multisig wallets should be completely
firewalled from each other. That means one unique XPUB per wallet. This is
what we have been doing with the Nunchuk wallet.



> We’ve also have been looking into multi round commitment scheme, but
> wanted to align the UX so that it would work like to musig for users.
> Discussion on it is scattered, for instance
>
> https://github.com/BlockchainCommons/Airgapped-Wallet-Community/discussions/16#discussioncomment-212013
>
> Nothing got as far as your version though.
>
> So Concept ACK from Blockchain Commons. Less clear on your specifics
> though. We will review.
>
> Note that we are releasing a descriptor & multisig centric iOS and Android
> reference wallet soon so solving this correctly and having interoperability
> with others is very important for our roadmap.
>

Thank you and good to know ! Look forward to solving this correctly as well.

Best,

Hugo


>
> — Christopher Allen
>
>
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] Proposal: Bitcoin Secure Multisig Setup

[Christopher Allen via bitcoin-dev]

In the Airgapped Wallet Community we also have been investigating
solutions, in particular as current common practice is is reuse the same
xpub for all multisigs, for instance [90081696/48'/0'/0'/2']
xpub6DYLEkDfCdHzh5FHGHDJksQvFqu6kYANa1sfo6fA8n5ZWkSwyCRVVzyq9LY2eNGB6T9BKDeGJp2ZarjRZHd7WB95nSaFEDhFMK6zSV6D49b

We’ve also have been looking into multi round commitment scheme, but wanted
to align the UX so that it would work like to musig for users. Discussion
on it is scattered, for instance
https://github.com/BlockchainCommons/Airgapped-Wallet-Community/discussions/16#discussioncomment-212013

Nothing got as far as your version though.

So Concept ACK from Blockchain Commons. Less clear on your specifics
though. We will review.

Note that we are releasing a descriptor & multisig centric iOS and Android
reference wallet soon so solving this correctly and having interoperability
with others is very important for our roadmap.

— Christopher Allen
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] Proposal: Bitcoin Secure Multisig Setup

[Craig Raw via bitcoin-dev]

Hi Hugo,

Thanks for raising this again - I'll note there has already been much
discussion on this topic. With respect to your "two layers of protection":

> The Coordinator shares the TOKEN with all participating Signers over a
secure channel.

What secure channel do you propose? Currently, with the default of a
software wallet coordinator talking to hardware wallets, we have USB, file
(microSD), and QR as communication channels. It's unclear to me why the
token and encryption process is necessary - in fact it's easier to verify
what is going on using clear text, and the majority of setups will be
locally done with the reasonable assumption of a secure environment. When
the setup is remote, it's simpler to just transmit the key information over
the secure channel which presumably already has encryption.

> The second one is through the descriptor checksum and visual inspection
of the descriptor itself.

This is a reasonable suggestion, although it's worth noting that support
for storing multisig setups on hardware wallets varies. Coldcard supports
this through importing of a proprietary .txt format file (which has been
adopted by a number of other vendors). Trezor and Ledger (AFAIK) do not
however store multisig setups, which could make this step confusing. With
that said, the use of an output descriptor is certainly a more standardised
approach, albeit one without the wallet name included. By the use of the
singular, I assume you mean a descriptor without the /0/* or /1/* suffix
(which I think is a good idea).

WRT to QR codes, using the BCR UR2.0 standard you linked to is IMO the
right approach. I'll link directly to the two BCR UR2.0 formats here which
are relevant:

1. For sharing the sharing the BIP44 account information from the signers
to the coordinator, the crypto-account format: [
https://github.com/BlockchainCommons/Research/blob/master/papers/bcr-2020-015-account.md
]
2. For sharing the output descriptor from the coordinator to the signers,
the crypto-output format: [
https://github.com/BlockchainCommons/Research/blob/master/papers/bcr-2020-010-output-desc.md
]

Craig

On Tue, Feb 9, 2021 at 9:53 AM Hugo Nguyen via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:

> Hi all,
> I would like to propose a new BIP for Secure Multisig Setup.
> This proposal has taken inputs from folks at Coldcard, Shift Crypto and
> Cobo -- listed below as co-authors.
>
> This was inspired by my own experience working with hardware wallets on
> the market, as well as existing research into the challenges of multisig.
>
> Cheers,
> Hugo
>
> 
>   BIP: To be determined
>   Layer: Applications
>   Title: Bitcoin Secure Multisig Setup (BSMS)
>   Author: Hugo Nguyen , Peter Gray ,
> Marko Bencun , Aaron Chen ,
> Rodolfo Novak 
>   Comments-Summary: No comments yet.
>   Comments-URI:
>   Status: Proposed
>   Type: Standards Track
>   Created: 2020-11-10
>   License: BSD-2-Clause
> 
>
> ==Introduction==
>
> ===Abstract===
>
> This document proposes a mechanism to set up multisig wallets securely.
>
> ===Copyright===
>
> This BIP is licensed under the 2-clause BSD license.
>
> ===Motivation===
>
> The Bitcoin multisig experience has been greatly streamlined under [
> https://github.com/bitcoin/bips/blob/master/bip-0174.mediawiki BIP-0174
> (Partially Signed Bitcoin Transaction)]. However, what is still missing is
> a standardized process for setting up multisig wallets securely across
> different vendors.
>
> There are a number of concerns when it comes to setting up a multisig
> wallet:
>
> # Whether the multisig configuration, such as Signer membership, script
> type, derivation paths and number of signatures required, is correct and
> not tampered with.
> # Whether Signer persists the multisig configuration in their respective
> storage, and under what format.
> # Whether Signer's storage is tamper-proof.
> # Whether Signer subsequently uses the multisig configuration to generate
> and verify receive and change addresses.
>
> An attacker who can modify the multisig configuration can steal or hold
> funds to ransom by duping the user into sending funds to the wrong address.
>
> This proposal seeks to address concerns #1 and #2: to mitigate the risk of
> tampering during the initial setup phase, and to define an interoperable
> multisig configuration format.
>
> Concerns #3 and #4 should be handled by Signers and is out of scope of
> this proposal.
>
> ==Specification==
>
> ===Prerequisites===
> This proposal assumes the parties in the multisig support [
> https://github.com/bitcoin/bips/blob/master/bip-0032.mediawiki BIP32], [
> https://github.com/bitcoin/bitcoin/blob/master/doc/descriptors.md the
> descriptor language] and encryption.
>
> ==Roles==
> ===Coordinator===
>
> The Coordinator initiates the multisig setup. The Coordinator determines
> what type of multisig is used and how many members and signatures are
> needed. If encryption is enabled, the Coordinator generates a secret token,
> to be shared among

[bitcoin-dev] Proposal: Bitcoin Secure Multisig Setup

[Hugo Nguyen via bitcoin-dev]

Hi all,
I would like to propose a new BIP for Secure Multisig Setup.
This proposal has taken inputs from folks at Coldcard, Shift Crypto and
Cobo -- listed below as co-authors.

This was inspired by my own experience working with hardware wallets on the
market, as well as existing research into the challenges of multisig.

Cheers,
Hugo


  BIP: To be determined
  Layer: Applications
  Title: Bitcoin Secure Multisig Setup (BSMS)
  Author: Hugo Nguyen , Peter Gray ,
Marko Bencun , Aaron Chen ,
Rodolfo Novak 
  Comments-Summary: No comments yet.
  Comments-URI:
  Status: Proposed
  Type: Standards Track
  Created: 2020-11-10
  License: BSD-2-Clause


==Introduction==

===Abstract===

This document proposes a mechanism to set up multisig wallets securely.

===Copyright===

This BIP is licensed under the 2-clause BSD license.

===Motivation===

The Bitcoin multisig experience has been greatly streamlined under [
https://github.com/bitcoin/bips/blob/master/bip-0174.mediawiki BIP-0174
(Partially Signed Bitcoin Transaction)]. However, what is still missing is
a standardized process for setting up multisig wallets securely across
different vendors.

There are a number of concerns when it comes to setting up a multisig
wallet:

# Whether the multisig configuration, such as Signer membership, script
type, derivation paths and number of signatures required, is correct and
not tampered with.
# Whether Signer persists the multisig configuration in their respective
storage, and under what format.
# Whether Signer's storage is tamper-proof.
# Whether Signer subsequently uses the multisig configuration to generate
and verify receive and change addresses.

An attacker who can modify the multisig configuration can steal or hold
funds to ransom by duping the user into sending funds to the wrong address.

This proposal seeks to address concerns #1 and #2: to mitigate the risk of
tampering during the initial setup phase, and to define an interoperable
multisig configuration format.

Concerns #3 and #4 should be handled by Signers and is out of scope of this
proposal.

==Specification==

===Prerequisites===
This proposal assumes the parties in the multisig support [
https://github.com/bitcoin/bips/blob/master/bip-0032.mediawiki BIP32], [
https://github.com/bitcoin/bitcoin/blob/master/doc/descriptors.md the
descriptor language] and encryption.

==Roles==
===Coordinator===

The Coordinator initiates the multisig setup. The Coordinator determines
what type of multisig is used and how many members and signatures are
needed. If encryption is enabled, the Coordinator generates a secret token,
to be shared among the parties for secure communication. The Coordinator
gathers information from the Signers to generate a descriptor record. The
Coordinator distributes the descriptor record back to the Signers.

===Signer===

The Signer is a participating member in the multisig. Its responsibilities
include providing its XPUB to the Coordinator, verifying that its XPUB is
included in the descriptor record and persisting the descriptor record in
its storage.

==Setup Process==

===Round 1===

Coordinator

* The Coordinator creates a multisig wallet creation session. The
Coordinator determines the type of multisig script used and the signing
configuration (M and N).
* If encryption is enabled, the Coordinator also generates a secret token,
hereby denoted TOKEN.
* TOKEN is in ASCII format and must have a minimum of 8 characters. TOKEN
should expire after some time period determined by the Coordinator, e.g.,
24 hours.
* TOKEN acts as an encryption key among the parties. The method of
encryption is AES, CTR mode. The encryption key can be calculated by
performing a double hash operation on the TOKEN: ENCRYPTION_KEY =
SHA256(SHA256(TOKEN)).
* A TOKEN value of -1 means that encryption is disabled and all
the encryption/decryption steps below can be skipped.
* The Coordinator shares the TOKEN with all participating Signers over a
secure channel.

Signer

* The Signer generates a key record by prompting the user for the TOKEN and
a derivation path.
* The first line in the record must be the TOKEN. If encryption is
disabled, set the TOKEN to -1. The second line must be the KEY,
whereas KEY is an XPUB. KEY must include key origin information and written
in the descriptor-defined format, i.e.: [{master key
fingerprint}/{derivation path}]{XPUB}. The third line must be a
SIG, whereas SIG is the signature generated by using the
corresponding private key to sign the first two lines. Finally, the Signer
encrypts the entire record with ENCRYPTION_KEY.

===Round 2===

Coordinator

* The Coordinator gathers key records from all participating Signers. Abort
the setup if TOKEN has expired.
* For each key record, the Coordinator decrypts it using ENCRYPTION_KEY.
The Coordinator verifies that the included SIG is valid given the KEY.
* If all key records look good, the Coordinator generates a descriptor
record, which is simply the descriptor st