From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from sog-mx-3.v43.ch3.sourceforge.com ([172.29.43.193] helo=mx.sourceforge.net) by sfs-ml-3.v29.ch3.sourceforge.com with esmtp (Exim 4.76) (envelope-from ) id 1UV8hK-0008Cz-6p for bitcoin-development@lists.sourceforge.net; Wed, 24 Apr 2013 23:01:58 +0000 Received-SPF: pass (sog-mx-3.v43.ch3.sourceforge.com: domain of gmail.com designates 209.85.212.47 as permitted sender) client-ip=209.85.212.47; envelope-from=jeremy.spilman@gmail.com; helo=mail-vb0-f47.google.com; Received: from mail-vb0-f47.google.com ([209.85.212.47]) by sog-mx-3.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128) (Exim 4.76) id 1UV8hJ-0000FL-9A for bitcoin-development@lists.sourceforge.net; Wed, 24 Apr 2013 23:01:58 +0000 Received: by mail-vb0-f47.google.com with SMTP id x13so2137575vbb.6 for ; Wed, 24 Apr 2013 16:01:51 -0700 (PDT) MIME-Version: 1.0 X-Received: by 10.58.173.131 with SMTP id bk3mr25803670vec.48.1366844511659; Wed, 24 Apr 2013 16:01:51 -0700 (PDT) Received: by 10.58.137.197 with HTTP; Wed, 24 Apr 2013 16:01:51 -0700 (PDT) Date: Wed, 24 Apr 2013 16:01:51 -0700 Message-ID: From: Jeremy Spilman To: bitcoin-development@lists.sourceforge.net Content-Type: multipart/alternative; boundary=047d7b677b3e94e32d04db234944 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 (jeremy.spilman[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: 1UV8hJ-0000FL-9A Subject: [Bitcoin-development] Cold Signing Payment Requests X-BeenThere: bitcoin-development@lists.sourceforge.net X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Apr 2013 23:01:58 -0000 --047d7b677b3e94e32d04db234944 Content-Type: text/plain; charset=ISO-8859-1 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 --047d7b677b3e94e32d04db234944 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable 
Payment Protoco=
l 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 therefo=
re 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, an=
d the payer sees a 'green box' but the coins go to the attacker. Th=
e question... is there a way to sign something once, with a key kept offlin=
e, which verifies the address in the Payment Request belongs to the payee?

1) Given a 'parent' cert which is kept offline, and a child certifi=
cate of 'parent' which is kept hot on the payment server.

2) Given a public key and chain code { pubKey, code } under BIP32 we genera=
te child keys as I =3D HMAC(code, Kpar || i), Ki =3D 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 c=
ould also just be randomly generated.

Any I[0:32] included in the Payment Request, even if it is tampered with, w=
ill correspond to an address for which the payee can calculate the correspo=
nding private key.
So the idea is your 'most trusted' cert would be use=
d offline only to sign a Kpar once, and a 'less trusted' cert would=
 be used to sign the other stuff, like 'amount', 'description&#=
39;, '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 co=
nstraint, 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 longe=
r a standard certificate chain. I would love to hear a better idea.<=
br>

Any comme=
nts if this is something worth pursuing? I think there are definitely benef=
its if merchants can keep the key signing the address offline.
Thanks,<=
/font>
--Jeremy
--047d7b677b3e94e32d04db234944--