1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
|
Return-Path: <snigirev.stepan@gmail.com>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
[172.17.192.35])
by mail.linuxfoundation.org (Postfix) with ESMTPS id B2DD82865
for <bitcoin-dev@lists.linuxfoundation.org>;
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 <bitcoin-dev@lists.linuxfoundation.org>;
Fri, 26 Apr 2019 15:21:19 +0000 (UTC)
Received: by mail-qt1-f179.google.com with SMTP id g4so4460858qtq.10
for <bitcoin-dev@lists.linuxfoundation.org>;
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 <snigirev.stepan@gmail.com>
Date: Fri, 26 Apr 2019 17:21:06 +0200
Message-ID: <CACL8y1v9fpZ+gWLVHMx-bGUCaSd0=0ecHU-u4FF=LnhT7s1zTg@mail.gmail.com>
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 <bitcoin-dev.lists.linuxfoundation.org>
List-Unsubscribe: <https://lists.linuxfoundation.org/mailman/options/bitcoin-dev>,
<mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=unsubscribe>
List-Archive: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/>
List-Post: <mailto:bitcoin-dev@lists.linuxfoundation.org>
List-Help: <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=help>
List-Subscribe: <https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev>,
<mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=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
<div dir=3D"ltr"><div dir=3D"ltr"><div>Hi list,</div><div><br></div><div>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.</div><div><br></div><div>I made a small writ=
e-up on this: <a href=3D"https://github.com/stepansnigirev/random_notes/blo=
b/master/psbt_multisig.md">https://github.com/stepansnigirev/random_notes/b=
lob/master/psbt_multisig.md</a></div><div><br></div><div>To compress:</div>=
<div><br></div><div>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.</div><div><br></div><div>Ther=
efore an attacker can replace half of the keys in the change address by his=
own keys and still get the transaction signed.</div><div><br></div><div>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.</div><div><br></div><div>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.</div><div><br></div><div>I suggest to add the follow=
ing key-value pairs to PSBT:</div><div><br></div><div>Type: BIP 32 public k=
ey `PSBT_IN_BIP32_XPUB =3D 0x10`</div><div>- Key: derivation path for xpub<=
/div><div>=C2=A0 `{0x10}|{master key fingerprint}|{32-bit int}|...|{32-bit =
int}`</div><div>- Value: 78-byte xpub value</div><div>=C2=A0 `{xpub}`</div>=
<div><br></div><div>Type: BIP 32 public key `PSBT_OUT_BIP32_XPUB =3D 0x03`<=
/div><div>- Key: derivation path for xpub</div><div>=C2=A0 `{0x03}|{master =
key fingerprint}|{32-bit int}|...|{32-bit int}`</div><div>- Value: 78-byte =
xpub value</div><div>=C2=A0 `{xpub}`</div><div><br></div><div>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.</div><div><br></div><div>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<br></div=
><div><br></div><div>If everyone is happy about the proposal I would prepar=
e a pull request to the bip.</div><div><br></div><div>Best regards,</div><d=
iv>Stepan Snigirev.</div><div><br></div></div></div>
--000000000000767b9e0587707c60--
|
