Bitcoin Forum
February 24, 2017, 05:18:52 PM *
News: Latest stable version of Bitcoin Core: 0.13.2  [Torrent]. (New!)
 
   Home   Help Search Donate Login Register  
Pages: « 1 [2] 3 4 »  All
  Print  
Author Topic: [Pre-Announce] OpenPay, use your bitcoins at any merchant that takes Visa!  (Read 5727 times)
isis
Full Member
***
Offline Offline

Activity: 154


View Profile
June 19, 2012, 08:28:44 AM
 #21

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?

Interested in OpenPay?
https://github.com/openpay
Donate to show your appreciation and support the effort!

1LMDCSAwjhT2Vp1sSf62dybEYW3MYpsoZj

Pyramining Links - Help OpenPay and get a 10% bonus on your funds.
http://pyramining.com/referral/zre9ysgqt
http://pyramining.com/referral/ans9km72g
http://pyramining.com/referral/f3k4xebzp
http://pyramining.com/referral/nc3ag2sdb
1487956732
Hero Member
*
Offline Offline

Posts: 1487956732

View Profile Personal Message (Offline)

Ignore
1487956732
Reply with quote  #2

1487956732
Report to moderator
1487956732
Hero Member
*
Offline Offline

Posts: 1487956732

View Profile Personal Message (Offline)

Ignore
1487956732
Reply with quote  #2

1487956732
Report to moderator
Advertised sites are not endorsed by the Bitcoin Forum. They may be unsafe, untrustworthy, or illegal in your jurisdiction. Advertise here.
Elwar
Legendary
*
Offline Offline

Activity: 2016


www.bitpools.com


View Profile WWW
June 19, 2012, 01:36:49 PM
 #22

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?

http://www.bitpools.com
Pool your bitcoins with others. Vote on solutions using the Bitcoin blockchain. Keep your bitcoins in your cold storage until you find a solution you like.
Links and Reviews of useful every day places to spend bitcoins: https://bitcointalk.org/index.php?topic=943143.0
Stephen Gornick
Legendary
*
Offline Offline

Activity: 2072



View Profile
June 19, 2012, 05:44:22 PM
 #23

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
Legendary
*
Offline Offline

Activity: 2184


The revolution will be monetized!


View Profile
June 19, 2012, 05:58:24 PM
 #24

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?

The gospel according to Satoshi - https://bitcoin.org/bitcoin.pdf

Free bitcoin - https://bitcointalk.org/index.php?topic=1610684
rjk
Sr. Member
****
Offline Offline

Activity: 420


1ngldh


View Profile
June 19, 2012, 06:00:07 PM
 #25

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.

Mining Rig Extraordinaire - the Trenton BPX6806 18-slot PCIe backplane [PICS] Dead project is dead, all hail the coming of the mighty ASIC!
DeathAndTaxes
Donator
Legendary
*
Offline Offline

Activity: 1218


Gerald Davis


View Profile
June 19, 2012, 06:00:09 PM
 #26

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

Which is why credit cards are resversible and have fraud protection.
RodeoX
Legendary
*
Offline Offline

Activity: 2184


The revolution will be monetized!


View Profile
June 19, 2012, 06:02:00 PM
 #27

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

The gospel according to Satoshi - https://bitcoin.org/bitcoin.pdf

Free bitcoin - https://bitcointalk.org/index.php?topic=1610684
MoneyIsDebt
Full Member
***
Online Online

Activity: 224



View Profile
June 19, 2012, 06:13:52 PM
 #28

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
Legendary
*
Offline Offline

Activity: 2072



View Profile
June 19, 2012, 06:33:35 PM
 #29

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
Full Member
***
Offline Offline

Activity: 154


View Profile
June 19, 2012, 08:23:36 PM
 #30

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 Wink


Interested in OpenPay?
https://github.com/openpay
Donate to show your appreciation and support the effort!

1LMDCSAwjhT2Vp1sSf62dybEYW3MYpsoZj

Pyramining Links - Help OpenPay and get a 10% bonus on your funds.
http://pyramining.com/referral/zre9ysgqt
http://pyramining.com/referral/ans9km72g
http://pyramining.com/referral/f3k4xebzp
http://pyramining.com/referral/nc3ag2sdb
rjk
Sr. Member
****
Offline Offline

Activity: 420


1ngldh


View Profile
June 19, 2012, 08:28:29 PM
 #31

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.

Mining Rig Extraordinaire - the Trenton BPX6806 18-slot PCIe backplane [PICS] Dead project is dead, all hail the coming of the mighty ASIC!
DeathAndTaxes
Donator
Legendary
*
Offline Offline

Activity: 1218


Gerald Davis


View Profile
June 19, 2012, 08:38:56 PM
 #32

Quote
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
Donator
Legendary
*
Offline Offline

Activity: 1218


Gerald Davis


View Profile
June 19, 2012, 08:41:18 PM
 #33

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
Full Member
***
Offline Offline

Activity: 154


View Profile
June 19, 2012, 08:49:25 PM
 #34

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.

Interested in OpenPay?
https://github.com/openpay
Donate to show your appreciation and support the effort!

1LMDCSAwjhT2Vp1sSf62dybEYW3MYpsoZj

Pyramining Links - Help OpenPay and get a 10% bonus on your funds.
http://pyramining.com/referral/zre9ysgqt
http://pyramining.com/referral/ans9km72g
http://pyramining.com/referral/f3k4xebzp
http://pyramining.com/referral/nc3ag2sdb
rjk
Sr. Member
****
Offline Offline

Activity: 420


1ngldh


View Profile
June 19, 2012, 08:51:39 PM
 #35

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?

Mining Rig Extraordinaire - the Trenton BPX6806 18-slot PCIe backplane [PICS] Dead project is dead, all hail the coming of the mighty ASIC!
isis
Full Member
***
Offline Offline

Activity: 154


View Profile
June 19, 2012, 08:53:38 PM
 #36

Quote
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!"

Interested in OpenPay?
https://github.com/openpay
Donate to show your appreciation and support the effort!

1LMDCSAwjhT2Vp1sSf62dybEYW3MYpsoZj

Pyramining Links - Help OpenPay and get a 10% bonus on your funds.
http://pyramining.com/referral/zre9ysgqt
http://pyramining.com/referral/ans9km72g
http://pyramining.com/referral/f3k4xebzp
http://pyramining.com/referral/nc3ag2sdb
isis
Full Member
***
Offline Offline

Activity: 154


View Profile
June 19, 2012, 08:58:51 PM
 #37

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 Wink

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.

Interested in OpenPay?
https://github.com/openpay
Donate to show your appreciation and support the effort!

1LMDCSAwjhT2Vp1sSf62dybEYW3MYpsoZj

Pyramining Links - Help OpenPay and get a 10% bonus on your funds.
http://pyramining.com/referral/zre9ysgqt
http://pyramining.com/referral/ans9km72g
http://pyramining.com/referral/f3k4xebzp
http://pyramining.com/referral/nc3ag2sdb
rjk
Sr. Member
****
Offline Offline

Activity: 420


1ngldh


View Profile
June 19, 2012, 09:00:14 PM
 #38

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 Wink

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.

Mining Rig Extraordinaire - the Trenton BPX6806 18-slot PCIe backplane [PICS] Dead project is dead, all hail the coming of the mighty ASIC!
marcus_of_augustus
Legendary
*
Offline Offline

Activity: 2170



View Profile
June 19, 2012, 09:10:28 PM
 #39

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
Full Member
***
Offline Offline

Activity: 154


View Profile
June 19, 2012, 09:30:36 PM
 #40

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.

Interested in OpenPay?
https://github.com/openpay
Donate to show your appreciation and support the effort!

1LMDCSAwjhT2Vp1sSf62dybEYW3MYpsoZj

Pyramining Links - Help OpenPay and get a 10% bonus on your funds.
http://pyramining.com/referral/zre9ysgqt
http://pyramining.com/referral/ans9km72g
http://pyramining.com/referral/f3k4xebzp
http://pyramining.com/referral/nc3ag2sdb
Pages: « 1 [2] 3 4 »  All
  Print  
 
Jump to:  

Sponsored by , a Bitcoin-accepting VPN.
Powered by MySQL Powered by PHP Powered by SMF 1.1.19 | SMF © 2006-2009, Simple Machines Valid XHTML 1.0! Valid CSS!