NFC APDU READ command performance tuning

问题:

I am reading several hundred bytes from a DESFire card using APDU commands.

The data application is authenticated, and the response MAC'ed.

I submit a series of READ_DATA commands (0xBD), each retrieving 54 bytes+MAC while increasing read offset for each command.

Will this operation go much quicker if I use a long READ with ADDITIONAL_FRAME (AF) instead of many sequential reads?

I understand that a simple AF is 1 byte vs 8 bytes for a full READ DATA command, thus reducing the number of bytes transferred by ~10%. But will use of AF give additional performance benefits, for example because of less processing needed by the card?

I am asking this since I am getting only ~220kbit/s effective transfer rate when the theoretical limit is 424kbit/s. See my question on this here

回答1:

I modified my reads to use ADDITIONAL FRAME.

This reduced the total bytes sent+received from 1628 to 1549 bytes, a 5% reduction.

The time used by tranciecve() was reduced from 602ms to 593ms, a 1.5% reduction.

The conclusion is that use of AF will not give additional performance other that the reduced time for bytes transfered.

The finding also indicates that since the time was reduced by a much lower factor than the data reduction, there must be operations that introduce significant latency that is not dependent on the data trancieved, but ReadFile is not the one.

Authenticate, SelectApplication or ReadRecord may be significantly more expensive than the time used for data transfer.

回答2:

(Wanted to write a comment, but it got quite long...)

I would use the ADDITIONAL FRAME (AF) way, some reasoning follows:

• in addition to the mentioned 7 bytes saved in the command, you save 4 MAC bytes in all of the responses (but the last one, of course)

• every time you read 54 bytes, you wastefully MAC 2 zero bytes of padding, which might have been MACed as data (given by DES block size of 8). In the "AF way" there is only a single MAC run covering all the data, so this does not happen here

• you are not enforcing the actual frame size. It is up to the reader and the card to select the right frame size (here I am not 100% sure how DESFire handles the ISO 14443-4 chaining and FSD)

• some readers can handle the AF situation on their own and (magically?) give you the complete answer (doing the AF somehow in their firmware -- I have seen at least one reader doing this)

If my thoughts are (at least partially) correct, these points make only 9ms difference in your scenario. But under another scenario they might make much more.

Additional notes:

• I would exclude the SELECT APPLICATION and AUTHENTICATE from the benchmark and measure them separately. It is up to you, but I would say that they only interfere with the desired "raw" data transfer measurement

• I would recommend to benchmark the pure "plain data transfer" mode which is (presumably) the fastest "raw" data transfer possible

Thank you for sharing your results, not many people do so...Good luck!