PWD_AUTH for NTAG21x

[HalParticipant]

Hello,

This is a follow up to a question posed by Nagavardhana on October 31, 2017 at 2:49 pm, the thread topic was “Reading card data from ACR1255 Android”. Sorry to start a new thread on this but I can’t seem to reply on the existing one nor do I see a resolution.

Basically: I have a FloBlePlus bluetooth reader that connects reliable to my device (iPad, iOS 11.4). The reader software is firmware: FWV 1.17.00, hardware: HWV 1.03; the flomio SDK is 3.0.3.

Using sendApdu commands I was able to set a password on my NTAG216 card, locking pages 60 and above but leaving pages below that as read/write. Pages 60 and above are locked for WRITE access, they do not require a password for READ (i.e., PROT = 0).

I then verified that I can read / write to pages below 60 and read a page above 60, but trying to write to pages above 60 w/o authentication fails as expected. I’m reasonably confident I have the security set up correctly.

Now I’m trying to authenticate so that I can then write to the locked pages but the command I’m using always returns 60 03. This is similar to what Naga found per the previous thread (reproduced below for your convenience).

Has anyone been able to make PWD_AUTH or some variation work on an NTAG21x type card? The command I’m sending is as follows (and I’ve done a lot of permutations..):

FF 00 00 00 07 D4 42 1B xx xx xx xx

Thanks!

===============================================================================

Posted By Nagavardhana
Date October 31, 2017 at 2:49 pm
Subject Reading card data from ACR1255 Android

Hi Richard,

I have used the following command to authenticate NTAG213 card
using ACR1255U

FF 00 00 00 07 D4 42 1B 41 41 41 41

This command returns always 63 00, any suggestions?

Thanks
Naga

[ScottKeymaster]

Hi again Hal!

You will need to use a PCSC 2.0 tansparent session.

Try these APDUs
FF C2 00 00 04 81 00 84 00 // Start Transparent Session
FF C2 00 00 02 84 00 // Turn on the Antenna Field
FF C2 00 02 04 8F 02 00 03 // Switch to ISO 14443-3 Type A
FF C2 00 01 07 95 05 1B XX XX (XX XX == password) // Send PWD Auth

…Write to your tag here…

FF C2 00 00 02 82 00 // Close transparent session

Let us know how you get on.
Regards,
Scott

• This reply was modified 6 years, 5 months ago by  Scott.
• This reply was modified 6 years, 5 months ago by  Scott.

[AmalParticipant]

Hi guys,

Thank you Scott for the information about transparent sessions. It’s like a lightbulb going on.

Forgive my ignorance, but I’m still wondering about the command structure;

FF 00 00 00 07 D4 42 1B xx xx xx xx

I get CLA is FF, INS is 00, P1 and P2 are both 00, and the data payload length is 07… but the PWD_AUTH command is 1B, and the XX represent the 4 byte password.. so where are we getting D4 42 from? What do those signify and how were they arrived at? Would they be different for different commands?

• This reply was modified 6 years, 5 months ago by  Amal.

[AmalParticipant]

I guess I should also ask this.. are the commands outlined above for entering the transparent session specific to a particular reader? I ask because I’m using an OmniKey 5022CL and the documentation seems to indicate the command to enter a transparent session is FF 68 0E 06 01 00 and FF 68 0E 07 01 00 to exit. These commands can be found on page 8-3 (page 69/88) of the following PDF; https://www.hidglobal.com/sites/default/files/resource_files/plt-03092_a.1_-_omnikey_5022_sw_dev_guide.pdf

I assume I follow the commands for my given reader, but am I right to be annoyed that there seems to be no standard for this kind of stuff? Is this really as messy as it seems to be?

[AmalParticipant]

Ok ok.. I’m kinda getting it now I think. According to the documentation for my OmniKey 5022 reader, it should look something like this;

> FF 68 0E 06 01 00 //enter transparent session
> FF 68 0E 03 (10 + n) (Header 10 bytes + Generic Card Command) 00 //send data
> FF 68 0E 07 01 00 //exit transparent session

This sequence assumes that the application has used the PC/SC SCardConnect() function to establish a connection between the calling application and the card. This means the card has already been placed on the reader and the application has established an ICC handle, the card has been “powered up” – air protocol type has been set along with other transmission parameters, and the card is selected and ready to work.

In this case, after entering transparent mode, one can communicate immediately with the card using the transceive command. If the card is on on the reader or the card state is not known, then you will likely have to manually set protocol, speed, etc. For the HID 5022CL those commands are;

> FF 68 0E 00 01 02 //set protocol to 02 (ISO14443A)
> FF 68 0E 01 03 00 00 00 //set speed. might be optional. not sure.
> FF 68 0E 02 01 01 //set field to 01 (on)

[ScottParticipant]

Hi Amal,

Glad you made some progress.
The command I gave above:
FF C2 00 01 07 95 05 1B X X X X
FF C2 00 01 – Transparent Exchange Command
07 – Data Length Lc
95 – Transceive Data Object
05 – Data Length
1B is Password auth
X X X X – Password

Scott

[HalParticipant]

Hey Scott!

Worked perfectly! Thanks again for the fast turn-around, really appreciate it!

[AmalParticipant]

Hey Scott,

So yeah I was able to confirm the HID OmniKey 5022CL has a different set of command values for transparent mode operation. In fact, it also supports slip-streaming transparent commands without having to go into or out of transparent mode at all. If the card is on the reader, selected and ready to go, which is typically handled by the reader automatically, then you just issue the transparent mode tranceive command and it works. The transparent mode transcieve command has a huge 10 byte header that must be sent, but beyond that it’s simple.

For example, if I want to issue the GET_VERSION command to an NTAG2xx, which is 0x60, then the following command is what you send;

> FF 68 0E 03 0B 0F 00 FF FF FF FF 00 00 00 00 60 00

It will return two status bytes, then any data returned for the command sent, then SW1 SW2 bytes.

On a side note, we have a Flomio ACR35-A1 contactless + swipe reader. Any idea if that supports ISO15693 as well as ISO14443A?

[ScottKeymaster]

Very good, glad you made progress.

It is not something we have experimented with with the ACR35, so I’m not sure.
The docs say that it is compliant with the following standards:
o EN 6095/IEC 60950
o ISO 14443
o ISO 18092
o ISO 7811
o CE
o FCC
o RoHS 2
o REACH
o VCCI (Japan)

[AmalParticipant]

Ah yeah, no ISO15693 support for the ACR35.. so I guess we’ll have to stick with this 5022.. which is now giving me fits talking to an ISO15693 tag. Everything I try to send to the chip times out.

Here is the command log. The first command is “enter transparent mode”. The second is supposed to return some data, but the response is a timeout error, which is what I get for every transceive attempt I make. I can successfully use the standard READ BINARY (0xB0) and UPDATE BINARY (0xD6) commands to read and update user memory blocks, but any other commands which require transparent mode just time out.

$ scriptor -p T=0
Trying T=0 protocol
No reader given: using HID Global OMNIKEY 5022 Smart Card Reader [OMNIKEY 5022 Smart Card Reader] (KJ-10333541-1728-000446) 00 00
Using T=0 protocol
Reading commands from STDIN

> FF 68 0E 06 00
< 90 00 : Normal processing.

> FF 68 0E 03 0D 07 00 00 FF FF FF 00 00 00 00 00 B2 04 00
< 06 08 6F 00 : No precise diagnosis.

I have tried increasing the timeout to FF FF FF FF which is several seconds, I’ve tried various flags, sending UID of the tag along with the command, omitting it (with proper flag values), etc. but I only get timeout errors. I believe I must be doing something wrong, but do not know what. I’ve already put in a support request with HID to see if they can help figure out what might be happening.

[ScottKeymaster]

Sorry to hear you’re having those issues, sounds like a complete pain.
Hopefully HID will be able to give you a bit of assistance. Be sure to reach out again if you think there’s anything else we may be able to help with.
I will close this thread as the original purpose is resolved.

[Author]

Posts