This is page 2 of:
Chip-And-PIN Hack Is So Scary Because It Surprised No One
Black added that it’s the liability split that dictates who has the incentive to properly safeguard systems. “Most importantly, with the legislation in place to shift liability to merchants and cardholders, the banks have little incentive to improve the system–their cost savings have already been achieved. However, neither the merchants nor the cardholders can effect any changes to the security model for the system,” he said. “Chip-and-PIN is dangerous, not due to the security issues but because the accompanying legislation has disconnected the incentive to continue the security development lifecycle from the parties that are directly responsible for it.”
Another IT security manager—albeit with an even larger chain—said industry officials who try to defend EMV by poking holes in the Cambridge report are doing little more than “damage control” and that their defenses “don’t forgive a broken protocol.”
But that security manager added that the effort required for the university hack is unlikely—right away—to be used widely. Variations of it, however, will almost certainly materialize and then quickly mushroom. “This is probably not a serious threat for some time to come. But attackers never get less effective. And I don’t think they’ll have fixed the problem by the time we see some actual criminals exploiting it.”
The Cambridge report details an approach that tricks both the chip and the card reader into believing that the other has given the transaction its blessing.
“The central flaw in the protocol is that the proceedings of the PIN verification step are never explicitly authenticated. Whilst the authenticated data sent to the bank contains two fields which incorporate information about the result of the cardholder verification, they do not together provide an unambiguous encoding of the events which took place,” the report said. The terminal verification results (TVR) “merely enumerates various possible failure conditions for the authentication and, in the event of success, does not indicate which particular method was used. Therefore, a man-in-the-middle device, which can intercept and modify the communications between card and terminal, can trick the terminal into believing that PIN verification succeeded by responding with 0x9000 to Verify, without actually sending the PIN to the card.”
The report continued with its planned attack technique. “A dummy PIN must be entered, but the attack allows any one to be accepted. The card will then believe that the terminal did not support PIN verification, and has either skipped cardholder verification or used a signature instead,” the report said. “Because the dummy PIN is never sent to the card, the PIN retry counter is not altered. Neither the card nor terminal will spot this subterfuge, because the cardholder verification byte of the TVR is only set if PIN verification has been attempted and failed. The terminal believes that PIN verification succeeded (and so generates a zero byte), and the card believes it was not attempted, so it will accept the zero byte.”
“The IAD does often indicate whether PIN verification was attempted; however, it is in an issuer-specific proprietary format, and not specified in EMV. Therefore, the terminal (which knows the cardholder verification method chosen) cannot decode it. The issuer, which can decode the IAD, does not know which cardholder verification method was used, and so cannot use it to prevent the attack,” the report said. “Because of the ambiguity in the TVR encoding, neither party can identify the inconsistency between the cardholder verification methods they each believe were used. The issuer will thus believe that the terminal was incapable of soliciting a PIN, which is an entirely plausible, yet inaccurate, conclusion.”
-Marc
February 18th, 2010 at 10:11 am
This hack demonstrates a much larger vulnerability that goes way beyond payment authorization. As software design has moved to “object oriented” designs that encapsulate data and processes along with the whole concept of “stateless objects” the “man in the middle” or wedge attack becomes much easier. This could really happen in any situation. Just as we are hearing more about cyber attacks from overseas, we are using software design techniques that make our systems more vulnerable. Better get a kerosene lamp.
February 18th, 2010 at 12:08 pm
I worked on EMV project in Canada. EMV is better than plain MSR card. No doubt. This is not marketing “gimmick”.
The Cambridge/BBC video shows a guy using a Netbook PC and an EMV “test card” hooked on a stolen EMV card. Sure, you may hide all the cables
February 18th, 2010 at 12:15 pm
Sure, you may hide all the cables but the setup will be obvious if you are wearing a T-Shirt. ;)
EMV has to fix this. I don’t know if the same issue has been raised in Canada.
February 18th, 2010 at 10:40 pm
Mr. Bittner,
How do you equate the failure of a developed-in-secret, 14-year-old cryptographic protocol with the adoption of object oriented programming, the recognition of design patterns, or the maturity of software engineering as a discipline? You are comparing oranges to a philosopher’s left elbow — the argument doesn’t even parse.
There were no software failures here, no code crashes being exploited nor buffer overrun attacks smashing stacks. This was a failure in the design and creation of a *protocol* that fell prey to being spoofed. No objects failed, because no objects were transmitted. This is 100% protocol design failure; and it can be blamed on the secretive nature of the original design process and the immature cryptographic skills of the original protocol designers. (Here’s a hint for all you budding cryptographers: the best cryptographers know they aren’t good enough by themselves. They always seek outside validation of their designs. Always.)
The chips inside the smart cards don’t even have the memory or the horsepower to support object oriented programming techniques. There aren’t dynamic memory allocations. These are tiny 8-bit chips with about 1K of RAM, and the applications hand coded in assembler (or possibly C.)
I’m sorry if you are uncomfortable with modern design techniques, object oriented languages, test-driven development, design patterns, or if you think programming should still be functional now because it was functional back when you first learned it. If you are interested in that kind of bare-metal programming, might I suggest embedded systems design? It’s all about writing code for these tiny standalone processors, where every byte still matters and every cycle still counts. You even get style points for writing in assembler. :-)
February 22nd, 2010 at 11:12 pm
Long ago I used to write code for smart card terminals, including those that accepted EMV cards. Even with the imperfections, the chip-based systems are much more secure than mag-stripe. The fact that this particular hole went undiscovered for at least six years is actually pretty impressive. Although I don’t know the specifics, I’m willing to bet this particular issue can be resolved in the terminal code without having to reissue all the cards.
This is a great example of the importance of ethical hacking. Hats off to the Cambridge team.
February 23rd, 2010 at 12:50 pm
Was it undiscovered? And are we sure there are variations already in the wild? There have been many customer complaints of fraudulent activity with EMV and most were simply swept under the carpet and attributed to a failure of the cardholder without much investigation. Recently the EU shifted some of the burden of proof back to the banks and this was done prior to this Cambridge report. If the system is so secure, why the shift?
February 23rd, 2010 at 12:59 pm
This hack has been available for over 8 years now. I doubt this should be a surprise to anyone.