Community

"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?"

"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.

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.

Matt,

The BBC footage couldn't contain much detail, if only due to time constraints. They had to cut down two days of filming into a seven minute package. For further information, I'd refer you to the paper, and FAQ.

I do think that these clearly state the limitations of the attack, including that it only works for stolen cards, and that these can be canceled. However, in practice, it does take customers quite a while to notice, especially if their card has been stolen from home rather than their wallet. This, along with mail non-receipt, was after all the reason that PIN-based cardholder verification was introduced in the first place.

I don't think changing the IAC to require PIN is a feasible solution because some terminals do not have a PIN pad, and merchants consider it desirable to fall back to a signature sometimes. The solution we suggest in the paper is for the issuer to cross-check the card verification results (CVR) against the cardholder verification method results (CVMR). This would prevent the attack while still permitting the terminal to opt for non-PIN transactions if necessary.

Steven.

Sorry, the URL to my comment was wrong. It should be http://www.lightbluetouchpaper.org/2010/01/29/why-is-3-d-secure-a-single-sign-on-system/.

Hi Stephen,

Thanks for your comment. I think the architectural change to the four-party model which 3DS introduces is a useful insight. Your point about whether 3DS is single sign-on is also interesting, so I have published a separate blog post on this question.

Steven.

Thanks for your comment.

"then they can optionally perform some internal checks using the current date, such as the number of days that the card can remain offline without contacting the host"

It could be, of course, that the 2016 idea is a red-herring because I haven't heard it from any reputable source. I hope we do find out what the problem is in the end, because it will be a very useful lesson for the industry and should be examined in more detail.

Hi Stephen,

"But still, tampering with a retail terminals on a large scale is still much more difficult than mounting a conventional MitM attack at the browser isn't it?"

Probably, but this isn't an either/or situation; smart criminals will do both.

MitM trojans will pick up credentials for customers who have malware on their PC. However, businesses are more likely to have effective malware protection measures to resist this threat.

Criminals could use attacks like I demonstrated to attack high-value targets. In these cases the investment, manpower and risk necessary to pull off the attack, would be justified by the large payoff, even on a small scale.

South African criminal gangs are already taking this approach (known as whale phishing), and I see no reason crooks in the UK will not follow, if they haven't already.

Hi Stephen,

"If you're mounting a real time MitM attack, you don't need to have tampered with a retail terminal to get the CAP OTP; you just trap the user's OTP as they enter it."

By a real-time MitM attack, I don't mean on on the customer's PC, I mean one on the tampered retail terminal. This would allow criminals to carry out successful attacks against people who:
1) Have no malware on their PC; and
2) Will not visit a malicious website (whether by DNS spoofing or social engineering tricks)

Conventional OTP tokens are not vulnerable to this attack, but because CAP uses the same card and PIN for point of sale and online banking, it can be attacked in this way.

Hi Stephen,

"Sure, obtaining CAP codes via a tampered terminal is a bit of an eye opener, but the secrets are no good in the vast majority of CAP implementations where codes aren't replayable."

In the Barclays CAP implementation, codes are replayable. In the NatWest/RBS implementation they are not, but that's irrelevant because you can perform a real time man-in-the-middle attack so that the resulting authentication code is used while it is still valid. I am not aware of any CAP implementation which can resist this attack. Could you say which particular implementation you are thinking of?