> However there has been a bit of shift towards online transactions

Not just a bit of a shift: Offline-preferred transactions are basically a thing of the past. EU rules have nothing to do with it (offline EMV is fully SCA compliant as well, as the chip can keep count, although it's a bit annoying to keep counters in sync if there's more than one); it's mostly for risk management and simplification reasons, I believe.

> The terminal has the transaction cryptographically signed using symmetric encryption with a private key

Offline transactions essentially always require card authentication as well, which requires asymmetric cryptography. (Otherwise, you could trivially forge valid-looking cards and offline terminals would be none the wise since they obviously don't hold the symmetric keys for every card issued; that would be way too risky).

> EU rules have nothing to do with it (offline EMV is fully SCA compliant as well, as the chip can keep count, although it's a bit annoying to keep counters in sync if there's more than one);

EU rules have everything to do with it. Meeting EMV with offline counters is tricky to get right. The reason I can confidently claim the SCA drove the migration of online transactions is because I was responsible for the technical implementation of SCA for a bank, and was part of the industry wide conversations that happened as banks figured out who they would comply with the rules, and tried to figure out what wiggle room existed. So I know SCA was a driver, because I talked to the people making this decisions.

> which requires asymmetric cryptography. (Otherwise, you could trivially forge valid-looking cards and offline terminals would be none the wise since they obviously don't hold the symmetric keys for every card issued; that would be way too risky).

This is where you are simply wrong. Again speaking as someone with actual experience working on this stuff, and having dealt with actual forged offline transactions as well. I can tell you the card uses symmetric encryption, the terminals themselves have zero ability to validate the signature a card produces. The terminals include some data that allows them to validate if a card number is routable, and also a hot list of card numbers to always reject, and thus reject transactions that can never be fulfilled, but they have no way of validating that a specific card or transaction hasn’t been forged.

The entire system depends on the physical security of the chips in cards to make key extraction extremely hard, and to also make the correct mimicking of cards extremely hard. But it’s hardly impossible, and there’s plenty of demonstrated EMV attacks out there in the wild. It’s just that they all hard to replicate, require special equipment, and generally make you look very dodge in the moment because you have to have a weird card with wires running your shelves so you can intercept the card comms. The manufacturer and distribution of the chips in cards is extremely tightly controlled, so you can’t just buy them. In theory anyone with a million dollars and ASIC contract could manufacture their own ICs, but there simply easier ways to steal money.

Ultimately EMV only needs provide enough security to make other methods of stealing more palatable. Cards are used for pretty low value transactions, so breaking EMV isn’t a very scalable way to steal money. You would be better off stealing products from merchants using decent pair of running shoes, rather than creating crazy ways to trick their payment terminals. Running shoes are cheaper and much more accessible than ASIC production.

> The reason I can confidently claim the SCA drove the migration of online transactions is because I was responsible for the technical implementation of SCA for a bank

Ok, "nothing to do with it" was too strong: I don't doubt that SCA was the death knell for many offline implementations. However, I've seen online-only cards in the field by many banks well before SCA became effective.

And on the other hand, I also know SCA-compliant EMV implementations that do still support offline transactions. As you say it's tricky, but it's possible. Europe is large, and you probably haven't talked to every single bank/processor :)

> This is where you are simply wrong. Again speaking as someone with actual experience working on this stuff, [...] they have no way of validating that a specific card or transaction hasn’t been forged.

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.

Without that, you could indeed copy the static signature data from any EMV card and replay it to an offline terminal and get away with it. That's why SDA has long been deprecated for offline transactions.

> The manufacturer and distribution of the chips in cards is extremely tightly controlled, so you can’t just buy them. [...] In theory anyone with a million dollars and ASIC contract could manufacture their own ICs

You can absolutely get them on Aliexpress straight from the manufacturer for a few bucks each, cheaper in bulk. They run Java, so you can just write your own software – the EMV specs are public!

What you can't get there is the cryptographic private key specific to the card number that the issuing bank embeds into it at personalization time.

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.

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

I used to have an online maestro card (was solo and now known as debit mastercard) and an offline card (was switch, now also known as debit mastercard) from a UK bank, due to having two current accounts there.

The offline card was from a current account with an overdraft and also worked as a cheque guarantee card, for cheques up to £250 under the (discontinued ~2011) cheque guarantee scheme[0] and had a special hologram on the back. The retailer would watch you sign the cheque and write details about you, the card and any CCTV etc. on the back of the cheque. I imagine the offline behavior of the card was similar, and was a carry over from that.

The online card was from a basic account with no overdraft facility and acted a bit like a prepaid debit card.

[0] https://en.wikipedia.org/wiki/Cheque_guarantee_card

The tech is fundamentally fine - where the problem arises is human behaviour.

When offline contactless payments first emerged in the U.K., there was a significant spike in unplanned overdraft usage and disputed transactions, as people rapidly realised it essentially worked as a free line of credit, up to £100 or £250 depending on your issuer.

This quite quickly caused issuers to push up prices on offline transactions, which made them less appealing to merchants - add to that that people were talking about them being a hotbed of fraud, and merchants err away from offering them, PCNs start dropping the capability due to lack of demand, and here we are today.