From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org [172.17.192.35]) by mail.linuxfoundation.org (Postfix) with ESMTPS id B2DD82865 for ; Fri, 26 Apr 2019 15:21:19 +0000 (UTC) X-Greylist: whitelisted by SQLgrey-1.7.6 Received: from mail-qt1-f179.google.com (mail-qt1-f179.google.com [209.85.160.179]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 17B1682A for ; Fri, 26 Apr 2019 15:21:19 +0000 (UTC) Received: by mail-qt1-f179.google.com with SMTP id g4so4460858qtq.10 for ; Fri, 26 Apr 2019 08:21:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:from:date:message-id:subject:to; bh=qaIkZy/Mdh/ze8IVSgqYWFW5dZfR3d/K4J81j5oMfXY=; b=o5k8SwCyV0he3bOwTfTrDfRRVUyx5NKvqMzqXCTnQBQhljkMX7R68EV55PL1Blb1Y2 wn+C0boYZRQw9+38GKNuafeM9Bj86RCpGmou2g0nd4aIJ9hParayJ+D9RfHeoG9Gkapp sQT+99D82aedVUKOFfnraop8sXF/PcrAt6orZS8XGeuug42AAkHZ11KyRBkD+ndu7ypB 1Zsk0rTfaT1Ij1GP/2pi/ybUAhG8ByrRsp15W9T9QbbvN4LLox5qNeBbGO13VB5g5Zpt 7fVqY6Wn/u4L9QGYlZVQHx+DFApfjoMSjSuyLKh8zQACfKt2R4rBAr4jXwSkzaAhmTjw LFrw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=qaIkZy/Mdh/ze8IVSgqYWFW5dZfR3d/K4J81j5oMfXY=; b=asYu+GC+dG9g0oh1Blah6xzEfny5UtWZv2khJStlRmU/2370Z0Lz6O5IggcfTy1BHL JdH/KM4paQD6GZ8JFbqsRi8DEQq2tRk4/LsIvYfbTOPk1epWeZ+mqo7ZrK8FcDmsjJ0h DhB6zxD7eKbzuvdjGQ6nuAU11XZDJeYeBKBYKk1OTDjEYP6CV9sdEB8yY/Qdiwlg513g /v3lNlRT/WxPZc2ohRAUPlaZGqxpnNapFrr9VVYTOmkGom+23ANVWZfPioKirXZGkQOW DsMIEe6PoTakJ1NmnaR3AntcBtxWx1Tt4ND/8dk2xgl5rj07y89od9efqUJBG/Y/FNeN Wv8w== X-Gm-Message-State: APjAAAVbW81FXIuHZQSGP+eUjklddh1BKTsDdL6AAoaz0j/f8KrCXhXC y3SKXJEMsAyWvKQN4U8JT6atgwbCvbcEb1DwPyNsXLdQeQk= X-Google-Smtp-Source: APXvYqwuCwREP8r/g5n72uzdnrokkgmtY97QyQax/LUnGOAyh5Sd7v8zHu4XmaPnd6IYYtjNvofNeOOybYb7eB6lCNo= X-Received: by 2002:ac8:614b:: with SMTP id d11mr8786802qtm.280.1556292077778; Fri, 26 Apr 2019 08:21:17 -0700 (PDT) MIME-Version: 1.0 From: Stepan Snigirev Date: Fri, 26 Apr 2019 17:21:06 +0200 Message-ID: To: bitcoin-dev@lists.linuxfoundation.org Content-Type: multipart/alternative; boundary="000000000000767b9e0587707c60" X-Spam-Status: No, score=-2.0 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, FREEMAIL_FROM, HTML_MESSAGE, RCVD_IN_DNSWL_NONE autolearn=ham version=3.3.1 X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on smtp1.linux-foundation.org X-Mailman-Approved-At: Sat, 27 Apr 2019 04:05:30 +0000 Subject: [bitcoin-dev] Adding xpub field to PSBT to make multisig more secure X-BeenThere: bitcoin-dev@lists.linuxfoundation.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Bitcoin Protocol Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 26 Apr 2019 15:21:19 -0000 --000000000000767b9e0587707c60 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi list, I was looking at the bip174 PSBT specs, in particular for multisignature setup, and I think with current spec there is a way to steal user funds in M of N setup with M =E2=89=A4 N/2. I made a small write-up on this: https://github.com/stepansnigirev/random_notes/blob/master/psbt_multisig.md To compress: Currently in PSBT there is no way to reliably say if the output uses the keys derived from the same root keys as the inputs aside from the key owned by the signer =3D> there is no way to verify that the output is a change output in multisig setup. Therefore an attacker can replace half of the keys in the change address by his own keys and still get the transaction signed. I suggest to add an xpub field to the inputs and outputs metadata, then signers can verify that the same xpubs are used for public keys in inputs and outputs =3D> output is indeed a change. Normally change and receiving addresses are derived from the same xpub with non-hardened derivation pathes, so providing xpub after the last hardened index should be enough to see that public keys of inputs and change output are derived from the same xpub. I suggest to add the following key-value pairs to PSBT: Type: BIP 32 public key `PSBT_IN_BIP32_XPUB =3D 0x10` - Key: derivation path for xpub `{0x10}|{master key fingerprint}|{32-bit int}|...|{32-bit int}` - Value: 78-byte xpub value `{xpub}` Type: BIP 32 public key `PSBT_OUT_BIP32_XPUB =3D 0x03` - Key: derivation path for xpub `{0x03}|{master key fingerprint}|{32-bit int}|...|{32-bit int}` - Value: 78-byte xpub value `{xpub}` Derivation paths are in the key of the key-value pair as they are used for lookup, and xpub itself is the actual value being looked up. I also want to mention that Trezor for example doesn't suffer from this problem as they use xpubs to verify change outputs. So it may make sense to go through the communication protocols of existing hardware / multisignature wallets and see if there is something else we are missing. If everyone is happy about the proposal I would prepare a pull request to the bip. Best regards, Stepan Snigirev. --000000000000767b9e0587707c60 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi list,

I = was looking at the bip174 PSBT specs, in particular for multisignature setu= p, and I think with current spec there is a way to steal user funds in M of= N setup with M =E2=89=A4 N/2.


To compress:
=

Currently in PSBT there is no way to reliably say if th= e output uses the keys derived from the same root keys as the inputs aside = from the key owned by the signer =3D> there is no way to verify that the= output is a change output in multisig setup.

Ther= efore an attacker can replace half of the keys in the change address by his= own keys and still get the transaction signed.

I = suggest to add an xpub field to the inputs and outputs metadata, then signe= rs can verify that the same xpubs are used for public keys in inputs and ou= tputs =3D> output is indeed a change.

Normally = change and receiving addresses are derived from the same xpub with non-hard= ened derivation pathes, so providing xpub after the last hardened index sho= uld be enough to see that public keys of inputs and change output are deriv= ed from the same xpub.

I suggest to add the follow= ing key-value pairs to PSBT:

Type: BIP 32 public k= ey `PSBT_IN_BIP32_XPUB =3D 0x10`
- Key: derivation path for xpub<= /div>
=C2=A0 `{0x10}|{master key fingerprint}|{32-bit int}|...|{32-bit = int}`
- Value: 78-byte xpub value
=C2=A0 `{xpub}`
=

Type: BIP 32 public key `PSBT_OUT_BIP32_XPUB =3D 0x03`<= /div>
- Key: derivation path for xpub
=C2=A0 `{0x03}|{master = key fingerprint}|{32-bit int}|...|{32-bit int}`
- Value: 78-byte = xpub value
=C2=A0 `{xpub}`

Derivation pa= ths are in the key of the key-value pair as they are used for lookup, and x= pub itself is the actual value being looked up.

I = also want to mention that Trezor for example doesn't suffer from this p= roblem as they use xpubs to verify change outputs. So it may make sense to = go through the communication protocols of existing hardware / multisignatur= e wallets and see if there is something else we are missing.=C2=A0

If everyone is happy about the proposal I would prepar= e a pull request to the bip.

Best regards,
Stepan Snigirev.

--000000000000767b9e0587707c60--