path: root/91/6553ea6918b3b3636c9b8a33b1cf5620a5e887

Return-Path: <dev@jonasschnelli.ch>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
	[172.17.192.35])
	by mail.linuxfoundation.org (Postfix) with ESMTPS id 1651C89C
	for <bitcoin-dev@lists.linuxfoundation.org>;
	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 <bitcoin-dev@lists.linuxfoundation.org>;
	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 <bitcoin-dev@lists.linuxfoundation.org>;
	Tue, 16 Aug 2016 16:10:07 +0200 (CEST)
To: Bitcoin development mailing list <bitcoin-dev@lists.linuxfoundation.org>
From: Jonas Schnelli <dev@jonasschnelli.ch>
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 <bitcoin-dev.lists.linuxfoundation.org>
List-Unsubscribe: <https://lists.linuxfoundation.org/mailman/options/bitcoin-dev>,
	<mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=unsubscribe>
List-Archive: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/>
List-Post: <mailto:bitcoin-dev@lists.linuxfoundation.org>
List-Help: <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=help>
List-Subscribe: <https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev>,
	<mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=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 <dev@jonasschnelli.ch>
To: Bitcoin development mailing list <bitcoin-dev@lists.linuxfoundation.org>
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

</jonas>


---- BIP (rough early stage draft)

<pre>
  BIP: ???
  Title: Detached Signing
  Author: Jonas Schnelli <dev@jonasschnelli.ch>
  Status: Draft (early stage!)
  Type: Standards Track
  Created: 2016-08-02
</pre>

=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.

<code>detatchedsigning://<command>?<querystring>&returnurischeme=3D<retur=
nurischeme://></code>

The <code>querystring</code> 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 <code>returnurischeme</code> 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:

<code>detatchedsigning://sign?type=3D<bitcoin-p2pkh|bitcoin-p2sh|bitcoin-=
msg>&data=3D<raw-transaction|message>&inputscripts=3D<scriptPubKey-input0=
>,<scriptPubKey-input1>,...&inputhdkeypath=3D<hdkeypath0>,<hdkeypath1>,..=
=2E&returnscheme=3D<returnurischeme></code>

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.

<code><returnurischeme>://signresponse?errorcode=3D<errorcode>&signatures=
=3D<signature-input0>,<signature-input0>,...</code>

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:
<code>0100000001fd3cd19d0fb7dbb5bff148e6d3e18bc42cc49a76ed2bfd7d760ad1d79=
07fd9ce0100000000ffffffff0100e1f505000000001976a9149062e542a78d4fe00dcf7c=
ca89c24a8013c381a388ac00000000</code>
(input ced97f90d7d10a767dfd2bed769ac42cc48be1d3e648f1bfb5dbb70f9dd13cfd
vout:1, output: P2PKH mtgQ54Uf3iRTc9kq18rw9SJznngvF5ryZn 1 BTC)

signing-request URI must be:
<code>detatchedsigning://sign?type=3Dbitcoin-p2pkh&data=3D0100000001fd3cd=
19d0fb7dbb5bff148e6d3e18bc42cc49a76ed2bfd7d760ad1d7907fd9ce0100000000ffff=
ffff0100e1f505000000001976a9149062e542a78d4fe00dcf7cca89c24a8013c381a388a=
c00000000&inputscripts=3D76a914531148ad17fdbffd4bac72d43deea6c7cf0387d088=
ac&inputhdkeypath=3Dm/0'/0'/1&returnscheme=3Dmyapp</code>
The <code>inputhdkeypath</code> is optional in this case

signing-response URI must be:
<code>detatchedsigning://signresponse?error=3D0&signatures=3D<128hex-char=
s></code>

=3D=3D=3D=3D=3D Simple a bitcoin message =3D=3D=3D=3D=3D
Message: <code>Lorem ipsum dolor sit amet</code>

signing-request URI must be:
<code>detatchedsigning://sign?type=3Dbitcoinmsg&data=3DLorem+ipsum+dolor+=
sit+amet&inputhdkeypath=3Dm/0'/0'/2</code>

signing-response URI must be:
<code>detatchedsigning://signresponse?error=3D0&signatures=3D<128hex-char=
s></code>

=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].

<code>detatchedsigning<brandid>://</code>

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--