There should be a 9-minute film on Newsnight tonight (10:30pm, BBC Two) showing some research by Steven Murdoch, Saar Drimer, Mike Bond and me. We demonstrate a middleperson attack on EMV which lets criminals use stolen chip and PIN cards without knowing the PIN.
Our technical paper Chip and PIN is Broken explains how. It has been causing quite a stir as it has circulated the banking industry privately for over 2 months, and it has been accepted for the IEEE Symposium on Security and Privacy, the top conference in computer security. (See also our FAQ and the press release.)
The flaw is that when you put a card into a terminal, a negotiation takes place about how the cardholder should be authenticated: using a PIN, using a signature or not at all. This particular subprotocol is not authenticated, so you can trick the card into thinking it’s doing a chip-and-signature transaction while the terminal thinks it’s chip-and-PIN. The upshot is that you can buy stuff using a stolen card and a PIN of 0000 (or anything you want). We did so, on camera, using various journalists’ cards. The transactions went through fine and the receipts say “Verified by PIN”.
It’s no surprise to us or bankers that this attack works offline (when the merchant cannot contact the bank) — in fact Steven blogged about it here last August.
But the real shocker is that it works online too: even when the bank authorisation system has all the transaction data sent back to it for verification. The reason why it works can be quite subtle and convoluted: bank authorisation systems are complex beasts, including cryptographic checks, account checks, database checks, and interfaces with fraud detection systems which might apply a points-scoring system to the output of all the above. In theory all the data you need to spot the wedge attack will be present, but in practice? And most of all, how can you spot it if you’re not even looking? The banks didn’t even realise they needed to check.
This attack is both academically and practically significant. We get reports weekly from different victims of phantom withdrawals, and these include large numbers of stolen cards used to make purchases in the window between theft and the cancellation of the card. Currently these victims are denied refunds by their banks, but this attack could explain some of the frauds we are seeing. The fact the receipt says “PIN Verified” when actually it wasn’t raises a whole load of legal and evidential questions which call into question the banking industry’s claim that their systems work (and log) properly. Merchants will be none too pleased either; the system no longer protects their interests but only those of the issuing bank.
There’s been some confusion, possibly even misinformation, about our attack and its effects. Cartes Bancaires in France were so concerned that they briefed the press way in advance of our plans for publication. We can set the record straight on a few things:
- the attack applies to cards used online (where the merchant POS contacts the bank) as well as offline;
- the attack works regardless of the amount of money spent (not just for small value amounts that are below floor limit);
- the attack doesn’t work once a card has been cancelled by the bank — just like stolen cards in the past can only be used for a certain window of time once the cardholder discovers the loss;
- the attack doesn’t work at ATMs (cash machines);
- the failure applies to bank card schemes based on EMV – the most widely deployed standard for smartcard payments. Older national smartcard schemes may or may not be vulnerable; we don’t know.
So what went wrong? In essence, there is a gaping hole in the specifications which together create the “Chip and PIN” system. These specs consist of the EMV protocol framework, the card scheme individual rules (Visa, MasterCard standards), the national payment association rules (UK Payments Association aka APACS, in the UK), and documents produced by each individual issuer describing their own customisations of the scheme. Each spec defines security criteria, tweaks options and sets rules – but none take responsibility for listing what back-end checks are needed. As a result, hundreds of issuers independently get it wrong, and gain false assurance that all bases are covered from the common specifications. The EMV specification stack is broken, and needs fixing.
We’re really worried that if something isn’t done to fix this problem, and the many others we’ve found in EMV, other regions adopting it (like the USA) are going to make the same mistakes again and again – and that means customers stay vulnerable.
That’s why again we’re arguing that Chip and PIN is broken. We don’t want people keeping their money in shoe boxes – we want the problems fixed. That means getting decent governance for the system that involves all the stakeholders – banks, regulators, merchants and customers.
Update (2010-02-11): ZDNet UK have some in-depth press coverage, and the story has also been picked up by the Telegraph and Daily Mail.
total pwnage,
well done guys knew it wouldn’t till it was cracked.
The shocker for me was the silly un-crypted communication between the terminal as a computer scientist it made me laugh.
your chaos communication conference presentation are good too though i wasn’t sure about your tie
POS is really the word i mean the slang term 🙂
i guess these payment systems will never be secure until they stop useing windows on atm.
Remember bill gates line about vista “Vista is so secure it could run life support systems”
(yes i know atm have nothing to do with payment terminals.)
Well done Steven and others.
Anyway i must get back to bioshock
well done guys about time these banks were put right with their silly clames.
so i’ll leave you with this one-liner form Bruce Schneider
“security is not something you can buy; it is something you must have”
Now back to sorting out the splicers.
Take it easy guys.
Excellent work! The devil, as ever, is in the detail – and what a lot of detail in the EMV specs…
Here is a TV clip.
Ross
While your experimentation and reverse engineering of the protocol is clever, the attack is not.
Many security people at the FSA must surely have known the details of how this protocol works. I can only assume there is not a competent person amongst them.
Well done. As a consumer, I’m glad I know that.
One is amazed at the comment by the UK Cards Association (02:06 in the video clip) that the method will never present a real threat to our customers’s cards because… drum roll… it requires possession of a customer’s card.
A bit like going from “it would be very hard for a thief to steal your card AND at the same time figure out your PIN in 3 tries or less” to “it would be very hard for a thief to steal your card”.
And of course not a word about the crux of the matter, ie victim cardholders blamed for the fraud because the allegedly infallible computer system says “PIN verified”.
Great work, guys!
Nice attack. I believe there is another fairly simple countermeasure for issuers though:
The “Terminal Capabilities” data element (tag 9F33) contains a declaration by the terminal of its ability to perform offline PIN.
This could be requested by the card (in CDOL) and checked for consistency with TVR and any VERIFY commands. (Of course the TC element could itself be spoofed by the MITM, making this ).
For online transactions this could be checked directly by the issuer (or acquirer) when processing the authorisation request, as both it and the TVR are supposed to be sent in the online message (book 4, section 12.1.1, table 9).
For offline transactions the card could request Terminal Capabilities in the CDOL and perform a similar check locally, but this is less robust since a MITM could easily spoof the value from the terminal.
Whether issuers perform these sorts of checks In the real world is an interesting question, and your experimental results would seem to indicate that it’s not common practice.
Obviously great work guys, just seen it on Newsnight. I would have thought though, that this stuff would have been very thoroughly checked before implementing it. Good jobs await you. I think..
@James
There’s a field called the CVMR (Cardholder Verification Method Results) which should describe what method actually took place, according to the terminal. Cross check that with the CVR (Cardholder Verification Results) and you should be able to spot the hack.
Sounds simple once you know it, eh?
But implementing such a fix in practice has not turned out as easy as people hoped, for all sorts of reasons. Otherwise it would be fixed already. Sadly it’s not.
Mike
Back when C+P was starting Ross argued that cards should retain a signature option. Does this still seem a good idea?
Definitely a flaw in the EMV protocol. Yet, …
What is security about? Security is all about compromise. Absolute security exists, but it tends to have an absolute price. EMV is not absolutely secure, but it is still a good compromise, far better that signature and magnetic stripe technology;
And, what has been discovered is… Not at all new. This flaw was known since a long time but kept silent;
And, EMV cryptography has not been Brocken yet;
And, systematic online is generalizing rapidly like in Spain or Canada a fix to the identified flaw.
But I have to admit I have not yet read the Paper… Finally, the good new is that maybe this will accelerate the introduction of a replacement to EMV which has proven far too complex for the objective. Maybe a new standard done by some people from other horizon that the Card manufacturers and issuer associations that have worked isolated with a focus far too strong on the card itself, leaving the rest of the transaction chain outside of the analysis… Let’s move on! and thanks for the paper.
Congratulations on finding this, one can only hope that the specifications get improved. While my impressions may be slightly out of date (most of my EMV work was done around 1999-2000), I am not surprised that this type of error occurred. I found a couple of problems myself when designing the host HSM commands to verify the online transactions.
Back then EMV specs were very fragmented, and there was not a very clean hand-off between generic EMV requirements and chip-card specific implementations. There was also a culture problem, much of the offline transactions were done by people who were not familiar with traditional financial transactions (poor or non-existent key typing, dodgy card-terminal negotiation. etc.).
One of my best “no-shit this really happened” stories came out of my EMV experience. Despite strenuous efforts and very solid NDAs, I could I never get test vectors from EuroPay/MasterCard (the E and M of EMV). They claimed that creating test data would leak confidential information. This was despite that fact that we had access (at least in theory) to the algorithms and all we wanted to do was make sure we had implemented it correctly with totally fake keys. As it happened, we did have a minor misunderstanding (been so long I forget the details now) which we did not catch until pilot testing. Needless to say, I am not surprised there are implementation errors when you have people so far out of touch that they think synthetic test data is more sensitive than the algorithm specs!
@ Emmanuel Haydont,
“EMV is not absolutely secure, but it is still a good compromise, far better that signature and magnetic stripe technology;”
Sorry I’d have to disagre quit strongly.
After WWI the French built an in depth fortified line between them and Germany.
As we all know (or should do if our history teachers bothered to tell us) the Germans simply did an “end run attack” and went around the line by going through an adjoining country.
The security of the line gave the French a false sense of security, and it wasted valuble resources.
EVM Chip and Pin does the same but worse.
I would say from the banks reactions they are fully aware that EVM is a pup (ie usless) but it is very conveniant for them to do a smoke and mirrors dance infront of a judge.
The way they play the game it is not even perjury (though it should be), as the person doing the arm waving smoke and mirrors in court is never told. Thus the “knowingly” part of perjury is not for filled (see the declaration on a section 9 witness statment).
Thus the Banks get away with not having to pay for their failings the customer or the merchant picks up the bill. As Bruce Schneier so tactfully puts it “they externalise the risk” in past times onto the merchants who have got so sick of it they started getting nasty (but that’s another story). Now it’s been foisted on the people who can least afford to defend themselves the poor customers.
You only have to take a look at the PCI protocol for security to realise that all it does is provide auditors with a job and merchants with large penalties.
Which brings me onto your comment,
“What is security about? Security is all about compromise. Absolute security exists, but it tends to have an absolute price.”
Yes security is apparently about comprmise, but it is a special type of compromise between cost and risk.
For payment cards the risk of fraud is inordinatly high just look at the declaired losses to fraud across the world and say ok that is the current loss cost, then look at who’s paying it.
Then look at who is mandating the payment card protocols and what the cost is to them and what their risk is.
There is quite an imbalance in incentives.
However getting back to your
“far better that signature and magnetic stripe technology”
Comment. Have you seen what has happened to the fraud figures since EVM Chip-n-Pin was introduced?
What did the fraudsters do when first confrunted by EVM. Simple they did an “end run” around it’s faux defensess and it looks like they are still doing it.
Not being funny but The team at Camb Labs doing their EVM Chip-n-Pin investigations is tiny and comparativly very poorly resoursed for the work.
Ask yourself just what sort of resources can the card fraudsters afford to offer to keep the money supply coming in. Then askyourself what sort of talent those resources could attract?
You might well say,
“Absolute security exists, but it tends to have an absolute price.”
What the customer needs is “proportionate security” not “smoke and mirrors security” designed by those with a desire to off set their risk onto those least able to defend themselves.
Hi Mr Robinson. I have been a victim of a case like this one and I am about to go to court to fight my case, do you happen to know of any jurisprudence, any other case that went to court that could help me with my case? Greatly appreciated
And it occurs to me that the DECT crack – http://www.theregister.co.uk/2010/02/08/dect_phone_encryption_cracked/ – means that it ought to be possible to MITM without wires.
@ Clive Robinson
I totally agree with you. About the PCI DSS scandal, about the transfer of liability from the Issuer banks to the Merchants, about the bad compromise for security, etc. And I would add to it, the related constrains put on the Merchants and Acquirers regarding the end-to-en testing, about the weaknesses of the EMV specifications, and about the general lack of standardization in the electronic payment industry beyond the card.
Yet, the introduction of EMV in Turkey has reduced the fraud on payment by 90%. And the Credit-card fraud in France before EMV, with B0’ cards, was 20 times lower than the European fraud levels… So chip cards can be useful and PIN may be a good cardholder authentication method.
There is still a lot to do…
Many congratulations for going to the effort of implementing all this. However, the possibility of such an attack has been known for many years, both by the banking industry and by academia. Indeed, I have been describing the possibility of just such an attack in a course I have been giving to second year undergd for the last three years – see slide 70 of:
http://www.isg.rhul.ac.uk/~cjm/IY2760/Case_study_1_EMV_0910_v1.pdf
It has been taught to our masters students for longer – and the slide decks have all been publicly available.
Hi Chris–
Fascinating comments. Just to clarify, have you been teaching your students for quite a few years that this attack is possible in both offline and online scenarios, or just for offline?
We have known for a few years too that it works offline, but it was a big step for us to go from there to discovering that it would also work online. That’s why we’re making a fuss.
It also raises this question: if its been known about for several years, and all that is needed to fix it is a back-end CVMR to CVR cross-check, why hasn’t that check been added to bank auth systems as part of a standard maintenance cycle?
@Ross
In the TV clip (comment 3), the terminal clearly shows ‘Visa’ on the screen at PIN entry and the receipt shows a MasterCard AID.
Eh?
@Ricardo
Newnight filmed both Visa and Mastercard transactions, and we used a different card on each shot (to get a representative survey). Every single test worked.
I guess when they edited together the footage, they used a transaction from one card, and a receipt from another; fairly minor as continuity errors go.
I believe that we all hold Cambridge University in awe as one of the world’s most prestigious universities. I have to say, however, that the quality of this so called research leaves a lot to be desired, and could tarnish its justifiably high reputation. If I were an academic and a student were to present me a copy of a paper with some many unproven assertions and innuendo I would be forced to return it to them and ask them to show again! As happened to me when I was a student.
At a time when other academics are under pressure because of doubts over the validity of their research and findings on climate research it is very worrying that others seem hell bent on following the same path; research must be sold and assertions backed up by facts. In the mantra given to all school students – where is the working on the left hand side of the page? To me it reads as opinion and rant thinly disguised as fact.
Let us be clear “Security Economics” theory is sound but unproven, except to those who evangelise it.
Researchers are not in a position to say that an attack such as this is the cause of a fraud, or even could be, without eliminating all other possible causes. The researchers are not competent fraud or police investigators used to generating evidence.
The attack was never successfully executed. To be successful it had to be done against a card that was reported lost and stolen. Nowhere in the report do they assert that they reported their cards they tested as lost or stolen! All they have done is prove a genuine card can be processed with odd and inconsistent CVR and TVR settings. Hardly compelling evidence.
As for the technology used. It isn’t big and it certainly isn’t clever. For Cambridge post graduates with doctorates one would have expected more than a first year electronic engineering student could achieve.
Can we please have some meaningful security research rather than this alarmist opinion speak.
regards
@Chris Mitchell
Thanks for your comment. My understanding of the wedge attack, as was previously described, was that it applied only to offline transactions. As Mike points out, what makes the attack we discuss interesting is that it works for online too.
In our (limited) correspondence with the banking industry, they have always been careful to say that they were not aware of this attack. If it turns out that industry knew about it already, but decided not to fix it, then it would leave them open to allegations of negligence, or even worse.
P.S. I did discuss the traditional wedge attack in a previous post, where I mentioned your slides. Thanks for putting these online.
Re: Scrutineer
So you are now boiling down to the argument that because the card would be reported stolen, it won’t work anyway.
If you’re suggesting that it is improbable that a fraudster would have a stolen card that hasn’t been reported, then why have chip and pin at all in online scenarios – using your argument if you have a card that hasn’t been reported stolen it must be legitimate.
Alex
The chap “Scrutineer” who posted comment 19 seems to have forgotten to sign it!
Anyway he’s not very good at anonymity:
$ whois 193.128.116.71
….
address: APACS (Administration) Ltd
address: 14 Finsbury Square
address: London
address: EC2A 1BR
address: England, UK
Pity APACS couldn’t get it together to put up a spokesman for Newsnight
Surely that has to be a set-up? I realise that APACS quite frequently have been bad with their PR – but a member of staff posting something like that from their work PC? That’s pretty misguided.
It’s also a bit strange as reading the paper quite clearly shows that certain things are presented as fact, and others as opinion, and the dividing line is pretty clear.
@Ross
That machine responds to an HTTP request with a blank page with the server header set to: “Webproxy/5.0”, which is apparently the an old vulnerable (http://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2005-4085) version of “Blue coat winproxy”.
Looks like a compromised machine to me.
Good trolling though.
I refuse point blank to use C&P maybe because I’m paranoid. It’s quite easy to obtain pin numbers just by standing behind someone doing a transaction, then mugging the victim in the car park, max the card out and throw it away. My lack of awareness has caused me problems when I go into my bank though, as if I want to book an appointment with an admin bod, I have to use it; this has created some relatively minor scenes. Cash may be the poor man’s credit card, but I’m happy to stick with it whilst it exists!
I suspect it will take some time to fix, due to costs involved. It’s good to keep them on their toes, though.
I see the same security flaw in the EMV specification and ICAO specification for ePassports. There is some information optional and it can be used to bypass the security measures. EMV: PIN, ICAO: signature over critical data. Workaround could be that the terminal signals the capabilities, e.g. PIN and signature verification, and this capability information is signed, and the card will enforce these. Then you need of course either an on-line transaction or a SAM in the terminal.
This is absolutely fantastic work.
Thank you for showing that these systems are imperfect; It’s important that people do not simply behave like slaves in the face of a simple printout from a machine. Your work keeps people aware, skeptical, and asking questions that cannot be silenced with an argument from authority.
It’s very inspiring! Great job!
I am a bit surprised that EMV be presented in the paper as a standard used in Europe + Canada. It is deployed on all continents and it is faster to name the few countries with no migration plan than the countries that have or are migrating: US and some African countries are the exceptions…
About the term “Chip and PIN”, it is a name used by APACS for the second EMV migration project to EMV. The first one having been done without PIN… So it is definitely an English term based on the local UK organization created for that purpose of the migration to PIN. Mostly the standard is known and referred to as EMV in English and non English speaking countries.
Just to bring some precision…
@Emmanuel,
It is deployed on all continents
what about antartica?
I worked with EMV for a few years in one of the payment card organisation, but have been out of touch with it since 2006. If my memory serves me right the “signature” based customer verification is still supported only due to the issuer bank business needs. The issuers would like to ensure the cards are still accepted if the PIN based verification does not work due to a problem with chip (damaged) or customer forgets the pin.
Why is there such a problem to configure the card not support signature based verification method? OK, the issuer banks may lose some revenue. But hey, here in the Netherlands PIN and mag stripe are used and if the customer enters a PIN 3 times and gets it all three times wrong, the Merchant will not accept the signature.
So I cannot see such a big impact and do not consider EMV flawed. In the first place signature verification is a pretty weak customer verification method and should be removed as an option.
Forgot to metntion, that of course, the issuers will have to stop configuring “signature” based verification method in their newly issued cards. in the worst case scenario they can replace the cards before the planned expiry date.
This is a very clever attack, however there are 2 glaring mistakes in the draft paper. On page 5, the following 2 sentences are completely wrong:
“The IAD (Figure 5) does often indicate whether PIN verification was attempted, however it is in an issuer-specific proprietary format, and not specified in EMV.”
– The IAD contains the CVR, which are both defined by EMV and the card associations. The CVR should be reviewed by the issuer to determine if Offline PIN was actually attempted.
“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.”
– As above, the CVR (provided by the card and protected by the MAC) indicates whether Offline PIN took place.
So this isn’t a failure in the EMV protocol, but in the approval logic used by individual Issuers. The fact that some Issuers don’t review the CVR is a risk that they take.
@Alun Harford
The IP address used by Scrutineer to post is certainly registered to APACS (aka the UK Cards Association). I also know that APACS use a proxy for their Internet access. So either the commenter just happened to select an open proxy owned by APACS or, more likely, he/she works for APACS.
@Joe
Neither the format of the IAD or CVR are defined by EMV. All the EMV specification says about the IAD is “Contains proprietary application data for transmission to the issuer in an online transaction”.
There is the Common Core Definitions, which does define a recommended format for the IAD, but I have not seen any cards which comply with that standard. The ones which I have seen follow Visa cryptogram format 10, which is covered by a VIS specification.
Indeed they should, but the problem is that the EMV specification does not allow them to check whether the terminal believes it has carried out offline PIN cardholder verification.
EMV is a security specification, and the fact that it doesn’t tell the issuer how to prevent this attack is a serious flaw. In fact, it doesn’t even give the issuer enough information to prevent the attack.
While the issuer can tell whether the PIN was correctly entered (through the CVR), finding out whether the terminal thinks the PIN was correctly entered is left to other standards. The TVR, which one might think would be enough, is inadequate (see the paper for details).
Specifications are supposed to encourage good implementations, and the fact that every single implementation we looked at is flawed in the same way strongly indicates that the specification is to blame.
@Steven
But your attack clearly shows that issuers should never rely on terminal results if they want to determine whether offline PIN was performed. This is probably why EMV specifically excluded this type of indicator from the TVR – they may have known that it couldn`t be trusted. Issuers must rely on card results to detemine if offline PIN occurred (i.e. the CVR).
“There is the Common Core Definitions, which does define a recommended format for the IAD, but I have not seen any cards which comply with that standard. The ones which I have seen follow Visa cryptogram format 10, which is covered by a VIS specification.”
– This means that you tested Visa cards, which means the CVR is present (as required by the VIS specifications).
– Also, if an issuer isn’t compliant with CCD, isn’t that a problem with their implementation, not the specifications?
“Specifications are supposed to encourage good implementations, and the fact that every single implementation we looked at is flawed in the same way strongly indicates that the specification is to blame.”
– Or it could mean that the issuers you tested simply made the same mistake (e.g. not checking the CVR or issuing cards not compliant with CCD). I guarantee this attack would not work with the Canadian bank that issued my CCD-compliant Visa card.
Again, if an issuer doesn’t follow EMV’s security recommendations, how is that a problem with the specifications?
Hi Joe,
Let me make a few comments on the exchange above.
We’ve tested this attack for a range of issuers, on cards issued in th UK. APACS said in their press release response that this attack is “easily detectable”, but here we are, the attack still works despite us informing them about it months ago.
I think that our discussion shows that “guaranteeing” that this attack doesn’t work based on reading the (enormous piece of) specification doesn’t provide much confidence. The only way to know for sure is to test if the attacks works on a live system.
Security protocol design isn’t poetry. If the protocol/specification allows the implementer the freedom to “interpret” one of its fundamental security properties, it’s broken. In other words, it needs fixing. Remember, it’s called “Chip and *PIN*”, and what you are suggesting is that the specification is allowed to let the implementer ignore the PIN part. I don’t think that’s right.
All
When one places comments on topics such as this on discussion groups it is generally acknowledged they they are personal observations and no more than that irrespective of where they may seem to come from.
In doing so I was offering these personal observations in the spirit of what is supposed to be lively and passionate debate on an important topic between indivudals. I acknowledge that I wa sperhaps more passionate than I should have been, but if we cannot be passionate at this time of year when can we be. No one cannot tell me that the authors aren’t as equally passionate about their work, and why shouldn’t they be?
My goal, which I probably failed, was to try to encourage a broader debate on the type of issues raised in this valuable research. Let me say again, however that this was valuable research because only fool doesn’t value vulnerability research. It is important and challenging, and I would suggest all the more valuable coming from where the researchers are. The point I was making in the debate is that we are all entitled to our differing assessments of the significance of the vulnerability findings.
Surely this is healthy to test the findings! By way of example of how differing research comes across I would like to note that we didn’t see the same level of passionate assessment and opinion of any perceived criticality by the authors of other equally valuable research.
And here I refer to what, I think we all may agree, is perhaps more serious vulnerabilities in our crypto primitives with the factorisation of the 768 bit key and last years attack against MD5. All I am trying to do is to encourage a balanced and reasoned assessment in order to build upon the quality of research so we can a broader consensus of the significance of any findings. I am not sure an adversarial approach is the best for any of us.
In my note I noted that there is more than an ample set of topics for security research and security vulnerability researchers to engage upon. Perhaps I should identify some areas of research
to exemplify what I was thinking about.
The authors note the importance of establishing mutual authenticity and mutual trust between two objects – I agree 100%. The challenge is that although SSL is good, is it a good enough, efficient enough and quick protocol in any and every application? Would that we could find one or prove that SSL could work in the any-to-any authentication paragdigm.
From a security vulnerability research we have the prospect of the IT industry embarking upon cloud computing. Yet we have no established body of knowledge of the underlying vulnerability of the primitives that will rely upon to keep data separate and secure.
On a consumer front we have everyone telling us that mobiles are good for anything and everything. Yet here again the underlying knowledge of the vulnerbailities of the platform and the components within it are weakly understood. Many of the analogies relate it to the PC platform, and whilst valid is it worse or better, if so why?
In this sense I would welcome and embrace any vulnerability research that allows us to make better decisins on how and what we need to deploy, and perhaps mitigate or prevent the need to debate vulnerabilities after the fact than before.
regards
I have a small technical remark on the paper. In the section “VI. SOLUTIONS AND NON-SOLUTIONS” you state:
Such a repair may in fact be possible: the card can change its CDOL to request that the CVMR (cardholder verification method results) be included in the payload to the Generate AC command.
I don’t think this would make a difference for the described attack. The card has no way to authenticate the payload and the man-in-the-middle device could therefore modify it to indicate no PIN entry has occured.
What is more important, is the sum of all transaction data sent to the issuer by the terminal.
Regarding the attack you described, the question is whether the terminal sends the CVMR to the issuer (along with all other transaction details like the amount).
In case the terminal has not been tampered with, the issuer can trust this terminal view of the transaction and compare it with the CVR contained in the IAD.
Several bank-type people have said that the attack is detectable at a later time from examining their records. The issuing bank will be able to tell that the card thinks a signature was used, but will the acquiring bank have records to say what method of cardholder verification the terminal thinks was used?
The TVR doesn’t contain it, but does the acquiring bank get any other records from the terminal? Does the terminal keep any long-term records?
On another point, won’t the issuing bank see from the IAD that the card thinks a signature was used, and demand the signed receipt? In which case liability would fall on the retailer, not the cardholder?
I think that our discussion shows that “guaranteeing” that this attack doesn’t work based on reading the (enormous piece of) specification doesn’t provide much confidence. The only way to know for sure is to test if the attacks works on a live system.
I made the statement based on some testing that I performed on numerous bank cards in my possession (they all provide CVR) and confirmation from one Bank that CVR results are reviewed (I know someone at this Bank). So in the case of this Bank, the attack wouldn’t work, since the attack relies on failure to check the CVR appropriately.
Security protocol design isn’t poetry. If the protocol/specification allows the implementer the freedom to “interpret” one of its fundamental security properties, it’s broken. In other words, it needs fixing. Remember, it’s called “Chip and *PIN*”, and what you are suggesting is that the specification is allowed to let the implementer ignore the PIN part. I don’t think that’s right.
But it’s not really an interpretation issue. The EMV specifications define a specific CVR bit to indicate whether Offline PIN was performed. Should they have included a warning that failure to check this means that Offline PIN may not have been performed? Okay, that probably would have helped these UK banks, but I don’t see how that’s a failure in the specifications.
As another example, if an issuer decides to authorize transactions with incorrect MAC values – the primary security feature of EMV – under certain circumstances (e.g. low-value transactions from countries or networks with poor telecom service) is this a problem with the EMV specifications?
Saar,
Sorry, I forgot to address post #40 to you…
As a consumer, I am from the United States. Even though we don’t use chip and pin. We do use pin at merchants using an ATM or Debit card. I wrote Professor Ross.Anderson. Don’t know if he will answer. With my dual branded debit card. I use it as a pin transactions whenever I can, to save the merchants money. What I want to know if I should go back to use it as signature transaction and only use pin if I need cash back. I do change my pin every so often.
Types of cards the U.S. has
For checking account
ATM cards restricted to the your own banks ABM-Requires using a pin
ATM cards restricted to ABMS (Which is becoming obsolete)–Requires using a pin
ATM cards that work at merchants and ABMs-Requires using a pin
Debit cards with a MasterCard or Visa logo-Can be used a signature or pin–This is what I have.
A Quick n’ Dirty Fix.
In section III of the paper you wrote:
“The IAD (Figure 5) 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.
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.”
But the last isn’t a plausible, or even possible, conclusion for the issuer.
I’ll assume that the card’s CV Rule list (which the issuing bank will know) contains the following rules for different CVMs (cardholder verification methods).
1) online verification (for ATMs)
2) offline verification (the situation we are talking about, where cardholder verification is done offline by the terminal but the terminal is online)
3) signature verification
– there will probably be some more rules, but that’s enough for now.
For an ordinary sales transaction the terminal will go through the list of rules in order, bypass the first option, and consider the second.
There are “exceptional” situations where rule 2 will also be bypassed and rule 3, signature verification, will be chosen. I’ll go into those later.
If the bank sees that bit 3 of byte 5 of the IAD is not set (the authenticated-by-the-card card’s view telling the issuing bank that, in the card’s view, offline PIN verification has not been successfully completed) and none of the bits of byte 3 of the TVR are set, then there are three potential causes of this:
a) one of the “exceptional” situations has occurred and rule 2 has been bypassed,
b) the CVM in rule 2 is not supported by the terminal, or
c) an attack of this type has taken place.
In regard to b): “If the CVM is not supported, processing continues at step 2. In case the CVM was PIN-related, then in addition the terminal shall set the ‗PIN entry required and PIN pad not present or not working‘ bit (b5 of byte 3) of the TVR to 1.”
[EMV Integrated Circuit Card Specifications for Payment Systems Book 3, version 4.2, section 10.5, page 104.
Available at http://www.emvco.com/specifications.aspx?id=155%5D
The conclusion that “the terminal was incapable of soliciting
a PIN” is however *not* possible, as if that had happened because the terminal didn’t support it or because the pad was broken then bit 5 of the TVR would be set.
Which leaves only the possibilities that the rule was bypassed or an attack has taken place.
The circumstances in which a CV Rule is bypassed are:
“If any of the following is true:
the conditions expressed in the second byte of a CV Rule are not satisfied, or
data required by the condition (for example, the Application Currency Code or Amount, Authorised) is not present, or
the CVM Condition Code is outside the range of codes understood by the terminal (which might occur if the terminal application program is at a different version level than the ICC application),”
[EMV Integrated Circuit Card Specifications, as above]
The first of these circumstances happens a lot, eg that’s how rule 1 got bypassed above, so it’s not really “exceptional” at all.
However the issuing bank knows rule 2 in the card, and knows when it should and shouldn’t be bypassed.
The issuing bank will also in most cases know when the second condition should be invoked by the terminal (almost never for a normal domestic transaction).
The third is a little trickier, but if they stick to the simple codes then in most cases they will be able to avoid this. Again, it’s not something which happens in a normal transaction.
Thus the issuing bank will, in most cases, be able detect and prevent an attack of the type in the paper.
They would get some false positives if they only look at bit 3 of byte 5 of the IAD and bits 3-8 of byte 3 of the TVR, but they shouldn’t get any false negatives, and the false positive rate can be lowered by looking at other factors such as why the rule might have been bypassed.
I would seem that the Banks don’t actually do this sort of checking, and that’s why the attack works in practice – but I don’t see why they couldn’t start.
It’s not a “proper” fix, but …
Interesting finding. very similar to that of SDA vs DDA vs CDA, i.e. DDA can be attacked using the same “man-in-the-middle”, thus CDA was introduced. I guess they can extend this to offline PIN, i.e. combine offline PIN with DDA with generate AC.
but would doing the above, prevent any other attacks? of course time will tell…
Is the specification flawed? Depends on the perspective… It’s flaw is that it provides too many options for implementation and has left issuers to use their risk management to decide what to implement… Unfortunately most only validate transaction using the cryptogram generated…
On the other hand, I do believe that EMV is a specification for the communication between the card and the terminal… some would even argue that it is a terminal specification… the card specification is scheme specifics, in which case it is the scheme that would need to strengthen their authorisation protocol.
There are a lot of other data included in the transaction that is not being used at the time of authentication (IAD, CVMR, etc) This is the unfortunately reality, which needs to be fixed.
The interesting question is: who would be at fault, and who should be made liable?
If I understad it correctly it’s actually a “signature” purchase that is validated by the bank and not a “PIN” purchase (Even though the user thinks so). But if the user hasn’t actually put any signature on paper how can the bank not refund the money to the customer? In the transaction log in the banks backend system it must show that the purchase was made with a signature and not with a PIN verification.
Hi All,
A few comments here
1.) If the offline PIN is not verfified by the card, the Bit on the card for Offline PIN verification not performed will be set. correct??
2.)If the wrong PIN is inserted, the bit for Offline PIN verification failed will be set.correct?? (on CVR and not CVM )
So based on the prefference of the issuer you may set the card to decline these transactions offline
In addition if the card believes the PIN is INCORRECT and the terminal believes that the PIN is CORRECT, then the CVR Bit on Terminal erroneously considers offline PIN correct will be set. Here the card compares the CVR (offline PIN verification failed against the CVM results to determine this.Again the Isser has the option of setting the card to decline these transactions offline.
In the even that the issuer prefares to send such transactions online, The CVR can be examined by the issuer’s systems and decline the transaction based on the particular bit being set in the CVR
Unless I’m missing the point here???
Hi all, just a quick note to say that we welcome the vigorous discussion, from all commenters, both those comments on technical issues and on policy/ethical issues.
Of course if you undertake a vigorous attack (which on examination we disagree with) expect a vigorous response! But that is not to say that criticism of our work is unwelcome on the comment thread.
I’ve been compiling a big chart of responses to the work — as you can imagine when a big story breaks there is a sea of feedback so it will take some time. Once we’ve discussed the chart, we hope in due course to use it to update the paper and to provide other commentary on the feedback we’ve received.
So, thanks all, and watch this space.
Mike
Nice, simple, protocol break.
It seems to me that one of the reasons that these chip and pin security weaknesses can be ignored is that a wire running up the sleeve to a laptop in a backpack gives the false impression that the equipment required to execute the attack needs to be bulky or expensive.
Perhaps you should look into miniaturized MITM technology similar to the Turbo SIM.
(For readers unfamiliar with this technology, these consist of a micro-controller mounted on a thin circuit board which fits between a GSM phone and its SIM card. They can be used to modify the SIM card communications to provide additional features.)
This attack looks like it could very easily be implemented with similar technology.
The weak link in this attack is the terminal and not the card. The terminal thinks it’s performing a “PIN” transaction while the card actually responds with a “signature” transaction which the terminal then just sends to the bank for verification. If the terminal actually had provided the information to the bank that user had entered PIN on the terminal then the transaction would not go through since the PIN veification flag wouldn’t have been included in the cryptogram while generation a “signature” transaction.
So it’s probably the protocol between the terminal and the bank that needs to be upgraded. The cards are working fine as they are. Unless it’s an offline transaction, then the problem would remain.
@Peter
I think it is genuinely unclear whether the TVR bit for “PIN entry required and PIN pad not present or not working” should be set if the PIN pad is not present. My reasoning is that the section you cited is conditional on “If an offline PIN is the selected CVM as determined by the above process”.
The UK CVM lists I have seen all state that offline-PIN should be used only if the terminal supports it. Therefore, I think the CVM selection process will not choose offline-PIN if the terminal has no PIN pad. In which case the terminal should skip offline-PIN without setting bit 5 of byte 3 in the TVR.
I agree this is counter-intuitive, but is I think what the specification says. In any case, I think that there is enough ambiguity for a reasonable proportion of terminal manufacturers to not set the TVR during this attack.
As an aside, I think this illustrates one of the major problems in EMV. It is so complex that even on close reading, it is hard to know what terminals should do.
@JoJo
In EMV, there are multiple data items which pertain to cardholder verification, and multiple logs. The problem from the customer’s perspective is that the bank’s logs will be inconsistent. The TVR will show PIN verified, as will the POS Data Entry Code and the Cardholder Verification Method Results (CVMR). The Card Verification Results (CVR) will show that PIN verification was not performed.
So the question is, if the transaction is disputed, which log will the bank look at. I think common practice is to inspect the settlement log, which will show that the transaction was authorized by PIN, hence the customer is likely to be held liable.
Of course, if the bank looks into the full details of the authorization request, they will discover the truth. However, in my experience, fraud investigators have neither the expertise or access to do so. And by the time there is any external scrutiny, most of the logs (including the CVR) have been destroyed.
In my experience the bank would simply present the merchant receipt which says “verified by PIN”, and inspect the settlement logs which show the terminal’s perspective of the transaction, i.e. that the PIN was entered correctly.
@Iaru
The online authorization system could be configured to reject a transaction based on the CVR stating that offline-PIN verification had not been performed. However, this would prevent terminals without PIN pads from working (these do exist), and prevent merchants from opting to fall-back to signature (which they consider a desirable option). The issuer would also have to special-case cards issued which do not have a PIN, given to customers who request them.
The card cannot prevent this attack for offline transactions, because the man-in-the-middle could simply turn the AAC into a TC, as well as interfering with cardholder verification.
This assumes that the CVM results go to the card or issuer. In the UK, cards typically do not request the CVM results. They may go back to the issuer though (but the EMV specification marks this as optional).
Since the attack works, clearly issuers do not. They have not stated why. It could be that issuers don’t have the CVM results, or cannot sufficiently rely on it when deciding whether to authorize the transaction.
@ steven (50) (Hi!)
I don’t entirely agree that it’s unclear – the “above process” is the process by which the rule is bypassed, which I covered.
If the terminal does not bypass the CV Rule in my view it clearly should set the “PIN entry required and PIN pad not present or not working” bit (or another bit) when it looks at the rule in these circumstances. That’s what all versions of EMV from v3.0 onward say – also see figures 9-12.
Though perhaps it’s the name of the bit which is confusing, as PIN entry is not required for the transaction to proceed.
EMV have changed the wording of the section a few times, maybe that’s why – but apart from the name it doesn’t seem ambiguous to me.
Maybe EMVco should rename it the “PIN entry required by an attempted CV Rule but terminal unable to comply” bit, ‘cos that’s it’s real function.
I’d expect that EMVco testing would require the bit to be set in these conditions on all terminals made since at least 2004 and probably earlier, but I don’t know for sure.
Do you have any data on how often terminals don’t actually set the bit when they should?
However even if it’s unclear and some terminals do “misbehave” the issuing bank could still quite easily check the seven bits in the ARQC involved with a couple of lines of code, and if they are all unset then they could divert the transaction for more detailed examination.
They would get some false positives, some because the bypass rules were followed and perhaps some because of terminal misbehaviour – but not many over all.
Even if some terminals misbehave and do not set the bit when they should, I think that by far the majority do – and the vast majority of offline verifications will not fall back to signature due to pad failure or absence of pad anyway, and the offine_verification_successful bit in the IAD will be set in these cases.
If the retailer bypasses the rule (“I don’t know my Ma’s PIN”), then a bit gets set for that. If the terminal is behaving as it should but the pad gets broken or is otherwise unavailable, then a bit gets set too. So, assuming most terminals don’t misbehave, there won’t be many false positives.
More importantly, they would catch all these attacks just by checking seven bits, which would be significant if the attack becomes prevalent in the wild.
I don’t know for sure what other kinds of examination would be needed to weed out the false positives, as it would depend on how often rules get bypassed, how many terminals misbehave and so on, and the interactions between the bank and the terminal are covered by different standards and I don’t know what other data the issuing bank gets – but it shouldn’t be that hard to do it to the required level if the rate of these attacks gets high.
As for disputed transactions, the bank can in most cases tell for sure when the attack has not occurred just by a simple check of seven bits in the ARQC or TC.
That’s if they keep them – they should be automatically liable if they don’t, they are the main primary evidence that any sort of transaction at all has taken place, otherwise it’s just bank records.
As I said, it’s only a quick n’ dirty fix – it doesn’t fix the underlying flaws in the EMV protocols – but as far as I can see it’s a practical fix for an issuing bank to implement quickly and cheaply if the attack becomes widespread.
@Peter
That is the key question, but I don’t know the answer. The TVR is rarely on the receipt, and we haven’t ever logged a transaction while using a card in a terminal without a PIN pad.
Sure, but I can’t see how the banks currently know what the rate of these attacks is. I know there are at least 10, because I did them (with consent of cardholder and merchant). The banks missed all of these, so who knows how many other ones they are missing.
That’s why I would like to see the banks to look over their previous transaction logs, and find out whether this attack has been happening.
Agreed. It is sadly not the case though. I hope disclosure of this vulnerability will help change the situation.
It would be very interesting to know how a bank would handle a dispute over a transaction where this attack was used.
The key question is if they would claim that a PIN was used and hold the customer liable, or if they would see that there is something wrong with the transaction and accept the liability.
As the issue stands right now you have demonstrated that the vendor will accept the transaction thinking that a PIN was used so the bad guy will get away with the goods.
You have still not demonstrated who will be forced to accept the loss, the bank, the vendor or the customer.
Any chance that you might continue with such an experiment ?
@Stefan G
I agree this would be very interesting. It’s a tricky experiment to do, though. If you got your money back, it could be argued that you had committed fraud. The banks have been known to prosecute people who disclose vulnerabilities in their systems, so I would not like to give them an opportunity. The journalists we’ve spoken to weren’t willing to go this far either.
It should be possible to safely do this experiment with the bank’s consent. In fact, they should be doing this already to test whether their systems are working. However, as far as I know, no bank has actually tested whether this attack works on their systems, nor tested whether their dispute handing processes work.
We have offered our assistance to the banks, but so far have received no response, other than through press-release.
This is for sure true for VISA 1.4. MasterCard MChip4 has internal check for this attack. One of the CVR bit “terminal erroneously consider PIN OK” Together with CDA this will be safe.
@Lars
This attack does work for MasterCard cards (we tested). It would be good to look at the M/Chip4 specification you referred to though. Is it publicly available?
@Steven
Sorry but the document belongs to MasterCard. Any how they warned for this already 2007. The MChip/4 standard is the common MC standard for EMV chip since at least 2007. But still banks issuing EMV cards om MChip 2.1. Mabye you tested on that old chip OS?
@Steven
Ask Mike about the documents? I have meeth him in Sweden and I think he will have it…
Hi Lars–
Thanks for dropping by the blog, as you can see there are theories flying in all directions about what works and what doesn’t, and for those who agree it works (It clearly does on a range of UK cards), a vast variety of theories on the best or most appropriate fix. We appreciate your comments in the mix.
I do have MChip/4 spec knocking around somewhere at the office but while I can take a quick look see for this CVR bit you describe, I can’t really send the docs to Steven. Not without getting into trouble with Mastercard, just like you may.
Oh for a day of public specs…
Steven I’ll let you know the status quo on this bit that Lars describes when I’m next in the office (thu prob).
cheers,
Mike
Hi Mike,
Nice to hear from you. At page A-38 in “M-Chip 4 Card Application Spec…” you will find all the CVR bits. Also take a look at the flow diagram for Gen AC1. Hint CDOL is involved! For Online the banksystem has to take care about the checking as decribed on this blog.
//Lars
Steven/Saar,
I’d like to summarize our discussions thus far…
There are 2 facts we’ve established:
1. The EMV specs define the CVR, which is sent to the issuer during an online transaction.
2. The CVR contains 2 bits (Offline PIN Verification Performed and Offline PIN Verification Performed and PIN Not Successfully Verified), which the issuer can examine to determine if offline PIN verification occurred.
And these are your conclusions, which I believe are incorrect:
1. There is a fundamental protocol failure in EMV. But the facts clearly show there’s nothing with EMV. The problem is with the authorization logic used by the banks that you tested.
2. Issuers must ignore the EMV framework to fix this problem. On the contrary, issuers should follow the EMV framework more closely. The information they need is available – they simply need to start looking at it. And an important note: in the event of a dispute, the bank can always examine the CVR after the transaction (if they’ve retained it), to determine if offline PIN really was used.
@ joe
The CVR may well be sent to the issuer in an offline-cardholder-verified online transaction, though the CVR is not in the EMV spec. I/we are assuming it, or something like it, is sent in the IAD.
But the CVR is just the card’s view of what happened.
In order to detect the attack in real time from only data which the issuer gets, the issuer has to compare the card’s version of the cardholder verification method used with the terminal’s version, and see if they differ.
He needs both versions, the terminal’s and the card’s.
The bits in the CVR which you describe are of no use in detecting an attack – in an attack situation they will simply show that offline verification was not performed, which is not enough information for the issuer to refuse the transaction.
It doesn’t tell the issuer what the terminal thinks took place.
There may be other information in the CVR which does, but I don’t think there is, and even if there was it could probably be MITM’d as well, as it would have to come from the terminal.
Afaics the only field in which the issuer reliably gets with information on what the terminal thinks happened is the TVR.
Sometimes the issuer gets the CVMR, which could also be used to tell the issuer the terminals view of what happened – but the issuers don’t always (or even usually) get it.
@Peter
The CVR may well be sent to the issuer in an offline-cardholder-verified online transaction, though the CVR is not in the EMV spec. I/we are assuming it, or something like it, is sent in the IAD.
The CVR is defined in section C7.3 Card Verification Results of EMV 4.2 Book 3 Application Specification.
In order to detect the attack in real time from only data which the issuer gets, the issuer has to compare the card’s version of the cardholder verification method used with the terminal’s version, and see if they differ.
He needs both versions, the terminal’s and the card’s.
That’s not correct. If you look at the contents of the TVR (in C5 Terminal Verification Results), you’ll see there’s nothing specific to indicate whether Offline PIN was performed.
This is by design – the EMV specifications know that only the card can be trusted to provide this information. The TVR will tell you whether cardholder verification was successful, but you have to look at the CVR to determine if Offline PIN was the method used. Note: The TVR does provide additional information on why Offline PIN was NOT used (Pinpad not present, PIN bypassed, etc) in case the issuer wants to know why a non-PIN method was used.
The bits in the CVR which you describe are of no use in detecting an attack – in an attack situation they will simply show that offline verification was not performed, which is not enough information for the issuer to refuse the transaction.
The issuer doesn’t need to detect this attack in order to decline the transaction. The point of this attack to fool the issuer into approving a transaction that it thinks was verified using PIN – it won’t work if the issuer examines the CVR.
@ joe
The attack isn’t about fooling the issuer into thinking a transaction was verified by PIN. He always knows when a PIN wasn’t used, from the CVR.
But the issuer can’t reasonably decline transactions just because they weren’t verified by PIN. There are millions of entirely legitimate transactions like that every day, people would be up in arms.
In non-PIN cases the TVR should tell him why the verification was not done by PIN. If it does then the attack has not occurred, and he can authorize the transaction, all else being well. This will happen for almost all the legitimate non-PIN transactions.
If the TVR doesn’t tell him why the PIN wasn’t used then the attack may have occurred and he can either decline the transaction or, more likely, look for other indicators like a CVMR or a PIN entry type code, terminal type, etc. before deciding.
Hi, I am joining this debate which is quite interesting.
My feeling about this:
1) nothing new in this attack, this was quite obvious for all EMV professionals that the PIN can be tricked like this (there are no verifications by the terminal that the PIN is entered correctly – Note: a card status word is not a proof)
2) of course, this can be seen as a problem, but not in EMV logic: offline PIN is to be checked by the card, not the terminal, so the card ‘knows’ if the PIN has been entered correctly. The correct information is logged by the card.
3) the only real discovery is that some issuer authorization systems can allow such transactions. I think this can be fixed quite easily as detailed in the previous posts. But anyway, if the issuer can’t be 100% sure that it is a risk management assessment: security Vs. service. does an issuer prefer to authorize risky transactions or to refuse legitimate transactions?
4) mineral water is so expensive, 5 GBP for a small bottle!!
In such security issues, you have to look at the whole system to get a clear picture of what is happening, and to understand the risks:
1) the cardholder does not risk anything. A transaction has been made without the PIN (the proof is the CVR, which is authenticated by the application cryptogram — the ticket and POS logs are no proofs as there is no proof cryptogram) –> the cardholder is not liable
2) what about the merchant??? nobody is talking about it. a guy is performing a transaction with an obviously fake card (not talking about the other stuff that I am sure can be miniaturized so I will not insist on that). Merchant is clearly liable. Same when they never check the receipt signature Vs. card signature… Merchants (acquirers) have obviously chosen service over security, that might have to be rethinked.
3) there are a lot of different securities in the EMV / payment system, if one fails, there are a lot of others that will be triggered.
I have a lot more to say about this, but will stop here for the moment…
@Lars
As Mike says, thanks for your comments. I will be sure to investigate the M/Chip 4 CVR in more detail.
This however raises an interesting issue. If the banks were made aware of this attack, in writing, why haven’t they fixed it 3 years later?
I wrote:
In non-PIN cases the TVR should tell him why the verification was not done by PIN. If it does then the attack has not occurred, and he can authorize the transaction, all else being well. This will happen for almost all the legitimate non-PIN transactions.
If the TVR doesn’t tell him why the PIN wasn’t used then the attack may have occurred and he can either decline the transaction or, more likely, look for other indicators like a CVMR or a PIN entry type code, terminal type, etc. before deciding.
I got the PIN entry type code name wrong, it should be the “PIN_entry_mode”. It’s subfield 3 of field 22 of the ISO8583/UKPA standard for messages between issuers (acceptors) and acquirers. If the terminal thinks the cardholder was validated by PIN it should have a value of 9.
However the point of using the TVR in the first instance is that the TVR as supplied by the terminal is validated by the card ‘s MAC before the terminal contacts the acquirer, and the PIN_entry_mode isn’t.
The PIN_entry_mode may not be present in the ARQC message, though it should be, or it may be wrong for several reasons.
Testing the TVR against the CVR is also only a test of three bits, which should be very cheap and quick to do. It will raise some false positives though
However if the transaction fails both the TVR test and the PIN_entry_mode test then the issuer can be very confident that an attack has occurred.
Steven, the other values for the PIN_entry_mode are:
0-Entry Mode Unknown
1-Terminal has PIN Entry Capability
2-Terminal does NOT have PIN Entry Capability
8 -Terminal has PIN Entry Capability but PIN Pad is down
9- PIN Verified by Terminal Device
I heard you were looking for these.
It might be better to do both tests on all non-PIN transactions, or do the PIN_entry_mode test first – that depends on the false negative rates, which I have no data about, though they should be zero for the TVR test if the CV Rule list is sensible.
@Peter
Thanks for the information on the ISO 8583 Point of service entry mode; yes I was looking for that. Though there is a new twist to the story. Someone from ACI (who make the widely used Base24 authorization software) claims that even if the CVMR makes it to the acquirer, it may not be sent to the issuer. I wonder if the PIN entry mode field suffers from the same problem?
Here in Sweden word has gotten out from representatives of the merchants that our terminals are unaffected because they’re “online unlike in the UK”. This seems fishy at first since the paper makes quite a thing of the attack working against terminals that are online. Also, the paper mentions that the vast majority of your terminals are online as well.
My immediate conclusion is that our terminals are “online” as in “online PIN” in the way you describe ATMs on p. 3 in the paper.
Could this be correct?
If it is, why can’t all merchant’s terminals just do online PIN verfications like the ATMs?
@Stefan,
Yes, it appears the Swedish banks have misunderstood the attack. UK terminals are almost exclusively online, yet the attack still works (all our tests were online). They are also claiming that CDA fixes the problem, but this is incorrect.
It could be that the terminals are doing online-PIN, but it wouldn’t surprise me if the banks are simply confusing this attack with an older one which only works for online authorization (as the French banks did).
To do online PIN verification, the terminal needs to be given cryptographic keys to protect the PIN as it is sent back to the acquirer. This adds complexity and expense, so is not done in the UK.
@ Steven
Indeed, I do think the PIN entry mode field might not always reach the issuer, and also it might not be helpful for attack detection even when it did.
First, afaik UKPA (was APACS) requires that field 22 be included in the message sent to the issuer, but I don’t think all “compatible” systems do. Eg foreign systems may follow ISO8583 but not UKPA standards.
Second, the acquiring bank or terminal may not fill in the field in the message they send when they send the ARQC on to the issuer – the field should exist for all UK inter-bank messages, but it may be empty.
This is especially true of the third subfield – it can be set to zero “Entry mode unknown” by the acquirer or terminal for all transactions, even when the first two subfields, which say what kind of card it is, are filled in.
(to be more exact, the first two subfields of 22 tell how the PAN was entered – 05 for chip, something I’d have to look up for magstripe, something else for manually, and so on)
I’ve heard that this practice of setting subfield 3 to zero definitely happens in some foreign transactions. I don’t know about UK ones.
There are so many standards and they keep changing – and even at best compliance for new systems, the equipment in actual use doesn’t always keep up.
The relevant one today, as I’m sure you know, is Standard 70. Books 1 and 2 (and maybe 4) are what you need, but unfortunately I don’t have book 2.
Also you can still use Standard 60 message formats in (new) Standard 70 systems, and I think that is the most common message format in use today. There are some other older APACS standards still in use too.
There’s another theoretical possibility, but I stress that I don’t know whether it should ever happen – the terminal may report that eg it can accept a PIN and give subfield 3 a value of 1. It’s supposed to change to 9 when a PIN is entered, but it may not do so in time, or an old value may be used by the acquirer.
My point above was that under EMV (remember them?) standards the issuer has to get the TVR, as it’s included in the MAC from the card, and he can’t authenticate the MAC if he hasn’t got it.
He may not get the PIN entry mode field, and it may not be of use even if he does (though again there should be no false negatives, only false positives).
Taken together, testing the TVR, CVMR and PIN entry mode field (when available) against the CVR should give few or no false negatives. and sufficiently few false positives that the issuer can reject transactions without upsetting too many people.
However the banks may not want to upset anybody unnecessarily, and as the attack is not widespread that may be why they aren’t checking every transaction for it.
It simply isn’t economic to test, for now. Testing costs money (though not a lot) and it upsets people – unless their losses from the attack are more than that it doesn’t make sense for them to test.
Or at least that’s how they probably see it. The publicity may have changed their cost model though.
@ Steven,
You say,
“However, this would prevent terminals without PIN pads from working (these do exist)”
Oh dear this sounds like a “user level” protocol failure.
That is If customers are taught that “pin” is the way to authenticate a transaction, then they will expect to type their pin into a keypad….
Thus potentialy a keypad less terminal will alow somebody to put a keypad etc on top of it and record the pin being typed.
When combined with,
“… and prevent merchants from opting to fall-back to signature (which they consider a desirable option).”
Thus the transaction will procead as expected (as the merchants till jocky can say the sig is ok etc).
Thus the pin has been (unknowingly) disclosed by the card holder.
If the person who has put the fake keypad there also gets the data required for the mag stripe then it’s back to the equivalent of ATM facia card reading…
Ho hum.
The important question then becomes,
“Can this reasonably be exploited as an attack”
And if yes how to deal with it…
While I agree that the attack is possible, I disagree with the ipso facto conclusion that EMV is broken.
Yes the attack described can be executed for offline PIN, but we can detect it and then take appropriate action. Here is how-:
The terminal capabilities field (tag 9F33) from the terminal will indicate that the terminal is capable of supporting offline PIN. This attack will not change this field.
The terminal will read the CVM list from the stolen card and see that the card requires offline PIN if the terminal supports it. So the terminal will then prompt the cardholder for PIN. The fraudster will enter any bogus PIN, and the terminal will send the PIN to the card which will be intercepted by the man-in-the middle wedge, which will simply respond to the terminal with a PIN verified response. The real card will never receive the PIN verification request. The next thing the real card will see is the request from the terminal asking to go online for authorisation. I agree that there will be nothing set in the TVR to indicate that anything failed with the PIN.
The card will set the CVR to indicate offline PIN verification was not performed (or not set that offline PIN verification was performed), and because the CVR is included in the ARQC, the attack cannot change this (which is confirmed in the Cambridge University paper).
So we have a conflict – the CVR which is sent to the issuer in the Issuer Application Data (IAD) says no offline PIN occurred, while the terminal capabilities field says offline PIN supported by the terminal. If a card is set up to always require offline PIN to be entered (even if bypass is allowed), and if the terminal supports offline PIN, then this combination of CVR and terminal capabilities is not valid under EMV. I agree with the Cambidge University paper this will not be detected at the terminal, but it could be detected at the issuer host because terminal capabilities and IAD must be sent to the issuer in field 55. If this is an online transaction, then the issuer can decline. If the attack occurs for an offline transaction, then the issuer will detect it after the fact, but can then still take action to stop the card for any subsequent transactions.
While I would agree that today most issuer hosts are not set up to detect this type of attack, it could be done. And thanks to the work of Steven J. Murdoch, Saar Drimer, Ross Anderson, and Mike Bond, banks are at least aware that they may need to stop these sort of attacks, even if they are for the purpose of seeking publicity, rather than for financial gain.
This is extremely interesting and should be fixed, however there is a further simple security application that could be undertaken by Banks in general to protect all credit and debit cards. Simply put the cards are exposed 7/24/365 to fraud ! Allow the customer to book their respective cards into a logical vault (Bank application) when no it use, in other words allow the customer to “block them” …. of course you need to allow recurring payments to take place, but you are now in a position to squeeze the window of fraud availability. With wireless and PC banking this would provide the self serve customer with some piece of mind that its truly locked away and brought back in when needed… will definitely prevent a major amount of Card Not Present fraud …!!!! Why should they be open 7/24/365 especially corporate cards…
I think the paper is good, however I think the title it’s too offensive, which might suggest that EMV is actually broken, which I strongly disagree with. A more appropriate title should have been relating to stolen cards, as it covers only one special niche in this spectrum.
You have found one interesting issue, that involves lack of expressing terminal intent in the transaction, and that is something that EMVCo needs to handle.
Also, the paper could have be more informative, as some parts, (even though it’s correct what you are hinting), a mental understanding of CDA, and why this don’t help the terminal to verify the terminal intention (because of IAD-parsing issues), and why the online mode is still attackable (because of fallback attack of paper signature).
Several banks still haven’t grasped fully why it’s like this, and a more clear description on those parts could be useful.
EMV is complex, and will stay so for long time, as it comes from evolution of a huge number of requirements and legacy support, making up this complexity soap.
cheers
This has certainly generated a huge response, and counter response from the team at Cambridge. There are bound to be some holes in chip and PIN, as there might be in any complex secure system. After much effort, it appears that the team has found one. One has to say, though, that if EMV was really flawed and full of holes, surely they would have found more of them and sooner. Now it’s also true that within the transaction processing world, we know that there are other holes and traps, but we’re not telling. I guess the team, spurred on by their current success will now be redoubling their efforts to find the rest. I think we wish them all the best in their quest to discover the others and to make the Daily Mail before the industry has managed to close them down or fill them in.
But we have to consider …
Had we not implemented the complicated rat’s nest that is EMV, we would still be using magstripe technology with all of its associated nastiness – tell me now if I am wrong! Magstripe cards are very easy to copy, clone, whatever you want to call it. The security of the card-PIN combination was based on the protection of the PIN, and since the only place the PIN was exposed was at an ATM, a compromised PIN was considered to be the responsibility of the cardholder.
Imagine the potential for cloning if all cards were magstripe, covert card readers and miniature video cameras would be everywhere, and the cardholder would be responsible for the lot.
Within the EMV framework, the strength is in the chip and not the PIN, and banks acknowledge this when assessing fraud claims – the cardholder is generally not responsible. I know that some of the banks could do with lessons in customer service (I have been on the receiving end), and possibly a good kicking, but this has little to do with the actual technology.
The banks are also willing to accept this level of risk, they already do so when they issue contactless cards. They also weigh the risk of security against that of usability, and in this respect chip and PIN has done its job (don’t tell me that CNP and Internet fraud are the same the same as EMV transaction fraud, they are not related).
So …
we have an inspired compromise that works for online transactions until the card status is updated as stolen, and that works for offline transactions until the offline counters are exceeded. However, if the issuer systems are up to scratch, they can probably spot the anomaly, which limits the risk to offline transactions until the counters block any further activity.
The key point in this context is that whilst there is a bit of an hole in EMV in this area, it does not imply open season on transaction abuse and it certainly doesn’t prove that EMV is broken. Ultimately, the transaction process is protected and exposure is limited by the bits of EMV that the team haven’t been able to crack.
Now … crack those bits and there is a story worth telling!
My banks have always made it clear to me that until I call to block my missing or stolen card, which I can do 24 hours a day, all losses incurred to my account will be mine.
So I’d say this finding merely reinforces the importance of taking that message seriously.
I take it you do not bank in the UK.
@Chiptester and Lars
In my view many of these comments have a very UK-centric view and assume a common history that is actually not common, but this problem is truly international.
In most European countries the legacy national debit schemes that dominated the cards market for decades (BankAxept, Dankort, PagoBancomat, EC-cash, EC-Direct, Bancontact-MrCash, PIN(!), Bancomat etc etc) have always been online-only and online-PIN-only at both ATM and POS.
France is of course the major exception, but there are some minor ones like Finland.
When PIN was (finally) introduced in the UK a few years ago it was done simultaneously with EMV (hence Chip and PIN) but in all these other countries EMV is only being added to schemes that were already (online) PIN everywhere.
Cardholders in these countries learned to keep PINs secret everywhere and national schemes required PIN privacy shields, the need for which is still not accepted by all.
Online PIN only (which still works fine in most POS terminals in many countries due to this legacy) protects against this problem which was introduced by allowing offline PIN on EMV cards!
I believe the ATM approach of ignoring EMV CVM lists and mandating online PIN is not a bad idea, but my understanding is that future POS will no longer be allowed to only have online PIN by new international card scheme rules. This is a pity, I think.
Our press office has sent us links to coverage which I thought I’d put here for easy reference – the Daily Mail, This is Money, the Sun, the Yorkshire Post, Finance Week, IDG News, the Press Association, the Evening Standard and the Scotsman.
@ Brit Abroad
You raise some good points about the brit-centric approach, but they essentially reflect how banks operate abroad. The base question here is whether or not chip and PIN is broken, and I think the answer is: not really.
If that is the case, the question then becomes: how do the banks deal with these technological pokes in the eye? Perhaps now is the time for some sort of international review, but again, I don’t really think so. None of the card technologies are bleeding enough cash to merit wholesale cardholder fear, from which I deduce that the systems are fit for purpose, possibly with the exception of some of the weak USA implementations, but I suspect they will soon be weeded out. They don’t / can’t work in contactless transit mode so their days are, without doubt, numbered.
As I have already said, we would have been in a much worse state if we still thought magstripe cards were a neat idea. We have moved on, and we have moved on successfully. Don’t let the Prof lead you to believe otherwise.
CNP is the next challenge, just look at the graph on the paper. How about the clever guys in Cambridge come up with a viable and secure means of transacting over the internet, and the rest of us have a go at trying to break it. Now that’s a challenge. But would an unbroken security protocol make the headlines?
@Lars,
thanks for that. One of my colleagues since found a public reference to that bit in the EMV CPA Specs, December 2005, which are online at emvco.
@Peter
Thanks for your comment. We will certainly be revising the paper, and the comments on this blog have been very helpful pointing out where clarification is needed.
In particular, the biggest confusion is the online/offline authorization question, which we did not cover in the paper at length, because pretty much all UK transactions are online. Internationally, this is not the case, so we will discuss this point in more detail.
@ Brit Abroad 81
“When PIN was (finally) introduced in the UK a few years ago it was done simultaneously with EMV (hence Chip and PIN)”
–> Actually not. EMV migration in the UK started in 1999/2000 with UKIS specification, which did not have an offline PIN.
A second migration was done in the following years to introduce the offline PIN.
@Yann
Sorry, you are correct.
I wrote “simultaneously” and I am aware it was not actually done at the same time in the UK. What I really meant was “in connection with”. ie: PIN was only introduced at POS in the UK via EMV cards using (almost exclusively) offline PIN.
This was in contrast to all the other countries mentioned that had PIN already (online PIN on magstripe terminals) and only changed the card and (sometimes) the PIN method when moving to EMV.
As a consumer, I’m inclined to agree with the title of the paper as it stands. Banks provide us with this technology and as a customer I expect them to make sure that any holes in their system are patched up. After all companies such as Microsoft continuously patch their operating systems, so why shouldn’t the same rule apply to banks? As I mentioned before in post 25 it all boils down to costs. A few years back (2004/5) when I worked in a repair facility warehouse these units had to be returned to the manufacturer for repairs. It would cost about £30 to do this, and the the card reading component (the most common fault) itself only cost 20p. On top of this the company would factor in its own charges, so I would guess there wouldn’t be much change out of £100. If you are, say, Tesco as an example, this soon runs up a large bill.
Warning about biometric transactions:
Sooner or later, someone will trust the result of a biometric match-on-card APDU just because the card returns 9000.
Card Term
Term believes that a match on card occurred, but perhaps a man in the middle just returned 9000.
The relevant question is always what happens to the card internally after an external authentication of this sort. Typically it should unlock a key which can be used to authenticate back to the terminal.
@ Yann & Brit abroad
First: EMV was introduces in the UK in two phases. Under the pressure of the retailers which defended that adding PIN Pads would be too expensive, a first issuance of millions of cards was done with no PIN CVM.
Then: Month later, as the issuers “discovered” that EMV without “serious” cardholder authentication (e.g. PIN), had no effect on fraud development, came the second project introducing PIN. APACS, for the occasion and to distinguish both EMV migrations, created for this project an organisation called “Chip and PIN”. Second issuance of millions of cards…
I remember that the main argument from the retail industry on the first failed EMV project was that many cardholders in the UK would have difficulties remembering a 4 digit code… That is industry lobbying! No comment.
UK Chip and PIN project also promoted the concept of “fallback”, but that is an other issue 😉
__
Also, about online options, most “direct debit” countries in Europe, Canada, etc have chosen to leverage their online infrastructure by requiring EMV with online authorisation, but in most cases offline PIN.
Like 88 poster in this contribution, am a consumer and whichever positions posters 19, 37,75, 77 and 78 are willing to have us look at, the sad reality is that they are people like me in real life suffering from the security lapses of this system. i was the claimant in person in this matter.www.which.co.uk/…/judge-rejects-card-fraud-case-against-halifax and while i had to accept the judgement made on this matter, i still very much feel that a miscarriage of justice has occurred in this matter, we will all acept that, denial is highly indicative of the abuse, that the bank and in this caes Halifax has destroyed the primary evidences of the disputed transactions only reinforces in my mind the idea that the system is actually litteraly put broken. None of you i suspect might not feel the impact of the lost of £2100, but for me it has been hell so far and am powerless to get my money back. The secrecy surrounding the number of complaint made by victims of Chip and Pin frauds by Banks, Apacs, FOS and other financial security services only reinforces the view that something is fishy about Chip and Pin. Now suppose the same secrecy was allowed to reign in the plane crashes security issues then you will understand the reality of the matter. most middle class british men don’t have to suffer whay am going through as they will be quickly reimburse in case of similar lost. Ross and its team are certainly doing a great job, the only thing they need is greater support from politicians to impose greater transparency in banking security systems. As for Halifax, it is never finished until the fat lady sings goes the saying.
I found a pile of receipts in a box at home and checked them for TVR’s. Unfortunately I haven’t found any references on the net on how to decode them but since they are 10 digits long I assume they are given in hex to represent the five bytes.
Unsurprisingly, the TVR’s vary between different terminals. Below are some of the results for a MasterCard and a VISA, respectively, on different types of terminals. All purchases were made in Sweden during the past three months.
MasterCard
TVR: 0000000000 (no bits set)
TVR: 0000001000 (transaction selected randomly for online processing)
TVR: 0000008000 (transaction exceeds floor limit)
VISA
TVR: 0000000000 (no bits set)
TVR: 0080001000 (ICC and terminal have different application versions, transaction selected randomly for online processing)
TVR: 0000008000 (transaction exceeds floor limit)
Two questions: (1) Is this the correct way to decode the TVR? (2) Does the lack of “Online PIN entered”-bit set mean that the PIN was verified offline (i.e. only by the card)?
@Stefan
Unlike the CVR, the TVR is specified by EMV. The definition can be found in EMV v4.2, Book 3, Annex C5 (pp 171–173).
I think your decoding of the TVRs is correct, and based on the lack of the “Online PIN entered” flag, it does seem like offline PIN verification was used, assuming that you did enter a PIN. Alternatively, it could be that the terminal did not set the TVR correctly, which we have heard of some terminals doing.
@Ross Anderson.
Wow! A commenter criticises your paper and you blow his anonymity out of the water! Don’t you realise that he will now probably be sacked for criticising your paper? I hope you have a good lawyer at Cambridge University.
@Steven,
“UK terminals are almost exclusively online…”
Does this only mean that the terminals have online capability or does it also mean that most transactions are authorized online whenever possible?
Do you know what percentage of UK transactions that are authorized online? Or where I can get that information?
@Adam
The vast majority of UK transactions are authorized online. The latest figure I have is 90%, which was given by Jemma Smith, a PR representative for the UK Cards Association, on a TV interview a couple of years ago. They may have more up-to-date information if you ask them.
@no 94. Not at all. This is the behaviour that we have come to expect from the City boys – they fight dirty. Fortunately for us they also tend to be too arrogant to think the rest of the world can work out what they are up to.
They have recent form on this: check out http://shar.es/mntBi
Best of luck getting the banks to sort out the problem, Ross et al. You’ll need it.
In response to Alain (post 90) I had £100 removed from my account which I documented elsewhere on this blog back in 2008. I told a police officer that thew machine looked like it had been tampered with, but she went ahead and used it anyway.
If this is the sort of response from the police, then what (as customers) are we supposed to do. As I said elsewhere (if you can find the posts) it makes quite interesting reading. Errors by humans and duff technology combined are a recipe for disaster.
The only thing you can do is use cash and physically go to your bank and use the machines inside and not using any other ATM as the may be cracked, or othe old fashioned way like my mother and sister do. That way, you will pop up on the bank’s security cameras so you have that as evidence.
It made me a lot more vigilant in checking my statement. Those who cloned my card could have easily wiped me out financially, and I believe that I would indeed end up with a situation not dissimilar to Alain’s.
One last thing, why is stuff (such as ATM parts) freely on sale worldwide to ANYONE other than banks?
Can anyone help with this kind fraud?
I have had £250.00 removed from an ATM. The card was with me – 150 miles away.
So HOW does someone, use a card at an ATM and remove money from my account?
The bank says a member of my family must have done it? which is rather interesting as the wife was working at the time) and my baby is only 15months old?
Andy ideas??
@99 – when a bank claims its systems are secure when they aren’t and you lose money as a result, then they have committed an offence under the Fraud Act. But they know from experience that the police won’t be interested, you won’t get the access to their systems to prove it, the Financial Ombudsman Service will find against you and the FSA won’t care.
You can always change banks; look at the Job case and our submission to the Hunt Review of the Financial Ombudsman Service for some hints about which banks to avoid.
Ross – thanks for the advice.
This is so sickening because the so called Fraud Investigation Team in my case really can not be bothered to complete a half decent investigation.
Furthermore, they fail to see the obvious, that is – if I have retained possession of my card and was 150 miles away from the ATM at the time of the transaction, then its obvious to me, that a cloned card was used.
I am now starting to understand this kind “kind of crime” a little better now. I suspect that the fraudsters no longer require the exact PIN if they can alter the chip’s software to be read as another command??
I am a layperson in all the technical gibberish so please accept my laypersons gibberish of the lack of technical know how.
What I do undertand, is that they have managed to create a card, used as a point of sale (or in my case at an ATM) to be misinterpretated as verified by pin, and/or customer not present commands (as I undertsand the middlman theory??) then its not too far from being able to fool an ATM in the same manner?
The end result is that I am £250.00 short from my account and the so called Fraud Investigations department could not even be bothered to seek CCTV footage for that time period.
Though the banks are not a local authority, I feel that they should be subject to RIPA and PACE and should be held to account for their level of service.
Anyone have any more ideas how a Fraud Investigator could do their job a little more thoroughly and offer any further specifics on the cloned card / “any PIN” at an ATM theory?? please let me know.
Regards Andy
The banks just don’t care, as you can’t touch them. There’s a TV program you can still watch on iPlayer for a few days – do have a look.
Andy what is the details of your case please? i am the victim of chip and pin fraud in Job v Halifax and still looking for other victims so that we can present a common front to banks in subsequent disputes until banks acknowledge that chip and Pinch is just anopther scam. tell me if you want my contact details to that effect.
If I comprehend it properly it’s in fact a “signature” buy that is validated by the bank and not a “PIN” purchase. But if the user hasn’t actually put any autograph on document how cans the bank not repayment the currency to the client? In the contract log in the banks backend organization it must show that the purchase was completed with a signature and not with a PIN confirmation.
credit cards
[q] D-Type flip flop [/q]
I thought that most ATM’s use OS2 , not Windows …
Am i now under a misunderstanding??
Steven
You have made an assumption that Banks have implemented EMV ensuring that all security features are implemented. I assume that you expected the Banks to implement simple checks that are available in an EMV transaction flow.
The truth is, as a result just getting EMV implemented, many Banks do not check anything to extra to improve the quality of an Authorisation. ARQC is also not verified. Many Banks would not be able to verify the ARQC or the TC after the event.
I have found many cards that return a TC after the card has failed an External Auth with an Incorrect Field error message. If a card failed to Authenticate the Issuer it should decline the transaction.
The EMV flow has sufficient in it to specify a secure transaction if a proper implementation guide is written for the full transaction flow and processing with sufficient tools being provided to all parties to ensure accurate and correct processing.
Do Chip & Pin cards in the UK generally use offline PIN authentication?
@Khan
At point-of-sale, UK cards always use offline unencrypted PIN verification. UK point-of-sale terminals cannot do online encrypted PIN verification. UK ATMs always do online encrypted PIN verification.
Having just lost £500 to ATM fraud, and experienced insulting “Customer Care” from Citibank UK, I have been fascinated to read all this. The bank simply says “first attempt” debit card withdrawals by thieves in Spain prove PIN disclosure – case closed. So I must still be in a state of self-delusion as I protest the absolute security of my PIN. And why didn’t the thief use my Spanish Visa Electron debitcard for which I had a common PIN?
Is there any similarity with the experience of Job (v Halifax) and Andy?
It is probably time to change my bank!
R.
I have just fallen victim to this.
My card was used last Thursday (7th July) in Selfridges Oxford Street and a Hifi Store on Edgware Road to purchase goods totalling almost £12,000.
At the time they card was in my possession. I used it legitimately in Clapham at 12.10pm in person. The bank will not disclose to me the times of the transactions as this is “now a police investigation”. However they have pretty much accused me of fraud. I attempted to use the card again at 5.11pm when I found it declined.
The fraudsters then attempted to use “the card” again at an ATM at 7.11pm. At that time I was having dinner with a friend in another part of London and had the card with me. In fact he saw it on my person as I took it out of my wallet to comment it had been declined earlier. He is a barrister and quite prepared to testify to this.
Interestingly at 9.02pm the fraudsters called Lloyds to try and get the card re-enabled and passed some basic security questions (name, address, DoB, mother’s maiden name) but failed beyond that. However if Lloyds is to be believed this was either me or someone who had access to my card and then later replaced it.
It will be interesting to see where this ends up. At the moment I am being made to feel like a criminal, since I know the card was in my possession at all times. Surely the bank’s energy would be better spent on closing loop-holes rather than insulting long-standing customers.
Tony
Hi Tony,
The attack we describe above is primarily of use to thieves who wish to use a stolen card without knowing the PIN. The description you give indicates that your card may not have left your possession, and that maybe a cloned card was used, or possibly the relay attack which is described here http://www.lightbluetouchpaper.org/2007/02/06/chip-pin-relay-attacks/
Nonetheless your case is very interesting and the short period of time (only a week that has elapsed) between disputed transaction and you taking steps to investigate could play to your favour.
Feel free to get in touch if I might be of assistance, my mobile number is on my homepage http://www.cl.cam.ac.uk/~mkb23/ and there is useful advice for those involved in card-related banking disputes here http://www.stephenmason.eu/banks-atms-internet-banking/actions-to-consider/ and here http://www.phantomwithdrawals.com
regards,
Mike Bond
(co-author)
Thanks Mike .. I also replied by email.
You are correct. The card never left my person. Of that I am 110% sure. Also, given the nature of the first store (Selfridges in London) I would think it highly unlikely that a relay attack could have been used. The only reasonable answer is a cloned card. However the bank is adamant that their chip and PIN card cannot be cloned. Do you have evidence to the contrary?
Thanks
Tony
Cards can be cloned, and we’ve got the kit in the lab – check out Sergei Skorobogatov’s home page. But that’s tiresome and expensive. Much more likely explanations include an extra card issued by a corrupt insider, a relay attack, magstripe fallback fraud that was misreported as chip-and-pin, or an implementation vulnerability we haven’t documented yet.
As you can see from the comments above and elsewhere, a significant number of people complain of fraudulent transactions against cards that they had in their possession at the time. But the banks just don’t want to know. They’ve got away with lying about security for years; why should they change?
The reason it is taking so long for EMV cards to come to the U.S. is that credit card companies have been willing to tolerate mag-stripe related losses. Switching to EMV would cost U.S. issuers about $3 billion, according to one estimate, and merchants would have to pay not much less to upgrade their point-of-sale equipment.
Now that Visa has made it mandatory for all U.S. processors to support acceptance of chip-based transactions by April, 2013 (http://blog.unibulmerchantservices.com/nfc-ascent-pushes-visa-to-speed-up-adoption-of-smart-credit-cards), the dynamics have changed completely. The banks have no option but to build the infrastructure, so once that’s done, they might as well start using it. After all, if the U.K. chip-and-PIN experience is anything to go by, switching to it would result in hundreds of millions of dollars in savings from lower fraud losses. U.S. banks would certainly take the windfall if it comes their way.
The year 2012 has seen prosecutions of bad people who used the No-PIN attack to steal several hundred thousand Euro. These attacks started before our paper was published, and were known to the UK banking industry. If you go back and study APACS’ statements carefully, you’ll see that they just denied the frauds in question were happening in the UK.
Here is a French news article about this attack being used for real. The crooks put middleperson circuitry in stolen cards, as we described here, and got away with hundreds of thousands. The case is still wending its way through the appeal courts. The prosecution expert report describes the modus operandi in detail, but there is no telling when (if ever) it will be published.
@Eugene
In the Netherlands EMV replaced the mag stripe.
The fear expressed in the article that adopting countries such as USA could make the same mistakes seems to be a reality. Tried our new (first chip & pin from US bank) cards yesterday. Transactions approved without even entering a pin!!! No security at all.
Your attack is rubbish as it can work only is the icc is not configured properly. You show you master the protocol. Good for you. Emvco specs explain better than you. Dont try things people tried 20 years ago
The attack has been fielded in France: http://www.inforisktoday.com/how-criminals-cracked-emv-a-8607
Are there any (accessible) legal textbooks that explain the problems associated with testimonies from banks et al., that rely on unreliable audit trails?
(Cross posted https://www.lightbluetouchpaper.org/2009/04/09/chip-and-pin-on-trial/#comment-1408760)
Stephen Mason writes on this.
Six years on, and most banks still have no fixed the flaw. This article describes some of the excuses the banks are using, such as that zero floor limits “mitigate” the flaw. This is misleading, as none of the transactions done either in No-PIN frauds or in our demonstrations have been authorised offline as far as we’re aware. Online balance checking may reduce the bank’s exposure in theory, but it does not reduce the cardholder’s exposure either in theory or in practice.
Hi Mr Robinson. I have been a victim of a case like this one and I am about to go to court to fight my case, do you happen to know of any jurisprudence, any other case that went to court that could help me with my case? Greatly appreciated