đź“… Original date posted:2021-04-10
đź“ť Original message: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 at 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 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 <hugo at nunchuk.io>, Peter Gray <peter at coinkite.com>, Marko Bencun <marko at shiftcrypto.ch>, 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>
>
> ==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
> bitcoin-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
Erik Aronesty [ARCHIVE] /
npub1y2…5taj0
2023-06-07 22:51:19
in reply to nevent1q…nn8d
Author Public Key
npub1y22yec0znyzw8qndy5qn5c2wgejkj0k9zsqra7kvrd6cd6896z4qm5taj0Published at
2023-06-07 22:51:19Event JSON
{
"id": "f60549a2e3de146cbb74716790d50f2df0d99ba3b1e5eeb29ac893cc684057ec",
"pubkey": "22944ce1e29904e3826d25013a614e4665693ec514003efacc1b7586e8e5d0aa",
"created_at": 1686178279,
"kind": 1,
"tags": [
[
"e",
"f86c661936c3e6f7931e28ea97f181b1cc63a558750c07531fcca84c0c1b78c4",
"",
"root"
],
[
"e",
"28631a07ce4a7d8037c2b487c1718088009f607f94cf91f7e73c2a4776bae837",
"",
"reply"
],
[
"p",
"931a6829f7e5cb4e97113f9e9c9b91597fea65dd5df324f02e5687e9c7973d7d"
]
],
"content": "📅 Original date posted:2021-04-10\n📝 Original message:here's what we do for multisig:\n\n- each member generates their own public/private key pair first and\npublishes the pair to all other members\n- members are then verified using a secondary channel, like a phone\ncall ... where the H128(pubk) is turned into BIP-words for\nmanual/visual verification\n- multi-round DKG is used with appropriate commitments and\nverification of components (nice article:\nhttps://link.springer.com/content/pdf/10.1007/s00145-006-0347-3.pdf)\n\nwithout that, there's simply no guarantee that you're not\ncommunicating with an attacker during setup.\n\nOn Tue, Feb 9, 2021 at 2:53 AM Hugo Nguyen via bitcoin-dev\n\u003cbitcoin-dev at lists.linuxfoundation.org\u003e wrote:\n\u003e\n\u003e Hi all,\n\u003e I would like to propose a new BIP for Secure Multisig Setup.\n\u003e This proposal has taken inputs from folks at Coldcard, Shift Crypto and Cobo -- listed below as co-authors.\n\u003e\n\u003e This was inspired by my own experience working with hardware wallets on the market, as well as existing research into the challenges of multisig.\n\u003e\n\u003e Cheers,\n\u003e Hugo\n\u003e\n\u003e \u003cpre\u003e\n\u003e BIP: To be determined\n\u003e Layer: Applications\n\u003e Title: Bitcoin Secure Multisig Setup (BSMS)\n\u003e Author: Hugo Nguyen \u003chugo at nunchuk.io\u003e, Peter Gray \u003cpeter at coinkite.com\u003e, Marko Bencun \u003cmarko at shiftcrypto.ch\u003e, Aaron Chen \u003caarondongchen at gmail.com\u003e, Rodolfo Novak \u003crodolfo at coinkite.com\u003e\n\u003e Comments-Summary: No comments yet.\n\u003e Comments-URI:\n\u003e Status: Proposed\n\u003e Type: Standards Track\n\u003e Created: 2020-11-10\n\u003e License: BSD-2-Clause\n\u003e \u003c/pre\u003e\n\u003e\n\u003e ==Introduction==\n\u003e\n\u003e ===Abstract===\n\u003e\n\u003e This document proposes a mechanism to set up multisig wallets securely.\n\u003e\n\u003e ===Copyright===\n\u003e\n\u003e This BIP is licensed under the 2-clause BSD license.\n\u003e\n\u003e ===Motivation===\n\u003e\n\u003e 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.\n\u003e\n\u003e There are a number of concerns when it comes to setting up a multisig wallet:\n\u003e\n\u003e # Whether the multisig configuration, such as Signer membership, script type, derivation paths and number of signatures required, is correct and not tampered with.\n\u003e # Whether Signer persists the multisig configuration in their respective storage, and under what format.\n\u003e # Whether Signer's storage is tamper-proof.\n\u003e # Whether Signer subsequently uses the multisig configuration to generate and verify receive and change addresses.\n\u003e\n\u003e 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.\n\u003e\n\u003e 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.\n\u003e\n\u003e Concerns #3 and #4 should be handled by Signers and is out of scope of this proposal.\n\u003e\n\u003e ==Specification==\n\u003e\n\u003e ===Prerequisites===\n\u003e 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.\n\u003e\n\u003e ==Roles==\n\u003e ===Coordinator===\n\u003e\n\u003e 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.\n\u003e\n\u003e ===Signer===\n\u003e\n\u003e 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.\n\u003e\n\u003e ==Setup Process==\n\u003e\n\u003e ===Round 1===\n\u003e\n\u003e ====Coordinator====\n\u003e\n\u003e * The Coordinator creates a multisig wallet creation session. The Coordinator determines the type of multisig script used and the signing configuration (\u003ctt\u003eM\u003c/tt\u003e and \u003ctt\u003eN\u003c/tt\u003e).\n\u003e * If encryption is enabled, the Coordinator also generates a secret token, hereby denoted \u003ctt\u003eTOKEN\u003c/tt\u003e.\n\u003e * 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.\n\u003e * 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: \u003ctt\u003eENCRYPTION_KEY = SHA256(SHA256(TOKEN))\u003c/tt\u003e.\n\u003e * A TOKEN value of \u003ctt\u003e-1\u003c/tt\u003e means that encryption is disabled and all the encryption/decryption steps below can be skipped.\n\u003e * The Coordinator shares the TOKEN with all participating Signers over a secure channel.\n\u003e\n\u003e ====Signer====\n\u003e\n\u003e * The Signer generates a key record by prompting the user for the TOKEN and a derivation path.\n\u003e * The first line in the record must be the \u003ctt\u003eTOKEN\u003c/tt\u003e. If encryption is disabled, set the TOKEN to -1. The second line must be the \u003ctt\u003eKEY\u003c/tt\u003e, whereas KEY is an XPUB. KEY must include key origin information and written in the descriptor-defined format, i.e.: \u003ctt\u003e[{master key fingerprint}/{derivation path}]{XPUB}\u003c/tt\u003e. The third line must be a \u003ctt\u003eSIG\u003c/tt\u003e, 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.\n\u003e\n\u003e ===Round 2===\n\u003e\n\u003e ====Coordinator====\n\u003e\n\u003e * The Coordinator gathers key records from all participating Signers. Abort the setup if TOKEN has expired.\n\u003e * For each key record, the Coordinator decrypts it using ENCRYPTION_KEY. The Coordinator verifies that the included SIG is valid given the KEY.\n\u003e * If all key records look good, the Coordinator generates a descriptor record, which is simply the descriptor string plus a \u003ctt\u003eCHECKSUM\u003c/tt\u003e, 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.\n\u003e * The Coordinator sends the encrypted descriptor record to all participating Signers.\n\u003e\n\u003e ====Signer====\n\u003e\n\u003e * The Signer imports the descriptor record, decrypts it by prompting the user for TOKEN.\n\u003e * The Signer calculates and verifies the descriptor’s CHECKSUM. Abort the setup if the CHECKSUM is incorrect.\n\u003e * 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.\n\u003e * 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.\n\u003e * 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.\n\u003e\n\u003e This completes the setup.\n\u003e\n\u003e ==QR Codes==\n\u003e 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].\n\u003e\n\u003e ==Security==\n\u003e\n\u003e 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.\n\u003e\n\u003e 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.\n\u003e\n\u003e 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.\n\u003e\n\u003e 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.\n\u003e\n\u003e 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.\n\u003e _______________________________________________\n\u003e bitcoin-dev mailing list\n\u003e bitcoin-dev at lists.linuxfoundation.org\n\u003e https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev",
"sig": "5d5bd95300012001c76c3609fb478026fd15eac537460ff6df30278159207118a84f271f79cc0276af51fc15b543e61444f2e60c8b063fbe5fc20cc7ed6408d7"
}