Hello, I am sending some byte array by portions of 255 bytes to my on-card Applet using a sequence of APDU command-response operations. I just wanted to know, in case there is any possibility to make on-side chaining: send some sequence of APDU commands and receive only one response from the applet after the last portion of data received.
Best regards,
Eve
It would be great, if anyone could explain APDU chaining tome. That question i defined after reading the ISO 7816-4, where i found out some ideas about the chaining possibilities. Those where defined for the work with th card, but not with proprietary sleeted applet.
Best regards,
Eve
According to ISO 7816-4 the chaining possibilities are
- Extended APDU --> up to 65k data field
- Command chaining --> ICCD responds after each APDU
Your requirement would fit only to extended APDU. Java Card adopts only a certain class of the APDU structure from ISO 7816-4, which does not allow extended APDU: JC 2.2.1 API, javacard.framework.APDU (p. 44) ..
This class does not support extended length fields.
..
This is one of the reasons it won't work with a card compliant to Java Card. The other reason are the fixed constants for the ISO7816 interface (e.g. javacard.framework.ISO7816.OFFSET_CDATA, which is 5 --> extended length field not possible).
But there is an Extended APDU interface.
But I have JCOP card, compliant with Java Card specifications 2.2.1. Thre is an interface for extended APDU's, that is not impelmented, but can be in case extended APDU's are supported.
How can i know, if my card supports extended APDU? Because ATR, returned by the JCOP card, doesn't seem to be very informative for me, it's first historical byte is not '00'.
So, lexdabear, you want to say, that there is no other possibility to send string of bytes, that are is too long for APDU buffer. except the handling command-response pair after the every portion sent?
Thanks for your help,
Best regards,
Eve
I think you mix up the 2.2.1 and 2.2.2 specification. JCOP is compliant to JC 2.2.1, and there is nothing mentioned about the extended APDU interface. This optional feature you can find in JC 2.2.2 . As far as I know there is no JC 2.2.2 implementation out yet.
With JC there is no possibility to send a bytes than with APDU's limited to a maximum size of 261 bytes and at least 133 bytes. The lower bound is HW dependant (IO buffer). So if you e.g. want to send 40kb, you need to do it in 160 X 255 byte chunks, receiving 160 responses for each command APDU.
@ lexdabear
My current implementation of application works just like that: portion-by-portion sending with response receiving and check9000 method call on terminal side each time. I just thought that time of such kind of sending could be reduced a bit, because it affects the performance time of my on-card algorithm.
And does JCOP support chaining option? (I think no, because even during the loading of cap file command-response pairs are used). But are there any other cards that implemented those possibilities? Or implemented the usage of extended APDU? Or latter exist only in theory?
Thanks for your help, lexdabear.
I really appreciate it.
Best regards,
Eve
