Help understanding what is what in the nfc ecosystem

[Jose Luis Campanello]

Hi,

i'm new to NFC and i have a bit of confusion about what is what. Mi goal is to use MIFARE Classic/Plus cards with mobile phones.

If i understand correctly:

THE FIRST thing to consider is the chipset the phone has. There are phones with an NXP chipset and these read cards without problem. There are other phones (ex: Samsung) with Boardcom chipsets. On these i receive a message on the line of "Card type not Supported message".

This last error message is puzzling, because MIFARE cards are ISO-14443 compatible, so they should at least be able to communicate. On Android these readers report the card as an NfcA type (ISO-14443 Type A, i believe). On other phones, Android reports MifareClassic together with NfcA.

Can someone assist me with this to understand the scenario of using MIFARE cards with any mobile (independent of chipset)? I've considered using MIFARE Plus EV1 cards (supposedly compatible, they have an ISO-wrapping mode). Will this work?

-----
THE SECOND thing to consider are APDU commands. These depend on the actual chipset. The idea here is that APDU's are a method for the application to request the mobile's NFC chip to actually send commands to the contactless card (MIFARE or otherwise). Is this correct?

There is also the problem of "set key" APDUs. I think these are for the mobile's chip. Is this possibly the source of the incompatibility with Boardcom chips of the first point?

-----
THE THIRD think is Android's support for the cards. Devices with the Boardcom chips do not provide the MifareClassic class. But if they are ISO-14443 compatible, then i understand that despite the lack of this class, i should be able to wrap the commands and "re-create" this native class somehow?

----------

Well, as i said i'm new to this technology and the ecosystem is so complex that i cannot wrap my head around all combinations.

I would greatly appreciate any help with this and THANKS in advance!!!

---

+ 0  |  - 0

[TapLinx Support]

Hi Jose Luis,

This depends on the cipher used for the MIFARE Classic. It is proprietary and not implemented by most non-NXP reader chip manufacturers. So, it has nothing to do with the ISO 14443-3 standard. Unfortunately, you cannot detect, if an Android phone is able to communicate with a Classic or not by software methods.

But there are alternatives, for price sensitive applications the MIFARE Ultralight and for security sensitive applications the MIFARE DESFire. Of course, you can use the MIFARE Plus EV1—but you should avoid the security layer 1! With this layer the Plus is compatible with the Classic and inherit also the Classic cipher.

The “setkey” APDU command comes from stationary reader infrastructure where the key is stored in the reader because the cryptographic methods are handled in the reader. For the Android implementation there is no such command. You should have a look to TapLinx, our Android library (see link below). You will find that the key is handled in the library.

The TapLinx team

https://www.mifare.net/en/products/tools/taplinx/

---

+ 0  |  - 0

[Jose Luis Campanello]

Hi, thanks for the quick response!

If i understand correctly then, i could use TapLinx with MIFARE Plus EV1 in mixed mode (both ISO-compatible and Classic compatible) to achieve my goal?

That will require a migration of cards (Classic to Plus EV1) and setting the new EV1 cards to mixed mode.

Using TapLinx on the phones will let me access the EV1 cards through all chipsets (both NXP and not, such as Boardcom) and operate the cards as if they were Classic.

The existing readers will still be able to access Classic and new EV1 cards.

Is this correct?

Again: thanks a lot for the response!!!

---

+ 0  |  - 0

[TapLinx Support]

Hi Jose Luis,

Your card must not identify itself as MIFARE Classic. You will not overcome the MIFARE Classic mode in this case. Your MIFARE Plus EV1 should use SL3 layer not to fall into the Classic mode.

The TapLinx team

---

+ 0  |  - 0

[Author]

Posts