From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from whitealder.osuosl.org (smtp1.osuosl.org [140.211.166.138]) by lists.linuxfoundation.org (Postfix) with ESMTP id 20D13C013A for ; Tue, 9 Feb 2021 10:11:51 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by whitealder.osuosl.org (Postfix) with ESMTP id 16B8186B2A for ; Tue, 9 Feb 2021 10:11:51 +0000 (UTC) X-Virus-Scanned: amavisd-new at osuosl.org Received: from whitealder.osuosl.org ([127.0.0.1]) by localhost (.osuosl.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IePwFQYOYNNH for ; Tue, 9 Feb 2021 10:11:48 +0000 (UTC) X-Greylist: from auto-whitelisted by SQLgrey-1.7.6 Received: from mail-ua1-f53.google.com (mail-ua1-f53.google.com [209.85.222.53]) by whitealder.osuosl.org (Postfix) with ESMTPS id 820F386B10 for ; Tue, 9 Feb 2021 10:11:48 +0000 (UTC) Received: by mail-ua1-f53.google.com with SMTP id 30so1359382uac.7 for ; Tue, 09 Feb 2021 02:11:48 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nunchuk-io.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=gPRzMRqcEiyniPuG5b3f19mfl0QNolFoXpjHvSCl6b4=; b=EZqaF5nRNSoPzVpX1btvYegrtC/w2o43fwMJ2mcxkjEZQheArdNtjQRzZUc1sbvui9 Zksuh7zIFHRseXR8PpYHMUuufHbSD0QtKujkSrVQfc8QRG+WDa4u/PsaynGW/9Riw0nA Kr/dGdRUI9vRxMgq1IcXWkOyJesX6O4iCVXuIMxKNO8W6fjE+mUwLfmv3F63rRrTPPtq 77ubT/aI3ArMFxnlEU+rilNg2P1MdGak6LZmQ7g+WrDwW2+SE+mevVUUIyQLOGy5O/Sx /aBFT2U0374oCsnJRwz9u697+w31XYsMjDbyBLNHehT00MC0rZiPbep6U6PuPZa9gDGn GneA== 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:cc; bh=gPRzMRqcEiyniPuG5b3f19mfl0QNolFoXpjHvSCl6b4=; b=H1a6YbMh5GrojhDZOIgl+m1QQLVmybNGnvAu1C99mLLrg0TCttgIN0azsOPpHUeLeT vELw9lc593R8dAiztp3eim/Y53x1KZhL2QIXYUMxK1DpuQT9whzj8z9zyHXHMLDsP8lt mf3tkZho15Pbz52cM0hS1/vSJRLHt1c+6IK9aRws1f7V/WDAprB0e3LOIH1anGZcPNZd ZMU9T53d4A0ScyzXzHwjlRq2vqctI+Z4+0AHwJM/t6R3t7HjmvuRoq048PyfW7+uO5xe RRIPWBlHgwg1SuC1U/emVDEIJG2XwKkPcPz+00juGPowUUkDEXac5iVlXeOsHskEGw72 e3og== X-Gm-Message-State: AOAM531sIFGK4GxW8e2OmYWgrdiE7TI0tNhJOJ3q1LogB+RYsXq7Z7fL uLarR3y8bHL4fBzZlFyVHpV1Nnq0ZIW4KQ0xrKYiVs1c0Si9SufAp2+njw== X-Google-Smtp-Source: ABdhPJw3K/KqiaXf1zpwQYtdFbBBv3RvBijchjXm8aFtUM08fb5UBUfHWPIjs8wTNK6yVnH+XfB3jVjq547dyQmSkXQ= X-Received: by 2002:ab0:4d66:: with SMTP id k38mr4158433uag.101.1612863959940; Tue, 09 Feb 2021 01:45:59 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: From: Hugo Nguyen Date: Tue, 9 Feb 2021 01:45:48 -0800 Message-ID: To: Craig Raw Content-Type: multipart/alternative; boundary="00000000000067531105bae42741" X-Mailman-Approved-At: Tue, 09 Feb 2021 11:38:02 +0000 Cc: Bitcoin Protocol Discussion 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: Tue, 09 Feb 2021 10:11:51 -0000 --00000000000067531105bae42741 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi Craig, Comments inline. On Tue, Feb 9, 2021 at 1:17 AM Craig Raw wrote: > Hi Hugo, > > Thanks for raising this again - I'll note there has already been much > discussion on this topic. With respect to your "two layers of protection"= : > > > The Coordinator shares the TOKEN with all participating Signers over a > secure channel. > > What secure channel do you propose? Currently, with the default of a > software wallet coordinator talking to hardware wallets, we have USB, fil= e > (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 ov= er > 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 standardis= ed > 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 whic= h > are relevant: > > 1. For sharing the sharing the BIP44 account information from the signers > to the coordinator, the crypto-account format: [ > https://github.com/BlockchainCommons/Research/blob/master/papers/bcr-2020= -015-account.md > ] > 2. For sharing the output descriptor from the coordinator to the signers, > the crypto-output format: [ > https://github.com/BlockchainCommons/Research/blob/master/papers/bcr-2020= -010-output-desc.md > ] > > Thanks, will update! > Craig > > > > On Tue, Feb 9, 2021 at 9:53 AM Hugo Nguyen via bitcoin-dev < > bitcoin-dev@lists.linuxfoundation.org> wrote: > >> Hi all, >> I would like to propose a new BIP for Secure Multisig Setup. >> This proposal has taken inputs from folks at Coldcard, Shift Crypto and >> Cobo -- listed below as co-authors. >> >> This was inspired by my own experience working with hardware wallets on >> the market, as well as existing research into the challenges of multisig= . >> >> Cheers, >> Hugo >> >> 
>>   BIP: To be determined
>>   Layer: Applications
>>   Title: Bitcoin Secure Multisig Setup (BSMS)
>>   Author: Hugo Nguyen , Peter Gray =
,
>> Marko Bencun , Aaron Chen ,
>> Rodolfo Novak 
>>   Comments-Summary: No comments yet.
>>   Comments-URI:
>>   Status: Proposed
>>   Type: Standards Track
>>   Created: 2020-11-10
>>   License: BSD-2-Clause
>>
>> >> =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 = 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 generat= e >> 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 addre= ss. >> >> This proposal seeks to address concerns #1 and #2: to mitigate the risk >> of tampering during the initial setup phase, and to define an interopera= ble >> 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 BIP32], [ >> https://github.com/bitcoin/bitcoin/blob/master/doc/descriptors.md the >> descriptor language] and encryption. >> >> =3D=3DRoles=3D=3D >> =3D=3D=3DCoordinator=3D=3D=3D >> >> 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 tok= en, >> to be shared among the parties for secure communication. The Coordinator >> gathers information from the Signers to generate a descriptor record. Th= e >> Coordinator distributes the descriptor record back to the Signers. >> >> =3D=3D=3DSigner=3D=3D=3D >> >> The Signer is a participating member in the multisig. Its >> responsibilities include providing its XPUB to the Coordinator, verifyin= g >> that its XPUB is included in the descriptor record and persisting the >> descriptor record in its storage. >> >> =3D=3DSetup Process=3D=3D >> >> =3D=3D=3DRound 1=3D=3D=3D >> >> =3D=3D=3D=3DCoordinator=3D=3D=3D=3D >> >> * The Coordinator creates a multisig wallet creation session. The >> Coordinator determines the type of multisig script used and the signing >> configuration (M and N). >> * If encryption is enabled, the Coordinator also generates a secret >> token, hereby denoted TOKEN. >> * TOKEN is in ASCII format and must have a minimum of 8 characters. TOKE= N >> should expire after some time period determined by the Coordinator, e.g.= , >> 24 hours. >> * TOKEN acts as an encryption key among the parties. The method of >> encryption is AES, CTR mode. The encryption key can be calculated by >> performing a double hash operation on the TOKEN: ENCRYPTION_KEY =3D >> SHA256(SHA256(TOKEN)). >> * A TOKEN value of -1 means that encryption is disabled and all >> the encryption/decryption steps below can be skipped. >> * The Coordinator shares the TOKEN with all participating Signers over a >> secure channel. >> >> =3D=3D=3D=3DSigner=3D=3D=3D=3D >> >> * The Signer generates a key record by prompting the user for the TOKEN >> and a derivation path. >> * The first line in the record must be the TOKEN. If encryption >> is disabled, set the TOKEN to -1. The second line must be the KEY, >> whereas KEY is an XPUB. KEY must include key origin information and writ= ten >> in the descriptor-defined format, i.e.: [{master key >> fingerprint}/{derivation path}]{XPUB}. The third line must be a >> SIG, whereas SIG is the signature generated by using the >> corresponding private key to sign the first two lines. Finally, the Sign= er >> encrypts the entire record with ENCRYPTION_KEY. >> >> =3D=3D=3DRound 2=3D=3D=3D >> >> =3D=3D=3D=3DCoordinator=3D=3D=3D=3D >> >> * 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 CHECKSUM, = all >> in one line. The CHECKSUM has BECH32 encoding and is described at [ >> https://github.com/bitcoin/bitcoin/blob/master/doc/descriptors.md#checks= ums]. >> The Coordinator encrypts this descriptor record with ENCRYPTION_KEY. >> * The Coordinator sends the encrypted descriptor record to all >> participating Signers. >> >> =3D=3D=3D=3DSigner=3D=3D=3D=3D >> >> * The Signer imports the descriptor record, decrypts it by prompting the >> user for TOKEN. >> * The Signer calculates and verifies the descriptor=E2=80=99s 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. T= he >> check must perform an exact match on the KEYs, and not using shortcuts s= uch >> 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 descriptor's >> CHECKSUM, plus other configurations, such as M and N. The total number o= f >> 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 a= nd >> verify receive and change addresses. >> >> This completes the setup. >> >> =3D=3DQR Codes=3D=3D >> 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-202= 0-005-ur.md >> the BCR standard]. >> >> =3D=3DSecurity=3D=3D >> >> 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 throw= n >> 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 addin= g a >> new member. >> >> For the first two methods, one of the Signers will be able to detect tha= t >> 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 >> > --00000000000067531105bae42741 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi Craig,
Comments inline.

On Tue, Feb 9, 2021 at 1= :17 AM Craig Raw <craigraw@gmail.c= om> wrote:
Hi Hugo,

Thanks for raising this agai= n - I'll note there has already been much discussion on this topic. Wit= h 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=C2=A0= talking to hardware wallets, we have USB, file (microSD), and QR as communi= cation channels. It's unclear to me why the token and encryption proces= s is necessary - in fact it's easier to verify what is going on using c= lear text, and the majority of setups will be locally done with the reasona= ble=C2=A0assumption of a secure environment. When the setup is remote, it&#= 39;s simpler to just transmit the key information over the secure channel w= hich presumably already has encryption.=C2=A0


In short, a shared secret (the TOKEN) is need= ed because without it you cannot guarantee that the devices you are connect= ing to are legitimate members of the multisig wallet. Yes, the connection b= etween the coordinator and each device could be secure - but a malicious ac= tor can establish a secure channel just as well as a good one. You are corr= ect that this is less of an issue for local setups, but this is especially = important for distributed multisig=C2=A0- where you cannot physically see w= hat's on the other side.

I would love to remove the shared secre= t/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 se= tting 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 (class= ic...), I also realized there could be another optimization: the secure ses= sion established by the shared secret can remain open indefinitely on the d= evice side - until a different TOKEN is entered. That way the user needs to= enter the TOKEN only once, saving us one interaction.
=C2=A0=
> The second one is through the descriptor checksum an= d visual inspection of the descriptor itself.

This= is a reasonable=C2=A0suggestion, although it's worth noting that suppo= rt for storing multisig setups on hardware wallets varies. Coldcard support= s 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 how= ever store multisig setups, which could make this step confusing. With that= said, the use of an output descriptor is certainly a more standardised app= roach,=C2=A0albeit one without the wallet name included. By the use of the = singular, I assume you mean a descriptor without the /0/* or /1/* suffix (w= hich I think is a good idea).

<= br>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 yo= u don't have to rely on everything being included in the PSBT (which al= so adds mental overhead as the user has to verify each and every transactio= n).

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

=C2=A0
WRT to QR codes, us= ing the BCR UR2.0 standard you linked to is IMO the right approach. I'l= l link directly to the two BCR UR2.0 formats here which are relevant:
=

1. For sharing the sharing the BIP44 account informatio= n from the signers to the coordinator, the crypto-account format: [https://github.com/BlockchainCommons/R= esearch/blob/master/papers/bcr-2020-015-account.md]
2. For sh= aring the output descriptor from the coordinator to the signers, the crypto= -output format: [https://gi= thub.com/BlockchainCommons/Research/blob/master/papers/bcr-2020-010-output-= desc.md]


Thanks, will u= pdate!
=C2=A0
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 p= ropose a new BIP for Secure Multisig Setup.
This proposal has taken inpu= ts from folks at Coldcard, Shift Crypto and Cobo -- listed=C2=A0below as co= -authors.

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

Cheers,
Hugo

<pre>
= =C2=A0 BIP: To be determined
=C2=A0 Layer: Applications
=C2=A0 Title:= Bitcoin Secure Multisig Setup (BSMS)
=C2=A0 Author: Hugo Nguyen <hugo@nunchuk.io>, = Peter Gray <pete= r@coinkite.com>, Marko Bencun <marko@shiftcrypto.ch>, Aaron Chen <aarondongchen@gmail.= com>, Rodolfo Novak <rodolfo@coinkite.com>
=C2=A0 Comments-Summary: No c= omments yet.
=C2=A0 Comments-URI:
=C2=A0 Status: Proposed
=C2=A0 T= ype: Standards Track
=C2=A0 Created: 2020-11-10
=C2=A0 License: BSD-2= -Clause
</pre>

=3D=3DIntroduction=3D=3D

=3D=3D=3DAbs= tract=3D=3D=3D

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

=3D=3D=3DCopyright=3D=3D=3D

This BIP is l= icensed 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.med= iawiki 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 wh= en 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.
# Whet= her Signer persists the multisig configuration in their respective storage,= and under what format.
# Whether Signer's storage is tamper-proof.<= br># Whether Signer subsequently uses the multisig configuration to generat= e and verify receive and change addresses.

An attacker who can modif= y the multisig configuration can steal or hold funds to ransom by duping th= e 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.

=3D=3DSpecification=3D=3D

=3D=3D= =3DPrerequisites=3D=3D=3D
This proposal assumes the parties in the multi= sig support [https://github.com/bitcoin/bips/blob/master/= bip-0032.mediawiki BIP32], [https://github.com/bit= coin/bitcoin/blob/master/doc/descriptors.md the descriptor language] an= d encryption.

=3D=3DRoles=3D=3D
=3D=3D=3DCoordinator=3D=3D=3D
=
The Coordinator initiates the multisig setup. The Coordinator determine= s what type of multisig is used and how many members and signatures are nee= ded. If encryption is enabled, the Coordinator generates a secret token, to= be shared among the parties for secure communication. The Coordinator gath= ers information from the Signers to generate a descriptor record. The Coord= inator distributes the descriptor record back to the Signers.

=3D=3D= =3DSigner=3D=3D=3D

The Signer is a participating member in the multi= sig. Its responsibilities include providing its XPUB to the Coordinator, ve= rifying that its XPUB is included in the descriptor record and persisting t= he descriptor record in its storage.

=3D=3DSetup Process=3D=3D
=3D=3D=3DRound 1=3D=3D=3D

=3D=3D=3D=3DCoordinator=3D=3D=3D=3D
<= br>* The Coordinator creates a multisig wallet creation session. The Coordi= nator determines the type of multisig script used and the signing configura= tion (<tt>M</tt> and <tt>N</tt>).
* If encryptio= n 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 determ= ined by the Coordinator, e.g., 24 hours.
* TOKEN acts as an encryption k= ey among the parties. The method of encryption is AES, CTR mode. The encryp= tion key can be calculated by performing a double hash operation on the TOK= EN: <tt>ENCRYPTION_KEY =3D SHA256(SHA256(TOKEN))</tt>.
* A T= OKEN value of <tt>-1</tt> means that encryption is disabled and= all the encryption/decryption steps below can be skipped.
* The Coordin= ator shares the TOKEN with all participating Signers over a secure channel.=

=3D=3D=3D=3DSigner=3D=3D=3D=3D

* 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 encrypt= ion 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 inform= ation and written in the descriptor-defined format, i.e.: <tt>[{maste= r key fingerprint}/{derivation path}]{XPUB}</tt>. The third line must= be a <tt>SIG</tt>, whereas SIG is the signature generated by u= sing the corresponding private key to sign the first two lines. Finally, th= e Signer encrypts the entire record with ENCRYPTION_KEY.

=3D=3D=3DRo= und 2=3D=3D=3D

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

* The Coor= dinator gathers key records from all participating Signers. Abort the setup= if TOKEN has expired.
* For each key record, the Coordinator decrypts i= t using ENCRYPTION_KEY. The Coordinator verifies that the included SIG is v= alid given the KEY.
* If all key records look good, the Coordinator gene= rates a descriptor record, which is simply the descriptor string plus a <= ;tt>CHECKSUM</tt>, all in one line. The CHECKSUM has BECH32 encodi= ng and is described at [https://github.com/b= itcoin/bitcoin/blob/master/doc/descriptors.md#checksums]. The Coordinat= or encrypts this descriptor record with ENCRYPTION_KEY.
* The Coordinato= r sends the encrypted descriptor record to all participating Signers.
=3D=3D=3D=3DSigner=3D=3D=3D=3D

* The Signer imports the descriptor= record, decrypts it by prompting the user for TOKEN.
* The Signer calcu= lates and verifies the descriptor=E2=80=99s CHECKSUM. Abort the setup if th= e CHECKSUM is incorrect.
* The Signer checks whether one of the KEYs in= the descriptor belongs to it, using path and fingerprint information inclu= ded 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 s= poof). Abort the setup if it doesn=E2=80=99t detect its own KEY.
* For c= onfirmation, the Signer must display to the user the descriptor's CHECK= SUM, plus other configurations, such as M and N. The total number of Signer= s, N, is important to prevent a KEY insertion attack. All participating Sig= ners should be able to display the same confirmation.
* If all checks p= ass, the Signer persists the descriptor record in its storage. The Signer s= hould subsequently use the descriptor to generate and verify receive and ch= ange addresses.

This completes the setup.

=3D=3DQR Codes=3D= =3D
For signers that use QR codes to transmit data, key and descriptor r= ecords can be converted to QR codes, following [https://github.com/BlockchainCommons/Research/blob/master/paper= s/bcr-2020-005-ur.md the BCR standard].

=3D=3DSecurity=3D=3D
=
This proposal introduce two layers of protection. The first one is a te= mporary, secret token, used to encrypt the two rounds of communication betw= een the Signers and the Coordinator. The second one is through the descript= or checksum and visual inspection of the descriptor itself.

The toke= n is only needed during the setup phase, and can be safely thrown away afte= rwards. 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 cha= nging an existing member, by removing an existing member, or by adding a ne= w 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 th= at 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 inspectio= n of the descriptor itself are the only way to guard against malicious memb= ers from being inserted into the set.
_______________________________________________
bitcoin-dev mailing list
= bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mail= man/listinfo/bitcoin-dev
--00000000000067531105bae42741--