🍨 🤷🏼 🚚 Offline transactions in public transport - security and antifraud 👨🏻‍🎤 👈🏼 🎉

And not a day has passed, as I am writing a new article, which is also related to NFC technology. Namely - offline transactions in public transport, why and what are the pros and cons for passengers and carriers it carries. About five years ago, several scandals related to the hacking of Troika cards in Moscow made a noise. Then the hackers needed to get the keys to access the contents of Mifare 1K cards and the like, as well as quite specific software for working with them. At the same time, the probability of being detected was quite high - cards with inconsistencies in the content and the Troika server were quickly sent to the stop list, and when trying to go through such a card, the turnstile emitted a piercing scream, attracting attention. What changed when the terminals began to support bank cards?

This is exactly the picture when paying for fare can be observed in some large cities. New terminals can work both with old Mifare cards and with contactless EMV cards. Is it necessary to say that despite the scandals that have erupted, the vulnerabilities of old Mifare have not gone away? But in this article, we’ll talk about the vulnerabilities that EMV support brings.

Warning for outcasts, crooks and hackers of all stripes:

Described below is purely informative and informative in nature. I understand that for some subjective reasons this warning will not stop some readers, but still remember - there are articles of the Criminal Code of the Russian Federation No. 159 and No. 272!

Bit of theory

EMV (Europay Mastercard Visa) - a standard that describes the behavior of a payment card chip in various scenarios to ensure the highest possible security of payments. You can read more about this here in a respected postAlexgre. We are only interested in the fact that in some cases the protocol allows offline transactions, that is, the operation that the card and terminal conducts exclusively between themselves, and transaction information is transmitted to the acquirer bank later. The advantage of this approach is undoubtedly that this solution is ideal for conditions where there is no connection, or the connection is unstable - like the same bus, for example. The minus follows from the name - the terminal cannot check the availability of funds on the card, as well as the status of the card itself. The bank will only be able to confirm or deny write-offs for a specific transaction during synchronization. What happens if you show the conductor a blank or blocked card? But nothing will happen.Using basic APDU commands, the terminal will ask the card for its expiration date and compare it with the system time - if it has not expired, then it will ask the card for its PAN - this is the same card number stamped on it. Having saved this data, further at the discretion of TRM (Terminal Risk Management, Terminal Risk Management), the terminal will transfer a random number to the card, it hashes it and signs it with its key, the terminal saves the original number and the card's response so that it can later be transferred to the bank. After performing these operations, the terminal sends a command to end the connection to the card and terminates the connection by printing a check ticket. Later, the terminal will not be able to write off money from this card - the PAN card is sent to the stop list - until they pay off the debt, they will not accept this card in any bus. An ideal system, isn't it? It would seem that there are vulnerabilities,no freebies all pay for everything in the end. Everything would have remained the same, if not for one big "But" ... Or a few.

Apple/Samsung/Google Pay —

And on September 9, 2014, Apple introduced a new contactless payment method over existing infrastructure. Apple Pay has been focused on simplicity, speed and privacy. Simplicity was provided (and provides) by Wallet's intuitive interface, and privacy is ensured by tokenization. When adding a card to Wallet, a payment system (such as Mastercard or Visa) generates a token. The token is a PAN - but not the one that is knocked out on the card being added, but its equivalent in the payment system. From now on, POS terminal requests for this virtual PAN will be considered by the payment system as if it were a physical card number. With this approach, even a potentially compromised terminal does not see the real card number - the token can only be used for payments on POS terminals, in other cases it is useless.Later, Samsung Pay and Google Pay (formerly Android Pay) began to work on the same principle.

Tokens in offline transactions

Yes. A contactless device here is tantamount to a physical card. And in case of a payment error, the terminal on the bus will pedantically put the PAN in the stop list. Justice has triumphed! Only ... PAN is ephemeral! Each time you add a card to a mobile device, the token will be different. Accordingly - we add the card to the device - and we got out of the stop list without paying a dime. Repeat if necessary. Thus, to reproduce this attack, any device capable of making contactless payment is suitable. That is 90 percent of all phones with NFC.

How to fight?

Offline - no way. Absolutely. There is no way to determine whether a token belongs to any account. Therefore, we need terminals that can go offline only when necessary, and stay online for as long as possible. I understand that the sum of risks is small, but the vulnerability is so easy to operate that everyone can take advantage. You can fix the situation - there are specialized validators for public transport.

Type of such.

, . .

What are the findings?

Hasty innovations will not always be safe and reliable. As with the transport system, the old vulnerabilities have not yet been fixed, but they have already brought in new, easily exploited ones. And crutches are bad. I hope that my little research will help some transport companies rethink their priorities.