Chip and PIN is back in the news and since I am heading to Europe next week on vacation, I thought I would pass this information along.
In a recent interview, Ms. Ellen Richey, Visa’s Chief Enterprise Risk Officer, indicated that Chip and PIN would head to the United States at some point. As usual, there was an impression given that Chip and PIN is some sort of magic bullet that will cure all ills. However, as you will see, Chip and PIN is not the “silver bullet” solution.
For those of you that have not traveled to Europe a little background. Chip and PIN was developed by the British government to implement the Europay, MasterCard and Visa (EMV) standard for credit cards containing a built-in integrated circuit (IC), also known as the ‘Chip’. The PIN part comes from the fact that you no longer sign a receipt when you make a purchase, you enter your PIN, just like at an ATM. The purpose of developing Chip and PIN was to reduce the amount of fraud in face-to-face credit card transactions. Chip and PIN is a worldwide standard that has only been implemented in Europe. With the exception of Discover Financial, all of the other major card brands (Visa, MasterCard, JCB and American Express) have adopted various forms of the Chip and PIN technology.
Chip and PIN replaces the swiping of the magnetic stripe and receipt-signing common in the United States. With Chip and PIN technology, the information contained on the magnetic stripe is also recorded on the Chip contained in the card. The data stored in the chip is encrypted using either the DES, 3DES, RSA or SHA encryption algorithms. Rather than swiping the magnetic stripe, the card is inserted into the payment terminal where the chip is read and decrypted and the transaction is submitted for authorization. If authorized, the payment terminal is given to the cardholder and the cardholder enters their PIN into the terminal, a receipt is generated and the transaction is completed. Most Chip and PIN terminals also have a magnetic stripe readers – you want the tourists to be able to use their “old” cards. Chip and PIN terminals can operate over wired, dialup, 802.11 wireless or cellular networks. In all communication environments, the terminals use secure transmission technology to ensure the privacy of cardholder data.
Looks good so far, but as I have said before, security is not perfect. While Chip and PIN has significantly reduced fraud in face-to-face transactions, there are a number of issues regarding the security of this technology. Those issues include:
- The EMV specification is open source and available from a number of sources, including EMV Co. Because of this, any attacker can obtain the specification to build their own hardware and software for creating and processing Chip and PIN cards as well as creating attack methods to compromise the cards. This has lead to a number of successful attacks resulting in cloned cards as well as obtaining and computing valid PINs.
- The entry of the PIN can be bypassed by the merchant. If bypassed, the receipt is generated and signed by the cardholder, no different from a transaction performed with a traditional credit card. While banks have tried to discourage this practice, this option is still available which does not provide any additional protections against fraudulent transactions.
- Theft of physical credit cards has risen since the introduction of Chip and PIN. Criminals often hold victims hostage and threaten them with bodily harm until they reveal their PIN, which the criminals can confirm with a simple card reader. Card readers are very easy to come by as banks sent them to all their customers along with their Chip and PIN cards when they were introduced.
- Banks encourage credit and debit card customers to take their card readers along with them. The readers require the entry of the PIN in order to get information displayed from the card. Security researchers found that because of frequent use of these readers, the readers had four more heavily worn keys that reduced the likelihood of guessing a card’s PIN from 1 in 3,333 to 1 in 8.
- Chip and PIN cards connected to PCs can generate authentication tokens, but the standards do not specify how these tokens are to be used in an online environment. In addition, most e-Commerce sites and many banks have not implemented this capability into their Internet processing environments. As a result, security of online environments is not always enhanced by using Chip and PIN cards. In fact, some banks will not allow their Chip and PIN cards to be used online.
- Offline entry of PINs is supported by certain cards in certain countries. In offline mode, the PIN is not encrypted, so it can readily be retrieved in plaintext from the terminal.
- The introduction of Chip and PIN technology has moved attacks to the merchant terminal or integrated point of sale (POS) solution. In the case of terminals, the terminal is modified by the attacker to record the information on the chip after it is decrypted (skimming). Since most terminals use some form of high-speed network connection, the compromised terminal periodically sends the captured chip data to an attacker any where in the world. For POS, the attacker compromises the POS station and then obtains the chip data by monitoring the program that processes the Chip and PIN card. Again, since most POS terminals are on a network, the attacker has their capture program send the captured card data to their computer.A number of incidents involving the skimming of Chip and PIN cards using tampered software or terminals have been documented. Skimmed cards are typically sold in areas like Asia and the United States where magnetic stripes are still used. The incidence of compromised terminals and POS systems has risen significantly since the introduction of Chip and PIN technology.
Many European organizations believe that Chip and PIN makes them immune to complying with the PCI standards. The standards promulgated by the PCI Security Standards Council are worldwide in nature. So, regardless of the type of card used, all merchants and acquirers are required to comply with all PCI standards. This is legally enforced through merchant and service provider agreements between these entities and the card brands. All agreements were updated worldwide over the last three to four years to include addendums that require all parties to be PCI compliant.
While Chip and PIN cards and their terminals are different, the integrated POS and the back end systems that authorize and process transactions are not different. These systems provide their functionality the same way regardless of the card used. At a minimum, these back end systems process and transmit cardholder data. But these back end systems may also store cardholder data. As a result, these back end systems must comply with the PCI standards.
Chip and PIN terminals are no different than their magnetic stripe swiping cousins. They require proper configuration to ensure that they mask cardholder data and that they transmit transactions securely so that they comply with the PCI Data Security Standard. They are also required to comply with the PCI PIN Entry Device (PED) standard.
The bottom line is that Chip and PIN reduces face-to-face transaction fraud, but it does not remove all of the risks involved in the use of a credit card. As a result, there is still some amount of effort required to ensure that an organization’s credit card processing infrastructure is secure and complies with the various relevant PCI standards.
Update: Bruce Schneier has an interesting post regarding a new flaw in the Chip and PIN card that basically makes the PIN unimportant.
PCI Guru 
I am reposting my comments on the bullets presented by the PCI Guru. There was much more to this discussion, but my answers seem out of context since the context has disappeared. I have therefore restricted this post to the bullets only.
First Bullet:
I am not sure what “open source” means here, I thought “open source” referred to code. Whilst the EMV specification is in the public domain, I am not aware of any public domain code, though I could be wrong. As far as I am aware, all of the EMV code that has been written is proprietary and belongs to the terminal manufacturers and system suppliers.
It is possible to attack the terminals, and the guys at Cambridge University have demonstrated the ability to steal a PIN internally, it’s also possible to extract some of the card data. The problem for the fraudster is that the PIN is useless without the card, and the fraudster can not create a cloned card from the data that can be extracted from a genuine card. The cloned cards referred to in the press and by PCI Guru are magstripe clones, but as we have seen, this loophole has since been closed. The comment relating to computing valid PINs doesn’t merit discussion.
Second Bullet:
Yes, the entry of the PIN can be by-passed by the merchant. This feature was due to an agreed concession whilst the UK population got used to using PINs with credit cards. All PIN by-pass transactions are signature verified, and authorised online as an EMV transaction, generating a Transaction Certificate. All of the EMV processing is therefore maintained, and so it is clearly not the same as a transaction performed on a magstripe credit card, even though it is not PIN verified. As already stated, all PIN by-pass transactions must be authorised online by the issuing bank, and since 14th February 2006, all PIN by-pass authorisation requests are declined.
Third Bullet:
PCI Guru is clearly more in the know then me on this one! I haven’t seen any Daily Mail full page spreads about criminals holding cardholders hostage until they hand over their PIN (I have to say that it did happen once, but I think the motivation was more than just robbery, it certainly doesn’t appear to be the norm). Good story though. Now, on the subject of the card readers: the banks do not send them out to customers when they send out the Chip and PIN cards. The readers are used to secure online transactions, and some other stuff, but this technology is still catching on. More importantly here, the device will not confirm the PIN is correct. The device issues a string of numbers based on the card, its current settings and counters, the time, the result of the PIN verification and other clever stuff. The number is a cryptogram of which one piece of input data is the result of the PIN check. A cryptogram is therefore returned whether the PIN is right or wrong.
Fourth Bullet:
Chip and PIN cards do not enhance online payments. This is the first true (sort of) point that has been made. The reason this is the case is the general mistrust of any device that might be attached to a PC, because PCs are seen as inherently insecure. Chip and PIN authentication tokens on PCs would work fine – the problem isn’t the chip, or the PIN, it’s the perception of the PC! The statement about some banks not allowing chip and PIN cards to be used online might apply to some specific chip and PIN cards, such as ATM-only cards, but as a general statement, this is rubbish!
Fifth Bullet:
Chip and PIN cards connected to PCs can generate authentication tokens, this is true. However, there is no necessity for the standards to define the use of these as surely this would be down to the individual card issuer. 3d-secure provides a framework and is becoming more and more prevalent, but many internet merchants have not implemented this. The fact that security of online environments is not enhanced by the use of chip and PIN cards is not really in question, but the fact that security would be enhanced by the introduction of 3d-secure should be. This lack of implementation has nothing to do with EMV, so shouldn’t really be included in a discussion about the weaknesses of EMV.
I have no idea where this notion of banks not allowing EMV cards to be used on the internet comes from. There are some cards that are not acceptable on the internet, and some of these have chips, but that’s a different story isn’t it?
Sixth Bullet:
Makes no sense. I think you might mean that in some cases the PIN is transmitted to the chip in an encrypted form, but sometimes it’s in the clear. This is true, and it depends on the card. However, as I said earlier, just having the PIN is of no use whatsoever to anybody – the criminal needs the card as well and the cardholder will spot this!
Bullet Seven:
True. The reason for the attack on the merchant terminals was the fact that the Track II data on the chip could be used to create a magstripe card that could be used in the USA. Because of the time it takes to re-issue cards, this took a while to stop, but it went on long enough to be noted. The problem has now gone away. There is now no point in trying to compromise terminals, unless the terminal reads both the magstripe and the chip at the same time (these are around but are disappearing), in which case the real magstripe can be compromised, and a card can be cloned that can be used in the USA. There is a pattern emerging here.
Bottom line is that the PCI Guru, like many security experts, doesn’t understand the mechanics of the EMV process. Applying general security principles to EMV hearsay is not productive – people believe experts and assume that expertise in one area implies similar expertise in other areas. This is not true.
Well written reply, David. I completely agree with your carefully articulated points.
I agree with you david. You have explained your points very clearly.
Update on the update: the Man in the Middle attack does work, but sadly for the Guru, it doesn’t actually present any problems.
Makes good headlines though, and it certainly scares the punters. Must go out and buy some more PCI … !!!
Where have all the responses gone?
After 30+ years of developing and managing POS software, security and operating systems, I’m sure that no matter what I say will sway your opinions.
Remember, we’re not talking about the breach of complete track data in all cases. All an attacker needs is a name, PAN and an expiration date. EMV or not, a lot of POS systems keep those three items and those are allowed to be retained under the PCI DSS.
As to my experience in these areas, I have been working over the years with a number of merchants in the UK and Europe and, regardless of EMV, their POS and back office systems are/were full of cardholder data. They are/were going through a remediation process, but in some cases it’s still there. How did it get there? Bad programming on the part of the merchant’s IT department, contractors and/or packaged software vendors. It’s not their fault. It’s just the programming practices of an era gone by when security was not as big an issue.
Once systems get interconnected on an internal network and then that network gets connected to the Internet, security becomes a very big issue. It’s that process that got lost in the translation at these companies. Luckily and thankfully, security incidents have been minimal, if they occurred at all. However, in a couple of cases, there could have been a major breach if anyone had actually tried.
It is not EMV that is the problem, it is all of the software and databases that exist after the card is swiped that are the problem. A lot of that infrastructure and data resides inside organizations other than banks due to loyalty, membership and other programs meant to entice customers. And even where banks are involved, we’re talking subsidiaries that handle the card processing, not the bank itself. In a lot of cases, those subsidiaries were acquired and are no where near as secure as the bank that owns them for the very reason I stated earlier, their software sucks as well from a security perspective.
So, like it or not, no matter what security features are with the card, they matter little once the card is swiped. Granted, that is finally changing. However, for the foreseeable future, issues will still exist until the new wave of systems get implemented.