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
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):
