Return-Path: Received: from hemlock.osuosl.org (smtp2.osuosl.org [140.211.166.133]) by lists.linuxfoundation.org (Postfix) with ESMTP id DE846C013A for ; Mon, 15 Feb 2021 13:53:19 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by hemlock.osuosl.org (Postfix) with ESMTP id CCF9E87095 for ; Mon, 15 Feb 2021 13:53:19 +0000 (UTC) X-Virus-Scanned: amavisd-new at osuosl.org Received: from hemlock.osuosl.org ([127.0.0.1]) by localhost (.osuosl.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZqMB6g3I-e56 for ; Mon, 15 Feb 2021 13:53:17 +0000 (UTC) X-Greylist: domain auto-whitelisted by SQLgrey-1.7.6 Received: from mail-io1-f50.google.com (mail-io1-f50.google.com [209.85.166.50]) by hemlock.osuosl.org (Postfix) with ESMTPS id 7048887058 for ; Mon, 15 Feb 2021 13:53:17 +0000 (UTC) Received: by mail-io1-f50.google.com with SMTP id a22so4944133iot.1 for ; Mon, 15 Feb 2021 05:53:17 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to; bh=SzbzaaEMyxPdPMtOI0RsQIyvrUJxet84JXiS1RfYcko=; b=aspMJwgIakFd+n+4ELrIl2HDiPZTLnUZjOT5K9k0NJl+p7ne3ucDc2aRED4peSGhpl JqvWRQighOdJbGpWKUBinbU/7ydZR3BLfReD03Zr+BzJuRIfDT7l7otKsVwvjo21OEI1 NPjRWy8/r7gzbdkHB9OUa8ttloRxbbef1Pa4cc41yG4bomFT112bOpRNtA03uCgppUzs weShKDiAkkYzDNgzx2ekYO7IBgScvABfPb45dFwEOgWFbm+KEkSnB7jHBqPZy7eZafU8 rIo5J6gEGrpDVGog+fmmsLGH2vIy4afPFAJNVf71pNGVRBnXzqTFy/LGY17o6h4LpckM Dn4A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to; bh=SzbzaaEMyxPdPMtOI0RsQIyvrUJxet84JXiS1RfYcko=; b=XJhCFj7Z3AQjCQYjvJNRcHEajkZyxsIZPiqF8X1S1kNumDQbOq6r/xcCbnsc0JILMe tDEfY9GlHw9+/pQyrZXEAS2ZWxjTLr4ggXKOR+OTXYcWrJsgaK+9ysbdFm6HKS3drra2 G1wcJQQaAjc443fQ7tRfHlEj/IQN8Uo4V74+CfHd5wpQ3tXA6KuQ7Re7TXKw8X8lo4vy Hh0+ik7S5eUIWFPaAB/E+wvwfL8dNfKMGa7yb47klD3CpdzqpgzS18isPxnaK2q/vYdC QXAavj7ccRUSvCcjRKehxFAor/yiUzi50395GtsYGntXlBmmjIaD/505OKrnhLTG1/bf JpJQ== X-Gm-Message-State: AOAM530/KOCStMTbJ7sCFrAJEYBG4yoLVX7NWfISUF4fZc6Yy+UZWbl6 YzyCvsP9nOhnAbLyFNlE4w5TT9v8xrRpN0fi09Y= X-Google-Smtp-Source: ABdhPJxRQ0PxUQz55KgbpQtb7fbCMNanDAVf1qFqjmyOweXWdYKig51R2wqwojjvYZdazN6dWd+g9TayFBOunKpqoiY= X-Received: by 2002:a05:6602:106:: with SMTP id s6mr12665769iot.17.1613397196679; Mon, 15 Feb 2021 05:53:16 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: From: Craig Raw Date: Mon, 15 Feb 2021 15:53:05 +0200 Message-ID: To: Hugo Nguyen , Bitcoin Protocol Discussion Content-Type: multipart/alternative; boundary="000000000000ca302805bb604e0a" X-Mailman-Approved-At: Mon, 15 Feb 2021 15:39:15 +0000 Subject: Re: [bitcoin-dev] Proposal: Bitcoin Secure Multisig Setup X-BeenThere: bitcoin-dev@lists.linuxfoundation.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Bitcoin Protocol Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Feb 2021 13:53:20 -0000 --000000000000ca302805bb604e0a Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable 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 th= e > 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? > > > =3D=3D=3D Quick summary of changes from last update =3D=3D=3D > > 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. > > =3D=3D=3D End of summary =3D=3D=3D > > > Cheers, > Hugo > > > 
>   BIP: To be determined
>   Layer: Applications
>   Title: Bitcoin Secure Multisig Setup (BSMS)
>   Author: Hugo Nguyen , Peter Gray  coinkite.com>, Marko Bencun , Pavol Rusnak <
> stick@satoshilabs.com>, Aaron Chen , Rodolfo
> Novak 
>   Comments-Summary: No comments yet.
>   Comments-URI:
>   Status: Proposed
>   Type: Standards Track
>   Created: 2020-11-10
>   License: BSD-2-Clause
>
> > =3D=3DIntroduction=3D=3D > > =3D=3D=3DAbstract=3D=3D=3D > > This document proposes a mechanism to set up multisig wallets securely. > > =3D=3D=3DCopyright=3D=3D=3D > > This BIP is licensed under the 2-clause BSD license. > > =3D=3D=3DMotivation=3D=3D=3D > > 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 i= s > 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 addres= s. > > This proposal seeks to address concerns #1 and #2: to mitigate the risk o= f > 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. > > =3D=3DSpecification=3D=3D > > =3D=3D=3DPrerequisites=3D=3D=3D > 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. > > =3D=3D=3DRoles=3D=3D=3D > =3D=3D=3D=3DCoordinator=3D=3D=3D=3D > > 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 secre= ts > 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. > > =3D=3D=3D=3DSigner=3D=3D=3D=3D > > The Signer is a participating member in the multisig. Its responsibilitie= s > 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. > > =3D=3D=3DSetup Process=3D=3D=3D > > =3D=3D=3D=3DRound 1=3D=3D=3D=3D > > =3D=3D=3D=3D=3DCoordinator=3D=3D=3D=3D=3D > > * The Coordinator creates a multisig wallet creation session. The > Coordinator constructs the multisig script and its policy parameters, suc= h > as the total number of signers and the required number of signatures > (M and N). > * The session should expire after some time period determined by the > Coordinator, e.g., 24 hours. > * If encryption is enabled, the Coordinator distributes a secret > TOKEN to each Signer over a secure channel. The Signer can use t= he > TOKEN to derive an ENCRYPTION_KEY. Refer to the > Encryption section below for details on the TOKEN, the key > derivation function and the encryption scheme. Depending on the use case, > the Coordinator can decide whether to share one common TOKEN for > all Signers, or to have one per Signer. > * If encryption is disabled, TOKEN is set to 0, and all > the encryption/decryption steps below can be skipped. > > =3D=3D=3D=3D=3DSigner=3D=3D=3D=3D=3D > > * The Signer initiates a new secure multisig setup session by setting the > TOKEN. The Signer derives an ENCRYPTION_KEY from the > TOKEN. The Signer can keep the session open until a different > value for the TOKEN is set. > * The Signer generates a key record by prompting the user for a multisig > derivation path and retrieves the XPUB at that derivation path. Optionall= y, > 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 TOKEN. The second lin= e > must be the KEY. The KEY is an XPUB plus its key origin > information, written in the descriptor-defined format, i.e.: [{master > key fingerprint}/{derivation path}]{XPUB}. The third line must be a > SIG, whereas SIG is the signature generated by using th= e > 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 wi= th > ENCRYPTION_KEY. > > =3D=3D=3D=3DRound 2=3D=3D=3D=3D > > =3D=3D=3D=3D=3DCoordinator=3D=3D=3D=3D=3D > > * 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 > ENCRYPTION_KEY. The Coordinator verifies that the included > SIG is valid given the KEY. > * If all key records look good, the Coordinator fills in all necessary > information to generate a descriptor record, which is simply the descript= or > string plus a CHECKSUM, all in one line. The CHECKSUM h= as > [ > https://github.com/bitcoin/bitcoin/blob/master/doc/descriptors.md#checksu= ms > BECH32 encoding]. > * The Coordinator encrypts this descriptor record with > ENCRYPTION_KEY. > * The Coordinator sends the encrypted descriptor record to all > participating Signers. > > =3D=3D=3D=3D=3DSigner=3D=3D=3D=3D=3D > > * The Signer imports the descriptor record, decrypts it using the > ENCRYPTION_KEY derived from the open session. > * The Signer calculates and verifies the descriptor=E2=80=99s CHECKSU= M. > 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, a= nd > not using shortcuts such as matching fingerprints (which is trivial to > spoof). Abort the setup if it doesn=E2=80=99t detect its own KEY= . > * For confirmation, the Signer must display to the user the > 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 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 verif= y > receive and change addresses. > > This completes the setup. > > =3D=3D=3DEncryption=3D=3D=3D > > =3D=3D=3D=3DThe Token=3D=3D=3D=3D > We define three modes of encryption. > > # NO_ENCRYPTION : the TOKEN is set to 0. > Encryption is disabled. > # STANDARD : the TOKEN is a 64-bit nonce. > # EXTENDED : the TOKEN is a 128-bit nonce. > > The TOKEN 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 STANDARD mode, 12 words in EXTENDED > mode) > * A decimal number (20 digits in STANDARD mode, 40 digits in > EXTENDED 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. > > =3D=3D=3D=3DKey Derivation=3D=3D=3D=3D > The key derivation function is [https://tools.ietf.org/html/rfc2898 > PBKDF2], with PRF =3D SHA512. Specifically: > > DK =3D PBKDF2(PRF, Password, Salt, c, dkLen) > > Whereas: > > * PRF =3D SHA512 > * Password =3D "No SPOF" > * Salt =3D TOKEN > * c =3D 2048 > * dkLen =3D 256 > * DK =3D Derived ENCRYPTION_KEY > > =3D=3D=3D=3DEncryption Scheme=3D=3D=3D=3D > The encryption scheme is [https://tools.ietf.org/html/rfc3686 AES, CTR > mode]. > > =3D=3DQR Codes=3D=3D > For signers that use QR codes to transmit data, key and descriptor record= s > 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. > > =3D=3DSecurity=3D=3D > > 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. > > =3D=3DAcknowledgement=3D=3D > > Special thanks to Dmitry Petukhov, Christopher Allen, Craig Raw and other= s > for their feedback on the specification. > > =3D=3DReferences=3D=3D > > Original mailing list thread: > https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2021-February/018= 385.html > > > _______________________________________________ > bitcoin-dev mailing list > bitcoin-dev@lists.linuxfoundation.org > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev > --000000000000ca302805bb604e0a Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
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 s= ecurely, and if you have established an (off-protocol) secure channel to do= this, why not just share the actual multisig configuration data directly i= n 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) co= mplexity 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 ca= n 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 a= ccount number) and increasing the standardisation on common derivation path= s. On receiving these derivation/xpub pairs, the Coordinator can simply pic= k the appropriate one.

These concerns noted, I agr= ee 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 e= xport formats (not just for multisig). On that note, I'd love to see gr= eater adoption of the efficient UR2.0 standard and associated formats for a= irgapped data transmission using QR codes.

Craig


On Mon, Feb 15, 2021 at 11:13 AM Hugo Nguyen via bitcoin= -dev <bitcoin-d= ev@lists.linuxfoundation.org> wrote:
Hi all,
I have updated= the proposal based on further feedback. The new spec is included at the bo= ttom.

I have also created a public Github PR to ma= ke it easier to comment on the text of the spec itself:=C2=A0https://github.co= m/nunchuk-io/bips/pull/1 .

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


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

1. Define= encryption modes

# NO_ENCRYPTION: Encryption is disabled.
# STAN= DARD : 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 opt= ion where the Coordinator can choose to use one common TOKEN for all Signer= s, or use one per Signer.

=3D=3D=3D End of summary =3D=3D=3D


Cheers,
Hugo
=

<pre>
=C2=A0 BIP: To be determined
=C2=A0 Layer: Applic= ations
=C2=A0 Title: Bitcoin Secure Multisig Setup (BSMS)
=C2=A0 Auth= or: 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>=C2=A0 Comments-Summary: No comments yet.
=C2=A0 Comments-URI:
=C2= =A0 Status: Proposed
=C2=A0 Type: Standards Track
=C2=A0 Created: 202= 0-11-10
=C2=A0 License: BSD-2-Clause
</pre>

=3D=3DIntrod= uction=3D=3D

=3D=3D=3DAbstract=3D=3D=3D

This document propose= s a mechanism to set up multisig wallets securely.

=3D=3D=3DCopyrigh= t=3D=3D=3D

This BIP is licensed under the 2-clause BSD license.
<= br>=3D=3D=3DMotivation=3D=3D=3D

The Bitcoin multisig experience has = been greatly streamlined under [https://github.com/bitcoi= n/bips/blob/master/bip-0174.mediawiki BIP-0174
(Partially Signed Bit= coin Transaction)]. However, what is still missing is a standardized proces= s for setting up multisig wallets securely across different vendors.
There are a number of concerns when it comes to setting up a multisig wall= et:

# Whether the multisig configuration, such as Signer membership,= script type, derivation paths and number of signatures required, is correc= t and not tampered with.
# Whether Signer persists the multisig configur= ation in their respective storage, and under what format.
# Whether Sign= er'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 ad= dress.

This proposal seeks to address concerns #1 and #2: to mitigat= e the risk of tampering during the initial setup phase, and to define an in= teroperable multisig configuration format.

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

=3D=3DS= pecification=3D=3D

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

=3D=3D=3DRoles=3D= =3D=3D
=3D=3D=3D=3DCoordinator=3D=3D=3D=3D

The Coordinator initia= tes the multisig setup. The Coordinator determines what type of multisig is= used and the exact policy script. If encryption is enabled, the Coordinato= r also distributes a shared secret or shared secrets to the parties involve= d for secure communication. The Coordinator gathers information from the Si= gners to generate a descriptor record. The Coordinator distributes the desc= riptor record back to the Signers.

=3D=3D=3D=3DSigner=3D=3D=3D=3D
The Signer is a participating member in the multisig. Its responsibili= ties include providing its key record -- which contains an Extended Public = Key (XPUB) -- to the Coordinator, verifying that its XPUB is included in th= e descriptor record and persisting the descriptor record in its storage.
=3D=3D=3DSetup Process=3D=3D=3D

=3D=3D=3D=3DRound 1=3D=3D=3D=3D=

=3D=3D=3D=3D=3DCoordinator=3D=3D=3D=3D=3D

* The Coordinator = creates a multisig wallet creation session. The Coordinator constructs the = multisig script and its policy parameters, such as the total number of sign= ers and the required number of signatures (<tt>M</tt> and <t= t>N</tt>).
* The session should expire after some time period d= etermined by the Coordinator, e.g., 24 hours.
* If encryption is enabled= , the Coordinator distributes a secret <tt>TOKEN</tt> to each S= igner over a secure channel. The Signer can use the <tt>TOKEN</tt&= gt; to derive an <tt>ENCRYPTION_KEY</tt>. Refer to the Encrypti= on section below for details on the <tt>TOKEN</tt>, the key der= ivation function and the encryption scheme. Depending on the use case, the = Coordinator can decide whether to share one common <tt>TOKEN</tt&g= t; for all Signers, or to have one per Signer.
* If encryption is disabl= ed, <tt>TOKEN</tt> is set to <tt>0</tt>, and all th= e encryption/decryption steps below can be skipped.

=3D=3D=3D=3D=3DS= igner=3D=3D=3D=3D=3D

* The Signer initiates a new secure multisig se= tup session by setting the <tt>TOKEN</tt>. The Signer derives a= n <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 prom= pting the user for a multisig derivation path and retrieves the XPUB at tha= t derivation path. Optionally, the Signer can choose a path on behalf of th= e user. If the Signer chooses the path, it should try to avoid reusing XPUB= s 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 fin= gerprint}/{derivation path}]{XPUB}</tt>. The third line must be a <= ;tt>SIG</tt>, whereas <tt>SIG</tt> is the signature ge= nerated by using the private key associated with the XPUB to sign the first= two lines.=C2=A0 The signature should follow [https://gi= thub.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>.

=3D=3D=3D=3DRound 2=3D=3D=3D=3D
=3D=3D=3D=3D=3DCoordinator=3D=3D=3D=3D=3D

* The Coordinator gather= s key records from all participating Signers. Abort the setup if the wallet= setup session has expired.
* For each key record, the Coordinator decry= pts 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 al= l necessary information to generate a descriptor record, which is simply th= e 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 encryp= ted descriptor record to all participating Signers.

=3D=3D=3D=3D=3DS= igner=3D=3D=3D=3D=3D

* The Signer imports the descriptor record, dec= rypts it using the <tt>ENCRYPTION_KEY</tt> derived from the ope= n session.
* The Signer calculates and verifies the descriptor=E2=80=99s= <tt>CHECKSUM</tt>. Abort the setup if the <tt>CHECKSUM&l= t;/tt> is incorrect.
* The Signer checks whether one of the <tt>= ;KEY</tt>s in the descriptor belongs to it, using path and fingerprin= t information included in the descriptor. The check must perform an exact m= atch on the <tt>KEY</tt>s, and not using shortcuts such as matc= hing fingerprints (which is trivial to spoof). Abort the setup if it doesn= =E2=80=99t 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</t= t>. The total number of Signers, <tt>N</tt>, is important to= prevent a <tt>KEY</tt> insertion attack. All participating Sig= ners should be able to display the same confirmation.
* If all checks pa= ss, the Signer persists the descriptor record in its storage.
* The Sign= er can choose to further restrict post-XPUB derivation paths, such as to th= ose defined in [https://github.com/bitcoin/bips/blob/mast= er/bip-0044.mediawiki BIP-0044].
* The Signer should subsequently us= e the descriptor to generate and verify receive and change addresses.
This completes the setup.

=3D=3D=3DEncryption=3D=3D=3D

=3D= =3D=3D=3DThe Token=3D=3D=3D=3D
We define three modes of encryption.
<= br># <tt>NO_ENCRYPTION</tt> : the <tt>TOKEN</tt> is= set to <tt>0</tt>. Encryption is disabled.
# <tt>STAN= DARD</tt> : the <tt>TOKEN</tt> is a 64-bit nonce.
# &l= t;tt>EXTENDED</tt> : the <tt>TOKEN</tt> is a 128-bit n= once.

The <tt>TOKEN</tt> can be converted to one of thes= e formats:
* A mnemonic phrase using [https://github.c= om/bitcoin/bips/blob/master/bip-0039.mediawiki BIP-0039] word list (6 w= ords in <tt>STANDARD</tt> mode, 12 words in <tt>EXTENDED&= lt;/tt> mode)
* A decimal number (20 digits in <tt>STANDARD<= /tt> mode, 40 digits in <tt>EXTENDED</tt> mode)
* A QR co= de
* Other formats

The flexibility in the data format allows each= Signer to customize the User Experience based on its respective capabiliti= es.

=3D=3D=3D=3DKey Derivation=3D=3D=3D=3D
The key derivation fun= ction is [https://tools.ietf.org/html/rfc2898 PBKDF2], with PRF =3D SHA512. Spec= ifically:

<tt>DK =3D PBKDF2(PRF, Password, Salt, c, dkLen)<= /tt>

Whereas:

* PRF =3D <tt>SHA512</tt>
* P= assword =3D <tt>"No SPOF"</tt>
* Salt =3D <tt&g= t;TOKEN</tt>
* c =3D <tt>2048</tt>
* dkLen =3D <= tt>256</tt>
* DK =3D Derived <tt>ENCRYPTION_KEY</tt>= ;

=3D=3D=3D=3DEncryption Scheme=3D=3D=3D=3D
The encryption scheme= is [http= s://tools.ietf.org/html/rfc3686 AES, CTR mode].

=3D=3DQR Codes= =3D=3D
For signers that use QR codes to transmit data, key and descripto= r records can be converted to QR codes, following [https://github.com/BlockchainCommons/Research/blob/master/pa= pers/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 [ht= tps://github.com/BlockchainCommons/Research/blob/master/papers/bcr-2020-010= -output-desc.md UR Type Definition for Bitcoin Output Descriptors] for = more details.

=3D=3DSecurity=3D=3D

This proposal introduces t= wo layers of protection. The first one is a temporary, secret token, used t= o encrypt the two rounds of communication between the Signer and the Coordi= nator. The second one is through the descriptor checksum and visual inspect= ion of the descriptor itself.

The token is only needed during the se= tup phase, and can be safely thrown away afterwards. The token does not gua= rantee that the Signer membership set is not modified, since that depends o= n the overall security of all parties in the setup, but it can make it sign= ificantly harder for an attacker to do so.

There are three ways an a= ttacker can modify the membership set: by changing an existing member, by r= emoving 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 mean= s 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 t= he set.

=3D=3DAcknowledgement=3D=3D

Special thanks to Dmitry = Petukhov, Christopher Allen, Craig Raw and others for their feedback on the= specification.

=3D=3DReferences=3D=3D

Original mailing list = thread: https://lists.linuxfoundation.= org/pipermail/bitcoin-dev/2021-February/018385.html

=C2=A0
=
_______________________________________________
bitcoin-dev mailing list
= bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mail= man/listinfo/bitcoin-dev
--000000000000ca302805bb604e0a--