public inbox for bitcoindev@googlegroups.com
 help / color / mirror / Atom feed
* [Bitcoin-development] Cold Signing Payment Requests
@ 2013-04-24 23:01 Jeremy Spilman
  2013-04-24 23:07 ` Alan Reiner
  0 siblings, 1 reply; 19+ messages in thread
From: Jeremy Spilman @ 2013-04-24 23:01 UTC (permalink / raw)
  To: bitcoin-development

[-- Attachment #1: Type: text/plain, Size: 2585 bytes --]

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

[-- Attachment #2: Type: text/html, Size: 3754 bytes --]

^ permalink raw reply	[flat|nested] 19+ messages in thread

end of thread, other threads:[~2013-05-06 21:30 UTC | newest]

Thread overview: 19+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
     [not found] <mailman.38128.1366844895.4905.bitcoin-development@lists.sourceforge.net>
2013-04-25  9:58 ` [Bitcoin-development] Cold Signing Payment Requests Timo Hanke
2013-04-25 10:05   ` Mike Hearn
2013-04-25 10:28     ` Timo Hanke
2013-04-25 10:45       ` Mike Hearn
2013-04-25 10:52         ` Mike Hearn
2013-04-25 11:55         ` Timo Hanke
     [not found]         ` <FDF215AE-F9A4-4EE3-BDC9-0A4EF027423A@swipeclock.com>
2013-04-25 14:31           ` Mike Hearn
2013-04-25 19:12             ` Jeremy Spilman
2013-04-26  1:07               ` Gavin Andresen
2013-04-28 18:03                 ` Timo Hanke
2013-04-29 18:40                   ` Jeremy Spilman
2013-04-30  9:17                     ` Mike Hearn
2013-04-30 11:32                       ` Jouke Hofman
2013-04-30 13:14                         ` Gavin Andresen
2013-04-30 17:17                           ` Jeremy Spilman
2013-05-06 21:29                             ` Peter Todd
2013-04-24 23:01 Jeremy Spilman
2013-04-24 23:07 ` Alan Reiner
2013-04-25  9:08   ` Mike Hearn

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox