NTAG-424: Getting 917E in reading proprietary file

[gopesh]

Hi Experts,

I am working on an Android NFC application that communicates with an NTAG 424 card using the ISO-DEP protocol to perform authentication and read operations. I'm implementing AES authentication following the EV2 protocol and am facing an issue with the ReadData command. Specifically, I am receiving a 0x917E error response when sending the ReadData command to the card, indicating a possible length error.

I've used the AES-CMAC algorithm to generate the session keys and encrypt the command header. I have cross-referenced my implementation with examples available from similar projects, but the problem persists.

Below is a detailed breakdown of my implementation, logs, and the steps I've taken to address the issue.

Current Implementation Overview:

1. Authentication Process:

   • The authenticateAndReadData method sends the AuthFirstPart1 and AuthPart2 commands successfully.
   • I generate the random numbers RndA and RndB and derive session keys (sessionKeyEnc and sessionKeyMac) using AES-CMAC.
   • The authentication completes successfully, and the card returns 0x9100 for Auth Part 2, indicating successful authentication.

2. Constructing the ReadData Command:

   • I prepare the command header and encrypt it using sessionKeyEnc.
   • I calculate the CMAC for the constructed command using sessionKeyMac.
   • I construct the final read command by combining the encrypted command header and truncated CMAC code.

Observed Behavior and Logs:

Here are the detailed logs for my current execution flow:

Logs:

Auth Part2 Response: F51F388CEC802F150DBC8763B90EFEB48E4B92686F9CBB2F8E33F6A2EA6B96CA9100 Decrypted Auth Part2 Response: C7E7F9B500F557A397093FCA1C99195B8FA84A1F000000000000000000000000 TI: C7E7F9B5 RndA' from Response: 00F557A397093FCA1C99195B8FA84A1F PDCap2: 000000000000 PCDCap2: 000000000000 RndA Verification Successful: 00F557A397093FCA1C99195B8FA84A1F SV Label Prefix: A55A00010080 Final SV after RndA[7..0] Copy: A55A000100801F00FFA75EACB0BBCFD1CA6C35BBC7B5EB34CA1C99195B8FA84A Session Key ENC: AE5D18EECB88EE6953CDAD880C37DCAD Session Key MAC: 2A932217D02F938DE6AF0ECB94D8FA44 Original Command Header: 03000000000000 Encrypted Command Header: FAA78E21A4393A509E699D965665DB9E MAC Input Data: AD0000C7E7F9B503000000000000 Padded Data for CMAC: AD0000C7E7F9B503000000000000000080000000000000000000000000000000 Truncated CMAC Code: 2AC226F74BB83765 Final Read Command with CMAC: 90AD00000FFAA78E21A4393A509E699D965665DB9E2AC226F74BB8376500 Read Response: 917E READ FAILED: 917E

Analysis:

• I ensured the Lc value is fixed to 0x0F, as the total length of the encrypted command header (16 bytes) plus the truncated CMAC (8 bytes) equals 24 bytes (0x18 in hexadecimal), which seems correct.
• Despite aligning the structure, the card continues to return 0x917E (Length error), suggesting that the card might expect something different in the command structure.

What I’ve Tried:

1. Adjusting Lc to 0x0F to match the known working command length.
2. Comparing the generated Session Key ENC and Session Key MAC with reference implementations.
3. Verifying the padding for both the MAC input data and the encrypted command header.

Despite these checks, the read command still fails with 0x917E.

Questions:

1. Could the Session Key ENC or Session Key MAC derivation be incorrect in any way? My implementation uses AES-CMAC as specified in the NTAG 424 documentation, but I want to confirm if there might be nuances in the calculation I'm missing.

2. Is there a specific requirement for constructing the MAC input data that might not be immediately obvious? For instance, should the Command Header be constructed differently or padded differently when included in the MAC input?

3. Does the Le byte (expected response length, currently 0x00) impact the length error in any way? In reference implementations, Le is often 0x00. Could there be situations where it needs to be explicitly set?

4. Are there any known issues with the NTAG 424 card interpreting the ReadData command in specific configurations?

5. Could the issue be related to how the 0x80 padding is applied? I apply 0x80 followed by 0x00 to pad to a multiple of 16 bytes. Could the padding length or placement cause an issue with the MAC calculation?
   
   
   Can you suggest, how to achieve this implementation without taplinx sdk ?
   
   

Thank you for your support!

---

[gopesh]

Hi @EduardoZamora 

Above issue is fixed..Now i am getting 911E, which mean integrity error:

here my logs

2024-09-27 13:02:18.339 25740-25779 NFCManager com.remoteplanet.keyapp D Select NDEF Response: 9000
2024-09-27 13:02:18.339 25740-25779 NFCManager com.remoteplanet.keyapp D Auth First Part1 Command: 9071000002020000
2024-09-27 13:02:18.354 25740-25779 NFCManager com.remoteplanet.keyapp D Auth First Part1 Response: D4DF5723B5253C6880FEA07039830C3491AF
2024-09-27 13:02:18.354 25740-25779 NFCManager com.remoteplanet.keyapp D Encrypted RndB: D4DF5723B5253C6880FEA07039830C34
2024-09-27 13:02:18.354 25740-25779 NFCManager com.remoteplanet.keyapp D Decrypted RndB: 39D23F55F861BC5250AD3893A8D8A9BC
2024-09-27 13:02:18.355 25740-25779 NFCManager com.remoteplanet.keyapp D Generated RndA: 9EC2C944DA86CCB74C69F04DC54DD190
2024-09-27 13:02:18.356 25740-25779 NFCManager com.remoteplanet.keyapp D Encrypted RndA||RndB': 27C374C49E09EE8B3C9EEEAF5548AF5641826D9CC656195759E8111446127508
2024-09-27 13:02:18.356 25740-25779 NFCManager com.remoteplanet.keyapp D Auth Part2 Command: 90AF00002027C374C49E09EE8B3C9EEEAF5548AF5641826D9CC656195759E811144612750800
2024-09-27 13:02:18.373 25740-25779 NFCManager com.remoteplanet.keyapp D Auth Part2 Response: 7EFDA9806F5A1E58CBFDCCFD0DD4F80F7D07BC9B86616D1FD1246CDCCB3268149100
2024-09-27 13:02:18.373 25740-25779 NFCManager com.remoteplanet.keyapp D Decrypted Auth Part2 Response: 9397D23AC2C944DA86CCB74C69F04DC54DD1909E000000000000000000000000
2024-09-27 13:02:18.373 25740-25779 NFCManager com.remoteplanet.keyapp D TI: 9397D23A
2024-09-27 13:02:18.374 25740-25779 NFCManager com.remoteplanet.keyapp D RndA' from Response: C2C944DA86CCB74C69F04DC54DD1909E
2024-09-27 13:02:18.374 25740-25779 NFCManager com.remoteplanet.keyapp D PDCap2: 000000000000
2024-09-27 13:02:18.374 25740-25779 NFCManager com.remoteplanet.keyapp D PCDCap2: 000000000000
2024-09-27 13:02:18.374 25740-25779 NFCManager com.remoteplanet.keyapp D RndA Verification Successful: C2C944DA86CCB74C69F04DC54DD1909E
2024-09-27 13:02:18.374 25740-25779 NFCManager com.remoteplanet.keyapp D SV Label Prefix: A55A00010080
2024-09-27 13:02:18.374 25740-25779 NFCManager com.remoteplanet.keyapp D RndA[7..0]: 4C69F04DC54DD190
2024-09-27 13:02:18.375 25740-25779 NFCManager com.remoteplanet.keyapp D Final SV after RndA[7..0] Copy: A55A000100809EC274FA58956CF1BC5250AD3893A8D8A9BC4C69F04DC54DD190
2024-09-27 13:02:18.375 25740-25779 NFCManager com.remoteplanet.keyapp D SV Label Prefix: 5AA500010080
2024-09-27 13:02:18.375 25740-25779 NFCManager com.remoteplanet.keyapp D RndA[7..0]: 4C69F04DC54DD190
2024-09-27 13:02:18.376 25740-25779 NFCManager com.remoteplanet.keyapp D Final SV after RndA[7..0] Copy: 5AA5000100809EC274FA58956CF1BC5250AD3893A8D8A9BC4C69F04DC54DD190
2024-09-27 13:02:18.376 25740-25779 NFCManager com.remoteplanet.keyapp D SV1:: A55A000100809EC274FA58956CF1BC5250AD3893A8D8A9BC4C69F04DC54DD190
2024-09-27 13:02:18.376 25740-25779 NFCManager com.remoteplanet.keyapp D SV2:: 5AA5000100809EC274FA58956CF1BC5250AD3893A8D8A9BC4C69F04DC54DD190
2024-09-27 13:02:18.378 25740-25779 NFCManager com.remoteplanet.keyapp D Session Key ENC: C8C49C59175DF3644BAB08DBC991582728D919E4049A2000AA85450B93CFDD3C
2024-09-27 13:02:18.378 25740-25779 NFCManager com.remoteplanet.keyapp D Session Key MAC: 872053773BD638F50BBFA3AA878CCE6E28D919E4049A2000AA85450B93CFDD3C
2024-09-27 13:02:18.378 25740-25779 NFCManager com.remoteplanet.keyapp D Original Command Header (Unencrypted): 03000000000000
2024-09-27 13:02:18.379 25740-25779 NFCManager com.remoteplanet.keyapp D MAC Input Data: AD00009397D23A03000000000000
2024-09-27 13:02:18.379 25740-25779 NFCManager com.remoteplanet.keyapp D Padded Data for CMAC: AD00009397D23A030000000000008000
2024-09-27 13:02:18.379 25740-25779 NFCManager com.remoteplanet.keyapp D Final CMAC Code: 76DFCC8E6B90ED5F23072616DA744903
2024-09-27 13:02:18.379 25740-25779 NFCManager com.remoteplanet.keyapp D Truncated CMAC Code: DF8E905F07167403
2024-09-27 13:02:18.380 25740-25779 NFCManager com.remoteplanet.keyapp D Final Read Command with Unencrypted Data and Correct CMAC: 90AD00000F03000000000000DF8E905F0716740300
2024-09-27 13:02:18.380 25740-25779 NFCManager com.remoteplanet.keyapp D Constructed Read Command: 90AD00000F03000000000000DF8E905F0716740300
2024-09-27 13:02:18.388 25740-25779 NFCManager com.remoteplanet.keyapp D Read Response: 911E
2024-09-27 13:02:18.388 25740-25779 NFCManager com.remoteplanet.keyapp D READ FAILED: 911E

how to verify that where is the issue ?

and pls suggest how to fix it ?

Thanks

[EduardoZamora]

Hi,

I just sent you a private Community message.

Regards,
Eduardo.

[EduardoZamora]

Hello @gopesh

Hope you are doing well.

Let me share my insights:

CMAC and Encryption Session Keys can be generated as in the example from NTAG 424 DNA and NTAG 424 DNA TagTamper features and hints, Table 20.

0x917E should be purely related to the expected length of the APDU being sent, and not to an erroneous data. I understand from your log and your analysis that you are setting Lc to 0x0F. Please, try setting Lc field to encrypted command header length + CMAC length; this is, 0x18 instead of 0x0F. Le byte does not impact on the length calculation.

According to NTAG 424 Data Sheet, padding is applied by adding 80h followed, if required, by zero bytes until a string with length of a multiple of 16 byte is obtained, so this should not suppose an inconvenience.

Regards,
Eduardo.