This discussion is archived
3 Replies Latest reply: Feb 29, 2012 12:00 PM by 802338 RSS

Getting rid of 6CXX responses.

802338 Newbie
Currently Being Moderated
Hello,

while trying to mimic an older card with a JavaCard applet, I've run into an annoying issue. When reading a record of size XX:
- card A (old card) replies with 61XX, and the host software does the obvious.
- card B (JavaCard) replies with 6CXX, and the host software barfs.

I don't want to argue what is the most correct solution (what would be the host software re-issuing the command with correct Le) but I'd like to know if/how it is possible to enforce a specific response from JavaCard side, as my idea is to mimic an existing card as closely as possible.

The card is an JTOP one. I've digged through the JC2.2.2 documentation of javacard.framework.APDU and I don't really see hot this could be done differently. Playing around with different setOutgoing* combinations does not seem to affect it either.

Any hints?
  • 1. Re: Getting rid of 6CXX responses.
    Umer Journeyer
    Currently Being Moderated
    You can't force java card, you need to behave it according to its standards.
  • 2. Re: Getting rid of 6CXX responses.
    911739 Newbie
    Currently Being Moderated
    Hello 799335 ,

    In "GlobalPlatform Card Specification" Version 2.2.1.
    Section A.1: T=0 Transmission Protocol
    i read the info as "+If the data is less than the data expected by the terminal, the OPEN will store the data and output a '6Cxx' response code and wait for the CAD to re-issue the command with the correct length. When the re-issued command is received the JCRE will manage the outputting of the stored data+".

    May be this is also the reason to getting 6CXX.

    Hope this will help you.
  • 3. Re: Getting rid of 6CXX responses.
    802338 Newbie
    Currently Being Moderated
    Answering my own question for those who might stumble upon it.

    Say I have commands 00 12 00 00 00 and 00 12 00 00 64 and 0A bytes of data to send back (all numbers are hex).

    This is a case 2 APDU, thus P3 is supposed to be Le, not Lc, with the Le semantics as described in ISO (00 = "all data available up to 256"). I would like to process Le to send different SW-s with the data if necessary (like 6282 if called with the second command, where 0A < 64).

    Calling setIncomingAndReceive is thus not supposed to be called when implementing this command, as there is not supposed to be any input from the host (case 2)

    Calling setOutgoing* will result in an otherwise proper command-cycle with P3=00, but with 6CXX instead of 61XX.

    Thus it is needed to "eat away" the Le byte as empty (zero) Lc with setIncomingAndReceive if P3 == 00, after what setOutgoing will not have a reference value for the expected Le and setOutgoing* will result in 61XX response in T=0 mode (and of course, proper functioning in T=1 as well).

    Probably obvious, but made me wonder for a while.

Legend

  • Correct Answers - 10 points
  • Helpful Answers - 5 points