Topic: [PROPOSAL] Secure Payment Protocol (Read 3584 times)

Mr. Hanke, let me thank you for explaining things so even I can understand them .

It's very reassuring to see bitcoin is being recognized and worked on by parts of the german research community, btw. Danke!

Maybe it would be good to take a step back when thinking about the problem.  First and foremost what I think you need is a way to deliver a secure message from one node to another, no matter what communication mechanism is employed (and by "secure" I mean signed and encrypted).  Since bitcoin is already using ECC, I see no reason not to use an ECC key pair for this as well.

So, now you have a node, and you generate an ECC key pair for communications.  There are many ways that you could exchange public keys:
- you could email a public key, along with a short hash and verify the short hash with a telephone call
- you could make a public key available on a web server over https with using an SSL certificate and CAs for authentication
- you could sign and send the public key using a PGP identity and PGP key servers
- you could use DNSSEC and whatever that entails (I have no idea, never really studied DNSSEC)

The point is, encrypt and sign the messages from endpoint to endpoint and leave the key exchange and verification protocol outside the scope for now.  With all of the different communications options available (some secure, some not), it seems unfathomable that any payment protocol would not encrypt and sign messages from endpoint to endpoint.

If you are signing requests entirely offline - like in your proposal - then compromising the web server doesn't compromise any private keys.

On one hand:  "Complexity is the enemy of security."  Several PKIs in parallel is more complex.

On the other hand: "Security In Depth."  Several PKIs in parallel could be more secure. But I'd insist that ALL PKI authentications MUST be successful, otherwise you're just giving an attacker the ability to attack the least secure PKI. It would be a mistake to show users a dialog box:


BUT: I think it is unlikely people will be willing deploy and keep secure multiple PKI systems, and I think the incremental security is small, so I think the right decision here is Keep It Simple, Stupid.

For example, I re-ordered the fields of SignedPaymentRequest so the entire structure doesn't have to be in memory at once to be processed, which is a suggestion from somebody considering implementing the payment protocol on a very memory-constrained hardware device. There are real tradeoffs if we make this more complex.

I suppose you are saying "to modify SSL" you only need control over the site because of the way EV works. But "to modify DNS" you would need  offline credentials. So far, I can follow. 


Not sure if I get the point here. The payment request signing key can not be replaced because it is in DNSSEC but it's private part would still be compromised, right? I guess the term "payment request signing key" confused me and you mean the private part to be offline, too.

For the design of the payment protocol, I would certainly like to see the PKI as easily exchangeable as possible. And even allow several PKIs in parallel. The bitcoin client should then display to the user for which PKIs authentication was successful, and for which not. 

I just wanted to point out something that maybe isn't obvious based on the previous discussions. Currently, signing payments offline with SSL keys isn't that useful because most merchants (at least today) don't have their keys in hard-to-compromise places like SSL terminators, they're running off cheap VPS systems and so on. And even if they didn't, control of the web server is often enough to get new SSL keys issued anyway.

But with DNSSEC, that is no longer the case, because the credentials you need to modify DNS are typically kept offline (in admins heads or some other safe place). There's no reason for them to be online. Even if your entire online serving setup is compromised, DNS can stay secure. So if DNSSEC/DANE was implemented as a secondary form of PKI in a future version this use case would make a lot more sense because the payment request signing key could be placed in DNS.

You don't have to lose the self-contained nature of the current payment request protocol. Although it's designed for securing online DNS lookups, DNSSEC is just another PKI - it's conceptually the same as SSL except with the DNS roots taking the place of todays certificate authorities, free signing (as far as I know) and of course it's easier to embed arbitrary data that gets signed as well. But you can still extract all the signatures and keys needed and have them be embedded into the payment request, then checked without any need to reference DNS. It conceptually forms a chain as well.

If somebody asked me to implement a payment protocol that was safe against compromised merchant servers, I'd probably do it by implementing thankes proposal (or the similar one posted in a different thread) and in parallel implementing DNSSEC as an alternative PKI. Then anyone who wants it can generate a new EC key, put the public part into a new DNS record on their domain, and then sign a bunch of payment requests offline. It would be a nice enhancement. It's also complex enough that it'd need to be part of a version 2 effort.

Yeah, that's exactly what I was proposing.

Suppose we define our own (bitcoin-specific) cert type and want to chain it to an existing SSL cert. The SSL cert does not have the CA-flag enabled in the extensions, that would allow it to operate as a CA, i.e. to sign other certs. Do you suggest to simply ignore this flag (at least in v1.0) and have the bitcoin client accept the X.509 chain even though one link does not conform to the X.509 specification? If you did not suggest this, would it very bad if we did ignore this flag (again, in v1.0 only)?

This is obvious. If you have separate machines you can of course run payment request signing on them as well, and have that machine do some basic sanity checks to avoid signing obviously bogus requests (ie, to addresses that are not owned by the merchant). Same thing for compartmentalizing using separate user accounts, SELinux, trusted computing, etc.

The "compromised web server" scenario applies for small merchants where everything is done on one machine for cost reasons, which today describes most Bitcoin accepting merchants.


The transactions themselves can't be modified. I suppose one of the tx keys could be used to sign the refund_to attribute as well, but I doubt any virus would make a profit by maliciously modifying the refund address. Refunds shouldn't be that common. It's a simple extension to sign the rest of Payment with a key used in the transactions though. Gavin can make the call.


As certs just encode public keys anyway, nothing stops you from directly importing certificates into a local trust store and deciding you trust them because of a WoT instead of a chain to a root CA. In practice basically no-one uses the web of trust. So this mode of operation isn't a big deal, but it can be done if you want it.

The protocol proposed there has several shortcomings. Firstly, it assumes that merchant's web server would not be compromised. Mike Hearn said that the server needs to have access to SSL private key, so if it is compromised, the game is over. However, this is not true: SSL termination can be performed on a machine different from the one running the web server. Even if it is done on the same machine, web applications are typically run with limited permissions, so they can't access SSL private key.

However, in the proposed payment protocol, an application running on the server needs access to private key to be able to sign PaymentRequests. If this application is compromised, so is the key.

Secondly, this protocol can't be used securely with offline wallet because Payment structure is not signed so it can be modified by compromised customer's online computer. Modifications to refund_to attribute seem the most dangerous. Also, a merchant can reject the payment but still broadcast the transactions (possibly after some delay).

As far as I understand, thanke's proposal has none of these shortcomings.

Also, it doesn't depend on traditional PKI. Merchants may sign their master keys with SSL certificates, GPG certificates, or even both. So a normal customer can verify merchant's key using SSL certificate, but a paranoid customer, who doesn't trust governments and CAs but trusts GPG WOT, can verify the merchant's key using GPG.

DNSSEC signatures are conceptually no different to SSL signatures - they form a hierarchy to a root of trust. In DNSSEC there's only one root of trust, the root domain servers, whereas in SSL there are many. So you can take the DNSSEC keys/signatures and embed them in other contexts:

  http://www.imperialviolet.org/2011/06/16/dnssecchrome.html

Actually that support was taken out of Chrome due to lack of use. But the principle is the same. You could still have payments that can be verified standalone.

The main issue is that DNSSEC signatures expire fairly quickly. But I suppose wallet software could choose to be lax about expiry in some cases, if necessary.

In principle, yes. Differences to namecoin would be:
* no alt-chain
* no limit to number of alias registrations per block
* alias registration is not recognizable as such, looks like arbitary transaction
* you can lookup the pubkey of a given alias (or see thats it's not yet registered), but it would be impossible to obtain a list of all registered aliases

What if you want to transact without DNS lookups? Certs work offline, too.

Is that what namecoin does?

Thanks for sharing the insight how the decisions made so far about the payment protocol came about.


No, I didn't mean that you, as a user aka customer, receive a payment request for an alias first and then start looking up that alias' pubkey. The other way around, that's why I meant that the bitcoin cert (what ever it is, payment cert) is higher level than the SSL cert. Instead of this:
We have this:
You first lookup the alias, e.g. 'amazon'. This results in a blockchain lookup, and a lookup to somewhere else for the derived certs, and then opens the bitcoin client and browser.
 
Typos like 'amazonn' result in the same problems as they do now.


Have CAs that replicate the data. Merchants register an alias 'amazon' first in the blockchain, then with the CA. The CA takes the pubkey from the blockchain and produces a cert, i.e. signs the pair (alias, pubkey) with its own key. The CA key can itself be an alias in the blockchain. But SPV clients can just accept the cert. Both ways of verification can co-exist. For very important things the user may want to choose to lookup the blockchain himself.

This eliminates root CAs. Advantage: CAs become cheap and free. Free in the sense of issuing whatever kind of extended cert they want.

I agree with the issue etothepi raised in the other thread: we cannot completely rely on CAs with bitcoin. The damage of a compromised CA is too big. It's unlike e-commerce based on the traditional banking system.

What Mike said.

Building a new PKI infrastructure is most definitely out of scope right now.

But if somebody wants to spearhead an effort to get CAs to allow extra public keys in the certificates that they issue... that might be worthwhile.

Then again, maybe not-- DNSSEC/DANE might make the CAs obsolete.

No, I meant an SSL cert. We haven't specced out what a "bitcoin cert" would mean or be (so far the payment protocol is largely a collaboration between Gavin and myself with some input from the others).

We don't have a way to make weaker certs right now. Perhaps there's some way we can manipulate the PKIX protocols/algorithms to get what we want, but at least with the code we've written, payment requests are signed using plain old SSL certs.


We made the decision pretty early on not to tackle this, at least not at the moment. Building a better PKI is a lot of work and Bitcoin is always manpower constrained. Just implementing the simple SSL cert based payment protocol is a lot of work. So we want to try and think ahead, make sure we don't close any doors, but get something out the door and deployed as fast as possible. Perfect is enemy of the good and all that.

Gavin is putting effort into this because one of his top priorities is 2-factor coins. It doesn't make much sense to have a 2-factor coin if the second factor can't verify the identity of the recipient of what it's asked to sign, hence, we need a payment protocol first. So right now it's just a means to an end.


It's a neat idea but I don't see how to efficiently implement that in SPV clients. Also the devil is in the details. If an "identity" is any arbitrary unverified string then it's possible to play all sorts of games. For instance, if I hack a merchant using "Mike's Widget Shop" then I could sign payment requests under all sorts of identities that 99% of users would blindly accept:

"Mike's Widget Shop, Inc"
"Mike's Widget Shop    "
"Mikes Widget Shop"
"Mike's Widgets Shop"
"mikes-widget-shop.com"
"Mike's widget shop"
"Mike's widget shop"

etc. There are just tons of different ways I can claim identities confusingly similar to existing ones. All these possible attacks need to be thought through and countermeasures devised. It's just a ton of work.

DV certs at least require proof of control over a domain name which probably matches the one the user typed in, and EV certs require you actually prove control over a legally registered entity, so it's harder to get one that asserts you are called "Amaz0n Inc". How much harder, I think is an open question, but the bar is definitely higher than "just register a string".

For these and other reasons we already made the decision to go with SSL certs for v1 despite their many problems. Later on, we can build either extensions to the SSL PKI or entirely new parallel ones.

So far, neither. As you said, the paper as well as the bakery example do not discuss how you get the provable identity from. I come back to that at the end. Some comments first.


I suppose you mean an X.509 cert with all the bitcoin specific extensions that are currently being discussed, not a standard SSL cert? I ask this because I think of a "bitcoin cert" as something more universal than an "SSL cert". Yes, a bitcoin cert could be used by a company also to secure their website, and also to secure their vending/teller/etc machines which operate non-SSL. I do not want to discourage SSL connections when they are possible. My only point is to not sign payment addresses at order time with the SSL cert. The bitcoin cert can sign a weaker SSL cert, which then secures the connection. And the PaymentRequest can be partially signed, even at order time, with some weaker certs (to certify something like "yes, we have this item in stock"). Just the payment address should not be signed (consequently, can be removed alltogether from the PaymentRequest, because the customer derives the payment address).

BTW, deriving the payment address from the raw PaymentRequest (raw=not containing a payment address yet) can interoperate with the previous protocol where the merchant generates the payment address. So yes, as you say, this can be backwards compatible and customer generated payment addresses would just be an extension.  


Most merchants are not accepting bitcoin. Aren't we early enough in the adoption to bootstrap an infrastructure for authenticated "bitcoin identities"? Better now than later.


We don't need hierarchical deterministic wallets. The type 2 deterministic wallets that are already implemented suffice. Just agree how to encode strings to 256bit numbers, thats all.


What exactly is "web of trust". Are the PGP distribution keys in my packet manager "web of trust"?


For an all-bitcoin integrated solution we can distribute the links of a string to a pubkey via the blockchain. Strings can be colored coins and the address who currently owns that colored coin defines the pubkey linked to that string. The original owner of ""Mikes Widget Shop, Ltd" is the pubkey
G["Mikes Widget Shop, Ltd"] := Hash256("Mikes Widget Shop, Ltd")*G
where G is some arbitrary base point that we all agree on and whose privkey is public. Since the address of G["Mikes Widget Shop, Ltd"] doesn't appear on the blockchain there is no owner. If you make a transaction from  G["Mikes Widget Shop, Ltd"] to your own address then you have transferred that string/colored coin to your possession. If you want to update your key or sell your string, pass on the colored coin.

EDIT: removed this post because it really belonged in its own thread:  https://bitcointalksearch.org/topic/protecting-merchants-from-compromised-webservers-130749

I'm confused. Are you arguing against the usage of X.509 certs or not?

If yes, where does your software get the provable identity from? In your bakery example you gloss over that, you simply assume users have shopped there before and assigned a custom label to the shops key. If the user has a compromised computer and shops at a new merchant, your scheme doesn't help unless the order form/payment request has some kind of standalone verifiable identity attached to it, that's meaningful for the first time user .... like an SSL cert.

If a company owns an SSL cert, then why would they not use it to secure their website too? Do we really want to discourage encrypted web connections?

Being able to create and sign payment requests entirely offline is potentially useful in the face of a hacked web server, if you don't have any other accepted form of identity on that server which could be used to sign payment requests. Unfortunately as two SSL certs are equivalent, that means only the case of non-secured websites. There are plenty of reasons a site might want to use SSL beyond Bitcoin.

I'm not saying the ideas in the paper are bad. Just pointing out that, for now, for most merchants/websites, it wouldn't make a practical difference because they don't have a separate identity that can be used only for Bitcoin payments and not web connections. If we can find a way to do that (by chaining two certs off the issued cert??) it'd have a lot more immediate impact.

Despite that, a future extension that lets a payment request contain base keys (in the requested scripts) that are modified by the client is still a good idea. It's something that can be added in a backwards compatible manner. As Gavin says, you'd just add some new flags to the payment request message stating that the part of the output scripts where keys should go, should have a key generated by the customer.

Re: scope. With respect, writing a paper is not the same as implementing it in all major clients. Bear in mind some of the most widely used wallets don't support hierarchical deterministic wallets at all yet, so writing specs that assume them will just delay implementation significantly.


Nobody likes it, but there's no widely accepted equivalent. People throw around "web of trust" as if that approach hasn't been an even greater failure than PKI.

Show me another mechanism to get a certificate asserting my identity in a way that's intuitive to all end users. I don't know of one. PKI means if somebody hears about my website from a friend saying "hey, check out mikes-widget-shop.com" and they browse to it, they'll see "mikes-widget-shop.com" on their second factor device, transaction history, etc. That's meaningful - it matches the identity their friend gave them. If they see "Mikes Widget Shop, Ltd" and my rights to owning that string was verified by someone trustworthy (trademarks, etc) that's even better! EV certs are expensive and hard to obtain, but clearly not out of reach for the Bitcoin community, blockchain.info has one for instance.

Anyway, SSL PKI is a foundation on which we can build, not the end game.