MIFARE Classic Emulation throws \"Stack Error\" on iOS13\'s CoreNFC framework

[Rick van Krevelen]

My team is attempting to get the iOS13 SDK's CoreNFC framework to read MIFARE Classic/emulation ICs (as used in Dutch public transportation) on iPhone X models.
Whereas the MIFARE Plus, DESfire and Ultralight have explicit support (which we confirmed for both DESfire and UltraLight ICs), Classic (Emulation) does not. However, there is also the "unknown" family member (https://developer.apple.com/documentation/corenfc/nfcmifarefamily/unknown) and also a note on the NFC Tools iOS app's description mentioning the MIFARE Classic card will read and write when in "compatibility mode" (https://apps.apple.com/us/app/nfc-tools/id1252962749).

One Infineon MIFARE Classic Emulation IC actually gets detected as both "Generic ISO 14443-4A" and "MiFare" tag, but iOS CoreNFC framework finally throws a "Stack Error" after two threads seem to collide. Strangely enough, a NXP SmartMX which also emulates a MIFARE Classic, does not get detected but rather causes "Receiption errors" (misspelling from source). See CoreNFC/NearFIeld framework console log excerpts below.

What can we do
===== Log excerpt for Infineon MIFARE CLassic Emulation IC

error	14:48:08.630735 +0200	nfcd	00000001 04e04390 -

    [NFDriverWrapper disconnectTag:tagRemovalDetect:]:1448  Failed to disconnect tag: 

    -{length = 8, bytes = 0x7bad0300e0d9f789} 

    { Tech=A Type=Generic 4A ID={length = 4, bytes = 0x319a2f88} 

    SAK={length = 1, bytes = 0x20} ATQA={length = 2, bytes = 0x0200} historicalBytes={length = 0, bytes = 0x}}

:

error	14:48:08.667559 +0200	nfcd	00000001 04e04390 -

    [NFDriverWrapper connectTag:]:1436  Failed to connect to tag: 

    -{length = 8, bytes = 0x7bad030077180efa} 

    { Tech=A Type=Generic 4A ID={length = 4, bytes = 0x319a2f88} 

    SAK={length = 1, bytes = 0x20} ATQA={length = 2, bytes = 0x0200} historicalBytes={length = 0, bytes = 0x}}

:

error	14:48:08.675369 +0200	nfcd	00000001 04e04390 -

    [NFDriverWrapper connectTag:]:1436  Failed to connect to tag: 

    -{length = 8, bytes = 0x7bad030077180efa} 

    { Tech=A Type=Generic 4A ID={length = 4, bytes = 0x319a2f88} 

    SAK={length = 1, bytes = 0x20} ATQA={length = 2, bytes = 0x0200} historicalBytes={length = 0, bytes = 0x}}

:

error	14:48:08.682881 +0200	nfcd	00000001 04e04390 -

    [NFDriverWrapper connectTag:]:1436  Failed to connect to tag: 

    -{length = 8, bytes = 0x81ad0300984374f3} 

    { Tech=A Type=MiFare ID={length = 4, bytes = 0x319a2f88} 

    SAK={length = 1, bytes = 0x18} ATQA={length = 2, bytes = 0x0200} historicalBytes={length = 0, bytes = 0x}}

:

default	14:48:08.683150 +0200	nfcd	00000001 04e07470 -

    [_NFReaderSession handleRemoteTagsDetected:]:445  1 tags found

default	14:48:08.685792 +0200	nfcd	00000001 04e07470 -

    [_NFReaderSession connect:callback:]:507  NFC-Example

:

error	14:48:08.693429 +0200	nfcd	00000001 04e04390 -

    [NFDriverWrapper connectTag:]:1436  Failed to connect to tag: 

    -{length = 8, bytes = 0x81ad0300984374f3} 

    { Tech=A Type=MiFare ID={length = 4, bytes = 0x319a2f88} 

    SAK=(null) ATQA=(null) historicalBytes={length = 0, bytes = 0x}}

:

error	14:48:08.694019 +0200	NFC-Example	00000002 802e2700 -

    [NFCTagReaderSession _connectTag:error:]:568  Error 

    Domain=NFCError Code=100 "Stack Error" UserInfo={NSLocalizedDescription=Stack Error, NSUnderlyingError=0x2822a86c0 

    {Error Domain=nfcd Code=15 "Stack Error" UserInfo={NSLocalizedDescription=Stack Error}}}

Result: Reception seems almost ok:

• type: Generic 4A or MiFare (correct)


• identifier: 0x319a2f88 (correct)


• ATQA: 0x0200 (correct) or null


• SAK: 0x20, 0x18 or null (expected 0x38)


• historical bytes: 0x (correct)

===== Log excerpt for NXP SmartMX MIFARE CLassic Emulation IC

error	10:44:50.677470 +0200	nfcd	00000001 04e04390 -

    [NFDriverWrapper disconnectTag:tagRemovalDetect:]:1448  Failed to disconnect tag: 

    -{length = 8, bytes = 0x07320d00f3041861} 

    { Tech=A Type=Generic 4A ID={length = 4, bytes = 0xcf3e4004} 

    SAK={length = 1, bytes = 0x20} ATQA={length = 2, bytes = 0x0200} historicalBytes={length = 0, bytes = 0x}}

default	10:44:50.677682 +0200	nfcd	00000001 04e04390 -

    [NFDriverWrapper restartDiscovery]:1953

:

error	10:44:50.650673 +0200	nfcd	Proc Iso-Dep pres chk ntf: Receiption failed

Result: ISO 14443-4 Type A (T=CL Iso Dep) reception fails

• type: Generic 4A (correct)


• identifier: 0x319a2f88 (correct)


• ATQA: 0x0200 (correct)


• SAK: 0x20 (expected 0x38)


• historical bytes: 0x (expected 0x4A434F503234325232, i.e. JCOP242R2 or JCOP OS v2.4.2 R2)

---

+ 1  |  - 0

[TapLinx Support]

Hi Rick,

The NFC Interface on iOS devices is very restricted. Since iOS13 it is possible to read NDEF messages from NFC tags. If you want to read MIFARE Classic cards I highly recommend using an Android device! On Android you can use the NFC without restrictions.

The TapLinx team

---

+ 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

[Rick van Krevelen]

PS. the links have vanished, but should be:

• stackoverflow.com/a/44582430


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

---

+ 0  |  - 0

[TapLinx Support]

Hi Rick,

In your listing I found: “SAK: 0x20 (expected 0x38)”. SAK = 20 means ISO 14443-4 protocol cards (MIFARE DESFire and MIFARE Plus in SL3). However, the MIFARE Classic has SAK = 08 (1K memory size) or 18 (4K). So, the card cannot be a MIFARE Classic.

The TapLinx team

---

+ 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

[TapLinx Support]

Hi Rick,

The SmartMX is JCOP card with an optional MIFARE Classic and/or MIFARE DESFire functionality. The SAK and ATQA signature of a SmartMX does not have to be the same as for a MIFARE Classic and/or a MIFARE DESFire.

For me it is not clear which is the target product you want to use in your business? Instead of using an “emulation” from a third-party manufacturer, does it make not more sense to use the target card and analyze the behavior with your device?

Regards,
The TapLinx team

---

+ 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

[TapLinx Support]

Hi Rick,

the stumbling block here is the limitation of iOS to accept only “NFC Forum compliant” tags. The NFC Forum defines, how data and data blocks must be organized into NDEF message types. You can use a MIFARE DESFire or a MIFARE Ultralight or an NTAG to format it as NFC Forum compliant tag—but not a MIFARE Classic. The reason is the architecture of the Classic which does it not allow to have NDEF messages blocks.

If I were a card issuer for a transport ticket (or whatever), would I then format my card as NDEF compliant tag? The answer is no! I would always use the full features of the card and organize the data in an optimal way (and ignore the NFC Forum compliant limitations). From this point of view, you will never be able to use tags with other formats as NDEF type on your iOS. So, for me it is not a “bug” which you are facing, it is a decision only accept NDEF type tags and reject all other.

The TapLinx team

---

+ 0  |  - 0

[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

[TapLinx Support]

There has been a critical error on this website.

Learn more about troubleshooting WordPress.