Problem with ACR122U firmware release 2.13 and writing AES encrypted files.

[GoogleCodeExporter]

What steps will reproduce the problem?
1. Create an application with AES encryption on DESFIRE EV1 4k card and 
authenticate afterwords.
2. Create a file with AES encryption inside the application.
3. Write data into this file by using mifare_desfire_create_std_data_file().

Expected output of the method mifare_desfire-create_std_data_file is simply the 
amount of data written to the card. Instead the corresponding function " 
returns -1. I also tried mifare_desfire_create_std_data_file_ex with parameter 
cs set to MDCM_ENCYPHERED, which had the same effect.
I'm using libfreefare 1.3.4 and libnfc 1.7.0 under Windows 7 64 Bit, both 
compiled using MINGW64. The executables and libraries are 32 Bit versions. The 
error occurs with libusb as well as using the PC/SC interface. As reader I'm 
using several ACR122U-A9. Devices with firmware 2.13 are affected by the 
described issue, while devices with firmware 2.10 are working properly (file is 
written without any problems). I will invest more time in further 
investigations. Does somebody have this problem too? I could also provide a 
code snippet if needed.
If I write a file without encryption (MDCM_PLAIN), it also works with firmware 
2.13. So it seems to depend on the communcation settings.

Bye, Eike

Original issue reported on code.google.com by chevi...@gmail.com on 7 Nov 2013 at 1:30

[GoogleCodeExporter]

[deleted comment]

[GoogleCodeExporter]

Hello,

okay, here are further details. Despite my first suspicion the problem may 
arise  one step earlier, that is to say when the file is created. I compiled 
libnfc with debug to get the transacted APDUs.

Here the sequence with firmware 2.10:

debug   libnfc.driver.acr122_pcsc   TX: ff 00 00 00 10 d4 40 01 90 cd 00 00 07 01 
03 00 00 20 00 00 00 
debug   libnfc.driver.acr122_pcsc   RX: d5 41 00 e6 72 1c 6e 84 1e cc da 91 00 90 
00 

Here the corresponding line with Firmware 2.13, please note the different 
content in the answer (which might be okay):

debug   libnfc.driver.acr122_pcsc   TX: ff 00 00 00 10 d4 40 01 90 cd 00 00 07 01 
03 00 00 20 00 00 00 
debug   libnfc.driver.acr122_pcsc   RX: d5 41 00 68 4d f0 f0 bc d1 0b c1 91 00 90 
00 

libfreefare tells me by returning a value of 0 in both cases that the file has 
been created successfully - that could be indeed verified by using a different 
reader and software, the file has actually been created logically. But after 
completing the file creation the reader seems to stop responding, because no 
further commands are sent to the reader by libfreefare, although I executed the 
succeeding command mifare_desfire_create_std_data_file(), which then returns 
with returncode -1. 

The question is: When is the debug of libnfc generated? I still believe that in 
the end the reader stops responding when it receives the following sequence 
(recording originates from firmware 2.10):

debug   libnfc.driver.acr122_pcsc   TX: ff 00 00 00 3f d4 40 01 90 3d 00 00 36 01 
00 00 00 20 00 00 6e 8f 77 6a b9 aa 64 5d 04 19 1b 9c 34 8e a5 d9 4a 8a 3b 42 
1e 21 dd 41 c6 6f 61 88 2b 17 5b d9 b3 83 9c c6 b4 d9 e1 23 3e 22 1c f6 df 12 
d1 00 

I will try to get more debug out of libnfc to track down this issue.

Thank you and best regards,

Eike

Original comment by chevi...@gmail.com on 8 Nov 2013 at 9:33

[GoogleCodeExporter]

Hi
If you want to have more traces at usb level you can also try sniff-pn532:
https://code.google.com/p/nfc-tools/source/browse/trunk/dev-tools/sniff-pn53x.sh

It will tap directly into the usb stack to recover the same frames but you can 
also get more insight on the usb protocol itself.
it has also helpful basic parsing of the pn532 commands so it's a bit easier to 
follow.
Note that sniffed frames are truncated so don't be surprised if it looks like 
you're missing bytes.

Thanks for tracking down that problem! as you've both fw in your hands you're 
unfortunately almost on your own to dig into that issue.

Phil

Original comment by yob...@gmail.com on 8 Nov 2013 at 10:03

[GoogleCodeExporter]

Hello,

I made some traces using USBlyzer under Windows. Attached you'll find the 
results in csv-format. At the moment I'm not able to see any difference in the 
answer of both firmware versions to the file write command.

Bye, Eike

Original comment by chevi...@gmail.com on 11 Nov 2013 at 8:37

Attachments:

• success.csv
• failure.csv

[GoogleCodeExporter]

Hello,

attached the traced data in a more readable form (Excel format). Please note 
the differences in the data sent (!) by libnfc listed in the sequence numbers 
414 and above in firmware 2.10 (respective sequence numbers 406 and above in 
firmware 2.13). For what reason libnfc sends telegrams of different sizes (25 
bytes for 2.10 versus 18 bytes for 2.13)? Is this a problem with the preceding 
answer? I have to work myself into DESFire and the corresponding APDUs in order 
to analyse the data traffic between host and reader. Any help would be 
appreciated.

Bye, Eike

Original comment by chevi...@gmail.com on 11 Nov 2013 at 9:05

[GoogleCodeExporter]

Hello,

here's the promised Excel file...

Bye, Eike

Original comment by chevi...@gmail.com on 11 Nov 2013 at 9:06

Attachments:

• usb_traces.xlsx

[GoogleCodeExporter]

Hello,

in the end, I got it: Following the sequence 04 00 00 FF in the outgoing 
package stands some kind of sequence number. Considering this, the firmware 
2.13 will answer to this particular DESFure command 0x3F (create file) in case 
of AES encryption with a wrong sequence number. The sequence number is always 
decremented by 1! For example:

Beginning of outgoing command:
6F 44 00 00 00 00 8B 04 00 00 FF 00 00 00 3F D4 
                  ^^

Beginning of incoming answer:
80 07 00 00 00 00 8A
                  ^^

I was able to verify this issue by comparing the messages to the data transfer 
of firmware 2.10, where the sequence numbers of request and answer are always 
identical.
So in my opinion the firmware 2.13 is definitly broken in this aspect. 
Furthermore, this issue resembles a problem mentioned in another forum:

http://musclecard.996296.n3.nabble.com/ACR122U-response-frames-contain-wrong-seq
uence-numbers-td5002.html

In order to provide a patch for libnfc, someone has to check the firmware 
version of the connected ACR122U reader and, after sending particular commands, 
accept answers with a decremented sequence number. I'll take a look into the 
corresponding source files in the next two weeks. If anyone could provide a 
patch for libnfc quicker, it would be very apprectiated! Thanks in advance!
To ACS: Please provide a firmware downgrade utility! I was happy with release 
2.10!

Bye, Eike

Original comment by chevi...@gmail.com on 11 Nov 2013 at 9:33

[GoogleCodeExporter]

Hi Eike, 

Thank you for your findings. We are looking into this issue and contact you 
regarding the resolution. 

Regards, 
ACS

Original comment by Advanced...@gmail.com on 11 Nov 2013 at 10:02

[GoogleCodeExporter]

Hello,

one last addition: IMHO this issue can't be fixed in libnfc (just checked it), 
because the sequence number is already processed one stage lower, that is to 
say on USB driver level. The decreased sequence number seems to be responded in 
all cases when the APDU is larger than 54 bytes (according to Mr. Eugene 
Crosser, see the link in my last post to the corresponding thread). This is 
neither a failure in libfreefare nor in libnfc, but I think this information 
should be kept for providing an optional patch for libnfc warning of issues in 
combination with f/w release 2.13.

Kind regards,

Eike

Original comment by chevi...@gmail.com on 12 Nov 2013 at 9:22

[GoogleCodeExporter]

Thanks for this thorough analysis!
Could you provide such warning patch?
I'll be happy to apply it to the repository.

Original comment by yob...@gmail.com on 12 Nov 2013 at 9:47

• Added labels: Type-Other, OpSys-All, Usability
• Removed labels: Type-Defect