6

I'm interested in ISO7816-4 compliant first interindustry APDUs. What is the maximum length such an APDU can/is allowed to have?

The longest APDU I can think of should be an extended length ISO case 4 APDU. This means we have 4 Bytes of header, 3 Bytes for extended Lc and 2 Bytes for extended Le. Additionally the Lc field allows to address a total of 2^16 Bytes. Considering this worst case APDU a 2-Byte large short value obviously would not suffice to address the offsets of the last bytes.

Is there a best practise for this problem or do I miss anything?

Thomas Lieven
  • 371
  • 4
  • 14

1 Answers1

7

Your calculations are correct (except that the maximum size of Nc is 64Ki - 1 in bytes, not 64Ki. So the maximum command APDU would be 4 + 3 + (64Ki - 1) + 2 = 64Ki + 8. Note that the amount of data that can be returned is 64Ki, with two bytes for the status word the maximum size of the response APDU is 64Ki + 2. Many smart cards however will limit the amount of data that can be send and returned by the smart card. The ISO 7816-4 2013 specifications contain methods to indicate the "buffer sizes" of the smart card and smart card applications.

In Java Card the limit is set to 32 Ki - 1 for the simple reason that larger values cannot be stored inside a signed short. It would be required to stream the bytes from EEPROM to get anywhere near that size, the APDU buffer will be much smaller than that.

Now with regard to the "offset of the last bytes" I presume you are talking about reading file structures from a Smart card. Those are read out using the READ BINARY APDU (B0) command, which actually contains an offset in P1/P2. READ BINARY with odd INS (B1) can be used for offsets higher than 32Ki. With these commands you can address files that are larger than the maximum amount of memory of most smart cards.

The same goes for the UPDATE BINARY commands, of course. So reading/writing bytes over the 64Ki limit is not an issue. Determining the file size and reading up to the exact end of the file however is more "fun" than you would imagine however.

Maarten Bodewes
  • 90,524
  • 13
  • 150
  • 263
  • I was able to follow your (64Ki - 1)-argument - Lc is not allowed to be set to all zeros. – Thomas Lieven Oct 04 '13 at 07:31
  • As for the "offset of the last bytes" I was just wondering how to address e.g. the Le-field or the last Nc bytes of such a large APDU. If the card however can limit/determine the size of accepted APDUs and even is able to indicate this then this should not be a problem. Part of my confusion was due to the fact that ISO7816 specifies Lc as short values but the length of BER-TLV structures that are transported within the data field may be well into the integer size class also according to ISO7816. Apparently there seems to be another way for handling large BER-TLV structures. – Thomas Lieven Oct 04 '13 at 07:39
  • TLV structures are normally only of interest for *record* structures on the card, representing objects. Furthermore they are used for handling parameters (DO's) in the command and response structures themselves. Those are normally not that big. TLV structures within files are not of interest. Up to I think ISO 7816-4 2005 the maximum size of the length was 64Ki - 1. This may have changed to allow for more flexible handling of the length parameter (in BER, even small lengths may be represented by up to 5 bytes, e.g. 8400000001 is perfectly valid), what is used depends on the implementation. – Maarten Bodewes Oct 04 '13 at 09:23