rich1.0npub10vqyu8x3f0lfttk98xc28ppuyufaz4df8x4aspa9w9xz5z05snzq7t058yhttps://nostr.ae/npub10vqyu8x3f0lfttk98xc28ppuyufaz4df8x4aspa9w9xz5z05snzq7t058ynjumphttps://nostr.ae📅 Original date posted:2020-01-11 📝 Original message:## 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 -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 529 bytes Desc: not available URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20200111/51fab912/attachment.sig>