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