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
170
171
172
173
174
175
176
177
178
179
180
181
182
183
|
Return-Path: <achow101-lists@achow101.com>
Received: from hemlock.osuosl.org (smtp2.osuosl.org [140.211.166.133])
by lists.linuxfoundation.org (Postfix) with ESMTP id 1D07AC077D
for <bitcoin-dev@lists.linuxfoundation.org>;
Mon, 13 Jan 2020 06:39:37 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
by hemlock.osuosl.org (Postfix) with ESMTP id 074D986DEE
for <bitcoin-dev@lists.linuxfoundation.org>;
Mon, 13 Jan 2020 06:39:37 +0000 (UTC)
X-Virus-Scanned: amavisd-new at osuosl.org
Received: from hemlock.osuosl.org ([127.0.0.1])
by localhost (.osuosl.org [127.0.0.1]) (amavisd-new, port 10024)
with ESMTP id sKDbfKh++ic0
for <bitcoin-dev@lists.linuxfoundation.org>;
Mon, 13 Jan 2020 06:39:35 +0000 (UTC)
X-Greylist: from auto-whitelisted by SQLgrey-1.7.6
Received: from mail2.protonmail.ch (mail2.protonmail.ch [185.70.40.22])
by hemlock.osuosl.org (Postfix) with ESMTPS id 34A6786DEA
for <bitcoin-dev@lists.linuxfoundation.org>;
Mon, 13 Jan 2020 06:39:35 +0000 (UTC)
Date: Mon, 13 Jan 2020 06:39:28 +0000
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=achow101.com;
s=protonmail; t=1578897572;
bh=YVB7QjkrymjhGCgF3XLSh7r9bMRfEUi/vBrnXtnv6Q8=;
h=Date:To:From:Cc:Reply-To:Subject:In-Reply-To:References:
Feedback-ID:From;
b=pgd9Z6MduO7+JRO3MWuaOQW0DeODb7DITMUJV7rcSgCBBzaPjsvSABiHnuE6ifijS
G0Z9P/27nOnbYVQqbsCNLNLCaX8nAWKT+IGyyIwTTY41AkopcT2QihnpR8bIQYeLdf
tNGnOraBDdAAvGp7xP1gECMBZLBQH1Ac9pUgdj+Y=
To: Dmitry Petukhov <dp@simplexum.com>,
Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
From: Andrew Chow <achow101-lists@achow101.com>
Reply-To: Andrew Chow <achow101-lists@achow101.com>
Message-ID: <78dbbce2-0372-2516-489f-ed6e839b1a6f@achow101.com>
In-Reply-To: <20200112011705.6f6102dd@simplexum.com>
References: <20200111172906.GO10797@coinkite.com>
<20200112011705.6f6102dd@simplexum.com>
Feedback-ID: VjS95yl5HLFwBfNLRqi61OdL1ERZPmvMbZRH2ZcBR7SKVUVYPgv7VJsV9uoyC4vIfjYnW8hPXGuLTycZbh49Zw==:Ext:ProtonMail
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
Cc: Peter Gray <peter@coinkite.com>
Subject: Re: [bitcoin-dev] PSBT Addition (BIP 174) for authenticating
source/output PSBT files
X-BeenThere: bitcoin-dev@lists.linuxfoundation.org
X-Mailman-Version: 2.1.15
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: Mon, 13 Jan 2020 06:39:37 -0000
I agree with Dimitry. I don't see the point of having the MiTM
protection within the PSBT structure itself, in addition to the fact
that adding new fields is largely unnecessary. In fact, I'm not quite
sure what kind of attack you are trying to defend against with this
proposal.
If there is a MiTM who can modify your PSBT, then they can just modify
the result the signed PSBT to drop the auth signatures. Furthermore, any
modifications to scripts or UTXOs would just result in an invalid
signature, so only time is wasted. But you'll just waste time anyways
when you see a failed auth sig.
Additionally, when a signer processes a PSBT, it will either accept the
PSBT and add a signature for its inputs, or reject it and do nothing.
Given this behavior (and I assume you aren't going to add auth sigs for
rejected PSBTs because that doesn't make any sense), then you already
have a signature there that covers everything your auth signature would
cover. So just verify those signatures instead; for any inputs with
signatures, everything you need to verify them are already there.
Lastly, IMO, if you want MiTM protection, then you should do your
protection with out of band communication. Just PGP sign the PSBT (or
something similar) and send the signature along separately.
Andrew
On 1/11/20 3:17 PM, Dmitry Petukhov via bitcoin-dev wrote:
>=20
> I am not sure that this particular task should be done with data
> embedded in PSBT itself, and not with some sort of container that
> includes PSBT and the authentication information.
>=20
> The benefit seems to be in reusing PSBT structure for compatibilty, and
> this might be a valid way, although I do not agree with some of your
> points. I elaborate below:
>=20
>> 1) In the PSBT globals section, a signature over the "source" PSBT
>> file. It would cover all the bytes of the original PSBT file, as
>> it was received by the Signer.
>=20
> The problem of authenticating the contents of PSBT is independent of
> the signing action. PSBT might be altered on the path from Creator to
> Signer. Therefore you cannot always say that Signer will be an
> authority over 'correctness' of PSBT.
>=20
>> - At the end of the signing process, the Finalizer should check all
>> the Signers have worked from the same PSBT file (assuming that's
>> the flow expected)
>=20
> If there is MitM, checking something at Finalizer is likely too
> late - the party that can intercept PSBTs can finalize before the
> legitimate Finalizer and broadcast the transaction.
>=20
> Participants can work from the same PSBT file if they all receive the
> same PSBT, and not working in chain where next particpant receives
> updated PSBT from the previous participant. Otherwise they will need to
> either pass two files (original and updated), or work out which fields
> (key-value blobs) to remove to get the 'source' PSBT (which might not be
> trivial with presense of proprietary and unknown fields). Even if you
> know which key-value pairs to remove, there is no requirement for
> ordering of the fields, and some signer can serialize them in different
> order after dserialize/sign/add-signatures/re-serialize operation.
>=20
> Introducing additional ordering or other structure requirements over
> simple key-value structure will add complexity to PSBT processing, and
> adding complexity on such a basic level should have really serious
> reasons, because that increases effort required for even basic
> implementations and increases chance of bugs.
>=20
> If there is some authority on the 'correctness' of 'original' PSBT
> (all particpants receive same PSBT at the start), particpants should
> check the signature by that authority. That authority might use
> the key used only for authentication, and not in the tx signing.
>=20
> If particpants send PSBT in chain after adding their signatures, then
> each participant can add their signature to say 'the contents
> of PSBT after my updates should match this hash'.
>=20
> The signatures of previous participants in the chain most likely do not
> matter because of difficulty of restoring the contents of PSBT as it
> was before the previous particpant, if you do not pass _all_ the PSBTs
> (which is excessive).
>=20
>> 2) In the output section, specifically, the last key/value pair of
>> the last output of the transaction, I want to add a similar signature,
>> again signed by one of the keys used in the signing process. This
>> signature will cover all the bytes of the resulting (signed) PSBT
>> up to that point. Because it is the last output of the output
>> section, that signature will be the last few bytes of the PSBT file.
>> By "appending" the signature in this way, it's easier to validate
>> and create the signature, without blanking the signature area during
>> digest step.
>=20
> This will introduce unnecessary higher-level structure to PSBT for the
> reasons that I do not find strong enough for the amount of complexity
> added.
>=20
> Also, as I said above, you likely do not need more than one
> signature - if this is 'fan-out' scheme, then participants need do
> check the sig of authority that created PSBT; if this is piggy-back
> chain, then only previous particpant's signature is easily verifiable.
>=20
>> ## Next Steps
>>
>> I'd like to get two officially-assigned BIP-174 key numbers assigned
>> for these two signatures, and then I will see that it gets added
>> into Coldcard's firmware immediately. In time, other tools are
>> welcome to take advantage of these checks. I will also write a BIP
>> for this, and/or make an addition to BIP-174.
>=20
> I think you do not need to wait for officially-assigned key numbers,
> and can just implement the scheme you envision with proprietary keys,
> document and promote it. Then if it shows its usefulness, it will
> either become de-facto standard with your proprietary keys (and
> everyone will want to support 'Coldard PSBT auth' or whatever the name),
> or the scheme will have serious grounds to be converted to standard and
> have non-proprietary keys assigned.
>=20
> // Dmitry.
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>=20
|
