3 ms·

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/chi

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".

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".