From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from silver.osuosl.org (smtp3.osuosl.org [140.211.166.136]) by lists.linuxfoundation.org (Postfix) with ESMTP id 57ADAC013A for ; Thu, 14 Jan 2021 18:23:50 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by silver.osuosl.org (Postfix) with ESMTP id 17E8820452 for ; Thu, 14 Jan 2021 18:23:50 +0000 (UTC) X-Virus-Scanned: amavisd-new at osuosl.org Received: from silver.osuosl.org ([127.0.0.1]) by localhost (.osuosl.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sXrAtBLeg-9D for ; Thu, 14 Jan 2021 18:23:47 +0000 (UTC) X-Greylist: delayed 00:06:18 by SQLgrey-1.7.6 Received: from mail-41103.protonmail.ch (mail-41103.protonmail.ch [185.70.41.103]) by silver.osuosl.org (Postfix) with ESMTPS id 348CE2044F for ; Thu, 14 Jan 2021 18:23:47 +0000 (UTC) Received: from mail-02.mail-europe.com (mail-02.mail-europe.com [51.89.119.103]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits)) (No client certificate requested) by mail-41103.protonmail.ch (Postfix) with ESMTPS id 90BE120000AA for ; Thu, 14 Jan 2021 18:17:26 +0000 (UTC) Authentication-Results: mail-41103.protonmail.ch; dkim=pass (2048-bit key) header.d=revault.dev header.i=@revault.dev header.b="lAe0Gcv/" Date: Thu, 14 Jan 2021 18:17:09 +0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=revault.dev; s=protonmail; t=1610648235; bh=cW80ooAK0grJ9fg6VepyWwSiVMB+Y6FEeJs2lmYeWUs=; h=Date:To:From:Cc:Reply-To:Subject:From; b=lAe0Gcv/cCjERGxKa+92Klk/JZLsqyQ8dqcnJEzY2kbI9WfQq14h3f0IPIG5TRyn4 Z3rHys7aKN1E96uonv4u4+yKBbvSDK0MpZpbRXzs6uF3WWa0LUYOfSuEhChJgiKgvm F7ikT0IrC9m/IW4VJVaO7uKjkSMT8t1KlUseD2VPMtszs7PVjwzM5mpIoPClukYgGE Py+95kjzMKwc7LtaGTGjOkAndEc5ycGpvZWwDQsBUoWFteEHaLJn7viEoT4QJMNwLW n/jWp/TN2uozsl6n73Ga/sDxNMGL9/wl9T4V2QRVaDORpkXL5ITe6Fz2x25QCpDU0f L0b3ubAZqAZ1g== To: bitcoin-dev@lists.linuxfoundation.org From: Kevin Loaec Reply-To: Kevin Loaec Message-ID: MIME-Version: 1.0 Content-Type: multipart/signed; protocol="application/pgp-signature"; micalg=pgp-sha256; boundary="---------------------dfe9d0fc9b60932f5711ac315889c99b"; charset=utf-8 X-Mailman-Approved-At: Thu, 14 Jan 2021 18:46:44 +0000 Subject: [bitcoin-dev] Hardware wallets and "advanced" Bitcoin features X-BeenThere: bitcoin-dev@lists.linuxfoundation.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Bitcoin Protocol Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Jan 2021 18:23:50 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) -----------------------dfe9d0fc9b60932f5711ac315889c99b Content-Type: multipart/mixed; boundary=1564201b3da96813596b57e3fcee872fe533e1f15cf6747db05361ee25c2 Mime-Version: 1.0 Message-ID: Subject: Hardware wallets and "advanced" Bitcoin features From: Kevin Loaec To: bitcoin-dev@lists.linuxfoundation.org Cc: darosior Date: Thu, 14 Jan 2021 18:17:01 +0000 Organization: Revault User-Agent: Evolution 3.38.2 --1564201b3da96813596b57e3fcee872fe533e1f15cf6747db05361ee25c2 Content-Transfer-Encoding: 7bit Content-Disposition: Content-Type: text/plain; charset=UTF-8 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/ --1564201b3da96813596b57e3fcee872fe533e1f15cf6747db05361ee25c2 Content-Transfer-Encoding: base64 Content-Disposition: attachment; name="publickey - kevin@revault.dev - 7c1d686c.asc"; filename="publickey - kevin@revault.dev - 7c1d686c.asc" Content-Type: application/pgp-keys; name="publickey - kevin@revault.dev - 7c1d686c.asc"; filename="publickey - kevin@revault.dev - 7c1d686c.asc" LS0tLS1CRUdJTiBQR1AgUFVCTElDIEtFWSBCTE9DSy0tLS0tCgp4ak1FWDVNajJSWUpLd1lCQkFI YVJ3OEJBUWRBa2h0QXpiR0Nwd0llOVBVUVVnZklFcHYyUlB3QTdyckV0cG9RCnBYMTdpYWpOSld0 bGRtbHVRSEpsZG1GMWJIUXVaR1YySUR4clpYWnBia0J5WlhaaGRXeDBMbVJsZGo3Q2p3UVEKRmdv QUlBVUNYNU1qMlFZTENRY0lBd0lFRlFnS0FnUVdBZ0VBQWhrQkFoc0RBaDRCQUNFSkVGSnBkNzAv UEdoQwpGaUVFZkIxb2JPNXdXQ3oxam5mM1VtbDN2VDg4YUVKZWJRRUErWlR5VGczS1VIeEVPSEk3 MXhZNEJ2UzZZOXEyCnhRVG1hZUJaMGVTdldCWUJBS3BSWXYzSWw4ajlQYkZIVTJOamZaMS9kYldM c2cyaXBteDA4K2VVbGdnRXpqZ0UKWDVNajJSSUtLd1lCQkFHWFZRRUZBUUVIUUFyaG84WVRYSDBZ RXJ1K1lTaHNRWDZwMEljVDUvUVN4aG01NWtkQwptYlFSQXdFSUI4SjRCQmdXQ0FBSkJRSmZreVBa QWhzTUFDRUpFRkpwZDcwL1BHaENGaUVFZkIxb2JPNXdXQ3oxCmpuZjNVbWwzdlQ4OGFFTFNIQUQr UElIbGdvVmpEbWRWYzZTbmxTNmU3QWRLMjd6SEtkM09HS0NDTjhlQytSNEIKQUtFL2tTYytCTnVT N2h1cWtkOWowUVFxcXZpUTRYUXF0SG9JUmRvWlVFc0IKPXJFT0QKLS0tLS1FTkQgUEdQIFBVQkxJ QyBLRVkgQkxPQ0stLS0tLQ== --1564201b3da96813596b57e3fcee872fe533e1f15cf6747db05361ee25c2-- -----------------------dfe9d0fc9b60932f5711ac315889c99b Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: ProtonMail wmgEARYIABAFAmAAiqMJEFJpd70/PGhCAAoJEFJpd70/PGhCTkMBAMQBVlHl yvTB6Uz8pxskxC4Pl6/0Rdqm6qk1FbC61KI8AP9n6wE6cdBWbrRwl5Tc3cE1 b1NR3fY5cQzeTi5VlsAOBw== =uuh/ -----END PGP SIGNATURE----- -----------------------dfe9d0fc9b60932f5711ac315889c99b--