5 ms·

The kind of fraud prevented by a PIN enabled chip card is supposedly pretty rare. What would be more useful is a standard for browser attached chip card reader

The kind of fraud prevented by a PIN enabled chip card is supposedly pretty rare. What would be more useful is a standard for browser attached chip card readers to bring the anti-fraud protections of a chip card to everyday Internet transactions.

tehwebguy 9y ago
If a PIN were required for credit transactions I bet fraud from cloned / stolen cards would drop to about zero.
- pmorici 9y ago
  Cloning is not possible with chip cards pin or no pin. That's the whole reason US issuers switched to chips from mag stripes.
  - AshleyGrant 9y ago
    It is possible to clone chip and pin cards. Not easy, but possible: https://www.kaspersky.com/blog/chip-n-pin-cloning/21502/ https://www.kaspersky.com/blog/chip-n-pin-cloning/21502/ https://www.theregister.co.uk/2012/09/13/chip_and_pin_security_flaw_research/ https://www.theregister.co.uk/2012/09/13/chip_and_pin_securi...
    - dfox 9y ago
      I didn't know about the first attack you mentioned, but it still seems to boil down to cloning non-EMV card onto card that behaves like EMV. For this to work I think that the terminal must be horribly misconfigured and then it almost certainly defrauds the merchant and not the original cardholder as I don't see how merchant's bank would ever authorize such transaction. The second on you mention is based on exploiting flawed RNGs in certain ATM implementations and using that to replay transactions that happened elsewhere. Fix is obvious: don't use flawed RNGs. Third known attack on EMV is similar to the "accept any PIN" part of the first, but done by MitMing the interface between terminal and card. This relies on the fact, that "No PIN was required" and "Correct PIN entered" produces same transaction certificate. This also can be mitigated by altering the terminal configuration.
      - tialaramex 9y ago
        Light Blue Touchpaper talked about this all at some length. On the one hand it's true that all these flaws can be worked around. But on the other hand, how did card companies not bring in cryptographers to help them get this stuff right in the first place? Did they not think it was important? The TLS journey is illustrative. Originally SSL is hand-rolled crypto. And so SSL 1.0 is so bad it was never really used, their second attempt, SSL 2.0 is still pretty flawed, it's no longer "Herp, I eat paste" bad but even SSL 3.0 still suffers from some pretty bad decisions where clearly engineers who've heard of encryption but aren't experts are making too many cryptographically important decisions. TLS 1.0 goes to the IETF. So now there's a wider pool looking at this stuff, but firstly it's still trying to be compatible with SSL and secondly these are still just more engineers, not cryptographers. Even in TLS 1.2 actual crypto people only get involved at the end, and they're basically asked (like a poor submission to r/crypto) "Is this OK?" rather than "What would _you_ do here?". It's hard to say "This is not OK" even if your gut instinct is screaming, unless you can prove it. So that's weaker than we'd like. Finally in TLS 1.3 crypto people are involved from the outset, serious mathematical crypto people who say things like "In this paper we show that under the stated threat model an attacker cannot discover key C in this protocol without having key A if the PRF meets the criteria laid down in reference Z" and they helped produce what we expect to be the most secure version of TLS. Now, TLS 1.3 took _years_ longer than SSL 2.0, but banks don't do anything quickly anyway. So why didn't EMV take its time and produce something better by hiring in cryptographers to design this stuff? No cryptographer would go "Oh, yeah, just ask for four numbers and if they're all different that's good enough".
politician 9y ago
This seems like something Square should be easily able to enable.
rkeene2 9y ago
This already exists. If EMV specified an X.509 certificate instead of a proprietary one, then we could be doing card-present transactions over the Internet right now thanks to TLS client certificates.
- ajdlinux 9y ago
  https://en.wikipedia.org/wiki/Secure_Electronic_Transaction https://en.wikipedia.org/wiki/Secure_Electronic_Transaction was actually a thing once...
- dfox 9y ago
  The RSA certificates used in EMV are not used to authorize transactions, but only to authenticate card to the terminal (and optionally to encrypt communication between pin pad and the card). Only effect of using full-blown X.509 for that would be that the certificates will be three times larger. Transactions are "signed" with issuer-specific symmetric algorithm (the specification AFAIK recommends CBC-MAC and HMAC), original motivation for this constructions seems to be backward compatibility in the sense that the algorithm can be designed such that it produces 8 digit decimal numbers that can then pass through various backend systems in field originally intended for swipe card online authorization code. And by the way nothing technically prevents the issuers to combine EMV application with some PKCS#11 applet with X.509 certificate on the same physical card. EMV is in fact to some extent explicitly overdesigned to allow not only this but even multiple EMV "cards" on same physical chip. One interesting idea would be to do EMV transaction over the internet by just forwarding the PDUs sent to the card over the internet, but it has lots of subtle usability and security issues to be really practical.
  - rkeene2 9y ago
    There is definitely nothing that prevents another applet (JavaCard, not PKCS#11 -- that's just a generic interface) from running on smartcards currently running the EMV applet. Or any other smartcard from running more than one applet -- this is a result of ISO7816 more than EMV. But my point is that if EMV had chosen to use X.509 instead of inventing their own certificate format then we could re-use the existing infrastructure with zero cost. Passing arbitrary APDUs from webpages to your card isn't a great idea and it will be SLOW since it will require multiple round-trips -- it's already slow enough just reading objects from smartcards. This is the mechanism used by Citrix/MS Remote Desktop, which is to forward a PC/SC connection -- this has a disadvantage that the remote side must have drivers and is also real slow, but the advantage that the resource can be used for anything, just like it were local. For what it's worth, I'm the author of some smartcard middleware (CACKey) and have worked with the EMV specification and EMV applets to a lesser degree.
u801e 9y ago
> The kind of fraud prevented by a PIN enabled chip card is supposedly pretty rare. Are lost and stolen cards not a common problem? I suppose if the card holder reports it to the credit card company fast enough, it would prevent fraudulent charges from going through, but it would be nice if the person who found/stole the card(s) wasn't able to just use it without having to enter a PIN to do so.
- tialaramex 9y ago
  Both the card and the terminal are able to make a decision about whether this transaction must be "online", a live session. If either insists on being "online" and that's not possible the transaction fails. If the card is reported stolen, all such online transactions are (should be) blocked, and the risk is up to both the issuer (you could ship cards that insist on all transactions needing to be online, and some cards intended for people who struggle to manage their money do that) and the merchant (you can insist on going online for every transaction). However, forcing every transaction online is super annoying. Train sat in a tunnel? No card purchased G&T for you until it gets out again. Internet down at the burger shack? No burger until their Internet is back up. Merchants would usually rather risk some fraud for smaller purchases, than lose sales when there's a problem. "Weird money" causes the same issues, it's rare in the US but some places deliberately issue loads of different money that's all theoretically worth the same but you rarely see some types. In England for example a Scottish or Northern Irish bank note, issued with the name of some company you've never heard of, is still "worth" the same as familiar English notes. Except if you live closer to France than Scotland you've probably never seen one before. Maybe it's fake. Should you, as a shopkeeper, risk taking this weird-looking money? Again, risk of fraud versus risk of a lost sale.
- pmorici 9y ago
  My understanding is that lost and stolen cards are a very small portion of fraud compared to industrial scale skimming, cloning, hacking operations. Lost stolen cards only account for 14% of fraud cases. [0] [0] https://www.nasdaq.com/article/credit-card-fraud-and-id-theft-statistics-cm520388 https://www.nasdaq.com/article/credit-card-fraud-and-id-thef...
jon_adler 9y ago
The European payment industry is adopting secure customer authentication in the form of 3DS2.1.

tehwebguy 9y ago

If a PIN were required for credit transactions I bet fraud from cloned / stolen cards would drop to about zero.

pmorici 9y ago
Cloning is not possible with chip cards pin or no pin. That's the whole reason US issuers switched to chips from mag stripes.
- AshleyGrant 9y ago
  It is possible to clone chip and pin cards. Not easy, but possible: https://www.kaspersky.com/blog/chip-n-pin-cloning/21502/ https://www.kaspersky.com/blog/chip-n-pin-cloning/21502/ https://www.theregister.co.uk/2012/09/13/chip_and_pin_security_flaw_research/ https://www.theregister.co.uk/2012/09/13/chip_and_pin_securi...
  - dfox 9y ago
    I didn't know about the first attack you mentioned, but it still seems to boil down to cloning non-EMV card onto card that behaves like EMV. For this to work I think that the terminal must be horribly misconfigured and then it almost certainly defrauds the merchant and not the original cardholder as I don't see how merchant's bank would ever authorize such transaction. The second on you mention is based on exploiting flawed RNGs in certain ATM implementations and using that to replay transactions that happened elsewhere. Fix is obvious: don't use flawed RNGs. Third known attack on EMV is similar to the "accept any PIN" part of the first, but done by MitMing the interface between terminal and card. This relies on the fact, that "No PIN was required" and "Correct PIN entered" produces same transaction certificate. This also can be mitigated by altering the terminal configuration.
    - tialaramex 9y ago
      Light Blue Touchpaper talked about this all at some length. On the one hand it's true that all these flaws can be worked around. But on the other hand, how did card companies not bring in cryptographers to help them get this stuff right in the first place? Did they not think it was important? The TLS journey is illustrative. Originally SSL is hand-rolled crypto. And so SSL 1.0 is so bad it was never really used, their second attempt, SSL 2.0 is still pretty flawed, it's no longer "Herp, I eat paste" bad but even SSL 3.0 still suffers from some pretty bad decisions where clearly engineers who've heard of encryption but aren't experts are making too many cryptographically important decisions. TLS 1.0 goes to the IETF. So now there's a wider pool looking at this stuff, but firstly it's still trying to be compatible with SSL and secondly these are still just more engineers, not cryptographers. Even in TLS 1.2 actual crypto people only get involved at the end, and they're basically asked (like a poor submission to r/crypto) "Is this OK?" rather than "What would _you_ do here?". It's hard to say "This is not OK" even if your gut instinct is screaming, unless you can prove it. So that's weaker than we'd like. Finally in TLS 1.3 crypto people are involved from the outset, serious mathematical crypto people who say things like "In this paper we show that under the stated threat model an attacker cannot discover key C in this protocol without having key A if the PRF meets the criteria laid down in reference Z" and they helped produce what we expect to be the most secure version of TLS. Now, TLS 1.3 took _years_ longer than SSL 2.0, but banks don't do anything quickly anyway. So why didn't EMV take its time and produce something better by hiring in cryptographers to design this stuff? No cryptographer would go "Oh, yeah, just ask for four numbers and if they're all different that's good enough".

politician 9y ago

This seems like something Square should be easily able to enable.

rkeene2 9y ago

This already exists. If EMV specified an X.509 certificate instead of a proprietary one, then we could be doing card-present transactions over the Internet right now thanks to TLS client certificates.

ajdlinux 9y ago
https://en.wikipedia.org/wiki/Secure_Electronic_Transaction https://en.wikipedia.org/wiki/Secure_Electronic_Transaction was actually a thing once...
dfox 9y ago
The RSA certificates used in EMV are not used to authorize transactions, but only to authenticate card to the terminal (and optionally to encrypt communication between pin pad and the card). Only effect of using full-blown X.509 for that would be that the certificates will be three times larger. Transactions are "signed" with issuer-specific symmetric algorithm (the specification AFAIK recommends CBC-MAC and HMAC), original motivation for this constructions seems to be backward compatibility in the sense that the algorithm can be designed such that it produces 8 digit decimal numbers that can then pass through various backend systems in field originally intended for swipe card online authorization code. And by the way nothing technically prevents the issuers to combine EMV application with some PKCS#11 applet with X.509 certificate on the same physical card. EMV is in fact to some extent explicitly overdesigned to allow not only this but even multiple EMV "cards" on same physical chip. One interesting idea would be to do EMV transaction over the internet by just forwarding the PDUs sent to the card over the internet, but it has lots of subtle usability and security issues to be really practical.
- rkeene2 9y ago
  There is definitely nothing that prevents another applet (JavaCard, not PKCS#11 -- that's just a generic interface) from running on smartcards currently running the EMV applet. Or any other smartcard from running more than one applet -- this is a result of ISO7816 more than EMV. But my point is that if EMV had chosen to use X.509 instead of inventing their own certificate format then we could re-use the existing infrastructure with zero cost. Passing arbitrary APDUs from webpages to your card isn't a great idea and it will be SLOW since it will require multiple round-trips -- it's already slow enough just reading objects from smartcards. This is the mechanism used by Citrix/MS Remote Desktop, which is to forward a PC/SC connection -- this has a disadvantage that the remote side must have drivers and is also real slow, but the advantage that the resource can be used for anything, just like it were local. For what it's worth, I'm the author of some smartcard middleware (CACKey) and have worked with the EMV specification and EMV applets to a lesser degree.

u801e 9y ago

> The kind of fraud prevented by a PIN enabled chip card is supposedly pretty rare. Are lost and stolen cards not a common problem? I suppose if the card holder reports it to the credit card company fast enough, it would prevent fraudulent charges from going through, but it would be nice if the person who found/stole the card(s) wasn't able to just use it without having to enter a PIN to do so.

tialaramex 9y ago
Both the card and the terminal are able to make a decision about whether this transaction must be "online", a live session. If either insists on being "online" and that's not possible the transaction fails. If the card is reported stolen, all such online transactions are (should be) blocked, and the risk is up to both the issuer (you could ship cards that insist on all transactions needing to be online, and some cards intended for people who struggle to manage their money do that) and the merchant (you can insist on going online for every transaction). However, forcing every transaction online is super annoying. Train sat in a tunnel? No card purchased G&T for you until it gets out again. Internet down at the burger shack? No burger until their Internet is back up. Merchants would usually rather risk some fraud for smaller purchases, than lose sales when there's a problem. "Weird money" causes the same issues, it's rare in the US but some places deliberately issue loads of different money that's all theoretically worth the same but you rarely see some types. In England for example a Scottish or Northern Irish bank note, issued with the name of some company you've never heard of, is still "worth" the same as familiar English notes. Except if you live closer to France than Scotland you've probably never seen one before. Maybe it's fake. Should you, as a shopkeeper, risk taking this weird-looking money? Again, risk of fraud versus risk of a lost sale.
pmorici 9y ago
My understanding is that lost and stolen cards are a very small portion of fraud compared to industrial scale skimming, cloning, hacking operations. Lost stolen cards only account for 14% of fraud cases. [0] [0] https://www.nasdaq.com/article/credit-card-fraud-and-id-theft-statistics-cm520388 https://www.nasdaq.com/article/credit-card-fraud-and-id-thef...

jon_adler 9y ago

The European payment industry is adopting secure customer authentication in the form of 3DS2.1.