> Huh? If you have worked on this stuff, surely DDA and CDA ring a bell? They're both based on asymmetric cryptography, and they absolutely allow the terminal to dynamically verify whether a given card is authentic or cloned, without having to go online.

Yes I was a little wrong here. My most recent experience in this area is dealing with messages on the issuer side. It’s been a while since I’ve done anything serious at the card config level, and don’t have a huge amount of experience with the handshakes that occur between card and terminal.

The missing nuance is that the transaction cryptogram is symmetrical encrypted, and that’s the only cryptographic blob sent over the card network to the issuer. As the asymmetric stuff only happens locally between card and terminal, and isn’t included in any data transmitted from terminal to issuer.

So the terminal can check that the card is a real card using asymmetric encryption, and that the produced transaction cryptogram was produced by that card. But none of that evidence is passed on to the issuer, only the symmetric cryptogram, which can’t be used for non-repudiation is sent to the issuer later.

Hence the experience dealing with forged transaction cryptograms, which were forged by an acquirer in a systematic manner to try and gain stronger chargeback protection because their sloppy transaction processing resulted in them processing a lot of fraudulent transactions, and then being hit with a lot of chargebacks. The process of “proving” to the network that this acquirer was forging cryptograms was sending a letter signed by legal team attesting to fact we had evidence of forgery, plus a much nastier letter sent to the acquirer in question to knock it off, and stop doing obviously illegal things. Ultimately it’s the acquirers legal counsel that acts as the enforcement mechanism here, and the obvious threat of lawsuit they’re clearly can’t win tends to be a very strong motivator for companies to tidy up their act.

> EMV is a cryptographically sound (if dated and very complex) scheme, and secrecy of implementation is actually much less of a security factor than you seem to claim, despite the industry's (largely historical) obsession with secrecy.

I may have overstated it a little. Bad habits from spending too much time dealing with PCI rubbish. The difficult thing to get across in these threads about payment networks is how much of the systems “security” really comes from clever legal contracts, and smart distribution of liability and risk. Effectively making in everyone’s interests to not do anything really silly, but the actual technical security is almost secondary to legal mechanisms that exist to ensure that participants are highly motivated to make sure that fraudulent transactions are kept to a minimum.

Ah, so you're talking about the edge case where the terminal claims to have, but did not actually, perform ODA? Yes, that's somewhat of a gap in the EMV protocol. As I've mentioned in my other comment, I could see CDA eventually becoming mandatory, as well as keeping the entire CDA output terminal-side. That trace does provide non-repudiation.

There are other ways too to stop "sloppy terminal processing", but as far as I understand they're not cryptographically secure in a way that would provide an unambiguous and third-party verifiable protocol trace.

I suspect that all of that is a big reason why the networks don't love offline processing if it can be avoided.

And I couldn't agree more to your last paragraph – the industry does have an unfortunate history of propping up questionable security engineering with legal threats. But I'm slightly more optimistic on EMV, at least some implementations: Decades later, we can actually have some nice things :)

Also, thanks for the anecdote! Helped me confirm a theory I had on the motivation for a particular obscure protocol feature that I have so far not found solidly explained anywhere in the literature.

> Ah, so you're talking about the edge case where the terminal claims to have, but did not actually, perform ODA? Yes, that's somewhat of a gap in the EMV protocol. As I've mentioned in my other comment, I could see CDA eventually becoming mandatory, as well as keeping the entire CDA output terminal-side. That trace does provide non-repudiation.

No, not even that. Remember that transaction settlement is based only on what’s actually sent over the network. All kinds of stuff can happen between the terminal and card, but if that info isn’t actually sent over the network, it may as well not exist (from a settlement perspective).

So we have no reason to believe that CDA wasn’t performed. Instead we had a network participant effectively mutating presentment messages so they no longer matched the cryptogram produced by the card. We already knew the presentment were mutated because they indicated our card were approving transactions offline that they were configure not to approve. But during the dispute process, we had the acquirer claim that they had valid cryptograms, so we had no right to chargeback. In turn we actually had to go and start decryption cryptograms, and as we expected, the decrypted cryptograms didn’t match the transactions they had been sent with. The transaction amounts didn’t match up.

The sloppy processing was a little more complicated, and was a bit more complex than just badly configured terminals. The types of transactions in question where fairly complex multi-step transactions, that to process correctly required properly supporting some of the slightly more niche network features by both issuers and acquirers. Due to a lack of proper support by many issuer (although we had proper support), the acquirer took some shortcuts to reduce customer complaints, but drastically increasing their own risk exposure. Unfortunately for them an OCG had figured out they could exploit this nuance.

I doubt the OCG had any understanding of the underlying transaction mechanisms. They had just figured out if they followed a specific set of steps, they got free money (or something trivially easy to covert into money).

But to deal with the losses the acquirer was seeing. Some bright spark over there decided they would start forging network messages to try and cover their losses, and shift them onto us. Unfortunately for them, we were more technically competent than most issuers, and more importantly, really couldn’t afford to take the losses.

> I suspect that all of that is a big reason why the networks don't love offline processing if it can be avoided.

Nah the networks don’t care. They get paid regardless, and they’re never on the hook for any losses that might appear. But certainly offline transactions carry a lot of additional risks for issuers (notably it’s impossible to ensure funds will exist to cover any offline payments that might have happened), which are easily mitigated by simply configuring your cards to always go online, and thus shifting the liability on to the merchant if stuff goes wrong.

> And I couldn't agree more to your last paragraph – the industry does have an unfortunate history of propping up questionable security engineering with legal threats. But I'm slightly more optimistic on EMV, at least some implementations: Decades later, we can actually have some nice things :)

Eh, ultimately everything in this world boils down to who has the larger capacity for violence, regardless of what may be correct. Thankfully in most countries we’ve replaced violence with government, police and courts. So now it’s more a question of who has the larger capacity to hire lawyers.

Even if the technical layer supported non-repudiation, I doubt it would make much difference in a court of law. It’s extra evidence for sure, but ultimately most of these things are resolved via settlement based on what makes the most financial sense for the parties involved, which includes many more factors than just the state of the transactions are the heart of such a dispute.