Hacker News Reader

Comment by ajross | Hacker News Reader

FTA: A fraudulent chip can listen for that query and pre-empt the real chip with its own answer: a “yes” signal regardless of whatever random PIN the fraudster has entered. “The attacker intercepts the PIN query and replies that it’s correct, whatever the code is,”

Wait, what? How is that the protocol? There's no two way validation at all? The chip just says "yes"?!

Can anyone with knowledge of details confirm? This seems isomorphic to my ears with "the PIN is just security theater".

View on HN

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.

That's an urban myth.

http://www.theukcardsassociation.org.uk/faqs/

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.

https://www.cl.cam.ac.uk/research/security/banking/nopin/oak...

(my comment edited for clarity)

Why doesn't it address the issue?

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.

> Why doesn't it address the issue?

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.

I'm not disagreeing.. was only stating a reason why they might bypass the check.

Really? Its like the banks saying "really all this fraud stuff isn't really our problem."

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

https://www.cl.cam.ac.uk/research/security/banking/nopin/oak...

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:

http://blogs.wsj.com/corporate-intelligence/2014/02/06/octob...

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.

> http://www.npr.org/sections/money/2014/09/08/345820789/why-d...

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.

Which EBCDIC CCSID?

At least you knew which encoding to use. For one of our payment integrations we've given up, and just pass it 7-bit ASCII.

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.

He's saying it's like the banks threw up their hands and said "screw it", because that's how horrendously bad the security ended up being.

    > The chip just says "yes"?!

Yes.

From https://www.cl.cam.ac.uk/research/security/banking/nopin/oak... page 446 (last page), T: Terminal, M: "Man in the Middle":

    T → M 00 20 00 80
          08 24 00 00
          ff ff ff ff ff   Verify PIN “0000”
    M → T 90 00            PIN correct

There's nothing wrong with the smart card system and the crypto protocols developed around them. The problem is that the applications that have been bodged onto the smart card since it was invented (in the 70s) have all been garbage. The banks and payment networks just aren't qualified to implement these things, and they don't have any reason to because they've managed to externalize the cost of fraud onto the individual customers and the merchants.

Sorry, but in this case we have a POS terminal accepting a fraudulent PIN because the card device, which could have cryptographically signed that validation, did not because the protocol didn't require it.

That's a fundamentally broken protocol. The hardware capability was there to do this securely, the software design messed up.

Unless what you're saying is that the PIN itself is an "application", in which case your point seems sorta specious. OK, so the application has a broken protocol which invalidates the whole idea of "Chip & PIN" authentication.

I think we agree. This is a broken application, built upon a sound technology. The card is perfectly capable of signing the transaction, and will only do so if the correct PIN is entered (smart cards can also be programmed to disable themselves after a number of incorrect PIN attempts). However the banks either don't know how to, or do not want to, run a public-key cryptosystem, so they don't ask the card to sign.

Their "fix" is also similarly insane:

> According to their paper, at least some chip-and-PIN card readers now send a command to verify a PIN before the user even enters it to check if the card responds with a spoofed “verified” signal.

Trivial to detect and control, e.g. have a discrete button on the card that you press exactly when you enter your pin that enables the spoofed response. There are probably more sophisticated methods.

Hopefully they've done more than just that though. Hopefully.

Why not just have it reply with a "verified" signal when you enter a predefined PIN? That way you're mimicking the card's original behavior with a different PIN code.

Even worse, the person entering the pin knows what they are going to type in. Your backpack chip doesn't need to accept every pin.

I don't like their hack, but the card reader could issue multiple attempts at the password verification in succession, with only one of them randomly being the one typed in.

Not a bad idea, except there's a limit on the number of attempts. Otherwise you could easily brute force the PIN.

On the bright side, this only affects offline PIN verification. Cards which are configured to require online PIN verification should be more secure. They will send a (triple DES encrypted) PIN block to the terminal, which sends it to the issuer, which decrypts and verifies it.

Yes. Most new-ish deployments of chip-and-PIN using online PIN verification, such as Germany, Switzerland, Australia, and the U.S.

Isn't the US chip-and-signature?

It's complicated. U.S. EMV credit is (virtually) all chip and signature. Debit is split between PIN and signature. US Debit Common AID is Online PIN, but you can legally do PIN bypass ("no cvm") or even fall back (or have user select) the card brand's application on the card (instead of the US Debit Common AID), in which case for Visa it will be signature and for Mastercard it will be online PIN. Politics and posturing.

We are heading there, but very slowly.

I've only ever seen one merchant (Target) that requires the chip. Every other store is still using the mag stripe. In fact, while travelling this weekend, I used my card in a dozen new stores. But none used the chip.

in my experience, Walgreens, Home Depot and Walmart all require the chip when it is present now. At least with AMEX cards.

This the only implementation I've encountered in real-life, so far.

I have a few chip and pin cards and one chip and signature.

This is a good overview by some researchers in the different ways Chip and Pin can be hacked.

This explains this hack as well.

https://m.youtube.com/watch?v=Ks0SOn8hjG8

I share your amazement. That said, apparently the functional security was "how could you put a system physically between the card and the reader?" which seems silly. The chip is capable of signing the response with the secret key of the card, why wouldn't it do that?

It's fucking ridiculous, especially since this was already commonplace with mobile phone SIM cards when they said it, but it allowed UK banks to force their customers to accept potentially-fraudulent payments by claiming that their PIN must have been used. (Otherwise they'd have had to eat the loss and no bank wants to do that.)

Here's a good write-up of SDA (very vulnerable to the yes-card) and DDA (not vulnerable to the yes-card if authenticated online, but still vulnerable if authenticated offline due to a bad protocol):

https://www.lightbluetouchpaper.org/2009/08/25/defending-aga...

I believe there is either Online or Offline PIN verification.

http://www.smartcardalliance.org/publications-emv-faq/#q14

When I use my chip card, I don't need to enter a PIN when I select credit... and all debit cards usually can also be used as a credit card...

Reply on news.ycombinator.com