CODEWITHSUNDEEP
javacard
FaST4
FaST4

Reputation: 279

JavaCard T=0 handing of case 2 APDUs (0x61XX (GET RESPONSE) vs 0x6CXX)

I have tested several javacards (Feitian D11CR, Infineon JTOP, G&D Smart Cafe) over T=0 and here is what I have observed.

If applet returns some data in case 4 APDU, the JCRE signals with SW 0x61XX that there is data available which terminal should retrieve using GET RESPONSE APDU.

However, if applet returns some data in case 2 APDU and Le does not match number of bytes to be returned, JCRE signals with error SW 0x6CXX, instructing that the same C-APDU has to be resent with correct Le.

For legacy reasons there are terminals who know how to handle 0x61XX, but fail to handle 0x6CXX response. Is there a way how to force JCRE to handle case 2 APDUs using 0x61XX (GET RESPONSE) method?

Upvotes: 1

Views: 1685

Answers (2)

vlp
vlp

Reputation: 8116

This behavior is given by the T=0 protocol where the length of data bytes transmitted must be fixed from the beginning of the TPDU exchange (i.e. the interface device decides it) -- in contrast to T=1/T=CL where the response length is left open for the card to decide.

Which causes trouble when the interface device sends an unacceptable value as data bytes length for Case 2 command -- the card can not transmit a different number of data bytes and has to send a special status word instead.

In T=0 the command cases are transmitted this way (very simplified):

  • Case 1:

    • CLA INS P1 P2 00, card responds with: SW1 SW2

  • Case 2:

    • CLA INS P1 P2 P3,
    • card responds with:
      • [ P3 bytes of response data ] SW1 SW2 if the actual length of response data equals P3
      • 6C XX if value of P3 is unacceptable

  • Case 3:

    • CLA INS P1 P2 P3 [P3 bytes of command data], card responds with: SW1 SW2

  • Case 4:

    • CLA INS P1 P2 P3 [P3 bytes of command data], card responds with: 61 YY
    • CLA C0 00 00 YY card responds with: [YY bytes of response data] SW1 SW2

See ISO 7816-3, section "Command-response pair transmission by T=0" for exact details.

(In theory,) to workaround that (i.e. to prevent JCRE from sending the 6C XX status word), you would have to implement all Case 2 commands as Case 1 commands (i.e. do not call the APDU.setOutgoing()), return 61 XX status word and implement the GET RESPONSE command yourself (JCRE should pass this command to your process() method if it does not have it's own response data).

This brings some unnecessary overhead for terminal supporting 6C XX.

Some additional (random) notes:

  • user-level processing of extra GET RESPONSE command in process() method just worked for me. I did not check the JC specifications regarding this, YMMV.

  • it is a pity you can't use T=1

  • the workaround proposed above is just a theory. I've never implemented that approach (but I am definitely interested in the results you might get)

Hope this answer makes some sense...good luck!

Upvotes: 1

FaST4
FaST4

Reputation: 279

There is a trick for Feitian and Infinion cards how to force 0x61XX response in "case 2" APDUs where Le=0x00 - the trick is to call setIncomingAndReceive(). This, however, will not work with other Le values (calling setIncomingAndReceive() with positive Le will cause error).

For compatibility reasons I ended up implementing 0x61XX support in the applet. So if the Le received does not match the length to be returned, the applet buffers the response in RAM and returns SW 0x61XX. When the GET RESPONSE APDU is received by process(), the Le will match the length buffered and the data will be returned using setOutgoingAndSend().

Upvotes: 0

Related Questions