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
|
Received: from sog-mx-2.v43.ch3.sourceforge.com ([172.29.43.192]
helo=mx.sourceforge.net)
by sfs-ml-2.v29.ch3.sourceforge.com with esmtp (Exim 4.76)
(envelope-from <etotheipi@gmail.com>) id 1UV8nO-00024x-Bu
for bitcoin-development@lists.sourceforge.net;
Wed, 24 Apr 2013 23:08:14 +0000
Received-SPF: pass (sog-mx-2.v43.ch3.sourceforge.com: domain of gmail.com
designates 209.85.128.54 as permitted sender)
client-ip=209.85.128.54; envelope-from=etotheipi@gmail.com;
helo=mail-qe0-f54.google.com;
Received: from mail-qe0-f54.google.com ([209.85.128.54])
by sog-mx-2.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128)
(Exim 4.76) id 1UV8nN-0007XK-3R
for bitcoin-development@lists.sourceforge.net;
Wed, 24 Apr 2013 23:08:14 +0000
Received: by mail-qe0-f54.google.com with SMTP id s14so1675979qeb.27
for <bitcoin-development@lists.sourceforge.net>;
Wed, 24 Apr 2013 16:08:07 -0700 (PDT)
X-Received: by 10.49.35.132 with SMTP id h4mr23603597qej.29.1366844887636;
Wed, 24 Apr 2013 16:08:07 -0700 (PDT)
Received: from [192.168.1.85] (c-76-111-96-126.hsd1.md.comcast.net.
[76.111.96.126])
by mx.google.com with ESMTPSA id b13sm7541090qai.3.2013.04.24.16.08.06
for <bitcoin-development@lists.sourceforge.net>
(version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128);
Wed, 24 Apr 2013 16:08:06 -0700 (PDT)
Message-ID: <517865CF.9050306@gmail.com>
Date: Wed, 24 Apr 2013 19:07:59 -0400
From: Alan Reiner <etotheipi@gmail.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
rv:17.0) Gecko/20130329 Thunderbird/17.0.5
MIME-Version: 1.0
To: bitcoin-development@lists.sourceforge.net
References: <CA+CODZFNo6KRW-wKvVbnesQMEm9k5MEoTPEPXepCKKnzt+1E6g@mail.gmail.com>
In-Reply-To: <CA+CODZFNo6KRW-wKvVbnesQMEm9k5MEoTPEPXepCKKnzt+1E6g@mail.gmail.com>
X-Enigmail-Version: 1.5.1
Content-Type: multipart/alternative;
boundary="------------010608060408050802030806"
X-Spam-Score: -0.6 (/)
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 FREEMAIL_FROM Sender email is commonly abused enduser mail provider
(etotheipi[at]gmail.com)
-0.0 SPF_PASS SPF: sender matches SPF record
1.0 HTML_MESSAGE BODY: HTML included in message
-0.1 DKIM_VALID_AU Message has a valid DKIM or DK signature from
author's domain
0.1 DKIM_SIGNED Message has a DKIM or DK signature,
not necessarily valid
-0.1 DKIM_VALID Message has at least one valid DKIM or DK signature
X-Headers-End: 1UV8nN-0007XK-3R
Subject: Re: [Bitcoin-development] Cold Signing Payment Requests
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: Wed, 24 Apr 2013 23:08:14 -0000
This is a multi-part message in MIME format.
--------------010608060408050802030806
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
There's some good discussion about that here:
https://bitcointalk.org/index.php?topic=130749.msg1398972#msg1398972
thanke came up with this first, and then I reinvented it, and now you
have. But the thread has some good discussion about how to move
forward. I'm a big fan of putting the lower-case root hash160 in your
subdomain and getting and SSL cert for that. Feel free to contribute to
that thread if you find it compelling.
-Alan
On 04/24/2013 07:01 PM, Jeremy Spilman wrote:
> Payment Protocol uses x509 certs to sign a Payment Request. This allows wallets to display meta-data from the cert to the payer instead of the address, which should make it easier to verify where money is being sent, and make it harder for an attacker to change the address displayed to a user so that coins are not sent to the wrong place.
>
> The difficulty is that Payment Requests must be generated live, and therefore the key used to sign those requests must also be live, exposing the key to theft similar to a hot wallet. Steal the key, forge payment requests, and the payer sees a 'green box' but the coins go to the attacker. The question... is there a way to sign something once, with a key kept offline, which verifies the address in the Payment Request belongs to the payee?
>
> 1) Given a 'parent' cert which is kept offline, and a child certificate of 'parent' which is kept hot on the payment server.
>
> 2) Given a public key and chain code { pubKey, code } under BIP32 we generate child keys as I = HMAC(code, Kpar || i), Ki = I[0:32] * Kpar.
>
> 3) If we sign Kpar with the parent cert's key offline, we can sign the remaining less critical data (address, I[0:32], amount, description, etc.) with the child cert's key.
>
> 4) The payer verifies Kpar, and verifies the address by calculating Hash160(Kpar * I[0:32])
>
> In fact, there's no requirement to use BIP32 to calculate I[0:32], it could also just be randomly generated.
>
> Any I[0:32] included in the Payment Request, even if it is tampered with, will correspond to an address for which the payee can calculate the corresponding private key.
> So the idea is your 'most trusted' cert would be used offline only to sign a Kpar once, and a 'less trusted' cert would be used to sign the other stuff, like 'amount', 'description', 'merchant-data', and the 'I[0:32]' as well.
> I'm not an expert on x509, but I imagine the trouble is, how does the payer know which cert is which? I was originally thinking the parent cert would be an intermediate CA cert used to sign the child cert, but I guess good look getting one of those, even with a name constraint, from a Root CA. I'm not sure if you can do better than just a 'convention' such as one is an EV cert and one is not. Perhaps the less trusted cert is actually self-signed using the EV cert, but that requires special validation, since its no longer a standard certificate chain. I would love to hear a better idea.
>
> Any comments if this is something worth pursuing? I think there are definitely benefits if merchants can keep the key signing the address offline.
> Thanks,
> --Jeremy
>
>
> ------------------------------------------------------------------------------
> Try New Relic Now & We'll Send You this Cool Shirt
> New Relic is the only SaaS-based application performance monitoring service
> that delivers powerful full stack analytics. Optimize and monitor your
> browser, app, & servers with just a few lines of code. Try New Relic
> and get this awesome Nerd Life shirt! http://p.sf.net/sfu/newrelic_d2d_apr
>
>
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
--------------010608060408050802030806
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
<html>
<head>
<meta content="text/html; charset=ISO-8859-1"
http-equiv="Content-Type">
</head>
<body text="#000000" bgcolor="#FFFFFF">
There's some good discussion about that here:<br>
<br>
<meta http-equiv="content-type" content="text/html;
charset=ISO-8859-1">
<a
href="https://bitcointalk.org/index.php?topic=130749.msg1398972#msg1398972">https://bitcointalk.org/index.php?topic=130749.msg1398972#msg1398972</a><br>
<br>
thanke came up with this first, and then I reinvented it, and now
you have. But the thread has some good discussion about how to move
forward. I'm a big fan of putting the lower-case root hash160 in
your subdomain and getting and SSL cert for that. Feel free to
contribute to that thread if you find it compelling.<br>
<br>
-Alan<br>
<br>
<br>
<div class="moz-cite-prefix">On 04/24/2013 07:01 PM, Jeremy Spilman
wrote:<br>
</div>
<blockquote
cite="mid:CA+CODZFNo6KRW-wKvVbnesQMEm9k5MEoTPEPXepCKKnzt+1E6g@mail.gmail.com"
type="cite">
<div dir="ltr">
<pre style="color:rgb(0,0,0);word-wrap:break-word;white-space:pre-wrap"><font face="arial, helvetica, sans-serif">Payment Protocol uses x509 certs to sign a Payment Request. This allows wallets to display meta-data from the cert to the payer instead of the address, which should make it easier to verify where money is being sent, and make it harder for an attacker to change the address displayed to a user so that coins are not sent to the wrong place.
The difficulty is that Payment Requests must be generated live, and therefore the key used to sign those requests must also be live, exposing the key to theft similar to a hot wallet. Steal the key, forge payment requests, and the payer sees a 'green box' but the coins go to the attacker. The question... is there a way to sign something once, with a key kept offline, which verifies the address in the Payment Request belongs to the payee?
1) Given a 'parent' cert which is kept offline, and a child certificate of 'parent' which is kept hot on the payment server.
2) Given a public key and chain code { pubKey, code } under BIP32 we generate child keys as I = HMAC(code, Kpar || i), Ki = I[0:32] * Kpar.
3) If we sign Kpar with the parent cert's key offline, we can sign the remaining less critical data (address, I[0:32], amount, description, etc.) with the child cert's key.
4) The payer verifies Kpar, and verifies the address by calculating Hash160(Kpar * I[0:32])
In fact, there's no requirement to use BIP32 to calculate I[0:32], it could also just be randomly generated.
Any I[0:32] included in the Payment Request, even if it is tampered with, will correspond to an address for which the payee can calculate the corresponding private key.</font></pre>
<pre style="word-wrap:break-word"><span style="white-space:pre-wrap;color:rgb(0,0,0)"><font face="arial, helvetica, sans-serif">So the idea is your 'most trusted' cert would be used offline only to sign a Kpar once, and a 'less trusted' cert would be used to sign the other stuff, like 'amount', 'description', 'merchant-data', and the 'I[0:32]' as well.</font></span></pre>
<pre style="word-wrap:break-word"><span style="color:rgb(0,0,0);font-family:arial,helvetica,sans-serif;white-space:pre-wrap">I'm not an expert on x509, but I imagine the trouble is, how does the payer know which cert is which?</span><span style="font-family:arial;white-space:pre-wrap;color:rgb(0,0,0)"><font face="arial, helvetica, sans-serif"> I was originally thinking the parent cert would be an intermediate CA cert used to sign the child cert, but I guess good look getting one of those, even with a name constraint, from a Root CA.</font></span><span style="color:rgb(0,0,0);font-family:arial,helvetica,sans-serif;white-space:pre-wrap"> I'm not sure if you can do better than just a 'convention' such as one is an EV cert and one is not. Perhaps the less trusted cert is actually self-signed using the EV cert, but that requires special validation, since its no longer a standard certificate chain. I would love to hear a better idea.</span>
</pre>
<pre style="word-wrap:break-word"><font face="arial, helvetica, sans-serif" color="#000000"><span style="white-space:pre-wrap">Any comments if this is something worth pursuing? I think there are definitely benefits if merchants can keep the key signing the address offline.</span></font></pre>
<pre style="word-wrap:break-word"><font face="arial, helvetica, sans-serif" color="#000000"><span style="white-space:pre-wrap">Thanks,</span></font>
<span style="white-space:pre-wrap;color:rgb(0,0,0);font-family:arial,helvetica,sans-serif">--Jeremy</span></pre>
</div>
<br>
<fieldset class="mimeAttachmentHeader"></fieldset>
<br>
<pre wrap="">------------------------------------------------------------------------------
Try New Relic Now & We'll Send You this Cool Shirt
New Relic is the only SaaS-based application performance monitoring service
that delivers powerful full stack analytics. Optimize and monitor your
browser, app, & servers with just a few lines of code. Try New Relic
and get this awesome Nerd Life shirt! <a class="moz-txt-link-freetext" href="http://p.sf.net/sfu/newrelic_d2d_apr">http://p.sf.net/sfu/newrelic_d2d_apr</a></pre>
<br>
<fieldset class="mimeAttachmentHeader"></fieldset>
<br>
<pre wrap="">_______________________________________________
Bitcoin-development mailing list
<a class="moz-txt-link-abbreviated" href="mailto:Bitcoin-development@lists.sourceforge.net">Bitcoin-development@lists.sourceforge.net</a>
<a class="moz-txt-link-freetext" href="https://lists.sourceforge.net/lists/listinfo/bitcoin-development">https://lists.sourceforge.net/lists/listinfo/bitcoin-development</a>
</pre>
</blockquote>
<br>
</body>
</html>
--------------010608060408050802030806--
|
