Return-Path: Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org [172.17.192.35]) by mail.linuxfoundation.org (Postfix) with ESMTPS id 1651C89C for ; Tue, 16 Aug 2016 14:10:12 +0000 (UTC) X-Greylist: from auto-whitelisted by SQLgrey-1.7.6 Received: from server3 (server3.include7.ch [144.76.194.38]) by smtp1.linuxfoundation.org (Postfix) with ESMTP id BA434120 for ; Tue, 16 Aug 2016 14:10:09 +0000 (UTC) Received: by server3 (Postfix, from userid 115) id 667C42E605AE; Tue, 16 Aug 2016 16:10:08 +0200 (CEST) X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on smtp1.linux-foundation.org X-Spam-Level: X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00, FSL_HELO_NON_FQDN_1 autolearn=ham version=3.3.1 Received: from Jonass-MacBook-Pro-2.local (cable-static-140-182.teleport.ch [87.102.140.182]) by server3 (Postfix) with ESMTPSA id 812A02D0073A for ; Tue, 16 Aug 2016 16:10:07 +0200 (CEST) To: Bitcoin development mailing list From: Jonas Schnelli Message-ID: <57B31EBC.1030806@jonasschnelli.ch> Date: Tue, 16 Aug 2016 16:10:04 +0200 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:38.0) Gecko/20100101 Thunderbird/38.7.2 MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="cdTBVnDBGIC0CCRPQqPNv0kEMRTI9LtAd" Subject: [bitcoin-dev] Hardware Wallet Standard X-BeenThere: bitcoin-dev@lists.linuxfoundation.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Bitcoin Protocol Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Aug 2016 14:10:12 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --cdTBVnDBGIC0CCRPQqPNv0kEMRTI9LtAd Content-Type: multipart/mixed; boundary="cTlTkvQRBGCGb03PfMOQbQ5gurJc1Vp74" From: Jonas Schnelli To: Bitcoin development mailing list Message-ID: <57B31EBC.1030806@jonasschnelli.ch> Subject: Hardware Wallet Standard --cTlTkvQRBGCGb03PfMOQbQ5gurJc1Vp74 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hi Unfortunately, there is no standard in how desktop- or mobile-wallets can interact with a hardware device resulting in wallet vendors adding plugins with proprietary code for non-standardized interfaces. I started a BIP (extreme draft, feel free to improve language, grammar and content) to address this missing part of the ecosystem. I think it would be extremely helpful if @ledger, @trezor, @voisin/@breadwallet, @electrum, @bitpay (and more?!) would help working on a such standard. The BIP describes two approaches how to communicate (pipe and URI-scheme) with the signing-devices app, although, in my opinion, all major platform do support the URI approach (maybe we could drop the pipe approach then). The URI approach means that there is no need to configure the application location in order to start a inter-process(-app) communicatio= n. Mediawiki: https://github.com/jonasschnelli/bips/blob/8abb51f0b21b6664388f6e88f6fd64= 2c90d25dca/bip-undef-0.mediawiki ---- BIP (rough early stage draft) 
  BIP: ???
  Title: Detached Signing
  Author: Jonas Schnelli 
  Status: Draft (early stage!)
  Type: Standards Track
  Created: 2016-08-02
=3D=3D Abstract =3D=3D This BIP describes a way how wallet applications can decouple sensitive privatekeys from the internal keychain and interact with a signing-devices (hardware wallet, "cold" storage) over a generic interface in order to get signatures. =3D=3D Motivation =3D=3D It seems like that the current approach for allowing signing-devices to interact with third party wallets is to build a plugin [1][2][3]. Adding plugins for each hardware wallet type will increase possible security issues and result in multiple proprietary-third-party code within the wallet application with very similar structures. A generic interface how wallets can interact with signing-devices would result in better user experience, less critical code and simpler adaption for various signing-devices. =3D=3D Specification =3D=3D In order to support desktop- and smartphone-wallet-applications, this BIP describes two slightly different approaches (process pipe and URI call) in how to interact with the signing-devices. If possible, the modern URI approach should be chosen. =3D=3D=3D Signing-Device-Controller-Application =3D=3D=3D To allow a generic interface while still allowing different ways how to internally communicate with the signing device itself (USB, TCP/IP, air-gapped Qr-Code scanning, etc.) a controller-application is required. =3D=3D=3D General signing process =3D=3D=3D The wallets signing process must be according the following principal: * Wallet prepares signing-request-object including bitcoin-transaction or message together with metadata (scriptPubKey, hd-keypath of the inputs= ) * Wallet passes signing-request-object to the signing-device-controller-application * Signing-device-controller-application processes signing-request-object, eventually shows UI, user can sign or cancel * Signing-device-controller-application sends back signing-response-object with signatures or an error * Wallet processes signing-response-object and completes data-object creating process (example: add signatures to transaction and broadcast) =3D=3D=3D Desktop Process Intercommunication =3D=3D=3D Desktop wallets can interact with a signing device over process intercommunication (pipe) together with a signing-device-controller-application. As specified below, the signing-request-object is a URI string passed through the pipe. The desktop wallet needs to wait (with a recommended timeout between 1 and 5 minutes) until the signing-response-object will be sent back by the signing-device-controller-application. =3D=3D=3D Smartphone/URI App Intercommunication =3D=3D=3D Smartphones and modern operating systems are trying to sandbox applications and interprocess communication (on pipe level) is mostly disallowed. On smartphones, we must use URI-schemes. The wallet can pass information to the signing-device-controller-application by using a predefined URI scheme. detatchedsigning://?&returnurischeme=3D The querystring must be URI encoded. RFC 2616 does not specify a maximum length of URIs (get request). Most modern smartphone operating system allow URIs up to serval megabytes. Signing complex data-structure is therefore possible. The returnurischeme must contain a URI schema where the result of the signing process should be returned to. The returnurischeme must be populated and "opened" once the signing process has been completed (or cancled). =3D=3D=3D Signing Request =3D=3D=3D The signing request is a flexible URI-Query-String that will be used by the Signing-device-controller-application for user confirmation as well as for creating the signature. The URI-query-string must conform to the following format: detatchedsigning://sign?type=3D&data=3D&inputscripts=3D,,...&inputhdkeypath=3D,,..= =2E&returnscheme=3D type =3D type of the data to sign data =3D raw unsigned bitcoin transaction or text-message (optional)inputscripts =3D scriptPubKey(s) of the inputs in exact order (optional)inputhdkeypath =3D hd-keypath of the inputs in exact order (optional)returnscheme =3D a URI scheme where the response must be sent t= o (smartphone approach) * inputhdkeypath or inputscripts must be provided. =3D=3D=3D Signing Response =3D=3D=3D The signing response is a flexible URI-Query-String that will be sent back to the wallet application and must contain the signatures or an error code. The URI-query-string can be opened (smartphone approach) or will be sent back though the interprocess pipe. ://signresponse?errorcode=3D&signatures= =3D,,... In case of ECDSA, the returned signatures must be normalized compact signatures with the size of 64bytes (128 hex chars). =3D=3D=3D=3D Possible error code =3D=3D=3D=3D 0 =3D no error 1 =3D user canceled 2 =3D timeout 10 =3D missing key identifier (missing HD keypath or input scriptpubkey) 11 =3D unsupported signing type 12 =3D could not resolve script 50 =3D unknown internal error =3D=3D=3D=3D Examples =3D=3D=3D=3D =3D=3D=3D=3D=3D Simple p2pkh transaction =3D=3D=3D=3D=3D Unsigned raw transaction: 0100000001fd3cd19d0fb7dbb5bff148e6d3e18bc42cc49a76ed2bfd7d760ad1d79= 07fd9ce0100000000ffffffff0100e1f505000000001976a9149062e542a78d4fe00dcf7c= ca89c24a8013c381a388ac00000000 (input ced97f90d7d10a767dfd2bed769ac42cc48be1d3e648f1bfb5dbb70f9dd13cfd vout:1, output: P2PKH mtgQ54Uf3iRTc9kq18rw9SJznngvF5ryZn 1 BTC) signing-request URI must be: detatchedsigning://sign?type=3Dbitcoin-p2pkh&data=3D0100000001fd3cd= 19d0fb7dbb5bff148e6d3e18bc42cc49a76ed2bfd7d760ad1d7907fd9ce0100000000ffff= ffff0100e1f505000000001976a9149062e542a78d4fe00dcf7cca89c24a8013c381a388a= c00000000&inputscripts=3D76a914531148ad17fdbffd4bac72d43deea6c7cf0387d088= ac&inputhdkeypath=3Dm/0'/0'/1&returnscheme=3Dmyapp The inputhdkeypath is optional in this case signing-response URI must be: detatchedsigning://signresponse?error=3D0&signatures=3D<128hex-char= s> =3D=3D=3D=3D=3D Simple a bitcoin message =3D=3D=3D=3D=3D Message: Lorem ipsum dolor sit amet signing-request URI must be: detatchedsigning://sign?type=3Dbitcoinmsg&data=3DLorem+ipsum+dolor+= sit+amet&inputhdkeypath=3Dm/0'/0'/2 signing-response URI must be: detatchedsigning://signresponse?error=3D0&signatures=3D<128hex-char= s> =3D=3D=3D Support for multiple signing-devices =3D=3D=3D Must operating systems allow only one registered application per URI-scheme. To support multiple signing-devices, wallets and signing-devices can optional add support for brand based URI-schemes. In addition to the standard URI scheme, signing-devices-controller-applications can register an additional URI scheme (with the identical request/response syntax and logic) including a brand-identifier. Registering a brand-identifier based URI scheme without registering the default URI scheme is not allowed. Wallets can detect if a certain brand based URI scheme is supported and therefore gives user a selection if multiple signing-devices where detected [4][5]. detatchedsigning:// Supported brand-identifiers are: * trezor * ledger * keepkey * digitalbitbix =3D=3D References =3D=3D [1] https://github.com/spesmilo/electrum/pull/1662 [2] https://github.com/spesmilo/electrum/pull/1391 [3] https://github.com/bitpay/copay/pull/3143 [4] https://developer.apple.com/library/ios/documentation/UIKit/Reference/UIA= pplication_Class/ [5] https://developer.android.com/reference/android/content/pm/PackageManager= =2Ehtml =3D=3D Acknowledgements =3D=3D =3D=3D Copyright =3D=3D This work is placed in the public domain. --cTlTkvQRBGCGb03PfMOQbQ5gurJc1Vp74-- --cdTBVnDBGIC0CCRPQqPNv0kEMRTI9LtAd Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQIcBAEBCAAGBQJXsx68AAoJECnUvLZBb1PsugAP/0YkdaAG280QJDyagKxuOPNG CPV7h8Z3+hAR8nSRX3Kf63InaoD/ECToTgiMxXC2rA4l4edZFhTWCiQDQ0BB2Clw +VNTUR5SdsMuBrAA6WNge74jW+XpZgX6lxUHLSPYhyIwl0i1w97N3onB/tnPpYvj pIumMR2d6qZ5bm+rJk4hJ3Y4ECd6RjgzrBaTufeUl6YpBTls3LrR5cXWcYl0BUDZ M0XCVv/GZuk2h7W/nBkukTaH5N8DHyaa1HIvjzvJ5Mg+2ZBhVDjyf43HVn6XWAWn 2iydioaXZClB557wM7rt+nzhtsWnsCKlMYe7YCcvMyPH/txibphzHNxKcFi5gTMJ TxCyuixeOfdCNmKoYqHnh7Uzn1nvg6Qo79JdfKwAPD+QCocDwMcrbcd1x/ky0M1o CerDEb68jhOiwZ482r4K0RfXHR/mQm5vx2P4/PpTXUfRvnkXeFI6EzDBm3zn/t7n q1ircBg+Nd6ltVYx66MTGYTIgFYZiEMwOfKX80t6LXESEzh8nUUlacdpyEjtCMW7 Tumjq++7evmuvvwphjdGs/Odg81NL2yakiqeo1R+UU4vbKK1ySGmoElWv70q3Qja EuUOslnJUk4EcuIhz8YgFWX7bqNfdfrHm/NSpRBsBW1hnIDwdIdJO13VpSWb8w6s FOHjD26XyLzU+VeY2gfO =Tcvk -----END PGP SIGNATURE----- --cdTBVnDBGIC0CCRPQqPNv0kEMRTI9LtAd--