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)
Subject: [bitcoin-dev] PSBT Addition (BIP 174) for authenticating
	source/output PSBT files
Precedence: list


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