* [bitcoin-dev] Proposal: Bitcoin Secure Multisig Setup
@ 2021-02-08 23:14 Hugo Nguyen
2021-02-09 9:33 ` Craig Raw
` (5 more replies)
0 siblings, 6 replies; 37+ messages in thread
From: Hugo Nguyen @ 2021-02-08 23:14 UTC (permalink / raw)
To: bitcoin-dev
[-- Attachment #1: Type: text/plain, Size: 8303 bytes --]
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
<pre>
BIP: To be determined
Layer: Applications
Title: Bitcoin Secure Multisig Setup (BSMS)
Author: Hugo Nguyen <hugo@nunchuk•io>, Peter Gray <peter@coinkite•com>,
Marko Bencun <marko@shiftcrypto•ch>, Aaron Chen <aarondongchen@gmail•com>,
Rodolfo Novak <rodolfo@coinkite•com>
Comments-Summary: No comments yet.
Comments-URI:
Status: Proposed
Type: Standards Track
Created: 2020-11-10
License: BSD-2-Clause
</pre>
==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 (<tt>M</tt> and <tt>N</tt>).
* If encryption is enabled, the Coordinator also generates a secret token,
hereby denoted <tt>TOKEN</tt>.
* 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: <tt>ENCRYPTION_KEY =
SHA256(SHA256(TOKEN))</tt>.
* A TOKEN value of <tt>-1</tt> 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 <tt>TOKEN</tt>. If encryption is
disabled, set the TOKEN to -1. The second line must be the <tt>KEY</tt>,
whereas KEY is an XPUB. KEY must include key origin information and written
in the descriptor-defined format, i.e.: <tt>[{master key
fingerprint}/{derivation path}]{XPUB}</tt>. The third line must be a
<tt>SIG</tt>, 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 string plus a <tt>CHECKSUM</tt>, all
in one line. The CHECKSUM has BECH32 encoding and is described at [
https://github.com/bitcoin/bitcoin/blob/master/doc/descriptors.md#checksums].
The Coordinator encrypts this descriptor record with ENCRYPTION_KEY.
* The Coordinator sends the encrypted descriptor record to all
participating Signers.
====Signer====
* The Signer imports the descriptor record, decrypts it by prompting the
user for TOKEN.
* The Signer calculates and verifies the descriptor’s CHECKSUM. Abort the
setup if the CHECKSUM is incorrect.
* The Signer checks whether one of the KEYs in the descriptor belongs to
it, using path and fingerprint information included in the descriptor. The
check must perform an exact match on the KEYs, and not using shortcuts such
as matching fingerprints (which is trivial to spoof). Abort the setup if it
doesn’t detect its own KEY.
* For confirmation, the Signer must display to the user the descriptor's
CHECKSUM, plus other configurations, such as M and N. The total number of
Signers, N, is important to prevent a KEY insertion attack. All
participating Signers should be able to display the same confirmation.
* If all checks pass, the Signer persists the descriptor record in its
storage. The Signer should subsequently use the descriptor to generate and
verify receive and change addresses.
This completes the setup.
==QR Codes==
For signers that use QR codes to transmit data, key and descriptor records
can be converted to QR codes, following [
https://github.com/BlockchainCommons/Research/blob/master/papers/bcr-2020-005-ur.md
the BCR standard].
==Security==
This proposal introduce two layers of protection. The first one is a
temporary, secret token, used to encrypt the two rounds of communication
between the Signers and the Coordinator. The second one is through the
descriptor checksum and visual inspection of the descriptor itself.
The token is only needed during the setup phase, and can be safely thrown
away afterwards. The token does not guarantee that the Signer membership
set is not modified, since that depends on the overall security of all
parties in the setup, but it can make it significantly harder for an
attacker to do so.
There are three ways an attacker can modify the membership set: by changing
an existing member, by removing an existing member, or by adding a new
member.
For the first two methods, one of the Signers will be able to detect that
its membership has been changed or removed, and reject the final
descriptor. Thus, it is vital that all participating Signers check that
their membership is intact in the descriptor. Even one Signer failing to
check for its membership means that the setup could be compromised.
For the third type of attack, the descriptor checksum and visual inspection
of the descriptor itself are the only way to guard against malicious
members from being inserted into the set.
[-- Attachment #2: Type: text/html, Size: 9302 bytes --]
^ permalink raw reply [flat|nested] 37+ messages in thread
* Re: [bitcoin-dev] Proposal: Bitcoin Secure Multisig Setup
2021-02-08 23:14 [bitcoin-dev] Proposal: Bitcoin Secure Multisig Setup Hugo Nguyen
@ 2021-02-09 9:33 ` Craig Raw
[not found] ` <CACrqygA1JRA293joYOxxpSepiuFD=uVvQQy3wpuosYyLQHff-A@mail.gmail.com>
` (4 subsequent siblings)
5 siblings, 0 replies; 37+ messages in thread
From: Craig Raw @ 2021-02-09 9:33 UTC (permalink / raw)
To: Hugo Nguyen, Bitcoin Protocol Discussion
[-- Attachment #1: Type: text/plain, Size: 11119 bytes --]
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
>
> <pre>
> BIP: To be determined
> Layer: Applications
> Title: Bitcoin Secure Multisig Setup (BSMS)
> Author: Hugo Nguyen <hugo@nunchuk•io>, Peter Gray <peter@coinkite•com>,
> Marko Bencun <marko@shiftcrypto•ch>, Aaron Chen <aarondongchen@gmail•com>,
> Rodolfo Novak <rodolfo@coinkite•com>
> Comments-Summary: No comments yet.
> Comments-URI:
> Status: Proposed
> Type: Standards Track
> Created: 2020-11-10
> License: BSD-2-Clause
> </pre>
>
> ==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 (<tt>M</tt> and <tt>N</tt>).
> * If encryption is enabled, the Coordinator also generates a secret token,
> hereby denoted <tt>TOKEN</tt>.
> * 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: <tt>ENCRYPTION_KEY =
> SHA256(SHA256(TOKEN))</tt>.
> * A TOKEN value of <tt>-1</tt> 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 <tt>TOKEN</tt>. If encryption
> is disabled, set the TOKEN to -1. The second line must be the <tt>KEY</tt>,
> whereas KEY is an XPUB. KEY must include key origin information and written
> in the descriptor-defined format, i.e.: <tt>[{master key
> fingerprint}/{derivation path}]{XPUB}</tt>. The third line must be a
> <tt>SIG</tt>, 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 string plus a <tt>CHECKSUM</tt>, all
> in one line. The CHECKSUM has BECH32 encoding and is described at [
> https://github.com/bitcoin/bitcoin/blob/master/doc/descriptors.md#checksums].
> The Coordinator encrypts this descriptor record with ENCRYPTION_KEY.
> * The Coordinator sends the encrypted descriptor record to all
> participating Signers.
>
> ====Signer====
>
> * The Signer imports the descriptor record, decrypts it by prompting the
> user for TOKEN.
> * The Signer calculates and verifies the descriptor’s CHECKSUM. Abort the
> setup if the CHECKSUM is incorrect.
> * The Signer checks whether one of the KEYs in the descriptor belongs to
> it, using path and fingerprint information included in the descriptor. The
> check must perform an exact match on the KEYs, and not using shortcuts such
> as matching fingerprints (which is trivial to spoof). Abort the setup if it
> doesn’t detect its own KEY.
> * For confirmation, the Signer must display to the user the descriptor's
> CHECKSUM, plus other configurations, such as M and N. The total number of
> Signers, N, is important to prevent a KEY insertion attack. All
> participating Signers should be able to display the same confirmation.
> * If all checks pass, the Signer persists the descriptor record in its
> storage. The Signer should subsequently use the descriptor to generate and
> verify receive and change addresses.
>
> This completes the setup.
>
> ==QR Codes==
> For signers that use QR codes to transmit data, key and descriptor records
> can be converted to QR codes, following [
> https://github.com/BlockchainCommons/Research/blob/master/papers/bcr-2020-005-ur.md
> the BCR standard].
>
> ==Security==
>
> This proposal introduce two layers of protection. The first one is a
> temporary, secret token, used to encrypt the two rounds of communication
> between the Signers and the Coordinator. The second one is through the
> descriptor checksum and visual inspection of the descriptor itself.
>
> The token is only needed during the setup phase, and can be safely thrown
> away afterwards. The token does not guarantee that the Signer membership
> set is not modified, since that depends on the overall security of all
> parties in the setup, but it can make it significantly harder for an
> attacker to do so.
>
> There are three ways an attacker can modify the membership set: by
> changing an existing member, by removing an existing member, or by adding a
> new member.
>
> For the first two methods, one of the Signers will be able to detect that
> its membership has been changed or removed, and reject the final
> descriptor. Thus, it is vital that all participating Signers check that
> their membership is intact in the descriptor. Even one Signer failing to
> check for its membership means that the setup could be compromised.
>
> For the third type of attack, the descriptor checksum and visual
> inspection of the descriptor itself are the only way to guard against
> malicious members from being inserted into the set.
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists•linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
[-- Attachment #2: Type: text/html, Size: 12993 bytes --]
^ permalink raw reply [flat|nested] 37+ messages in thread
* Re: [bitcoin-dev] Proposal: Bitcoin Secure Multisig Setup
[not found] ` <CACrqygA1JRA293joYOxxpSepiuFD=uVvQQy3wpuosYyLQHff-A@mail.gmail.com>
@ 2021-02-09 9:38 ` Christopher Allen
2021-02-09 10:05 ` Hugo Nguyen
1 sibling, 0 replies; 37+ messages in thread
From: Christopher Allen @ 2021-02-09 9:38 UTC (permalink / raw)
To: Bitcoin Protocol Discussion
[-- Attachment #1: Type: text/plain, Size: 982 bytes --]
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
[-- Attachment #2: Type: text/html, Size: 1421 bytes --]
^ permalink raw reply [flat|nested] 37+ messages in thread
* Re: [bitcoin-dev] Proposal: Bitcoin Secure Multisig Setup
[not found] ` <CAPR5oBNWGLcnw97yPJBCgrj=EwoNdxz_RS9HM6EMpuX2-90JnQ@mail.gmail.com>
@ 2021-02-09 9:45 ` Hugo Nguyen
0 siblings, 0 replies; 37+ messages in thread
From: Hugo Nguyen @ 2021-02-09 9:45 UTC (permalink / raw)
To: Craig Raw; +Cc: Bitcoin Protocol Discussion
[-- Attachment #1: Type: text/plain, Size: 13240 bytes --]
Hi Craig,
Comments inline.
On Tue, Feb 9, 2021 at 1:17 AM Craig Raw <craigraw@gmail•com> 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
>>
>> <pre>
>> BIP: To be determined
>> Layer: Applications
>> Title: Bitcoin Secure Multisig Setup (BSMS)
>> Author: Hugo Nguyen <hugo@nunchuk•io>, Peter Gray <peter@coinkite•com>,
>> Marko Bencun <marko@shiftcrypto•ch>, Aaron Chen <aarondongchen@gmail•com>,
>> Rodolfo Novak <rodolfo@coinkite•com>
>> Comments-Summary: No comments yet.
>> Comments-URI:
>> Status: Proposed
>> Type: Standards Track
>> Created: 2020-11-10
>> License: BSD-2-Clause
>> </pre>
>>
>> ==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 (<tt>M</tt> and <tt>N</tt>).
>> * If encryption is enabled, the Coordinator also generates a secret
>> token, hereby denoted <tt>TOKEN</tt>.
>> * 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: <tt>ENCRYPTION_KEY =
>> SHA256(SHA256(TOKEN))</tt>.
>> * A TOKEN value of <tt>-1</tt> 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 <tt>TOKEN</tt>. If encryption
>> is disabled, set the TOKEN to -1. The second line must be the <tt>KEY</tt>,
>> whereas KEY is an XPUB. KEY must include key origin information and written
>> in the descriptor-defined format, i.e.: <tt>[{master key
>> fingerprint}/{derivation path}]{XPUB}</tt>. The third line must be a
>> <tt>SIG</tt>, 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 string plus a <tt>CHECKSUM</tt>, all
>> in one line. The CHECKSUM has BECH32 encoding and is described at [
>> https://github.com/bitcoin/bitcoin/blob/master/doc/descriptors.md#checksums].
>> The Coordinator encrypts this descriptor record with ENCRYPTION_KEY.
>> * The Coordinator sends the encrypted descriptor record to all
>> participating Signers.
>>
>> ====Signer====
>>
>> * The Signer imports the descriptor record, decrypts it by prompting the
>> user for TOKEN.
>> * The Signer calculates and verifies the descriptor’s CHECKSUM. Abort the
>> setup if the CHECKSUM is incorrect.
>> * The Signer checks whether one of the KEYs in the descriptor belongs to
>> it, using path and fingerprint information included in the descriptor. The
>> check must perform an exact match on the KEYs, and not using shortcuts such
>> as matching fingerprints (which is trivial to spoof). Abort the setup if it
>> doesn’t detect its own KEY.
>> * For confirmation, the Signer must display to the user the descriptor's
>> CHECKSUM, plus other configurations, such as M and N. The total number of
>> Signers, N, is important to prevent a KEY insertion attack. All
>> participating Signers should be able to display the same confirmation.
>> * If all checks pass, the Signer persists the descriptor record in its
>> storage. The Signer should subsequently use the descriptor to generate and
>> verify receive and change addresses.
>>
>> This completes the setup.
>>
>> ==QR Codes==
>> For signers that use QR codes to transmit data, key and descriptor
>> records can be converted to QR codes, following [
>> https://github.com/BlockchainCommons/Research/blob/master/papers/bcr-2020-005-ur.md
>> the BCR standard].
>>
>> ==Security==
>>
>> This proposal introduce two layers of protection. The first one is a
>> temporary, secret token, used to encrypt the two rounds of communication
>> between the Signers and the Coordinator. The second one is through the
>> descriptor checksum and visual inspection of the descriptor itself.
>>
>> The token is only needed during the setup phase, and can be safely thrown
>> away afterwards. The token does not guarantee that the Signer membership
>> set is not modified, since that depends on the overall security of all
>> parties in the setup, but it can make it significantly harder for an
>> attacker to do so.
>>
>> There are three ways an attacker can modify the membership set: by
>> changing an existing member, by removing an existing member, or by adding a
>> new member.
>>
>> For the first two methods, one of the Signers will be able to detect that
>> its membership has been changed or removed, and reject the final
>> descriptor. Thus, it is vital that all participating Signers check that
>> their membership is intact in the descriptor. Even one Signer failing to
>> check for its membership means that the setup could be compromised.
>>
>> For the third type of attack, the descriptor checksum and visual
>> inspection of the descriptor itself are the only way to guard against
>> malicious members from being inserted into the set.
>> _______________________________________________
>> bitcoin-dev mailing list
>> bitcoin-dev@lists•linuxfoundation.org
>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>>
>
[-- Attachment #2: Type: text/html, Size: 15599 bytes --]
^ permalink raw reply [flat|nested] 37+ messages in thread
* Re: [bitcoin-dev] Proposal: Bitcoin Secure Multisig Setup
[not found] ` <CACrqygA1JRA293joYOxxpSepiuFD=uVvQQy3wpuosYyLQHff-A@mail.gmail.com>
2021-02-09 9:38 ` Christopher Allen
@ 2021-02-09 10:05 ` Hugo Nguyen
[not found] ` <CACrqygDhuateDtJMBSWd9sGRu1yzrZBw2yZ75OyKD1Xmzix3Cw@mail.gmail.com>
1 sibling, 1 reply; 37+ messages in thread
From: Hugo Nguyen @ 2021-02-09 10:05 UTC (permalink / raw)
To: Christopher Allen; +Cc: Bitcoin Protocol Discussion
[-- Attachment #1: Type: text/plain, Size: 1622 bytes --]
Hi Christopher,
Comments inline.
On Tue, Feb 9, 2021 at 1:31 AM Christopher Allen <
ChristopherA@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
>
>
[-- Attachment #2: Type: text/html, Size: 2617 bytes --]
^ permalink raw reply [flat|nested] 37+ messages in thread
* Re: [bitcoin-dev] Proposal: Bitcoin Secure Multisig Setup
[not found] ` <CACrqygDhuateDtJMBSWd9sGRu1yzrZBw2yZ75OyKD1Xmzix3Cw@mail.gmail.com>
@ 2021-02-09 10:58 ` Hugo Nguyen
2021-02-11 13:25 ` Pavol Rusnak
0 siblings, 1 reply; 37+ messages in thread
From: Hugo Nguyen @ 2021-02-09 10:58 UTC (permalink / raw)
To: Christopher Allen; +Cc: Bitcoin Protocol Discussion
[-- Attachment #1: Type: text/plain, Size: 1419 bytes --]
On Tue, Feb 9, 2021 at 2:19 AM Christopher Allen <
ChristopherA@lifewithalacrity•com> wrote:
>
>
> On Tue, Feb 9, 2021 at 2:06 AM Hugo Nguyen <hugo@nunchuk•io> 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
>
>>
[-- Attachment #2: Type: text/html, Size: 2585 bytes --]
^ permalink raw reply [flat|nested] 37+ messages in thread
* Re: [bitcoin-dev] Proposal: Bitcoin Secure Multisig Setup
2021-02-09 10:58 ` Hugo Nguyen
@ 2021-02-11 13:25 ` Pavol Rusnak
2021-02-11 13:45 ` Hugo Nguyen
0 siblings, 1 reply; 37+ messages in thread
From: Pavol Rusnak @ 2021-02-11 13:25 UTC (permalink / raw)
To: Hugo Nguyen, Bitcoin Protocol Discussion
[-- Attachment #1: Type: text/plain, Size: 2327 bytes --]
> 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 <
> ChristopherA@lifewithalacrity•com> wrote:
>
>>
>>
>> On Tue, Feb 9, 2021 at 2:06 AM Hugo Nguyen <hugo@nunchuk•io> 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
[-- Attachment #2: Type: text/html, Size: 4676 bytes --]
^ permalink raw reply [flat|nested] 37+ messages in thread
* Re: [bitcoin-dev] Proposal: Bitcoin Secure Multisig Setup
2021-02-11 13:25 ` Pavol Rusnak
@ 2021-02-11 13:45 ` Hugo Nguyen
2021-02-11 16:29 ` Dmitry Petukhov
0 siblings, 1 reply; 37+ messages in thread
From: Hugo Nguyen @ 2021-02-11 13:45 UTC (permalink / raw)
To: Pavol Rusnak; +Cc: Bitcoin Protocol Discussion
[-- Attachment #1: Type: text/plain, Size: 3169 bytes --]
Hi Pavol,
On Thu, Feb 11, 2021 at 5:25 AM Pavol Rusnak <stick@satoshilabs•com> 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 <
>> ChristopherA@lifewithalacrity•com> wrote:
>>
>>>
>>>
>>> On Tue, Feb 9, 2021 at 2:06 AM Hugo Nguyen <hugo@nunchuk•io> 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
>
>
[-- Attachment #2: Type: text/html, Size: 6239 bytes --]
^ permalink raw reply [flat|nested] 37+ messages in thread
* Re: [bitcoin-dev] Proposal: Bitcoin Secure Multisig Setup
2021-02-11 13:45 ` Hugo Nguyen
@ 2021-02-11 16:29 ` Dmitry Petukhov
2021-02-11 19:11 ` Hugo Nguyen
2021-02-12 16:55 ` Hugo Nguyen
0 siblings, 2 replies; 37+ messages in thread
From: Dmitry Petukhov @ 2021-02-11 16:29 UTC (permalink / raw)
To: Hugo Nguyen via bitcoin-dev
В Thu, 11 Feb 2021 05:45:33 -0800
Hugo Nguyen via bitcoin-dev <bitcoin-dev@lists•linuxfoundation.org>
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.
^ permalink raw reply [flat|nested] 37+ messages in thread
* Re: [bitcoin-dev] Proposal: Bitcoin Secure Multisig Setup
2021-02-11 16:29 ` Dmitry Petukhov
@ 2021-02-11 19:11 ` Hugo Nguyen
2021-02-11 19:11 ` Hugo Nguyen
2021-02-12 16:55 ` Hugo Nguyen
1 sibling, 1 reply; 37+ messages in thread
From: Hugo Nguyen @ 2021-02-11 19:11 UTC (permalink / raw)
To: Dmitry Petukhov, Bitcoin Protocol Discussion
[-- Attachment #1: Type: text/plain, Size: 2495 bytes --]
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 <bitcoin-dev@lists•linuxfoundation.org>
> 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
>
[-- Attachment #2: Type: text/html, Size: 3372 bytes --]
^ permalink raw reply [flat|nested] 37+ messages in thread
* Re: [bitcoin-dev] Proposal: Bitcoin Secure Multisig Setup
2021-02-11 19:11 ` Hugo Nguyen
@ 2021-02-11 19:11 ` Hugo Nguyen
2021-02-11 22:29 ` Christopher Allen
0 siblings, 1 reply; 37+ messages in thread
From: Hugo Nguyen @ 2021-02-11 19:11 UTC (permalink / raw)
To: Dmitry Petukhov, Bitcoin Protocol Discussion
[-- Attachment #1: Type: text/plain, Size: 2674 bytes --]
*BIP39 seed words list.
On Thu, Feb 11, 2021 at 11:11 AM Hugo Nguyen <hugo@nunchuk•io> 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 <bitcoin-dev@lists•linuxfoundation.org>
>> 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
>>
>
[-- Attachment #2: Type: text/html, Size: 3759 bytes --]
^ permalink raw reply [flat|nested] 37+ messages in thread
* Re: [bitcoin-dev] Proposal: Bitcoin Secure Multisig Setup
2021-02-11 19:11 ` Hugo Nguyen
@ 2021-02-11 22:29 ` Christopher Allen
2021-02-12 12:31 ` Hugo Nguyen
2021-02-12 13:48 ` Peter D. Gray
0 siblings, 2 replies; 37+ messages in thread
From: Christopher Allen @ 2021-02-11 22:29 UTC (permalink / raw)
To: Bitcoin Protocol Discussion
[-- Attachment #1: Type: text/plain, Size: 2741 bytes --]
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
[-- Attachment #2: Type: text/html, Size: 2926 bytes --]
^ permalink raw reply [flat|nested] 37+ messages in thread
* Re: [bitcoin-dev] Proposal: Bitcoin Secure Multisig Setup
2021-02-11 22:29 ` Christopher Allen
@ 2021-02-12 12:31 ` Hugo Nguyen
2021-02-12 13:48 ` Peter D. Gray
1 sibling, 0 replies; 37+ messages in thread
From: Hugo Nguyen @ 2021-02-12 12:31 UTC (permalink / raw)
To: Christopher Allen, Bitcoin Protocol Discussion
[-- Attachment #1: Type: text/plain, Size: 5447 bytes --]
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 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
>
[-- Attachment #2: Type: text/html, Size: 6397 bytes --]
^ permalink raw reply [flat|nested] 37+ messages in thread
* Re: [bitcoin-dev] Proposal: Bitcoin Secure Multisig Setup
2021-02-11 22:29 ` Christopher Allen
2021-02-12 12:31 ` Hugo Nguyen
@ 2021-02-12 13:48 ` Peter D. Gray
1 sibling, 0 replies; 37+ messages in thread
From: Peter D. Gray @ 2021-02-12 13:48 UTC (permalink / raw)
To: Christopher Allen; +Cc: Bitcoin Protocol Discussion
[-- Attachment #1: Type: text/plain, Size: 3534 bytes --]
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
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
^ permalink raw reply [flat|nested] 37+ messages in thread
* Re: [bitcoin-dev] Proposal: Bitcoin Secure Multisig Setup
2021-02-11 16:29 ` Dmitry Petukhov
2021-02-11 19:11 ` Hugo Nguyen
@ 2021-02-12 16:55 ` Hugo Nguyen
2021-02-12 17:42 ` Dmitry Petukhov
1 sibling, 1 reply; 37+ messages in thread
From: Hugo Nguyen @ 2021-02-12 16:55 UTC (permalink / raw)
To: Dmitry Petukhov, Bitcoin Protocol Discussion
[-- Attachment #1: Type: text/plain, Size: 3423 bytes --]
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 <bitcoin-dev@lists•linuxfoundation.org>
> 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
>
[-- Attachment #2: Type: text/html, Size: 4198 bytes --]
^ permalink raw reply [flat|nested] 37+ messages in thread
* Re: [bitcoin-dev] Proposal: Bitcoin Secure Multisig Setup
2021-02-12 16:55 ` Hugo Nguyen
@ 2021-02-12 17:42 ` Dmitry Petukhov
2021-02-12 17:48 ` Dmitry Petukhov
2021-02-12 17:54 ` Hugo Nguyen
0 siblings, 2 replies; 37+ messages in thread
From: Dmitry Petukhov @ 2021-02-12 17:42 UTC (permalink / raw)
To: Hugo Nguyen; +Cc: Bitcoin Protocol Discussion
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 <hugo@nunchuk•io> 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 <bitcoin-dev@lists•linuxfoundation.org>
> > 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
> >
^ permalink raw reply [flat|nested] 37+ messages in thread
* Re: [bitcoin-dev] Proposal: Bitcoin Secure Multisig Setup
2021-02-12 17:42 ` Dmitry Petukhov
@ 2021-02-12 17:48 ` Dmitry Petukhov
2021-02-12 17:54 ` Hugo Nguyen
1 sibling, 0 replies; 37+ messages in thread
From: Dmitry Petukhov @ 2021-02-12 17:48 UTC (permalink / raw)
To: Hugo Nguyen; +Cc: Bitcoin Protocol Discussion
В Fri, 12 Feb 2021 18:42:31 +0100
Dmitry Petukhov <dp@simplexum•com> 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.
^ permalink raw reply [flat|nested] 37+ messages in thread
* Re: [bitcoin-dev] Proposal: Bitcoin Secure Multisig Setup
2021-02-12 17:42 ` Dmitry Petukhov
2021-02-12 17:48 ` Dmitry Petukhov
@ 2021-02-12 17:54 ` Hugo Nguyen
2021-02-14 10:37 ` Dmitry Petukhov
1 sibling, 1 reply; 37+ messages in thread
From: Hugo Nguyen @ 2021-02-12 17:54 UTC (permalink / raw)
To: Dmitry Petukhov; +Cc: Bitcoin Protocol Discussion
[-- Attachment #1: Type: text/plain, Size: 5330 bytes --]
On Fri, Feb 12, 2021 at 9:36 AM Dmitry Petukhov <dp@simplexum•com> 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 <hugo@nunchuk•io> 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 <bitcoin-dev@lists•linuxfoundation.org>
> > > 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
> > >
>
>
[-- Attachment #2: Type: text/html, Size: 7243 bytes --]
^ permalink raw reply [flat|nested] 37+ messages in thread
* Re: [bitcoin-dev] Proposal: Bitcoin Secure Multisig Setup
2021-02-12 17:54 ` Hugo Nguyen
@ 2021-02-14 10:37 ` Dmitry Petukhov
2021-02-14 11:28 ` Dmitry Petukhov
0 siblings, 1 reply; 37+ messages in thread
From: Dmitry Petukhov @ 2021-02-14 10:37 UTC (permalink / raw)
To: Hugo Nguyen; +Cc: Bitcoin Protocol Discussion
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, <Alice>, <Bob>, <Carol>), older(1000, <Dylan>))`
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 <hugo@nunchuk•io> wrote:
> On Fri, Feb 12, 2021 at 9:36 AM Dmitry Petukhov <dp@simplexum•com>
> 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 <hugo@nunchuk•io> 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
> > > > <bitcoin-dev@lists•linuxfoundation.org> 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
> > > >
> >
> >
^ permalink raw reply [flat|nested] 37+ messages in thread
* Re: [bitcoin-dev] Proposal: Bitcoin Secure Multisig Setup
2021-02-14 10:37 ` Dmitry Petukhov
@ 2021-02-14 11:28 ` Dmitry Petukhov
0 siblings, 0 replies; 37+ messages in thread
From: Dmitry Petukhov @ 2021-02-14 11:28 UTC (permalink / raw)
To: Hugo Nguyen; +Cc: Bitcoin Protocol Discussion
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 <dp@simplexum•com> 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, <Alice>, <Bob>, <Carol>), older(1000, <Dylan>))`
>
> 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 <hugo@nunchuk•io> wrote:
>
> > On Fri, Feb 12, 2021 at 9:36 AM Dmitry Petukhov <dp@simplexum•com>
> > 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 <hugo@nunchuk•io> 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
> > > > > <bitcoin-dev@lists•linuxfoundation.org> 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
> > > > >
> > >
> > >
>
^ permalink raw reply [flat|nested] 37+ messages in thread
* Re: [bitcoin-dev] Proposal: Bitcoin Secure Multisig Setup
2021-02-08 23:14 [bitcoin-dev] Proposal: Bitcoin Secure Multisig Setup Hugo Nguyen
` (2 preceding siblings ...)
[not found] ` <CAPR5oBNWGLcnw97yPJBCgrj=EwoNdxz_RS9HM6EMpuX2-90JnQ@mail.gmail.com>
@ 2021-02-15 8:44 ` Hugo Nguyen
2021-02-15 13:53 ` Craig Raw
2021-04-05 7:02 ` Hugo Nguyen
2021-04-10 13:53 ` Erik Aronesty
5 siblings, 1 reply; 37+ messages in thread
From: Hugo Nguyen @ 2021-02-15 8:44 UTC (permalink / raw)
To: Bitcoin Protocol Discussion
[-- Attachment #1: Type: text/plain, Size: 11791 bytes --]
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
<pre>
BIP: To be determined
Layer: Applications
Title: Bitcoin Secure Multisig Setup (BSMS)
Author: Hugo Nguyen <hugo at nunchuk.io>, Peter Gray <peter at
coinkite.com>, Marko Bencun <marko at shiftcrypto.ch>, Pavol Rusnak <
stick@satoshilabs•com>, Aaron Chen <aarondongchen at gmail.com>, Rodolfo
Novak <rodolfo at coinkite.com>
Comments-Summary: No comments yet.
Comments-URI:
Status: Proposed
Type: Standards Track
Created: 2020-11-10
License: BSD-2-Clause
</pre>
==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
(<tt>M</tt> and <tt>N</tt>).
* 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
<tt>TOKEN</tt> to each Signer over a secure channel. The Signer can use the
<tt>TOKEN</tt> to derive an <tt>ENCRYPTION_KEY</tt>. Refer to the
Encryption section below for details on the <tt>TOKEN</tt>, the key
derivation function and the encryption scheme. Depending on the use case,
the Coordinator can decide whether to share one common <tt>TOKEN</tt> for
all Signers, or to have one per Signer.
* If encryption is disabled, <tt>TOKEN</tt> is set to <tt>0</tt>, and all
the encryption/decryption steps below can be skipped.
=====Signer=====
* The Signer initiates a new secure multisig setup session by setting the
<tt>TOKEN</tt>. The Signer derives an <tt>ENCRYPTION_KEY</tt> from the
<tt>TOKEN</tt>. The Signer can keep the session open until a different
value for the <tt>TOKEN</tt> 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. If the Signer chooses
the path, it should try to avoid reusing XPUBs for different wallets.
* The first line in the record must be the <tt>TOKEN</tt>. The second line
must be the <tt>KEY</tt>. The <tt>KEY</tt> is an XPUB plus its key origin
information, written in the descriptor-defined format, i.e.: <tt>[{master
key fingerprint}/{derivation path}]{XPUB}</tt>. The third line must be a
<tt>SIG</tt>, whereas <tt>SIG</tt> is the signature generated by using the
private key associated with the XPUB to sign the first two lines. The
signature should follow [
https://github.com/bitcoin/bips/blob/master/bip-0322.mediawiki BIP-0322],
legacy format accepted. Finally, the Signer encrypts the entire record with
<tt>ENCRYPTION_KEY</tt>.
====Round 2====
=====Coordinator=====
* The Coordinator gathers key records from all participating Signers. Abort
the setup if the wallet setup session has expired.
* For each key record, the Coordinator decrypts it using
<tt>ENCRYPTION_KEY</tt>. The Coordinator verifies that the included
<tt>SIG</tt> is valid given the <tt>KEY</tt>.
* If all key records look good, the Coordinator fills in all necessary
information to generate a descriptor record, which is simply the descriptor
string plus a <tt>CHECKSUM</tt>, all in one line. The <tt>CHECKSUM</tt> has
[https://github.com/bitcoin/bitcoin/blob/master/doc/descriptors.md#checksums
BECH32 encoding].
* The Coordinator encrypts this descriptor record with
<tt>ENCRYPTION_KEY</tt>.
* The Coordinator sends the encrypted descriptor record to all
participating Signers.
=====Signer=====
* The Signer imports the descriptor record, decrypts it using the
<tt>ENCRYPTION_KEY</tt> derived from the open session.
* The Signer calculates and verifies the descriptor’s <tt>CHECKSUM</tt>.
Abort the setup if the <tt>CHECKSUM</tt> is incorrect.
* The Signer checks whether one of the <tt>KEY</tt>s in the descriptor
belongs to it, using path and fingerprint information included in the
descriptor. The check must perform an exact match on the <tt>KEY</tt>s, and
not using shortcuts such as matching fingerprints (which is trivial to
spoof). Abort the setup if it doesn’t detect its own <tt>KEY</tt>.
* For confirmation, the Signer must display to the user the
<tt>CHECKSUM</tt>, plus other configurations, such as <tt>M</tt> and
<tt>N</tt>. The total number of Signers, <tt>N</tt>, is important to
prevent a <tt>KEY</tt> insertion attack. All participating Signers should
be able to display the same confirmation.
* If all checks pass, the Signer persists the descriptor record in its
storage.
* The Signer can choose to further restrict post-XPUB derivation paths,
such as to those defined in [
https://github.com/bitcoin/bips/blob/master/bip-0044.mediawiki BIP-0044].
* The Signer should subsequently use the descriptor to generate and verify
receive and change addresses.
This completes the setup.
===Encryption===
====The Token====
We define three modes of encryption.
# <tt>NO_ENCRYPTION</tt> : the <tt>TOKEN</tt> is set to <tt>0</tt>.
Encryption is disabled.
# <tt>STANDARD</tt> : the <tt>TOKEN</tt> is a 64-bit nonce.
# <tt>EXTENDED</tt> : the <tt>TOKEN</tt> is a 128-bit nonce.
The <tt>TOKEN</tt> can be converted to one of these formats:
* A mnemonic phrase using [
https://github.com/bitcoin/bips/blob/master/bip-0039.mediawiki BIP-0039]
word list (6 words in <tt>STANDARD</tt> mode, 12 words in <tt>EXTENDED</tt>
mode)
* A decimal number (20 digits in <tt>STANDARD</tt> mode, 40 digits in
<tt>EXTENDED</tt> mode)
* A QR code
* Other formats
The flexibility in the data format allows each Signer to customize the User
Experience based on its respective capabilities.
====Key Derivation====
The key derivation function is [https://tools.ietf.org/html/rfc2898
PBKDF2], with PRF = SHA512. Specifically:
<tt>DK = PBKDF2(PRF, Password, Salt, c, dkLen)</tt>
Whereas:
* PRF = <tt>SHA512</tt>
* Password = <tt>"No SPOF"</tt>
* Salt = <tt>TOKEN</tt>
* c = <tt>2048</tt>
* dkLen = <tt>256</tt>
* DK = Derived <tt>ENCRYPTION_KEY</tt>
====Encryption Scheme====
The encryption scheme is [https://tools.ietf.org/html/rfc3686 AES, CTR
mode].
==QR Codes==
For signers that use QR codes to transmit data, key and descriptor records
can be converted to QR codes, following [
https://github.com/BlockchainCommons/Research/blob/master/papers/bcr-2020-005-ur.md
the BCR standard].
Also refer to [
https://github.com/BlockchainCommons/Research/blob/master/papers/bcr-2020-015-account.md
UR Type Definition for BIP44 Accounts] and [
https://github.com/BlockchainCommons/Research/blob/master/papers/bcr-2020-010-output-desc.md
UR Type Definition for Bitcoin Output Descriptors] for more details.
==Security==
This proposal introduces two layers of protection. The first one is a
temporary, secret token, used to encrypt the two rounds of communication
between the Signer and the Coordinator. The second one is through the
descriptor checksum and visual inspection of the descriptor itself.
The token is only needed during the setup phase, and can be safely thrown
away afterwards. The token does not guarantee that the Signer membership
set is not modified, since that depends on the overall security of all
parties in the setup, but it can make it significantly harder for an
attacker to do so.
There are three ways an attacker can modify the membership set: by changing
an existing member, by removing an existing member, or by adding a new
member.
For the first two methods, one of the Signers will be able to detect that
its membership has been changed or removed, and reject the final
descriptor. Thus, it is vital that all participating Signers check that
their membership is intact in the descriptor. Even one Signer failing to
check for its membership means that the setup could be compromised.
For the third type of attack, the descriptor checksum and visual inspection
of the descriptor itself are the only way to guard against malicious
members from being inserted into the set.
==Acknowledgement==
Special thanks to Dmitry Petukhov, Christopher Allen, Craig Raw and others
for their feedback on the specification.
==References==
Original mailing list thread:
https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2021-February/018385.html
[-- Attachment #2: Type: text/html, Size: 14221 bytes --]
^ permalink raw reply [flat|nested] 37+ messages in thread
* Re: [bitcoin-dev] Proposal: Bitcoin Secure Multisig Setup
2021-02-15 8:44 ` Hugo Nguyen
@ 2021-02-15 13:53 ` Craig Raw
2021-02-15 14:19 ` Hugo Nguyen
0 siblings, 1 reply; 37+ messages in thread
From: Craig Raw @ 2021-02-15 13:53 UTC (permalink / raw)
To: Hugo Nguyen, Bitcoin Protocol Discussion
[-- Attachment #1: Type: text/plain, Size: 14243 bytes --]
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
>
>
> <pre>
> BIP: To be determined
> Layer: Applications
> Title: Bitcoin Secure Multisig Setup (BSMS)
> Author: Hugo Nguyen <hugo at nunchuk.io>, Peter Gray <peter at
> coinkite.com>, Marko Bencun <marko at shiftcrypto.ch>, Pavol Rusnak <
> stick@satoshilabs•com>, Aaron Chen <aarondongchen at gmail.com>, Rodolfo
> Novak <rodolfo at coinkite.com>
> Comments-Summary: No comments yet.
> Comments-URI:
> Status: Proposed
> Type: Standards Track
> Created: 2020-11-10
> License: BSD-2-Clause
> </pre>
>
> ==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
> (<tt>M</tt> and <tt>N</tt>).
> * 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
> <tt>TOKEN</tt> to each Signer over a secure channel. The Signer can use the
> <tt>TOKEN</tt> to derive an <tt>ENCRYPTION_KEY</tt>. Refer to the
> Encryption section below for details on the <tt>TOKEN</tt>, the key
> derivation function and the encryption scheme. Depending on the use case,
> the Coordinator can decide whether to share one common <tt>TOKEN</tt> for
> all Signers, or to have one per Signer.
> * If encryption is disabled, <tt>TOKEN</tt> is set to <tt>0</tt>, and all
> the encryption/decryption steps below can be skipped.
>
> =====Signer=====
>
> * The Signer initiates a new secure multisig setup session by setting the
> <tt>TOKEN</tt>. The Signer derives an <tt>ENCRYPTION_KEY</tt> from the
> <tt>TOKEN</tt>. The Signer can keep the session open until a different
> value for the <tt>TOKEN</tt> 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. If the Signer chooses
> the path, it should try to avoid reusing XPUBs for different wallets.
> * The first line in the record must be the <tt>TOKEN</tt>. The second line
> must be the <tt>KEY</tt>. The <tt>KEY</tt> is an XPUB plus its key origin
> information, written in the descriptor-defined format, i.e.: <tt>[{master
> key fingerprint}/{derivation path}]{XPUB}</tt>. The third line must be a
> <tt>SIG</tt>, whereas <tt>SIG</tt> is the signature generated by using the
> private key associated with the XPUB to sign the first two lines. The
> signature should follow [
> https://github.com/bitcoin/bips/blob/master/bip-0322.mediawiki BIP-0322],
> legacy format accepted. Finally, the Signer encrypts the entire record with
> <tt>ENCRYPTION_KEY</tt>.
>
> ====Round 2====
>
> =====Coordinator=====
>
> * The Coordinator gathers key records from all participating Signers.
> Abort the setup if the wallet setup session has expired.
> * For each key record, the Coordinator decrypts it using
> <tt>ENCRYPTION_KEY</tt>. The Coordinator verifies that the included
> <tt>SIG</tt> is valid given the <tt>KEY</tt>.
> * If all key records look good, the Coordinator fills in all necessary
> information to generate a descriptor record, which is simply the descriptor
> string plus a <tt>CHECKSUM</tt>, all in one line. The <tt>CHECKSUM</tt> has
> [
> https://github.com/bitcoin/bitcoin/blob/master/doc/descriptors.md#checksums
> BECH32 encoding].
> * The Coordinator encrypts this descriptor record with
> <tt>ENCRYPTION_KEY</tt>.
> * The Coordinator sends the encrypted descriptor record to all
> participating Signers.
>
> =====Signer=====
>
> * The Signer imports the descriptor record, decrypts it using the
> <tt>ENCRYPTION_KEY</tt> derived from the open session.
> * The Signer calculates and verifies the descriptor’s <tt>CHECKSUM</tt>.
> Abort the setup if the <tt>CHECKSUM</tt> is incorrect.
> * The Signer checks whether one of the <tt>KEY</tt>s in the descriptor
> belongs to it, using path and fingerprint information included in the
> descriptor. The check must perform an exact match on the <tt>KEY</tt>s, and
> not using shortcuts such as matching fingerprints (which is trivial to
> spoof). Abort the setup if it doesn’t detect its own <tt>KEY</tt>.
> * For confirmation, the Signer must display to the user the
> <tt>CHECKSUM</tt>, plus other configurations, such as <tt>M</tt> and
> <tt>N</tt>. The total number of Signers, <tt>N</tt>, is important to
> prevent a <tt>KEY</tt> insertion attack. All participating Signers should
> be able to display the same confirmation.
> * If all checks pass, the Signer persists the descriptor record in its
> storage.
> * The Signer can choose to further restrict post-XPUB derivation paths,
> such as to those defined in [
> https://github.com/bitcoin/bips/blob/master/bip-0044.mediawiki BIP-0044].
> * The Signer should subsequently use the descriptor to generate and verify
> receive and change addresses.
>
> This completes the setup.
>
> ===Encryption===
>
> ====The Token====
> We define three modes of encryption.
>
> # <tt>NO_ENCRYPTION</tt> : the <tt>TOKEN</tt> is set to <tt>0</tt>.
> Encryption is disabled.
> # <tt>STANDARD</tt> : the <tt>TOKEN</tt> is a 64-bit nonce.
> # <tt>EXTENDED</tt> : the <tt>TOKEN</tt> is a 128-bit nonce.
>
> The <tt>TOKEN</tt> can be converted to one of these formats:
> * A mnemonic phrase using [
> https://github.com/bitcoin/bips/blob/master/bip-0039.mediawiki BIP-0039]
> word list (6 words in <tt>STANDARD</tt> mode, 12 words in <tt>EXTENDED</tt>
> mode)
> * A decimal number (20 digits in <tt>STANDARD</tt> mode, 40 digits in
> <tt>EXTENDED</tt> mode)
> * A QR code
> * Other formats
>
> The flexibility in the data format allows each Signer to customize the
> User Experience based on its respective capabilities.
>
> ====Key Derivation====
> The key derivation function is [https://tools.ietf.org/html/rfc2898
> PBKDF2], with PRF = SHA512. Specifically:
>
> <tt>DK = PBKDF2(PRF, Password, Salt, c, dkLen)</tt>
>
> Whereas:
>
> * PRF = <tt>SHA512</tt>
> * Password = <tt>"No SPOF"</tt>
> * Salt = <tt>TOKEN</tt>
> * c = <tt>2048</tt>
> * dkLen = <tt>256</tt>
> * DK = Derived <tt>ENCRYPTION_KEY</tt>
>
> ====Encryption Scheme====
> The encryption scheme is [https://tools.ietf.org/html/rfc3686 AES, CTR
> mode].
>
> ==QR Codes==
> For signers that use QR codes to transmit data, key and descriptor records
> can be converted to QR codes, following [
> https://github.com/BlockchainCommons/Research/blob/master/papers/bcr-2020-005-ur.md
> the BCR standard].
>
> Also refer to [
> https://github.com/BlockchainCommons/Research/blob/master/papers/bcr-2020-015-account.md
> UR Type Definition for BIP44 Accounts] and [
> https://github.com/BlockchainCommons/Research/blob/master/papers/bcr-2020-010-output-desc.md
> UR Type Definition for Bitcoin Output Descriptors] for more details.
>
> ==Security==
>
> This proposal introduces two layers of protection. The first one is a
> temporary, secret token, used to encrypt the two rounds of communication
> between the Signer and the Coordinator. The second one is through the
> descriptor checksum and visual inspection of the descriptor itself.
>
> The token is only needed during the setup phase, and can be safely thrown
> away afterwards. The token does not guarantee that the Signer membership
> set is not modified, since that depends on the overall security of all
> parties in the setup, but it can make it significantly harder for an
> attacker to do so.
>
> There are three ways an attacker can modify the membership set: by
> changing an existing member, by removing an existing member, or by adding a
> new member.
>
> For the first two methods, one of the Signers will be able to detect that
> its membership has been changed or removed, and reject the final
> descriptor. Thus, it is vital that all participating Signers check that
> their membership is intact in the descriptor. Even one Signer failing to
> check for its membership means that the setup could be compromised.
>
> For the third type of attack, the descriptor checksum and visual
> inspection of the descriptor itself are the only way to guard against
> malicious members from being inserted into the set.
>
> ==Acknowledgement==
>
> Special thanks to Dmitry Petukhov, Christopher Allen, Craig Raw and others
> for their feedback on the specification.
>
> ==References==
>
> Original mailing list thread:
> https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2021-February/018385.html
>
>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists•linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
[-- Attachment #2: Type: text/html, Size: 17055 bytes --]
^ permalink raw reply [flat|nested] 37+ messages in thread
* Re: [bitcoin-dev] Proposal: Bitcoin Secure Multisig Setup
2021-02-15 13:53 ` Craig Raw
@ 2021-02-15 14:19 ` Hugo Nguyen
2021-02-15 16:45 ` Hugo Nguyen
0 siblings, 1 reply; 37+ messages in thread
From: Hugo Nguyen @ 2021-02-15 14:19 UTC (permalink / raw)
To: Craig Raw; +Cc: Bitcoin Protocol Discussion
[-- Attachment #1: Type: text/plain, Size: 16261 bytes --]
Hi Craig,
Thanks for the feedback! Sharing my comments inline.
On Mon, Feb 15, 2021 at 5:53 AM Craig Raw <craigraw@gmail•com> 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
>>
>>
>> <pre>
>> BIP: To be determined
>> Layer: Applications
>> Title: Bitcoin Secure Multisig Setup (BSMS)
>> Author: Hugo Nguyen <hugo at nunchuk.io>, Peter Gray <peter at
>> coinkite.com>, Marko Bencun <marko at shiftcrypto.ch>, Pavol Rusnak <
>> stick@satoshilabs•com>, Aaron Chen <aarondongchen at gmail.com>, Rodolfo
>> Novak <rodolfo at coinkite.com>
>> Comments-Summary: No comments yet.
>> Comments-URI:
>> Status: Proposed
>> Type: Standards Track
>> Created: 2020-11-10
>> License: BSD-2-Clause
>> </pre>
>>
>> ==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
>> (<tt>M</tt> and <tt>N</tt>).
>> * 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
>> <tt>TOKEN</tt> to each Signer over a secure channel. The Signer can use the
>> <tt>TOKEN</tt> to derive an <tt>ENCRYPTION_KEY</tt>. Refer to the
>> Encryption section below for details on the <tt>TOKEN</tt>, the key
>> derivation function and the encryption scheme. Depending on the use case,
>> the Coordinator can decide whether to share one common <tt>TOKEN</tt> for
>> all Signers, or to have one per Signer.
>> * If encryption is disabled, <tt>TOKEN</tt> is set to <tt>0</tt>, and all
>> the encryption/decryption steps below can be skipped.
>>
>> =====Signer=====
>>
>> * The Signer initiates a new secure multisig setup session by setting the
>> <tt>TOKEN</tt>. The Signer derives an <tt>ENCRYPTION_KEY</tt> from the
>> <tt>TOKEN</tt>. The Signer can keep the session open until a different
>> value for the <tt>TOKEN</tt> 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. If the Signer chooses
>> the path, it should try to avoid reusing XPUBs for different wallets.
>> * The first line in the record must be the <tt>TOKEN</tt>. The second
>> line must be the <tt>KEY</tt>. The <tt>KEY</tt> is an XPUB plus its key
>> origin information, written in the descriptor-defined format, i.e.:
>> <tt>[{master key fingerprint}/{derivation path}]{XPUB}</tt>. The third line
>> must be a <tt>SIG</tt>, whereas <tt>SIG</tt> is the signature generated by
>> using the private key associated with the XPUB to sign the first two
>> lines. The signature should follow [
>> https://github.com/bitcoin/bips/blob/master/bip-0322.mediawiki
>> BIP-0322], legacy format accepted. Finally, the Signer encrypts the entire
>> record with <tt>ENCRYPTION_KEY</tt>.
>>
>> ====Round 2====
>>
>> =====Coordinator=====
>>
>> * The Coordinator gathers key records from all participating Signers.
>> Abort the setup if the wallet setup session has expired.
>> * For each key record, the Coordinator decrypts it using
>> <tt>ENCRYPTION_KEY</tt>. The Coordinator verifies that the included
>> <tt>SIG</tt> is valid given the <tt>KEY</tt>.
>> * If all key records look good, the Coordinator fills in all necessary
>> information to generate a descriptor record, which is simply the descriptor
>> string plus a <tt>CHECKSUM</tt>, all in one line. The <tt>CHECKSUM</tt> has
>> [
>> https://github.com/bitcoin/bitcoin/blob/master/doc/descriptors.md#checksums
>> BECH32 encoding].
>> * The Coordinator encrypts this descriptor record with
>> <tt>ENCRYPTION_KEY</tt>.
>> * The Coordinator sends the encrypted descriptor record to all
>> participating Signers.
>>
>> =====Signer=====
>>
>> * The Signer imports the descriptor record, decrypts it using the
>> <tt>ENCRYPTION_KEY</tt> derived from the open session.
>> * The Signer calculates and verifies the descriptor’s <tt>CHECKSUM</tt>.
>> Abort the setup if the <tt>CHECKSUM</tt> is incorrect.
>> * The Signer checks whether one of the <tt>KEY</tt>s in the descriptor
>> belongs to it, using path and fingerprint information included in the
>> descriptor. The check must perform an exact match on the <tt>KEY</tt>s, and
>> not using shortcuts such as matching fingerprints (which is trivial to
>> spoof). Abort the setup if it doesn’t detect its own <tt>KEY</tt>.
>> * For confirmation, the Signer must display to the user the
>> <tt>CHECKSUM</tt>, plus other configurations, such as <tt>M</tt> and
>> <tt>N</tt>. The total number of Signers, <tt>N</tt>, is important to
>> prevent a <tt>KEY</tt> insertion attack. All participating Signers should
>> be able to display the same confirmation.
>> * If all checks pass, the Signer persists the descriptor record in its
>> storage.
>> * The Signer can choose to further restrict post-XPUB derivation paths,
>> such as to those defined in [
>> https://github.com/bitcoin/bips/blob/master/bip-0044.mediawiki BIP-0044].
>> * The Signer should subsequently use the descriptor to generate and
>> verify receive and change addresses.
>>
>> This completes the setup.
>>
>> ===Encryption===
>>
>> ====The Token====
>> We define three modes of encryption.
>>
>> # <tt>NO_ENCRYPTION</tt> : the <tt>TOKEN</tt> is set to <tt>0</tt>.
>> Encryption is disabled.
>> # <tt>STANDARD</tt> : the <tt>TOKEN</tt> is a 64-bit nonce.
>> # <tt>EXTENDED</tt> : the <tt>TOKEN</tt> is a 128-bit nonce.
>>
>> The <tt>TOKEN</tt> can be converted to one of these formats:
>> * A mnemonic phrase using [
>> https://github.com/bitcoin/bips/blob/master/bip-0039.mediawiki BIP-0039]
>> word list (6 words in <tt>STANDARD</tt> mode, 12 words in <tt>EXTENDED</tt>
>> mode)
>> * A decimal number (20 digits in <tt>STANDARD</tt> mode, 40 digits in
>> <tt>EXTENDED</tt> mode)
>> * A QR code
>> * Other formats
>>
>> The flexibility in the data format allows each Signer to customize the
>> User Experience based on its respective capabilities.
>>
>> ====Key Derivation====
>> The key derivation function is [https://tools.ietf.org/html/rfc2898
>> PBKDF2], with PRF = SHA512. Specifically:
>>
>> <tt>DK = PBKDF2(PRF, Password, Salt, c, dkLen)</tt>
>>
>> Whereas:
>>
>> * PRF = <tt>SHA512</tt>
>> * Password = <tt>"No SPOF"</tt>
>> * Salt = <tt>TOKEN</tt>
>> * c = <tt>2048</tt>
>> * dkLen = <tt>256</tt>
>> * DK = Derived <tt>ENCRYPTION_KEY</tt>
>>
>> ====Encryption Scheme====
>> The encryption scheme is [https://tools.ietf.org/html/rfc3686 AES, CTR
>> mode].
>>
>> ==QR Codes==
>> For signers that use QR codes to transmit data, key and descriptor
>> records can be converted to QR codes, following [
>> https://github.com/BlockchainCommons/Research/blob/master/papers/bcr-2020-005-ur.md
>> the BCR standard].
>>
>> Also refer to [
>> https://github.com/BlockchainCommons/Research/blob/master/papers/bcr-2020-015-account.md
>> UR Type Definition for BIP44 Accounts] and [
>> https://github.com/BlockchainCommons/Research/blob/master/papers/bcr-2020-010-output-desc.md
>> UR Type Definition for Bitcoin Output Descriptors] for more details.
>>
>> ==Security==
>>
>> This proposal introduces two layers of protection. The first one is a
>> temporary, secret token, used to encrypt the two rounds of communication
>> between the Signer and the Coordinator. The second one is through the
>> descriptor checksum and visual inspection of the descriptor itself.
>>
>> The token is only needed during the setup phase, and can be safely thrown
>> away afterwards. The token does not guarantee that the Signer membership
>> set is not modified, since that depends on the overall security of all
>> parties in the setup, but it can make it significantly harder for an
>> attacker to do so.
>>
>> There are three ways an attacker can modify the membership set: by
>> changing an existing member, by removing an existing member, or by adding a
>> new member.
>>
>> For the first two methods, one of the Signers will be able to detect that
>> its membership has been changed or removed, and reject the final
>> descriptor. Thus, it is vital that all participating Signers check that
>> their membership is intact in the descriptor. Even one Signer failing to
>> check for its membership means that the setup could be compromised.
>>
>> For the third type of attack, the descriptor checksum and visual
>> inspection of the descriptor itself are the only way to guard against
>> malicious members from being inserted into the set.
>>
>> ==Acknowledgement==
>>
>> Special thanks to Dmitry Petukhov, Christopher Allen, Craig Raw and
>> others for their feedback on the specification.
>>
>> ==References==
>>
>> Original mailing list thread:
>> https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2021-February/018385.html
>>
>>
>> _______________________________________________
>> bitcoin-dev mailing list
>> bitcoin-dev@lists•linuxfoundation.org
>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>>
>
[-- Attachment #2: Type: text/html, Size: 19632 bytes --]
^ permalink raw reply [flat|nested] 37+ messages in thread
* Re: [bitcoin-dev] Proposal: Bitcoin Secure Multisig Setup
2021-02-15 14:19 ` Hugo Nguyen
@ 2021-02-15 16:45 ` Hugo Nguyen
0 siblings, 0 replies; 37+ messages in thread
From: Hugo Nguyen @ 2021-02-15 16:45 UTC (permalink / raw)
To: Craig Raw; +Cc: Bitcoin Protocol Discussion
[-- Attachment #1: Type: text/plain, Size: 17836 bytes --]
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 <hugo@nunchuk•io> wrote:
> Hi Craig,
> Thanks for the feedback! Sharing my comments inline.
>
> On Mon, Feb 15, 2021 at 5:53 AM Craig Raw <craigraw@gmail•com> 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
>>>
>>>
>>> <pre>
>>> BIP: To be determined
>>> Layer: Applications
>>> Title: Bitcoin Secure Multisig Setup (BSMS)
>>> Author: Hugo Nguyen <hugo at nunchuk.io>, Peter Gray <peter at
>>> coinkite.com>, Marko Bencun <marko at shiftcrypto.ch>, Pavol Rusnak <
>>> stick@satoshilabs•com>, Aaron Chen <aarondongchen at gmail.com>,
>>> Rodolfo Novak <rodolfo at coinkite.com>
>>> Comments-Summary: No comments yet.
>>> Comments-URI:
>>> Status: Proposed
>>> Type: Standards Track
>>> Created: 2020-11-10
>>> License: BSD-2-Clause
>>> </pre>
>>>
>>> ==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
>>> (<tt>M</tt> and <tt>N</tt>).
>>> * 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
>>> <tt>TOKEN</tt> to each Signer over a secure channel. The Signer can use the
>>> <tt>TOKEN</tt> to derive an <tt>ENCRYPTION_KEY</tt>. Refer to the
>>> Encryption section below for details on the <tt>TOKEN</tt>, the key
>>> derivation function and the encryption scheme. Depending on the use case,
>>> the Coordinator can decide whether to share one common <tt>TOKEN</tt> for
>>> all Signers, or to have one per Signer.
>>> * If encryption is disabled, <tt>TOKEN</tt> is set to <tt>0</tt>, and
>>> all the encryption/decryption steps below can be skipped.
>>>
>>> =====Signer=====
>>>
>>> * The Signer initiates a new secure multisig setup session by setting
>>> the <tt>TOKEN</tt>. The Signer derives an <tt>ENCRYPTION_KEY</tt> from the
>>> <tt>TOKEN</tt>. The Signer can keep the session open until a different
>>> value for the <tt>TOKEN</tt> 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. If the Signer chooses
>>> the path, it should try to avoid reusing XPUBs for different wallets.
>>> * The first line in the record must be the <tt>TOKEN</tt>. The second
>>> line must be the <tt>KEY</tt>. The <tt>KEY</tt> is an XPUB plus its key
>>> origin information, written in the descriptor-defined format, i.e.:
>>> <tt>[{master key fingerprint}/{derivation path}]{XPUB}</tt>. The third line
>>> must be a <tt>SIG</tt>, whereas <tt>SIG</tt> is the signature generated by
>>> using the private key associated with the XPUB to sign the first two
>>> lines. The signature should follow [
>>> https://github.com/bitcoin/bips/blob/master/bip-0322.mediawiki
>>> BIP-0322], legacy format accepted. Finally, the Signer encrypts the entire
>>> record with <tt>ENCRYPTION_KEY</tt>.
>>>
>>> ====Round 2====
>>>
>>> =====Coordinator=====
>>>
>>> * The Coordinator gathers key records from all participating Signers.
>>> Abort the setup if the wallet setup session has expired.
>>> * For each key record, the Coordinator decrypts it using
>>> <tt>ENCRYPTION_KEY</tt>. The Coordinator verifies that the included
>>> <tt>SIG</tt> is valid given the <tt>KEY</tt>.
>>> * If all key records look good, the Coordinator fills in all necessary
>>> information to generate a descriptor record, which is simply the descriptor
>>> string plus a <tt>CHECKSUM</tt>, all in one line. The <tt>CHECKSUM</tt> has
>>> [
>>> https://github.com/bitcoin/bitcoin/blob/master/doc/descriptors.md#checksums
>>> BECH32 encoding].
>>> * The Coordinator encrypts this descriptor record with
>>> <tt>ENCRYPTION_KEY</tt>.
>>> * The Coordinator sends the encrypted descriptor record to all
>>> participating Signers.
>>>
>>> =====Signer=====
>>>
>>> * The Signer imports the descriptor record, decrypts it using the
>>> <tt>ENCRYPTION_KEY</tt> derived from the open session.
>>> * The Signer calculates and verifies the descriptor’s <tt>CHECKSUM</tt>.
>>> Abort the setup if the <tt>CHECKSUM</tt> is incorrect.
>>> * The Signer checks whether one of the <tt>KEY</tt>s in the descriptor
>>> belongs to it, using path and fingerprint information included in the
>>> descriptor. The check must perform an exact match on the <tt>KEY</tt>s, and
>>> not using shortcuts such as matching fingerprints (which is trivial to
>>> spoof). Abort the setup if it doesn’t detect its own <tt>KEY</tt>.
>>> * For confirmation, the Signer must display to the user the
>>> <tt>CHECKSUM</tt>, plus other configurations, such as <tt>M</tt> and
>>> <tt>N</tt>. The total number of Signers, <tt>N</tt>, is important to
>>> prevent a <tt>KEY</tt> insertion attack. All participating Signers should
>>> be able to display the same confirmation.
>>> * If all checks pass, the Signer persists the descriptor record in its
>>> storage.
>>> * The Signer can choose to further restrict post-XPUB derivation paths,
>>> such as to those defined in [
>>> https://github.com/bitcoin/bips/blob/master/bip-0044.mediawiki
>>> BIP-0044].
>>> * The Signer should subsequently use the descriptor to generate and
>>> verify receive and change addresses.
>>>
>>> This completes the setup.
>>>
>>> ===Encryption===
>>>
>>> ====The Token====
>>> We define three modes of encryption.
>>>
>>> # <tt>NO_ENCRYPTION</tt> : the <tt>TOKEN</tt> is set to <tt>0</tt>.
>>> Encryption is disabled.
>>> # <tt>STANDARD</tt> : the <tt>TOKEN</tt> is a 64-bit nonce.
>>> # <tt>EXTENDED</tt> : the <tt>TOKEN</tt> is a 128-bit nonce.
>>>
>>> The <tt>TOKEN</tt> can be converted to one of these formats:
>>> * A mnemonic phrase using [
>>> https://github.com/bitcoin/bips/blob/master/bip-0039.mediawiki
>>> BIP-0039] word list (6 words in <tt>STANDARD</tt> mode, 12 words in
>>> <tt>EXTENDED</tt> mode)
>>> * A decimal number (20 digits in <tt>STANDARD</tt> mode, 40 digits in
>>> <tt>EXTENDED</tt> mode)
>>> * A QR code
>>> * Other formats
>>>
>>> The flexibility in the data format allows each Signer to customize the
>>> User Experience based on its respective capabilities.
>>>
>>> ====Key Derivation====
>>> The key derivation function is [https://tools.ietf.org/html/rfc2898
>>> PBKDF2], with PRF = SHA512. Specifically:
>>>
>>> <tt>DK = PBKDF2(PRF, Password, Salt, c, dkLen)</tt>
>>>
>>> Whereas:
>>>
>>> * PRF = <tt>SHA512</tt>
>>> * Password = <tt>"No SPOF"</tt>
>>> * Salt = <tt>TOKEN</tt>
>>> * c = <tt>2048</tt>
>>> * dkLen = <tt>256</tt>
>>> * DK = Derived <tt>ENCRYPTION_KEY</tt>
>>>
>>> ====Encryption Scheme====
>>> The encryption scheme is [https://tools.ietf.org/html/rfc3686 AES, CTR
>>> mode].
>>>
>>> ==QR Codes==
>>> For signers that use QR codes to transmit data, key and descriptor
>>> records can be converted to QR codes, following [
>>> https://github.com/BlockchainCommons/Research/blob/master/papers/bcr-2020-005-ur.md
>>> the BCR standard].
>>>
>>> Also refer to [
>>> https://github.com/BlockchainCommons/Research/blob/master/papers/bcr-2020-015-account.md
>>> UR Type Definition for BIP44 Accounts] and [
>>> https://github.com/BlockchainCommons/Research/blob/master/papers/bcr-2020-010-output-desc.md
>>> UR Type Definition for Bitcoin Output Descriptors] for more details.
>>>
>>> ==Security==
>>>
>>> This proposal introduces two layers of protection. The first one is a
>>> temporary, secret token, used to encrypt the two rounds of communication
>>> between the Signer and the Coordinator. The second one is through the
>>> descriptor checksum and visual inspection of the descriptor itself.
>>>
>>> The token is only needed during the setup phase, and can be safely
>>> thrown away afterwards. The token does not guarantee that the Signer
>>> membership set is not modified, since that depends on the overall security
>>> of all parties in the setup, but it can make it significantly harder for an
>>> attacker to do so.
>>>
>>> There are three ways an attacker can modify the membership set: by
>>> changing an existing member, by removing an existing member, or by adding a
>>> new member.
>>>
>>> For the first two methods, one of the Signers will be able to detect
>>> that its membership has been changed or removed, and reject the final
>>> descriptor. Thus, it is vital that all participating Signers check that
>>> their membership is intact in the descriptor. Even one Signer failing to
>>> check for its membership means that the setup could be compromised.
>>>
>>> For the third type of attack, the descriptor checksum and visual
>>> inspection of the descriptor itself are the only way to guard against
>>> malicious members from being inserted into the set.
>>>
>>> ==Acknowledgement==
>>>
>>> Special thanks to Dmitry Petukhov, Christopher Allen, Craig Raw and
>>> others for their feedback on the specification.
>>>
>>> ==References==
>>>
>>> Original mailing list thread:
>>> https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2021-February/018385.html
>>>
>>>
>>> _______________________________________________
>>> bitcoin-dev mailing list
>>> bitcoin-dev@lists•linuxfoundation.org
>>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>>>
>>
[-- Attachment #2: Type: text/html, Size: 21101 bytes --]
^ permalink raw reply [flat|nested] 37+ messages in thread
* Re: [bitcoin-dev] Proposal: Bitcoin Secure Multisig Setup
2021-02-08 23:14 [bitcoin-dev] Proposal: Bitcoin Secure Multisig Setup Hugo Nguyen
` (3 preceding siblings ...)
2021-02-15 8:44 ` Hugo Nguyen
@ 2021-04-05 7:02 ` Hugo Nguyen
2021-04-09 12:07 ` Sjors Provoost
2021-04-11 2:34 ` Michael.flaxman
2021-04-10 13:53 ` Erik Aronesty
5 siblings, 2 replies; 37+ messages in thread
From: Hugo Nguyen @ 2021-04-05 7:02 UTC (permalink / raw)
To: Bitcoin Protocol Discussion
[-- Attachment #1: Type: text/plain, Size: 38078 bytes --]
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
<pre>
BIP: To be determined
Layer: Applications
Title: Bitcoin Secure Multisig Setup (BSMS)
Author: Hugo Nguyen <hugo at nunchuk.io>, Peter Gray <peter at
coinkite.com>, Marko Bencun <marko at shiftcrypto.ch>, Aaron Chen
<aarondongchen at gmail.com>, Rodolfo Novak <rodolfo at coinkite.com>
Comments-Summary: No comments yet.
Comments-URI:
Status: Proposed
Type: Standards Track
Created: 2020-11-10
License: BSD-2-Clause
</pre>
==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 <tt>.bsms</tt> file
extension. Encrypted data should have a <tt>.dat</tt> 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 (<tt>M</tt> and <tt>N</tt>).
* 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
<tt>TOKEN</tt> to each Signer over a secure channel. The Signer can
use the <tt>TOKEN</tt> to derive an <tt>ENCRYPTION_KEY</tt>. Refer to
the Encryption section below for details on the <tt>TOKEN</tt>, the
key derivation function and the encryption scheme. Depending on the
use case, the Coordinator can decide whether to share one common
<tt>TOKEN</tt> for all Signers, or to have one per Signer.
* If encryption is disabled, the <tt>TOKEN</tt> is set to <tt>0</tt>,
and all the encryption/decryption steps below can be skipped.
=====Signer=====
* The Signer initiates the multisig wallet creation session by setting
the <tt>TOKEN</tt>. The Signer derives an <tt>ENCRYPTION_KEY</tt> from
the <tt>TOKEN</tt>. The Signer can keep the session open until a
different value for the <tt>TOKEN</tt> 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. Alternatively, the Signer can choose a path on behalf of the
user. If the Signer chooses the path, it should try to avoid reusing
XPUBs for different wallets.
* The first line in the record must be the specification version
(<tt>BSMS 1.0</tt> as of this writing). The second line must be the
hex-encoded <tt>TOKEN</tt>. The third line must be the <tt>KEY</tt>.
The <tt>KEY</tt> is an XPUB plus its key origin information, written
in the descriptor-defined format, i.e.: <tt>[{master key
fingerprint}/{derivation path}]{XPUB}</tt>. The fourth line is a text
description of the key, 80 characters maximum. The fifth line must be
a <tt>SIG</tt>, whereas <tt>SIG</tt> is the signature generated by
using the private key associated with the XPUB to sign the first four
lines. The signature should follow
[https://github.com/bitcoin/bips/blob/master/bip-0322.mediawiki
BIP-0322], legacy format accepted.
* The Signer calculates the Message Authentication Code (<tt>MAC</tt>)
for the record. The first 16 bytes of the <tt>MAC</tt> serves as the
Initialization Vector (<tt>IV</tt>) for the encryption.
* The Signer encrypts the key record with the <tt>ENCRYPTION_KEY</tt>
and <tt>IV</tt>.
* The Signer encodes the <tt>MAC</tt> and the ciphertext into
hexadecimal format, then concatenates the results: <tt>(MAC ||
ciphertext)</tt>.
====Round 2====
=====Coordinator=====
* The Coordinator gathers key records from all participating Signers.
The Coordinator verifies that there are exactly <tt>N</tt> unique key
records before the wallet setup session expires.
* For each key record, the Coordinator extracts the <tt>MAC</tt> from
the data, sets <tt>IV</tt> to the first 16 bytes of the <tt>MAC</tt>,
then decrypts the ciphertext using the <tt>ENCRYPTION_KEY</tt> and
<tt>IV</tt>.
* The Coordinator verifies that the included <tt>MAC</tt> is valid
given the plaintext.
* The Coordinator verifies that the key records have compatible
specification versions.
* The Coordinator verifies that the included <tt>SIG</tt> is valid
given the <tt>KEY</tt>.
* If all key records look good, the Coordinator fills in all necessary
information to generate a descriptor record.
* The first line in the descriptor record must be the specification
version (<tt>BSMS 1.0</tt> as of this writing). The second line must
be a comma-separated list of accepted derivation paths that the
Signers can use to generate addresses from the included XPUBs. The
paths must start with <tt>/</tt> and use non-hardened derivation. For
example, <tt>/0/*</tt> and <tt>/1/*</tt> are some common paths. If
there are no restrictions, it must say <tt>No path restrictions</tt>.
The third line must be the descriptor string plus a <tt>CHECKSUM</tt>,
all in one line. The <tt>CHECKSUM</tt> has
[https://github.com/bitcoin/bitcoin/blob/master/doc/descriptors.md#checksums
BECH32 encoding].
* The Coordinator calculates the <tt>MAC</tt> for the record. The
first 16 bytes of the <tt>MAC</tt> serves as the <tt>IV</tt> for the
encryption..
* The Coordinator encrypts the descriptor record with the
<tt>ENCRYPTION_KEY</tt> and <tt>IV</tt>.
* The Coordinator encodes the <tt>MAC</tt> and the ciphertext into
hexadecimal format, then concatenates the results: <tt>(MAC ||
ciphertext)</tt>.
* The Coordinator sends the encrypted descriptor record to all
participating Signers.
=====Signer=====
* The Signer imports the descriptor record.
* The Signer extracts the <tt>MAC</tt> from the data, sets <tt>IV</tt>
to the first 16 bytes of the <tt>MAC</tt>, then decrypts the
ciphertext using the <tt>ENCRYPTION_KEY</tt> (derived from the open
session) and <tt>IV</tt>.
* The Signer verifies that the included <tt>MAC</tt> is valid given
the plaintext.
* The Signer verifies that it can support the included specification version.
* The Signer verifies that it is compatible with the derivation path
restrictions.
* The Signer verifies the descriptor’s <tt>CHECKSUM</tt>.
* The Signer verifies that it can support the descriptor.
* The Signer checks that its <tt>KEY</tt> is included in the
descriptor, using path and fingerprint information provided. The check
must perform an exact match on the <tt>KEY</tt>s and not using
shortcuts such as matching fingerprints, which is trivial to spoof.
* For confirmation, the Signer must display to the user the
<tt>CHECKSUM</tt>, the derivation path restrictions and the policy
parameters, such as <tt>M</tt>, <tt>N</tt> and the position(s) of its
own XPUB in the policy script. The total number of Signers,
<tt>N</tt>, is important to prevent a <tt>KEY</tt> insertion attack.
The position is important for scripts where key order matters. When
applicable, all positions of the XPUB must be displayed. The full
descriptor must also be available for review upon user request.
* When possible, the Signer should also show a preview of the first
address(es) of the wallet.
* Parties must check with each other that all Signers have verified
the descriptor and has the same confirmation (except for the key
positions).
* If all checks pass, the Signer must persist the descriptor record in
its storage.
This completes the setup.
===Encryption===
====The Token====
We define three modes of encryption.
# <tt>NO_ENCRYPTION</tt> : the <tt>TOKEN</tt> is set to <tt>0</tt>.
Encryption is disabled.
# <tt>STANDARD</tt> : the <tt>TOKEN</tt> is a 64-bit nonce.
# <tt>EXTENDED</tt> : the <tt>TOKEN</tt> is a 96-bit nonce.
The <tt>TOKEN</tt> can be converted to one of these formats:
* A decimal number (recommended). The number must not exceed the
maximum value of the nonce.
* A mnemonic phrase using
[https://github.com/bitcoin/bips/blob/master/bip-0039.mediawiki
BIP-0039] word list (6 words in <tt>STANDARD</tt> mode; 9 words in
<tt>EXTENDED</tt> mode).
* A QR code.
* Other formats.
The flexibility in the data format allows each Signer to customize the
User Experience based on its respective capabilities.
====Key Derivation====
The key derivation function is [https://tools.ietf.org/html/rfc2898
PBKDF2], with PRF = SHA512. Specifically:
<tt>DKey = PBKDF2(PRF, Password, Salt, c, dkLen)</tt>
Whereas:
* PRF = SHA512
* Password = "No SPOF"
* Salt = <tt>TOKEN</tt>
* c = 2048
* dkLen = 256
* DKey = Derived <tt>ENCRYPTION_KEY</tt>
====Encryption Scheme====
The encryption scheme is [https://tools.ietf.org/html/rfc3686 AES-256-CTR].
<tt>MAC = HMAC-SHA256(HMAC_Key, hex-encoded TOKEN || Data)</tt>
<tt>IV = First 16 bytes of MAC</tt>
<tt>Ciphertext = AES-256-CTR-Encrypt(Plaintext, DKey, IV)</tt>
<tt>Plaintext = AES-256-CTR-Decrypt(Ciphertext, DKey, IV)</tt>
Whereas:
* DKey = <tt>ENCRYPTION_KEY</tt>
* HMAC_Key = SHA256(<tt>ENCRYPTION_KEY</tt>)
* Data = the plaintext, e.g. the entire key record in round 1 and the
entire descriptor record in round 2
The <tt>MAC</tt> is to be sent along with the key and descriptor
record, as specified above. Because it is a <tt>MAC</tt> over the
entire plaintext, this is essentially an
[https://en.wikipedia.org/wiki/Authenticated_encryption#Encrypt-and-MAC_(E&M)
Encrypt-and-MAC] form of authenticated encryption.
==QR Codes==
For signers that use QR codes to transmit data, key and descriptor
records can be converted to QR codes, following
[https://github.com/BlockchainCommons/Research/blob/master/papers/bcr-2020-005-ur.md
the BCR standard].
Also refer to [https://github.com/BlockchainCommons/Research/blob/master/papers/bcr-2020-015-account.md
UR Type Definition for BIP44 Accounts] and
[https://github.com/BlockchainCommons/Research/blob/master/papers/bcr-2020-010-output-desc.md
UR Type Definition for Bitcoin Output Descriptors] for more details.
==Security==
This proposal introduces two layers of protection. The first one is a
temporary, secret <tt>TOKEN</tt>. The second one is the descriptor
<tt>CHECKSUM</tt>.
The <tt>TOKEN</tt> is used to encrypt the two rounds of communication
between the Signer and the Coordinator. A <tt>MAC</tt> is also
generated from the <tt>TOKEN</tt> and plaintext to authenticate the
data being exchanged. The <tt>TOKEN</tt> is only needed during the
setup phase, and can be safely discarded afterwards.
The descriptor <tt>CHECKSUM</tt>, on the other hand, can be used to
verify the integrity of the multisig configuration. An attacker who
tampers with the multisig configuration must also change the
descriptor <tt>CHECKSUM</tt>. Parties must check with each other that
all Signers have the same <tt>CHECKSUM</tt>, along with the policy
parameters, to reduce the chance of tampering. The <tt>CHECKSUM</tt>
must be persisted along with the descriptor in each Signer’s storage.
The <tt>TOKEN</tt> and the <tt>CHECKSUM</tt> can’t guarantee complete
protection, since that depends on the overall security of all parties
in the setup, but they can make it significantly harder for an
attacker to tamper with the multisig configuration.
==Privacy==
Encryption helps improve the privacy of the wallet by avoiding sharing
XPUBs and descriptors in plaintext.
If the parties wish to have stronger privacy, it is recommended to use
a higher number of bits for the <tt>TOKEN</tt>, and to completely
erase knowledge of the <tt>TOKEN</tt> after the multisig wallet has
been set up.
==Test Vectors==
===Mode: <tt>NO_ENCRYPTION</tt>===
====ROUND 1====
* Coordinator
** M-of-N: 2/2
** ADDRESS_TYPE: NATIVE_SEGWIT
** TOKEN: 0
* Signer 1
** MASTER_KEY_FINGERPRINT: 539f3d89
** PRIVATE_KEY (m/48'/0'/0'/2'):
KyoXqiwiz6qm21BSYebiZFfNF7obkhiJW6TdPMZTQQMF4kZtfD78
** XPUB (m/48'/0'/0'/2'):
xpub6ETerig7tq89mtaD8Gau2xRWxouRMBy6XHqciA8GZzC2dJv3w6FxfgoegH4b2qYF4oG6VBrhpLrauPs5E1q58GLCnhKp6g9QsV9ZA7J5JNa
** Legacy signature
** <tt>signer_1_key.bsms</tt>:
<pre>BSMS 1.0
00
[539f3d89/48'/0'/0'/2']xpub6ETerig7tq89mtaD8Gau2xRWxouRMBy6XHqciA8GZzC2dJv3w6FxfgoegH4b2qYF4oG6VBrhpLrauPs5E1q58GLCnhKp6g9QsV9ZA7J5JNa
Signer 1 key
IPXsnNSZb8M6H4fAWtpjAc75hyHHd89fskpM5o7qFg+mPDzEPc1k2mjuIpVIIzaCe45FwPfAAa91RaStfC5Sak0=</pre>
* Signer 2
** MASTER_KEY_FINGERPRINT: f8b12aa6
** PRIVATE_KEY (m/48'/0'/0'/2'):
L1zht7muKnUYFMdzC3jwXd78u8tGoKr46AXGh4waF9nphUYWq7ow
** XPUB (m/48'/0'/0'/2'):
xpub6EWPNhGSX86SN4J2DrBUaQ826o6V4egHqAJZUDJqnsthv9CcjBZV79u68M3YZkuTJnJBXfCrHuJy97fkVurntwgt3V7Ms5hXpJV2vS8fQZM
** Legacy signature
** <tt>signer_2_key.bsms</tt>:
<pre>BSMS 1.0
00
[f8b12aa6/48'/0'/0'/2']xpub6EWPNhGSX86SN4J2DrBUaQ826o6V4egHqAJZUDJqnsthv9CcjBZV79u68M3YZkuTJnJBXfCrHuJy97fkVurntwgt3V7Ms5hXpJV2vS8fQZM
Signer 2 key
H38+lp9iaesBeCN05BDTH/SnmarlH6+X+Kmw1pgCk+c1Pc1evYIdBag9Nc0nsKhvPtfEbRt9r/qsUVZ5onCtBTc=</pre>
====ROUND 2====
* Coordinator
** <tt>my_multisig_wallet.bsms</tt>:
<pre>BSMS 1.0
/0/*,/1/*
wsh(sortedmulti(2,[539f3d89/48'/0'/0'/2']xpub6ETerig7tq89mtaD8Gau2xRWxouRMBy6XHqciA8GZzC2dJv3w6FxfgoegH4b2qYF4oG6VBrhpLrauPs5E1q58GLCnhKp6g9QsV9ZA7J5JNa/*,[f8b12aa6/48'/0'/0'/2']xpub6EWPNhGSX86SN4J2DrBUaQ826o6V4egHqAJZUDJqnsthv9CcjBZV79u68M3YZkuTJnJBXfCrHuJy97fkVurntwgt3V7Ms5hXpJV2vS8fQZM/*))#fntxdj7p</pre>
===Mode: <tt>STANDARD</tt> Encryption===
====ROUND 1====
* Coordinator
** M-of-N: 2/2
** ADDRESS_TYPE: NATIVE_SEGWIT
** TOKEN (hex): 1ed4ba49e96336b8
*** TOKEN (decimal): 2221605342811469496
*** TOKEN (mnemonic): burst place mystery spot cricket foster
** ENCRYPTION_KEY (hex):
72185a0e25b4efc5d6ac0f8ed32b0165199100e32385040e3a48eb30164bf492
* Signer 1
** MASTER_KEY_FINGERPRINT: 98d79e95
** PRIVATE_KEY (m/48'/0'/0'/2'):
KydC7hZFtWe56oQUAw14HvQ3gKeKVd3m8frFgVMxUqpuhKHvcmm3
** XPUB (m/48'/0'/0'/2'):
xpub6DvvwHS5pd1D36xt4YBGJvtdThWXfn8L9qRj9DbFMExMeP6eBE6Aw9WyBC7XUQwiPPDFurirewsKZpYv68yTV5RBy7SZmw45QEkaLka5BCt
** Legacy signature
** <tt>signer_1_key.bsms</tt>:
<pre>BSMS 1.0
1ed4ba49e96336b8
[98d79e95/48'/0'/0'/2']xpub6DvvwHS5pd1D36xt4YBGJvtdThWXfn8L9qRj9DbFMExMeP6eBE6Aw9WyBC7XUQwiPPDFurirewsKZpYv68yTV5RBy7SZmw45QEkaLka5BCt
Signer 1 key
HxtPoP0DrQSac/7ypcwC07R2s6jjpXR6Li2Q92zXj/FSIMQcV5yOU0/ONsDgHXamq0gD5DfPbvuVCp9ZJubclV4=</pre>
* Signer 1 encryption
** HMAC_KEY (hex):
4dab3988cbc683ad7a8c93d43f9b11a78b63a93d5e33ea19c603f4b7b87ac284
** MAC (hex): afe99e92f0eadc3308eb990045e90a4f54e9f59d22aae5034ac3d866d29c508d
** IV (hex) : afe99e92f0eadc3308eb990045e90a4f
** CIPHERTEXT (hex):
214ec9a861a238ba7f0412305a97a6e0faa332be15af09127e131d669e5d55d73891580a5808cea5d2bf39f43496d3c0f8236eff3854fcc7446daf9d2b58fd40d97ce3b1745de2959e29767039b99969821400eca0c3517fae56d2d24d5235a3430af1ed894b68681d706cce7c75adf35d8580603aa302bc01fef06d0336a37f19dd46100baa9e4eabd8796a810e13941ad0980c126ad55d6a4bbef11a7bf893b7d2ed8fb0d8324c4c9b512d4d1e75096c63511e15018fc832816b5639d58fc28c60c049487d04bd5a6cb32aa1381d0809660d54376b9f63325c18cfd1ac5024088e74cb703fe165972cc4485abb1feefe92a0b4ea297fe2f4f7416eeee1efc9b942540931ef
** <tt>signer_1_key.dat</tt>:
<pre>afe99e92f0eadc3308eb990045e90a4f54e9f59d22aae5034ac3d866d29c508d214ec9a861a238ba7f0412305a97a6e0faa332be15af09127e131d669e5d55d73891580a5808cea5d2bf39f43496d3c0f8236eff3854fcc7446daf9d2b58fd40d97ce3b1745de2959e29767039b99969821400eca0c3517fae56d2d24d5235a3430af1ed894b68681d706cce7c75adf35d8580603aa302bc01fef06d0336a37f19dd46100baa9e4eabd8796a810e13941ad0980c126ad55d6a4bbef11a7bf893b7d2ed8fb0d8324c4c9b512d4d1e75096c63511e15018fc832816b5639d58fc28c60c049487d04bd5a6cb32aa1381d0809660d54376b9f63325c18cfd1ac5024088e74cb703fe165972cc4485abb1feefe92a0b4ea297fe2f4f7416eeee1efc9b942540931ef</pre>
* Signer 2
** MASTER_KEY_FINGERPRINT: 3e94b5a1
** PRIVATE_KEY (m/48'/0'/0'/2'):
KyPh5XYjExjNHPiBjYhp8iAntAehrDziiwRv7y9Ln6eK9QU2xP55
** XPUB (m/48'/0'/0'/2'):
xpub6E1W1DUYY29V2b8czCcpi36GG2uD33B11vwNopgTZwsVyfgAkA4kPCqLP5R4YzaRvzW17CQrDkgmDQbA848AdkR7W18nNvMKXzzCBSnZP9c
** Legacy signature
** <tt>signer_2_key.bsms</tt>:
<pre>BSMS 1.0
1ed4ba49e96336b8
[3e94b5a1/48'/0'/0'/2']xpub6E1W1DUYY29V2b8czCcpi36GG2uD33B11vwNopgTZwsVyfgAkA4kPCqLP5R4YzaRvzW17CQrDkgmDQbA848AdkR7W18nNvMKXzzCBSnZP9c
Signer 2 key
ILR49QLy9+xkMS11TIXJRSMgOQOzGbAaooq4/ZRcd8VgM6j5upJMI0mjJHseQOMYSGk8FqjXZbMvBGyiX9wdutM=</pre>
* Signer 2 encryption
** HMAC_KEY (hex):
4dab3988cbc683ad7a8c93d43f9b11a78b63a93d5e33ea19c603f4b7b87ac284
** MAC (hex): 5c7cb2ac407cd60b1f2b86ef46077d3a312b6ce921df2a141347e8bf1e5c6573
** IV (hex) : 5c7cb2ac407cd60b1f2b86ef46077d3a
** CIPHERTEXT (hex):
f23e6c76ff45d308dea6014030a274127ad437228f1d5ec2431d2ea9e3cedd5b0a207a9efa6f926d5420205003f3cb9c4b82b2d595180e62a173a2e5aa0322de48a70a873f641bdae1764e6b1667c241e0fe03a4ccdc3fe0cfa5f75b239d6497c3b69dca17bb685ba70b307d1243836d8fb198ce727cfae4057ee0b4fdcb09f4ba5ae127f49c5de780edb4e40aec96303c8a7b98b1b8e53dd5e07e01d4f3ffd836763209a1f0cbc61adcfdc2951e77528ee7b6e68114c3a4bec38875d285021e68ae8aa913bb1e2e65dd52c649a0e98bfb4e8bab6dd10295c1167a0854ba44f094feb75d2fb00c944f07d4b47114f483df9838459316f3ddbc4a82e6507881931f8e20f5b805
** <tt>signer_2_key.dat</tt>:
<pre>5c7cb2ac407cd60b1f2b86ef46077d3a312b6ce921df2a141347e8bf1e5c6573f23e6c76ff45d308dea6014030a274127ad437228f1d5ec2431d2ea9e3cedd5b0a207a9efa6f926d5420205003f3cb9c4b82b2d595180e62a173a2e5aa0322de48a70a873f641bdae1764e6b1667c241e0fe03a4ccdc3fe0cfa5f75b239d6497c3b69dca17bb685ba70b307d1243836d8fb198ce727cfae4057ee0b4fdcb09f4ba5ae127f49c5de780edb4e40aec96303c8a7b98b1b8e53dd5e07e01d4f3ffd836763209a1f0cbc61adcfdc2951e77528ee7b6e68114c3a4bec38875d285021e68ae8aa913bb1e2e65dd52c649a0e98bfb4e8bab6dd10295c1167a0854ba44f094feb75d2fb00c944f07d4b47114f483df9838459316f3ddbc4a82e6507881931f8e20f5b805</pre>
====ROUND 2====
*Coordinator
** <tt>my_multisig_wallet.bsms</tt>:
<pre>BSMS 1.0
/0/*,/1/*
wsh(sortedmulti(2,[98d79e95/48'/0'/0'/2']xpub6DvvwHS5pd1D36xt4YBGJvtdThWXfn8L9qRj9DbFMExMeP6eBE6Aw9WyBC7XUQwiPPDFurirewsKZpYv68yTV5RBy7SZmw45QEkaLka5BCt/*,[3e94b5a1/48'/0'/0'/2']xpub6E1W1DUYY29V2b8czCcpi36GG2uD33B11vwNopgTZwsVyfgAkA4kPCqLP5R4YzaRvzW17CQrDkgmDQbA848AdkR7W18nNvMKXzzCBSnZP9c/*))#x0lx92qk</pre>
*Coordinator encryption
** HMAC_KEY (hex):
4dab3988cbc683ad7a8c93d43f9b11a78b63a93d5e33ea19c603f4b7b87ac284
** MAC (hex): df3d06db6c8b8a5f25de202e10ea225df6415d1ed0e36c64cc2be1b7e86c2a38
** IV (hex) : df3d06db6c8b8a5f25de202e10ea225d
** CIPHERTEXT (hex):
2761e6bfe839586b4c90954200bc4ce6d39ef164c5d14997755575d1691ee249ffd20beda526f57a7424907f839c6c2e3ecd46889ede290a2c81de22d3f33a7fa5e55ec95c0e26005c596d0f6346f819823f361f9f9f54d1eae48b325240d66c5888bd5ebab843061dcdd73b675346da982646c83026694d757661d31c2d654fb263c9ab3e874a258bc234c48532f15e9450c982fcf161404746e9f23d25e17b74139cd799983fd0c7a7a0386a823d3789b4578879a764172cc8ef96ab003eee24f6288007d31e2b999aff5a6d30cc524a0111a99730a29cf28ae41dbff6ce21ca6bc1df37074228178048e835584e6e70dba941154d024cd03cb6c56d0bde441ce464aa749de5e814dd30e21b75f62e831ac1f28eda1a7ba7e122076789e284402c8ba85b5a0e864bce220e3c78fa2f465e2bcf6b1d378816319de99f99ce7068
** <tt>my_multisig_wallet.dat</tt>:
<pre>df3d06db6c8b8a5f25de202e10ea225df6415d1ed0e36c64cc2be1b7e86c2a382761e6bfe839586b4c90954200bc4ce6d39ef164c5d14997755575d1691ee249ffd20beda526f57a7424907f839c6c2e3ecd46889ede290a2c81de22d3f33a7fa5e55ec95c0e26005c596d0f6346f819823f361f9f9f54d1eae48b325240d66c5888bd5ebab843061dcdd73b675346da982646c83026694d757661d31c2d654fb263c9ab3e874a258bc234c48532f15e9450c982fcf161404746e9f23d25e17b74139cd799983fd0c7a7a0386a823d3789b4578879a764172cc8ef96ab003eee24f6288007d31e2b999aff5a6d30cc524a0111a99730a29cf28ae41dbff6ce21ca6bc1df37074228178048e835584e6e70dba941154d024cd03cb6c56d0bde441ce464aa749de5e814dd30e21b75f62e831ac1f28eda1a7ba7e122076789e284402c8ba85b5a0e864bce220e3c78fa2f465e2bcf6b1d378816319de99f99ce7068</pre>
===Mode: <tt>EXTENDED</tt> Encryption===
====ROUND 1====
*Coordinator
** M-of-N: 2/3
** ADDRESS_TYPE: NESTED_SEGWIT
** TOKEN for Signer 1 (hex): 654d63309464afcda558c6aa
*** TOKEN (decimal): 31351541690484562733651510954
*** TOKEN (mnemonic): grab help slow churn enough traffic nice boat price
*** ENCRYPTION_KEY (hex):
4073adac2351e164b8d68039abd9d4b8e4d07adccfdf73ece6e236d60b107802
** TOKEN for Signer 2 (hex): b0344f51d5cb04083d598fa3
*** TOKEN (decimal): 54532600447720520868878192547
*** TOKEN (mnemonic): rabbit pen stamp process raccoon advice voice
cradle person
*** ENCRYPTION_KEY (hex):
6bae6b670e257d7468c3e90194029dd468a2f39d8b9a3ff187b08209b1d409b6
** TOKEN for Signer 3 (hex): 163fd307195982c4c39d50bb
*** TOKEN (decimal): 6885829092987042066541138107
*** TOKEN (mnemonic): bike write scrub crawl oblige give attack present rookie
*** ENCRYPTION_KEY (hex):
c78b94589214b6dc98b337ba4ce54380553ed00a1e5b1955fc540ce3b30d6566
* Signer 1
** MASTER_KEY_FINGERPRINT: 110dc257
** PRIVATE_KEY (m/48'/0'/0'/1'):
KzshDDEBhzyiwXHoyE7ZiLegzztEy54AG6Wq8N844LqHSQMHt4Ji
** XPUB (m/48'/0'/0'/1'):
xpub6EPQbDFezXYvVFHqnc8R7QUSE8hTepbyCXU7jJBT4dVm2rQHe1i6isqoj59qhyBiCdKquo6QsgMZNHvEz3BM4cNSszF25siTqLUCznBm8vk
** Legacy signature
** <tt>signer_1_key.bsms</tt>:
<pre>BSMS 1.0
654d63309464afcda558c6aa
[110dc257/48'/0'/0'/1']xpub6EPQbDFezXYvVFHqnc8R7QUSE8hTepbyCXU7jJBT4dVm2rQHe1i6isqoj59qhyBiCdKquo6QsgMZNHvEz3BM4cNSszF25siTqLUCznBm8vk
Signer 1 key
IDX6xLdM4XjetYPvVfpVBXAfT7oE3tHAOB4blZpbIst8bjJ+LbDeP4tZl4O8utAuys9igXE0G3kaHz1mg/+OU8w=</pre>
* Signer 1 encryption
** HMAC_KEY (hex):
f43c359a4b3d7b2e01be73c54519b12545ca9a23a86f824aadf577b314a7caa7
** MAC (hex): 40b6b43e2f1bc01b748eb242235d7e09fa8a2fd6cebe35784cf3adf81910ec98
** IV (hex) : 40b6b43e2f1bc01b748eb242235d7e09
** CIPHERTEXT (hex):
0877987764401c27e6c60ed2f1bb89dff1dbc5e8204149f682d53049bffe39553f24af3928aa2f78ac2d04ac5baa0c3ec39aaccf0d258e7bb6659a7b92e92f2c2784a94f4df8e8af2270d9d411bfff2cfb9f71b4e1ac87561c7d2ac57ca86a1f9716d5da7571719d24830fc8d015a0daf04b3742439484488798335357f2eeaa8e2db2ba630f9dffd88236e327ab5bfcfb6e29ee3ef6cc18e0b71c1731465c2351e76b92f7b1bd28ef6eff5414c22aa6c80090fa59b973c22e3044e92dbf3688990a49a42828e52c1e686f1193dcdf7b7118930e01419fe938c6811c58c84c36d692fd52846f998bc328471f1e73c22261791a08cda096ee3ac8b37f31afd0b1d9c335ff9ac67ff230eb0d69f2d7
** <tt>signer_1_key.dat</tt>:
<pre>40b6b43e2f1bc01b748eb242235d7e09fa8a2fd6cebe35784cf3adf81910ec980877987764401c27e6c60ed2f1bb89dff1dbc5e8204149f682d53049bffe39553f24af3928aa2f78ac2d04ac5baa0c3ec39aaccf0d258e7bb6659a7b92e92f2c2784a94f4df8e8af2270d9d411bfff2cfb9f71b4e1ac87561c7d2ac57ca86a1f9716d5da7571719d24830fc8d015a0daf04b3742439484488798335357f2eeaa8e2db2ba630f9dffd88236e327ab5bfcfb6e29ee3ef6cc18e0b71c1731465c2351e76b92f7b1bd28ef6eff5414c22aa6c80090fa59b973c22e3044e92dbf3688990a49a42828e52c1e686f1193dcdf7b7118930e01419fe938c6811c58c84c36d692fd52846f998bc328471f1e73c22261791a08cda096ee3ac8b37f31afd0b1d9c335ff9ac67ff230eb0d69f2d7</pre>
* Signer 2
** MASTER_KEY_FINGERPRINT: 5c890401
** PRIVATE_KEY (m/48'/0'/0'/1'):
L41Jnc9CdBtBJd18429MDGcTgP2DNoXaKyyGr271ndTprvrHXDQf
** XPUB (m/48'/0'/0'/1'):
xpub6EW1SmjSXq9YwVwcan5qWEncgx89SozMvGNpYF6hfZHYNTikNZ4gsXuVhHTi6xYJCkmY4X4wpPPS5Gr7aY39dVJMS2TGfihr25oaspKtU8q
** Legacy signature
** <tt>signer_2_key.bsms</tt>:
<pre>BSMS 1.0
b0344f51d5cb04083d598fa3
[5c890401/48'/0'/0'/1']xpub6EW1SmjSXq9YwVwcan5qWEncgx89SozMvGNpYF6hfZHYNTikNZ4gsXuVhHTi6xYJCkmY4X4wpPPS5Gr7aY39dVJMS2TGfihr25oaspKtU8q
Signer 2 key
H5kN6UHaK2xACB6iYdTxxQPD8qyFEYv9iMsQs5B0MRfCM7NA5GB+7EFgmBpSctwt6B122zWBr6mRjpYjKmj+7hs=</pre>
* Signer 2 encryption
** HMAC_KEY (hex):
e0a20b5f5285fbaa35aad08fb70f5626c9abbe1b384a4950735b28aca6325ff2
** MAC (hex): 3a6deec8dbdbd6606a52c7d7e64eca4f972a293cbabac6f62736629fbe77928a
** IV (hex) : 3a6deec8dbdbd6606a52c7d7e64eca4f
** CIPHERTEXT (hex):
bb0fb72f61b0c4858bd9c65235390b67651b94c4b0329238b0116dd6d3365ade33cb1c1b1619638968791a5d2d1d263d90280bdad8d9ca24c34a78e320076e0dccf59e7f729b541b44bbe40ba803dedd3b17c49765377cb2d913a856b86c3dd383dab475790e89226ed8ef2301574212d2809ed9c099aa67be434024ee2a4e82a146300acf755863da64807cb7bb2636f6616489636d254a870778d3540832aea44abac4328b5d90f3e6045ef36a526ce5d575f2305e3e4699dccbc713e9e68f50364036c1054c2a506aab77ea7c43a89536947c24330b09a62a90c3b4ae2d452f96ef34ec871af2c52d68ddede2503c87e2ba68d5cf9be589457879e06021ea6a6176f7dded820ba4c0e709e2a2
** <tt>signer_2_key.dat</tt>:
<pre>3a6deec8dbdbd6606a52c7d7e64eca4f972a293cbabac6f62736629fbe77928abb0fb72f61b0c4858bd9c65235390b67651b94c4b0329238b0116dd6d3365ade33cb1c1b1619638968791a5d2d1d263d90280bdad8d9ca24c34a78e320076e0dccf59e7f729b541b44bbe40ba803dedd3b17c49765377cb2d913a856b86c3dd383dab475790e89226ed8ef2301574212d2809ed9c099aa67be434024ee2a4e82a146300acf755863da64807cb7bb2636f6616489636d254a870778d3540832aea44abac4328b5d90f3e6045ef36a526ce5d575f2305e3e4699dccbc713e9e68f50364036c1054c2a506aab77ea7c43a89536947c24330b09a62a90c3b4ae2d452f96ef34ec871af2c52d68ddede2503c87e2ba68d5cf9be589457879e06021ea6a6176f7dded820ba4c0e709e2a2</pre>
* Signer 3
** MASTER_KEY_FINGERPRINT: 614cbf5f
** PRIVATE_KEY (m/48'/0'/0'/1'):
L2ccRLzH7GfVxWpU8YSY9y5UGyRoqW3UdeNT1vGfVbxAGhwU5qhD
** XPUB (m/48'/0'/0'/1'):
xpub6F9TfWTFcMYy5Ycd2ka2az1brJj78J2isLAWptZnCpFsesss5sZv5B8xsgt71ZXfhDWhUtf4vng4zY6HUVrQbDMPDYRLYvFFoLnAYfzgYPH
** Legacy signature
** <tt>signer_3_key.bsms</tt>:
<pre>BSMS 1.0
163fd307195982c4c39d50bb
[614cbf5f/48'/0'/0'/1']xpub6F9TfWTFcMYy5Ycd2ka2az1brJj78J2isLAWptZnCpFsesss5sZv5B8xsgt71ZXfhDWhUtf4vng4zY6HUVrQbDMPDYRLYvFFoLnAYfzgYPH
Signer 3 key
H0jf2JMtke5zDDIWys6fihOCA6QBmC5+hbgVB/c2mMPNPLB6tDXt0TFZU1f9wvaCR9762anKSc8CCqXLogw8V00=</pre>
* Signer 3 encryption
** HMAC_KEY (hex):
1f51ea067c121e2f86af5e1d484905046bc63e861573157d8b1ae9e7e47e224b
** MAC (hex): 1a5624fcb39cebabb6174456173eec19b756bc916cf2c9d815e9bcce070898c4
** IV (hex) : 1a5624fcb39cebabb6174456173eec19
** CIPHERTEXT (hex):
48d6e139bdc8c19e93cbbf5b4478340c8cf08aa91c28803084d5f58618773f7e615e0134492b496c4e7c130351c0350701f686918033f621378552d7040efedd5539d38c258bf936475de775f23da3953fe3ba5bbbd24816b8902b87a9a09700c446b085119dedee2395dd69665e742f72f2fb6da4ebe3f4704eaf45486fbfb84d764b718cc0b756e72f72ab6069d47765bdd3ebd4074af4fa99a95691a659675ce5f72235c28ddf3c3d53179e598cddc967fc896adc6e97edeeffc85b9e44611df748d923ff3dd921ad4d6e98e0de12359a37558e326faf585ba57e73ab45bc4a49f6e8a756f365f5d204e70f7c7bed269e81e9524a41e5d4cbaad0b6b442d6eea1e5da1ca345cc665a0cffe2c3
** <tt>signer_3_key.dat</tt>:
<pre>1a5624fcb39cebabb6174456173eec19b756bc916cf2c9d815e9bcce070898c448d6e139bdc8c19e93cbbf5b4478340c8cf08aa91c28803084d5f58618773f7e615e0134492b496c4e7c130351c0350701f686918033f621378552d7040efedd5539d38c258bf936475de775f23da3953fe3ba5bbbd24816b8902b87a9a09700c446b085119dedee2395dd69665e742f72f2fb6da4ebe3f4704eaf45486fbfb84d764b718cc0b756e72f72ab6069d47765bdd3ebd4074af4fa99a95691a659675ce5f72235c28ddf3c3d53179e598cddc967fc896adc6e97edeeffc85b9e44611df748d923ff3dd921ad4d6e98e0de12359a37558e326faf585ba57e73ab45bc4a49f6e8a756f365f5d204e70f7c7bed269e81e9524a41e5d4cbaad0b6b442d6eea1e5da1ca345cc665a0cffe2c3</pre>
====ROUND 2====
* Coordinator
** <tt>my_multisig_wallet.bsms</tt>:
<pre>BSMS 1.0
/0/*,/1/*
sh(wsh(multi(2,[110dc257/48'/0'/0'/1']xpub6EPQbDFezXYvVFHqnc8R7QUSE8hTepbyCXU7jJBT4dVm2rQHe1i6isqoj59qhyBiCdKquo6QsgMZNHvEz3BM4cNSszF25siTqLUCznBm8vk/*,[5c890401/48'/0'/0'/1']xpub6EW1SmjSXq9YwVwcan5qWEncgx89SozMvGNpYF6hfZHYNTikNZ4gsXuVhHTi6xYJCkmY4X4wpPPS5Gr7aY39dVJMS2TGfihr25oaspKtU8q/*,[614cbf5f/48'/0'/0'/1']xpub6F9TfWTFcMYy5Ycd2ka2az1brJj78J2isLAWptZnCpFsesss5sZv5B8xsgt71ZXfhDWhUtf4vng4zY6HUVrQbDMPDYRLYvFFoLnAYfzgYPH/*)))#j3ykhz7f</pre>
* Send to Signer 1:
** HMAC_KEY (hex):
f43c359a4b3d7b2e01be73c54519b12545ca9a23a86f824aadf577b314a7caa7
** MAC (hex): ee74a0f50943d7d1b65270028bb05133e87c832cdc1ef0a07c79db2093ca3432
** IV (hex) : ee74a0f50943d7d1b65270028bb05133
** CIPHERTEXT (hex):
8e3ba3dac0f979fad0d160bd00c8294ff1726d51b95ff3e1534e5a1900f3d7cd4f6d929985a94b9da2c11e4e0f7770cc53c6739fd099477323bd26a3eca9c8016e79848d15e274463424b8355cd73cced61f1816ac8bac87f8c650ee9052f50e347c52ad24b00794a9d5523714be2fdcf731f14b7a8d7c93eab44c258e1c417d2837b9676832e8ce7239dc28b4e1166803209947b8a875a99b9478ee94f7bc17399e886179ab2a0285dc11a3883f6fa439d0f2277dadbec8c355c379fc50e945897e1a738f6a55b09f6b8b6bdf6d4bc248219cbad3662a78a2f539c989e055e00b8efd42fbff978e1a5cc10f83df56117ece4d17f94a0a6d3803778ed53531419250c5a0fff6cad4ab401468dd054915b068cc8826ae1308a71b38060d68c9248d59eea11c2c52a66d5f6bc0d7ae6cb44305c36e56068456d293b70037902e7b05a3ee0af710201128dffc0c16c3306b66bd19b9ae5b91aded35ef33f07743e5b185a9f88a5c67d40270e3bbcf592167ceaf82ead693728d5129b50075edd5ce24863f3484b4b063599ed1327e1c87d0a2051fed3b1234a702722b686e4c9392a403b79726800dd6b691e516e44d9e836c190b10cf2bb262bba98293c97f2c323e59acd0a1f988c5
** <tt>my_multisig_wallet_for_signer_1.dat</tt>:
<pre>ee74a0f50943d7d1b65270028bb05133e87c832cdc1ef0a07c79db2093ca34328e3ba3dac0f979fad0d160bd00c8294ff1726d51b95ff3e1534e5a1900f3d7cd4f6d929985a94b9da2c11e4e0f7770cc53c6739fd099477323bd26a3eca9c8016e79848d15e274463424b8355cd73cced61f1816ac8bac87f8c650ee9052f50e347c52ad24b00794a9d5523714be2fdcf731f14b7a8d7c93eab44c258e1c417d2837b9676832e8ce7239dc28b4e1166803209947b8a875a99b9478ee94f7bc17399e886179ab2a0285dc11a3883f6fa439d0f2277dadbec8c355c379fc50e945897e1a738f6a55b09f6b8b6bdf6d4bc248219cbad3662a78a2f539c989e055e00b8efd42fbff978e1a5cc10f83df56117ece4d17f94a0a6d3803778ed53531419250c5a0fff6cad4ab401468dd054915b068cc8826ae1308a71b38060d68c9248d59eea11c2c52a66d5f6bc0d7ae6cb44305c36e56068456d293b70037902e7b05a3ee0af710201128dffc0c16c3306b66bd19b9ae5b91aded35ef33f07743e5b185a9f88a5c67d40270e3bbcf592167ceaf82ead693728d5129b50075edd5ce24863f3484b4b063599ed1327e1c87d0a2051fed3b1234a702722b686e4c9392a403b79726800dd6b691e516e44d9e836c190b10cf2bb262bba98293c97f2c323e59acd0a1f988c5</pre>
* Send to Signer 2:
** HMAC_KEY (hex):
e0a20b5f5285fbaa35aad08fb70f5626c9abbe1b384a4950735b28aca6325ff2
** MAC (hex): 81df9e064f1de1d5f754c4e20f9286f9d81b856d3965677a9f2430cb9297ad1f
** IV (hex) : 81df9e064f1de1d5f754c4e20f9286f9
** CIPHERTEXT (hex):
dcd82038ef627d6cb2deb62d04c4ccbaa3a354633d960e46312c22791f039f23fd9782a1e3a63504c1e5b3a0770bb8d32fdf168738b6c03278f1391dd5d01e9aafee7be2c8136ee018feff6fc8cdb926df13a36e115ddca8254934f56b7f700768c94cb8388a8297834de9affcd959417ae3d6ec3251387904f50f51f06306cc4d36eefc51418dd3b2c5454910a23ec67a40a3b918d2a740e812929aae949d8dde2c41cbbb3a2b7c2103788421c147f4794d6a26947c15ef4a99ceb825d0c5aaa78b8737d0ef712ba8e269a9941b1af5d217dcdd9cd06727fbdc70fabe3f5a8c09acff4e76992be7f27c6b12ca84739f62a6da86e5b79103d632c0dc8ab3f91fddb3cfbe67084dc4b861c4ac7c86fb171a058c98c67cffdc40ff17ae1533361cc6fb7b63657af0408cf30bf9d6d97aaacf9d3ff443eee61f207228cd91769ce83a0709c1be1847884c6a8fdc86ede66aef8e34fc509c49edf30f743bdc8f9052961ee340924ec2d1caadc6fd286bb3e233c153cd08c1934127752dc28e0d12efa92a050c4061653edb1cbf2fd4b2ba4e038f0b44f5735f198e92571c029156f65f534bfc149f38d611829901372cfc0176b9d2f9ac6512b7f37941a02dff701df0bceadaacfc6935
** <tt>my_multisig_wallet_for_signer_2.dat</tt>:
<pre>81df9e064f1de1d5f754c4e20f9286f9d81b856d3965677a9f2430cb9297ad1fdcd82038ef627d6cb2deb62d04c4ccbaa3a354633d960e46312c22791f039f23fd9782a1e3a63504c1e5b3a0770bb8d32fdf168738b6c03278f1391dd5d01e9aafee7be2c8136ee018feff6fc8cdb926df13a36e115ddca8254934f56b7f700768c94cb8388a8297834de9affcd959417ae3d6ec3251387904f50f51f06306cc4d36eefc51418dd3b2c5454910a23ec67a40a3b918d2a740e812929aae949d8dde2c41cbbb3a2b7c2103788421c147f4794d6a26947c15ef4a99ceb825d0c5aaa78b8737d0ef712ba8e269a9941b1af5d217dcdd9cd06727fbdc70fabe3f5a8c09acff4e76992be7f27c6b12ca84739f62a6da86e5b79103d632c0dc8ab3f91fddb3cfbe67084dc4b861c4ac7c86fb171a058c98c67cffdc40ff17ae1533361cc6fb7b63657af0408cf30bf9d6d97aaacf9d3ff443eee61f207228cd91769ce83a0709c1be1847884c6a8fdc86ede66aef8e34fc509c49edf30f743bdc8f9052961ee340924ec2d1caadc6fd286bb3e233c153cd08c1934127752dc28e0d12efa92a050c4061653edb1cbf2fd4b2ba4e038f0b44f5735f198e92571c029156f65f534bfc149f38d611829901372cfc0176b9d2f9ac6512b7f37941a02dff701df0bceadaacfc6935</pre>
* Send to Signer 3:
** HMAC_KEY (hex):
1f51ea067c121e2f86af5e1d484905046bc63e861573157d8b1ae9e7e47e224b
** MAC (hex): 159a91100cacd123480b7d085c8bb32ec8eb06f0391b6dc8fac07ae67eb37b81
** IV (hex) : 159a91100cacd123480b7d085c8bb32e
** CIPHERTEXT (hex):
c7269d8be21d1cfe172e35aa106760f1fdc929fce19da8fb7f74f759efec1ee02796fb1e8b008cf177f60a2021570f17aeeb41f8636858654082734b90959b98fd08419f901683c4ca3e76b3e482fea4c67162775e0d80bcb45df729f646c1364a3d8a7d1ff961717b00897e877c1c0554d3502942149726806269c546ad2dd34ba286ddf5cd336b83aabf7091fa25e607faf7e54017d84113e1e3ec440b3704addea188b89293469306fc0a98570afdcf269026b2d2e760f466c1f75bcf75fdf030c0a692e5681fd4487e59d6e96451ff5b6b9f2521b8e95e796ef4ab0a917794d91a30fdac7ee9ddbd89d174831bd133ab12a74f52f6283ee2c5fe3d5a957a7c1a15530b2c5224f76d90057dc94f2ee34e28b037ae7f518cc6dfe725cd3e657648de82b200ea77830eb93219f883998d3207a4ef5902d1119b0cde6b364bc1effb86109d9c2babc8ab26dce90329779d8cd0d737e9825a25586aa3c8fa5317e3e433ff235b82f629de0504e3c992f8e8de299f62751bc1fcb2e75e0262c7a27be7068cea69b14f303e97c24b99ed29cae142564e285657704b4c411d0d4f8c58819e2c0e0ffc3667eb5a408aad8a3023a5f00875e7deab95dc365d8757f7b79815a4fd9e6de2b3
** <tt>my_multisig_wallet_for_signer_3.dat</tt>:
<pre>159a91100cacd123480b7d085c8bb32ec8eb06f0391b6dc8fac07ae67eb37b81c7269d8be21d1cfe172e35aa106760f1fdc929fce19da8fb7f74f759efec1ee02796fb1e8b008cf177f60a2021570f17aeeb41f8636858654082734b90959b98fd08419f901683c4ca3e76b3e482fea4c67162775e0d80bcb45df729f646c1364a3d8a7d1ff961717b00897e877c1c0554d3502942149726806269c546ad2dd34ba286ddf5cd336b83aabf7091fa25e607faf7e54017d84113e1e3ec440b3704addea188b89293469306fc0a98570afdcf269026b2d2e760f466c1f75bcf75fdf030c0a692e5681fd4487e59d6e96451ff5b6b9f2521b8e95e796ef4ab0a917794d91a30fdac7ee9ddbd89d174831bd133ab12a74f52f6283ee2c5fe3d5a957a7c1a15530b2c5224f76d90057dc94f2ee34e28b037ae7f518cc6dfe725cd3e657648de82b200ea77830eb93219f883998d3207a4ef5902d1119b0cde6b364bc1effb86109d9c2babc8ab26dce90329779d8cd0d737e9825a25586aa3c8fa5317e3e433ff235b82f629de0504e3c992f8e8de299f62751bc1fcb2e75e0262c7a27be7068cea69b14f303e97c24b99ed29cae142564e285657704b4c411d0d4f8c58819e2c0e0ffc3667eb5a408aad8a3023a5f00875e7deab95dc365d8757f7b79815a4fd9e6de2b3</pre>
==Acknowledgement==
Special thanks to Pavol Rusnak, Dmitry Petukhov, Christopher Allen,
Craig Raw, Robert Spigler, Gregory Sanders, Ta Tat Tai, Michael
Flaxman, Pieter Wuille and others for their feedback on the
specification.
==References==
Original mailing list thread:
https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2021-February/018385.html
[-- Attachment #2: Type: text/html, Size: 41762 bytes --]
^ permalink raw reply [flat|nested] 37+ messages in thread
* Re: [bitcoin-dev] Proposal: Bitcoin Secure Multisig Setup
2021-04-05 7:02 ` Hugo Nguyen
@ 2021-04-09 12:07 ` Sjors Provoost
2021-04-09 14:09 ` Hugo Nguyen
2021-04-09 14:54 ` Hugo Nguyen
2021-04-11 2:34 ` Michael.flaxman
1 sibling, 2 replies; 37+ messages in thread
From: Sjors Provoost @ 2021-04-09 12:07 UTC (permalink / raw)
To: Bitcoin Dev; +Cc: marko, aarondongchen, peter
[-- Attachment #1: Type: text/plain, Size: 3671 bytes --]
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 <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.
>
> As a PR: https://github.com/bitcoin/bips/pull/1097
[-- Attachment #2: Message signed with OpenPGP --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
^ permalink raw reply [flat|nested] 37+ messages in thread
* Re: [bitcoin-dev] Proposal: Bitcoin Secure Multisig Setup
2021-04-09 12:07 ` Sjors Provoost
@ 2021-04-09 14:09 ` Hugo Nguyen
2021-04-09 14:54 ` Hugo Nguyen
1 sibling, 0 replies; 37+ messages in thread
From: Hugo Nguyen @ 2021-04-09 14:09 UTC (permalink / raw)
To: Sjors Provoost; +Cc: marko, Bitcoin Dev, aarondongchen, Peter Gray
[-- Attachment #1: Type: text/plain, Size: 3220 bytes --]
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
[-- Attachment #2: Type: text/html, Size: 3614 bytes --]
^ permalink raw reply [flat|nested] 37+ messages in thread
* Re: [bitcoin-dev] Proposal: Bitcoin Secure Multisig Setup
2021-04-09 12:07 ` Sjors Provoost
2021-04-09 14:09 ` Hugo Nguyen
@ 2021-04-09 14:54 ` Hugo Nguyen
2021-04-09 15:33 ` Sjors Provoost
1 sibling, 1 reply; 37+ messages in thread
From: Hugo Nguyen @ 2021-04-09 14:54 UTC (permalink / raw)
To: Sjors Provoost; +Cc: marko, Bitcoin Dev, aarondongchen, Peter Gray
[-- Attachment #1: Type: text/plain, Size: 5063 bytes --]
(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.
> >
> > As a PR: https://github.com/bitcoin/bips/pull/1097
>
>
[-- Attachment #2: Type: text/html, Size: 7136 bytes --]
^ permalink raw reply [flat|nested] 37+ messages in thread
* Re: [bitcoin-dev] Proposal: Bitcoin Secure Multisig Setup
2021-04-09 14:54 ` Hugo Nguyen
@ 2021-04-09 15:33 ` Sjors Provoost
2021-04-10 19:32 ` Robert Spigler
0 siblings, 1 reply; 37+ messages in thread
From: Sjors Provoost @ 2021-04-09 15:33 UTC (permalink / raw)
To: Bitcoin Dev; +Cc: marko, aarondongchen, Peter Gray
[-- Attachment #1.1: Type: text/plain, Size: 1206 bytes --]
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
[-- Attachment #1.2: Type: text/html, Size: 2024 bytes --]
[-- Attachment #2: Message signed with OpenPGP --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
^ permalink raw reply [flat|nested] 37+ messages in thread
* Re: [bitcoin-dev] Proposal: Bitcoin Secure Multisig Setup
2021-02-08 23:14 [bitcoin-dev] Proposal: Bitcoin Secure Multisig Setup Hugo Nguyen
` (4 preceding siblings ...)
2021-04-05 7:02 ` Hugo Nguyen
@ 2021-04-10 13:53 ` Erik Aronesty
5 siblings, 0 replies; 37+ messages in thread
From: Erik Aronesty @ 2021-04-10 13:53 UTC (permalink / raw)
To: Hugo Nguyen, Bitcoin Protocol Discussion
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
<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
>
> <pre>
> BIP: To be determined
> Layer: Applications
> Title: Bitcoin Secure Multisig Setup (BSMS)
> Author: Hugo Nguyen <hugo@nunchuk•io>, Peter Gray <peter@coinkite•com>, Marko Bencun <marko@shiftcrypto•ch>, Aaron Chen <aarondongchen@gmail•com>, Rodolfo Novak <rodolfo@coinkite•com>
> Comments-Summary: No comments yet.
> Comments-URI:
> Status: Proposed
> Type: Standards Track
> Created: 2020-11-10
> License: BSD-2-Clause
> </pre>
>
> ==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 (<tt>M</tt> and <tt>N</tt>).
> * If encryption is enabled, the Coordinator also generates a secret token, hereby denoted <tt>TOKEN</tt>.
> * 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: <tt>ENCRYPTION_KEY = SHA256(SHA256(TOKEN))</tt>.
> * A TOKEN value of <tt>-1</tt> 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 <tt>TOKEN</tt>. If encryption is disabled, set the TOKEN to -1. The second line must be the <tt>KEY</tt>, whereas KEY is an XPUB. KEY must include key origin information and written in the descriptor-defined format, i.e.: <tt>[{master key fingerprint}/{derivation path}]{XPUB}</tt>. The third line must be a <tt>SIG</tt>, 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 string plus a <tt>CHECKSUM</tt>, all in one line. The CHECKSUM has BECH32 encoding and is described at [https://github.com/bitcoin/bitcoin/blob/master/doc/descriptors.md#checksums]. The Coordinator encrypts this descriptor record with ENCRYPTION_KEY.
> * The Coordinator sends the encrypted descriptor record to all participating Signers.
>
> ====Signer====
>
> * The Signer imports the descriptor record, decrypts it by prompting the user for TOKEN.
> * The Signer calculates and verifies the descriptor’s CHECKSUM. Abort the setup if the CHECKSUM is incorrect.
> * The Signer checks whether one of the KEYs in the descriptor belongs to it, using path and fingerprint information included in the descriptor. The check must perform an exact match on the KEYs, and not using shortcuts such as matching fingerprints (which is trivial to spoof). Abort the setup if it doesn’t detect its own KEY.
> * For confirmation, the Signer must display to the user the descriptor's CHECKSUM, plus other configurations, such as M and N. The total number of Signers, N, is important to prevent a KEY insertion attack. All participating Signers should be able to display the same confirmation.
> * If all checks pass, the Signer persists the descriptor record in its storage. The Signer should subsequently use the descriptor to generate and verify receive and change addresses.
>
> This completes the setup.
>
> ==QR Codes==
> For signers that use QR codes to transmit data, key and descriptor records can be converted to QR codes, following [https://github.com/BlockchainCommons/Research/blob/master/papers/bcr-2020-005-ur.md the BCR standard].
>
> ==Security==
>
> This proposal introduce two layers of protection. The first one is a temporary, secret token, used to encrypt the two rounds of communication between the Signers and the Coordinator. The second one is through the descriptor checksum and visual inspection of the descriptor itself.
>
> The token is only needed during the setup phase, and can be safely thrown away afterwards. The token does not guarantee that the Signer membership set is not modified, since that depends on the overall security of all parties in the setup, but it can make it significantly harder for an attacker to do so.
>
> There are three ways an attacker can modify the membership set: by changing an existing member, by removing an existing member, or by adding a new member.
>
> For the first two methods, one of the Signers will be able to detect that its membership has been changed or removed, and reject the final descriptor. Thus, it is vital that all participating Signers check that their membership is intact in the descriptor. Even one Signer failing to check for its membership means that the setup could be compromised.
>
> For the third type of attack, the descriptor checksum and visual inspection of the descriptor itself are the only way to guard against malicious members from being inserted into the set.
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists•linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
^ permalink raw reply [flat|nested] 37+ messages in thread
* Re: [bitcoin-dev] Proposal: Bitcoin Secure Multisig Setup
2021-04-09 15:33 ` Sjors Provoost
@ 2021-04-10 19:32 ` Robert Spigler
0 siblings, 0 replies; 37+ messages in thread
From: Robert Spigler @ 2021-04-10 19:32 UTC (permalink / raw)
To: Sjors Provoost, Bitcoin Protocol Discussion
Cc: marko, aarondongchen, Peter Gray
[-- Attachment #1: Type: text/plain, Size: 3021 bytes --]
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 <bitcoin-dev@lists•linuxfoundation.org> 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
[-- Attachment #2: Type: text/html, Size: 4461 bytes --]
^ permalink raw reply [flat|nested] 37+ messages in thread
* Re: [bitcoin-dev] Proposal: Bitcoin Secure Multisig Setup
2021-04-05 7:02 ` Hugo Nguyen
2021-04-09 12:07 ` Sjors Provoost
@ 2021-04-11 2:34 ` Michael.flaxman
2021-04-11 16:45 ` Hugo Nguyen
1 sibling, 1 reply; 37+ messages in thread
From: Michael.flaxman @ 2021-04-11 2:34 UTC (permalink / raw)
To: Hugo Nguyen, Bitcoin Protocol Discussion
[-- Attachment #1: Type: text/plain, Size: 45128 bytes --]
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 places -- and makes a large deposit to receive address X. These funds now belong to the attacker and can be swept at any time!
If stateless Signer 1 required a signature to be replayed at step 3, stateless Signer 1 would refuse to display malicious receive address X (or at a minimum warn the end-user that it did not have enough info to properly validate the address).
This is also a concern for self-hosted multisig, I just used the hosted services as the best example.
It's also not just Trezor that is stateless. For example, I wrote [a simple CLI software multisig wallet as part of the buidl library](https://twitter.com/mflaxman/status/1321503036724989952) to be used mostly for emergency recovery. At 800 lines of code, it's too simple/minimal to touch the file system.
BIP39
While unrelated, the use of BIP39 words for session tokens seems like a big mistake, as end-users have learned over years that BIP39 words are for private key material. A small percent of users may backup their token BIP39 mnemonic and not their seed phrase BIP39 mnemonic! My suggestion is to just stick with the other two Token options: decimal and hex.
Conclusion
The main purpose/benefit of the BIP seems to be the encryption protocol. I wouldn't have strong objections if the BIP were simply renamed Bitcoin Multisig Encryption, as that more accurately reflects what it does. That said, I think this BIP is missing out on a real opportunity to improve security in setting up a multisig scheme, and if adopted in the current form will negatively impact multisig adoption.
I can't support this BIP in the current form, but I'd be happy to submit a PR if it's helpful.
Best,
Michael
https://btcguide.github.io/
‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐
On Monday, April 5, 2021 2:02 AM, Hugo Nguyen via bitcoin-dev <bitcoin-dev@lists•linuxfoundation.org> wrote:
> 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
>
> <pre>
> BIP: To be determined
> Layer: Applications
> Title: Bitcoin Secure Multisig Setup (BSMS)
> Author: Hugo Nguyen <hugo at
> nunchuk.io
>>, Peter Gray <peter at
> coinkite.com
>>, Marko Bencun <marko at
> shiftcrypto.ch
>>, Aaron Chen <aarondongchen at
> gmail.com
>>, Rodolfo Novak <rodolfo at
> coinkite.com
>>
> Comments-Summary: No comments yet.
> Comments-URI:
> Status: Proposed
> Type: Standards Track
> Created: 2020-11-10
> License: BSD-2-Clause
> </pre>
>
> ==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 <tt>.bsms</tt> file extension. Encrypted data should have a <tt>.dat</tt> 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 (<tt>M</tt> and <tt>N</tt>).
> * 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 <tt>TOKEN</tt> to each Signer over a secure channel. The Signer can use the <tt>TOKEN</tt> to derive an <tt>ENCRYPTION_KEY</tt>. Refer to the Encryption section below for details on the <tt>TOKEN</tt>, the key derivation function and the encryption scheme. Depending on the use case, the Coordinator can decide whether to share one common <tt>TOKEN</tt> for all Signers, or to have one per Signer.
> * If encryption is disabled, the <tt>TOKEN</tt> is set to <tt>0</tt>, and all the encryption/decryption steps below can be skipped.
>
> =====Signer=====
>
> * The Signer initiates the multisig wallet creation session by setting the <tt>TOKEN</tt>. The Signer derives an <tt>ENCRYPTION_KEY</tt> from the <tt>TOKEN</tt>. The Signer can keep the session open until a different value for the <tt>TOKEN</tt> 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. Alternatively, the Signer can choose a path on behalf of the user. If the Signer chooses the path, it should try to avoid reusing XPUBs for different wallets.
> * The first line in the record must be the specification version (<tt>BSMS 1.0</tt> as of this writing). The second line must be the hex-encoded <tt>TOKEN</tt>. The third line must be the <tt>KEY</tt>. The <tt>KEY</tt> is an XPUB plus its key origin information, written in the descriptor-defined format, i.e.: <tt>[{master key fingerprint}/{derivation path}]{XPUB}</tt>. The fourth line is a text description of the key, 80 characters maximum. The fifth line must be a <tt>SIG</tt>, whereas <tt>SIG</tt> is the signature generated by using the private key associated with the XPUB to sign the first four lines. The signature should follow [
> https://github.com/bitcoin/bips/blob/master/bip-0322.mediawiki
> BIP-0322], legacy format accepted.
> * The Signer calculates the Message Authentication Code (<tt>MAC</tt>) for the record. The first 16 bytes of the <tt>MAC</tt> serves as the Initialization Vector (<tt>IV</tt>) for the encryption.
> * The Signer encrypts the key record with the <tt>ENCRYPTION_KEY</tt> and <tt>IV</tt>.
> * The Signer encodes the <tt>MAC</tt> and the ciphertext into hexadecimal format, then concatenates the results: <tt>(MAC || ciphertext)</tt>.
>
> ====Round 2====
>
> =====Coordinator=====
>
> * The Coordinator gathers key records from all participating Signers. The Coordinator verifies that there are exactly <tt>N</tt> unique key records before the wallet setup session expires.
> * For each key record, the Coordinator extracts the <tt>MAC</tt> from the data, sets <tt>IV</tt> to the first 16 bytes of the <tt>MAC</tt>, then decrypts the ciphertext using the <tt>ENCRYPTION_KEY</tt> and <tt>IV</tt>.
> * The Coordinator verifies that the included <tt>MAC</tt> is valid given the plaintext.
> * The Coordinator verifies that the key records have compatible specification versions.
> * The Coordinator verifies that the included <tt>SIG</tt> is valid given the <tt>KEY</tt>.
> * If all key records look good, the Coordinator fills in all necessary information to generate a descriptor record.
> * The first line in the descriptor record must be the specification version (<tt>BSMS 1.0</tt> as of this writing). The second line must be a comma-separated list of accepted derivation paths that the Signers can use to generate addresses from the included XPUBs. The paths must start with <tt>/</tt> and use non-hardened derivation. For example, <tt>/0/*</tt> and <tt>/1/*</tt> are some common paths. If there are no restrictions, it must say <tt>No path restrictions</tt>. The third line must be the descriptor string plus a <tt>CHECKSUM</tt>, all in one line. The <tt>CHECKSUM</tt> has [
> https://github.com/bitcoin/bitcoin/blob/master/doc/descriptors.md#checksums
> BECH32 encoding].
> * The Coordinator calculates the <tt>MAC</tt> for the record. The first 16 bytes of the <tt>MAC</tt> serves as the <tt>IV</tt> for the encryption..
> * The Coordinator encrypts the descriptor record with the <tt>ENCRYPTION_KEY</tt> and <tt>IV</tt>.
> * The Coordinator encodes the <tt>MAC</tt> and the ciphertext into hexadecimal format, then concatenates the results: <tt>(MAC || ciphertext)</tt>.
> * The Coordinator sends the encrypted descriptor record to all participating Signers.
>
> =====Signer=====
>
> * The Signer imports the descriptor record.
> * The Signer extracts the <tt>MAC</tt> from the data, sets <tt>IV</tt> to the first 16 bytes of the <tt>MAC</tt>, then decrypts the ciphertext using the <tt>ENCRYPTION_KEY</tt> (derived from the open session) and <tt>IV</tt>.
> * The Signer verifies that the included <tt>MAC</tt> is valid given the plaintext.
> * The Signer verifies that it can support the included specification version.
> * The Signer verifies that it is compatible with the derivation path restrictions.
> * The Signer verifies the descriptor’s <tt>CHECKSUM</tt>.
> * The Signer verifies that it can support the descriptor.
> * The Signer checks that its <tt>KEY</tt> is included in the descriptor, using path and fingerprint information provided. The check must perform an exact match on the <tt>KEY</tt>s and not using shortcuts such as matching fingerprints, which is trivial to spoof.
> * For confirmation, the Signer must display to the user the <tt>CHECKSUM</tt>, the derivation path restrictions and the policy parameters, such as <tt>M</tt>, <tt>N</tt> and the position(s) of its own XPUB in the policy script. The total number of Signers, <tt>N</tt>, is important to prevent a <tt>KEY</tt> insertion attack. The position is important for scripts where key order matters. When applicable, all positions of the XPUB must be displayed. The full descriptor must also be available for review upon user request.
> * When possible, the Signer should also show a preview of the first address(es) of the wallet.
> * Parties must check with each other that all Signers have verified the descriptor and has the same confirmation (except for the key positions).
> * If all checks pass, the Signer must persist the descriptor record in its storage.
>
> This completes the setup.
>
> ===Encryption===
>
> ====The Token====
> We define three modes of encryption.
>
> # <tt>NO_ENCRYPTION</tt> : the <tt>TOKEN</tt> is set to <tt>0</tt>. Encryption is disabled.
> # <tt>STANDARD</tt> : the <tt>TOKEN</tt> is a 64-bit nonce.
> # <tt>EXTENDED</tt> : the <tt>TOKEN</tt> is a 96-bit nonce.
>
> The <tt>TOKEN</tt> can be converted to one of these formats:
> * A decimal number (recommended). The number must not exceed the maximum value of the nonce.
> * A mnemonic phrase using [
> https://github.com/bitcoin/bips/blob/master/bip-0039.mediawiki
> BIP-0039] word list (6 words in <tt>STANDARD</tt> mode; 9 words in <tt>EXTENDED</tt> mode).
> * A QR code.
> * Other formats.
>
> The flexibility in the data format allows each Signer to customize the User Experience based on its respective capabilities.
>
> ====Key Derivation====
> The key derivation function is [
> https://tools.ietf.org/html/rfc2898
> PBKDF2], with PRF = SHA512. Specifically:
>
> <tt>DKey = PBKDF2(PRF, Password, Salt, c, dkLen)</tt>
>
> Whereas:
>
> * PRF = SHA512
> * Password = "No SPOF"
> * Salt = <tt>TOKEN</tt>
> * c = 2048
> * dkLen = 256
> * DKey = Derived <tt>ENCRYPTION_KEY</tt>
>
> ====Encryption Scheme====
> The encryption scheme is [
> https://tools.ietf.org/html/rfc3686
> AES-256-CTR].
>
> <tt>MAC = HMAC-SHA256(HMAC_Key, hex-encoded TOKEN || Data)</tt>
>
> <tt>IV = First 16 bytes of MAC</tt>
>
> <tt>Ciphertext = AES-256-CTR-Encrypt(Plaintext, DKey, IV)</tt>
>
> <tt>Plaintext = AES-256-CTR-Decrypt(Ciphertext, DKey, IV)</tt>
>
> Whereas:
> * DKey = <tt>ENCRYPTION_KEY</tt>
> * HMAC_Key = SHA256(<tt>ENCRYPTION_KEY</tt>)
> * Data = the plaintext, e.g. the entire key record in round 1 and the entire descriptor record in round 2
>
> The <tt>MAC</tt> is to be sent along with the key and descriptor record, as specified above. Because it is a <tt>MAC</tt> over the entire plaintext, this is essentially an [
> https://en.wikipedia.org/wiki/Authenticated_encryption#Encrypt-and-MAC_(E&M)
> Encrypt-and-MAC] form of authenticated encryption.
>
> ==QR Codes==
> For signers that use QR codes to transmit data, key and descriptor records can be converted to QR codes, following [
> https://github.com/BlockchainCommons/Research/blob/master/papers/bcr-2020-005-ur.md
> the BCR standard].
>
> Also refer to [
> https://github.com/BlockchainCommons/Research/blob/master/papers/bcr-2020-015-account.md
> UR Type Definition for BIP44 Accounts] and [
> https://github.com/BlockchainCommons/Research/blob/master/papers/bcr-2020-010-output-desc.md
> UR Type Definition for Bitcoin Output Descriptors] for more details.
>
> ==Security==
>
> This proposal introduces two layers of protection. The first one is a temporary, secret <tt>TOKEN</tt>. The second one is the descriptor <tt>CHECKSUM</tt>.
>
> The <tt>TOKEN</tt> is used to encrypt the two rounds of communication between the Signer and the Coordinator. A <tt>MAC</tt> is also generated from the <tt>TOKEN</tt> and plaintext to authenticate the data being exchanged. The <tt>TOKEN</tt> is only needed during the setup phase, and can be safely discarded afterwards.
>
> The descriptor <tt>CHECKSUM</tt>, on the other hand, can be used to verify the integrity of the multisig configuration. An attacker who tampers with the multisig configuration must also change the descriptor <tt>CHECKSUM</tt>. Parties must check with each other that all Signers have the same <tt>CHECKSUM</tt>, along with the policy parameters, to reduce the chance of tampering. The <tt>CHECKSUM</tt> must be persisted along with the descriptor in each Signer’s storage.
>
> The <tt>TOKEN</tt> and the <tt>CHECKSUM</tt> can’t guarantee complete protection, since that depends on the overall security of all parties in the setup, but they can make it significantly harder for an attacker to tamper with the multisig configuration.
>
> ==Privacy==
> Encryption helps improve the privacy of the wallet by avoiding sharing XPUBs and descriptors in plaintext.
>
> If the parties wish to have stronger privacy, it is recommended to use a higher number of bits for the <tt>TOKEN</tt>, and to completely erase knowledge of the <tt>TOKEN</tt> after the multisig wallet has been set up.
>
> ==Test Vectors==
>
> ===Mode: <tt>NO_ENCRYPTION</tt>===
> ====ROUND 1====
> * Coordinator
> ** M-of-N: 2/2
> ** ADDRESS_TYPE: NATIVE_SEGWIT
> ** TOKEN: 0
>
> * Signer 1
> ** MASTER_KEY_FINGERPRINT: 539f3d89
> ** PRIVATE_KEY (m/48'/0'/0'/2'): KyoXqiwiz6qm21BSYebiZFfNF7obkhiJW6TdPMZTQQMF4kZtfD78
> ** XPUB (m/48'/0'/0'/2'): xpub6ETerig7tq89mtaD8Gau2xRWxouRMBy6XHqciA8GZzC2dJv3w6FxfgoegH4b2qYF4oG6VBrhpLrauPs5E1q58GLCnhKp6g9QsV9ZA7J5JNa
> ** Legacy signature
> ** <tt>signer_1_key.bsms</tt>:
> <pre>BSMS 1.0
> 00
> [539f3d89/48'/0'/0'/2']xpub6ETerig7tq89mtaD8Gau2xRWxouRMBy6XHqciA8GZzC2dJv3w6FxfgoegH4b2qYF4oG6VBrhpLrauPs5E1q58GLCnhKp6g9QsV9ZA7J5JNa
> Signer 1 key
> IPXsnNSZb8M6H4fAWtpjAc75hyHHd89fskpM5o7qFg+mPDzEPc1k2mjuIpVIIzaCe45FwPfAAa91RaStfC5Sak0=</pre>
>
> * Signer 2
> ** MASTER_KEY_FINGERPRINT: f8b12aa6
> ** PRIVATE_KEY (m/48'/0'/0'/2'): L1zht7muKnUYFMdzC3jwXd78u8tGoKr46AXGh4waF9nphUYWq7ow
> ** XPUB (m/48'/0'/0'/2'): xpub6EWPNhGSX86SN4J2DrBUaQ826o6V4egHqAJZUDJqnsthv9CcjBZV79u68M3YZkuTJnJBXfCrHuJy97fkVurntwgt3V7Ms5hXpJV2vS8fQZM
> ** Legacy signature
> ** <tt>signer_2_key.bsms</tt>:
> <pre>BSMS 1.0
> 00
> [f8b12aa6/48'/0'/0'/2']xpub6EWPNhGSX86SN4J2DrBUaQ826o6V4egHqAJZUDJqnsthv9CcjBZV79u68M3YZkuTJnJBXfCrHuJy97fkVurntwgt3V7Ms5hXpJV2vS8fQZM
> Signer 2 key
> H38+lp9iaesBeCN05BDTH/SnmarlH6+X+Kmw1pgCk+c1Pc1evYIdBag9Nc0nsKhvPtfEbRt9r/qsUVZ5onCtBTc=</pre>
>
> ====ROUND 2====
> * Coordinator
> ** <tt>my_multisig_wallet.bsms</tt>:
> <pre>BSMS 1.0
> /0/*,/1/*
> wsh(sortedmulti(2,[539f3d89/48'/0'/0'/2']xpub6ETerig7tq89mtaD8Gau2xRWxouRMBy6XHqciA8GZzC2dJv3w6FxfgoegH4b2qYF4oG6VBrhpLrauPs5E1q58GLCnhKp6g9QsV9ZA7J5JNa/*,[f8b12aa6/48'/0'/0'/2']xpub6EWPNhGSX86SN4J2DrBUaQ826o6V4egHqAJZUDJqnsthv9CcjBZV79u68M3YZkuTJnJBXfCrHuJy97fkVurntwgt3V7Ms5hXpJV2vS8fQZM/*))#fntxdj7p</pre>
>
> ===Mode: <tt>STANDARD</tt> Encryption===
> ====ROUND 1====
> * Coordinator
> ** M-of-N: 2/2
> ** ADDRESS_TYPE: NATIVE_SEGWIT
> ** TOKEN (hex): 1ed4ba49e96336b8
> *** TOKEN (decimal): 2221605342811469496
> *** TOKEN (mnemonic): burst place mystery spot cricket foster
> ** ENCRYPTION_KEY (hex): 72185a0e25b4efc5d6ac0f8ed32b0165199100e32385040e3a48eb30164bf492
>
> * Signer 1
> ** MASTER_KEY_FINGERPRINT: 98d79e95
> ** PRIVATE_KEY (m/48'/0'/0'/2'): KydC7hZFtWe56oQUAw14HvQ3gKeKVd3m8frFgVMxUqpuhKHvcmm3
> ** XPUB (m/48'/0'/0'/2'): xpub6DvvwHS5pd1D36xt4YBGJvtdThWXfn8L9qRj9DbFMExMeP6eBE6Aw9WyBC7XUQwiPPDFurirewsKZpYv68yTV5RBy7SZmw45QEkaLka5BCt
> ** Legacy signature
> ** <tt>signer_1_key.bsms</tt>:
> <pre>BSMS 1.0
> 1ed4ba49e96336b8
> [98d79e95/48'/0'/0'/2']xpub6DvvwHS5pd1D36xt4YBGJvtdThWXfn8L9qRj9DbFMExMeP6eBE6Aw9WyBC7XUQwiPPDFurirewsKZpYv68yTV5RBy7SZmw45QEkaLka5BCt
> Signer 1 key
> HxtPoP0DrQSac/7ypcwC07R2s6jjpXR6Li2Q92zXj/FSIMQcV5yOU0/ONsDgHXamq0gD5DfPbvuVCp9ZJubclV4=</pre>
>
> * Signer 1 encryption
> ** HMAC_KEY (hex): 4dab3988cbc683ad7a8c93d43f9b11a78b63a93d5e33ea19c603f4b7b87ac284
> ** MAC (hex): afe99e92f0eadc3308eb990045e90a4f54e9f59d22aae5034ac3d866d29c508d
> ** IV (hex) : afe99e92f0eadc3308eb990045e90a4f
> ** CIPHERTEXT (hex): 214ec9a861a238ba7f0412305a97a6e0faa332be15af09127e131d669e5d55d73891580a5808cea5d2bf39f43496d3c0f8236eff3854fcc7446daf9d2b58fd40d97ce3b1745de2959e29767039b99969821400eca0c3517fae56d2d24d5235a3430af1ed894b68681d706cce7c75adf35d8580603aa302bc01fef06d0336a37f19dd46100baa9e4eabd8796a810e13941ad0980c126ad55d6a4bbef11a7bf893b7d2ed8fb0d8324c4c9b512d4d1e75096c63511e15018fc832816b5639d58fc28c60c049487d04bd5a6cb32aa1381d0809660d54376b9f63325c18cfd1ac5024088e74cb703fe165972cc4485abb1feefe92a0b4ea297fe2f4f7416eeee1efc9b942540931ef
> ** <tt>signer_1_key.dat</tt>: <pre>afe99e92f0eadc3308eb990045e90a4f54e9f59d22aae5034ac3d866d29c508d214ec9a861a238ba7f0412305a97a6e0faa332be15af09127e131d669e5d55d73891580a5808cea5d2bf39f43496d3c0f8236eff3854fcc7446daf9d2b58fd40d97ce3b1745de2959e29767039b99969821400eca0c3517fae56d2d24d5235a3430af1ed894b68681d706cce7c75adf35d8580603aa302bc01fef06d0336a37f19dd46100baa9e4eabd8796a810e13941ad0980c126ad55d6a4bbef11a7bf893b7d2ed8fb0d8324c4c9b512d4d1e75096c63511e15018fc832816b5639d58fc28c60c049487d04bd5a6cb32aa1381d0809660d54376b9f63325c18cfd1ac5024088e74cb703fe165972cc4485abb1feefe92a0b4ea297fe2f4f7416eeee1efc9b942540931ef</pre>
>
> * Signer 2
> ** MASTER_KEY_FINGERPRINT: 3e94b5a1
> ** PRIVATE_KEY (m/48'/0'/0'/2'): KyPh5XYjExjNHPiBjYhp8iAntAehrDziiwRv7y9Ln6eK9QU2xP55
> ** XPUB (m/48'/0'/0'/2'): xpub6E1W1DUYY29V2b8czCcpi36GG2uD33B11vwNopgTZwsVyfgAkA4kPCqLP5R4YzaRvzW17CQrDkgmDQbA848AdkR7W18nNvMKXzzCBSnZP9c
> ** Legacy signature
> ** <tt>signer_2_key.bsms</tt>:
> <pre>BSMS 1.0
> 1ed4ba49e96336b8
> [3e94b5a1/48'/0'/0'/2']xpub6E1W1DUYY29V2b8czCcpi36GG2uD33B11vwNopgTZwsVyfgAkA4kPCqLP5R4YzaRvzW17CQrDkgmDQbA848AdkR7W18nNvMKXzzCBSnZP9c
> Signer 2 key
> ILR49QLy9+xkMS11TIXJRSMgOQOzGbAaooq4/ZRcd8VgM6j5upJMI0mjJHseQOMYSGk8FqjXZbMvBGyiX9wdutM=</pre>
>
> * Signer 2 encryption
> ** HMAC_KEY (hex): 4dab3988cbc683ad7a8c93d43f9b11a78b63a93d5e33ea19c603f4b7b87ac284
> ** MAC (hex): 5c7cb2ac407cd60b1f2b86ef46077d3a312b6ce921df2a141347e8bf1e5c6573
> ** IV (hex) : 5c7cb2ac407cd60b1f2b86ef46077d3a
> ** CIPHERTEXT (hex): f23e6c76ff45d308dea6014030a274127ad437228f1d5ec2431d2ea9e3cedd5b0a207a9efa6f926d5420205003f3cb9c4b82b2d595180e62a173a2e5aa0322de48a70a873f641bdae1764e6b1667c241e0fe03a4ccdc3fe0cfa5f75b239d6497c3b69dca17bb685ba70b307d1243836d8fb198ce727cfae4057ee0b4fdcb09f4ba5ae127f49c5de780edb4e40aec96303c8a7b98b1b8e53dd5e07e01d4f3ffd836763209a1f0cbc61adcfdc2951e77528ee7b6e68114c3a4bec38875d285021e68ae8aa913bb1e2e65dd52c649a0e98bfb4e8bab6dd10295c1167a0854ba44f094feb75d2fb00c944f07d4b47114f483df9838459316f3ddbc4a82e6507881931f8e20f5b805
> ** <tt>signer_2_key.dat</tt>: <pre>5c7cb2ac407cd60b1f2b86ef46077d3a312b6ce921df2a141347e8bf1e5c6573f23e6c76ff45d308dea6014030a274127ad437228f1d5ec2431d2ea9e3cedd5b0a207a9efa6f926d5420205003f3cb9c4b82b2d595180e62a173a2e5aa0322de48a70a873f641bdae1764e6b1667c241e0fe03a4ccdc3fe0cfa5f75b239d6497c3b69dca17bb685ba70b307d1243836d8fb198ce727cfae4057ee0b4fdcb09f4ba5ae127f49c5de780edb4e40aec96303c8a7b98b1b8e53dd5e07e01d4f3ffd836763209a1f0cbc61adcfdc2951e77528ee7b6e68114c3a4bec38875d285021e68ae8aa913bb1e2e65dd52c649a0e98bfb4e8bab6dd10295c1167a0854ba44f094feb75d2fb00c944f07d4b47114f483df9838459316f3ddbc4a82e6507881931f8e20f5b805</pre>
>
> ====ROUND 2====
> *Coordinator
> ** <tt>my_multisig_wallet.bsms</tt>:
> <pre>BSMS 1.0
> /0/*,/1/*
> wsh(sortedmulti(2,[98d79e95/48'/0'/0'/2']xpub6DvvwHS5pd1D36xt4YBGJvtdThWXfn8L9qRj9DbFMExMeP6eBE6Aw9WyBC7XUQwiPPDFurirewsKZpYv68yTV5RBy7SZmw45QEkaLka5BCt/*,[3e94b5a1/48'/0'/0'/2']xpub6E1W1DUYY29V2b8czCcpi36GG2uD33B11vwNopgTZwsVyfgAkA4kPCqLP5R4YzaRvzW17CQrDkgmDQbA848AdkR7W18nNvMKXzzCBSnZP9c/*))#x0lx92qk</pre>
>
> *Coordinator encryption
> ** HMAC_KEY (hex): 4dab3988cbc683ad7a8c93d43f9b11a78b63a93d5e33ea19c603f4b7b87ac284
> ** MAC (hex): df3d06db6c8b8a5f25de202e10ea225df6415d1ed0e36c64cc2be1b7e86c2a38
> ** IV (hex) : df3d06db6c8b8a5f25de202e10ea225d
> ** CIPHERTEXT (hex): 2761e6bfe839586b4c90954200bc4ce6d39ef164c5d14997755575d1691ee249ffd20beda526f57a7424907f839c6c2e3ecd46889ede290a2c81de22d3f33a7fa5e55ec95c0e26005c596d0f6346f819823f361f9f9f54d1eae48b325240d66c5888bd5ebab843061dcdd73b675346da982646c83026694d757661d31c2d654fb263c9ab3e874a258bc234c48532f15e9450c982fcf161404746e9f23d25e17b74139cd799983fd0c7a7a0386a823d3789b4578879a764172cc8ef96ab003eee24f6288007d31e2b999aff5a6d30cc524a0111a99730a29cf28ae41dbff6ce21ca6bc1df37074228178048e835584e6e70dba941154d024cd03cb6c56d0bde441ce464aa749de5e814dd30e21b75f62e831ac1f28eda1a7ba7e122076789e284402c8ba85b5a0e864bce220e3c78fa2f465e2bcf6b1d378816319de99f99ce7068
> ** <tt>my_multisig_wallet.dat</tt>: <pre>df3d06db6c8b8a5f25de202e10ea225df6415d1ed0e36c64cc2be1b7e86c2a382761e6bfe839586b4c90954200bc4ce6d39ef164c5d14997755575d1691ee249ffd20beda526f57a7424907f839c6c2e3ecd46889ede290a2c81de22d3f33a7fa5e55ec95c0e26005c596d0f6346f819823f361f9f9f54d1eae48b325240d66c5888bd5ebab843061dcdd73b675346da982646c83026694d757661d31c2d654fb263c9ab3e874a258bc234c48532f15e9450c982fcf161404746e9f23d25e17b74139cd799983fd0c7a7a0386a823d3789b4578879a764172cc8ef96ab003eee24f6288007d31e2b999aff5a6d30cc524a0111a99730a29cf28ae41dbff6ce21ca6bc1df37074228178048e835584e6e70dba941154d024cd03cb6c56d0bde441ce464aa749de5e814dd30e21b75f62e831ac1f28eda1a7ba7e122076789e284402c8ba85b5a0e864bce220e3c78fa2f465e2bcf6b1d378816319de99f99ce7068</pre>
>
> ===Mode: <tt>EXTENDED</tt> Encryption===
> ====ROUND 1====
> *Coordinator
> ** M-of-N: 2/3
> ** ADDRESS_TYPE: NESTED_SEGWIT
> ** TOKEN for Signer 1 (hex): 654d63309464afcda558c6aa
> *** TOKEN (decimal): 31351541690484562733651510954
> *** TOKEN (mnemonic): grab help slow churn enough traffic nice boat price
> *** ENCRYPTION_KEY (hex): 4073adac2351e164b8d68039abd9d4b8e4d07adccfdf73ece6e236d60b107802
> ** TOKEN for Signer 2 (hex): b0344f51d5cb04083d598fa3
> *** TOKEN (decimal): 54532600447720520868878192547
> *** TOKEN (mnemonic): rabbit pen stamp process raccoon advice voice cradle person
> *** ENCRYPTION_KEY (hex): 6bae6b670e257d7468c3e90194029dd468a2f39d8b9a3ff187b08209b1d409b6
> ** TOKEN for Signer 3 (hex): 163fd307195982c4c39d50bb
> *** TOKEN (decimal): 6885829092987042066541138107
> *** TOKEN (mnemonic): bike write scrub crawl oblige give attack present rookie
> *** ENCRYPTION_KEY (hex): c78b94589214b6dc98b337ba4ce54380553ed00a1e5b1955fc540ce3b30d6566
>
> * Signer 1
> ** MASTER_KEY_FINGERPRINT: 110dc257
> ** PRIVATE_KEY (m/48'/0'/0'/1'): KzshDDEBhzyiwXHoyE7ZiLegzztEy54AG6Wq8N844LqHSQMHt4Ji
> ** XPUB (m/48'/0'/0'/1'): xpub6EPQbDFezXYvVFHqnc8R7QUSE8hTepbyCXU7jJBT4dVm2rQHe1i6isqoj59qhyBiCdKquo6QsgMZNHvEz3BM4cNSszF25siTqLUCznBm8vk
> ** Legacy signature
> ** <tt>signer_1_key.bsms</tt>:
> <pre>BSMS 1.0
> 654d63309464afcda558c6aa
> [110dc257/48'/0'/0'/1']xpub6EPQbDFezXYvVFHqnc8R7QUSE8hTepbyCXU7jJBT4dVm2rQHe1i6isqoj59qhyBiCdKquo6QsgMZNHvEz3BM4cNSszF25siTqLUCznBm8vk
> Signer 1 key
> IDX6xLdM4XjetYPvVfpVBXAfT7oE3tHAOB4blZpbIst8bjJ+LbDeP4tZl4O8utAuys9igXE0G3kaHz1mg/+OU8w=</pre>
>
> * Signer 1 encryption
> ** HMAC_KEY (hex): f43c359a4b3d7b2e01be73c54519b12545ca9a23a86f824aadf577b314a7caa7
> ** MAC (hex): 40b6b43e2f1bc01b748eb242235d7e09fa8a2fd6cebe35784cf3adf81910ec98
> ** IV (hex) : 40b6b43e2f1bc01b748eb242235d7e09
> ** CIPHERTEXT (hex): 0877987764401c27e6c60ed2f1bb89dff1dbc5e8204149f682d53049bffe39553f24af3928aa2f78ac2d04ac5baa0c3ec39aaccf0d258e7bb6659a7b92e92f2c2784a94f4df8e8af2270d9d411bfff2cfb9f71b4e1ac87561c7d2ac57ca86a1f9716d5da7571719d24830fc8d015a0daf04b3742439484488798335357f2eeaa8e2db2ba630f9dffd88236e327ab5bfcfb6e29ee3ef6cc18e0b71c1731465c2351e76b92f7b1bd28ef6eff5414c22aa6c80090fa59b973c22e3044e92dbf3688990a49a42828e52c1e686f1193dcdf7b7118930e01419fe938c6811c58c84c36d692fd52846f998bc328471f1e73c22261791a08cda096ee3ac8b37f31afd0b1d9c335ff9ac67ff230eb0d69f2d7
> ** <tt>signer_1_key.dat</tt>: <pre>40b6b43e2f1bc01b748eb242235d7e09fa8a2fd6cebe35784cf3adf81910ec980877987764401c27e6c60ed2f1bb89dff1dbc5e8204149f682d53049bffe39553f24af3928aa2f78ac2d04ac5baa0c3ec39aaccf0d258e7bb6659a7b92e92f2c2784a94f4df8e8af2270d9d411bfff2cfb9f71b4e1ac87561c7d2ac57ca86a1f9716d5da7571719d24830fc8d015a0daf04b3742439484488798335357f2eeaa8e2db2ba630f9dffd88236e327ab5bfcfb6e29ee3ef6cc18e0b71c1731465c2351e76b92f7b1bd28ef6eff5414c22aa6c80090fa59b973c22e3044e92dbf3688990a49a42828e52c1e686f1193dcdf7b7118930e01419fe938c6811c58c84c36d692fd52846f998bc328471f1e73c22261791a08cda096ee3ac8b37f31afd0b1d9c335ff9ac67ff230eb0d69f2d7</pre>
>
> * Signer 2
> ** MASTER_KEY_FINGERPRINT: 5c890401
> ** PRIVATE_KEY (m/48'/0'/0'/1'): L41Jnc9CdBtBJd18429MDGcTgP2DNoXaKyyGr271ndTprvrHXDQf
> ** XPUB (m/48'/0'/0'/1'): xpub6EW1SmjSXq9YwVwcan5qWEncgx89SozMvGNpYF6hfZHYNTikNZ4gsXuVhHTi6xYJCkmY4X4wpPPS5Gr7aY39dVJMS2TGfihr25oaspKtU8q
> ** Legacy signature
> ** <tt>signer_2_key.bsms</tt>:
> <pre>BSMS 1.0
> b0344f51d5cb04083d598fa3
> [5c890401/48'/0'/0'/1']xpub6EW1SmjSXq9YwVwcan5qWEncgx89SozMvGNpYF6hfZHYNTikNZ4gsXuVhHTi6xYJCkmY4X4wpPPS5Gr7aY39dVJMS2TGfihr25oaspKtU8q
> Signer 2 key
> H5kN6UHaK2xACB6iYdTxxQPD8qyFEYv9iMsQs5B0MRfCM7NA5GB+7EFgmBpSctwt6B122zWBr6mRjpYjKmj+7hs=</pre>
>
> * Signer 2 encryption
> ** HMAC_KEY (hex): e0a20b5f5285fbaa35aad08fb70f5626c9abbe1b384a4950735b28aca6325ff2
> ** MAC (hex): 3a6deec8dbdbd6606a52c7d7e64eca4f972a293cbabac6f62736629fbe77928a
> ** IV (hex) : 3a6deec8dbdbd6606a52c7d7e64eca4f
> ** CIPHERTEXT (hex): bb0fb72f61b0c4858bd9c65235390b67651b94c4b0329238b0116dd6d3365ade33cb1c1b1619638968791a5d2d1d263d90280bdad8d9ca24c34a78e320076e0dccf59e7f729b541b44bbe40ba803dedd3b17c49765377cb2d913a856b86c3dd383dab475790e89226ed8ef2301574212d2809ed9c099aa67be434024ee2a4e82a146300acf755863da64807cb7bb2636f6616489636d254a870778d3540832aea44abac4328b5d90f3e6045ef36a526ce5d575f2305e3e4699dccbc713e9e68f50364036c1054c2a506aab77ea7c43a89536947c24330b09a62a90c3b4ae2d452f96ef34ec871af2c52d68ddede2503c87e2ba68d5cf9be589457879e06021ea6a6176f7dded820ba4c0e709e2a2
> ** <tt>signer_2_key.dat</tt>: <pre>3a6deec8dbdbd6606a52c7d7e64eca4f972a293cbabac6f62736629fbe77928abb0fb72f61b0c4858bd9c65235390b67651b94c4b0329238b0116dd6d3365ade33cb1c1b1619638968791a5d2d1d263d90280bdad8d9ca24c34a78e320076e0dccf59e7f729b541b44bbe40ba803dedd3b17c49765377cb2d913a856b86c3dd383dab475790e89226ed8ef2301574212d2809ed9c099aa67be434024ee2a4e82a146300acf755863da64807cb7bb2636f6616489636d254a870778d3540832aea44abac4328b5d90f3e6045ef36a526ce5d575f2305e3e4699dccbc713e9e68f50364036c1054c2a506aab77ea7c43a89536947c24330b09a62a90c3b4ae2d452f96ef34ec871af2c52d68ddede2503c87e2ba68d5cf9be589457879e06021ea6a6176f7dded820ba4c0e709e2a2</pre>
>
> * Signer 3
> ** MASTER_KEY_FINGERPRINT: 614cbf5f
> ** PRIVATE_KEY (m/48'/0'/0'/1'): L2ccRLzH7GfVxWpU8YSY9y5UGyRoqW3UdeNT1vGfVbxAGhwU5qhD
> ** XPUB (m/48'/0'/0'/1'): xpub6F9TfWTFcMYy5Ycd2ka2az1brJj78J2isLAWptZnCpFsesss5sZv5B8xsgt71ZXfhDWhUtf4vng4zY6HUVrQbDMPDYRLYvFFoLnAYfzgYPH
> ** Legacy signature
> ** <tt>signer_3_key.bsms</tt>:
> <pre>BSMS 1.0
> 163fd307195982c4c39d50bb
> [614cbf5f/48'/0'/0'/1']xpub6F9TfWTFcMYy5Ycd2ka2az1brJj78J2isLAWptZnCpFsesss5sZv5B8xsgt71ZXfhDWhUtf4vng4zY6HUVrQbDMPDYRLYvFFoLnAYfzgYPH
> Signer 3 key
> H0jf2JMtke5zDDIWys6fihOCA6QBmC5+hbgVB/c2mMPNPLB6tDXt0TFZU1f9wvaCR9762anKSc8CCqXLogw8V00=</pre>
>
> * Signer 3 encryption
> ** HMAC_KEY (hex): 1f51ea067c121e2f86af5e1d484905046bc63e861573157d8b1ae9e7e47e224b
> ** MAC (hex): 1a5624fcb39cebabb6174456173eec19b756bc916cf2c9d815e9bcce070898c4
> ** IV (hex) : 1a5624fcb39cebabb6174456173eec19
> ** CIPHERTEXT (hex): 48d6e139bdc8c19e93cbbf5b4478340c8cf08aa91c28803084d5f58618773f7e615e0134492b496c4e7c130351c0350701f686918033f621378552d7040efedd5539d38c258bf936475de775f23da3953fe3ba5bbbd24816b8902b87a9a09700c446b085119dedee2395dd69665e742f72f2fb6da4ebe3f4704eaf45486fbfb84d764b718cc0b756e72f72ab6069d47765bdd3ebd4074af4fa99a95691a659675ce5f72235c28ddf3c3d53179e598cddc967fc896adc6e97edeeffc85b9e44611df748d923ff3dd921ad4d6e98e0de12359a37558e326faf585ba57e73ab45bc4a49f6e8a756f365f5d204e70f7c7bed269e81e9524a41e5d4cbaad0b6b442d6eea1e5da1ca345cc665a0cffe2c3
> ** <tt>signer_3_key.dat</tt>: <pre>1a5624fcb39cebabb6174456173eec19b756bc916cf2c9d815e9bcce070898c448d6e139bdc8c19e93cbbf5b4478340c8cf08aa91c28803084d5f58618773f7e615e0134492b496c4e7c130351c0350701f686918033f621378552d7040efedd5539d38c258bf936475de775f23da3953fe3ba5bbbd24816b8902b87a9a09700c446b085119dedee2395dd69665e742f72f2fb6da4ebe3f4704eaf45486fbfb84d764b718cc0b756e72f72ab6069d47765bdd3ebd4074af4fa99a95691a659675ce5f72235c28ddf3c3d53179e598cddc967fc896adc6e97edeeffc85b9e44611df748d923ff3dd921ad4d6e98e0de12359a37558e326faf585ba57e73ab45bc4a49f6e8a756f365f5d204e70f7c7bed269e81e9524a41e5d4cbaad0b6b442d6eea1e5da1ca345cc665a0cffe2c3</pre>
>
> ====ROUND 2====
> * Coordinator
> ** <tt>my_multisig_wallet.bsms</tt>:
> <pre>BSMS 1.0
> /0/*,/1/*
> sh(wsh(multi(2,[110dc257/48'/0'/0'/1']xpub6EPQbDFezXYvVFHqnc8R7QUSE8hTepbyCXU7jJBT4dVm2rQHe1i6isqoj59qhyBiCdKquo6QsgMZNHvEz3BM4cNSszF25siTqLUCznBm8vk/*,[5c890401/48'/0'/0'/1']xpub6EW1SmjSXq9YwVwcan5qWEncgx89SozMvGNpYF6hfZHYNTikNZ4gsXuVhHTi6xYJCkmY4X4wpPPS5Gr7aY39dVJMS2TGfihr25oaspKtU8q/*,[614cbf5f/48'/0'/0'/1']xpub6F9TfWTFcMYy5Ycd2ka2az1brJj78J2isLAWptZnCpFsesss5sZv5B8xsgt71ZXfhDWhUtf4vng4zY6HUVrQbDMPDYRLYvFFoLnAYfzgYPH/*)))#j3ykhz7f</pre>
>
> * Send to Signer 1:
> ** HMAC_KEY (hex): f43c359a4b3d7b2e01be73c54519b12545ca9a23a86f824aadf577b314a7caa7
> ** MAC (hex): ee74a0f50943d7d1b65270028bb05133e87c832cdc1ef0a07c79db2093ca3432
> ** IV (hex) : ee74a0f50943d7d1b65270028bb05133
> ** CIPHERTEXT (hex): 8e3ba3dac0f979fad0d160bd00c8294ff1726d51b95ff3e1534e5a1900f3d7cd4f6d929985a94b9da2c11e4e0f7770cc53c6739fd099477323bd26a3eca9c8016e79848d15e274463424b8355cd73cced61f1816ac8bac87f8c650ee9052f50e347c52ad24b00794a9d5523714be2fdcf731f14b7a8d7c93eab44c258e1c417d2837b9676832e8ce7239dc28b4e1166803209947b8a875a99b9478ee94f7bc17399e886179ab2a0285dc11a3883f6fa439d0f2277dadbec8c355c379fc50e945897e1a738f6a55b09f6b8b6bdf6d4bc248219cbad3662a78a2f539c989e055e00b8efd42fbff978e1a5cc10f83df56117ece4d17f94a0a6d3803778ed53531419250c5a0fff6cad4ab401468dd054915b068cc8826ae1308a71b38060d68c9248d59eea11c2c52a66d5f6bc0d7ae6cb44305c36e56068456d293b70037902e7b05a3ee0af710201128dffc0c16c3306b66bd19b9ae5b91aded35ef33f07743e5b185a9f88a5c67d40270e3bbcf592167ceaf82ead693728d5129b50075edd5ce24863f3484b4b063599ed1327e1c87d0a2051fed3b1234a702722b686e4c9392a403b79726800dd6b691e516e44d9e836c190b10cf2bb262bba98293c97f2c323e59acd0a1f988c5
> ** <tt>my_multisig_wallet_for_signer_1.dat</tt>: <pre>ee74a0f50943d7d1b65270028bb05133e87c832cdc1ef0a07c79db2093ca34328e3ba3dac0f979fad0d160bd00c8294ff1726d51b95ff3e1534e5a1900f3d7cd4f6d929985a94b9da2c11e4e0f7770cc53c6739fd099477323bd26a3eca9c8016e79848d15e274463424b8355cd73cced61f1816ac8bac87f8c650ee9052f50e347c52ad24b00794a9d5523714be2fdcf731f14b7a8d7c93eab44c258e1c417d2837b9676832e8ce7239dc28b4e1166803209947b8a875a99b9478ee94f7bc17399e886179ab2a0285dc11a3883f6fa439d0f2277dadbec8c355c379fc50e945897e1a738f6a55b09f6b8b6bdf6d4bc248219cbad3662a78a2f539c989e055e00b8efd42fbff978e1a5cc10f83df56117ece4d17f94a0a6d3803778ed53531419250c5a0fff6cad4ab401468dd054915b068cc8826ae1308a71b38060d68c9248d59eea11c2c52a66d5f6bc0d7ae6cb44305c36e56068456d293b70037902e7b05a3ee0af710201128dffc0c16c3306b66bd19b9ae5b91aded35ef33f07743e5b185a9f88a5c67d40270e3bbcf592167ceaf82ead693728d5129b50075edd5ce24863f3484b4b063599ed1327e1c87d0a2051fed3b1234a702722b686e4c9392a403b79726800dd6b691e516e44d9e836c190b10cf2bb262bba98293c97f2c323e59acd0a1f988c5</pre>
>
> * Send to Signer 2:
> ** HMAC_KEY (hex): e0a20b5f5285fbaa35aad08fb70f5626c9abbe1b384a4950735b28aca6325ff2
> ** MAC (hex): 81df9e064f1de1d5f754c4e20f9286f9d81b856d3965677a9f2430cb9297ad1f
> ** IV (hex) : 81df9e064f1de1d5f754c4e20f9286f9
> ** CIPHERTEXT (hex): dcd82038ef627d6cb2deb62d04c4ccbaa3a354633d960e46312c22791f039f23fd9782a1e3a63504c1e5b3a0770bb8d32fdf168738b6c03278f1391dd5d01e9aafee7be2c8136ee018feff6fc8cdb926df13a36e115ddca8254934f56b7f700768c94cb8388a8297834de9affcd959417ae3d6ec3251387904f50f51f06306cc4d36eefc51418dd3b2c5454910a23ec67a40a3b918d2a740e812929aae949d8dde2c41cbbb3a2b7c2103788421c147f4794d6a26947c15ef4a99ceb825d0c5aaa78b8737d0ef712ba8e269a9941b1af5d217dcdd9cd06727fbdc70fabe3f5a8c09acff4e76992be7f27c6b12ca84739f62a6da86e5b79103d632c0dc8ab3f91fddb3cfbe67084dc4b861c4ac7c86fb171a058c98c67cffdc40ff17ae1533361cc6fb7b63657af0408cf30bf9d6d97aaacf9d3ff443eee61f207228cd91769ce83a0709c1be1847884c6a8fdc86ede66aef8e34fc509c49edf30f743bdc8f9052961ee340924ec2d1caadc6fd286bb3e233c153cd08c1934127752dc28e0d12efa92a050c4061653edb1cbf2fd4b2ba4e038f0b44f5735f198e92571c029156f65f534bfc149f38d611829901372cfc0176b9d2f9ac6512b7f37941a02dff701df0bceadaacfc6935
> ** <tt>my_multisig_wallet_for_signer_2.dat</tt>: <pre>81df9e064f1de1d5f754c4e20f9286f9d81b856d3965677a9f2430cb9297ad1fdcd82038ef627d6cb2deb62d04c4ccbaa3a354633d960e46312c22791f039f23fd9782a1e3a63504c1e5b3a0770bb8d32fdf168738b6c03278f1391dd5d01e9aafee7be2c8136ee018feff6fc8cdb926df13a36e115ddca8254934f56b7f700768c94cb8388a8297834de9affcd959417ae3d6ec3251387904f50f51f06306cc4d36eefc51418dd3b2c5454910a23ec67a40a3b918d2a740e812929aae949d8dde2c41cbbb3a2b7c2103788421c147f4794d6a26947c15ef4a99ceb825d0c5aaa78b8737d0ef712ba8e269a9941b1af5d217dcdd9cd06727fbdc70fabe3f5a8c09acff4e76992be7f27c6b12ca84739f62a6da86e5b79103d632c0dc8ab3f91fddb3cfbe67084dc4b861c4ac7c86fb171a058c98c67cffdc40ff17ae1533361cc6fb7b63657af0408cf30bf9d6d97aaacf9d3ff443eee61f207228cd91769ce83a0709c1be1847884c6a8fdc86ede66aef8e34fc509c49edf30f743bdc8f9052961ee340924ec2d1caadc6fd286bb3e233c153cd08c1934127752dc28e0d12efa92a050c4061653edb1cbf2fd4b2ba4e038f0b44f5735f198e92571c029156f65f534bfc149f38d611829901372cfc0176b9d2f9ac6512b7f37941a02dff701df0bceadaacfc6935</pre>
>
> * Send to Signer 3:
> ** HMAC_KEY (hex): 1f51ea067c121e2f86af5e1d484905046bc63e861573157d8b1ae9e7e47e224b
> ** MAC (hex): 159a91100cacd123480b7d085c8bb32ec8eb06f0391b6dc8fac07ae67eb37b81
> ** IV (hex) : 159a91100cacd123480b7d085c8bb32e
> ** CIPHERTEXT (hex): c7269d8be21d1cfe172e35aa106760f1fdc929fce19da8fb7f74f759efec1ee02796fb1e8b008cf177f60a2021570f17aeeb41f8636858654082734b90959b98fd08419f901683c4ca3e76b3e482fea4c67162775e0d80bcb45df729f646c1364a3d8a7d1ff961717b00897e877c1c0554d3502942149726806269c546ad2dd34ba286ddf5cd336b83aabf7091fa25e607faf7e54017d84113e1e3ec440b3704addea188b89293469306fc0a98570afdcf269026b2d2e760f466c1f75bcf75fdf030c0a692e5681fd4487e59d6e96451ff5b6b9f2521b8e95e796ef4ab0a917794d91a30fdac7ee9ddbd89d174831bd133ab12a74f52f6283ee2c5fe3d5a957a7c1a15530b2c5224f76d90057dc94f2ee34e28b037ae7f518cc6dfe725cd3e657648de82b200ea77830eb93219f883998d3207a4ef5902d1119b0cde6b364bc1effb86109d9c2babc8ab26dce90329779d8cd0d737e9825a25586aa3c8fa5317e3e433ff235b82f629de0504e3c992f8e8de299f62751bc1fcb2e75e0262c7a27be7068cea69b14f303e97c24b99ed29cae142564e285657704b4c411d0d4f8c58819e2c0e0ffc3667eb5a408aad8a3023a5f00875e7deab95dc365d8757f7b79815a4fd9e6de2b3
> ** <tt>my_multisig_wallet_for_signer_3.dat</tt>: <pre>159a91100cacd123480b7d085c8bb32ec8eb06f0391b6dc8fac07ae67eb37b81c7269d8be21d1cfe172e35aa106760f1fdc929fce19da8fb7f74f759efec1ee02796fb1e8b008cf177f60a2021570f17aeeb41f8636858654082734b90959b98fd08419f901683c4ca3e76b3e482fea4c67162775e0d80bcb45df729f646c1364a3d8a7d1ff961717b00897e877c1c0554d3502942149726806269c546ad2dd34ba286ddf5cd336b83aabf7091fa25e607faf7e54017d84113e1e3ec440b3704addea188b89293469306fc0a98570afdcf269026b2d2e760f466c1f75bcf75fdf030c0a692e5681fd4487e59d6e96451ff5b6b9f2521b8e95e796ef4ab0a917794d91a30fdac7ee9ddbd89d174831bd133ab12a74f52f6283ee2c5fe3d5a957a7c1a15530b2c5224f76d90057dc94f2ee34e28b037ae7f518cc6dfe725cd3e657648de82b200ea77830eb93219f883998d3207a4ef5902d1119b0cde6b364bc1effb86109d9c2babc8ab26dce90329779d8cd0d737e9825a25586aa3c8fa5317e3e433ff235b82f629de0504e3c992f8e8de299f62751bc1fcb2e75e0262c7a27be7068cea69b14f303e97c24b99ed29cae142564e285657704b4c411d0d4f8c58819e2c0e0ffc3667eb5a408aad8a3023a5f00875e7deab95dc365d8757f7b79815a4fd9e6de2b3</pre>
>
> ==Acknowledgement==
>
> Special thanks to Pavol Rusnak, Dmitry Petukhov, Christopher Allen, Craig Raw, Robert Spigler, Gregory Sanders, Ta Tat Tai, Michael Flaxman, Pieter Wuille and others for their feedback on the specification.
>
> ==References==
>
> Original mailing list thread:
> https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2021-February/018385.html
[-- Attachment #2: Type: text/html, Size: 55372 bytes --]
^ permalink raw reply [flat|nested] 37+ messages in thread
* Re: [bitcoin-dev] Proposal: Bitcoin Secure Multisig Setup
2021-04-11 2:34 ` Michael.flaxman
@ 2021-04-11 16:45 ` Hugo Nguyen
2021-04-12 15:03 ` Salvatore Ingala
0 siblings, 1 reply; 37+ messages in thread
From: Hugo Nguyen @ 2021-04-11 16:45 UTC (permalink / raw)
To: Michael.flaxman; +Cc: Bitcoin Protocol Discussion
[-- Attachment #1: Type: text/plain, Size: 11376 bytes --]
Hi Michael,
Comments inline.
On Sat, Apr 10, 2021 at 7:34 PM Michael.flaxman <
michael.flaxman@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
> <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:
>
> 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
> <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.
>
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 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).
>
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).
2) When the signature is "played back" to the Signer, a copy of the
original descriptor must be included. Who stores the descriptor? What if it
gets lost? This is an under-appreciated aspect of the stateful approach:
every participant in the multisig has a full copy of the original contract,
which adds resilience to the wallet backup / recovery process.
3) Because the full descriptor must be "played back" for every single
transaction, this means every detail of the contract must be shared again
and again, indefinitely. Not only does this add overhead (engineering and
cognitive) to the spending process, it has massive privacy implications,
since the descriptor contains everything you need to know about the wallets
and its participants.
Here's an analogy in the physical world. Would you:
a) Enter any type of written contract and
b) Not keep a copy of the contract, forget about it, and
c) Later on rely on your counter-parties or a third-party to provide you
with the original contract and your signature, when the terms get carried
out?
One would be insane to enter such a contract in the real world.
I realize that some vendors are currently not stateful, but I take this as
an unfortunate fact, because multisig wasn't a priority when these hardware
were originally designed. But that is no reason to keep going with a broken
architecture. The industry is green enough that we still can learn and
recover from these sorts of flaws.
Since you mentioned Trezor, I want to thank Pavol in particular here,
because as Trezor CTO Pavol knows best that Trezor is currently stateless,
but he's still on-board with the general idea here, AFAIU.
Bottom line: IMO, signers in a multisig MUST be stateful.
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:
>
> 1. 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.
> 2. 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).
> 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!
> 4. 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 places
> -- and makes a large deposit to receive address X. These funds now belong
> to the attacker and can be swept at any time!
>
> If stateless Signer 1 required a signature to be replayed at step 3,
> stateless Signer 1 would refuse to display malicious receive address X (or
> at a minimum warn the end-user that it did not have enough info to properly
> validate the address).
>
> This is also a concern for self-hosted multisig, I just used the hosted
> services as the best example.
>
> It's also not just Trezor that is stateless. For example, I wrote a
> simple CLI software multisig wallet as part of the buidl library
> <https://twitter.com/mflaxman/status/1321503036724989952> to be used
> mostly for emergency recovery. At 800 lines of code, it's too
> simple/minimal to touch the file system.
>
> *BIP39*
>
> While unrelated, the use of BIP39 words for session tokens seems like a
> big mistake, as end-users have learned over years that BIP39 words are for
> private key material. A small percent of users may backup their token BIP39
> mnemonic and not their seed phrase BIP39 mnemonic! My suggestion is to just
> stick with the other two Token options: decimal and hex.
>
Repost of my previous response. We discussed this at length on the
linked Github PR:
"We decided to keep the TOKEN at 6-9 words, not 12 or anything above
precisely for this reason. Please note that the user has to back up their
Signers first, before proceeding to setting up the multisig wallet. So
there's no writing both things down at once or mixing of the two flows here.
I also find it hard to believe that someone who wants to invest in a safe
multisig solution (and therefore must know at minimum what keys and
multisig represent) will not know the difference between (permanent) 12
words and (one-time use) 6 words. Also note that the TOKEN can be used
without using BIP39 mnemonic at all."
We also made the decimal format, not BIP39 mnemonic, the recommended
encoding in the spec.
Best,
Hugo
[-- Attachment #2: Type: text/html, Size: 17483 bytes --]
^ permalink raw reply [flat|nested] 37+ messages in thread
* Re: [bitcoin-dev] Proposal: Bitcoin Secure Multisig Setup
2021-04-11 16:45 ` Hugo Nguyen
@ 2021-04-12 15:03 ` Salvatore Ingala
2021-04-12 17:55 ` Hugo Nguyen
2021-04-12 18:45 ` Christopher Allen
0 siblings, 2 replies; 37+ messages in thread
From: Salvatore Ingala @ 2021-04-12 15:03 UTC (permalink / raw)
To: Hugo Nguyen, Bitcoin Protocol Discussion
[-- Attachment #1: Type: text/plain, Size: 6907 bytes --]
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.
> 2) When the signature is "played back" to the Signer, a copy of the
> original descriptor must be included. Who stores the descriptor? What if it
> gets lost? This is an under-appreciated aspect of the stateful approach:
> every participant in the multisig has a full copy of the original contract,
> which adds resilience to the wallet backup / recovery process.
>
"Playing back" the signature and wallet's setup data to the hardware wallet
would indeed happen transparently from the Signer's wallet software. If the
Signer lost this data due to malware, faulty hardware, etc., the user would
indeed have to recover from backup, which seems ok to me.
> 3) Because the full descriptor must be "played back" for every single
> transaction, this means every detail of the contract must be shared again
> and again, indefinitely. Not only does this add overhead (engineering and
> cognitive) to the spending process, it has massive privacy implications,
> since the descriptor contains everything you need to know about the wallets
> and its participants.
>
I agree with some of these concerns, but I observe:
- The engineering overhead in handling externally-stored-signed-data is
paid once, and would mostly fall on the hardware wallet vendor. External
software only cares about storing certain data and sending it back later.
- Storing xpubs/descriptors in the desktop software that interacts with
the HWW is already common practice, and necessary for using any watch-only
wallet.
Summarizing, I argue that the stateful/stateless characteristic of a
hardware wallet does not really affect (modulo some extra work) the ability
to participate in the BSMS ceremony, whose *Signers* should indeed be
stateful.
Some more clarifications on the trust assumptions might help at clarifying
the best possible software/hardware implementation tradeoffs, either in
this or a follow-up BIP.
Best,
Salvatore Ingala
[-- Attachment #2: Type: text/html, Size: 8793 bytes --]
^ permalink raw reply [flat|nested] 37+ messages in thread
* Re: [bitcoin-dev] Proposal: Bitcoin Secure Multisig Setup
2021-04-12 15:03 ` Salvatore Ingala
@ 2021-04-12 17:55 ` Hugo Nguyen
2021-04-12 18:45 ` Christopher Allen
1 sibling, 0 replies; 37+ messages in thread
From: Hugo Nguyen @ 2021-04-12 17:55 UTC (permalink / raw)
To: Salvatore Ingala; +Cc: Bitcoin Protocol Discussion
[-- Attachment #1: Type: text/plain, Size: 3902 bytes --]
Hello Salvatore,
On Mon, Apr 12, 2021 at 8:03 AM Salvatore Ingala <salvatore.ingala@gmail•com>
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
>
[-- Attachment #2: Type: text/html, Size: 5255 bytes --]
^ permalink raw reply [flat|nested] 37+ messages in thread
* Re: [bitcoin-dev] Proposal: Bitcoin Secure Multisig Setup
2021-04-12 15:03 ` Salvatore Ingala
2021-04-12 17:55 ` Hugo Nguyen
@ 2021-04-12 18:45 ` Christopher Allen
2021-04-12 20:43 ` Robert Spigler
1 sibling, 1 reply; 37+ messages in thread
From: Christopher Allen @ 2021-04-12 18:45 UTC (permalink / raw)
To: Bitcoin Protocol Discussion
[-- Attachment #1: Type: text/plain, Size: 4478 bytes --]
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
[-- Attachment #2: Type: text/html, Size: 5380 bytes --]
^ permalink raw reply [flat|nested] 37+ messages in thread
* Re: [bitcoin-dev] Proposal: Bitcoin Secure Multisig Setup
2021-04-12 18:45 ` Christopher Allen
@ 2021-04-12 20:43 ` Robert Spigler
0 siblings, 0 replies; 37+ messages in thread
From: Robert Spigler @ 2021-04-12 20:43 UTC (permalink / raw)
To: Christopher Allen, Bitcoin Protocol Discussion
[-- Attachment #1: Type: text/plain, Size: 6107 bytes --]
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 <bitcoin-dev@lists•linuxfoundation.org> 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 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
[-- Attachment #2: Type: text/html, Size: 7694 bytes --]
^ permalink raw reply [flat|nested] 37+ messages in thread
end of thread, other threads:[~2021-04-12 20:43 UTC | newest]
Thread overview: 37+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2021-02-08 23:14 [bitcoin-dev] Proposal: Bitcoin Secure Multisig Setup Hugo Nguyen
2021-02-09 9:33 ` Craig Raw
[not found] ` <CACrqygA1JRA293joYOxxpSepiuFD=uVvQQy3wpuosYyLQHff-A@mail.gmail.com>
2021-02-09 9:38 ` Christopher Allen
2021-02-09 10:05 ` Hugo Nguyen
[not found] ` <CACrqygDhuateDtJMBSWd9sGRu1yzrZBw2yZ75OyKD1Xmzix3Cw@mail.gmail.com>
2021-02-09 10:58 ` Hugo Nguyen
2021-02-11 13:25 ` Pavol Rusnak
2021-02-11 13:45 ` Hugo Nguyen
2021-02-11 16:29 ` Dmitry Petukhov
2021-02-11 19:11 ` Hugo Nguyen
2021-02-11 19:11 ` Hugo Nguyen
2021-02-11 22:29 ` Christopher Allen
2021-02-12 12:31 ` Hugo Nguyen
2021-02-12 13:48 ` Peter D. Gray
2021-02-12 16:55 ` Hugo Nguyen
2021-02-12 17:42 ` Dmitry Petukhov
2021-02-12 17:48 ` Dmitry Petukhov
2021-02-12 17:54 ` Hugo Nguyen
2021-02-14 10:37 ` Dmitry Petukhov
2021-02-14 11:28 ` Dmitry Petukhov
[not found] ` <CAPR5oBNWGLcnw97yPJBCgrj=EwoNdxz_RS9HM6EMpuX2-90JnQ@mail.gmail.com>
2021-02-09 9:45 ` Hugo Nguyen
2021-02-15 8:44 ` Hugo Nguyen
2021-02-15 13:53 ` Craig Raw
2021-02-15 14:19 ` Hugo Nguyen
2021-02-15 16:45 ` Hugo Nguyen
2021-04-05 7:02 ` Hugo Nguyen
2021-04-09 12:07 ` Sjors Provoost
2021-04-09 14:09 ` Hugo Nguyen
2021-04-09 14:54 ` Hugo Nguyen
2021-04-09 15:33 ` Sjors Provoost
2021-04-10 19:32 ` Robert Spigler
2021-04-11 2:34 ` Michael.flaxman
2021-04-11 16:45 ` Hugo Nguyen
2021-04-12 15:03 ` Salvatore Ingala
2021-04-12 17:55 ` Hugo Nguyen
2021-04-12 18:45 ` Christopher Allen
2021-04-12 20:43 ` Robert Spigler
2021-04-10 13:53 ` Erik Aronesty
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox