Just compare the prices (TME, VAT not included):
DESfire 2k - 0.96€ (100pcs)
DESfire 4k - 1.09€ (100pcs)
Ultralight C - 0.31€ (100pcs)
Plain Ultralight is even cheaper, but does not have any security at all (just couple of write once bits):
Ultralight EV1 - 0.24€ (100pcs)
NTAG213 - 0.23€ (100pcs)
I will add Mifare Classic pricing here as well, but remember the authentication there was broken about ten years ago so it can be also considered to be plain data storage medium only. It is not possible to prevent cloning, however there are systems that can detect cloned cards using a combination of ever increasing counter and a cryptographic signature (see for example here or here).
Mifare 1k - 0.18€ (100pcs)
Mifare 1k EV1 - 0.54€ (100pcs)
So here we have the Ultralight C card that is still secure and costs one third of the commonly used DESfire when cloning prevention is a priority.
An ideal candidate for a research project. Now, what about cheap reader/writer devices? There we have couple of popular options:
- NFC enabled Android phone (A)
- PN532 based devices
- Adafruit (B)
- Elechouse (C) and its clones (D)
- anonymous "Chinese" RC522 based devices (E)
All should be able to communicate with the card according to the chip datasheets. I ordered all the readers mentioned above and did some compatiblity tests with them. And the reality was a bit more interesting than expected indeed.
 |
| Some of the cards and tokens used for the tests |
(A) My old Samsung Galaxy Ace 2 (i8160p) was able to talk to all the cards I have available (Mifare 1k and its clones, Ultralight C, DESfire and DESfire EV1). So I used it as a reference reader for my tests.
(B) Adafruit PN532 Arduino shield. PN532 is a high level chip that does all the basic ISO 14443-3 handling by itself and the application only needs to implement the card specific protocol. This is really well designed board that uses the chip and it reads all cards I have with no issues as expected. It is also the most expensive board in the test.
 |
| Adafruit PN532 Arduino shield in UART mode connected to BusPirate |
(C) Elechouse PN532 module V3. There are reports that it really is different from all its clones and should work properly with all Mifare cards. It is also PN532 based so the notes from the Adafruit board (B) apply as well. My tests confirm that. I had no issues reading DESfire and Ultralight C cards.
 |  |
| original Elechouse PN532 (notice the font used for mode table at the lower left corner) | Back side of original Elechouse PN532, notice the Elechouse name IS printed in italic and top edge signal names have names |
(D) Elechouse clone (Kkmoon) detected Mifare cards with 4 byte ID just fine, but it never noticed any card with 7 byte long ID - like DESfire, DESfire EV1 or Ultralight C. The same was reported for some other clones. I confirmed this behaviour by using both custom hardware (based on this project) and using libnfc tooling. nfc-tools issue #352 also confirms this behaviour.
 |  |
| KKmoon PN532 with reset signal wired to the top header | Back side of Kkmoon PN532, notice the Elechouse name is not printed in italic |
(E) The cheapest reader was an RC522 board I bought locally (GMe 772-164). It was able to read Mifare 1k just fine, it also detected DESfire when the card was almost touching the antenna but it never noticed the Ultralight C card.
 |
| RC522 board with replaced parts and a custom clearance hole |
All NFC cards need a certain strength of the electromagnetic field to properly activate. The reading distance using the unmodified board is pretty bad for all cards and Ultralight C can't be powered at all. There are lots of questions on the internet about how to improve the reading distance when using this board. Sadly, answers are either horribly wrong (RC522 can't support 3DES cards), just wrong (can' t read this card type with Arduino Uno), or focused on the software stack only (increase receiver sensitivity using the built in register).
 |
| RC522 board connected to TI Stellaris Launchpad I just had lying around. It was running a modified https://github.com/miguelbalboa/rfid/blob/master/examples/DumpInfo/DumpInfo.ino sketch |
I only needed to realize (and read the datasheet) that the RC522 chip does not provide any real high level capabilities. It only manages the RF field and does modulation/demodulation of the signal (up to ISO 14443-2). All ISO 14443-3 collision resolving and higher card protocols have to be done in software. This means the chip can support all cards it can talk to using the supported frequency and modulation and that includes the Ultralight C. So the issue is not there.
It turns out the design of the board is sound, but the component selection is poor and tuning is not perfect. This was discovered by the only single person I have seen in all the forums to investigate the RF design and component selection of that board. Thank you ermok!
Now, the fix that is needed to make this board a good performer is supposed to be very simple. There are two inductors on this board that are of the right nominal value (2u2), but are simply unfit when you take a look at their current carrying capability and operating frequency. Replacing them with a properly rated inductor increases the current that can flow through the antenna and that increases the generated electromagnetic field which should allow the card to properly power up.
 |
| Replaced inductors (pay no atention to my soldering, I had little time and only crude tools) |
The other change needed seems to be replacing two tuning capacitors (0805 SMD size). Changing the value from 47p to 33p (using ceramic chip C0G capacitor) should improve tuning and that should increase the field strength even more.
 |
| Replaced capacitors (33p 0805 C0G ceramic) |
I decided to give it a try since I wanted to use Ultralight C cards and the reader was so cheap (about 8€) so I was not afraid to break it. I ordered the recommended set of inductors (FERROCORE CW1008-2200 - 1.26€ per 10 pcs), used hot air to remove the old parts and soldered the replacements. And guess what.. suddenly the reader recognizes Ultralight C cards just fine. The reading distance is not great, but good enough for the close proximity based access control system reader.
So a simple sub-1€ fix was enough to make this cheap board into a proper and usable reader (and writer). The question now is.. can the same procedure be adapted for the PN532 boards, or is the issue there more substantial (like a counterfeit PN532 chip)?
