diff options
| author | Peter D. Gray <peter@coinkite.com> | 2020-01-13 09:28:17 -0500 |
|---|---|---|
| committer | bitcoindev <bitcoindev@gnusha.org> | 2020-01-13 14:36:49 +0000 |
| commit | 74c17dd04f738031a2e366bfb243d2b6dcfaa473 (patch) | |
| tree | 07422215269f1f7f83dc97367ae183dc83566ef0 /6d | |
| parent | 25182bcc281bb8780bbc410009f55af86ca59b38 (diff) | |
| download | pi-bitcoindev-74c17dd04f738031a2e366bfb243d2b6dcfaa473.tar.gz pi-bitcoindev-74c17dd04f738031a2e366bfb243d2b6dcfaa473.zip | |
Re: [bitcoin-dev] PSBT Addition (BIP 174) for authenticating source/output PSBT files
Diffstat (limited to '6d')
| -rw-r--r-- | 6d/7ce5c7f957fc0ecd56fabe6074dcafa1494a6c | 337 |
1 files changed, 337 insertions, 0 deletions
diff --git a/6d/7ce5c7f957fc0ecd56fabe6074dcafa1494a6c b/6d/7ce5c7f957fc0ecd56fabe6074dcafa1494a6c new file mode 100644 index 000000000..43fa8a539 --- /dev/null +++ b/6d/7ce5c7f957fc0ecd56fabe6074dcafa1494a6c @@ -0,0 +1,337 @@ +Return-Path: <peter@coinkite.com> +Received: from hemlock.osuosl.org (smtp2.osuosl.org [140.211.166.133]) + by lists.linuxfoundation.org (Postfix) with ESMTP id 45BB8C077D + for <bitcoin-dev@lists.linuxfoundation.org>; + Mon, 13 Jan 2020 14:36:49 +0000 (UTC) +Received: from localhost (localhost [127.0.0.1]) + by hemlock.osuosl.org (Postfix) with ESMTP id 3485B8666D + for <bitcoin-dev@lists.linuxfoundation.org>; + Mon, 13 Jan 2020 14:36:49 +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 NLWcGAUMFRvT + for <bitcoin-dev@lists.linuxfoundation.org>; + Mon, 13 Jan 2020 14:36:47 +0000 (UTC) +X-Greylist: delayed 00:08:27 by SQLgrey-1.7.6 +Received: from smtp89.iad3b.emailsrvr.com (smtp89.iad3b.emailsrvr.com + [146.20.161.89]) + by hemlock.osuosl.org (Postfix) with ESMTPS id 9643C86632 + for <bitcoin-dev@lists.linuxfoundation.org>; + Mon, 13 Jan 2020 14:36:47 +0000 (UTC) +X-Auth-ID: peter@coinkite.com +Received: by smtp20.relay.iad3b.emailsrvr.com (Authenticated sender: + peter-AT-coinkite.com) with ESMTPSA id 137F6A00B9; + Mon, 13 Jan 2020 09:28:19 -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); Mon, 13 Jan 2020 09:28:19 -0500 +Date: Mon, 13 Jan 2020 09:28:17 -0500 +From: "Peter D. Gray" <peter@coinkite.com> +To: Andrew Chow <achow101-lists@achow101.com>, + Dmitry Petukhov <dp@simplexum.com> +Message-ID: <20200113142817.GQ10797@coinkite.com> +References: <20200111172906.GO10797@coinkite.com> + <20200112011705.6f6102dd@simplexum.com> + <78dbbce2-0372-2516-489f-ed6e839b1a6f@achow101.com> +MIME-Version: 1.0 +Content-Type: multipart/signed; micalg=pgp-sha512; + protocol="application/pgp-signature"; boundary="TakKZr9L6Hm6aLOc" +Content-Disposition: inline +In-Reply-To: <78dbbce2-0372-2516-489f-ed6e839b1a6f@achow101.com> +X-Mailman-Approved-At: Mon, 13 Jan 2020 15:12:19 +0000 +Cc: Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org> +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 14:36:49 -0000 + + +--TakKZr9L6Hm6aLOc +Content-Type: text/plain; charset=us-ascii +Content-Disposition: inline +Content-Transfer-Encoding: quoted-printable + +Thanks for the useful comments guys. I understand where you are +coming from, but my PoV is from the deep embedded side. + +On Mon, Jan 13, 2020 at 06:39:28AM +0000, Andrew Chow wrote: +> ... In fact, I'm not quite +> sure what kind of attack you are trying to defend against with this +> proposal. + +I don't have a specific attack in mind, but these signatures, if +adopted by the community at large, will allow detection of-, and +could mitigate damage from-, some broad "bug-classes". + +Consider if the PSBT Signer (hardware wallet) has bugs. Perhaps if +you tweak the PSBT in some unnatural way it produces output that +reveals the private key (duplicate k-value perhaps), or corrupts +the display of the transaction in helpful (to the attacker) ways +(typically case: output hidden as change). + +Seeing a corrupted file signature would alert you of the attempt +to do this. So maybe you don't transmit the transaction, maybe you +warn the user and so on. What happens next is up to you, but at +least we know something is happening. + +There could also be bugs in the Combiner/Finalizer which the MiTM +wants to trigger. Legimate files, signed by the PSBT Signer, will not +contain those attacks, so are "safer" to process, even if your +Combiner's PSBT parser has bugs or is tragically dumb. + +It's just another layer of security and confidence, on top of the +existing system-level security (which is already excellent). + +> 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. + +Yes, the MiTM can remove the signatures. However, if your tools expect +and require the signatures in place, then the feature is working +as intended, because the user will be alerted to the funny-business. + +More importantly: nothing has been lost by implementing the feature, +and Coldcard (and other PSBT Signers) have to be first to implement it. + +> ... 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 + +That's just it, when we receive a signed PSBT, at present we don't +know *what* was signed without a complete understanding of the +transaction, the input UTXO (at least syntactially), and PSBT file +contents. If there are bugs in that understanding (ie. checks we +all know are needed, but no-one actually implemented) then we might +transmit an harmful transaction, or continue to process a file +that has been corrupted-with-intent by a MiTM. + +> 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. + +It's fine to say that, but in an embedded environment, with very +limited memory like the Coldcard, PGP isn't an option (signing vs. +signature verification). I want to leverage the existing crypto and +PKI that we already have in play. + +> On 1/11/20 3:17 PM, Dmitry Petukhov via bitcoin-dev wrote: +=2E.. [many valid points, repeated by Andrew] ... +> > 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. + +Yes, that is a problem which is proposal does not address. If the +MitM has control over both directions, in and out, then whatever +he or she was trying to do will still happen. Personally, I'm okay +with that as a limition, but using the same signatures features, +and a pre-shared public key between the PSBT Creator and the Signer, +we could block the Signer from looking at MitM'ed files. (The Signer +would require and verify incoming unsigned PSBT to contain the +last-output-section-signature thing.) I'm not planning on supporting +that on the Coldcard (at least not yet), but with the proposed +additions, it is possible to do without further changes to the PSBT +spec. + +> > Participants can work from the same PSBT ... +> > 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. +=2E.. +> > 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. + +I want these signatures to protect against PSBT parsing bugs. That's +why they are byte-level on the whole file contents, and not based +on sub-sections of the file or various fields inside the file. Yes, +there are non-linear PSBT paths that will be difficult or impossible +to support with this approach. I would not expect implementations to +do anything fancy to reconstruct PSBT contents, I think they would +just track the complete file. In most setups today the Creator, +Combiner and Finalizer are the same device, and they are desktop +systems with gigs of memory. + +> > 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. + +Yes, this can be acheived by pre-sharing a public key with the +Signer (described above). Only signed incoming PSBT's would be +accepted. That key doesn't have anything to do with the blockchain +or value transfer. + +> > 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... + +Yes, 100% ... but I value the list's feedback, and I would prefer to +start with a legitimate key number which I don't need to change later. It's +a non-breaking change and I wouldn't propose it otherwise. + +--- +Peter D. Gray || Founder, Coinkite || Twitter: @dochex || GPG: A3A31B= +AD 5A2A5B10 + +On Mon, Jan 13, 2020 at 06:39:28AM +0000, Andrew Chow wrote: +> 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. +>=20 +> 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. +>=20 +> 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. +>=20 +> 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. +>=20 +> Andrew +>=20 +> 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 +>=20 + +--TakKZr9L6Hm6aLOc +Content-Type: application/pgp-signature; name="signature.asc" + +-----BEGIN PGP SIGNATURE----- +Comment: GPGTools - https://gpgtools.org + +iQEzBAEBCgAdFiEERYl3mt/BTzMnU06oo6MbrVoqWxAFAl4cfoEACgkQo6MbrVoq +WxDa6gf/Sg8fFp09FgQ5In9Q7/yfGxArFqKpBlKl+iyTzgc4aqA7Eds/KY3Wmyvt +EIJXJfIkWeQykh7+T05Te77PrZaIw7H7NMW2uFx5ftofCKSScurZ872gmgx9gEFT +GewppN2A+fci9Vdv3CUJoLGcjIOOGzbxP0qrqMut2P+p3evC0CTutQ8ew073GN7/ +Oa5x8QmSpRssD7QJZWfdIp4SPIdtC8Aw+wS1ui371NU/QRVMmYPuBOtbriqDF8/O +KkxHOBQP9dFpSiC9gDd5/e5diS8oMKux+OnsPwV2F7dr88U0Vyk+6VsZuUVBi7uI +8PFFQiATelBUYPdDcVZLNyvwkoIfBQ== +=v4E7 +-----END PGP SIGNATURE----- + +--TakKZr9L6Hm6aLOc-- + |