How MIFARE Uses Cookies

[Rick van Krevelen]

Hi TapLinx team,

Thanks for your explanation. Unfortunately however, I hope you understand that now I'm left a bit confused:

• you state iOS accepts only "NFC Forum Compliant" tags based on a decision to "only accept NDEF type tags and reject all other",
  yet the CLASSIC 4k (Emulation) ICs we use are ISO/IEC 14443-2,3[,4] compliant,
  thus within the NFC Forum specification's
  range of "ISO/IEC 18092, ISO/IEC 14443-2,3,4 and JIS X6319-9",
  and furthermore, these tags are referenced and used as NFC tag by applications such as NFC Tools
  for PC or Mac (using peripheral devices)
  and for Android NFC devices (as you already mentioned);



• you state "the architecture of the Classic which does it not allow to have NDEF messages blocks",
  yet NXP's application note #1305
  explains "how the Reader device (also called NFC device) can store NDEF data inside an MIFARE Classic or MIFARE Plus tag";



• you state a card issuer would not "format my card as NDEF compliant tag", yet an NFC device can
  perform State Changes/Transitions into NFC Forum compliant states (INITIALISED, READ-WRITE or READ-ONLY),
  not just when formatting a "blank card" after production phase (see section 6.5 of AN1305),
  but also when interacting with a "production" card in Valid State (see section 6.4 of AN1305).

In order to read/write MIFARE Classic as "NDEF enabled" tags, the NFC device must support
the following Command Set (Section 5 of AN1305) or ISO 7816-4 APDU:

• Read operation,


• Write operation, and


• Authentication operation.

At least for MIFARE DESfire and MIFARE Plus tags, these commands are supported in the (public) iOS13 CoreNFC framework's
NFCMiFareTag protocol, see e.g.
sendMiFareCommand
and sendMiFareISO7816Command.
Similar APIs are available for generic ISO 7816-enabled tags (with application identifier matching the app configuration) in
NFCISO7816Tag protocol's
sendCommand. Of course, this would require a successful detection of an not ISO/IEC 7816-4 (APDU) compliant tag (e.g. the SmartMX CLASSIC 4k Emulation tag, but unfortunately not the CLASSIC 4k).

This leaves me with two questions:

1. Do know why iOS13 does not the detect the ISO/IEC 7816-4 APDU compliant (SmartMX) Emulation tags, and therefore the respective (internally mapped) MIFARE Command Set required for (NFC Forum compliant) state changes/transitions, as e.g. described by AN1305?



2. given that we would also be fine with using private framework APIs, do you think the MIFARE Commands might be sent via custom interaction with the private NFReaderSession API?

Best regards,

Rick

---

+ 0  |  - 0

[Rick van Krevelen]

Hi TapLinx team,

My use case concerns a pre-existent or 'legacy' transaction system where various MIFARE Classic (emulation) card types are already circulating, and the new iOS/CoreNFC support might have opened up new opportunities for including iPhone users to interact with their current (legacy) smart cards.

I'm sure there are many legacy systems out there that would benefit greatly from iOS support for legacy ICs, as these will be circulating for a while before becoming obsolete and removed completely.

Regardless of the actual ATQA or SAK, do you think the interaction with Classic emulation ICs could be made to work with a bug-fix in iOS of the 14443-4A protocol, as it seems to fail differently for different manufacturers?

Kind regards,
Rick

---

+ 0  |  - 0

[Rick van Krevelen]

Hi TapLinx team,

Thanks again for responding. Yes indeed, similar to the previous listing of errors with the Infineon Classic emulation tag, the NXP SmartMX emulation tag is not itself a Classic 4K tag, but emulates it. Both Infineon and NXP tags have an actual SAK value of 0x38, e.g. when read on an Android device with NXP's TagInfo app, which should translates into bits #8..#1 as follows, according to Table 6 of Application Note #10833:

0 0 1 1 1 0 0 0

Following NXP's Figure 3 of Application Note #10834, this value (i.e. SAK bits 6=1, bit 5=1, and bit 4=1) should be classified as "Smart MX with MIFARE 4K".

When comparing the two log listings, the Infineon emulation tag gets detected as both 0x20, i.e. ISO 14443-4 generic, and 0x18, i.e. MIFARE 4k (the _NFReaderSession log actually reads "1 tags found" but fails with a "Stack Error"), whereas the NXP SmartMX emulation tag is classified only as 0x20, i.e. ISO 14443-4 generic. It seems the NXP tag short stops due to an internal 14443-4 "receiption error" and consequently never gets around to the Select Acknowledge (SAK) as an (emulated) type 0x18 or MIFARE 4k.

My question now remains: Assuming the new CoreNFC framework implemented the generic/standard 14443-4 protocol correctly, could one or both of these errors be due to incompatibility on the part of these emulation tags, or is/are the emulation tag(s) fine and is the recent iOS CoreNFC implementation of the generic/standard 14443-4 protocol incomplete?

---

+ 0  |  - 0

[Rick van Krevelen]

PS. the links have vanished, but should be:

• stackoverflow.com/a/44582430


• developer.apple.com/documentation/corenfc/nfcmifarefamily

---

+ 0  |  - 0

[Rick van Krevelen]

Hi TapLinx team,

Thanks for your response. I am aware of Android's NFC capabilities, but we would like to reach the iOS consumers too. Reading NDEF messages was already possible on iOS11 since 2017, even on MIFARE Classic tags (if properly formatted, see e.g. ).

I was hoping perhaps you would have more insights on the recent September 2019 expansion of iOS13 (beta since June 2019) with its extended CoreNFC framework, since this now has full support for reading/writing MIFARE DESfire, UltraLight and Plus tags, and also one

unknown

member (see ), which I suspected may be useful for the MIFARE Classic 4k (Emulation) ICs which are widely used today.

Cheers,
Rick

---

+ 0  |  - 0

[Author]

Posts