CODEWITHSUNDEEP
javacardapdu
thotheolh
thotheolh

Reputation: 7450

Safe Max Java Card APDU Data Command and Respond Size

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 ?

Upvotes: 6

Views: 3756

Answers (3)

Maarten Bodewes
Maarten Bodewes

Reputation: 94038

The Lc and Le fields encode the maximum data size, Nc and Ne. Nc maxes out on 256 (Lc = 00h, a special case) and Ne maxes at 255 (Le = FFh) for normal length APDU's where the Lc & Le fields are 1 byte each. The Nc does not include the 4 byte header, the Lc encoding or Le encoding. The size specified by Ne doesn't include the 2 byte (16 bit) status word.

It is of course possible to send more data for a particular command. You can use extended length if the card supports it. See ISO/IEC 7816-4 for details.

Extended length uses 16 bit effective Lc and Le sizes. It can support up to 64KiB for Nc (effective part is 0000h) and 64KiB - 1 for Ne (effective part of Le = FFFFh). However, due to the use of signed short, Java Card is limited to Nc = 32KiB - 1 and Ne = 32KiB - 1 when using extended length. Generally you'd run out of buffer space long before that, it depends on the card implementation how this is handled. Extended length also grows the header, Lc and Le overhead.

Command chaining is trickier because you'd have to implement it yourself. It basically sends the same command multiple times, using the chaining bit in the CLA byte to indicate that more commands will follow, until the bit is reset to zero.

Of course you can do anything with the commands yourself. So you can e.g. define a file and write to that using multiple WRITE BINARY commands. How you define these commands is all up to you.

I'll not go into maximum sizes when secure messaging is used. It makes for some very interesting calculations, especially if BER encoding is used to implement secure messaging.

Upvotes: 0

Paul Bastian
Paul Bastian

Reputation: 2647

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.

Upvotes: 2

vlp
vlp

Reputation: 8116

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)

Upvotes: 7

Related Questions