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
|
Return-Path: <peter@coinkite.com>
Received: from silver.osuosl.org (smtp3.osuosl.org [140.211.166.136])
by lists.linuxfoundation.org (Postfix) with ESMTP id E634DC0881
for <bitcoin-dev@lists.linuxfoundation.org>;
Sat, 11 Jan 2020 17:36:48 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
by silver.osuosl.org (Postfix) with ESMTP id D512420335
for <bitcoin-dev@lists.linuxfoundation.org>;
Sat, 11 Jan 2020 17:36:48 +0000 (UTC)
X-Virus-Scanned: amavisd-new at osuosl.org
Received: from silver.osuosl.org ([127.0.0.1])
by localhost (.osuosl.org [127.0.0.1]) (amavisd-new, port 10024)
with ESMTP id 45GG3NlwJdY5
for <bitcoin-dev@lists.linuxfoundation.org>;
Sat, 11 Jan 2020 17:36:47 +0000 (UTC)
X-Greylist: delayed 00:07:39 by SQLgrey-1.7.6
Received: from smtp81.ord1c.emailsrvr.com (smtp81.ord1c.emailsrvr.com
[108.166.43.81])
by silver.osuosl.org (Postfix) with ESMTPS id 90CCF20334
for <bitcoin-dev@lists.linuxfoundation.org>;
Sat, 11 Jan 2020 17:36:47 +0000 (UTC)
X-Auth-ID: peter@coinkite.com
Received: by smtp3.relay.ord1c.emailsrvr.com (Authenticated sender:
peter-AT-coinkite.com) with ESMTPSA id 77051A00DE;
Sat, 11 Jan 2020 12:29:07 -0500 (EST)
X-Sender-Id: peter@coinkite.com
Received: from coinkite.com ([UNAVAILABLE]. [216.223.129.56])
(using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384)
by 0.0.0.0:465 (trex/5.7.12); Sat, 11 Jan 2020 12:29:07 -0500
Date: Sat, 11 Jan 2020 12:29:06 -0500
From: "Peter D. Gray" <peter@coinkite.com>
To: bitcoin-dev@lists.linuxfoundation.org
Message-ID: <20200111172906.GO10797@coinkite.com>
Reply-To: Peter Gray <peter@coinkite.com>
MIME-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha512;
protocol="application/pgp-signature"; boundary="d6Gm4EdcadzBjdND"
Content-Disposition: inline
Organization: Coinkite Inc. (www.coinkite.com)
X-Mailman-Approved-At: Sat, 11 Jan 2020 17:43:16 +0000
Subject: [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: Sat, 11 Jan 2020 17:36:49 -0000
--d6Gm4EdcadzBjdND
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
## Background
PSBT files in transit are at risk of MiTM changes. This isn't
supposed to matter, but as another layer of defence, I would like
to add two signatures to PSBT files when they are processed by the
PSBT Signer. These additional fields would be optional, and should
pass through existing PSBT processors transparently, assuming they
pass unknown key/values as BIP-174 specifies.
## Additional Key/Values
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. The key used for the signature may
be any one the keys that the Signer applied during its transaction
signing process. (This is flexible so that the Signer can make the
signature at any point in the signing process. On the Coldcard, we
would probably use the first key that we used for signing, so the
first key involved in the first input.)
The "key" of the global value will be pubkey value of the key which
was selected by the Signer. If its BIP32 derivation is needed for
some reason, that is documented in the input section already.
The "value" will be 65(?) bytes of a standard Bitcoin signature.
The digest (hash) of the source PSBT is not provided, so any tool
that wants to verify this signature will need to have a copy of the
original PSBT. (I see that as a critical feature, not a limitation).
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.
## Role-Based View
The above additions can only be made by a PSBT processor in the Signer
role. No-one else has the keys needed. As for the other PSBT roles:
- Any tool that reads in a PSBT and finds a signature in the final output
section can and should verify it:
- check signature over a digest of the PSBT file up to the last X bytes
- file must end at that point, with only the signature following it
- also check the key used for signature is one of the input's keys
- PSBT processors in the "combining" role, should preserve the
signatures in the global section, accumulating them into the next
PSBT. (Of course they should validate them, if they have the original
PSBT on hand as well, but that's optional and could be done later
in the flow.) The Combiner should always check a signed PSBT was
not modified in transit via the signature in the final output
section, and then strip it out of the combined PSBT.
- 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), or the appropriate PSBT if it's a more complex
case. If the Finalizer is working on a file directly from a Signer,
then it can verify the signature in the output section as well.
## Open Questions
For the message digest, I propose simple SHA256(SHA256(bytes of PSBT)).
I'm not sure of the best way to serialize the signature, but to be
consistent with the rest of the file, it should probably be DER-encoded
and variable length.
## 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.
I think with these changes, and assuming all the tools are verifying
properly, we can shutdown undetectable MiTM changes to PSBT contents.
---
Peter D. Gray || Founder, Coinkite || Twitter: @dochex || GPG: A3A31BAD 5A2A5B10
--d6Gm4EdcadzBjdND
Content-Type: application/pgp-signature; name="signature.asc"
-----BEGIN PGP SIGNATURE-----
Comment: GPGTools - https://gpgtools.org
iQEzBAEBCgAdFiEERYl3mt/BTzMnU06oo6MbrVoqWxAFAl4aBeEACgkQo6MbrVoq
WxAwRQf/eqAA2cVvfy5qr+u2itBq1nJWvygaJZhLmwyi7UoWFL0JJvcHPXJQXaHG
hV+RyBGYRHU4q7h2R565a/trRD7QpyGVbYzFBPyh0Mcrsn1WmUnbwcu8DLPeLHtA
pLVqYhWyrW1eKQ5SqmyiPIIXogGgxOg8bs4aiOtMHUODuvPXW2X6vG4BWDi8Zm9q
+Wn5hHMFpToJG4SIS9kTiAyoOVvlG+bRRApwqljXHwcL+zdkR7MWs5fVJEnFE+Rf
vYSVCUBwq3ykzl7HMct/WvmgnI4dVrv/4hEiYFNO3cMIp7DMxdRximuVUKKk9jOa
17ldOxrxstd+zC2hwj+l4gQzBXrOdg==
=wJwP
-----END PGP SIGNATURE-----
--d6Gm4EdcadzBjdND--
|
