path: root/92/0dda66531eaf3b18d00d8bd756bfd1c72e4af5

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
>>>