Author: Michael.flaxman 2021-04-11 02:34:21
Published on: 2021-04-11T02:34:21+00:00
A proposed Bitcoin Secure Multisig Setup (BSMS) BIP has been drafted to set up multisig wallets securely and address concerns surrounding tampering during initial setup. The BIP proposes the use of PBKDF2-SHA512 for the key derivation function and a standardized process for setting up multisig wallets across different vendors. However, Michael Flaxman, an expert in multisig security, has raised concerns about the proposed BIP, stating that it doesn't improve the 10x security guide's most commonly raised issues on verifying hardware wallets and risks for stateless hardware wallets. He further suggests using a checksum with much higher entropy to reduce xpub validation and create a better user experience for signers. The current BIP does not address these issues and will negatively impact multisig adoption if adopted in its current form.This proposal outlines the process for creating a multisig wallet using encryption to improve privacy. The Signer initiates the wallet creation session by setting a TOKEN and derives an ENCRYPTION_KEY from it. They then generate a key record, which includes the XPUB and its key origin information, a text description of the key, and a signature generated by using the private key associated with the XPUB to sign the first four lines. The record is encrypted with the ENCRYPTION_KEY and Message Authentication Code (MAC), which serves as the Initialization Vector (IV) for the encryption. The Coordinator gathers key records from all participating Signers and verifies their validity before generating a descriptor record. The descriptor record includes a comma-separated list of accepted derivation paths and a descriptor string plus a CHECKSUM, all in one line. The Coordinator encrypts the descriptor record with the ENCRYPTION_KEY and IV and sends it to all participating Signers. The Signer then imports the descriptor record and verifies its compatibility with their system. They also verify that the KEY is included in the descriptor, using path and fingerprint information provided, and display all necessary information to confirm the setup. Encryption can be disabled or set to STANDARD or EXTENDED mode using the TOKEN, which can be converted to a decimal number, mnemonic phrase, QR code, or other formats.The context provided consists of two rounds of information exchange between a coordinator and two signers, with the aim of creating a multisignature wallet. The first round takes place in STANDARD Encryption mode, while the second round involves the generation of a legacy signature. In the first round, the coordinator sets up a 2-of-2 multisig wallet with native segwit address type, using a token (hexadecimal, decimal, and mnemonic representations provided) and an encryption key (hex). Signer 1 and Signer 2 then provide their master key fingerprints, private keys, and extended public keys (xpubs), along with their respective legacy signatures and BSMS 1.0 files containing the required data. Both signers also encrypt their private keys using shared HMAC keys (hex) and initialization vectors (IVs) which they derive from the encryption key. The encrypted keys and associated MAC values are stored in files named after the signer's key. In the second round, the coordinator creates a new multisig wallet using a sortedmulti script that requires both Signer 1's and Signer 2's public keys from their xpubs. The context includes a multisignature wallet that needs to be signed by three signers. Each signer is provided with specific details including HMAC key, MAC, IV, ciphertext and a data file.
Updated on: 2023-06-14T17:30:15.216098+00:00