diff options
| author | Andrew Chow <achow101-lists@achow101.com> | 2020-01-13 17:05:10 +0000 |
|---|---|---|
| committer | bitcoindev <bitcoindev@gnusha.org> | 2020-01-13 17:05:24 +0000 |
| commit | c763fcaceccc3fac3c4e09dedc9ccc69251a6bb3 (patch) | |
| tree | 21be13fc617b0141f40428ef2082d74af3b0ef0c | |
| parent | 74c17dd04f738031a2e366bfb243d2b6dcfaa473 (diff) | |
| download | pi-bitcoindev-c763fcaceccc3fac3c4e09dedc9ccc69251a6bb3.tar.gz pi-bitcoindev-c763fcaceccc3fac3c4e09dedc9ccc69251a6bb3.zip | |
Re: [bitcoin-dev] PSBT Addition (BIP 174) for authenticating source/output PSBT files
| -rw-r--r-- | 92/0dda66531eaf3b18d00d8bd756bfd1c72e4af5 | 323 |
1 files changed, 323 insertions, 0 deletions
diff --git a/92/0dda66531eaf3b18d00d8bd756bfd1c72e4af5 b/92/0dda66531eaf3b18d00d8bd756bfd1c72e4af5 new file mode 100644 index 000000000..e466cdd7d --- /dev/null +++ b/92/0dda66531eaf3b18d00d8bd756bfd1c72e4af5 @@ -0,0 +1,323 @@ +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 56C38C077D + for <bitcoin-dev@lists.linuxfoundation.org>; + Mon, 13 Jan 2020 17:05:24 +0000 (UTC) +Received: from localhost (localhost [127.0.0.1]) + by hemlock.osuosl.org (Postfix) with ESMTP id 4EEC3840EA + for <bitcoin-dev@lists.linuxfoundation.org>; + Mon, 13 Jan 2020 17:05:24 +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 MhxQkGxKqMGH + for <bitcoin-dev@lists.linuxfoundation.org>; + Mon, 13 Jan 2020 17:05:22 +0000 (UTC) +X-Greylist: from auto-whitelisted by SQLgrey-1.7.6 +Received: from mail-40131.protonmail.ch (mail-40131.protonmail.ch + [185.70.40.131]) + by hemlock.osuosl.org (Postfix) with ESMTPS id EDF1581F3B + for <bitcoin-dev@lists.linuxfoundation.org>; + Mon, 13 Jan 2020 17:05:21 +0000 (UTC) +Date: Mon, 13 Jan 2020 17:05:10 +0000 +DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=achow101.com; + s=protonmail; t=1578935118; + bh=uA2uIaPQIKpr2JJNe4Ro9iqlZaxfPVp20+DAyPevHvc=; + h=Date:To:From:Cc:Reply-To:Subject:In-Reply-To:References: + Feedback-ID:From; + b=pjOLgnzhCagJnxRSEtP0LJlL+1qlqrGHN6RVW9BKJzO4yWFBYOijR7ur6yUgPfyHM + CZy+OZcgTMbbX8+XCGkBkP/akSGsjypC+rXa43KG3WbuMHW9r9tHuG56wy22M/3RSE + 9F+rzasnyT9/4LU6rVv0PzXUmp4XVnsq4FO2CLIM= +To: "Peter D. Gray" <peter@coinkite.com>, Dmitry Petukhov <dp@simplexum.com> +From: Andrew Chow <achow101-lists@achow101.com> +Reply-To: Andrew Chow <achow101-lists@achow101.com> +Message-ID: <4adabcd3-e2ce-d143-0193-8a8581a318aa@achow101.com> +In-Reply-To: <20200113142817.GQ10797@coinkite.com> +References: <20200111172906.GO10797@coinkite.com> + <20200112011705.6f6102dd@simplexum.com> + <78dbbce2-0372-2516-489f-ed6e839b1a6f@achow101.com> + <20200113142817.GQ10797@coinkite.com> +Feedback-ID: VjS95yl5HLFwBfNLRqi61OdL1ERZPmvMbZRH2ZcBR7SKVUVYPgv7VJsV9uoyC4vIfjYnW8hPXGuLTycZbh49Zw==:Ext:ProtonMail +MIME-Version: 1.0 +Content-Type: text/plain; charset=UTF-8 +Content-Transfer-Encoding: quoted-printable +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 17:05:24 -0000 + + +On 1/13/20 9:28 AM, Peter D. Gray wrote: +> 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". +>=20 +> 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). + +Since the PSBT is to be signed by one of the Signers for the PSBT, I +don't see how this is useful. If it is mutated and the signer has bugs, +especially parsing bugs, the Signer also adding its signature won't +help. In your proposal, it is the Signer who adds the signature, so it +will receive a PSBT without auth sigs and thus that could be mutated to +trigger those bugs anyways. + +> 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. + +The job of Combiners is fairly limited and is really just related to +parsing the PSBT into some internal object then shuffling those fields +around. In that case, any bugs an attacker would want to exploit have to +be deserialization bugs, in which case, your auth sigs don't help. The +Combiner still has to deserialize the PSBT to get the signature, then it +needs to re-serialize the PSBT to check that signature. An attacker +could insert bad bytes into the PSBT which causes problems during +deserialization, before the Combiner is able to check the signature. + +For Finalizers, since its job is to construct the final +scriptSig/scriptWitness, at worst, all it can do is produce an invalid +transaction. Finalizers don't have access to the private keys so there's +no bug possible that can result in a Finalizer producing a transaction +that reveals the private key. + +>=20 +> 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. + +ISTM the same is true of your proposal. You need to deserialize the PSBT +and then figure out which fields were "original" and in what order. If +there is a bug in your deserialization, an attacker can still exploit +that. And if there is a bug in your reconstruction of "original", you'll +have false positives. + +> 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. + +My point was that you can achieve your MiTM protection by having the +signature separate from the PSBT. You can still make your ECDSA +signature and send it along with the PSBT, and you can do it with fixed +or exchanged keys, no need for parsing the PSBT itself. It can be part +of the transport protocol, not part of the data that is being transferred. + +Andrew + +>=20 +>> On 1/11/20 3:17 PM, Dmitry Petukhov via bitcoin-dev wrote: +> ... [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. +>=20 +> 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. +>=20 +>>> 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 b= +e +>>> 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. +> ... +>>> 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 +> 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. +>=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 +> 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. +>=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... +>=20 +> 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. +>=20 +> --- +> Peter D. Gray || Founder, Coinkite || Twitter: @dochex || GPG: A3A3= +1BAD 5A2A5B10 +>=20 +> 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. +>> +>> 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: +>>> +>>> 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. +>>> +>>> 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: +>>> +>>>> 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 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. +>>> +>>>> - 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) +>>> +>>> 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. +>>> +>>> 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 b= +e +>>> 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. +>>> +>>> 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. +>>> +>>> 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. +>>> +>>> 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'. +>>> +>>> 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). +>>> +>>>> 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. +>>> +>>> 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. +>>> +>>> 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. +>>> +>>>> ## 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 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. +>>> +>>> // Dmitry. +>>> _______________________________________________ +>>> bitcoin-dev mailing list +>>> bitcoin-dev@lists.linuxfoundation.org +>>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev +>>> + + |