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
|
Received: from sog-mx-3.v43.ch3.sourceforge.com ([172.29.43.193]
helo=mx.sourceforge.net)
by sfs-ml-1.v29.ch3.sourceforge.com with esmtp (Exim 4.76)
(envelope-from <pete@petertodd.org>) id 1V3EEt-0006n1-Hx
for bitcoin-development@lists.sourceforge.net;
Sat, 27 Jul 2013 23:49:31 +0000
Received-SPF: pass (sog-mx-3.v43.ch3.sourceforge.com: domain of petertodd.org
designates 62.13.149.78 as permitted sender)
client-ip=62.13.149.78; envelope-from=pete@petertodd.org;
helo=outmail149078.authsmtp.net;
Received: from outmail149078.authsmtp.net ([62.13.149.78])
by sog-mx-3.v43.ch3.sourceforge.com with esmtp (Exim 4.76)
id 1V3EEr-0005UY-68 for bitcoin-development@lists.sourceforge.net;
Sat, 27 Jul 2013 23:49:31 +0000
Received: from mail-c233.authsmtp.com (mail-c233.authsmtp.com [62.13.128.233])
by punt8.authsmtp.com (8.14.2/8.14.2/Kp) with ESMTP id r6RNnNBH033018
for <bitcoin-development@lists.sourceforge.net>;
Sun, 28 Jul 2013 00:49:23 +0100 (BST)
Received: from savin (76-10-178-109.dsl.teksavvy.com [76.10.178.109])
(authenticated bits=128)
by mail.authsmtp.com (8.14.2/8.14.2/) with ESMTP id r6RNnIm7092215
(version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO)
for <bitcoin-development@lists.sourceforge.net>;
Sun, 28 Jul 2013 00:49:21 +0100 (BST)
Date: Sat, 27 Jul 2013 19:49:18 -0400
From: Peter Todd <pete@petertodd.org>
To: Bitcoin Dev <bitcoin-development@lists.sourceforge.net>
Message-ID: <20130727234918.GA11635@savin>
MIME-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha256;
protocol="application/pgp-signature"; boundary="4Ckj6UjgE2iN1+kY"
Content-Disposition: inline
User-Agent: Mutt/1.5.21 (2010-09-15)
X-Server-Quench: 28e63ef0-f717-11e2-a49c-0025907707a1
X-AuthReport-Spam: If SPAM / abuse - report it at:
http://www.authsmtp.com/abuse
X-AuthRoute: OCd2Yg0TA1ZNQRgX IjsJECJaVQIpKltL GxAVJwpGK10IU0Fd
P1hXKl1LNVAaWXld WiVPGEoXDxgzCjYj NEgGOBsDNw4AXQ11
Kg0VXVBSFQZ4ARwL AhcUUBg8cANYeX5u ZEFqQHFbVVt/fUFi
QwAWEw94Ox49b2AW UkJZck1VcgZKfFFH YgV5VyZbYXhRYXtn
WlZqMmp0NGkOI2EN GltQfApNHh5UF2cq ew8FVTsmFlECXW0s
JhgiJ0JUA0cNMg01 N1ZkRVMdPloKAxZF AEZXDDQx
X-Authentic-SMTP: 61633532353630.1021:706
X-AuthFastPath: 0 (Was 255)
X-AuthSMTP-Origin: 76.10.178.109/587
X-AuthVirus-Status: No virus detected - but ensure you scan with your own
anti-virus system.
X-Spam-Score: -1.5 (-)
X-Spam-Report: Spam Filtering performed by mx.sourceforge.net.
See http://spamassassin.org/tag/ for more details.
-1.5 SPF_CHECK_PASS SPF reports sender host as permitted sender for
sender-domain
-0.0 SPF_PASS SPF: sender matches SPF record
X-Headers-End: 1V3EEr-0005UY-68
Subject: [Bitcoin-development] Two factor wallet with one-time-passwords
X-BeenThere: bitcoin-development@lists.sourceforge.net
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: <bitcoin-development.lists.sourceforge.net>
List-Unsubscribe: <https://lists.sourceforge.net/lists/listinfo/bitcoin-development>,
<mailto:bitcoin-development-request@lists.sourceforge.net?subject=unsubscribe>
List-Archive: <http://sourceforge.net/mailarchive/forum.php?forum_name=bitcoin-development>
List-Post: <mailto:bitcoin-development@lists.sourceforge.net>
List-Help: <mailto:bitcoin-development-request@lists.sourceforge.net?subject=help>
List-Subscribe: <https://lists.sourceforge.net/lists/listinfo/bitcoin-development>,
<mailto:bitcoin-development-request@lists.sourceforge.net?subject=subscribe>
X-List-Received-Date: Sat, 27 Jul 2013 23:49:31 -0000
--4Ckj6UjgE2iN1+kY
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable
Gavin Andresen recently suggested a design for a wallet protected by
two-factor authentication via one-time-passwords with the aid of a
third-party service to counter-sign 2-of-2 protected wallets.(1) The
design is useful when the user can't sign transactions on a second
device, such as a phone, but can provide one-time-passwords. (possibly
generated on a smart phone or stored on paper) However involving a
third-party has privacy and availability risks. Here is an alternate
design, also using one-time-passwords, that removes the requirement for
a third-party, along with other advantages and disadvantages.
User experience
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
The user has a wallet with a separate balances for savings and a smaller
day-to-day spending amount. Transactions spending the day-to-day balance
do not need two-factor authorization, while spending the savings balance
does. As the day-to-day balance becomes low the user is able to top it
up by authorizing the movement of discrete multiples of some amount from
savings to spending. That authorization requires one one-time-password
per multiple being moved.
Implementation
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
Savings use P2SH outputs matching the following scriptPubKey form:
HASH160 <H(nonce_i)> EQUALVERIFY <pubkey> CHECKSIG
spent with:
<sig> <nonce_i>
The way the pubkey/seckey is generated is unimportant, although some
kind of deterministic scheme is preferable. Nonces on the other hand are
generated deterministically using a counter-based one-time-password
scheme that takes some secret seed and an integer i. A large number of
H(nonce_n) are generated in advance and moved to the computer holding
the wallet. (generating them on that computer is also possible, but
obviously risks the secret seed being compromised)
A brute-force attack to spend a signed txout requires the attacker to
find a preimage, thus the security level is the number of bits for the
nonce; 64 bits is sufficient. (remember the birthday attack doesn't
apply here) Unfortunately the most popular one-time-password scheme, the
RFC6238 used in Google Authenticator, only outputs six digits numbers,
well below the security level required. (Google Auth is generally used
in a time-mode, but also has a counter mode)
The older RFC2289 however turns the passwords into six words from a 2048
entry wordlist, giving a 64-bit nonce with 2-bits of checksum. RFC2289
implementations are also well suited to paper print-outs and generally
make it easy to do so. RFC2289 as written uses SHA1, however the
suspected vulnerabilities in SHA1 are partial-preimage collisions, not
relevant in this application.
In a sense the user is now acting as an oracle answering the question of
whether or not funds should be allowed to move from savings to spending,
without being responsible for where those funds are allowed to go. As
described in (2) it is easy to create a whole range of conditions by
using multiple nonces if the use-case demanded. For instance a corporate
environment may want multiple parties to be required to authorize the
funds to move, possible with multiple nonces.
It's interesting to note how in some cases it may be preferable that the
authorization is simply authorization to spend without any other
involvement. Here the party acting as an oracle not only doesn't need to
know where funds are going but can even authorize the spend in advance
without two-way communication - possibly even prior to the funds being
received in the first place. This authorization can be easily given
manually, for instance over the phone, and the accounting to keep track
of the total amount authorized can be easily done with pen and paper -
something not possible with CHECKMULTISIG wallets.
Funding the wallet
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
As with any multi-party wallet receiving funds must also be handled
carefully to ensure an attacker can't fool the user into giving the
sender the wrong address. This requires the involvement of all parties
required to authorize an outgoing payment. In addition here the
protection only works if funds sent to the wallet are split up into the
discrete authorization amounts the user wishes. (possibly with more than
one amount level)
There hasn't been as much thought put into these systems as there has
been on payment protocols between a customer and a merchant, but the
basic idea is to have more than one device participate in the generation
of payment request signed somehow. For fund splitting the request can be
that the funds are paid to multiple txouts in one go. For recurring
payments the request could have some mechanism for multiple addresses to
be specified for future use. Fall-back to a standard multi-signature
wallet is possible as well.
More research is needed.
1) https://gist.github.com/gavinandresen/5616606
2) https://bitcointalk.org/index.php?topic=3D260898.msg2804469#msg2804469
--=20
'peter'[:-1]@petertodd.org
000000000000006447c7d824b1952ba36ad1f34351be6904c30247591156460c
--4Ckj6UjgE2iN1+kY
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: Digital signature
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)
iQEcBAEBCAAGBQJR9Fx9AAoJECSBQD2l8JH7XCcH/jhth4M6FQL1jxmlI06F/U5B
QFpjMXAsP5KkaYFVQgZJ5sU4ugrmA8OYtKpAMt1lnrFnxfTS0wbXsIpGdRGs84n5
9pkb1KmnCm/z7P+maLsZ7spCqCDqBqNVP5HpFhqK5ws2OWGpj3JpSiaO2mgRQUXO
XoBHrQvH8z3fBtQGxYZyCeu+9xnEFnE4VaQyDuFf0818SqnFIV9ZDqDTUjDYP5yX
jzlx9wY2xZGJ5x5kwgHwuJlor1qxv20x1HEyTdsAj69gtBGJh2LsdbZECndsrha4
tUESZU71n1NxOK/AATut+y31R0B+Olq8oJivPifnmnTRDO0VP4IZncGhDx61KFo=
=sjwC
-----END PGP SIGNATURE-----
--4Ckj6UjgE2iN1+kY--
|
