Chip and PIN is broken

This reminds me of that scene in Terminator 2.....

Why can't the issuer simply compare the IAD "offline PIN = false" with the CVMR "PIN verification performed by ICC"?

Hi Adam,

The CVMR is an optional field in the transaction related data, and most UK issuers do not include it in the CDOL. We have heard that some terminals do send the CVMR to the acquirer, even if the card didn't request it. If, in these cases, the CVMR does make it back to the issuer, then yes they should be able to compare it to the CVR in the IAD.

Evidently they do not, so the interesting question becomes "Why?" One possibility is that terminals do not set the CVMR correctly, and so rejecting an authorization request due to a CVR/CVMR mismatch would lead to too many false positives.

Steven.

Seems like the Norwegians made the right decision requiring online PIN for their BankAxept brand (with fallback to offline signature). I think there is a similar solution for the Dancard in Denmark.

Here in Sweden there are many cards with offline PIN. However, CVMR is a requirement in the transaction data, so I hope the issuers can and do take advantage of that, at least for domestic transactions.

You suggest that the issuer could include the CVMR in the CDOL of the chip. What if the attacker then tries to alter the CVMR when it's sent from the terminal to the chip?

"You suggest that the issuer could include the CVMR in the CDOL of the chip. What if the attacker then tries to alter the CVMR when it's sent from the terminal to the chip?"

If the attacker sends a tampered CVMR to the card, then the verification of the ARQC should fail. That is because the card will calculate the ARQC over the tampered data, but the issuer will use the legitimate CVMR from the terminal when verifying the MAC.

There is still an attack on this scheme – also tamper with the CVMR as it is sent to the acquirer. We haven't looked into how feasible this is, but at least in some cases, this connection is both unencrypted and unauthenticated.

"the issuer will use the legitimate CVMR from the terminal"

So including the CVMR in the CDOL will make the terminal send the CVMR separately to the chip and to the acquirer, even if the CVMR wasn't part of the terminal/acquirer protocol?

You also mentioned the possibility "that terminals do not set the CVMR correctly". If this is the case, then the issuer still cannot use it, since it would lead to false positives, right?

"So including the CVMR in the CDOL will make the terminal send the CVMR separately to the chip and to the acquirer, even if the CVMR wasn't part of the terminal/acquirer protocol?"

"You also mentioned the possibility "that terminals do not set the CVMR correctly". If this is the case, then the issuer still cannot use it, since it would lead to false positives, right?"

Online-PIN-only POS terminals would solve the problem the same way as ATMs do.

This is an industry-standard standard approach in many parts of Europe as it pre-dates EMV and as has been pointed out here, several national debit card schemes (still) only allow online PIN at POS just as at ATM.

It is really only in the UK and France that POS terminals do not normally support online PIN.

But, if the terminals have to go online in order to avoid other attacks, why not verify PIN at the same time?

Hi Jeremy,

I think there is a strong case for forcing EMV transactions to be online.

EMV was designed more than 15 years ago when one could not assume that terminals could be online. Now I think it would be much more reasonable.

This would greatly simplify the system, which would go a long way to preventing future problems. It would also lower the costs of the issuing process, and of the cards themselves.

Online-PIN is not such a clear decision however. Yes, it would prevent this vulnerability, but there is still the question of how to securely get the PIN back to the issuer. At least in the UK, the acquirer to merchant link is sometimes unencrypted.

With offline-PIN, the PIN is only sent between the terminal and the card (and is potentially encrypted). With online-PIN, the PIN block will be in the clear each time it is re-encrypted. There have been cases in the US where hardware security module security was breached, leaking the PIN blocks.

So I think a better end-to-end PIN encryption scheme is needed for online-PIN, before it should be recommended. This is certainly technically feasible, but I have not seen any concrete proposals for an EMV modification to support this.

Steven.

Dear Sirs,

Why would anybody bother with a complex attack on chip and pin since you need 1. stolen not yet blocked card 2. the card chip must be SDA or DDA and not CDA   3. The card product must be one that alows offline 4. The terminal must be offline PIN 5. preferrably the purchase need to be offline as well. Many of these circumstances are outside the control of the fraudster. This means that at best, the thief gets away with one or two trx per stolen card for a limited amount.

Much easier to go on the internet and buy something easily sellable by just using somebody elses card number, since there are still a lot of web shops, acquirers and card issuers that do not require any security protocol, just the entry of the card number is enough. 

"Why would anybody bother with a complex attack on chip and pin"

"1. stolen not yet blocked card"

"2. the card chip must be SDA or DDA and not CDA"

"3. The card product must be one that alows offline"

"4. The terminal must be offline PIN"

"5. preferrably the purchase need to be offline as well."

"Many of these circumstances are outside the control of the fraudster. This means that at best, the thief gets away with one or two trx per stolen card for a limited amount."

"Much easier to go on the internet and buy something easily sellable by just using somebody elses card number, since there are still a lot of web shops, acquirers and card issuers that do not require any security protocol, just the entry of the card number is enough."

In addition to CVMR, the terminals usually sends similar information in a general (non-EMV) field to the aquirer. This field has previously been used for magstripe transactions and should have correct values for chip as well. If this is included in APACS 70 and if this is sent to the issuer by the acquirer, then the issuer could use it instead of CVMR to detect the attack by comparing it to the IAD.

Hi Adam,

Are you referring to the ISO 8583 Point of service entry mode? I saw this mentioned in a blog post by Dave Birch. There is apparently a single-digit field which states how cardholder verification occurred, but I haven't been able to find out the encoding. That's yet another specification we should get (this one is £150, which is at least better than the £500 price tag on APACS 70).

Steven.

Dear Steven,

This seems then to be mainly a UK problem since several leading banks in Scandinavia are already issuing CDA chip cards and your attack as described  is not possible on these cards. Furthermore terminals in Scandinavia send the cvr to the issuer as a mandatory requirement which blocks the online mode attack also on SDA/DDA cards. And some card products, like Maestro does not allow  offline purchases so the terminal need to go online for authorisation anyway. For other card products that allow offline transactions the limits are low end which makes a 10 000 pound currency purchase impossible offline. Also most people that loose their cards over here immediately call in to block the lost card since it relieves them of liability from purchases after blocking was made. Therefore it is much easier for the fraudster to access value by sitting at home and get stolen card numbers over the internet and try to buy something online.  Especially since more than 95% of the population have broadband services at home and also pc:s, including the street criminals.

Jan-Olof,

CDA is not sufficient to prevent this attack, nor is online authorization. What is needed is for either the card or issuer to compare the CVMR against the CVR.

The UK banks claimed to do so, but our experiments showed that they did not. The question for other countries is whether they made the same mistake. I think the only way to find out is to perform a test on the live system.

"Are you referring to the ISO 8583 Point of service entry mode?"

Yes, in ISO 8583 it's part of that field.

Steven,

"Quite simply, criminals could make a lot more money this way. With an ATM, you can get £500 per day."

I would be very interested to hear the results of using your attack to get cash from an ATM.

Richard Allen.

Richard,

The attack doesn't work on ATMs. This is explained in the report on page 3.

Steven mentioned ATM above to explain that this non-ATM attack is more efficient than attacking ATMs. You can get £10,000, in cash, in an hour, compared to £500 per day from an ATM.

Richard,

We detail our experiments in our paper. We also discuss the ATM case in our blog post linked to above.

We did not try the equipment in an ATM (there are some logistical problems), but since I have been told that all UK ATMs use online PIN verification, this attack would not work. When I said you could get cash, I was referring to a foreign-currency exchange, for which this attack would work.

Steven,

Apols, I misread the ATM point in your comment.

"I was referring to a foreign-currency exchange, for which this attack would work."

Have you tried this attack against large foreign-currency exchange transactions?

Richard.

Richard,

"Have you tried this attack against large foreign-currency exchange transactions?"

I haven't, because we have not been able to find such a place who would consent to us testing this attack, but we did try some fairly high-value transactions. I think the largest was £200, because that's all the BBC were willing to try. I do know that there are UK currency exchanges which will accept Chip & PIN, without having to hand over the card, and without presenting additional ID.

Steven,

"Are you referring to the ISO 8583 Point of service entry mode? I saw this mentioned in a blog post by Dave Birch. There is apparently a single-digit field which states how cardholder verification occurred, but I haven't been able to find out the encoding."

Actually, this single-digit field does not necessarily include how cardholder verification occured. I just added a comment about this on Dave's blog.

Adam.