Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

Some of the answers are close, but no cigar. The main reason for the time delay is the offline authentication of the chip, combined with generation of the ARQC cryptogram. Additionally the EMV protocol is very chatty if there are multiple applications on the chip card, although the latency involved in the customer interaction far outweighs the protocol timings.

As mentioned in many comments online transactions will be an order of magnitude slower, as they need to be sent to the issuer, have their cryptogram verified and the challenge response returned if the card does host authentication - which most do these days.

The entry mode generally does not determine how a transaction is authorised - chip, PayPass (NFC) and stripe can either be off or online. In fact stripe transactions are invariably online unless you want your business to be overrun with fraudsters. One of the prime reasons in the early days of EMV was to have it so safe that offline transactions were fraud proof - or close to. Naturally this noble goal was shot full of holes the moment real fraudsters got to it. However, the card is personalised with various limits and counters and with the possibility of using an offline PIN, which combined with the static authentication does give reasonable protection for low value offline transactions. Fun fact - in the initial spec this offline PIN was communicated between the terminal and the card in the clear. What could possibly go wrong :-). These days it is encrypted.

Anyhow enough blather - hopefully this has given a bit of insight.



What I don't understand is that even when using a German card with multiple applications, online authentication, and online authorisation[0] it's quite fast in Germany – much faster than comparable or even simpler transactions in the US. On the other hand, the very same card is processed even faster when used in Sweden.

The difference is probably faster data connections and more efficient protocol implementations, I would think.

[0]: For some reason receipts here contain quite a lot of information on what happens behind the scenes if you know how to read it. I hope this link keeps working, it contains exercepts of receipts merchants give you here: http://docplayer.org/storage/33/16568026/1498495227/GbAKHYXN... With that information you can e.g. see which steps were perfomed offline.


Does Germany have exactly one financial interchange network?

Living in Canada, I tend to notice a wide variability in the response times of ATMs to withdrawal requests (i.e. the time between when you finalize the transaction request, and when it spins up the bill spitter) and I think the one factor I've noticed it coming down to is the number of interchange networks marked as being supported on the side of the machine.

The ones that just do Interac (the Canadian interbank debit-transaction network) are quite quick; the ones that do Interac and PLUS or Cirrus are slower; the ones that add support for cash advances on plain credit cards by supporting individual CC companies (Visa, AMEX) are slowest of all.

So, maybe it's not the number of applications on the card, per se, but rather the number of applications supported by the terminal, with some sort of O(N^2) interaction between them?


The POS terminals I talk about usually support at least MasterCard, Visa, Maestro, Vpay, and the German scheme Girocard (which in reality are multiple networks in its own). Some even more and they are still much faster than either using the same card in the US or using a US-issued card in the US. I'm honestly quite baffled as to why. I haven't tried a US card in a German terminal yet and neither looked closely at ATM speeds.


Your link gives a 403, could you re-upload it somewhere else?


I made a screenshot of the most interesting example: http://imgur.com/ye5MJcH This is what they print out for the international schemes. On the left is what the customer gets (sometimes directly on the receipt, sometimes on an extra piece of paper), the right one is for the merchant (some only save it electronically now). Some terminals show less info but much of it is almost always present, something which I haven't seen much internationally in that level of detail.


You can decipher some of the fields printed on the receipt using https://tvr-decoder.appspot.com. The acronyms are from the EMV specs (https://www.emvco.com/specifications.aspx?id=223, probably book 3)

Eg. TVR: 0000008000 (Byte 4 Bit 8) Transaction exceeds floor limit

Floor limit being the $/EUR/whatever amount that could be approved offline.

The 2 in the diagram appears to be pointing at a cleartext credit card number.


Why are some retailers so much faster than others? At Walgreens, for example, I get to "remove card" in around 1/3rd the time it takes at Safeway.

Have they decided to accept the risk of offline processing to speed up their checkout process?


What is the difference in the actual reader hardware itself ?

That is, what brand of terminal does walgreens use vs. safeway ?

In this late year of 2017 I know that many new NAS devices use cheap processors that make it difficult for them to run rsync over ssh ... it's too computationally expensive to encrypt the data stream at a high network speed.

If NAS vendors make that decision I wouldn't be surprised if some payment terminal vendors make similar decisions ...


> Fun fact - in the initial spec this offline PIN was communicated between the terminal and the card in the clear. What could possibly go wrong :-). These days it is encrypted.

How do you encrypt a 4 digit number (PIN) in a way that is resistant to brute force recovery?


You set up an secure session (e.g. TLS, but you wouldn't do it that way) and send the 4 digit number over it. Or you use any standard cryptosystem with appropriate security guarantees (RSA-OAEP, AES-GCM, you name it).

What you don't do is shove the 4 digit number straight into an ECB mode cipher.


Diffie–Hellman key exchange?

Oh gosh, this feels just like my crypto finals :(


You don't. The card has a CPU on it that's the only thing that has access to the key and just refuses to authenticate any more after a few attempts.

At least that's how I'd do it.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: