Re: [Bitcoin-development] Cold Signing Payment Requests

2013-05-06 Thread Peter Todd
On Tue, Apr 30, 2013 at 10:17:23AM -0700, Jeremy Spilman wrote:
 [Aside] I was reading Peter's fidelitybond writeup for his idea on contract
 value accounting, and he points to Stephan's post from last September on
 payer-encoded metadata (
 https://bitcointalk.org/index.php?topic=108423.msg1178438#msg1178438) which
 Timo applies here. As a relative newcomer, this is what I am loving most
 about Bitcoin.

The widespread disclosure we do is a good thing for sure.

Keep in mind that Bitcoin is brand new technology, and brand new fields
tend to get lots of people coming in and trying to patent them. Public
disclosure, and bitcointalk, the email list, and github all count, is a
valuable tool to ward off potential threats in the future if it ever
comes to that.

FWIW it might not be a bad idea to see if archive.org would accept some
of the key documentation like the development section of the forum, the
email list archives, and the irc logs. Some issues, especially on the
forum, with people's ability to edit posts after the fact, but we're
breaking new ground here and the history should be archived.

-- 
'peter'[:-1]@petertodd.org
00f5a3175efc20cdac41f848d47dc7d00debe821ebfa69f91db9


signature.asc
Description: Digital signature
--
Learn Graph Databases - Download FREE O'Reilly Book
Graph Databases is the definitive new guide to graph databases and 
their applications. This 200-page book is written by three acclaimed 
leaders in the field. The early access version is available now. 
Download your free book today! http://p.sf.net/sfu/neotech_d2d_may___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development


Re: [Bitcoin-development] Cold Signing Payment Requests

2013-04-30 Thread Mike Hearn
  Backing up a step, I'm not sure what the threat model is for signing the
 refund address? The same process that's signing the transaction is doing an
 HTTPS POST with the refund address.


It's a real threat, albeit an exotic one. The threat model is a malware
compromised host, with a wallet (possibly a low power hardware wallet like
a Trezor) that can understand the payment protocol and sign transactions,
but maybe not do a whole lot more than that. For instance, probably it
cannot do HTTPS connections itself. So a virus on the host could swap the
refund address for one that is owned by the attacker, and then try to make
the merchant issue an automatic refund, thus bouncing the funds back off
the merchant to the them.

If there are merchants that offer large, automatic refunds, it could be an
issue. I'm not sure how common that might be in reality. Steven or Tony
would know. Timo's protocol is an interesting solution, but again, at this
point the feature set for v1 is pretty much locked down.
--
Introducing AppDynamics Lite, a free troubleshooting tool for Java/.NET
Get 100% visibility into your production application - at no cost.
Code-level diagnostics for performance bottlenecks with 2% overhead
Download for free and get started troubleshooting in minutes.
http://p.sf.net/sfu/appdyn_d2d_ap1___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development


Re: [Bitcoin-development] Cold Signing Payment Requests

2013-04-30 Thread Jouke Hofman
We do automatic refunds. When bitcoins arrive after an offer has expired
(which happens quite often with webwallets that don't broadcast
transactions immediately), we return all the bitcoins to a specified
bitcoin-address. This happens a couple of times per day and can amount
to a couple of hundred bitcoins per offer.



On 04/30/2013 11:17 AM, Mike Hearn wrote:

 If there are merchants that offer large, automatic refunds, it could be
 an issue. I'm not sure how common that might be in reality. Steven or
 Tony would know. Timo's protocol is an interesting solution, but again,
 at this point the feature set for v1 is pretty much locked down.

--
Introducing AppDynamics Lite, a free troubleshooting tool for Java/.NET
Get 100% visibility into your production application - at no cost.
Code-level diagnostics for performance bottlenecks with 2% overhead
Download for free and get started troubleshooting in minutes.
http://p.sf.net/sfu/appdyn_d2d_ap1
___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development


Re: [Bitcoin-development] Cold Signing Payment Requests

2013-04-30 Thread Gavin Andresen
RE: Timo's proposal for protecting the refund address:

Seems to me there are two risks:

1) The risk that the merchant's web server will be compromised and the
attacker will redirect refunds
2) The risk that the merchant will miss payments because they miss a POST
to the payment_url (maybe the customer's machine crashes during the HTTPS
handshake)

If payments are a lot more common than refunds, then (2) will outweigh (1).

I also think an attacker who compromises the front-end web server would
probably just have it start generating plain-old pay-to-bitcoin-address
payment requests, and hope that lots of customers pay them directly before
the attack is discovered.

-- 
--
Gavin Andresen
--
Introducing AppDynamics Lite, a free troubleshooting tool for Java/.NET
Get 100% visibility into your production application - at no cost.
Code-level diagnostics for performance bottlenecks with 2% overhead
Download for free and get started troubleshooting in minutes.
http://p.sf.net/sfu/appdyn_d2d_ap1___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development


Re: [Bitcoin-development] Cold Signing Payment Requests

2013-04-30 Thread Jeremy Spilman
 1) The risk that the merchant's web server will be compromised and the
attacker will redirect refunds
 2) The risk that the merchant will miss payments because they miss a POST
to the payment_url (maybe the customer's machine crashes during the HTTPS
handshake)
 If payments are a lot more common than refunds, then (2) will outweigh
(1).

I think that's oversimplifying.  (1) is theft, (2) is payment processing.
Reliable payment processing with refund handling is not simple nor free,
but it should be secure. The cost of (2) depends primarily on the failure
rate, which we can only guess at this point, and secondarily on how much
manual intervention is required to recover.

(2) is perhaps more of a problem if wallets broadcast before POST. It's
trading one failure mode (funds sent but not claimed) for another (coins
marked as spent but not). Either way, you fix it by just retrying the POST.
But only with Transmit-After-ACK can the payer's wallet detect the failure
automatically, and even recover automatically (simply unlock the outputs,
or to be sure, spend them back to self).

Since merchants get to choose whether to have a POST url, they get to
decide if the cost of keeping their server up is worth it. I think
eventually there are enough benefits to Transmit-After-ACK that it will
become a supported use case.

Thanks Mike for explaining the threat.

[Aside] I was reading Peter's fidelitybond writeup for his idea on contract
value accounting, and he points to Stephan's post from last September on
payer-encoded metadata (
https://bitcointalk.org/index.php?topic=108423.msg1178438#msg1178438) which
Timo applies here. As a relative newcomer, this is what I am loving most
about Bitcoin.
--
Introducing AppDynamics Lite, a free troubleshooting tool for Java/.NET
Get 100% visibility into your production application - at no cost.
Code-level diagnostics for performance bottlenecks with 2% overhead
Download for free and get started troubleshooting in minutes.
http://p.sf.net/sfu/appdyn_d2d_ap1___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development


Re: [Bitcoin-development] Cold Signing Payment Requests

2013-04-29 Thread Jeremy Spilman
It's neat to use the payment address as an implicit signature by hashing
something and multiplying it into the payee's pubKey.

 One downside is that it complicates the merchant's wallet. In this case
the payment is going to a pseudo-random address which the merchant will
have to explicitly add to their wallet, complicating backups, etc.

 The other challenge is how to handle an error when you POST to the
payment_url. In the original spec, the payer would only broadcast the
transaction themselves if there wasn't a payment_url. In the current
version it looks like the payer will broadcast the transaction(s) either
way. I only saw some of the discussions around this, but I think part of
the problem is what state do you put the payer's wallet into if you POST a
Payment and don't get a PaymentAck? If the payer always broadcasts the
transaction, then wallet state becomes obvious. With your proposal you
would not want the payer to broadcast the transaction without a PaymentAck,
since you need the merchant to acknowledge they know where to look for the
payment.

 Backing up a step, I'm not sure what the threat model is for signing the
refund address? The same process that's signing the transaction is doing an
HTTPS POST with the refund address. If an attacker can defeat that, then
they can just redirect the payment in the first place. The only benefit I
can think of is the payer can prove what refund address they specified with
the payment.

 Wouldn't it be easier to just get the merchant to sign the PaymentAck?
Technically they already are signing it, but a TLS stream probably isn't
the most convenient way to capture that.
--
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


Re: [Bitcoin-development] Cold Signing Payment Requests

2013-04-25 Thread Mike Hearn
(for background: I did a lot of the design work with Gavin on the payment
protocol and suggested/prototyped using x.509 in the way we do).

So, I'm not a fan of weird hacks involving non-existent domain names.
There's a clean way to implement this and we decided to punt on it for v1
in order to get something shippable, but if you're volunteering ... :) then
indeed having a custom cert type that chains onto the end is the way to go.

It doesn't have to be X.509. It can just be a regular protocol buffer. Even
if we re-used X.509 it wouldn't be accepted by OpenSSL or any other SSL
stack, so it wouldn't buy us anything and it's not like ASN.1 is easy to
work with. Chaining an additional Bitcoin-specific cert onto the end also
solves the problem of delegation ... a lot of merchants are using BitPay
but probably don't want to share their SSL private keys with a third party.
That means today the payments would show up as paid to BitPay Inc which is
misleading and weird, they're just an intermediary. So if the merchant can
run a simple command line tool that you point to the private key, and it
spits out a signed protobuf that contains a new (ecdsa) public key and
saves the private key to a file, then you can send that cert and key off to
your payment processor. The identity is still taken from your CA cert but
the actual signing keys used are different.

Another use case - a company has a lot of roving sales agents, like in a
supermarket or waiters at a restaurant. The company wants the agents to be
able to sign with their corporate EV identity but the agents are not highly
trusted. So they can be issued a 24-hour expiring Bitcoin-specific cert at
the start of each working day and then they sign payment requests with that.
--
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


Re: [Bitcoin-development] Cold Signing Payment Requests

2013-04-25 Thread Timo Hanke
 So, I'm not a fan of weird hacks involving non-existent domain names.
 There's a clean way to implement this and we decided to punt on it for
 v1 in order to get something shippable, but if you're volunteering ...
 :) then indeed having a custom cert type that chains onto the end is
 the way to go.

Chaining a custom cert onto the end doesn't work, at least not if your
end is the SSL cert. Chaining it to the SSL cert defeats the OP's
intention of cold signing, as the SSL private key is usually kept
online, therefore can't be used to sign a pubkey that is supposed to
stay offline. Hence the idea of the hack, to get two independent
things signed by the CA in just one cert: 1) your SSL pubkey, 2) your
custom cert (by including its cryptograhic hash). This hack seems the
easiest possible solution.

It also seems the only solution if you want to stick with domain-names
as identifiers for the payment protocol (and I think you do). A cleaner
way would be to get a cert signed by your CA that contains an extended
bitcoin attribute in compliance with X.509, but this seems a little
far off.

So I am in favor of the hack (properly thought out where to place the
hash).

ps. In the long run I would of course like to see payee identities based
on alt-chains rather than domain-names plus CAs. But that's rather a
concern for v3 than v2. Of course, you can also chain custom certs to
non-SSL identities like PGP-keys. You probably don't want to do that,
but it would solve Melvin Carvalho's problem of sending to RSA keys
(assuming the RSA key holder previously published his custom cert with a
cert server). 

-- 
Timo Hanke
PGP AB967DA8, Key fingerprint = 1EFF 69BC 6FB7 8744 14DB  631D 1BB5 D6E3 AB96 
7DA8

--
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


Re: [Bitcoin-development] Cold Signing Payment Requests

2013-04-25 Thread Mike Hearn
 Chaining a custom cert onto the end doesn't work, at least not if your
 end is the SSL cert. Chaining it to the SSL cert defeats the OP's
 intention of cold signing, as the SSL private key is usually kept
 online, therefore can't be used to sign a pubkey that is supposed to
 stay offline.


What you wrote doesn't make any sense to me, sorry.

Yes, SSL private keys are kept online. That's irrelevant - the goal of all
this is not to protect against web server compromise. That's a pointless
goal to try and solve right now, because the SSL PKI cannot handle
compromised web servers and so neither can we (with v1 of the payments
spec).

The goal of this is to allow delegation of signing authority without giving
the delegate the SSL private key.
--
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


Re: [Bitcoin-development] Cold Signing Payment Requests

2013-04-25 Thread Timo Hanke
On Thu, Apr 25, 2013 at 12:05:06PM +0200, Mike Hearn wrote:
 Chaining a custom cert onto the end doesn't work, at least not if your
 end is the SSL cert. Chaining it to the SSL cert defeats the OP's
 intention of cold signing, as the SSL private key is usually kept
 online, therefore can't be used to sign a pubkey that is supposed to stay 
 offline.
i meant:  ^whose privkey is 
supposed to stay offline.

 the goal of all this is not to protect against web server compromise.

 The goal of this is to allow delegation of signing authority without giving 
 the
 delegate the SSL private key.

This is not how I understand the OP, which I said I was addressing:

 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?



 That's a pointless goal to try and solve right now, because the SSL
 PKI cannot handle compromised web servers and so neither can we (with
 v1 of the payments spec).

I don't think the OP intended to solve it right now, i.e. in v1. 

He differentiated between most trusted and less trusted keys
(certs). So he can clearly live with the SSL PKI being less trusted
for his purpose.  

-- 
Timo Hanke
PGP AB967DA8, Key fingerprint = 1EFF 69BC 6FB7 8744 14DB  631D 1BB5 D6E3 AB96 
7DA8

--
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


Re: [Bitcoin-development] Cold Signing Payment Requests

2013-04-25 Thread Mike Hearn

  That's a pointless goal to try and solve right now, because the SSL
  PKI cannot handle compromised web servers and so neither can we (with
  v1 of the payments spec).

 I don't think the OP intended to solve it right now, i.e. in v1.

 He differentiated between most trusted and less trusted keys
 (certs). So he can clearly live with the SSL PKI being less trusted
 for his purpose.


Yes, but my point is if the SSL key lives on the web server, and there are
CAs that issue you certs based on control of a web server at the given
domain name (there are), then you can simply issue yourself a new SSL cert
with whatever data in it you want and pose as the merchant.

So I don't see how you can have a payment request signing key that's safer
than an SSL key. As Jeremy notes, CAs will not issue you intermediate
certificates. Perhaps if one existed that would do the necessary things for
a reasonable price you could indeed give yourself an offline intermediate
cert and then use that to sign one cert for SSL and another for payment
request signing, but as far as anyone is aware no such CA exists.

The interesting case is where the thing signing payment requests is less
trusted than the web server. The scenario you're trying to solve is the
inverse - the payment request signing process is more trusted than the web
server. But unless/until the CA landscape changes we don't have a way to
implement that.
--
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


Re: [Bitcoin-development] Cold Signing Payment Requests

2013-04-25 Thread Mike Hearn
On Thu, Apr 25, 2013 at 4:13 PM, Mike Caldwell mcaldw...@swipeclock.comwrote:

 I am not sure if my replies hit the list. If not, can anyone who sees this
 help?

 In the past, I have pre signed (with PGP) large batches of Bitcoin
 addresses for distribution on my server. This way, even in the event of
 compromise, there is no way someone could substitute an address of their
 own and have it have the same characteristics as other addresses I have
 signed.  The same general concept could be used to keep signing keys off
 the web server.

 Mike


I didn't see your other replies but got this one.

The assumption you made by doing that is that people can obtain your PGP
key. This leads to the question of how someone knows what your key is or
that you signed the list in the first place. The most obvious way is to go
to https://www.casascius.com/ and click My PGP key - but we already
failed at this point if your web server was hacked. I'd have to learn about
your cryptographic identity via some other secure channel, but usually that
doesn't exist.

Being able to survive web server hacks is intuitively attractive because
web servers tend to be so insecure. But unfortunately there doesn't seem to
be any good way to do this with todays infrastructure because for most
businesses, their website *is* their identity, and if a hacker controls
that they it's very hard for anyone (including CAs) to know that something
has gone wrong.

I think there are some simple mitigations we can use in the short term.

One is that wallets could count how many times you paid to addresses signed
by a particular cert. If you're a repeat customer and your wallet says You
have never paid this recipient before instead of You have paid this
recipient 4 times then you might be suspicious. Someone pointed out to me
that the current payment protocol has nothing to say on phishing using
confusible domains - this could help with that too, and it's easy to
implement. Of course it means you get reset whenever your certificate
expires and has to be renewed, and crying wolf is often worse than doing
nothing at all. So that's an issue.

With time there might be more complex solutions available, like extensions
to X.509/CA infrastructure (if bitcoin stays growing and popular). Also,
alternative PKIs like DNSSEC or the ePassport PKI might be useful. In your
case Mike you aren't really a company, you're trading under your own name,
so signing the key list under your legal identity is really the best
solution. It's just not easily available right now.
--
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


Re: [Bitcoin-development] Cold Signing Payment Requests

2013-04-25 Thread Jeremy Spilman
There are definitely ways to keep the pay-to address secure even if the web
server is compromised, just perhaps not perfectly clean standard X.509 ways
under the current ecosystem which would be easier for everyone to agree on.

 - If a more trusted cert is an EV end cert, and a less trusted is a DV end
cert (not chained off the EV) then it's easy for the wallet to distinguish
between the two, and they are both valid certs. EV signs pubKey offline, DV
used hot on the web server.
 - If the more trusted cert is an EV or DV end cert, and the less trusted
cert is chained off that end cert, it's technically 'invalid' so again its
obvious which one is more/less trusted, but it's easier for an attacker to
get their own DV end cert for your domain.
 - The third way is getting the pubKey into the cert attributes, such as
encoding the pubKey, or a fingerprint of the pubKey, as a Subject Alternate
Name, so the attacker would need to get their own cert to change the
address, meaning it's not as critical if your cert key is stolen.

On the wallet side, it comes down to additional validation code paths which
get triggered by some detection logic. For example, if you pass PubKey and
InvoiceID in the Payment Request, the wallet needs to know if it should
check for a Subject Alternate Name in the cert for a fingerprint of the
PubKey, how the fingerprint is calculated, and then verify the Address is
indeed PubKey * InvoiceID.  I think falsely rejecting a legacy Payment
Request would get the extra validation code path commented out pretty
quickly.

I really like Mike Hearn's idea of 'You have paid this recipient 4 times'
but also agree completely on the crying wolf due to expiration or
revocation. At least such a message could be based on the domain name only,
to try to prevent phishing with similar domain names, then there's no
expiration issue. Slightly more restrictive would be domain + CA, again not
considering expiration, but pinning the pay count to the CA seems to have
little downside and makes it harder for an attacker to get their own cert
for your domain if you choose your CA 'wisely'.

I assume the ship has sailed on v1, but if we can get consensus on how we
want this to work in the near-term, we can start prototyping it and maybe
get this available sooner than later. In any case we should be confirm v1
doesn't do anything to prevent this from working in a clean, extensible
manor, which I think means prototyping it and seeing the new Payment
Request is handled transparently by v1 code.

Right now I'm leaning towards writing a prototype using a single cert with
a fingerprint of PubKey in the Subject Alternate Name, and getting PubKey
and InvoiceID in the Payment Request.  Gavin, would the best way to work on
this be to just fork your code on Github?

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


Re: [Bitcoin-development] Cold Signing Payment Requests

2013-04-25 Thread Gavin Andresen
On Thu, Apr 25, 2013 at 3:12 PM, Jeremy Spilman jeremy.spil...@gmail.comwrote:

 Right now I'm leaning towards writing a prototype using a single cert with
 a fingerprint of PubKey in the Subject Alternate Name, and getting PubKey
 and InvoiceID in the Payment Request.  Gavin, would the best way to work on
 this be to just fork your code on Github?


As usual, our bottleneck is code review / testing, so it would be nice if
you spent some time reviewing code and helping test v0.9 so we can actually
ship a v1 sometime in the next several months before you start working on a
v2.

-- 
--
Gavin Andresen
--
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


Re: [Bitcoin-development] Cold Signing Payment Requests

2013-04-24 Thread Alan Reiner
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

--
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