Safe Max Java Card APDU Data Command and Respond Size

Question

What is the recommended data field size in a Java Card APDU ? From Zhiqun Chen's Java Card Technology for Smart Cards: Architecture and Programmer's Guide book, it mentions that Le field allows a max of 255.

Are we to interpret it as follow for the APDU Command:

|<----------------------- 255 Bytes total ------------------------>|
|<- CLA -><- INS -><- P1 -><- P2 -><- Lc -><---- DATA ----><- Le ->|

Thus, if CLA, INS, P1, P2, Lc, Le are all 1 bytes each, we should assume that the we can safely only set 249 bytes into the DATA region ?

For the APDU Response are we to interpret:

|<----------------------- 258 Bytes total ------------------------>|
|<-------------------------- DATA ------------------------><- SW ->|

The response data can safely be set to 256 bytes with 2 bytes of SW and total of a response consisting of data response and SW is 258 bytes ?

What other considerations to safely send and receive data in chunks considering we have to face situations where chaining might not be possible and we have to manually handle data flow ourselves ?

Answer 1

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)

Answer 2

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.