path: root/43/40cb4af239fb1ad1e537fb4a6d364c024d4628

Return-Path: <earonesty@gmail.com>
Received: from smtp4.osuosl.org (smtp4.osuosl.org [IPv6:2605:bc80:3010::137])
 by lists.linuxfoundation.org (Postfix) with ESMTP id 6918DC000A
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Sat, 10 Apr 2021 13:53:33 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
 by smtp4.osuosl.org (Postfix) with ESMTP id 4A5E2403CF
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Sat, 10 Apr 2021 13:53:33 +0000 (UTC)
X-Virus-Scanned: amavisd-new at osuosl.org
X-Spam-Flag: NO
X-Spam-Score: -1.65
X-Spam-Level: 
X-Spam-Status: No, score=-1.65 tagged_above=-999 required=5
 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1,
 FREEMAIL_FORGED_FROMDOMAIN=0.001, FREEMAIL_FROM=0.001,
 HEADER_FROM_DIFFERENT_DOMAINS=0.249, RCVD_IN_DNSWL_NONE=-0.0001,
 SPF_PASS=-0.001] autolearn=no autolearn_force=no
Authentication-Results: smtp4.osuosl.org (amavisd-new);
 dkim=pass (2048-bit key) header.d=q32-com.20150623.gappssmtp.com
Received: from smtp4.osuosl.org ([127.0.0.1])
 by localhost (smtp4.osuosl.org [127.0.0.1]) (amavisd-new, port 10024)
 with ESMTP id zKUy6M7ia5rh
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Sat, 10 Apr 2021 13:53:31 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.8.0
Received: from mail-pj1-x1034.google.com (mail-pj1-x1034.google.com
 [IPv6:2607:f8b0:4864:20::1034])
 by smtp4.osuosl.org (Postfix) with ESMTPS id 9D76E40352
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Sat, 10 Apr 2021 13:53:31 +0000 (UTC)
Received: by mail-pj1-x1034.google.com with SMTP id
 lr1-20020a17090b4b81b02900ea0a3f38c1so7662259pjb.0
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Sat, 10 Apr 2021 06:53:31 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=q32-com.20150623.gappssmtp.com; s=20150623;
 h=mime-version:references:in-reply-to:from:date:message-id:subject:to
 :content-transfer-encoding;
 bh=mdzp0cAYOEOJ/cMEY4IUer+sTsQWNrGZdPVkXu8KNDA=;
 b=FaWWtKNt3/0uf96Fd59PiiITHCR5m0wizDFqJikR35gc0YthFSYDuiXFr/KQqqMe2Y
 AO7JqN6+3prpGAOnwiuwREzMXaSnUjTRCQGKkEhgyv3ch2OECApjMLlNp8ao/eHOncPQ
 YuEjDeQtzo+hkR854rn2k1T/vM6WnCoVCA0A9zKCCgmqz8JZB+mQUjYmKDdcDMfDQb60
 q7Ad+MWmKnl1G/VLRJZx/G+AMZtaEEO+c2XiVcCxnu+1BMcM1u9RlTtliQKg91MVr9r/
 Phfe+Y5LrUGax1UM1CIHjWs1FWStyOlUuCC5d6oRxHav5QC3ftbQ+bJL0HSDii5jGLnd
 xWig==
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:content-transfer-encoding;
 bh=mdzp0cAYOEOJ/cMEY4IUer+sTsQWNrGZdPVkXu8KNDA=;
 b=n6AUurqBuGeH7RqAPqc3jg55CNeV8QhVlu+tICPceJ6HgE06GMxyVGiuvutfHZqdmS
 cK/YzusWPXaOoafKp0bon6ZmRy68jGEfB5VdqTwwZoTRnw3/Q31mKp51I1T8xOFeAcsA
 XQL6EtGBtCFlZg6b4vmXGxPhmx6omdMpMn+ujrtdLcHhdGEduPbhwd300xDqxhPIWunO
 ebKQ8v/PecIb4mwnIWlOIeSlqQ/1/Z7Akc/Fyt6jh2yxiZbKOAKrltk+RFVB3nUcspD2
 my5iaP3kfEQPrzV+7uqwhiNea5Nfcs/ey5qgaKRxo16vLCvq7HanzjkwEk+3rrymLkSk
 Ymxw==
X-Gm-Message-State: AOAM530S91FTMKwupYBQ2l8dVYzP79I90x99LhsMl6VyXW70bnrXgIvz
 NYGmyL/PsJbKvLq35/V4YhZ2vHd9kAr3iPVnBvd+bLiH/5LTkJzcfw==
X-Google-Smtp-Source: ABdhPJwI6fWa2X0mWGC2yctXXZOyHxEr6s/z4pyuFugAwF1LNUVEDmyDlxT8AbAjPTD6unLG6Hg1HnPrvFzi/uR4pEE=
X-Received: by 2002:a17:902:a9c2:b029:e7:147f:76a1 with SMTP id
 b2-20020a170902a9c2b02900e7147f76a1mr18097671plr.5.1618062810887; Sat, 10 Apr
 2021 06:53:30 -0700 (PDT)
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
X-Mailman-Approved-At: Sat, 10 Apr 2021 14:13:09 +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 <bitcoin-dev.lists.linuxfoundation.org>
List-Unsubscribe: <https://lists.linuxfoundation.org/mailman/options/bitcoin-dev>, 
 <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=unsubscribe>
List-Archive: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/>
List-Post: <mailto:bitcoin-dev@lists.linuxfoundation.org>
List-Help: <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=help>
List-Subscribe: <https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev>, 
 <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=subscribe>
X-List-Received-Date: Sat, 10 Apr 2021 13:53:33 -0000

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