mifare classic 1k for micropayments

Question

Can Mifare Classic 1k be used for micro payments in a secure way?

I have a system in mind for use in a arcade game saloon. You are getting a card from cashier and can top it up for example with 100 points (they are written on the card not in database and only using ID). Then you can go to each machine, scan the card on the reader and your points will get decreased, and points left will be displayed on the lcd.

So each time you are scanning the card it writes new data and check its integrity.

Is this possible to be fully bullet proof, and cannot be copied over some custom hardware?

I'll create hardware to accept payments on the arcade games, and software/hardware for top-up operations.

I was thinking about a solution where I'll save a hash (with some secret seed) of unique id of the card, and current points amount and save it within the eeprom of the card (with points amount of course). I can wrap it up within a AES or 3DES block for extra security. I'll store the keys and hashing within the hardware so it will be pretty secure.

My concerns are:

1. What if somebody will take the card during write operation?
2. Will somebody be able to copy the card to some kind of emulator with its unique identifier and eeprom content?
3. Maybe there is another routine to use, better then "read, write, check" and turn on the game?
4. I red that Mifare DesFire standard is for micropayments solutions, but cards are more expensive, hardware probably also. However maybe somebody have some experience and its not as scary as it looks?
5. Anybody have any hardware recommendations for Mifare of course.

Much appreciate any input.

Answer 1

Mifare classic can be completely cloned. You can buy cards with changeable UID as well - I just ordered a bunch. The blocks of the card which require non-default keys can be cracked on a PC using cheap hardware. E.g.: Proxmark or Adafruit PN532 / Elechouse PN532 V3, using libnfc and a few other programs. All the tools needed come stock in Kali linux.

I haven't had any luck accessing these blocks which require non-default keys yet, but only because I have not applied serious effort. Desfire EV1 (IIRC) is a post-2008 revision, and these cards are considered secure and are uncloneable p.t.. If you know this to be incorrect, please provide links.

A lot of places use Mifare classic tags for access control and such - more power to that - but I would not use anything less than at least Desfire from NXP (no china knock-offs) for anything involving money.

Google 'mifare classic cloning'.

From reading various sources I estimate it will take max 25-30 minutes to read all data from these cards. For cards which use default keys, it takes less than a second. The Adafruit PN532 (it has a decent antenna) can do it from a distance of 7cm - this range can be increased with custom antennas. Desfire can be read from 3-4 cm. Seems that the more power the card requires to process and communicate, the lower the range of a scanner. Trivia: A single layer of alufoil prevents this... no need for a 'steel wallet'. Just duct tape it over a standard creditcard holder and store that in your wallet.

Edit: any supplementary info from pentesters and engineers would be useful for OP. Please correct any misunderstandings I may have about NFC ;)

Answer 2

You could use such a scheme. There are a few things to take care of, however.

Storing in the card the amount, along with, a hash of card UID + amount prevents copying the amount from a card to another.

It does not prevent, however, a user from reading the card data, using the card in the game (thus decrementing the amount), and later rewriting the previous card data to restore his initial amount. To prevent this, you have to ensure only the authorized terminals (gaming machines) are able to write in the card.

Mifare will solve this problem by allowing you to load custom keys in the card, which will protect the sectors from reading and/or writing. These keys will have to be known by the machine.

Now to prevent card emulation/cloning, if you load custom keys in the card, you solve this problem as well. The terminal will have to authenticate with your custom keys before the transaction, so you make sure the card is genuine. Note that, at this point, you don't even have to store a hash of amount+UID in the card to guarantee the amount is not transfered to another card, because only your machines (that you trust) can read/write to genuine cards.

So you're mostly fine, provided you appropriately set the keys and access bits of the mifare sectors. You'll have to secure your gaming machines hardware, as well, because a hacker having access to such a machine may find out how to change the amount stored in the cards.

Now as to your detailed questions:

1. If the card is withdrawn during the write, Mifare classic doesn't give you any guarantee. This means the sector can end up corrupted. To prevent this, you could write your data on multiple sectors, and make a consistency check when you re-read the cards. I also suggest heavy tracing/logging of card events/data within the machines, in case of dispute with a customer.

2. Adressed above (cards can't be copied/emulated if you set the mifare keys and access conditions appropriately).

3. I'd rather say read, check, write and turn on the game. Don't write anything in the card without prior verification of the card integrity. But otherwise, it's fine.

4. Mifare DESFire has Credit/Debit commands that could indeed suit your needs. What these commands will allow is to relax the security requirements around the machines. With the classic approach, if the machine hardware/firmware is hacked, you'll end up with a risk of fraud. However, if the cards become able to perform real debit/credit by themselves, you can mitigate this risk. Up to you to check if it is worth it.

5. I don't know if it was what you were asking for, but of course, NXP has off-the-shelf chips than you can use to design a Mifare terminal.

Answer 3

It seems to me that the only reasonably secure option for money 'storage' is to treat the card only as a somewhat secure container for a GUID and handle the actual balance verification and modification centrally.

There's a reason why standard policies for EMV credit cards often limit offline purchases (if any) to something like 20 dollars cumulative; there are too many different attack scenarios to keep an offline system secure unless the stakes are low enough, even if you use much more secure (and expensive) chips.

If it's an 'arcade game saloon' in the sense that people can pre-pay for a few hours of entertainment, then the risks are low and you can mitigate them with nontechnical means (has a person spent a dozen hours in your arcade without ever refilling the card?), but if it involves e.g. gambling and possible winnings, then it's an entirely different matter.