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 <[email protected]> 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 > > <pre> > BIP: To be determined > Layer: Applications > Title: Bitcoin Secure Multisig Setup (BSMS) > Author: Hugo Nguyen <[email protected]>, Peter Gray <[email protected]>, > Marko Bencun <[email protected]>, Aaron Chen <[email protected]>, > Rodolfo Novak <[email protected]> > Comments-Summary: No comments yet. > Comments-URI: > Status: Proposed > Type: Standards Track > Created: 2020-11-10 > License: BSD-2-Clause > </pre> > > ==Introduction== > > ===Abstract=== > > This document proposes a mechanism to set up multisig wallets securely. > > ===Copyright=== > > This BIP is licensed under the 2-clause BSD license. > > ===Motivation=== > > 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 generate and > verify receive and change addresses. > > An attacker who can modify the multisig configuration can steal or hold funds > to ransom by duping the user into sending funds to the wrong 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. > > ==Specification== > > ===Prerequisites=== > 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. > > ==Roles== > ===Coordinator=== > > 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 token, to be shared > among the parties for secure communication. The Coordinator gathers > information from the Signers to generate a descriptor record. The Coordinator > distributes the descriptor record back to the Signers. > > ===Signer=== > > The Signer is a participating member in the multisig. Its responsibilities > 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. > > ==Setup Process== > > ===Round 1=== > > ====Coordinator==== > > * The Coordinator creates a multisig wallet creation session. The Coordinator > determines the type of multisig script used and the signing configuration > (<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 encryption > is AES, CTR mode. The encryption key can be calculated by performing a double > hash operation on the TOKEN: <tt>ENCRYPTION_KEY = SHA256(SHA256(TOKEN))</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. > > ====Signer==== > > * 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 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 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>, whereas SIG is the signature generated by using the > corresponding private key to sign the first two lines. Finally, the Signer > encrypts the entire record with ENCRYPTION_KEY. > > ===Round 2=== > > ====Coordinator==== > > * 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 <tt>CHECKSUM</tt>, all > in one line. The CHECKSUM has BECH32 encoding and is described at > [https://github.com/bitcoin/bitcoin/blob/master/doc/descriptors.md#checksums]. > The Coordinator encrypts this descriptor record with ENCRYPTION_KEY. > * The Coordinator sends the encrypted descriptor record to all participating > Signers. > > ====Signer==== > > * The Signer imports the descriptor record, decrypts it by prompting the user > for TOKEN. > * The Signer calculates and verifies the descriptor’s 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. 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 it > doesn’t 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 > 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 and > verify receive and change addresses. > > This completes the setup. > > ==QR Codes== > 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-2020-005-ur.md > the BCR standard]. > > ==Security== > > 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 thrown > away afterwards. The token does not guarantee that the Signer membership set > is not modified, since that depends on the overall security of all parties in > the setup, but it can make it significantly harder for an attacker to do so. > > There are three ways an attacker can modify the membership set: by changing > an existing member, by removing an existing member, or by adding a new member. > > For the first two methods, one of the Signers will be able to detect that its > membership has been changed or removed, and reject the final descriptor. > Thus, it is vital that all participating Signers check that their membership > is intact in the descriptor. Even one Signer failing to check for its > membership means that the setup could be compromised. > > For the third type of attack, the descriptor checksum and visual inspection > of the descriptor itself are the only way to guard against malicious members > from being inserted into the set. > _______________________________________________ > bitcoin-dev mailing list > [email protected] > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev _______________________________________________ bitcoin-dev mailing list [email protected] https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
