3 ms·

Skimming continues to highlight the inherent vulnerability of account information transfer mechanisms (such as magstripe), as opposed to fixed currency transfer

by cheald 12y ago

Skimming continues to highlight the inherent vulnerability of account information transfer mechanisms (such as magstripe), as opposed to fixed currency transfer mechanisms. The fact that every vendor I transact with has the ability to capture my account information and make future requests for my money with it is terrifying. I have to trust that every 17-year old that handles my card at a restaurant isn't going to copy it and shop online with it later. The fact that the system works at all in its current state is a miracle. Even if Bitcoin never gains mass adoption, I really like the idea of being able to encode a consumable transaction that both authorizes the transfer and encodes the transfer amount. I can imagine a similar payment system (NFC payment with phones, perhaps?) that doesn't disclose arbitrary access to my account, but instead allows a transaction to be proposed, I accept the transaction on my trusted hardware (phone), and the transaction authorization with amount is then sent up the wire. This seems like it should be trivially accomplishable via mutual asymmetric signing. Vendor generates a request for money and signs it, sends it to my phone. My phone validates the chain-of-trust, presents me with the transaction request, and I can authorize it. If I authorize it, then the request is counter-signed with my private key, and the signed authorization is sent off to the payment processor, who has pubkeys for the vendor and myself and can validate the request and process it. Even if you could capture the transaction-in-transit, you wouldn't be able to compromise it, since you would need signing keys for both the vendor and the customer in order to forge the transaction, or to create new transactions with the signed account information. Is there any reason this wouldn't work?

Nursie 12y ago
"I really like the idea of being able to encode a consumable transaction that both authorizes the transfer and encodes the transfer amount." This occurs in EMV transactions. It's not exactly as you describe but there are a lot of similarities. Effectively, in your scenario, your credit card becomes your signing token. --edit-- Just to give you a bit more detail, there is mutual auth (terminal to card, card to terminal, card to payment process and payment processor to card), and the card creates a cryptogram from various pieces of transaction data (date/time, amount, customer verification method used etc etc).
- objclxt 12y ago
  EMV is all very well and good (to be clear, without a cryptogram the payment can't be charged), but it falls down because of the requirement for backwards compatibility. For physical, retail transactions the easy way out of this is a liability shift (make the retailer liable for any fraudulent transactions that aren't run using EMV), but it's much harder for card-not-present (online) transactions, where people just type in card numbers and go.
  - jon-wood 12y ago
    For cardholder not present transactions there's 3D Secure[1], which sits in the middle of online transactions. Customers fill in their details on the merchant's site, then redirect to a service run by their card provider which asks for some form of authentication that only the provider knows about, and then a token is passed back to the merchant which can be used to authenticated the transaction. Much as in store transactions which aren't conducted with Chip & PIN transfer liability to the merchant, online transactions without 3D Secure will also transfer liability, giving merchants a potentially hefty incentive to verify the customer's identity. [1] http://en.wikipedia.org/wiki/3-D_Secure http://en.wikipedia.org/wiki/3-D_Secure
    - josephlord 12y ago
      I hate this model. Try to buy something get redirected to a 4th party (not the retailer, buyer or the bank / card issuer) and get asked to enter private secret information. It teaches all the wrong things about security.
      - vertis 12y ago
        In the Australian Commonwealth Bank's implementation, this is a code that they SMS to my phone. No personal details, just MFA. Works pretty well. Edit: Also, it isn't a 4th party, the bank runs the service themselves.
        12y ago
drzaiusapelord 12y ago
Chip and pin pretty much solves this. My understanding is that its much more difficult to intercept the transaction due to the cryptography involved. No one handles your card or walks away with it like in the US. They bring the wireless cc terminal to you. These are coming to the US in 2015. I suspect a lot of the issues we have today will be minimized as we move away from magstripes and waiters walking away with your credit card. http://blogs.wsj.com/corporate-intelligence/2014/02/06/october-2015-the-end-of-the-swipe-and-sign-credit-card/ http://blogs.wsj.com/corporate-intelligence/2014/02/06/octob...
- sliverstorm 12y ago
  I've been pestering my credit card companies for years now, asking for chip-and-pin. It's the best I can think of to do.
- calpaterson 12y ago
  Sadly that is not the case. Major problems with chip and pin: - the chips used (32kb 90s-style smartcards AIUI) are simple to read and save, making chip and pin readers susceptible to the same social engineering attacks as magnetic stripe cards (btw, in the UK there have been skimmers for chip and pin for some time) - most terminals on the market transmit the pin in the clear from one part of the unit to the other, so it is trivial to doctor a legitimate chip and pin unit - it is difficult for the consumer to verify the trustworthiness of an unfamiliar chip and pin unit - in the UK, people often still try to walk away with my card, just as when we had magnetic stripe - transactions can be conducted offline in most configurations (true for example in the UK, but not in Germany) IMO the main selling point of Chip and PIN to UK retail banks is that they allow banks to reassign liability to for fraud to the customer. When your signature is forged, existing law clearly says you are not liable. When you PIN is discovered and used to send transactions, existing law is unclear and currently this allows banks to convince the customer to accept the liability. IIRC, American consumer fraud law is pretty strict, which is why the US has been slower to adopt the machines than eg the UK. In the UK, Chip and PIN seemed to cut fraud for a while, until attacks like skimming were applied. Now fraud is back on the rise :( There is good coverage of this in chapter 10 of Security Engineering 2nd edition by Ross Anderson, a book I highly recommend!
mleonhard 12y ago
I've been working on a protocol for this, not specific to bitcoin: https://github.com/mleonhard/hipp https://github.com/mleonhard/hipp

by cheald 12y ago

Nursie 12y ago

"I really like the idea of being able to encode a consumable transaction that both authorizes the transfer and encodes the transfer amount." This occurs in EMV transactions. It's not exactly as you describe but there are a lot of similarities. Effectively, in your scenario, your credit card becomes your signing token. --edit-- Just to give you a bit more detail, there is mutual auth (terminal to card, card to terminal, card to payment process and payment processor to card), and the card creates a cryptogram from various pieces of transaction data (date/time, amount, customer verification method used etc etc).

objclxt 12y ago
EMV is all very well and good (to be clear, without a cryptogram the payment can't be charged), but it falls down because of the requirement for backwards compatibility. For physical, retail transactions the easy way out of this is a liability shift (make the retailer liable for any fraudulent transactions that aren't run using EMV), but it's much harder for card-not-present (online) transactions, where people just type in card numbers and go.
- jon-wood 12y ago
  For cardholder not present transactions there's 3D Secure[1], which sits in the middle of online transactions. Customers fill in their details on the merchant's site, then redirect to a service run by their card provider which asks for some form of authentication that only the provider knows about, and then a token is passed back to the merchant which can be used to authenticated the transaction. Much as in store transactions which aren't conducted with Chip & PIN transfer liability to the merchant, online transactions without 3D Secure will also transfer liability, giving merchants a potentially hefty incentive to verify the customer's identity. [1] http://en.wikipedia.org/wiki/3-D_Secure http://en.wikipedia.org/wiki/3-D_Secure
  - josephlord 12y ago
    I hate this model. Try to buy something get redirected to a 4th party (not the retailer, buyer or the bank / card issuer) and get asked to enter private secret information. It teaches all the wrong things about security.
    - vertis 12y ago
      In the Australian Commonwealth Bank's implementation, this is a code that they SMS to my phone. No personal details, just MFA. Works pretty well. Edit: Also, it isn't a 4th party, the bank runs the service themselves.
      - 12y ago

drzaiusapelord 12y ago

Chip and pin pretty much solves this. My understanding is that its much more difficult to intercept the transaction due to the cryptography involved. No one handles your card or walks away with it like in the US. They bring the wireless cc terminal to you. These are coming to the US in 2015. I suspect a lot of the issues we have today will be minimized as we move away from magstripes and waiters walking away with your credit card. http://blogs.wsj.com/corporate-intelligence/2014/02/06/october-2015-the-end-of-the-swipe-and-sign-credit-card/ http://blogs.wsj.com/corporate-intelligence/2014/02/06/octob...

sliverstorm 12y ago
I've been pestering my credit card companies for years now, asking for chip-and-pin. It's the best I can think of to do.
calpaterson 12y ago
Sadly that is not the case. Major problems with chip and pin: - the chips used (32kb 90s-style smartcards AIUI) are simple to read and save, making chip and pin readers susceptible to the same social engineering attacks as magnetic stripe cards (btw, in the UK there have been skimmers for chip and pin for some time) - most terminals on the market transmit the pin in the clear from one part of the unit to the other, so it is trivial to doctor a legitimate chip and pin unit - it is difficult for the consumer to verify the trustworthiness of an unfamiliar chip and pin unit - in the UK, people often still try to walk away with my card, just as when we had magnetic stripe - transactions can be conducted offline in most configurations (true for example in the UK, but not in Germany) IMO the main selling point of Chip and PIN to UK retail banks is that they allow banks to reassign liability to for fraud to the customer. When your signature is forged, existing law clearly says you are not liable. When you PIN is discovered and used to send transactions, existing law is unclear and currently this allows banks to convince the customer to accept the liability. IIRC, American consumer fraud law is pretty strict, which is why the US has been slower to adopt the machines than eg the UK. In the UK, Chip and PIN seemed to cut fraud for a while, until attacks like skimming were applied. Now fraud is back on the rise :( There is good coverage of this in chapter 10 of Security Engineering 2nd edition by Ross Anderson, a book I highly recommend!

mleonhard 12y ago

I've been working on a protocol for this, not specific to bitcoin: https://github.com/mleonhard/hipp https://github.com/mleonhard/hipp