Secure Max Java Card APDU Data Command and Respond Size

Question

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

We must interpret this as following the APDU command:

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

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

For an APDU response, we need to understand:

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

Can the response data be safely set to 256 bytes with 2 bytes of SW and the whole response consisting of the data response, and SW - 258 bytes?

What other considerations are safe to send and receive data in chunks, given that we have to deal with situations where the chain may not be possible, and we have to manually process the data stream manually?

Answer 1

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

Answer 2

AFAIK Le field allows using 1-256 bytes (255 limit for Lc ), referring to ISO 7816-3:

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

(And this matches your "Response APDU" with a length of 256 + 2, maybe it's just a typo)

A 255 byte limit for the DATA "Command APDU" part. Thus, for the entire unexpanded length of the Command APDU, the limit should be 5+255+1 .

All of these limitations are precisely defined in ISO 7816-3 - see here.

---

Beware that javacard APDU buffer may be smaller. From the javadoc class of the APDU :

The buffer length (i.e. APDU buffer) must be at least 133 bytes (5 header bytes and 128 data bytes)

Thus, to read incoming data longer than 128 bytes, you may need to call APDU.receiveBytes() to retrieve the rest of the bytes that did not fit.

The same can be used to send data (i.e. APDU.sendBytes() may be needed to send longer data).

---

For the application level framework, I know about these methods (maybe inspirational):

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

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

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