Topic: [Pre-Announce] OpenPay, use your bitcoins at any merchant that takes Visa! - page 3. (Read 6511 times)

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.

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

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?


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?

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?

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?

Good concept.

Could the PIN portion of it not be solved by using multisig?

Merchant sends a message to send .42 BTC to XYZ address. The client receives the request and attempts the transaction. The multisig transaction is attempted and awaits the second sig method before it finalizes the transaction.



Some side suggestions of other ideas I had that would apply here.


I had previously suggested something similar to a domain name server but for Bitcoin addresses. Instead of saying "Send the BTC to 1X8JS8SXM42A9W4AJOWQ4262PEW" you would say "Send the BTC to elwarsspendingwallet2012". You could take this concept and have a number DNS setup.


And secondly, the concept of award points. A merchant accepting BTC could pay 1% of each transaction toward a reward program that is tied to the spending address. This would be geared toward people who do not use Bitcoin but would be willing to use it in order to get better rewards than the other cards.

In the USA, which cards you accept are also driven by your customers wants & needs.  A merchant selects which card networks they want to support based on his/her desire to service certain classes of customers and signs a merchant agreement with a payment processor.  The payment processors job is to handle all the details of credit card processing, however no matter which processing networks are used the hardware, card reader, pin pad etc are all basically the same.

A large part of my point is that if we want Bitcoin to gain broader acceptance we need to implement a solution that leverages that existing infrastructure to the degree possible.  Yes there are a lot of moving parts, but that's true of any payment processing mechanism.

As for the time delay, that's only true for the payment to become confirmed by the network, not the amount of time it takes for confirmation that a payment is on it's way.  Especially with the green address blocks (centrally issued cards) it's generally safe to allow the transaction to proceed without any delay.  We could probably speed it up a bit with a request/response callback mechanism.  Wallet X please call Wallet Y at IPx.x.x.x. re: tran-xyzpdq.

Yes

So will any of this be Open Source?

Seeing as it is called OpenPay ... and the brain-storming seems to be free-to-air .... just wondering.

because he wants to use the card-systems in shops.. but i doubt its that easy. in my country the systems are not that much in use as in the us, but a shop-owner decides which systems (aka networks, such as ec, visa, mastercard, amex ..) he supports on basis of his customers needs and will not be happy puchasing another service/network-api.

also the time/delay-issue isnt dealt with - transactions are instant most of the time, but they take their time - aproximately 10min/block. so still aproximateley 1 hour to complete. it could take longer.

isis, I like the creative solution to the security problem, but do you realize how many pieces of hardware are involved in the process?
You phone has to be able to receive SMS, and if you have self-issued card, you have to run bitcoind and ensure it's up and connected to network yourself.
I hate "Why don't you just use android wallet?" kind of arguments, but really... why don't you?

Ok let's back this discussion up just a little bit, I can see from some of the replies that folks are getting confused and it's starting to throw the discussion into disarray.

Step back a moment, open your wallet and look at your bank card.

You'll notice that it has several logos on it. 
One of those logos is likely to be Mastercard or Visa.
If you look on the back, you may see Plus, Interlink, Money Pass, paypass, blink etc.
I even have a card with "Green Dot" on the back.

What makes a mastercard a mastercard and not a visa is the network it runs off from.  It's also what makes an AMEX or Discover card what they are.

All these logos you see, they're just payment networks that your card is compatible with.

Bitcoin has a payment network as well, the problem is, there is at present no tie between the world of Bitcoin and the world of Visa/Master etc.

OpenPay (or whatever we decide to call it) would be exactly such a tie.
Regardless of what is on the card whether it be mag stripe, chip & pin, contactless NFC device, or magic pixie dust, the point still remains that the primary purpose is to allow offline spending of your BTC balance.

So that's the organizational aspect, first we find a way to get bitcoins circulating using the most painless methods possible.  Then we standardize those methods and try to get BTC flowing as widely as possible.

Now that's the organizational aspect let's look at the implementation.

After careful consideration I've decided that the way I was discussing magstripe is in fact the wrong way of doing it. 

Pull that bank card out and look at it again.  You'll notice that it starts with a 4 or a 5 and has a total of 16 digits.
The first 6 digits are what is known as an Issuer Identification Number (IIN).  It let's the merchant's payment processor know which network to communicate with to process the transaction. 

OpenPay would need to have it's own IIN because it really is it's own network playing by the rules of bitcoin rather than the rules of Visa or Mastercard. 

Even though it might look a lot like a Visa or Mastercard, the transaction would actually run over a wholly separate network, just like AMEX or Discover. 

Where I made my mistake was in assuming that the card would essentially be disposable if compromised. 
That just wouldn't be the case, so putting the private key into the magstripe (encrypted or otherwise) would be a bad idea. 
But after careful consideration I think I may have found a better way.

For instance let's imagine we have a card with the number 9123 - 4544 - 4112 - 3456 - 7890
The first 6 digits (912345) would be the IIN (Network ID) given to OpenPay by ISO.
The next 4 digits would be a routing code to the network, pointing to actual card issuer.
The remaining digits would be an individual account identifier that the issuer could use to tie the account.

Now before anyone complains about central control, realize that this is possible without any central authority other than a community owned body to pay the fee for the IIN which would be a requirement for any magstripe scenario.
 
The 4 digit routing code would have both reserved and public ranges, just like IP addresses do.  My recommendation is to allow any 4 digit repeating sequence 0000 ... 9999 etc to imply self issue. 

Other ranges could be sold to business issuers like banks, exchanges, mining pools.  These "centrally" issued ranges could be treated like green addresses are now.

Finally, the issue range database would be contained within bitcoin itself.  Just a microspend with a message attached "I'm wallet x and I own cardnumber y" (This is to prevent double issue).  We could take this a step further and allow a card revocation message for when a card gets lost or stolen.  This would free available card numbers over time.

Now let's look at how this all comes together.
Bob has a bitcoin denominated OpenPay card and goes to his local gas station for a drink and a bag of chips.
His total is USD $1.99.
He swipes his card, is prompted for a PIN, waits a few seconds and then is on his way home.

Under the covers as soon as he swiped his card the card reader determined from the IIN that this is actually an OpenPay card.
This triggered the merchant's payment processing software to load up the OpenPay connector which told the bitcoin deamon to send itself 0.01BTC with a message along the lines of "Please send $1.99 * USD/BTC rate, from $cardnumber to $merchant wallet."

Upon seeing that message, Bob's bitcoin wallet (with an OpenPay extension) possibly sitting at home on his computer or even running on his phone, picked a random number and sent a message to his phone.  This is what Bob ended up putting into the pin pad.

After Bob entered the number into the pin pad, the merchant's software sends itself 0.01BTC again, with the exact same message except the disposable pin is now appended. 

Bob's wallet sees the request with PIN attached and sends the transaction off as the merchant requested.

If per chance Bob had a non-self issued card, then the process could be much faster since the routing portion of the card would indicate the funds are coming from a "green address".  Also with a non-self issued card Bob would not need to have a wallet running at home, or on his phone, it would all be taken care of by whomever he has his account with.

Anyways, that's my new suggestion for magstripe.  I think the EMV chip & pin option is the way to go long term, but at least in the USA we've had a tendency to be resistant to changes like that so it could slow adoption.  What I'm proposing here would require nothing on the part of the merchant other than a single software install (and a BTC/USD exchange somewhere if they wanted to get USD at end of day).

sorry, really dont see that point in your description.

If it where to work pro bitcoin, your POS would have to accept (visa-)debt and pay bitcoin to some public key - which could be locked and verified in some way.
But certainly there is no reason to trust some POS with private keys  - thats the point with bitcoin. here the POS can earn trust.

Reverse for paying at shops where the trader accepts visa and we want to drop bitcoin, you'd offer a public key and connect it to some virtual visa and create advice as soon as your account sees the bitcoin-amount asked for. here the customers gain trust.

Chip and PIN is somewhat oldfashioned as we are used to that on creditcards, I miss the innovation.

I think it is really simple, but there cannot be any chargeback what makes it a hard business for your POS. They will need good inshurance and a good customer management with trust-levels allowing higher debts. Just take a closer look to what ppl already use to trade bitcoin.

Until now I did not find any (small) payments processor to take the risk, it would need a big player I think.
A main problem is, that the advice for the shop is wanted to be seen immediately. But to have some certainty bitcoin takes ~10min. There you might innovate things.

My point was to limit the usage to online-payments in the beginning. That would be natural. And as soon as the payment is confirmed  the delivering can be started. Thats how shops are used to it. As soon as customers have gained trust-levels they also can pay with the CC offline with reasonable amounts. Verifying the customer with some card is then still needed the same way it is for oldfashioned banking.

But nothing of this can be done without a central authority which comes in where your CC does.

/*break*/

innovative in my eyes would be a NFC-system "mailing" encrypted messages and handling "one time" private keys directly using some bitcoin-wallet. but thats much more than a smartcard.

Eventually yes, but at the start probably not.  The point of the mag swipe is to allow exactly that.  What will happen in the scenario you describe is that the merchant processor (not the merchant themselves) will handle the processing over the bitcoin network and we will be working with processors from the outset to allow this to become a reality. 

For the processor this is a matter of determining which network to run the transaction off from (hence the need for our own IIN).  For the merchant this should be as easy as telling their processor that they want to accept the card and have the processor enable it on their account, pretty much the same as if they wanted to accept AMEX, Discover etc.

Actually doing that would be a bit longer out though; it requires creating agreements with each processor to run transactions on the network, in addition to the overhead of adapting their systems to use it.  It's not insurmountable, and it is in the long range plan.  But the short term plan is to build momentum for the chip and pin system and give merchants a program to load on their POS/Pin Pad solution and some acquiring software to run the back office.  The hope being that after the installed base hits critical mass more processors will see the benefit of making it an integral part of their own systems (because the merchants will be asking for it).

My wife's store accepts Visa.

She has a card swiper connected to her laptop. She logs into a webpage that has the credit card transaction set up. She swipes their card and it fills in all of the card information. She types in the price and submits it. It then prints out a receipt.

Will your system work with this?

(though she can already accept Bitcoin payments via her smartphone, but just curious)

Well you could try to band-aid the current system by restricting it to specific POS devices and educating consumers about where not to swipe their cards,.... but I don't like that.

Additionally, consumers are unlikely to switch quickly or easily over to a chip&pin system either. Although Canada has chip&pin literally everywhere, consumers in the US have been known to microwave and hole-punch the chips out of their cards, because of their latent paranoia about "the system".

No not at the moment, but I am definitely open to suggestions on it.
The whole purpose of mag stripe is to allow existing merchants that don't have chip & pin to still process the transaction.

The only real solution that I can see is to limit the amount of money on the card to reduce the potential for damages.  However like I said that's not a complete solution.  The only other solution I see is a revocation mechanism that I have been working on, but I'm having difficulty finding a way to implement it without a central body.

I can go into details on it if you like, it's certainly better than the merchant having the actual key though.  The big drawback is it would require either a change to the way bitcoin operates, or a body of some sort to track & revoke what's encoded on the mag stripe.

If we assume that the magstripe card gets skimmed at some point, but the skimmer doesn't grab the PIN, what's to prevent him from bruteforcing it? If it's limited to digits 0-9, 10 characters is a cinch to crack. Is there any other protection?

Yes I understand I was just pointing you that any system where you give the private to the merchant and hope for the best is likely doomed.  Chip & Pin is completely different IF the entire transaction signing can be done in chip.  Having worked w/ smart cards that is somewhat difficult.  Still not sold on the advnatage of a chip+pin system vs smartphone especially as smartphones gain NFC.

If a merchant steals my checking account # I am not liable.  The bank is.  A check is reversible tx for exactly that reason.  Bad analogies don't improve the futility of a system involving trusting a merchant.

I used my credit card about 12 times today maybe 100 times in the last week.  Under a system where I gave my private key to all those merchants,  say the "money just disappears".  Who took it?  The risk is not just the merchant but also ever disgruntled employee, every modified terminal with a skimmer, etc.     It basically comes down to "trust the entire world" to not rob you despite the fact that they can do so trivially and anonymously at any point in the future.

POS system where customers card produced signed tx = valuable, maybe the killer app for Bitcoin
POS system where customer blindly and stupidly hands private key to entire world = useless.

Combining the two things causes the weak solution to undermine the security of the strong solution.

You have a good point.  It's a critical flaw with the Magstripe system, although not for the Chip & PIN.

But you're assuming the wallet itself isn't throw away.   Also if you were to buy a hotdog from a vendor using a check, what's to stop him from reading the MICR line and saving that for a rainy day?  You have to change your account number stop that (at least that's what I had to do when I had it happen).  Once you find you've been "robbed", you would just load a new key onto the stripe and get on with life.  Again, we are talking spending money not life savings.  Keep your big funds separate from your spending money.

With the Chip & PIN mode (which is what I'm advocating folks use whenever possible), you don't have this vulnerability since the PIN pad doesn't read anything from the card.  The pin pad just hands it an amount and a PIN code and gets back a transaction to pass on to the network, the card does all the heavy lifting.

Make sense?