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
_______________________________________________
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
