How MIFARE Uses Cookies

[Jorge Sanmiguel]

Hi,

I'm trying to use the PWD_AUTH command using an ACR1222L reader. I'm trying sending APDUs {e0 00 00 24 07 1b ff ff ff ff 63 00} and {ff 00 00 00 07 1b ff ff ff ff 63 00} but so far no luck.

Is this the correct formar for the pseudo APDu?

Thanks in advance

---

+ 0  |  - 0

[Jorge Sanmiguel]

Hi,

First, I understand that if the tag is behaving that way there is nothing that anyone can do in software and I trust you that this is the tags behavior. Therefore, I will keep the code I posted since is the only workaround that works for me. But I think you should update the Javadoc and datasheet to reflect that this is the expected behavior.

Second (just out of curiosity, as I said I’m keeping the code I have now) I don’t understand why the states are in any way related to this behavior. What I understand is that the tag will go to HALT or IDLE state when any error happens. For example, as far as I understand, if the tag receives a wrong CRC it will go to HALT or IDLE state and then will answer with a NAK. But if the tag receives a wrong password it will also go to HALT or IDLE but, instead of answering with a NAK, it will timeout. I don’t understand why these two errors will have a different behavior even though it seems like they will go to the same state.

Thanks for your time

---

+ 0  |  - 0

[Jorge Sanmiguel]

Hi Zhaoyu,

the code I had had since before I asked the question is something along this lines:

try {

   // Connect to the tag

   IUltralightEV1 ultralightEV1 = ...

   

   try {

      // Try to authenticate

      ultralightEV1.authenticatePwd(myKey);

   }

   catch(NxpNfcLibException e) {

      if(e.getMessage().equals("Tag was lost")) {

          // It is likely, but in no way sure, that this is an authentication error so handle it like one.

          // For this to be acceptable you need to use a really small timeout to make it unlikely that the user removes the tag while this command is running.

          handleAuthenticationError();

      }

   }

}

catch(NxpNfcLibException e) {

   // Handle other errors including the user removed the tag

}

This is of course an ugly workaround and I was hoping to find a better solution, especially since there is still the possibility to confuse an error caused by a wrong password with an error caused by losing the tag, but it seems this is the best we can do. Do note that this workaround just makes it more unlikely to confuse those errors since we are limiting the possible confusion to the authenticatePwd instruction and we are using a small timeout to force this instruction to end as fast as possible, but it is still possible to confuse these two errors when removing the tag just at the right moment.

Do note however that, if the taplinx team is right, there is nothing we can do to tell them apart. The hardware behaves in exactly the same way in these two cases so there is nothing we can do. Out of curiosity, I will implement this command using the android native NFC API when I have some free time to see if these two scenarios have the same behavior in hardware, but I don’t expect to find anything different to what the taplinx team said.

Regards
Jorge Sanmiguel

---

+ 0  |  - 0

[Jorge Sanmiguel]

Hi,
that's disappointing. Thanks anyway.

---

+ 0  |  - 0

[Jorge Sanmiguel]

Hi,

that's great news for me. Thanks a lot.

Regards

---

+ 0  |  - 0

[Jorge Sanmiguel]

Hi,

I’m handling the Tag Lost exceptions in my code. My problem is that I need to handle an authentication error (wrong password) in a different way than a Tag Lost error (the user removes the device from the tag) and right now it is impossible to tell them apart.

I think there is not a special NAK for PWD_AUTH (at least I can’t find it in the Table 10, Section 9.3, Page 21). But, per the diagram in page 35 (Fig 20, Section 10.8), there seems to be a difference between the two cases I’m trying to tell apart. When the tag is lost (as in the user removes the device from the tag) the tag will simply not be able to send any response to the device and the connection should timeout. On the other hand, when provided with the wrong password the tag will answer with a NAK. Therefore, it seems like it should be possible to tell apart these two cases. Of course, I understand that if the NFC driver is not handling this answer properly there is nothing that Taplinx can do to solve the problem.

Thanks a lot for your help, I will keep waiting for updates.

---

+ 0  |  - 0

[Jorge Sanmiguel]

As a side note, I think there is no waiting time in the code you posted because you are not setting a timeout in the reader. When I remove the timeout from my code I get the behavior you describe, i.e. no waiting time but still a “com.nxp.nfclib.exceptions.NxpNfcLibException: Tag was lost.” is thrown.

---

+ 0  |  - 0

[Jorge Sanmiguel]

Thank you very much for your answer, I really appreciate you taking the time to check the problem personally. I will be waiting for updates on this issue.

---

+ 0  |  - 0

[Jorge Sanmiguel]

For anyone interested in this feature, after some trial and error I was able to write the corresponding bits in the tag with the following code:

            ultralightEV1.enablePasswordProtection(true, 0); // Must be called before writing the tries page since it overwrites the corresponding page, enablePasswordProtection will write 00000000 or 10000000 on the corresponding byte if provided with false and true respectively

        ultralightEV1.authenticatePwd(myKey);





        //Write the limit tries byte, must be done after enablePasswordProtection

        int indexNumTries = ultralightEV1.getTotalMemory() - 12; // Index of associated byte

        int pageTries = indexNumTries / 4; // Index of associated page

        byte[] dataPage = ultralightEV1.read(pageTries); // We read the associated page with the value written by enablePasswordProtection

        byte[] finalPage = new byte[4]; // We create the page to write since dataPage has 16 bytes as documented by taplinx

        System.arraycopy(dataPage, 0, finalPage, 0, 4);

        finalPage[0] = (byte)(dataPage[0]|0x07); // The least 3 significant bytes are the number of tries, we are setting a max of 7 invalid tries but any value from 0 to 7 is valid (note that 0 disables the protection)



        ultralightEV1.write(pageTries, finalPage); //Write the page

Do note that any call to enablePasswordProtection will delete the bytes since it uses the most significative bit of the associated byte to signal if read is password protected and, instead of doing the proper byte operations with the current value of the page, the library will simply overwrite the byte value with 00000000 or 10000000, efectivelly disabling the tries protection.

Hopefully this feature will be supported by taplinx in the future but in the meantime this works.

---

+ 0  |  - 0

[Jorge Sanmiguel]

Hi,
sorry but your response does not solve my problem. I have tested with Taplinx 1.1 (and 1.0) and the behavior is the same.
In fact, in the code snippet you posted they documented exactly the behavior I’m describing:
//Authenticate failed with timeout as Tag Lost exception which is expected as per the datasheet

Can I please have a reference where to the datasheet where this is documented? My guess is they are talking about this document (http://www.nxp.com/documents/data_sheet/MF0ULX1.pdf), but I can’t find this behavior documented anywhere. Furthermore, if that is the expected behavior please update the documentation of the Taplinx Library. The relevant parts of the documentation (https://www.mifare.net/files/advanced_javadoc/com/nxp/nfclib/ultralight/IUltralightEV1.html#authenticatePwd-byte:A- and https://www.mifare.net/files/advanced_javadoc/com/nxp/nfclib/ultralight/UltralightEV1.html#authenticatePwd-byte:A- which I linked in my original post) both state that the method should return a wrong pack when provided with the wrong password which is clearly not what the method is doing.

Finally, since the timeout is the expected behavior, is there a way to tell apart a connection error (e.g. the user removes the tag before the IO is complete) and an authentication error? As of now both situations will cause an exception with “Tag Lost” as message so there is no way to tell them apart.

As a side note, I find this answer quite disrespectful. I don’t get how they “obviously know” which version of the library I’m using when the behavior is the same in both versions of Taplinx (and I tested in both versions before posting my question). Furthermore, you finish your post saying “With the current release (version 1.1) of TapLinx there is no issue regarding Ultralight authentication.” yet the code snippet you posted clearly shows that the library behaves exactly as I’m describing.

---

+ 0  |  - 0

[Jorge Sanmiguel]

Hi,
I have tested on an LG G4 with Andorid 5.1 and a Sony Xperia Z3 Compact with Android 6.0

---

+ 0  |  - 0

[Author]

Posts