[Pre-Announce] OpenPay, use your bitcoins at any merchant that takes Visa!

[isis]

Hi Everyone,
I just wanted to post an update on the progress of OpenPay

Today I found out from several manufacturers that PIN pad programming is generally only dictated by the payment processor if the equipment is leased from them.

However most merchants in the USA purchase their own equipment.  Some of the higher end merchants pay for some serious customization, but for the most part all products within a product line run essentially the same software.

So in the long run, reprogramming them to recognize a new IIN won't require a lot of messing around with merchant processing companies who might take offense to not getting as big a cut of the transactional revenue.

On another note...

I've been trying to solve the magstripe issue all day and I think I have a solution, one that should work regardless of whether or not you have a cellphone.  It also allows you to self issue without purchasing any additional cards or equipment.

I just don't have the mathematical capacity at my disposal to determine whether or not this is a holy grail or a major security problem.
So help me figure this out folks.


I call this the "pick a card, any card method"
It should only require a series of simple modifications to any existing bitcoin client and for the merchants part all they need is a pin pad with a configurable alt-tender option on the front end then a fairly simple gateway program running on the backend.

Using this method you can enroll any card you already have as an "OpenPay" compatible payment card.
This means literally any card with a magstripe compliant to payment industry standards, including an old gift card from $ome_random_place.

It wouldn't even matter if it's expired,  

You would enroll by entering the numbers on the card into your OpenPay enabled bitcoin client.  
During enrollment you also choose a static pin number or numbers, the purpose being to set various daily spending limits,
Furthermore you could enable an SMS option similar to the one described earlier to set a PIN on the fly and allow multi-factor authenticated transactions to potentially bypass any spending limits.

Once enrolled the client generates a hash based on the card number, the expiration date and PIN (cardnumber is entered and hashed without it's IIN for security reasons).
This part serves as one half of a surrogate key that can be disposed of or unenrolled on demand.
I call that half "The enrollment ID".

After setup the client goes into listening mode...


Now you just go to any merchant that accepts OpenPay, swipe your enrolled card and select OpenPay as your tender type (instead of credit, debit, ebt etc).  

The pin pad would forward the card number and optionally the PIN to a specialized gateway application running somewhere on the merchant's local network.

The gateway application would take the card number, expiration date & pin (optional).
It would perform the same steps the client did during enrollment to generate the static half of the key.
Next it will also add the current timestamp (the other half of the key) and hash it to a valid bitcoin address.  
Finally it would send 0.01BTC to the address.  Along with payment instructions encoded some way in the scripsig.

Back home on the ranch...


The bitcoin client would be spending it's time scanning incoming transactions.
When it sees a new transaction it would look first at the scriptsig to see if it bears an OpenPay fingerprint.
If it does then it would add the timestamp of the transaction to each of it's enrollment IDs and generate new bitcoin addresses (enrollment addresses) in an attempt to determine if the transaction was intended for it, i.e. someone sent it some money.
If it sees that someone has sent it money, then it creates a new spend from the primary wallet based on the rules it's been given about spending limits etc and the instructions in the previous transaction, i.e. send BTC to the merchant if it doesn't exceed previous authorization limits.
Additionally it generates a second transaction using the enrolled key to send the 0.01BTC off to the OpenPay network to help pay for future development (or anywhere else the user chooses).

.....

Meanwhile back at the store, the gateway sees the new spend come in with the required information (probably some merchant unique transaction id) and notifies the pin pad & POS that the transaction is complete.

That's pretty much it except for multi factor authentication...

The SMS option I discussed in my previous posting is still interesting and I see it as a great way to bypass spending limits.  
Basically if the transaction matches without a PIN then the client would...
 
Create a temporary enrollment ID with a random numbered PIN.
Send a messaging containing the onetime use PIN to the user via SMS, email, smoke signal, or whatever method the user sets up in the client.

Once the PIN has been sent off the to user, then the client would send back the 0.01BTC with the message PIN_REQUIRED
This would tell the gateway to put the pin pad back into PIN acceptance mode and the user now enters the one time use PIN.

So that's the end of the "pick a card, any card" method.  I think it would be a great starting point for getting bitcoins into the real world.  The EMV enabled card is still in the works, but like I said before it would take a year or so to implement.

This option looks to be about 400 man hours of work (1 person 10 weeks, or 5 people 5 weeks) to implement.
Most of that (50%) is coding a new tender type for each of the dominate PIN pad models, 25% would be the gateway and another 25% would be modifications to the existing client.

Before I start implementing it though I'd like some feedback to see if I'm making any significant mistakes here.
My initial calculations showed that this could be vulnerable to both denial of service and brute force attacks (we know ahead of time the size of the static portion of the key (PINs will typically be 4 digits, cardnumber minus IIN is 10) and the remainder is a predictable and visible timestamp).
However neither of these are economically feasible if we enforce the minimum 0.01BTC initial spend to initiate a transaction at the OpenPay network level, and enforce daily & transactional spending limits within the client.

Other than that, this feels really solid to me, I'm not seeing any other vulnerabilities.

Anyways, thanks for taking the time to read this and I'm anxiously awaiting your feedback!

Thoughts?

[1713261605]

1713261605

[1713261605]

1713261605

[1713261605]

1713261605

[Elwar]

I like the idea of being able to use any card for the transaction. That would help with implementation by saying "want to skip the bank and credit card companies? run this app".

I was wondering if there would be a way to set up the software so that you just check for that card on the OpenPay network before checking the other (debit/credit) networks. That way you would not need to choose "OpenPay" when paying and it would be seamless for the user. And it would be compatible with all merchant machines that way.


Also, where is that initial .01 BTC sent from and whom to? From the merchant to the customer BTC client?

[Stephen Gornick]

Back home on the ranch...

Whose ranch?  The way I read it, the customer needs a bitcoin client continuously running back "at the ranch" to support delivering that customer's OpenPay transactions.  Is this correct?

So that's the end of the "pick a card, any card" method.  I think it would be a great starting point for getting bitcoins into the real world.

A carder can install at any one of your merchants a card swiper and pin pad (presumably without the merchant's knowledge).  So the carder will eventually have all the information that the customer has ... card #, expiration and PIN.  The carder then creates a magstripe card with that same info and goes shopping at other OpenPay merchants.

What is the protection then from the carder that does this?

[RodeoX]

A carder can install at any one of your merchants a card swiper and pin pad (presumably without the merchant's knowledge).  So the carder will eventually have all the information that the customer has ... card #, expiration and PIN.  The carder then creates a magstripe card with that same info and goes shopping at other OpenPay merchants.

What is the protection then from the carder that does this?

Isn't this a risk faced by all types of magnetic cards now?

[rjk]

A carder can install at any one of your merchants a card swiper and pin pad (presumably without the merchant's knowledge).  So the carder will eventually have all the information that the customer has ... card #, expiration and PIN.  The carder then creates a magstripe card with that same info and goes shopping at other OpenPay merchants.

What is the protection then from the carder that does this?

Isn't this a risk faced by all types of magnetic cards now?

Yeah, except that it isn't as much of a risk because credit cards are reversible. Now that there is more risk because of the irreversibility of Bitcoin, this solution is a little less attractive.

[DeathAndTaxes]

Isn't this a risk faced by all types cards now?

Which is why credit cards are resversible and have fraud protection.

[RodeoX]

Ahh, roger that. So this is a unique risk to be addressed.

[MoneyIsDebt]

Is it possible with the bitcoin protocol, to transfer some money (for a hotdog) from wallet A to wallet B, then spend the money from (throwaway) wallet B in the same block? Or must the first transaction A->B be on the blockchain first? If possible, one could give the merchant the keys for wallet B together with a signed transaction A->B.
Having to wait ten minutes or more in the shop might be a dealbreaker though.

[Stephen Gornick]

Is it possible with the bitcoin protocol, to transfer some money (for a hotdog) from wallet A to wallet B, then spend the money from (throwaway) wallet B in the same block? Or must the first transaction A->B be on the blockchain first? If possible, one could give the merchant the keys for wallet B together with a signed transaction A->B.
Having to wait ten minutes or more in the shop might be a dealbreaker though.

The Bitcoin-qt client doesn't support it, but the protocol allows it.  If I remember correctly, older clients used to not relay these transactions where the inputs weren't confirmed but I believe that is no longer an issue.

I raise this issue (one confirmation required between uses) with another type of payment approach where there is a paper (throwaway) wallet:



 - http://bitcointalk.org/index.php?topic=74978.msg831171#msg831171

[isis]

A carder can install at any one of your merchants a card swiper and pin pad (presumably without the merchant's knowledge).  So the carder will eventually have all the information that the customer has ... card #, expiration and PIN.  The carder then creates a magstripe card with that same info and goes shopping at other OpenPay merchants.

What is the protection then from the carder that does this?

Isn't this a risk faced by all types of magnetic cards now?

Yeah, except that it isn't as much of a risk because credit cards are reversible. Now that there is more risk because of the irreversibility of Bitcoin, this solution is a little less attractive.

No mater what payment method you choose, carders are a risk.  You can't stop every criminal out there all you can do is make it horribly unattractive for them.   

As for reversibility being some sort of protection; in the EU if a transaction is made with a compromised PIN & card the law says it's up to you to prove that you didn't make the transaction, the bank is under no obligation to refund you if you can't prove it was stolen, they may do so as a courtesy but it really is bank policy that dictates this, not network policy.

In the US if you try to dispute a PIN based transaction the bank will generally laugh at you, my bank doesn't allow reversals on PIN based debit transactions at all.  If yours does you're very lucky.  I can't speak for all of them, but I know that of the major banks I've done business with in the past few years, none would reverse PIN debits for any reason even with a police report and newspaper article in hand.  The most they would do is re-issue the card.

You can't have it both ways.  You can't have the irreversibility of bitcoin and the reversibility of Visa, at some point you're going to have to say... Alright this is secure enough for me.

In furtherance of security, the solution includes several safe-guards to make it unattractive to carders & script kiddies.

A 1 time use disposable key generated on the fly to protect your primary wallet.
A tiered set of spending limits (you set) tied to static PINs which you also set.
Multi-factor auth or 1 time use disposable PIN via SMS

Network replay attacks are pointless because the key is disposed of by the client as soon as the request is received.
Brute-force attacks have a significant financial cost.
If someone had the static portion of the key (a carder for instance), the most they could get at is whatever you set your spending limit to for that PIN, for that day, for a single transaction etc.
If a carder were to try a non-pin transaction it would trigger an SMS to you, and it's doubtful they would have both your card and your phone. 

Additionally the carder would have to know that $ome_random_card was actually used on the OpenPay network and not visa/mc or instore credit.  That would require not just a pin pad compromise but a wholly compromised back office.

And if you're really paranoid about the threat of carders, just enroll different card(s) for different merchants and days of the week, a different one each day

[rjk]

To prevent PIN bruteforcing, it seems to me that it would make sense to require that the PIN be verified against a remote server that has limits on the number of PIN submissions per $time_period. If the PIN can be determined with the use of the track data and some cryptographic brute force, I think the project would be lost before it is started, especially since 10 numerical digits are trivial to bruteforce. However, making the PIN completely unrelated to the track data would make it a bit more secure.

However, I'm not sure how to do this. Especially without a central server, although that might be something that could be implemented as a bridge solution.

[DeathAndTaxes]

The pin pad would forward the card number and optionally the PIN to a specialized gateway application running somewhere on the merchant's local network.

The gateway application would take the card number, expiration date & pin (optional).
It would perform the same steps the client did during enrollment to generate the static half of the key.
Next it will also add the current timestamp (the other half of the key) and hash it to a valid bitcoin address. 
Finally it would send 0.01BTC to the address.  Along with payment instructions encoded some way in the scripsig.

Am I reading this wrong?  A pin pad that sends the pin as plain text to the merchant is of no value.  You just gave the merchant everything necessary to spend as the user.

[DeathAndTaxes]

To prevent PIN bruteforcing, it seems to me that it would make sense to require that the PIN be verified against a remote server that has limits on the number of PIN submissions per $time_period.

Which is why I don't see magnetic stripe being useful.  In a pin & chip system (Bitcoin or otherwise) the pin and secret never leave the smartcard.  The pin pad sends pin (hashed to prevent snooping) to the smartcard which verifies it and then performs some action on the secret only providing the output.

For Bitcoin the "secret" would be the private key or possibly deterministic seed for a range of private keys and the "some action" would be generating a signed tx.

[isis]

To prevent PIN bruteforcing, it seems to me that it would make sense to require that the PIN be verified against a remote server that has limits on the number of PIN submissions per $time_period. If the PIN can be determined with the use of the track data and some cryptographic brute force, I think the project would be lost before it is started, especially since 10 numerical digits are trivial to bruteforce. However, making the PIN completely unrelated to the track data would make it a bit more secure.

However, I'm not sure how to do this. Especially without a central server, although that might be something that could be implemented as a bridge solution.

The PIN in this case is just a number you tell the OpenPay client or that it tells you.  It's not stored anywhere including the track data.
It's used to generate the static half of the disposable key (an enrollment id) and that's it.  It's purpose is to ensure that you are in fact in possession of the card and also to help you enforce spending limits in the unlikely event of a compromise.

There is no verification on the PIN itself, if the pin makes the key fit the hole that the client is looking for,  then the merchant (or brute force attacker) will see a properly crafted BTC send transaction come their way.  But if it doesn't work, then they just spewed 0.01BTC into the void with each failed attempt.  There is no "PIN_FAILED" message, however a "PIN_REQUIRED" message might be seen if they stumble upon an address that has a listener at that exact second.

To crack a 4 digit PIN it would cost as much as 99.99BTC with no guarantee that the daily spending limit on a 4 digit PIN is greater than 99.99BTC.  I would recommend a PIN length 2 digits more than the daily spending limit for that PIN, just to keep the security level higher.

[rjk]

Eew, so granny making a mistake will waste money? Is the waste limited in how much? Could it be only a satoshi instead? Or does it have to be the amount of the whole transaction?

[isis]

The pin pad would forward the card number and optionally the PIN to a specialized gateway application running somewhere on the merchant's local network.

The gateway application would take the card number, expiration date & pin (optional).
It would perform the same steps the client did during enrollment to generate the static half of the key.
Next it will also add the current timestamp (the other half of the key) and hash it to a valid bitcoin address. 
Finally it would send 0.01BTC to the address.  Along with payment instructions encoded some way in the scripsig.

Am I reading this wrong?  A pin pad that sends the pin as plain text to the merchant is of no value.  You just gave the merchant everything necessary to spend as the user.

Yes you're reading it wrong.  It's one time disposable and limited by spending limits you set.  This isn't your primary private key, it's a generated ID used by the merchant to send a message to the client as signal to say "Hey look here!"

[isis]

Eew, so granny making a mistake will waste money? Is the waste limited in how much? Could it be only a satoshi instead? Or does it have to be the amount of the whole transaction?

I think you're confused.  The 0.01BTC spend is used to signal the client to look at the transaction.  It's sent from the merchants account to a disposable address calculated independently by the merchant and your client software.  That address is literally one time use and changes every single second.  Thus it's the merchant's money 0.01BTC that gets wasted in this instance.  I think 3 PIN failures is enough for the merchant to tell granny to stop brute forcing her own pin

The purpose of the network fee is to make brute forcing behavior unpalatable and unrewarding.  Doesn't matter if it's granny brute forcing her own pin, or some pimply faced clerk who is moonlighting as a carder.  The system can't tell the difference.

[rjk]

Eew, so granny making a mistake will waste money? Is the waste limited in how much? Could it be only a satoshi instead? Or does it have to be the amount of the whole transaction?

I think you're confused.  The 0.01BTC spend is used to signal the client to look at the transaction.  It's sent from the merchants account to a disposable address calculated independently by the merchant and your client software.  That address is literally one time use and changes every single second.  Thus it's the merchant's money 0.01BTC that gets wasted in this instance.  I think 3 PIN failures is enough for the merchant to tell granny to stop brute forcing her own pin

The purpose of the network fee is to make brute forcing behavior unpalatable and unrewarding.  Doesn't matter if it's granny brute forcing her own pin, or some pimply faced clerk who is moonlighting as a carder.  The system can't tell the difference.

OK, as long as it can't be done in the comfort of some carder's home or in the back office where an unscrupulous cashier doesn't care how much of his employer's money he wastes.

[marcus_of_augustus]

Multi-sig transactions and/or two-factor authentication can remove most of the risk of a 'Bitcoin card' ... so that the irreversibility is not a problem, except in an infinitesimally small number of cases, an acceptable level of risk.

[isis]

Multi-sig transactions and/or two-factor authentication can remove most of the risk of a 'Bitcoin card' ... so that the irreversibility is not a problem, except in an infinitesimally small number of cases, an acceptable level of risk.

I haven't taken multisig into account, just two factor.  That's mostly because it's a new concept I'm not sure I fully understand.  Is there a really good explanation of how that would work in the Bitcoin system?  It might be I could incorporate it into this design, or rework the whole concept to leverage it properly.