ACR 35 Authentication not working

[ArchannaParticipant]

I’m tring to read a mifare classic 1k card where load authentication is done but when i authenticate using that key its giving error.

[RichardKeymaster]

Hi, you need to make sure the you loaded the correct authentication keys for your MiFare cards into the reader. More details on how to do this in the ACR3x Technical Reference Manual on page 58.

[ArchannaParticipant]

Hi,
i tried authentication as per the following link from your forums https://flomio.com/forums/topic/acs-35-demo-code/

and i referred your manual too and i tried its happening for a new card which does not have any data but I tried that same in mifare classic 1k which is having data its not authenticating . I tried to read block 04.

what am i missing? what mistake i’m doing in reading the card ?

[RichardKeymaster]

Send me:
– Host device you’re using, including make and model number.
– Host OS you’re using, version number.
– Version of ACR35 driver you are using.
– NFC tag size, inlay manufacturer.
– Actual APDUs and response codes you are sending to the reader.
– What failure in particular are you observing. Provide console log dump.

thanks,
Richard

[ArchannaParticipant]

– Host device you’re using, including make and model number.
Android Mobile , Spice _MI _535
– Host OS you’re using, version number.
Jelly bean , v 4.2.1

– Version of ACR35 driver you are using.
version 1.0.0
we are using mifare classic 1k card .

APDU and response:

The process we are following:
>> store key B in reader
command: FF 82 00 01 06 8B 4A 03 86 AE 22
Response–90 00

>> authenticate block 04 using keyB
command: FF 86 00 00 05 01 00 04 61 01
Response–90 00 (for new card )
Response–63 00 (for card which has data )

>> read 04 block (data block)
command: FF B0 00 04 06
Response–63 00

I’m totally new to this that’s why i’m asking u help

[RichardKeymaster]

First off your device is not listed as supported by the ACS driver. See full list of supported devices here. Secondly, we don’t currently support Android with our Flomio SDK so we have little experience with using the ACS driver on Android. From our experience with iOS and the ACR35, there are several things beyond the driver that can cause inconsistent behavior. These include but not limited to volume of host device, battery level of host device (anything less than 100% charge is questionable), tag quality (varies amongst vendors), and method which the ACR35 is plugged into the audio receptacle of the host device.

That being said, I looked over your APDU pairs and found two issues that are suspect. 1) Why are you using Type B key instead of Type A?? 2) Read data block command requires the Number of Bytes to Read field to be a multiple of 16 bytes for MiFare Classic tags. You entered 0x06, should be 0x10 for that field.

hope that helps,
Richard

[ArchannaParticipant]

Thanks Richard , for your fast response I will look into it ..

once again thanks ..

[ArchannaParticipant]

Hi Richard ,

I’m using acr 35 ACS device ,in that i have done authentication with key A with default keys it authenticated but i tried to read the block which i have authenticated its giving
response as 63 00 .But content was there in that card which i’m reading

the commands which i’m using is :

Load Authentication:

FF 82 00 00 06 FF FF FF FF FF FF

Response :90 00

Authenticate Data:

FF 86 00 00 05 01 00 05 60 00

Response :90 00

Data read:

FF B0 00 05 10

Response :63 00

Datas are Stored from sector 1 and from block 04 to 06 and keys are default keys

In any way can u help me ?

[KhristineModerator]

Hi Mr. Archanna,

This is Khristine from ACS.

May you provide the firmware version of the ACR35 reader you are using? Our engineers made some testing here but were not able to reproduce the issue you encountered by using firmware v1.06.

Please try the script tool which I forwarded to Richard.

Thank you!

[RichardKeymaster]

Archanna, I uploaded the script tool for Android to our server. You can download the ACR3x Script Tool from here. Also, I’ve included a screen shot of the script ACS used to test out the scenario you’re having issues with.

Are you sure you have valid MiFare Classic tags? Are you sure that you’re running the precise sequence as displayed in the screen shot? I would try to reproduce using the ACS script tool to make sure you’re not dealing with defective hardware.

best,
Richard

[ArchannaParticipant]

Hello Khristine & Richard ,
Thanks for your reply,

firmware version v1.06 which u have tested is correct and really thanks for sending me the script to check the commands its working fine for me.So, I came to know that card reader is not a defective one. I will look the demo apk and find where i’m missing
Once again thanks for your reply …

[KhristineModerator]

Hi Archanna,

You are welcome 🙂 Just let us know in case there will any problems.

[ArchannaParticipant]

Hi,

I checked with the script tool which u have given its working fine with that .but the same apdu is not working in that demo app its working till authentication process but after that its not reading the block which i have authenticated ..

[KhristineModerator]

Hi Archanna,

May I know the demo app you are referring to? If you have the source code of that demo app, you can try to recompile it using a library. This library is used on the script tool provided.

You may download the library on this link: http://www.acsdownload.com/download-file/5674/5674-acsaudiojack-1.0.0preview15.rar

Username: flomio04
Password: ZnkHwdyzHq

Please let us know the progress.

Thanks again!

Khristine

[ArchannaParticipant]

Hi Khristine,
Thanks for your help,

As i mentioned earlier i’m using acr 35 ACS device and i’m using the source code in the link which i have given
http://www.acs.com.hk/en/products/341/acr35-nfc-mobilemate-card-reader/

and tried to do as mentioned the manual .As i said its happening till authenticating the block but its not reading the block which i have authenticated ..its giving 63 00 only as response but its working with the script tool app which u have given …
I tried with the jar file u have given in that also its showing the same output ..

but it’s working fine with the play store app
you can see the link for play store app here
https://play.google.com/store/apps/details?id=com.acs.mobilemate&hl=en

i could not find where is the mistake …help me if you can in any way

Thanks,
Archanna

[ReeceParticipant]

View post on imgur.com

Hi Richard, I am having similar issues to Archanna and have had some communication with Scott on another thread https://flomio.com/forums/topic/error-domainflomiosdk-code-3/

As per the image above I have now got the ACR3x Script Tool from this thread and trying to authenticate Sector 15 to read the data. The private key is not the standard all F’s but is correct as per the ’90 00′ response.

In all my other previous attempts using the ACR35 Driver and ACS MobileMate the only error code I received was ’63 00′ however this script tool has now shown a 6A 81 response. This is an invalid command response which I’ve found is due to incorrect P1 and P2 fields as per (https://www.eftlab.co.uk/index.php/site-map/knowledge-base/118-apdu-response-list)

6A	--	E	Wrong parameter(s) P1-P2
6A	00	E	No information given (Bytes P1 and/or P2 are incorrect)
6A	80	E	The parameters in the data field are incorrect.
6A	81	E	Function not supported

The APDUs I’m using follow the same pattern that Archanna and yourself have done following page 58/59 of ACR3x Reference Manual (http://www.acs.com.hk/download-manual/6379/REF-ACR3x-1.03.pdf).

Would you be able to advise what to change about the APDU’s or any other changes to make?

For reference here’s the relevant details:

– Host device you’re using, including make and model number.
Android Mobile, Samsung Galaxy S4 (GT-19-505)

– Host OS you’re using, version number.
Jelly bean , v 4.4.2

– Version of ACR35 driver you are using.
firmware version 1.0.6

using Mifare classic 1k card.

APDU and response:

The process we are following:
>> store keyA in reader
command: FF 82 00 00 06 C7 35 72 19 F2 03
Response–90 00

>> authenticate block 00 (Sector 15) using keyA
command: FF 86 00 00 05 01 3C 04 60 00
Response–63 00
Response–6A 81

>> read block (data block)
command: FF B0 00 00 10
Response– 63 00

[RichardKeymaster]

Hey Reece, I commend you on the thoroughness of your post. I wish all posters were like you. Based on everything you’ve experimented and reported, I get the feeling you are perhaps encountering an issue with the reader. I say so because it seems very odd that you’d get 2 different responses (63 00 and 6A 81) for the same sequence of APDU commands.

Perhaps there’s a timeout condition happening on the MiFare Classic or something of the sort. The problem could be the physical tag itself. We’ve found instances where the quality of a tag is so poor that not enough energy is harvested in order to properly perform certain tag functions. Particularly power intensive functions involving security and authentication. This would explain why we’ve been able to carry out the same APDU sequence on our side per Scott’s work.

I’ve talked it over with everyone on our team and we’re all puzzled. I would suggest trying tags from different vendors, HID and Smartrac offer quality tags. Otherwise, you could send us some sample tags and we can assess them in depth to get your some answers. Our address is on our About page.

best,
Richard

[ReeceParticipant]

Hi Richard, thank you for the prompt response. I’m glad to hear that you also think there could be an issue with the reader, I have been able to try different APDUs, different Cards and different keys to verify that the process I’m doing is correct but as of yet have been unable to verify whether the card reader is the issue as I am awaiting to order of the FloBLe Plus.

I should receive that this week and hopefully will be able to overcome this issue. However, would it be possible to return this reader in exchange for another to verify for our documentation whether it is a fault of the device or as you also mentioned an issue with the cards.

It is a FloJack v2 / ACR35
P/N: ACR35-A1
S/N RR291-002972
The Original E-Mail confirmation order can be provided if required too.

With regards to the Mifare Classic tags, they are ID Cards used in the company and I have tried various different ones available to me which vary with age, however I am unsure of the vendor which supplies these which I can look into and see if I can acquire and test this with tags from other vendors as you suggest.

[ReeceParticipant]

Hi Richard,

I have just received the FloBLe Plus which has been on order for some time. This integrates into my XCode project well by changing the selected device Type.

readerManager.selectedDeviceType = kFloBlePlus; //kFlojackMsr

I have still got the same issue in that the APDU to load the authentication key is successful, however trying to authenticate and read the data is returning a ’63 00′ error response APDU.

2017-03-20 15:15:04.202438 NFCCardReader[342:52965] Command APDU:FF 86 00 00 05 01 00 3C 60 00
2017-03-20 15:15:04.387353 NFCCardReader[342:50761] Response apdu:63 00
2017-03-20 15:15:04.389110 NFCCardReader[342:50761] MyTest foundTagWithData - payload = (null), deviceID = RR330-001010, ATR = 3B 8F 80 01 80 4F 0C A0 00 00 03 06 03 00 01 00 00 00 00 6A, error = Error Domain=FlomioSDK Code=-3 "Operation was unsuccessful." UserInfo={NSLocalizedFailureReason=State of non-volatile memory has changed, NSLocalizedRecoverySuggestion=No information given, NSLocalizedDescription=Operation was unsuccessful.}

The two potential problems highlighted were either a faulty reader or an issue with the tag themselves. Now having tried a new reader and getting the same error I think it is fair to rule that out. Therefore the tags may be the problem then, I have been told that previous work using the same tags has been successful using the ACR122U and the built-in NFC within the Nexus 7 Android Tablets.

This shows that the tags are capable of working with but seem to be having issues with these range of products. I was wondering if there is a particular chipset frontend being used (in FloJackv2 and FloBLe Plus) that is different to the ACR122U and Nexus Tablet.

Having looked around on NXP I have found this particular data sheet relevant for the PN65 chipset used in Nexus range. Is this different to the ones used in your Flomio product range and could this potentially be the issue? http://www.nxp.com/documents/data_sheet/PN512.pdf

Edit: Noteable thread related to Nexus 7:
http://stackoverflow.com/questions/12119933/what-nfc-tags-does-the-nexus-7-support-2012/18393983#18393983

• This reply was modified 7 years, 8 months ago by  Reece.
• This reply was modified 7 years, 8 months ago by  Reece. Reason: Nexus 7 Chip Link

[RichardKeymaster]

Hey Reece, based on your feedback I believe the issue is with the tags you have. It’s the only explanation that makes sense. The ACR122U and the FloBLE Plus (ACR1255U-J1) use the same NFC transceiver, the PN512, and also share much of the same firmware stack. In fact, you can switch the FloBLE Plus to USB mode, plug it into your PC, and run readily available open source software that works with the ACR122U. It may be worth trying your APDU sequence on the FloBLE Plus over USB and see if it works with the cards you have. If it doesn’t work but does with an ACR122U then you may have uncovered a bug with the BLE firmware stack. Otherwise, you can send us some samples of your MiFare Classic cards and we can do a comprehensive test for you and get to the bottom of this issue.

Flomio, Inc.
7171 Bay Dr. Ste 9
Miami Beach, FL 33141

best,
Richard

[Author]

Posts