NFC APDU READ命令的性能调整 [英] NFC APDU READ command performance tuning

问题描述

我正在使用APDU命令从DESFire卡读取数百个字节.

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

数据应用程序已通过身份验证，并且响应MAC已完成.

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

我提交了一系列READ_DATA命令(0xBD)，每个命令检索54个字节+ MAC，同时增加每个命令的读取偏移量.

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

如果我对ADDITIONAL_FRAME(AF)使用较长的READ而不是多次顺序读取，此操作会更快吗?

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

我了解到，简单的AF为1字节，而完整的READ DATA命令为8字节，因此将传输的字节数减少了约10％. 但是，使用AF是否会带来更多的性能优势，例如因为卡片所需的处理更少?

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?

之所以这样问，是因为当理论极限为424kbit/s时，我只能获得约220kbit/s的有效传输速率.请参阅我对此的问题

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

推荐答案

(想写评论，但时间很长...)

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

我将使用附加框架(AF)"方式，其原因如下:

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

• 除了在命令中保存的上述7个字节外，您还在所有响应中保存了4个MAC字节(当然是最后一个)

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

每次读取54个字节时，都浪费了MAC 2个零字节的填充，这可能已经作为数据MAC了(由8个DES块大小决定).在"AF方式"中，只有一个MAC运行覆盖了所有数据，因此这里不会发生这种情况

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

您没有强制执行实际的帧大小.由阅读器和卡来选择正确的帧大小(在此我不能100％地确定DESFire如何处理ISO 14443-4链接和FSD)

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)

如果我的想法(至少部分地)是正确的，那么这些观点在您的情况下仅相差9毫秒.但是在另一种情况下，它们可能会带来更多收益.

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.

其他说明:

• 我将从基准中排除SELECT APPLICATION和AUTHENTICATE并分别进行测量.这取决于您，但我要说的是，它们仅会干扰所需的原始"数据传输测量

• 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!

这篇关于NFC APDU READ命令的性能调整的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！