Safe Max Java Card APDU Data Command and Respond Size

蓝咒 提交于 2019-12-03 15:20:31

Lc and Le byte can signalize to hold/request upto 0xFF bytes. So for a Case 4 command APDU you have 6(header+lc+le) + 0xFF = 261 bytes. For a maxiumum response you have 256 bytes + 2(Statusword) = 258 bytes. This is what the standard would suggest. However, diffrent hardware tokens might have different implementations so this might not be 100% accurate. If you need more data you need to implement ExtendedLength.

AFAIK the Le field allows 1-256 bytes (the 255 limit is for Lc) citing ISO 7816-3:

Case 2S ⎯ The short Le field consists of C(5) encoding Ne from 1 to 256 ('00' means the maximum, 256)....
....
Case 4S ⎯ ...The short Le field consists of C(6+Nc) encoding Ne from 1 to 256 ('00' means the maximum, 256)....

(And it is in line with your "Response APDU" length of 256+2, maybe it is just a typo)

The 255-byte limit is for the DATA part of "Command APDU". So for the whole non-extended length "Command APDU" the limit should be 5+255+1.

All those limits are precisely defined in ISO 7816-3 -- have a look here.


Beware, that the javacard's APDU buffer might be smaller. From the javadoc of the APDU class:

The buffer length (meaning APDU buffer) must be at least 133 bytes ( 5 bytes of header and 128 bytes of data)

Thus to read incoming data longer than 128 bytes you might need to call APDU.receiveBytes() to fetch the rest of bytes that didn't fit.

The same might apply for sending data (i.e. APDU.sendBytes() might be needed to send longer data).


For application level framing, I am aware of these methods (might be inspirational):

  • ISO 7816-4 (using bit 5 in CLA)

  • Global platform (using the most significant bit of P1 to indicate more blocks/last block for some commands)

  • EMV CPS (STORE DATA command using explicit lengths inside data)

标签
易学教程内所有资源均来自网络或用户发布的内容,如有违反法律规定的内容欢迎反馈
该文章没有解决你所遇到的问题?点击提问,说说你的问题,让更多的人一起探讨吧!