{"type":"rich","version":"1.0","author_name":"npub1jqxs4ftunmm8qjyw9s80hpcayewkjfhpxund29l9qvzy7xqx4duq85jqeg","author_url":"https://nostr.ae/npub1jqxs4ftunmm8qjyw9s80hpcayewkjfhpxund29l9qvzy7xqx4duq85jqeg","provider_name":"njump","provider_url":"https://nostr.ae","html":"📅 Original date posted:2021-02-08\n📝 Original message:Hi all,\nI would like to propose a new BIP for Secure Multisig Setup.\nThis proposal has taken inputs from folks at Coldcard, Shift Crypto and\nCobo -- listed below as co-authors.\n\nThis was inspired by my own experience working with hardware wallets on the\nmarket, as well as existing research into the challenges of multisig.\n\nCheers,\nHugo\n\n\u003cpre\u003e\n  BIP: To be determined\n  Layer: Applications\n  Title: Bitcoin Secure Multisig Setup (BSMS)\n  Author: Hugo Nguyen \u003chugo at nunchuk.io\u003e, Peter Gray \u003cpeter at coinkite.com\u003e,\nMarko Bencun \u003cmarko at shiftcrypto.ch\u003e, Aaron Chen \u003caarondongchen at gmail.com\u003e,\nRodolfo Novak \u003crodolfo at coinkite.com\u003e\n  Comments-Summary: No comments yet.\n  Comments-URI:\n  Status: Proposed\n  Type: Standards Track\n  Created: 2020-11-10\n  License: BSD-2-Clause\n\u003c/pre\u003e\n\n==Introduction==\n\n===Abstract===\n\nThis document proposes a mechanism to set up multisig wallets securely.\n\n===Copyright===\n\nThis BIP is licensed under the 2-clause BSD license.\n\n===Motivation===\n\nThe Bitcoin multisig experience has been greatly streamlined under [\nhttps://github.com/bitcoin/bips/blob/master/bip-0174.mediawiki BIP-0174\n(Partially Signed Bitcoin Transaction)]. However, what is still missing is\na standardized process for setting up multisig wallets securely across\ndifferent vendors.\n\nThere are a number of concerns when it comes to setting up a multisig\nwallet:\n\n# Whether the multisig configuration, such as Signer membership, script\ntype, derivation paths and number of signatures required, is correct and\nnot tampered with.\n# Whether Signer persists the multisig configuration in their respective\nstorage, and under what format.\n# Whether Signer's storage is tamper-proof.\n# Whether Signer subsequently uses the multisig configuration to generate\nand verify receive and change addresses.\n\nAn attacker who can modify the multisig configuration can steal or hold\nfunds to ransom by duping the user into sending funds to the wrong address.\n\nThis proposal seeks to address concerns #1 and #2: to mitigate the risk of\ntampering during the initial setup phase, and to define an interoperable\nmultisig configuration format.\n\nConcerns #3 and #4 should be handled by Signers and is out of scope of this\nproposal.\n\n==Specification==\n\n===Prerequisites===\nThis proposal assumes the parties in the multisig support [\nhttps://github.com/bitcoin/bips/blob/master/bip-0032.mediawiki BIP32], [\nhttps://github.com/bitcoin/bitcoin/blob/master/doc/descriptors.md the\ndescriptor language] and encryption.\n\n==Roles==\n===Coordinator===\n\nThe Coordinator initiates the multisig setup. The Coordinator determines\nwhat type of multisig is used and how many members and signatures are\nneeded. If encryption is enabled, the Coordinator generates a secret token,\nto be shared among the parties for secure communication. The Coordinator\ngathers information from the Signers to generate a descriptor record. The\nCoordinator distributes the descriptor record back to the Signers.\n\n===Signer===\n\nThe Signer is a participating member in the multisig. Its responsibilities\ninclude providing its XPUB to the Coordinator, verifying that its XPUB is\nincluded in the descriptor record and persisting the descriptor record in\nits storage.\n\n==Setup Process==\n\n===Round 1===\n\n====Coordinator====\n\n* The Coordinator creates a multisig wallet creation session. The\nCoordinator determines the type of multisig script used and the signing\nconfiguration (\u003ctt\u003eM\u003c/tt\u003e and \u003ctt\u003eN\u003c/tt\u003e).\n* If encryption is enabled, the Coordinator also generates a secret token,\nhereby denoted \u003ctt\u003eTOKEN\u003c/tt\u003e.\n* TOKEN is in ASCII format and must have a minimum of 8 characters. TOKEN\nshould expire after some time period determined by the Coordinator, e.g.,\n24 hours.\n* TOKEN acts as an encryption key among the parties. The method of\nencryption is AES, CTR mode. The encryption key can be calculated by\nperforming a double hash operation on the TOKEN: \u003ctt\u003eENCRYPTION_KEY =\nSHA256(SHA256(TOKEN))\u003c/tt\u003e.\n* A TOKEN value of \u003ctt\u003e-1\u003c/tt\u003e means that encryption is disabled and all\nthe encryption/decryption steps below can be skipped.\n* The Coordinator shares the TOKEN with all participating Signers over a\nsecure channel.\n\n====Signer====\n\n* The Signer generates a key record by prompting the user for the TOKEN and\na derivation path.\n* The first line in the record must be the \u003ctt\u003eTOKEN\u003c/tt\u003e. If encryption is\ndisabled, set the TOKEN to -1. The second line must be the \u003ctt\u003eKEY\u003c/tt\u003e,\nwhereas KEY is an XPUB. KEY must include key origin information and written\nin the descriptor-defined format, i.e.: \u003ctt\u003e[{master key\nfingerprint}/{derivation path}]{XPUB}\u003c/tt\u003e. The third line must be a\n\u003ctt\u003eSIG\u003c/tt\u003e, whereas SIG is the signature generated by using the\ncorresponding private key to sign the first two lines. Finally, the Signer\nencrypts the entire record with ENCRYPTION_KEY.\n\n===Round 2===\n\n====Coordinator====\n\n* The Coordinator gathers key records from all participating Signers. Abort\nthe setup if TOKEN has expired.\n* For each key record, the Coordinator decrypts it using ENCRYPTION_KEY.\nThe Coordinator verifies that the included SIG is valid given the KEY.\n* If all key records look good, the Coordinator generates a descriptor\nrecord, which is simply the descriptor string plus a \u003ctt\u003eCHECKSUM\u003c/tt\u003e, all\nin one line. The CHECKSUM has BECH32 encoding and is described at [\nhttps://github.com/bitcoin/bitcoin/blob/master/doc/descriptors.md#checksums].\nThe Coordinator encrypts this descriptor record with ENCRYPTION_KEY.\n* The Coordinator sends the encrypted descriptor record to all\nparticipating Signers.\n\n====Signer====\n\n* The Signer imports the descriptor record, decrypts it by prompting the\nuser for TOKEN.\n* The Signer calculates and verifies the descriptor’s CHECKSUM. Abort the\nsetup if the CHECKSUM is incorrect.\n* The Signer checks whether one of the KEYs in the descriptor belongs to\nit, using path and fingerprint information included in the descriptor. The\ncheck must perform an exact match on the KEYs, and not using shortcuts such\nas matching fingerprints (which is trivial to spoof). Abort the setup if it\ndoesn’t detect its own KEY.\n* For confirmation, the Signer must display to the user the descriptor's\nCHECKSUM, plus other configurations, such as M and N. The total number of\nSigners, N, is important to prevent a KEY insertion attack. All\nparticipating Signers should be able to display the same confirmation.\n* If all checks pass, the Signer persists the descriptor record in its\nstorage. The Signer should subsequently use the descriptor to generate and\nverify receive and change addresses.\n\nThis completes the setup.\n\n==QR Codes==\nFor signers that use QR codes to transmit data, key and descriptor records\ncan be converted to QR codes, following [\nhttps://github.com/BlockchainCommons/Research/blob/master/papers/bcr-2020-005-ur.md\nthe BCR standard].\n\n==Security==\n\nThis proposal introduce two layers of protection. The first one is a\ntemporary, secret token, used to encrypt the two rounds of communication\nbetween the Signers and the Coordinator. The second one is through the\ndescriptor checksum and visual inspection of the descriptor itself.\n\nThe token is only needed during the setup phase, and can be safely thrown\naway afterwards. The token does not guarantee that the Signer membership\nset is not modified, since that depends on the overall security of all\nparties in the setup, but it can make it significantly harder for an\nattacker to do so.\n\nThere are three ways an attacker can modify the membership set: by changing\nan existing member, by removing an existing member, or by adding a new\nmember.\n\nFor the first two methods, one of the Signers will be able to detect that\nits membership has been changed or removed, and reject the final\ndescriptor. Thus, it is vital that all participating Signers check that\ntheir membership is intact in the descriptor. Even one Signer failing to\ncheck for its membership means that the setup could be compromised.\n\nFor the third type of attack, the descriptor checksum and visual inspection\nof the descriptor itself are the only way to guard against malicious\nmembers from being inserted into the set.\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: \u003chttp://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20210208/77bca22d/attachment.html\u003e"}