How MIFARE Uses Cookies

[Kevin Matthews]

Hi Christian,

Any luck? I'm curious if you've found a solution.

---

+ 0  |  - 0

[Kevin Matthews]

Hi Tithi,

Your questions is beyond my knowledge. We'll have to hope that support gets back to you.

If they don't respond to you on this thread, perhaps try opening a separate thread?

---

+ 0  |  - 0

[Kevin Matthews]

Hi Christian,

Ahh, I didn't even think to ask which chip you are using. I am using the PN7150, and your chip seems to handle the details differently. I can't claim to have much knowledge of the PN532.

What about using InDeselect instead of InRelease? It looks like InRelease completely deletes the target details while InDeselect retains target information. I think InDeselect corresponds to what I was calling "deactivation to sleep mode".

I don't see that InSelect gives you the option to specify the protocol, but I could easily be missing something. Maybe that won't work....

Have you tried the InJumpForDEP command? The description looks promising, actually.

How many targets appear when you put a single tag in the field? (Looks like this is done with InListPassiveTarget?). I had NXP's tech support hint that a tag supporting two protocols could appear as two tags. This contradicts my own experience - I had to use the sleep mode trick because only a single tag appears - but it's worth experimenting with.

Hope that gives you a few ideas,

-Kevin

---

+ 0  |  - 0

[Kevin Matthews]

Hi Christian,

The solution I found is to deactivate the tag to sleep mode and reactivate it while specifying the ISO-DEP protocol and interface (ISO-DEP == Layer 4 communication).

For hardware/historical reasons I was forced to spin my own state machine implementation, so I'm sending the commands manually.

When I put an SL1 tag in the field I see it activate using the Frame RF interface and Protocol T2T (are you the same?).
At this point, I have an active tag (RFST_POLL_ACTIVE).
I can sleep the RF_DEACTIVATE_CMD(sleep_mode), at which point the tag enters RFST_W4_HOST_SELECT.
From here, I reactivate the tag using RF_DISCOVER_SELECT, but I specify the the protocol as "PROTOCOL_ISO_DEP" and the interface as "ISO-DEP RF Interface".
If all went well you should receive an RF_INTF_ACTIVATED_NTF with the ISO-DEP interface and protocol.

If you're using the linux_libnfc-nci library (this is open source), I think they provide a function that does this:
nfcTag_writeNdef() in src/include/linux_nfc_api.h
If you follow the call stack down, I think the nuts and bolts are in:
reSelect() - src/service/interface/nativeNfcTag.cpp

If you're using the TapLinx SDK, I'm unfortunately not sure. I would imagine that they have a command similar to the linux libnfc-nci library that will do it all for you. If not, there must be functions to send deactivate and discover select commands.

Once the tag reactivates using ISO-DEP protocol and interface, you should be able to authenticate with the Level 3 switch key.

Hope this helps,

-Kevin

---

+ 0  |  - 0

[Kevin Matthews]

Hello TapLinx team,

Thanks for your help. Your response time was excellent!

I'm theorizing that I am not properly allowing layer 4 communication. I've been able to write the AES keys at 0x9000, 0x9001, and 0x9003. However, I've only been able to authenticate with the SL1 Card Authentication Key at 0x9004. It looks like this is available in ISO14443-3 mode while the SL3 Switch Key requires ISO14443-4 mode, just as you suggested. This makes me think that I'm not properly enabling ISO14443-4 communication. Does that sound correct?

Thanks for your help,

-Kevin

---

+ 0  |  - 0

[Author]

Posts