Don't keep purchasing at the same merchants; that's like Carder 101!
Regardless, this whole "ask the card if the PIN was right" protocol is just dumb. Surely they could have e.g. had the card sign a challenge in a way it could only do if given the right PIN? That gets slightly more complicated when revoking old PINs or issuing new ones, but it would still be possible. For all we heard about the wonders of C'n'P, this seems to fall short. If you're going to the expense of chipping all those cards and replacing all those terminals, at least get the software right.
> Don't keep purchasing at the same merchants; that's like Carder 101!
I know! It's the stupid details and extra people they bring in that seems to eventually get these rings caught.
> Surely they could have e.g. had the card sign a challenge in a way it could only do if given the right PIN?
Well, the article seemed to imply the chip put in the CC was from a different card, so maybe they know the pin for that chip, and the MITM is really about the authentication of the chip in the wrong card? Later they do seem to imply the fix was to authenticate the chip, but I'm not sure without reading the original paper if that's an over-simplification of what the fix was, and maybe it's better authentication of the chip.
But the chip is the only part of the communication that knows the PIN. (the protocol does not need a network connection to the bank).
The chips could be made to sign their response with a bank's private key and the terminal checks this against a known list of banks. But that would be cumbersome (lots of banks, lots of keys), the terminals would need to be constantly updated to keep the key list up to date, and it all falls apart when a key is extracted out of the chip.
Now if the protocol required a network connection to the bank, you could speak to the bank to validate a PIN instead of talking to the chip at all.
They signed transaction would indeed fix this issue but it was ignored by the bank (to their detriment) for other reasons. The implementation is actually pretty decent.
It doesn't require key management the way you describe it.
Banks use a derived key schemes for EMV transactions. In a way you can think of it as PKI. In any event, the actual verification doesn't happen on the terminal. The terminal is supposed to take the signed transaction and pass it up through the network where it will end up with the originating bank who will say "Yes, we accept it", or "No, we don't accept this charge". This is something that happens today but it is the CC# and the CVV that get passed. If they are revealed/stolen you're screwed.
Merchants are constantly punished for all sorts of things, why not punish them (e.g. with a higher rate or more cumbersome chargeback) when they don't have network connections? Then you could have two slightly different protocols and the secure one would actually be somewhat secure.
Designing a protocol for the offline case sounds like a game of Whack-a-Mole and also like something we've all been advised against. However, ISTM that the attacks against a better offline protocol that included e.g. zero-knowledge proofs would be much more difficult than racing to say "yes".
The chip would not have the bank's private key - that'd be bad for the reason you mentioned. It'd have a unique private key signed by the bank. I.e. exactly how certificate systems work. (Still would have issues of cert management if the bank's key or system master keys are lost.)
The chip does have a unique private key signed by the bank, and the terminal can use that to verify that it's a genuine bank-issued chip - that's why the fraudsters needed to embed genuine chips from valid bank cards in their hacked cards. Unfortunately, due to banking industry stupidity that signed message doesn't tell the terminal whether the PIN was verified or not. It has to rely totally on an unsigned, unprotected message that can be MITMed to verify the PIN.
Actually, the card number is signed by issuer's certificate for exactly this reason. The same signed datastructure can also contain card's own public key(s) when needed by the used EMV implementation. There can be signing key that is used when card generates signed data files internally (I'll admit that I have no idea what that is good for) and second RSA encryption public key that is used for some card holder authentication mechanisms (eg. for encrypting PIN sent over cable from PIN pad to the actual terminal).
One important point in this is that nothing from this PKI mechanism is involved when the card generates the final transaction signature (called "Transaction Certificate" by EMV). Standard does not specify mandatory algorithm for that and also such algorithm necessarily has to be some kind of truncated symmetric MAC, as the resulting value has to fit into 32 bits (and ideally contain only BCD nibbles). There are some recommendations about what algorithms can be used for that in the standard also with recommendations about key management for the symmetric part.
The MitM essentially has no idea about EMV whatsoever and only traps one command and returns fixed OK response. Due to way how the card holder verification process works this results in terminal thinking that the entered pin was correct, while card thinks that no PIN was required for transaction (the idea there is that terminal and card calculates what verification methods they deem sufficient depending on various parameters of transaction and their internal state). While these two states are obviously different, they are encoded by same binary pattern in transaction flags (there is bit that means "verification failed" and nothing that encodes whether the verification was attempted or even what method was selected) and thus the terminal's view of transaction matches the signature generated by card.
Interesting point in this is that the card usually allows the transaction even without the verification succeeding. Idea behind this is that the transaction can be downgraded to card+signature by the terminal for various reasons (standard specifies list of some reason codes that contains reasonable things like "hardware problem with keyboard" but also "cardholder does not know the PIN").
In it's entirety the protocol is designed not to be absolutely secure, but to be efficient, reliable and provide usable audit trail for later review that is usable to unequivocally assign blame for disputed transactions. Essentially only problems with EMV from security standpoint come from complexity that is motivated by the reliability and backward compatibility requirements.
By the way there are certainly better workarounds for this vulnerability that testing whether card with no selected application responds to pin verification command that can be implemented on the card side, but they reduce reliability (eg. disallowing offline PIN verification, disallowing transactions without cardholder verification...). On the other hand these workarounds really solve the issue, while testing from protocol peculiarities by the terminal can be worked around by the attacker by implementing better MitM chip that tracks state of the original chip.
Arm's race between phone companies and phreakers who emulated payphone EPROM chipcards that involved things like the phone measuring various impedances of the card pins and finally ended with deprecating the whole thing (either by migrating to true smartcards or by simply discontinuing the cards, or even payphones) should be enough to convince anyone that authenticating devices by means of implementation details only slows the attacker down.
Regardless, this whole "ask the card if the PIN was right" protocol is just dumb. Surely they could have e.g. had the card sign a challenge in a way it could only do if given the right PIN? That gets slightly more complicated when revoking old PINs or issuing new ones, but it would still be possible. For all we heard about the wonders of C'n'P, this seems to fall short. If you're going to the expense of chipping all those cards and replacing all those terminals, at least get the software right.