In this case the fault lies with the bank. The chip can authenticate the transaction and also optionally cryptographically sign it as verified. The bank should check the last step but most/some don't because a lot of the first wave of terminals that went out didn't have full/proper implementation, therefore they only relied on the chip saying "yeah it looks good", instead of "yeah it looks good, btw here is my signature on this transaction which you can pass to the bank to verify that it really is kosher".
So it is more an issue of the bank accepting partially verified transactions on large dollar amounts.
The card does sign the transaction, even without the PIN. As I understand it the chip believes that it's a non-PIN transaction, whilst the bank and merchant think it's a PIN transaction and that the PIN had been verified by the card, because the standard apparently didn't have any way to ensure that the chip and everyone else agreed on whether a PIN had been used. It's a really broken protocol.
The best part? In the UK, the cardholder is liable for the transactions because the bank thinks that the PIN was used.
This doesn't cover the issue, because the issuers assert that the customer has not been victim of a fraud - they claim that the customer made the transaction.
You're talking about something different to makomk, but again, not true, you're repeating another urban myth. It's rare for banks to do that, save for a handful of cases. Occasionally they contest it, but generally when they really think the customer is trying to pull a fast one.
If you believe you have a case, talk to the citizens advice bureau, they will help you. Otherwise stop trying to alarm people with a bunch of nonsense.
It is quite simple - the link you provide states that customers are not responsible for fraud, but that does not help if the issuer claims either that the cardholder authorized the transaction or was careless in protecting the PIN (that they can do this is also covered in your link.) If you were to read the link I provided, you would find cases in which issuers denied restitution for fraud on these grounds, even though they could not possibly have evidence that this happened (and there is plenty of circumstantial evidence that it didn’t). The reason they don’t have the evidence is that they chose to open an exploitable hole in their own protocol.
At least at the time of the article, the law allowed the issuers to act as if the protocol was as secure as it was intended to be, instead of how it actually was. If things have changed since then, I would be grateful if you could present evidence that actually shows that to be so.
Instead of being annoyed that I dare mention these inconvenient issues, you should spare your ire for the idiots who created this completely avoidable problem and who tried to brush it under the rug.
Edit: It is telling that the issuers didn't take this seriously until a case involving unissued cards arose - a case that cannot be blamed on the customer.
I think it comes down to unreliable communications... In the case that your POS terminal isn't able to connect upstream, do you completely decline the transaction? Businesses used to accept checks from most people without issue.. these transactions took several days.. yes there was some fraud, but it was minimal.
In this case it may be part of the protocol to not confirm if there is a communication problem, and that risk may be acceptable. It seems to me a test of is "0000" valid and is "9999" valid and at least one of the two rejected before the user is allowed to enter their pin would be reasonable here.
There's a lot to be said for user in/convenience in decision making.
Well... in principle the device is supposed to be able to provide an authenticated public key that gets signed by some upstream bank/authority, right? It's the same principle as TLS -- you can trust the site because they have a signed cert.
And this part apparently was unbroken, because the attackers left the initial chip in place and just proxied the PIN response.
So... if you have that, why on earth didn't the protocol specify a two-way kind of thing that allows the already-authenticated card device to sign and return a "I validated that PIN" message, which wouldn't be MitMable?
I'm just stunned that somehow they went through the trouble of putting a !@#!?! computer into every credit card capable of elaborate crypto and then blew this really obvious hole in the middle of it...
Offline authentication was included for reasons you state but banks and terminals are supposed to limit it to small transactions, i.e buying a cup of coffee. For larger ones you wait and retry for online transaction before you let the customer walk out with that shiny new 2K MBP.
The uncoverers of the original exploit made that point in their paper: the primary goal of the industry is not fraud reduction but liability shift (from them, on to the customers and/or merchants.)
The term "liability shift" was not invented by the paper's authors; it is the industry's own term. Here we can read MasterCard’s Carolyn Balfany openly using it:
In a way it is isn't though ;-) They are insured against it, they will refund the money back and their risk analysis probably indicates that loosing all that money to fraud is cheaper than waiting and properly deploying and testing the solution.
I imagine just like in the government security world, a lot of bank security is "paper" security (the way I call it). It is a set of formalities, certifications, rubber stamps, audits, other other red tape that in the end all check off and yet the system is still not secure.
> They are insured against it, they will refund the money back and their risk analysis probably indicates that loosing all that money to fraud is cheaper than waiting and properly deploying and testing the solution.
This. Some behaviour i encountered by acquiring banks when working on backend software for interfacing with them:
- Authorising a transaction when they failed to contact the issuing bank, because the value of the transaction is lower than a certain threshold.
- Overloading fields in the APACS spec to get around 3D Secure / Verified By Visa, i.e. passing the cardholder straight through the process and then marking it as bypassed (a poorly implemented one factor auth becomes a "eh, this looks ok to me" zero factor auth by the issuing bank).
- Being sat in meetings where the max value of contactless transactions was explicitly stated as being that of a level that any contactless chargebacks were not defended because they're so low.
- Asking me to send PANs in clear text, split over two e-mails (no, i didn't).
Backend backing systems are horrible. Nobody really wants to work on them and they have so much legacy cruft that they're like concrete, so any change takes forever and carries massive amounts of dev/test/risk.
Even the seemingly sensible ones have major WTF's - One of the integrations i did at my previous job was interfacing to Amex's endpoint for online authorisations. HTTPS posts over the web, seems sensible enough right compared to APACS-70 over X.25? No, the ISO-8859-1 POST parameter values needed to be encoded as EBCDIC and then converted to hex (IIRC) before being sent.
Banks playing the chargeback cost balancing game is all well and good for them, but if you're living on the edge and experience fraud then this can lead to all sorts of financial problems.
Having had to re-implement a few legacy systems in newer code for nothing nearly as complex or with as much risk as what you're referring to, I can't imagine any dev not screaming and running for the hills if asked to do this. The chance it will work correctly without bugs early on is close to nil, and the downside for bugs when dealing with financial systems makes the risk analysis being as large as it is, it's pretty clear cut.
I keep telling myself one of these days I'll get to reimplement some system that has good test cases, but I know that will never happen. Any system that is designed well enough to have good tests doesn't really require rewrites in the vast majority of cases.
Sorry. I'm not sure I understand your comment. Are you saying it is the bank's fault or it isn't?
EDIT: Thanks kbenson for clarification.
The banks did lobby hard to be able to shift the liability to customer when PIN is used so do they do care less and do care more about approved xactions/second than anything else.
So it is more an issue of the bank accepting partially verified transactions on large dollar amounts.