{"type":"rich","version":"1.0","title":"Kevin Loaec [ARCHIVE] wrote","author_name":"Kevin Loaec [ARCHIVE] (npub12w…j845v)","author_url":"https://yabu.me/npub12w0x6sueclvy20mq2sfdsj2uu6y6f3hks05vh82wf8fyxqj7y9qqsj845v","provider_name":"njump","provider_url":"https://yabu.me","html":"📅 Original date posted:2021-01-14\n📝 Original message:Hello everyone,\n\nI would like to start a discussion on improving Hardware Wallets.\n\nMy approach to this right now is from a vault protocol we are developing (Revault, [1]), and its Hardware Wallet\nrequirements. I started working on a Github Issue in our repo [2], other people recommended us to do a more general\ndiscussion on the mailing list instead as it could benefit many other protocols and users.\nThis email discusses improvements that would benefit everyone, and some that are more suitable for \"layer 2\" or pre-\nsigned transactions protocols.\nThe goal is to spark discussions and hopefully iterate to a more secure and more usable hardware ecosystem for all\nbitcoiners.\nWhile I mainly foresee issues/improvements that may affect Revault, I would be really happy to see people joining this\nthread with any other ideas and remarks that would benefit some parts of Bitcoin that I overlooked.\n\n\n\nPrior work on similar problematics:\n===================================\n- ZmnSCPx\nj: [Lightning-dev] Speculations on hardware wallet support for Lightning [3]\n- mflaxman: Known Issues: Verifying a Receive Address [4]\n- ksedgwic and devrandom01: Lightning-signer [5]\n- benma: How nearly all personal hardware wallet multisig setups are insecure [6]\n\n\nThe postulate we start from is that Hardware Wallets (HW) are useful to mitigate the compromission of the day-to-day\ndevice of a user. They mainly prevent private-key extraction today, and aren't very suitable against an attack on the\ntransaction being signed, as explained further.\nTo make this discussion security-focused, let's assume the general purpose device (laptop, for example) is compromised\nwith a malware implanted by an attacker, capable of modifying PSBTs, displayed addresses, etc.\n\nOur study so far:\n\n\nOutput Script Parsing:\n======================\nProblem: A typical HW today would display the \"destination\" of a transaction in the form of a bitcoin address. A user\nwould generally compare this wit\nh the address displayed on his laptop screen... which might have been compromised\nalready. The correct usage would be for a user to verify this address on a third device (mobile phone, for example).\nThis is weak security and bad user experience.\nProposed improvement: The HW should display the Bitcoin Script itself when possible (including the unlock conditions).\nThe best way to do so would be to lift this Script to a more user-friendly format such as a MiniScript Policy display,\nbut anything would be better than an \"address\".\nThis applies to pre-signed transaction protocols especially well as the template of these transactions could be known\nand recognized by the HW. Typically for Revault, the HW could display: \"Unvault Transaction, all expected pubkeys\npresent in the script\".\n\n\nPubkey Interpretation:\n======================\nProblem: currently HW cannot \"identify\" addresses or keys.\nProposed improvement: The HW could know pubkeys or xpubs it does not hold the private keys \nfor, and display a label (or\nunderstand it for logic reasons, such as \"expected pubkeys\" as the previous example). Going further, the xpubs could be\naliased the first time they are entered/verified (as part of, say, an initial setup ceremony) for instance with the\npreviously mentioned Miniscript policy: or(pk(Alice), and(pk(Bob), after(42))).\nThis should be done in the Secure Element if possible to avoid physical compromission, but would be a strong improvement\nversus a day-to-day laptop in any case.\n\n\nBetter Bitcoin Compatibility:\n=============================\nProblem: most HW cannot interpret some Script OPs such as OP_CSV, or any conditional outputs. This is a major issue for\nanyone using Bitcoin \"advanced\" features. Related to this are the Sighash flags: most HW do not support most Sighash\nflags. Kind of annoying for a signing device. Then there is PSBT support and the maximum transaction size limit for\nthese: we need more transparency from HW manufacturers on their li\nmitations.\nSolution: Make Bitcoin HW actually compatible with Bitcoin :D\n\n\nInputs (mainly for pre-signed Tx):\n==================================\nProblem: Poisoned inputs are a major risk for HW as they don't know the UTXO set. While this can be exploited for fee\nattacks, it is a bigger threat to pre-signed transactions protocols. Once any input of a (pre-signed)transaction is\nspent, this transaction isn't valid anymore. Most pre-signed transactions protocols are used today as a form of defense\nmechanism, spending any input would mean incapacitating the entire defense mechanism.\nProposed improvement: for protocols that requires it, keeping track of inputs already signed once would be extremely\nhelpful. Going further, most of these protocols require to follow a specific signing order (typically the \"clawback\"\nfirst, then the regular spend path) so adding a way to check that a \"clawback\" has been signed first, with the same\ninput, would be very helpful. All of this on the dev\nice itself.\n\n\n\n\nI understand some of these changes may be very difficult, especially given the low memory and computational power of\nsecure elements. However I truly believe most of these points are a MUST have for any decent security. If you don't\nassume the computer on which the transaction is crafted is compromised, then you don't need a hardware wallet. If you\nassume it may be compromised, then the HW needs to be able to defend against those.\n\nRevault does not plan on building hardware wallets, we hope existing and upcoming manufacturers will implement a strong\nsecurity that we could use for the Revault protocol users. Vault users will likely hold very large sums and would be\nhappy to pay a high premium for more secure HW. This will hopefully encourage existing players to keep on improving\ntheir devices and that will ultimately benefit us all.\n\nFeel free to reply with your comments or adding suggestions, I am not a hardware wallet expert and would take criticism\nwit\nhout being offended.\n\nKind Regards,\nKevin Loaec\n\n[1]: https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2020-May/017835.html\n[2]: https://github.com/re-vault/practical-revault/issues/59\n[3]: https://lists.linuxfoundation.org/pipermail/lightning-dev/2020-January/002425.html\n[4]: https://btcguide.github.io/known-issues/verify-receive-address\n[5]: https://gitlab.com/lightning-signer/docs\n[6]: https://shiftcrypto.ch/blog/how-nearly-all-personal-hardware-wallet-multisig-setups-are-insecure/\n\n-------------- next part --------------\nA non-text attachment was scrubbed...\nName: publickey - kevin at revault.dev - 7c1d686c.asc\nType: application/pgp-keys\nSize: 643 bytes\nDesc: not available\nURL: \u003chttp://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20210114/7adc4c33/attachment.bin\u003e\n-------------- next part --------------\nA non-text attachment was scrubbed...\nName: signature.asc\nType: application/pgp-signature\nSize: 233 bytes\nDesc: OpenPGP digital signature\nURL: \u003chttp://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20210114/7adc4c33/attachment.sig\u003e"}