Mifare Plus X switch from SL1 to SL3

[Kevin Matthews]

Hello,

I’ve been learning to program Mifare Plus X tags. After reading through the docs, I am under the impression that at minimum we are required to program the following AES keys (see ds163735, section 9.4):
• Card Configuration Key
• Card Master Key
• Level 2 Switch Key (for L1 card)
• Level 3 Switch Key (for L1 card)

I have verified that we are using an L1 card so I have programmed these keys using the WritePerso command. After this series of writes, I then commit the changes using CommitPerso. After this, the card enters SL1 and behaves as a Mifare Classic tag. However, I am unable to begin authentication with Level 3 Switch Key and so am unable to switch the card to SL3.

Do you have any ideas of what I could be missing? Any recommendations on what else I should read?

Are we required to program values for the Field Configuration Block or MFP Configuration Block?

For reference, I am able to read the random number response of the Originality Key when in SL0 but am unable to read this response in SL1.

Thanks for your help!

-Kevin Matthews

---

+ 0  |  - 0

[TapLinx Support]

Hi Kevin,

Yes, the “switch procedure” is a little bit tricky. With a blank card you start with SL0. Here you have to write the AES keys at (hex) blocknumber 9000 (Card Master Key), 9001 (Card Configuration Key), 9002 (SL2 Switch Key) and 9003 (SL3 Switch Key). For a MIFARE Plus S, address 9002 does not exist. With writePerso(), commitPers() and allowing layer 4 communication you switch to SL1. You switch to SL3 with an authentication to block 9003 with firstAuth() and also with allowing layer 4 communication.

The TapLinx team

---

+ 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

[TapLinx Support]

Hi Kevin,

“Layer 4 communication” is an option and you must set this option in SL0->SL1 and SL1->SL3. In SL0 you must do a write perso AND commit perso! In SL1 you make a “first authenticate” to block 9003 with the appropriate key. Do not forget to set also “Layer 4 communication”.

The TapLinx team

---

+ 0  |  - 0

[Christian Bongardt]

Hi,

we're also lost at the same step as Kevin.

We have swithed from SL0 to SL1. However now we are unable to perform the first authentication in order to switch from SL1 to SL3 since we are unable to set "Layer 4 communication". We are using the ACR1222L from ACS. Can anyone give a hint on how to active Layer 4? We have some cards which already are in SL3 and we can correctly authenticate, write and read encrypted without a problem.

Thank you in advance

---

+ 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

[Christian Bongardt]

Hi Kevin,

thank you very much for your quick reply.

We'll as I said we are just in the same stage as you did in the past. However we are using Kotlin and Javas SmartCard API. The readers were using are the ACS ACR122U and the ACS ACR 1222L which both use the PN532. The good thing is these readers provide a pseudo APDU to directly communicate with the PN532.

We're currently trying to put the tag to sleep and reactivate it in order to enable ISO14443-4 layer. However we're not sure which commands of the PN532 we should use in order to achieve this. We're using the InRelease command and the InAutoPoll. For layer 4 communication we successfully use the InDataExchange command and as I said we have completely implemented SL3 authentication, reading and writing. We're only stuck with the SL1 to SL3 switching.

(https://www.nxp.com/docs/en/user-guide/141520.pdf page 65-66 contains a list of the PN532 commands)

Any help is very much appreciated and once again thank you very much.

---

+ 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

[test12]

test

---

+ 0  |  - 1

[Tithi Patel]

Hi,

I am using Mifare Plus X cards and encoding them in SL0. After encoding I am trying to switch to SL3. If I manually remove the card from reader after encoding, I can switch the card to SL3, but not in the same session as I do encoding (after Commit Perso).

I understand that layer 4 communication is to be allowed. I am using WinScard.dll and HID Omnikey 6321. How do I achieve this?

Can you please detail out the steps after Commit Perso? I am following below:

1. Commit Perso
2. Power Down Mifare Plus
3. Connect Mifare Plus (winscard gives error that card is removed)

Thank you.

---

+ 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,

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

---

+ 0  |  - 0

[Christian Bongardt]

Hi Kevin,

thank you very much for your interest.. But not yet.

The good thing is that we'll order our Tags preconfigured to SL3. However I've ordered the CLRC663 plus development kit (OM26630FDK - https://www.nxp.com/products/identification-and-security/nfc/nfc-reader-ics/clrc663-iplus-i-nfc-frontend-development-kit-for-access-management-applications:OM26630FDK) and as soon as we get it I'll use the NFC Cockpit (https://www.nxp.com/products/identification-and-security/nfc/nfc-reader-ics/nfc-cockpit-configuration-tool-for-nfc-ics:NFC-COCKPIT) to test it out. Moreover we're moving away from the PN532 and ACS. The support ACS is giving us is terrible (actual there is no support at all).

We're looking for a desktop NFC reader which can be used from both, Linux and Windows, even if it has a propietary API. I think serial communication would be the best option. It should equip clrc663 or the pn5170. Any recommendations?

---

+ 0  |  - 0

[Tithi Patel]

Hi Kevin,

After going through your post again, I think I too am stuck at the same place. It works perfectly fine till Commit Perso. After that when I try to switch to SL3, SCardTransmit gives Card Removed error.

I think I am not activating Layer 4 properly. I am using HID Omnikey 6321. Will you be able to help out please?

Thank you!

---

+ 0  |  - 0

[Kadir YILDIZ]

@Kevin and @Christian
Hi,
About the ACS ACR readers;
I do not know if you solve your problems, but following information may be useful for everyone who use ACS readers.
I also got the same problem with the ACS reader ACR 1252U. Lots of solutions could be there. But it works for me.

In SL1 I got errors on two different processes;
1. AES authentication for SL0/SL1
2. Switch to SL1 to SL3.

The reason of errors is failure to activate correct protocol 14443-3 or 14443-4.

Due to the datasheet of ACR 1252U reader (90% same as ACR122U) there two type of process.
1. APDU Flow. => The reader understand your command then acts as it have to do. We use generally this flow for communicating with the cards.
2. Escape Command Flow. => The reader can not identify some APDU commands or sometimes you need to communicate with the reader. In these cases we use that.

APDU flow is;
1. SCardEstablishContext
2. SCardListReaders
3. SCardConnect
4. SCardTransmit
5. SCardDisconnect

Escape Command Flow is:
1. SCardEstablishContext
2. SCardListReaders
3. SCardConnect
4. SCardControl
5. SCardDisconnect.

For first authentication of Mifare SL1 or switching from SL1 to SL3, you have to choose 14443-3 or 14443-4 protocols.

If you need to communicate due to 14443-3; activate it using escape commands as follow;
1. Start a transparent session between reader and your controller (not the reader may be a PC)
2. Activate 14443-3 protocol.
3. End transparent session.

Full command list for activating 14443-3;
COMMAND_START_TRANSPARENT_SESSION = FF C2 00 00 02 81 00
COMMAND_END_TRANSPARENT_SESSION = FF C2 00 00 02 82 00
ACTIVATE_14443_3_COMMAND = FF C2 00 02 04 8F 02 00 03

1. SCardEstablishContext
2. SCardListReaders
3. SCardConnect
4. SCardControl(COMMAND_START_TRANSPARENT_SESSION)
5. SCardControl(ACTIVATE_14443_3_COMMAND)
6. SCardControl(COMMAND_END_TRANSPARENT_SESSION )
...
x. SCardDisconnect

Full command list for activating 14443-4;
COMMAND_START_TRANSPARENT_SESSION = FF C2 00 00 02 81 00
COMMAND_END_TRANSPARENT_SESSION = FF C2 00 00 02 82 00
ACTIVATE_14443_4_COMMAND = FF C2 00 02 04 8F 02 00 04
1. SCardEstablishContext
2. SCardListReaders
3. SCardConnect
4. SCardControl(COMMAND_START_TRANSPARENT_SESSION)
5. SCardControl(ACTIVATE_14443_4_COMMAND)
6. SCardControl(COMMAND_END_TRANSPARENT_SESSION )
...
x. SCardDisconnect


For Kevin's "However, I am unable to begin authentication with Level 3 Switch Key and so am unable to switch the card to SL3."
and Christian's problem "We are using the ACR1222L from ACS. Can anyone give a hint on how to active Layer 4?"

Use Escape command flow and activate 14443-4 first. It could solve the problem.

---

+ 0  |  - 0

[Author]

Posts