MIME-Version: 1.0
References: <CAPKmR9uyY70MhmVCh=C9DeyF2Tyxibux1E_bLPo00aW_h+OjLw@mail.gmail.com>
In-Reply-To: <CAPKmR9uyY70MhmVCh=C9DeyF2Tyxibux1E_bLPo00aW_h+OjLw@mail.gmail.com>
From: Erik Aronesty <erik@q32.com>
Date: Sat, 10 Apr 2021 09:53:20 -0400
Message-ID: <CAJowKg+4KsVej3M+9mMD8Y8sYvAGAVYLOA6+4v0AXc6B78bW9g@mail.gmail.com>
To: Hugo Nguyen <hugo@nunchuk.io>, 
 Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Subject: Re: [bitcoin-dev] Proposal: Bitcoin Secure Multisig Setup
Precedence: list

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 C=
obo -- listed below as co-authors.
>
> This was inspired by my own experience working with hardware wallets on t=
he 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>
>
> =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 (Partial=
ly Signed Bitcoin Transaction)]. However, what is still missing is a standa=
rdized process for setting up multisig wallets securely across different ve=
ndors.
>
> There are a number of concerns when it comes to setting up a multisig wal=
let:
>
> # Whether the multisig configuration, such as Signer membership, script t=
ype, 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 f=
unds 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 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 th=
is 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.co=
m/bitcoin/bitcoin/blob/master/doc/descriptors.md the descriptor language] a=
nd 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 neede=
d. If encryption is enabled, the Coordinator generates a secret token, to b=
e shared among the parties for secure communication. The Coordinator gather=
s information from the Signers to generate a descriptor record. The Coordin=
ator distributes the descriptor record back to the Signers.
>
> =3D=3D=3DSigner=3D=3D=3D
>
> The Signer is a participating member in the multisig. Its responsibilitie=
s 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.
>
> =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 Coordin=
ator determines the type of multisig script used and the signing configurat=
ion (<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 encryp=
tion is AES, CTR mode. The encryption key can be calculated by performing a=
 double hash operation on the TOKEN: <tt>ENCRYPTION_KEY =3D SHA256(SHA256(T=
OKEN))</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.
>
> =3D=3D=3D=3DSigner=3D=3D=3D=3D
>
> * The Signer generates a key record by prompting the user for the TOKEN a=
nd 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 writte=
n in the descriptor-defined format, i.e.: <tt>[{master key fingerprint}/{de=
rivation 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 si=
gn the first two lines. Finally, the Signer 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. Abo=
rt 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 re=
cord, which is simply the descriptor string plus a <tt>CHECKSUM</tt>, all i=
n one line. The CHECKSUM has BECH32 encoding and is described at [https://g=
ithub.com/bitcoin/bitcoin/blob/master/doc/descriptors.md#checksums]. The Co=
ordinator encrypts this descriptor record with ENCRYPTION_KEY.
> * The Coordinator sends the encrypted descriptor record to all participat=
ing 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. A=
bort 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 i=
t 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 of S=
igners, N, is important to prevent a KEY insertion attack. All participatin=
g Signers should be able to display the same confirmation.
> * If all checks pass, the Signer persists the descriptor record in its st=
orage. The Signer should subsequently use the descriptor to generate and ve=
rify 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 record=
s can be converted to QR codes, following [https://github.com/BlockchainCom=
mons/Research/blob/master/papers/bcr-2020-005-ur.md the BCR standard].
>
> =3D=3DSecurity=3D=3D
>
> This proposal introduce two layers of protection. The first one is a temp=
orary, secret token, used to encrypt the two rounds of communication betwee=
n 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 s=
et is not modified, since that depends on the overall security of all parti=
es 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 changi=
ng an existing member, by removing an existing member, or by adding a new m=
ember.
>
> 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 descripto=
r. Thus, it is vital that all participating Signers check that their member=
ship 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 inspecti=
on of the descriptor itself are the only way to guard against malicious mem=
bers from being inserted into the set.
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev