3

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.

migrated from electronics.stackexchange.com Nov 27 '16 at 21:39

This question came from our site for electronics and electrical engineering professionals, students, and enthusiasts.

  • 1) get the datasheets and start reading. You now make assumptions about how the system works / you think it works so you could be spending time on features that are not even possible. 2) Forget about "bullet proof" sofar all such systems are / will be hacked after some time. There is always a balance between security and price. Ask yourself what level of security is good enough for your application. Is security so important to you that you would want to hire an expert to challenge your system ? – FakeMoustache Nov 27 '16 at 21:36
  • I doubt the datasheets contain up to date information about attacks on the hardware. But wikipedia should be a good start. – Josef Nov 28 '16 at 13:56
  • Why not consider server side verification? – 4 Leave Cover Nov 29 '16 at 2:01
3

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 ;)

  • 2
    Accessing blocks with non standard keys is also trivial. It takes less than a minute to get all keys used on the card. The card can then be copied, restored to a previous state or cloned to a chinese card which allows to change the UID even with an android smartphone. To sum up: mifare classic is completely broken! Tools to do that are for example MFCUK and mfoc. A USB reader costs about ~30€ and once the keys are known a smartphone is enough to copy cards! – Josef Nov 28 '16 at 14:00
  • @Josef What hardware did you use to interface to your PC when getting these blocks? – user400344 Nov 28 '16 at 15:15
  • 1
    an ACR122U – Josef Nov 28 '16 at 15:17
1

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.

0

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.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy