topic Re: NFC NTAG213 READ_SIG Originality Signature Verification Using ACS ACR1552U NFC USB Reader in NFC

NFC NTAG213 READ_SIG Originality Signature Verification Using ACS ACR1552U NFC USB Reader

ChiChi — Mon, 17 Jun 2024 13:32:23 GMT

Hi,

I am using the ACS ACR1552U NFC USB reader to read the originality signature from NTAG213 tags. The reading of the data is successful but the actual signature data does not appear to be correct. I'll try to explain in more detail.

Firstly, please note that I have confirmed my signature verification should be correct as per the following post: Demo for Originality Signature Verification - NXP Community. This was checked by executing the example ECDSA verification algorithm against other known NTAG213 UIDs and signatures, e.g.:

For my specific setup, I'm using an ACS ACR1552U NFC USB reader which works nicely for reading/writing from/to the manufacturing data, user memory data, and the dynamic lock bytes. I used the following ACR1552U commands for general read/write, respectively:

As for reading the originality signature, this was slightly more complicated. I had to use the Transparent Exchange command to passthrough the READ_SIG command to the NTAG213, as shown below.

Transparent Exchange command (ACR1552U):

READ_SIG command (NTAG213):

The combined PDU is as follows (for a C# implementation):

When the above method is called, the following 36 signature bytes (for a tag with UID 04-90-EB-42-97-12-90) was returned (in hexadecimal format):

C0-03-00-90-00-14-82-90-33-A7-18-1A-B2-CF-59-4D-03-BC-D1-22-81-A9-BA-D5-73-14-33-90-46-88-BE-7B-41-5D-90-00

I was expecting 32 bytes, possibly with a couple of response codes at the end but the ACR1552U datasheet does not make this clear.

Anyhow, I tried to verify the above signature using the first 32 bytes and the result was a fail. I tried again by dropping the first byte (e.g. 0xC0) and verifying the next 32 bytes but the result was also a fail. I repeated this until the last 32 bytes remained. In all cases, the verification result was a fail.

Hoping someone here can spot my mistake and point me in the right direction. All feedback appreciated.

Thank you in advance,
Chi

Re: NFC NTAG213 READ_SIG Originality Signature Verification Using ACS ACR1552U NFC USB Reader

EduardoZamora — Mon, 17 Jun 2024 22:10:33 GMT

Hello @ChiChi

Hope you are doing well.

Please, consider that our support scope is limited to the usage of our NFC Readers, our recommended NFC Reader Library and Software Tools such as RFIDDiscover.

Since this implementation is running on a third-party reader device, I will recommend you please contact the manufacturer for more information on its commands and responses, perhaps you may need to take care, for example, of the endianness of the data.

Regards,
Eduardo.

Re: NFC NTAG213 READ_SIG Originality Signature Verification Using ACS ACR1552U NFC USB Reader

ChiChi — Wed, 19 Jun 2024 20:02:44 GMT

Hi Eduardo,

Thank you for your response and after some digging, I think I have tracked down the root cause of my issue. In case anybody else come across the same problem, I shall document my findings here.

First thing I tried was to remove my software from the equation and I did so by using the NFC reader manufacturer's own tool which supports command scripting. The specific tool I used was the "ACS Script Tool 5" running in a Windows 11 environment.

The specific command I used was: FF C2 00 01 04 95 02 3C 00 00. This corresponds to the Transparent Exchange command in transceive mode. And the NXP NTAG213 command being transceived is 3C 00, which corresponds to the READ_SIG custom command.

Below is a screenshot of the observed result after running the command:

To highlight the issue, I have underlined the signature payload bytes. The other bytes in the response indicates that the command was executed successfully (according to the following List of APDU Responses), e.g.:

The second thing I did was to remove the ACR1552U USB NFC reader from the equation. Unfortunately, I did not have access to any other NFC readers other than a smart phone. Nevertheless, it was really just to confirm that the NTAG213 NFC tag itself is behaving correctly. Indeed it does as shown in the next screenshot:

The above findings have been reported to ACS but I have not yet received any responses to confirm or deny whether there is an issue.

Lastly, the AR1552U NFC reader that I am using has the following configuration:

Hopefully this is useful to someone who is also going down a rabbit hole.

Cheers,
Chi

P.S. For completeness, here is the signature verification result (C# implementation):

Re: NFC NTAG213 READ_SIG Originality Signature Verification Using ACS ACR1552U NFC USB Reader

ThGTgs — Mon, 21 Oct 2024 15:51:38 GMT

Hello Chi,

we have stumbled over the "3 missing Bytes at the end of the response" topic as well with our ACS1552U reader for literally any command that we are sending to NFC Forum Type 2 Tags (like the NTAG213) and have found the following fix:
For NFC Type 2 Tags (like NTAG213), when sending a "Transparent Exchange" command, you need to
1) Start a Transparent Session,
2) Change/set the protocol to ISO/IEC 14443-A, Layer 3,
and only after that:
3) Send the "Transparent Exchange" command,
4) Close the Transparent session.
Then the last 3 Bytes of the response from the tag will no longer get swallowed by the ACS1552U reader.

I.e.:
1) FF C2 00 00 81 00 (Start Transparent Session)
2) FF C2 00 02 04 8F 02 00 03 (Set protocol to "ISO/IEC 14443-A, Layer 3)
3) FF C2 00 01 04 95 02 3C 00 00 (Send "Read Signature" command - then in the answer, the last three bytes are no longer missing)
4) FF C2 00 00 82 00 (End/Close Transparent Session)

Hope this helps with the ACS1552U reader.
On the signature part of the question, I didn't look into it in detail.

Best regards
Thomas