Chip and PIN compatibility leads to insecurity

Filed Under: Data loss, Vulnerability

Credit card with ChipOver the last few years, banks have been rolling out their new, chip-based payment cards which follow the EMV (Eurocard, Mastercard and Visa) standard to improve the security of card-based payment processing.

In theory, the intelligence of a semiconductor chip should be able to defeat many of the card skimming attacks that were possible with the classic magnetic stripe technology of the older chip-less cards.

A brief look at the back side of the new cards reveals, however, that the magnetic stripe is still present. Apparently it is still necessary to maintain backwards-compatibility with card reader devices that don’t support the new technology yet.

In 2006, Cambridge researchers showed that the PIN may be grabbed in clear text by an interception device that eavesdrops the communication between a Point Of Sale (POS) terminal and the chip.

This offline verification is specified for POS terminals only, and not for ATMs. With the latter, the cardholder identity (including PIN) will always be verified online against a central bank computer, and the PIN consequently doesn’t pass the interception device.

Since then, new chip generations have been introduced that support an encrypted communication between reader and card, preventing eavesdropping of the PIN. Cards with Dynamic Data Authentication (DDA) or its sibling, Combined Data Authentication (CDA), come with a crypto chip of their own. DDA and CDA cards are not yet widespread, though.

Chip and PIN skimmerBut as researchers demonstrated at this year’s CanSecWest security conference, it is possible for an interception device to convince the POS terminal or ATM into transmitting the PIN in clear text to the chip.

This worked with all tested terminals (including ATMs) and all card generations. Apparently, all terminals still accept a compatibility mode for older chips with offline verification.

With the more secure DDA or CDA chips, this mode might result in one failed PIN verification process, as these chips would not accept the clear text PIN verification protocol. Most users would simply take this for an erroneous PIN entry, and try again.

The researchers presented a super-flat interception board that an attacker can insert in the card slot of an ATM. The board is hidden so well inside the slot that it is totally invisible to any customer.

What’s even cheekier is that it is powered by the regular ATM card reader device. So when a bank client inserts her card into the ATM slot, it actually communicates with the interceptor rather than with the card reader.

Still, it is necessary for a successful attack to get hold of the card or some essential information from it. Of course, card theft is the most obvious option.

Magnetic stripe skimming only works if the card is not yet protected with a so-called iCVV code. This is an additional property that lets the card issuer detect abuse cases. This feature is not yet supported by all existing payment cards.

It is even possible to read sufficient application data right from the chip and perform card-not-present transactions on web portals that do not require the entry of any additional card security codes (like CVV numbers on the back of the card).

Many websites like this are still out there, and this drives a booming black market for such data.

As demonstrated in these cases, backward-compatibility voids the security progress achieved by more advanced technologies.

ATM with Blue screen of deathThis reminds me of last year’s hassle with the introduction of a new generation of EMV payment cards in Germany, where the chip did not work correctly due to a firmware glitch, so that withdrawals at ATMs were no longer possible. The workaround that helped in many cases was covering the chip contacts with sticky tape, hence forcing authentication back into magnetic stripe mode.

Yet, in this recent case, backwards compatibility could be enforced in situations where it wasn’t even necessary, i.e. the offline mode in ATMs. This needs to be fixed as soon as possible.

What is an even bigger concern here is the fact that card issuers attempt to shift liability for card abuse onto their customers. With the introduction of the new technology, card issuers will implicitly assume that the cardholders’ negligence is to blame and shift the burden of proof to them, even though the technology is obviously still flawed.

So what recommendation can we give you in this case? Probably none that will help you individually. It is important to raise public awareness about the flaws and pressure on the card issuers to fix them. With sufficient public pressure it will become more difficult for the issuers to blame their customers by default in cases of abuse. And this is essential when it comes to trial.

Creative Commons image of ATM with BSOD courtesy of hashashin's Flickr photostream.

, , ,

You might like

3 Responses to Chip and PIN compatibility leads to insecurity

  1. Dirah · 1319 days ago

    They need to make the credit card machines read your retina in your eye instead of a PIN, let them make copies of your eyes.

  2. Andrew Ludgate · 1319 days ago

    The last thing you want is for financial data to be tied to biometric data -- the thugs will take the easy way out and just "borrow" your retina, while the more advanced fraudsters will find some way to bypass the physical object -- after all, a retina scan stores a copy of specific data in a hash; if the attackers can get the scanner to replicate the hash via another image, they've got access to your personal information that you can't revoke. If you're the victim of THIS kind of ID theft, not only is there nothing you can do about it, but you're going to be fighting an uphill battle in any court case, even if you can do a live demo showing that a retina scan can be faked both on the reader side and in the database.

    The EMV spec (including backwards compatibility) was thoroughly thought out, and stems from earlier specs going back to 1998. The credit companies came to the conclusion that fraud was inevitable, and decided to make hotlists (blacklists) more of a priority and improve revocation and re-issuing of cards to compensate. They also shifted liability from themselves to the merchants and consumers to offset the major foreseeable costs to themselves from the projected increase in fraud from 1999 to 2020.

    That said, the system was designed to allow chip-only mode in suitable situations -- which includes ATMs. Unfortunately, the banks have been slow to adopt chip-only, as North American acceptance of chip cards stalled out when the dot-com bubble burst at the turn of the century. For example, my bank finally issued me a chip+track 1 and 2 mag card last year -- almost exactly a decade after I was first using a chip-only card issued by the same bank (for controlled tests and review of the pre-EMV spec only). Considering it took the banks ten years to catch up to European standards and basic spec recommendations, you can expect much more time to go by before the original security recommendations have all been implemented.

  3. Andrea · 1311 days ago

    One correction, the PIN interception attack works only on POS terminals and not ATMs.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

About the author

Michael A Schmidt is the primary security contact within Sophos Data Protection Group (DPG) software development. He has been with Utimaco (the predecessor of the DPG) development for many years, filling various development- and security-related positions. Currently, he is harassing the other developers in the group with the promotion of a security-oriented software development process. Even more, Michael is forming a group of conspirators within Sophos to run a world-wide, 'Distributed Promotion of Secure Coding' attack.