1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
|
Return-Path: <kanzure@gmail.com>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
[172.17.192.35])
by mail.linuxfoundation.org (Postfix) with ESMTPS id 3337693D
for <bitcoin-dev@lists.linuxfoundation.org>;
Wed, 17 Aug 2016 18:36:42 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.7.6
Received: from mail-oi0-f43.google.com (mail-oi0-f43.google.com
[209.85.218.43])
by smtp1.linuxfoundation.org (Postfix) with ESMTPS id BAEED170
for <bitcoin-dev@lists.linuxfoundation.org>;
Wed, 17 Aug 2016 18:36:40 +0000 (UTC)
Received: by mail-oi0-f43.google.com with SMTP id l203so148840753oib.1
for <bitcoin-dev@lists.linuxfoundation.org>;
Wed, 17 Aug 2016 11:36:40 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
h=mime-version:in-reply-to:references:from:date:message-id:subject:to;
bh=mWFRH++qxYmgvR5j9L2zmTKCaJzz91ReBG1Ymi9e+c4=;
b=y+mT3lYkSJohc4tUOZ+nPeynrR5MizyoaFzGoDNkJXtrSjXw+1zQnml+JHDLSH0PLq
OCKffbY7Nxjo8K9TES+mgOCQ3J8OgWA4um0ERM9JNVYW6j+AcDFxRYgX306HvlgO7g/K
uh6Y6M00QSRpZMF+oegz6nFTpH3tLUZ0fsbsuXTOr/bu1jmh1mg8bok2YIeCai/830PH
FhKGG49twrHID6CzcLNTg5V8qoDrzfOl9GamrIeneUc5E38vFrttgp9+xVXUFd3JMy5C
2iMlxI8RoWwhOqIJuetFsV8CbiVEslfEk/EnKfR+UsSA8o247HIlCrjn08+npwlpPHJk
DuJg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=1e100.net; s=20130820;
h=x-gm-message-state:mime-version:in-reply-to:references:from:date
:message-id:subject:to;
bh=mWFRH++qxYmgvR5j9L2zmTKCaJzz91ReBG1Ymi9e+c4=;
b=aoB2yPU4DUGZBQ+4HhuL3xIiJnKBfdcACl0OnERf0qw8cSiG/WyuiTSV3+Sw1wcSKM
ZPIc5bdbYeZMjDJgYJS+Keea8sRr+p9/9UCezZmlX3ZxYtX3fde4NwNrscFLt39cUswY
VVlImPNAkPEpyDtYSEVs1wMg8Ox1J9shNPc/vzaR4smOMcBzQb+eCpoD5cTHw5rSWkkb
l+rLvnj5GvkM09Gva3TusgcCCXIUhfGb9QBregvrye4Xm+UMmeMD9brdjGKOuGcyzVov
lfI7aEQ9wvVFO/CBTGQ9iwvo1OOaOTDCVcl6XApVYvx3HjO2ai4+XyNgVFY1a52bOQrR
HSNg==
X-Gm-Message-State: AEkoouvrmF07GKebs0x3j9u2VFItRoZTLm6JAT8Q1j9og7SmgN+6Nb1+HxUIMc6cG+s1Uo8V1iY+nlcSI415WA==
X-Received: by 10.202.196.151 with SMTP id u145mr25160452oif.141.1471458999993;
Wed, 17 Aug 2016 11:36:39 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.157.43.113 with HTTP; Wed, 17 Aug 2016 11:36:38 -0700 (PDT)
In-Reply-To: <20160817001407.GA6571@fedora-21-dvm>
References: <57B31EBC.1030806@jonasschnelli.ch>
<0501f5c2-611c-53c1-5fd1-d4da5ba5137b@gmail.com>
<20160817001407.GA6571@fedora-21-dvm>
From: Bryan Bishop <kanzure@gmail.com>
Date: Wed, 17 Aug 2016 13:36:38 -0500
Message-ID: <CABaSBawL29aRF5aJ9jbshBU+FSzOPGYj0EaETawi7ttXewTAsg@mail.gmail.com>
To: Peter Todd <pete@petertodd.org>,
Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>,
Bryan Bishop <kanzure@gmail.com>
Content-Type: multipart/alternative; boundary=001a113e4c12ff0f00053a48be57
X-Spam-Status: No, score=-2.7 required=5.0 tests=BAYES_00,DKIM_SIGNED,
DKIM_VALID,DKIM_VALID_AU,FREEMAIL_FROM,HTML_MESSAGE,RCVD_IN_DNSWL_LOW
autolearn=ham version=3.3.1
X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on
smtp1.linux-foundation.org
Subject: Re: [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: Wed, 17 Aug 2016 18:36:42 -0000
--001a113e4c12ff0f00053a48be57
Content-Type: text/plain; charset=UTF-8
On Tue, Aug 16, 2016 at 7:14 PM, Peter Todd via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:
> The other serious problem - and this is a problem with smartcards in
> general
> anyway - is that without Bitcoin-specific logic you're just signing
> blindly; we
> recently saw the problems with that with the Bitfinex/BitGo hack. And even
> then, without a screen most of the hardware wallets in are still just
> signing
> blindly, with at best hard-to-use limits on maximum funds moved
> per-transaction. Also note how even hardware wallets with a screen, like
> Trezor, aren't yet able to authenticate who you are paying.
>
"Welcome to my threat model."
In multisig scenarios, there must be a different "trust root" for each key.
For example, storing two private keys next to each other on the same web
server is broken because if one key is compromised it is infinitely trivial
to compromise the second key. Using multiple web servers is also broken if
the two servers are controlled by the same AWS keys or same "help me get my
servers back" support email request to whatever single sign-on service is
used. In some cases, it can be better to write software such that
transaction data is served at a particular location, and another
security-critical step is responsible for downloading that data from the
first machine, rather than the first computer directly pushing (with
authentication credentials in place for the attacker to compromise) the
data to the second computer.
I recommend using hardware security modules (HSMs). It's important to have
a public, reviewed bitcoin standard for hardware wallets, especially HSMs.
I expect this is something that the entire industry has a tremendous
interest in following and contributing to, which could even lead to
additional resources contributed (or at the very least, more detailed
requirements) towards libconsensus work.
Instead of signing any bitcoin transaction that the hardware wallet is
given, the hardware should be responsible for running bitcoin validation
rules and business logic, which I recommend for everyone, not only
businesses. Without running business logic and bitcoin validation rules,
the actual bitcoin history on the blockchain could be a very different
reality from what the hardware thinks is happening. Using a different
out-of-band communication channel, the hardware could query for information
from another database in another trust root, which would be useful for
business logic to validate against.
As for a screen, I consider that somewhat limited because you only get text
output (and I don't know if I can reasonably suggest QR codes here). With a
screen, you are limited to text output, which can compromise privacy of the
device's operations and info about the wallet owner. An alternative would
be to have a dedicated port that is responsibly only for sending out data
encrypted to the key of the wallet owner, to report information such as
whatever the hardware's transaction planner has decided, or to report about
the state of the device, state of the bitcoin validation rules, or any
accounting details, etc. Additionally, even a signed transaction should be
encrypted to the key of the device owner because a signed transaction can
be harmless as long as the owner still has the ability to control whether
the signed transaction is broadcasted to the network. It's "separation of
concerns" for transaction signing and decrypting a signed transaction
should be unrelated and uncoupled.
Also I am eager to see what the community proposes regarding signed and
authenticated payment requests.
((insert here general promotional statement regarding the value of reusable
checklists used during every signing ritual ceremony))
- Bryan
http://heybryan.org/
1 512 203 0507
--001a113e4c12ff0f00053a48be57
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><div class=3D"gmail_extra"><div class=3D"gmail_quote">On T=
ue, Aug 16, 2016 at 7:14 PM, Peter Todd via bitcoin-dev <span dir=3D"ltr">&=
lt;<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" target=3D"_blan=
k">bitcoin-dev@lists.linuxfoundation.org</a>></span> wrote:<br><blockquo=
te class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left-widt=
h:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-le=
ft:1ex"><div id=3D":itg" class=3D"">The other serious problem - and this is=
a problem with smartcards in general<br>
anyway - is that without Bitcoin-specific logic you're just signing bli=
ndly; we<br>
recently saw the problems with that with the Bitfinex/BitGo hack. And even<=
br>
then, without a screen most of the hardware wallets in are still just signi=
ng<br>
blindly, with at best hard-to-use limits on maximum funds moved<br>
per-transaction. Also note how even hardware wallets with a screen, like<br=
>
Trezor, aren't yet able to authenticate who you are paying.<br></div></=
blockquote></div><div class=3D"gmail_extra"><br>"Welcome to my threat =
model."<br><br></div><div class=3D"gmail_extra">In multisig scenarios,=
there must be a different "trust root" for each key. For example=
, storing two private keys next to each other on the same web server is bro=
ken because if one key is compromised it is infinitely trivial to compromis=
e the second key. Using multiple web servers is also broken if the two serv=
ers are controlled by the same AWS keys or same "help me get my server=
s back" support email request to whatever single sign-on service is us=
ed. In some cases, it can be better to write software such that transaction=
data is served at a particular location, and another security-critical ste=
p is responsible for downloading that data from the first machine, rather t=
han the first computer directly pushing (with authentication credentials in=
place for the attacker to compromise) the data to the second computer.<br>=
</div><div class=3D"gmail_extra"><br></div></div><div class=3D"gmail_extra"=
>I recommend using hardware security modules (HSMs). It's important to =
have a public, reviewed bitcoin standard for hardware wallets, especially H=
SMs. I expect this is something that the entire industry has a tremendous i=
nterest in following and contributing to, which could even lead to addition=
al resources contributed (or at the very least, more detailed requirements)=
towards libconsensus work.<br><br>Instead of signing any bitcoin transacti=
on that the hardware wallet is given, the hardware should be responsible fo=
r running bitcoin validation rules and business logic, which I recommend fo=
r everyone, not only businesses. Without running business logic and bitcoin=
validation rules, the actual bitcoin history on the blockchain could be a =
very different reality from what the hardware thinks is happening. Using a =
different out-of-band communication channel, the hardware could query for i=
nformation from another database in another trust root, which would be usef=
ul for business logic to validate against.</div><div class=3D"gmail_extra">=
<br></div><div class=3D"gmail_extra">As for a screen, I consider that somew=
hat limited because you only get text output (and I don't know if I can=
reasonably suggest QR codes here). With a screen, you are limited to text =
output, which can compromise privacy of the device's operations and inf=
o about the wallet owner. An alternative would be to have a dedicated port =
that is responsibly only for sending out data encrypted to the key of the w=
allet owner, to report information such as whatever the hardware's tran=
saction planner has decided, or to report about the state of the device, st=
ate of the bitcoin validation rules, or any accounting details, etc. Additi=
onally, even a signed transaction should be encrypted to the key of the dev=
ice owner because a signed transaction can be harmless as long as the owner=
still has the ability to control whether the signed transaction is broadca=
sted to the network. It's "separation of concerns" for transa=
ction signing and decrypting a signed transaction should be unrelated and u=
ncoupled.<br><br>Also I am eager to see what the community proposes regardi=
ng signed and authenticated payment requests.<br><br>((insert here general =
promotional statement regarding the value of reusable checklists used durin=
g every signing ritual ceremony))<br><br></div><div class=3D"gmail_extra"><=
div class=3D"gmail_signature" data-smartmail=3D"gmail_signature">- Bryan<br=
><a href=3D"http://heybryan.org/" target=3D"_blank">http://heybryan.org/</a=
><br>1 512 203 0507</div>
</div></div>
--001a113e4c12ff0f00053a48be57--
|
