Re: [bitcoin-dev] Hardware wallets and "advanced" Bitcoin features

From: darosior <darosior@protonmail•com>
To: Antoine Riard <antoine.riard@gmail•com>,
	Bitcoin Protocol Discussion
	<bitcoin-dev@lists•linuxfoundation.org>
Subject: Re: [bitcoin-dev] Hardware wallets and "advanced" Bitcoin features
Date: Sun, 17 Jan 2021 10:02:32 +0000	[thread overview]
Message-ID: <-dbEbZdrKCipubghS84uRlP0r158rIrh9dfQQb5QPCpWgAMimf3sMygdMyEXNXKgnE_ttcIB3JhbDxvp8_xEDWuFS9NAp5zi3R_qnbuBarc=@protonmail.com> (raw)
In-Reply-To: <CALZpt+EMHkYFxkO+SxFEjbiG2hU2Rm5kpMd8+71+Wjxc48J5ig@mail.gmail.com>

[-- Attachment #1: Type: text/plain, Size: 11229 bytes --]

Hi Antoine, and Kevin,

>> * Proposed improvement: The HW should display the Bitcoin Script itself when possible (including the unlock conditions).
>
> What level of script literacy are you assuming on your users ? I can see enterprise/hobbyist folks to know enough of Script to understand the intended behavior but I don't think that's a reasonable assumption for your average user. Of course, Miniscript Policy makes things easier, but IMHO, I still hope to see some mature, higher-level language (e.g Ivy) to ease script semantic understanding and thus widen the crowd of users.

No Script literacy should be assumed. I believe with Miniscript Policy (with possibly alias instead of pubkeys, see below) we are to the highest possible level of abstraction
without loss of meaning for user verification. I don't think Ivy would be helpful here.
Also, as Kevin mentioned, anything would be better than an address anyways.

> Further, I would do a bit on UX research on the correctness model expected by your users. I.e if they fail to verify accordingly, are they losing funds, transaction doesn't confirm, transaction doesn't even propagate, etc. You should also make assumptions on the mental resources you're required from them. Time-sensitive L2 protocols have a wide scope to check, e.g not verifying the nSequence/nLocktime fields can provoke funds failures.

Regarding the correctness, with the OP threat model (laptop compromised), for any transaction: if they fail to verify the locking policy, fund loss.
Re nSeq: If we trust the HM, and the HM support Miniscript, it must be able to satisfy inputs in a sa[n,f]e way.

>> This applies to pre-signed transaction protocols especially well as the template of these transactions could be known
> and recognized by the HW. Typically for Revault, the HW could display: "Unvault Transaction, all expected pubkeys
> present in the script".
>
> In the future, I would expect templates of high-security protocols like vaults to be part of the trusted computing base of any decent HW. I think good standards there would avoid HW vendors to come with some kind of certified-templates scheme and thus having to bless custom scripts of every vaults implementations.

+1

>> Then there is PSBT support and the maximum transaction size limit for
> these: we need more transparency from HW manufacturers on their li
> mitations.
>
> I understand them, Script is full of subtleties, taproot is likely to have more of them and if you take sighash malleability that's not something you want your average user to play with. Maybe it
> would be better to come up with a first wave of script features on which you expect transparency ? For sure, OP_CSV is a good candidate.

I agree that rather than supporting all of Script it would be better to support a "safe", analyzable subset of Script: that's Miniscript :p
I also believe supporting any new Script capabilities without Miniscript would be a huge footgun. It would also ease the upgrade to Tapscript.

>> Once any input of a (pre-signed)transaction is
> spent, this transaction isn't valid anymore. Most pre-signed transactions protocols are used today as a form of defense
> mechanism, spending any input would mean incapacitating the entire defense mechanism.
>
> I don't see the exact issue here. E.g in Lightning, even if you pre-sign a justice transaction punishing every revokeable outputs on counterparty transaction, and one input is spent, will current HWs prevent you to-resign an updated justice transaction ?

That's because in Revault we don't require HMs for watchtowers. Funds holders are expected to have a routine signing of cancel / deterrent / unvault transactions
and share them with the watchtowers. The attack Kevin is talking about is a (expected-to-be-stateless) HM will happily sign a cancel of deterrent transaction that
spends an already-signed input. So let's say a fund holder sends a signature for an Unvault tx and a Cancel tx that does not spend this Unvault to their watchtower.
The watchtower would cringe (in our v0 protocol, send an NACK): but the NACK isn't handled by the HM therefore at the end of the day the already-compromised laptop
is ensuring the (statefull) validity of the signature.

Thanks,
Antoine

> Le jeu. 14 janv. 2021 à 13:46, Kevin Loaec via bitcoin-dev <bitcoin-dev@lists•linuxfoundation.org> a écrit :
>
>> Hello everyone,
>>
>> I would like to start a discussion on improving Hardware Wallets.
>>
>> My approach to this right now is from a vault protocol we are developing (Revault, [1]), and its Hardware Wallet
>> requirements. I started working on a Github Issue in our repo [2], other people recommended us to do a more general
>> discussion on the mailing list instead as it could benefit many other protocols and users.
>> This email discusses improvements that would benefit everyone, and some that are more suitable for "layer 2" or pre-
>> signed transactions protocols.
>> The goal is to spark discussions and hopefully iterate to a more secure and more usable hardware ecosystem for all
>> bitcoiners.
>> While I mainly foresee issues/improvements that may affect Revault, I would be really happy to see people joining this
>> thread with any other ideas and remarks that would benefit some parts of Bitcoin that I overlooked.
>>
>> Prior work on similar problematics:
>> ===================================
>> - ZmnSCPx
>> j: [Lightning-dev] Speculations on hardware wallet support for Lightning [3]
>> - mflaxman: Known Issues: Verifying a Receive Address [4]
>> - ksedgwic and devrandom01: Lightning-signer [5]
>> - benma: How nearly all personal hardware wallet multisig setups are insecure [6]
>>
>> The postulate we start from is that Hardware Wallets (HW) are useful to mitigate the compromission of the day-to-day
>> device of a user. They mainly prevent private-key extraction today, and aren't very suitable against an attack on the
>> transaction being signed, as explained further.
>> To make this discussion security-focused, let's assume the general purpose device (laptop, for example) is compromised
>> with a malware implanted by an attacker, capable of modifying PSBTs, displayed addresses, etc.
>>
>> Our study so far:
>>
>> Output Script Parsing:
>> ======================
>> Problem: A typical HW today would display the "destination" of a transaction in the form of a bitcoin address. A user
>> would generally compare this wit
>> h the address displayed on his laptop screen... which might have been compromised
>> already. The correct usage would be for a user to verify this address on a third device (mobile phone, for example).
>> This is weak security and bad user experience.
>> Proposed improvement: The HW should display the Bitcoin Script itself when possible (including the unlock conditions).
>> The best way to do so would be to lift this Script to a more user-friendly format such as a MiniScript Policy display,
>> but anything would be better than an "address".
>> This applies to pre-signed transaction protocols especially well as the template of these transactions could be known
>> and recognized by the HW. Typically for Revault, the HW could display: "Unvault Transaction, all expected pubkeys
>> present in the script".
>>
>> Pubkey Interpretation:
>> ======================
>> Problem: currently HW cannot "identify" addresses or keys.
>> Proposed improvement: The HW could know pubkeys or xpubs it does not hold the private keys
>> for, and display a label (or
>> understand it for logic reasons, such as "expected pubkeys" as the previous example). Going further, the xpubs could be
>> aliased the first time they are entered/verified (as part of, say, an initial setup ceremony) for instance with the
>> previously mentioned Miniscript policy: or(pk(Alice), and(pk(Bob), after(42))).
>> This should be done in the Secure Element if possible to avoid physical compromission, but would be a strong improvement
>> versus a day-to-day laptop in any case.
>>
>> Better Bitcoin Compatibility:
>> =============================
>> Problem: most HW cannot interpret some Script OPs such as OP_CSV, or any conditional outputs. This is a major issue for
>> anyone using Bitcoin "advanced" features. Related to this are the Sighash flags: most HW do not support most Sighash
>> flags. Kind of annoying for a signing device. Then there is PSBT support and the maximum transaction size limit for
>> these: we need more transparency from HW manufacturers on their li
>> mitations.
>> Solution: Make Bitcoin HW actually compatible with Bitcoin :D
>>
>> Inputs (mainly for pre-signed Tx):
>> ==================================
>> Problem: Poisoned inputs are a major risk for HW as they don't know the UTXO set. While this can be exploited for fee
>> attacks, it is a bigger threat to pre-signed transactions protocols. Once any input of a (pre-signed)transaction is
>> spent, this transaction isn't valid anymore. Most pre-signed transactions protocols are used today as a form of defense
>> mechanism, spending any input would mean incapacitating the entire defense mechanism.
>> Proposed improvement: for protocols that requires it, keeping track of inputs already signed once would be extremely
>> helpful. Going further, most of these protocols require to follow a specific signing order (typically the "clawback"
>> first, then the regular spend path) so adding a way to check that a "clawback" has been signed first, with the same
>> input, would be very helpful. All of this on the dev
>> ice itself.
>>
>> I understand some of these changes may be very difficult, especially given the low memory and computational power of
>> secure elements. However I truly believe most of these points are a MUST have for any decent security. If you don't
>> assume the computer on which the transaction is crafted is compromised, then you don't need a hardware wallet. If you
>> assume it may be compromised, then the HW needs to be able to defend against those.
>>
>> Revault does not plan on building hardware wallets, we hope existing and upcoming manufacturers will implement a strong
>> security that we could use for the Revault protocol users. Vault users will likely hold very large sums and would be
>> happy to pay a high premium for more secure HW. This will hopefully encourage existing players to keep on improving
>> their devices and that will ultimately benefit us all.
>>
>> Feel free to reply with your comments or adding suggestions, I am not a hardware wallet expert and would take criticism
>> wit
>> hout being offended.
>>
>> Kind Regards,
>> Kevin Loaec
>>
>> [1]: https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2020-May/017835.html
>> [2]: https://github.com/re-vault/practical-revault/issues/59
>> [3]: https://lists.linuxfoundation.org/pipermail/lightning-dev/2020-January/002425.html
>> [4]: https://btcguide.github.io/known-issues/verify-receive-address
>> [5]: https://gitlab.com/lightning-signer/docs
>> [6]: https://shiftcrypto.ch/blog/how-nearly-all-personal-hardware-wallet-multisig-setups-are-insecure/
>>
>> _______________________________________________
>> bitcoin-dev mailing list
>> bitcoin-dev@lists•linuxfoundation.org
>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

[-- Attachment #2: Type: text/html, Size: 15087 bytes --]