{"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-09\n📝 Original message:Hi Craig,\nComments inline.\n\nOn Tue, Feb 9, 2021 at 1:17 AM Craig Raw \u003ccraigraw at gmail.com\u003e wrote:\n\n\u003e Hi Hugo,\n\u003e\n\u003e Thanks for raising this again - I'll note there has already been much\n\u003e discussion on this topic. With respect to your \"two layers of protection\":\n\u003e\n\u003e \u003e The Coordinator shares the TOKEN with all participating Signers over a\n\u003e secure channel.\n\u003e\n\u003e What secure channel do you propose? Currently, with the default of a\n\u003e software wallet coordinator talking to hardware wallets, we have USB, file\n\u003e (microSD), and QR as communication channels. It's unclear to me why the\n\u003e token and encryption process is necessary - in fact it's easier to verify\n\u003e what is going on using clear text, and the majority of setups will be\n\u003e locally done with the reasonable assumption of a secure environment. When\n\u003e the setup is remote, it's simpler to just transmit the key information over\n\u003e the secure channel which presumably already has encryption.\n\u003e\n\u003e\nIn short, a shared secret (the TOKEN) is needed because without it you\ncannot guarantee that the devices you are connecting to are legitimate\nmembers of the multisig wallet. Yes, the connection between the coordinator\nand each device could be secure - but a malicious actor can establish a\nsecure channel just as well as a good one. You are correct that this is\nless of an issue for local setups, but this is especially important for\ndistributed multisig - where you cannot physically see what's on the other\nside.\n\nI would love to remove the shared secret/encryption aspect out of the\nproposal, but so far I haven't found any way around this issue, aside from\nestablishing a shared secret prior to setting up the wallet...\n\nI also realized that supporting this could be a big ask for vendors, so\nI've made this part of the proposal optional.\n\nAnother note here is that right after I posted the proposal (classic...), I\nalso realized there could be another optimization: the secure session\nestablished by the shared secret can remain open indefinitely on the device\nside - until a different TOKEN is entered. That way the user needs to enter\nthe TOKEN only once, saving us one interaction.\n\n\n\u003e \u003e The second one is through the descriptor checksum and visual inspection\n\u003e of the descriptor itself.\n\u003e\n\u003e This is a reasonable suggestion, although it's worth noting that support\n\u003e for storing multisig setups on hardware wallets varies. Coldcard supports\n\u003e this through importing of a proprietary .txt format file (which has been\n\u003e adopted by a number of other vendors). Trezor and Ledger (AFAIK) do not\n\u003e however store multisig setups, which could make this step confusing. With\n\u003e that said, the use of an output descriptor is certainly a more standardised\n\u003e approach, albeit one without the wallet name included. By the use of the\n\u003e singular, I assume you mean a descriptor without the /0/* or /1/* suffix\n\u003e (which I think is a good idea).\n\u003e\n\u003e\nI'm aware that Trezor and Ledger currently cannot support this. But IMHO\nlack of support on some devices shouldn't prevent us from setting a good\nstandard here. Cosigner registration on the device is crucial, as you don't\nhave to rely on everything being included in the PSBT (which also adds\nmental overhead as the user has to verify each and every transaction).\n\nYes, descriptor without the /0/* and /1/* - Thanks for clarifying. Will\nupdate the proposal.\n\n\n\n\u003e WRT to QR codes, using the BCR UR2.0 standard you linked to is IMO the\n\u003e right approach. I'll link directly to the two BCR UR2.0 formats here which\n\u003e are relevant:\n\u003e\n\u003e 1. For sharing the sharing the BIP44 account information from the signers\n\u003e to the coordinator, the crypto-account format: [\n\u003e https://github.com/BlockchainCommons/Research/blob/master/papers/bcr-2020-015-account.md\n\u003e ]\n\u003e 2. For sharing the output descriptor from the coordinator to the signers,\n\u003e the crypto-output format: [\n\u003e https://github.com/BlockchainCommons/Research/blob/master/papers/bcr-2020-010-output-desc.md\n\u003e ]\n\u003e\n\u003e\nThanks, will update!\n\n\n\u003e Craig\n\u003e\n\u003e\n\u003e\n\u003e On Tue, Feb 9, 2021 at 9:53 AM Hugo Nguyen via bitcoin-dev \u003c\n\u003e bitcoin-dev at lists.linuxfoundation.org\u003e wrote:\n\u003e\n\u003e\u003e Hi all,\n\u003e\u003e I would like to propose a new BIP for Secure Multisig Setup.\n\u003e\u003e This proposal has taken inputs from folks at Coldcard, Shift Crypto and\n\u003e\u003e Cobo -- listed below as co-authors.\n\u003e\u003e\n\u003e\u003e This was inspired by my own experience working with hardware wallets on\n\u003e\u003e the market, as well as existing research into the challenges of multisig.\n\u003e\u003e\n\u003e\u003e Cheers,\n\u003e\u003e Hugo\n\u003e\u003e\n\u003e\u003e \u003cpre\u003e\n\u003e\u003e   BIP: To be determined\n\u003e\u003e   Layer: Applications\n\u003e\u003e   Title: Bitcoin Secure Multisig Setup (BSMS)\n\u003e\u003e   Author: Hugo Nguyen \u003chugo at nunchuk.io\u003e, Peter Gray \u003cpeter at coinkite.com\u003e,\n\u003e\u003e Marko Bencun \u003cmarko at shiftcrypto.ch\u003e, Aaron Chen \u003caarondongchen at gmail.com\u003e,\n\u003e\u003e Rodolfo Novak \u003crodolfo at coinkite.com\u003e\n\u003e\u003e   Comments-Summary: No comments yet.\n\u003e\u003e   Comments-URI:\n\u003e\u003e   Status: Proposed\n\u003e\u003e   Type: Standards Track\n\u003e\u003e   Created: 2020-11-10\n\u003e\u003e   License: BSD-2-Clause\n\u003e\u003e \u003c/pre\u003e\n\u003e\u003e\n\u003e\u003e ==Introduction==\n\u003e\u003e\n\u003e\u003e ===Abstract===\n\u003e\u003e\n\u003e\u003e This document proposes a mechanism to set up multisig wallets securely.\n\u003e\u003e\n\u003e\u003e ===Copyright===\n\u003e\u003e\n\u003e\u003e This BIP is licensed under the 2-clause BSD license.\n\u003e\u003e\n\u003e\u003e ===Motivation===\n\u003e\u003e\n\u003e\u003e The Bitcoin multisig experience has been greatly streamlined under [\n\u003e\u003e https://github.com/bitcoin/bips/blob/master/bip-0174.mediawiki BIP-0174\n\u003e\u003e (Partially Signed Bitcoin Transaction)]. However, what is still missing is\n\u003e\u003e a standardized process for setting up multisig wallets securely across\n\u003e\u003e different vendors.\n\u003e\u003e\n\u003e\u003e There are a number of concerns when it comes to setting up a multisig\n\u003e\u003e wallet:\n\u003e\u003e\n\u003e\u003e # Whether the multisig configuration, such as Signer membership, script\n\u003e\u003e type, derivation paths and number of signatures required, is correct and\n\u003e\u003e not tampered with.\n\u003e\u003e # Whether Signer persists the multisig configuration in their respective\n\u003e\u003e storage, and under what format.\n\u003e\u003e # Whether Signer's storage is tamper-proof.\n\u003e\u003e # Whether Signer subsequently uses the multisig configuration to generate\n\u003e\u003e and verify receive and change addresses.\n\u003e\u003e\n\u003e\u003e An attacker who can modify the multisig configuration can steal or hold\n\u003e\u003e funds to ransom by duping the user into sending funds to the wrong address.\n\u003e\u003e\n\u003e\u003e This proposal seeks to address concerns #1 and #2: to mitigate the risk\n\u003e\u003e of tampering during the initial setup phase, and to define an interoperable\n\u003e\u003e multisig configuration format.\n\u003e\u003e\n\u003e\u003e Concerns #3 and #4 should be handled by Signers and is out of scope of\n\u003e\u003e this proposal.\n\u003e\u003e\n\u003e\u003e ==Specification==\n\u003e\u003e\n\u003e\u003e ===Prerequisites===\n\u003e\u003e This proposal assumes the parties in the multisig support [\n\u003e\u003e https://github.com/bitcoin/bips/blob/master/bip-0032.mediawiki BIP32], [\n\u003e\u003e https://github.com/bitcoin/bitcoin/blob/master/doc/descriptors.md the\n\u003e\u003e descriptor language] and encryption.\n\u003e\u003e\n\u003e\u003e ==Roles==\n\u003e\u003e ===Coordinator===\n\u003e\u003e\n\u003e\u003e The Coordinator initiates the multisig setup. The Coordinator determines\n\u003e\u003e what type of multisig is used and how many members and signatures are\n\u003e\u003e needed. If encryption is enabled, the Coordinator generates a secret token,\n\u003e\u003e to be shared among the parties for secure communication. The Coordinator\n\u003e\u003e gathers information from the Signers to generate a descriptor record. The\n\u003e\u003e Coordinator distributes the descriptor record back to the Signers.\n\u003e\u003e\n\u003e\u003e ===Signer===\n\u003e\u003e\n\u003e\u003e The Signer is a participating member in the multisig. Its\n\u003e\u003e responsibilities include providing its XPUB to the Coordinator, verifying\n\u003e\u003e that its XPUB is included in the descriptor record and persisting the\n\u003e\u003e descriptor record in its storage.\n\u003e\u003e\n\u003e\u003e ==Setup Process==\n\u003e\u003e\n\u003e\u003e ===Round 1===\n\u003e\u003e\n\u003e\u003e ====Coordinator====\n\u003e\u003e\n\u003e\u003e * The Coordinator creates a multisig wallet creation session. The\n\u003e\u003e Coordinator determines the type of multisig script used and the signing\n\u003e\u003e configuration (\u003ctt\u003eM\u003c/tt\u003e and \u003ctt\u003eN\u003c/tt\u003e).\n\u003e\u003e * If encryption is enabled, the Coordinator also generates a secret\n\u003e\u003e token, hereby denoted \u003ctt\u003eTOKEN\u003c/tt\u003e.\n\u003e\u003e * TOKEN is in ASCII format and must have a minimum of 8 characters. TOKEN\n\u003e\u003e should expire after some time period determined by the Coordinator, e.g.,\n\u003e\u003e 24 hours.\n\u003e\u003e * TOKEN acts as an encryption key among the parties. The method of\n\u003e\u003e encryption is AES, CTR mode. The encryption key can be calculated by\n\u003e\u003e performing a double hash operation on the TOKEN: \u003ctt\u003eENCRYPTION_KEY =\n\u003e\u003e SHA256(SHA256(TOKEN))\u003c/tt\u003e.\n\u003e\u003e * A TOKEN value of \u003ctt\u003e-1\u003c/tt\u003e means that encryption is disabled and all\n\u003e\u003e the encryption/decryption steps below can be skipped.\n\u003e\u003e * The Coordinator shares the TOKEN with all participating Signers over a\n\u003e\u003e secure channel.\n\u003e\u003e\n\u003e\u003e ====Signer====\n\u003e\u003e\n\u003e\u003e * The Signer generates a key record by prompting the user for the TOKEN\n\u003e\u003e and a derivation path.\n\u003e\u003e * The first line in the record must be the \u003ctt\u003eTOKEN\u003c/tt\u003e. If encryption\n\u003e\u003e is disabled, set the TOKEN to -1. The second line must be the \u003ctt\u003eKEY\u003c/tt\u003e,\n\u003e\u003e whereas KEY is an XPUB. KEY must include key origin information and written\n\u003e\u003e in the descriptor-defined format, i.e.: \u003ctt\u003e[{master key\n\u003e\u003e fingerprint}/{derivation path}]{XPUB}\u003c/tt\u003e. The third line must be a\n\u003e\u003e \u003ctt\u003eSIG\u003c/tt\u003e, whereas SIG is the signature generated by using the\n\u003e\u003e corresponding private key to sign the first two lines. Finally, the Signer\n\u003e\u003e encrypts the entire record with ENCRYPTION_KEY.\n\u003e\u003e\n\u003e\u003e ===Round 2===\n\u003e\u003e\n\u003e\u003e ====Coordinator====\n\u003e\u003e\n\u003e\u003e * The Coordinator gathers key records from all participating Signers.\n\u003e\u003e Abort the setup if TOKEN has expired.\n\u003e\u003e * For each key record, the Coordinator decrypts it using ENCRYPTION_KEY.\n\u003e\u003e The Coordinator verifies that the included SIG is valid given the KEY.\n\u003e\u003e * If all key records look good, the Coordinator generates a descriptor\n\u003e\u003e record, which is simply the descriptor string plus a \u003ctt\u003eCHECKSUM\u003c/tt\u003e, all\n\u003e\u003e in one line. The CHECKSUM has BECH32 encoding and is described at [\n\u003e\u003e https://github.com/bitcoin/bitcoin/blob/master/doc/descriptors.md#checksums].\n\u003e\u003e The Coordinator encrypts this descriptor record with ENCRYPTION_KEY.\n\u003e\u003e * The Coordinator sends the encrypted descriptor record to all\n\u003e\u003e participating Signers.\n\u003e\u003e\n\u003e\u003e ====Signer====\n\u003e\u003e\n\u003e\u003e * The Signer imports the descriptor record, decrypts it by prompting the\n\u003e\u003e user for TOKEN.\n\u003e\u003e * The Signer calculates and verifies the descriptor’s CHECKSUM. Abort the\n\u003e\u003e setup if the CHECKSUM is incorrect.\n\u003e\u003e * The Signer checks whether one of the KEYs in the descriptor belongs to\n\u003e\u003e it, using path and fingerprint information included in the descriptor. The\n\u003e\u003e check must perform an exact match on the KEYs, and not using shortcuts such\n\u003e\u003e as matching fingerprints (which is trivial to spoof). Abort the setup if it\n\u003e\u003e doesn’t detect its own KEY.\n\u003e\u003e * For confirmation, the Signer must display to the user the descriptor's\n\u003e\u003e CHECKSUM, plus other configurations, such as M and N. The total number of\n\u003e\u003e Signers, N, is important to prevent a KEY insertion attack. All\n\u003e\u003e participating Signers should be able to display the same confirmation.\n\u003e\u003e * If all checks pass, the Signer persists the descriptor record in its\n\u003e\u003e storage. The Signer should subsequently use the descriptor to generate and\n\u003e\u003e verify receive and change addresses.\n\u003e\u003e\n\u003e\u003e This completes the setup.\n\u003e\u003e\n\u003e\u003e ==QR Codes==\n\u003e\u003e For signers that use QR codes to transmit data, key and descriptor\n\u003e\u003e records can be converted to QR codes, following [\n\u003e\u003e https://github.com/BlockchainCommons/Research/blob/master/papers/bcr-2020-005-ur.md\n\u003e\u003e the BCR standard].\n\u003e\u003e\n\u003e\u003e ==Security==\n\u003e\u003e\n\u003e\u003e This proposal introduce two layers of protection. The first one is a\n\u003e\u003e temporary, secret token, used to encrypt the two rounds of communication\n\u003e\u003e between the Signers and the Coordinator. The second one is through the\n\u003e\u003e descriptor checksum and visual inspection of the descriptor itself.\n\u003e\u003e\n\u003e\u003e The token is only needed during the setup phase, and can be safely thrown\n\u003e\u003e away afterwards. The token does not guarantee that the Signer membership\n\u003e\u003e set is not modified, since that depends on the overall security of all\n\u003e\u003e parties in the setup, but it can make it significantly harder for an\n\u003e\u003e attacker to do so.\n\u003e\u003e\n\u003e\u003e There are three ways an attacker can modify the membership set: by\n\u003e\u003e changing an existing member, by removing an existing member, or by adding a\n\u003e\u003e new member.\n\u003e\u003e\n\u003e\u003e For the first two methods, one of the Signers will be able to detect that\n\u003e\u003e its membership has been changed or removed, and reject the final\n\u003e\u003e descriptor. Thus, it is vital that all participating Signers check that\n\u003e\u003e their membership is intact in the descriptor. Even one Signer failing to\n\u003e\u003e check for its membership means that the setup could be compromised.\n\u003e\u003e\n\u003e\u003e For the third type of attack, the descriptor checksum and visual\n\u003e\u003e inspection of the descriptor itself are the only way to guard against\n\u003e\u003e malicious members from being inserted into the set.\n\u003e\u003e _______________________________________________\n\u003e\u003e bitcoin-dev mailing list\n\u003e\u003e bitcoin-dev at lists.linuxfoundation.org\n\u003e\u003e https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev\n\u003e\u003e\n\u003e\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: \u003chttp://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20210209/0796efc1/attachment-0001.html\u003e"}