Max length of ISO7816 APDU and addressing offsets?

Question

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?

Answer 1

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.