diff options
author | Hugo Nguyen <hugo@nunchuk.io> | 2021-02-15 06:19:14 -0800 |
---|---|---|
committer | bitcoindev <bitcoindev@gnusha.org> | 2021-02-15 14:19:29 +0000 |
commit | bd22b19306143f1b21894b75a1db50308148c4c4 (patch) | |
tree | eff02f5c8b2c8f489ac2d2fe930fad9e7c02da7f | |
parent | f688e01ea039a10bd237030ce03159a04577eebc (diff) | |
download | pi-bitcoindev-bd22b19306143f1b21894b75a1db50308148c4c4.tar.gz pi-bitcoindev-bd22b19306143f1b21894b75a1db50308148c4c4.zip |
Re: [bitcoin-dev] Proposal: Bitcoin Secure Multisig Setup
-rw-r--r-- | e9/69da5076c3069c7c212f345f98ba3998d81bb7 | 788 |
1 files changed, 788 insertions, 0 deletions
diff --git a/e9/69da5076c3069c7c212f345f98ba3998d81bb7 b/e9/69da5076c3069c7c212f345f98ba3998d81bb7 new file mode 100644 index 000000000..571d71da9 --- /dev/null +++ b/e9/69da5076c3069c7c212f345f98ba3998d81bb7 @@ -0,0 +1,788 @@ +Return-Path: <hugo@nunchuk.io> +Received: from hemlock.osuosl.org (smtp2.osuosl.org [140.211.166.133]) + by lists.linuxfoundation.org (Postfix) with ESMTP id AA165C013A + for <bitcoin-dev@lists.linuxfoundation.org>; + Mon, 15 Feb 2021 14:19:29 +0000 (UTC) +Received: from localhost (localhost [127.0.0.1]) + by hemlock.osuosl.org (Postfix) with ESMTP id 8565A87031 + for <bitcoin-dev@lists.linuxfoundation.org>; + Mon, 15 Feb 2021 14:19:29 +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 qFkxTMolPxK2 + for <bitcoin-dev@lists.linuxfoundation.org>; + Mon, 15 Feb 2021 14:19:27 +0000 (UTC) +X-Greylist: delayed 05:34:55 by SQLgrey-1.7.6 +Received: from mail-vk1-f180.google.com (mail-vk1-f180.google.com + [209.85.221.180]) + by hemlock.osuosl.org (Postfix) with ESMTPS id 0A9308702B + for <bitcoin-dev@lists.linuxfoundation.org>; + Mon, 15 Feb 2021 14:19:27 +0000 (UTC) +Received: by mail-vk1-f180.google.com with SMTP id m145so1513286vke.7 + for <bitcoin-dev@lists.linuxfoundation.org>; + Mon, 15 Feb 2021 06:19:26 -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=ncEnMX1Pql0WuFGTJxBtB7HxUSWS97Pgve8xsmZQTNs=; + b=eNocWxvtMP7RwdfW0t419fY5x5ZTuE4H5o38MuOMNPp1wAm5GLEj/ICIB37PTzADWZ + bj8u3ELjs3BsPaXHKuuLt3XJom/5Psa3tqIV2cAvOAdY2iCHjNhKvqchN/E4Ri/ZTsxm + 7d2T1rr3XW2TGKc1yP40wZbWnEg8NuYcNwy2UVkx6nxyzdJSt74UBrmneN/l9DKmIJm4 + eoDwXELMi0f32/K55vEwE8P1sNOheug10S8KJpeihPiJhsFVTBaaD0OhVQE9LKDyvPRW + QzStPp1H36n9Isci9CcshLVl5HFeJa32NoxbnoUK0DPeSwR4Jw2s2KCEJjugq2kAaEbT + OBQA== +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=ncEnMX1Pql0WuFGTJxBtB7HxUSWS97Pgve8xsmZQTNs=; + b=RSGG6SJvJTY0UNaF0aTLKiAXrpKBIVSvZUUFEe/BBMpo2ghXAYV4Ckcg7L2sQvdz71 + swi/jqNWiIP3t5jYgYsYYkyyFPbGiReg0BUFYoKipuDyhBGzDEFUM71U+EhLW01WCNcV + mbnbT0qfX7/f174cUsVDqcz+Ger0TQz3HHxsPlUNKWTkVv2C8UBGZRNE1psL9IRpcJRf + ii4eWrVgb4/WfBoTOr1jw2+4e5E+lyezHFYtF++c8xwbGZFkrAR+g6DrnpGc/YW1REZv + 0pXRAJ6VhMWALQnNIXpHDJNk4fkyhfSVSQ6+i3riLFxz9YOM+rJTrH3y6wWN0rP3H5Xx + Iupw== +X-Gm-Message-State: AOAM533pkuVftjLPuzCz5UUhimYQEqFJ+IoMf1ZbijT2Sa5M8EatOaZI + NRmTL8cLkCjX4P681W4+9YavxACHrRss960H2dEkQQ== +X-Google-Smtp-Source: ABdhPJxsyn+Rli2yGFQwui5bFRyFourD0tzlNr6DPPQ25YAtYIKbhyDV5Cqp8xHtwusHQWFt6CKkbXXF+3ineiheDPI= +X-Received: by 2002:a05:6122:788:: with SMTP id + k8mr7575847vkr.23.1613398765689; + Mon, 15 Feb 2021 06:19:25 -0800 (PST) +MIME-Version: 1.0 +References: <CAPKmR9uyY70MhmVCh=C9DeyF2Tyxibux1E_bLPo00aW_h+OjLw@mail.gmail.com> + <CAPKmR9urumKTTdBFtu-xY+RdSptOGomnJGK+sbEVnmDH=ZkBKw@mail.gmail.com> + <CAPR5oBPtap5Q7DUbNsjy9JxLOp82nEOnj5WA=amas1OqVot-Ew@mail.gmail.com> +In-Reply-To: <CAPR5oBPtap5Q7DUbNsjy9JxLOp82nEOnj5WA=amas1OqVot-Ew@mail.gmail.com> +From: Hugo Nguyen <hugo@nunchuk.io> +Date: Mon, 15 Feb 2021 06:19:14 -0800 +Message-ID: <CAPKmR9uhuC5L9RUK3MsMrzgNezTgmHsZ6MWwaud1bcxRje0=ww@mail.gmail.com> +To: Craig Raw <craigraw@gmail.com> +Content-Type: multipart/alternative; boundary="000000000000500c1805bb60aca6" +X-Mailman-Approved-At: Mon, 15 Feb 2021 15:39:15 +0000 +Cc: Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org> +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: Mon, 15 Feb 2021 14:19:29 -0000 + +--000000000000500c1805bb60aca6 +Content-Type: text/plain; charset="UTF-8" +Content-Transfer-Encoding: quoted-printable + +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 i= +n +> 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 tha= +t +> 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? +>> +>> +>> =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 +>> +>> +>> <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> +>> +>> =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 acros= +s +>> 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 +>> 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 secr= +ets +>> to the parties involved for secure communication. The Coordinator gather= +s +>> 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 +>> responsibilities include providing its key record -- which contains an +>> Extended Public Key (XPUB) -- to the Coordinator, verifying that its XPU= +B +>> is included in the descriptor record and persisting the descriptor recor= +d +>> 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, su= +ch +>> 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> fo= +r +>> all Signers, or to have one per Signer. +>> * If encryption is disabled, <tt>TOKEN</tt> is set to <tt>0</tt>, and al= +l +>> 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 th= +e +>> <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. Optional= +ly, +>> the Signer can choose a path on behalf of the user. If the Signer choose= +s +>> 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 l= +ine +>> 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 enti= +re +>> 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 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 descrip= +tor +>> 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#checks= +ums +>> BECH32 encoding]. +>> * The Coordinator encrypts this descriptor record with +>> <tt>ENCRYPTION_KEY</tt>. +>> * 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 +>> <tt>ENCRYPTION_KEY</tt> derived from the open session. +>> * The Signer calculates and verifies the descriptor=E2=80=99s <tt>CHECKS= +UM</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=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</tt>. The total number of Signers, <tt>N</tt>, is important to +>> prevent a <tt>KEY</tt> insertion attack. All participating Signers shoul= +d +>> 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. +>> +>> =3D=3D=3DEncryption=3D=3D=3D +>> +>> =3D=3D=3D=3DThe Token=3D=3D=3D=3D +>> 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. +>> +>> =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: +>> +>> <tt>DK =3D PBKDF2(PRF, Password, Salt, c, dkLen)</tt> +>> +>> Whereas: +>> +>> * PRF =3D <tt>SHA512</tt> +>> * Password =3D <tt>"No SPOF"</tt> +>> * Salt =3D <tt>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 [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 +>> 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]. +>> +>> Also refer to [ +>> https://github.com/BlockchainCommons/Research/blob/master/papers/bcr-202= +0-015-account.md +>> UR Type Definition for BIP44 Accounts] and [ +>> https://github.com/BlockchainCommons/Research/blob/master/papers/bcr-202= +0-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 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. +>> +>> =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/01= +8385.html +>> +>> +>> _______________________________________________ +>> bitcoin-dev mailing list +>> bitcoin-dev@lists.linuxfoundation.org +>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev +>> +> + +--000000000000500c1805bb60aca6 +Content-Type: text/html; charset="UTF-8" +Content-Transfer-Encoding: quoted-printable + +<div dir=3D"ltr"><div>Hi Craig,<br>Thanks for the feedback! Sharing my comm= +ents inline.</div><br><div class=3D"gmail_quote"><div dir=3D"ltr" class=3D"= +gmail_attr">On Mon, Feb 15, 2021 at 5:53 AM Craig Raw <<a href=3D"mailto= +:craigraw@gmail.com">craigraw@gmail.com</a>> wrote:<br></div><blockquote= + class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px so= +lid rgb(204,204,204);padding-left:1ex"><div dir=3D"ltr"><div>Hi all,</div><= +div><br></div>Hugo and I have discussed off-list, and I have two concerns w= +ith this proposal:<div><br></div><div>1. I believe adding the TOKEN and enc= +ryption to the exchange adds complexity to already notoriously complex mult= +isig, without adding much in the way of security. </div></div></blockquote>= +<div><br>I disagree that this doesn't add security. This proposal was i= +nspired by a real vulnerability we discovered in the wild while experimenti= +ng 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 t= +heir own XPUBs. This is especially important for remote multisig setups - w= +hich is not common now but I imagine will be a lot more common in the futur= +e.<br><br><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8= +ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">This is because= + the shared secret (TOKEN) must still be shared securely, and if you have e= +stablished an (off-protocol) secure channel to do this, why not just share = +the actual multisig configuration data directly in that channel? </blockquo= +te></div><div><br>Because multisig is inherently an interactive process. If= + we can create the multisig configuration in one shot for everybody, you= +9;re correct that this is not necessary! But the fact that multisig is by n= +ature interactive and requires a few rounds of communication (since it need= +s each Signer to voluntarily share its=C2=A0XPUB before a wallet can be cre= +ated) makes this necessary IMO.<br></div><div><br><blockquote class=3D"gmai= +l_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,20= +4,204);padding-left:1ex">If you are able to do so, you retain the advantage= + of being able to inspect the data directly.</blockquote><br>Note that some= + manual inspection is still part of the proposal. But instead of exclusivel= +y 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.</div>= +<div>=C2=A0</div><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px = +0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir= +=3D"ltr"><div><br></div><div>2. Asking the user to enter the derivation int= +o the Signer also adds (IMO unnecessary) complexity to the multisig setup p= +rocess. A different way of doing it, which is specified in the UR crypto-ac= +count format linked to previously, has the Signer provide as many common de= +rivations (along with their xpubs) as it can support for a given BIP44 acco= +unt number. This has the dual advantage of making things simpler for the us= +er (they only have to provide an optional account number) and increasing th= +e standardisation on common derivation paths. On receiving these derivation= +/xpub pairs, the Coordinator can simply pick the appropriate one.</div></di= +v></blockquote><div><br>Note that in the updated proposal, I added the opti= +on 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.<br><br>Best,<br>Hugo<br>=C2=A0</div><blockquo= +te class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px = +solid rgb(204,204,204);padding-left:1ex"><div dir=3D"ltr"><div><br></div><d= +iv>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 stand= +ardisation in hww import and export formats (not just for multisig). On tha= +t note, I'd love to see greater adoption of the efficient UR2.0 standar= +d and associated formats for airgapped data transmission using QR codes.</d= +iv><div><br></div><div>Craig</div><div><br></div></div><br><div class=3D"gm= +ail_quote"><div dir=3D"ltr" class=3D"gmail_attr">On Mon, Feb 15, 2021 at 11= +:13 AM Hugo Nguyen via bitcoin-dev <<a href=3D"mailto:bitcoin-dev@lists.= +linuxfoundation.org" target=3D"_blank">bitcoin-dev@lists.linuxfoundation.or= +g</a>> wrote:<br></div><blockquote class=3D"gmail_quote" style=3D"margin= +:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"= +><div dir=3D"ltr"><div>Hi all,<br>I have updated the proposal based on furt= +her feedback. The new spec is included at the bottom.</div><div><br></div><= +div>I have also created a public Github PR to make it easier to comment on = +the text of the spec itself:=C2=A0<a href=3D"https://github.com/nunchuk-io/= +bips/pull/1" target=3D"_blank">https://github.com/nunchuk-io/bips/pull/1</a= +> .<br><br>Could someone please let me know what else needs to be done befo= +re a BIP number can be assigned?<br><br><br>=3D=3D=3D Quick summary of chan= +ges from last update =3D=3D=3D<br><br>1. Define encryption modes<br><br># N= +O_ENCRYPTION: Encryption is disabled.<br># STANDARD : the TOKEN is a 64-bit= + nonce.<br># EXTENDED : the TOKEN is a 128-bit nonce.<br><br>2. Define sign= +ature algorithm<br><br>Follow BIP-0322, legacy format allowed.<br><br>3. Mu= +ltiple TOKENs (optional)<br><br>Also add an option where the Coordinator ca= +n choose to use one common TOKEN for all Signers, or use one per Signer.<br= +><br>=3D=3D=3D End of summary =3D=3D=3D</div><div><br></div><div><br>Cheers= +,<br>Hugo</div><div class=3D"gmail_quote"><div><br><br><pre><br>=C2= +=A0 BIP: To be determined<br>=C2=A0 Layer: Applications<br>=C2=A0 Title: Bi= +tcoin Secure Multisig Setup (BSMS)<br>=C2=A0 Author: Hugo Nguyen <hugo a= +t <a href=3D"http://nunchuk.io" target=3D"_blank">nunchuk.io</a>>, Peter= + Gray <peter at <a href=3D"http://coinkite.com" target=3D"_blank">coinki= +te.com</a>>, Marko Bencun <marko at <a href=3D"http://shiftcrypto.ch"= + target=3D"_blank">shiftcrypto.ch</a>>, Pavol Rusnak <<a href=3D"mail= +to:stick@satoshilabs.com" target=3D"_blank">stick@satoshilabs.com</a>>, = +Aaron Chen <aarondongchen at <a href=3D"http://gmail.com" target=3D"_bla= +nk">gmail.com</a>>, Rodolfo Novak <rodolfo at <a href=3D"http://coink= +ite.com" target=3D"_blank">coinkite.com</a>><br>=C2=A0 Comments-Summary:= + No comments yet.<br>=C2=A0 Comments-URI:<br>=C2=A0 Status: Proposed<br>=C2= +=A0 Type: Standards Track<br>=C2=A0 Created: 2020-11-10<br>=C2=A0 License: = +BSD-2-Clause<br></pre><br><br>=3D=3DIntroduction=3D=3D<br><br>=3D=3D= +=3DAbstract=3D=3D=3D<br><br>This document proposes a mechanism to set up mu= +ltisig wallets securely.<br><br>=3D=3D=3DCopyright=3D=3D=3D<br><br>This BIP= + is licensed under the 2-clause BSD license.<br><br>=3D=3D=3DMotivation=3D= +=3D=3D<br><br>The Bitcoin multisig experience has been greatly streamlined = +under [<a href=3D"https://github.com/bitcoin/bips/blob/master/bip-0174.medi= +awiki" target=3D"_blank">https://github.com/bitcoin/bips/blob/master/bip-01= +74.mediawiki</a> BIP-0174<br>(Partially Signed Bitcoin Transaction)]. Howev= +er, what is still missing is a standardized process for setting up multisig= + wallets securely across different vendors.<br><br>There are a number of co= +ncerns when it comes to setting up a multisig wallet:<br><br># Whether the = +multisig configuration, such as Signer membership, script type, derivation = +paths and number of signatures required, is correct and not tampered with.<= +br># Whether Signer persists the multisig configuration in their respective= + storage, and under what format.<br># Whether Signer's storage is tampe= +r-proof.<br># Whether Signer subsequently uses the multisig configuration t= +o generate and verify receive and change addresses.<br><br>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.<br><br>This propos= +al seeks to address concerns #1 and #2: to mitigate the risk of tampering d= +uring the initial setup phase, and to define an interoperable multisig conf= +iguration format.<br><br>Concerns #3 and #4 should be handled by Signers an= +d is out of scope of this proposal.<br><br>=3D=3DSpecification=3D=3D<br><br= +>=3D=3D=3DPrerequisites=3D=3D=3D<br>This proposal assumes the parties in th= +e multisig support [<a href=3D"https://github.com/bitcoin/bips/blob/master/= +bip-0032.mediawiki" target=3D"_blank">https://github.com/bitcoin/bips/blob/= +master/bip-0032.mediawiki</a> BIP-0032], [<a href=3D"https://github.com/bit= +coin/bitcoin/blob/master/doc/descriptors.md" target=3D"_blank">https://gith= +ub.com/bitcoin/bitcoin/blob/master/doc/descriptors.md</a> the descriptor la= +nguage] and encryption.<br><br>=3D=3D=3DRoles=3D=3D=3D<br>=3D=3D=3D=3DCoord= +inator=3D=3D=3D=3D<br><br>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 descrip= +tor record. The Coordinator distributes the descriptor record back to the S= +igners.<br><br>=3D=3D=3D=3DSigner=3D=3D=3D=3D<br><br>The Signer is a partic= +ipating member in the multisig. Its responsibilities include providing its = +key record -- which contains an Extended Public Key (XPUB) -- to the Coordi= +nator, verifying that its XPUB is included in the descriptor record and per= +sisting the descriptor record in its storage.<br><br>=3D=3D=3DSetup Process= +=3D=3D=3D<br><br>=3D=3D=3D=3DRound 1=3D=3D=3D=3D<br><br>=3D=3D=3D=3D=3DCoor= +dinator=3D=3D=3D=3D=3D<br><br>* The Coordinator creates a multisig wallet c= +reation session. The Coordinator constructs the multisig script and its pol= +icy parameters, such as the total number of signers and the required number= + of signatures (<tt>M</tt> and <tt>N</tt>).<br>* Th= +e session should expire after some time period determined by the Coordinato= +r, e.g., 24 hours.<br>* If encryption is enabled, the Coordinator distribut= +es 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 detail= +s on the <tt>TOKEN</tt>, the key derivation function and the en= +cryption scheme. Depending on the use case, the Coordinator can decide whet= +her to share one common <tt>TOKEN</tt> for all Signers, or to h= +ave one per Signer.<br>* If encryption is disabled, <tt>TOKEN</tt&= +gt; is set to <tt>0</tt>, and all the encryption/decryption ste= +ps below can be skipped.<br><br>=3D=3D=3D=3D=3DSigner=3D=3D=3D=3D=3D<br><br= +>* The Signer initiates a new secure multisig setup session by setting the = +<tt>TOKEN</tt>. The Signer derives an <tt>ENCRYPTION_KEY&= +lt;/tt> from the <tt>TOKEN</tt>. The Signer can keep the ses= +sion open until a different value for the <tt>TOKEN</tt> is set= +.<br>* The Signer generates a key record by prompting the user for a multis= +ig derivation path and retrieves the XPUB at that derivation path. Optional= +ly, the Signer can choose a path on behalf of the user. If the Signer choos= +es the path, it should try to avoid reusing XPUBs for different wallets.<br= +>* 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>, wher= +eas <tt>SIG</tt> is the signature generated by using the privat= +e key associated with the XPUB to sign the first two lines.=C2=A0 The signa= +ture should follow [<a href=3D"https://github.com/bitcoin/bips/blob/master/= +bip-0322.mediawiki" target=3D"_blank">https://github.com/bitcoin/bips/blob/= +master/bip-0322.mediawiki</a> BIP-0322], legacy format accepted. Finally, t= +he Signer encrypts the entire record with <tt>ENCRYPTION_KEY</tt&g= +t;.<br><br>=3D=3D=3D=3DRound 2=3D=3D=3D=3D<br><br>=3D=3D=3D=3D=3DCoordinato= +r=3D=3D=3D=3D=3D<br><br>* The Coordinator gathers key records from all part= +icipating Signers. Abort the setup if the wallet setup session has expired.= +<br>* For each key record, the Coordinator decrypts it using <tt>ENCR= +YPTION_KEY</tt>. The Coordinator verifies that the included <tt>= +;SIG</tt> is valid given the <tt>KEY</tt>.<br>* If all ke= +y 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 [<a href=3D"https://github.com/bitcoin/bitcoin/blob/master/doc/d= +escriptors.md#checksums" target=3D"_blank">https://github.com/bitcoin/bitco= +in/blob/master/doc/descriptors.md#checksums</a> BECH32 encoding].<br>* The = +Coordinator encrypts this descriptor record with <tt>ENCRYPTION_KEY&l= +t;/tt>.<br>* The Coordinator sends the encrypted descriptor record to al= +l participating Signers.<br><br>=3D=3D=3D=3D=3DSigner=3D=3D=3D=3D=3D<br><br= +>* The Signer imports the descriptor record, decrypts it using the <tt&g= +t;ENCRYPTION_KEY</tt> derived from the open session.<br>* The Signer = +calculates and verifies the descriptor=E2=80=99s <tt>CHECKSUM</tt&= +gt;. Abort the setup if the <tt>CHECKSUM</tt> is incorrect.<br>= +* The Signer checks whether one of the <tt>KEY</tt>s in the des= +criptor belongs to it, using path and fingerprint information included in t= +he descriptor. The check must perform an exact match on the <tt>KEY&l= +t;/tt>s, and not using shortcuts such as matching fingerprints (which is= + trivial to spoof). Abort the setup if it doesn=E2=80=99t detect its own &l= +t;tt>KEY</tt>.<br>* For confirmation, the Signer must display to t= +he user the <tt>CHECKSUM</tt>, plus other configurations, such = +as <tt>M</tt> and <tt>N</tt>. The total number of S= +igners, <tt>N</tt>, is important to prevent a <tt>KEY<= +/tt> insertion attack. All participating Signers should be able to displ= +ay the same confirmation.<br>* If all checks pass, the Signer persists the = +descriptor record in its storage.<br>* The Signer can choose to further res= +trict post-XPUB derivation paths, such as to those defined in [<a href=3D"h= +ttps://github.com/bitcoin/bips/blob/master/bip-0044.mediawiki" target=3D"_b= +lank">https://github.com/bitcoin/bips/blob/master/bip-0044.mediawiki</a> BI= +P-0044].<br>* The Signer should subsequently use the descriptor to generate= + and verify receive and change addresses.<br><br>This completes the setup.<= +br><br>=3D=3D=3DEncryption=3D=3D=3D<br><br>=3D=3D=3D=3DThe Token=3D=3D=3D= +=3D<br>We define three modes of encryption.<br><br># <tt>NO_ENCRYPTIO= +N</tt> : the <tt>TOKEN</tt> is set to <tt>0</tt&= +gt;. Encryption is disabled.<br># <tt>STANDARD</tt> : the <t= +t>TOKEN</tt> is a 64-bit nonce.<br># <tt>EXTENDED</tt>= + : the <tt>TOKEN</tt> is a 128-bit nonce.<br><br>The <tt>= +TOKEN</tt> can be converted to one of these formats:<br>* A mnemonic = +phrase using [<a href=3D"https://github.com/bitcoin/bips/blob/master/bip-00= +39.mediawiki" target=3D"_blank">https://github.com/bitcoin/bips/blob/master= +/bip-0039.mediawiki</a> BIP-0039] word list (6 words in <tt>STANDARD&= +lt;/tt> mode, 12 words in <tt>EXTENDED</tt> mode)<br>* A dec= +imal number (20 digits in <tt>STANDARD</tt> mode, 40 digits in = +<tt>EXTENDED</tt> mode)<br>* A QR code<br>* Other formats<br><b= +r>The flexibility in the data format allows each Signer to customize the Us= +er Experience based on its respective capabilities.<br><br>=3D=3D=3D=3DKey = +Derivation=3D=3D=3D=3D<br>The key derivation function is [<a href=3D"https:= +//tools.ietf.org/html/rfc2898" target=3D"_blank">https://tools.ietf.org/htm= +l/rfc2898</a> PBKDF2], with PRF =3D SHA512. Specifically:<br><br><tt>= +DK =3D PBKDF2(PRF, Password, Salt, c, dkLen)</tt><br><br>Whereas:<br>= +<br>* PRF =3D <tt>SHA512</tt><br>* Password =3D <tt>"= +;No SPOF"</tt><br>* Salt =3D <tt>TOKEN</tt><br>* c = +=3D <tt>2048</tt><br>* dkLen =3D <tt>256</tt><br>* = +DK =3D Derived <tt>ENCRYPTION_KEY</tt><br><br>=3D=3D=3D=3DEncry= +ption Scheme=3D=3D=3D=3D<br>The encryption scheme is [<a href=3D"https://to= +ols.ietf.org/html/rfc3686" target=3D"_blank">https://tools.ietf.org/html/rf= +c3686</a> AES, CTR mode].<br><br>=3D=3DQR Codes=3D=3D<br>For signers that u= +se QR codes to transmit data, key and descriptor records can be converted t= +o QR codes, following [<a href=3D"https://github.com/BlockchainCommons/Rese= +arch/blob/master/papers/bcr-2020-005-ur.md" target=3D"_blank">https://githu= +b.com/BlockchainCommons/Research/blob/master/papers/bcr-2020-005-ur.md</a> = +the BCR standard].<br><br>Also refer to [<a href=3D"https://github.com/Bloc= +kchainCommons/Research/blob/master/papers/bcr-2020-015-account.md" target= +=3D"_blank">https://github.com/BlockchainCommons/Research/blob/master/paper= +s/bcr-2020-015-account.md</a> UR Type Definition for BIP44 Accounts] and [<= +a href=3D"https://github.com/BlockchainCommons/Research/blob/master/papers/= +bcr-2020-010-output-desc.md" target=3D"_blank">https://github.com/Blockchai= +nCommons/Research/blob/master/papers/bcr-2020-010-output-desc.md</a> UR Typ= +e Definition for Bitcoin Output Descriptors] for more details.<br><br>=3D= +=3DSecurity=3D=3D<br><br>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 it= +self.<br><br>The token is only needed during the setup phase, and can be sa= +fely thrown away afterwards. The token does not guarantee that the Signer m= +embership set is not modified, since that depends on the overall security o= +f all parties in the setup, but it can make it significantly harder for an = +attacker to do so.<br><br>There are three ways an attacker can modify the m= +embership set: by changing an existing member, by removing an existing memb= +er, or by adding a new member.<br><br>For the first two methods, one of the= + Signers will be able to detect that its membership has been changed or rem= +oved, and reject the final descriptor. Thus, it is vital that all participa= +ting Signers check that their membership is intact in the descriptor. Even = +one Signer failing to check for its membership means that the setup could b= +e compromised.<br><br>For the third type of attack, the descriptor checksum= + and visual inspection of the descriptor itself are the only way to guard a= +gainst malicious members from being inserted into the set.<br><br>=3D=3DAck= +nowledgement=3D=3D<br><br>Special thanks to Dmitry Petukhov, Christopher Al= +len, Craig Raw and others for their feedback on the specification.<br><br>= +=3D=3DReferences=3D=3D<br><br>Original mailing list thread: <a href=3D"http= +s://lists.linuxfoundation.org/pipermail/bitcoin-dev/2021-February/018385.ht= +ml" target=3D"_blank">https://lists.linuxfoundation.org/pipermail/bitcoin-d= +ev/2021-February/018385.html</a><br><br>=C2=A0</div></div></div> +_______________________________________________<br> +bitcoin-dev mailing list<br> +<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" target=3D"_blank">= +bitcoin-dev@lists.linuxfoundation.org</a><br> +<a href=3D"https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev" = +rel=3D"noreferrer" target=3D"_blank">https://lists.linuxfoundation.org/mail= +man/listinfo/bitcoin-dev</a><br> +</blockquote></div> +</blockquote></div></div> + +--000000000000500c1805bb60aca6-- + |