[security-dev 00260]: Re: Handling of APDU output chaining in Channel.transmit()

[Sean Mullan]

Hi Ming,

Ming Yung wrote:
In this case should this feature be configurable, at least? Say, on/off 
and/or making the "32" configurable?

Yes, probably.

Could you file an RFE at bugs.sun.com? Please use the JDK/JRE category 
and the classes_security subcategory.

Thanks,
Sean


The Exception message is extremely misleading, by the way. If it wasn't 
for jpcsc I would have believed that the card did actually stop responding.

Thanks,
Ming

On Tue, Jul 29, 2008 at 1:14 AM, Sean Mullan <[EMAIL PROTECTED] 
<mailto:[EMAIL PROTECTED]>> wrote:

    I have asked someone who worked on this code and they said:

    I believe this is a failsafe to prevent the code from going into an
    infinite loop when talking to a bad card or driver.

    --Sean


    Ming Yung wrote:

         Hi there,

        This relates to a limitation (bug?) in the implementation of
        javax.smartcardio.Channel.

        I am looking at doing APDU output chaining using the "SW 61XX
        and GET RESPONSE" mechanism in order to transfer large datasets
        out of a JavaCard. As it stands, I am limited to chains of
        length 31 because of the following condition in
        sun.security.smartcardio.ChannelImpl.doTransmit(byte[] command):

         int k=0;
         while (true) {
           if (++k >=32) {
             throw new CardException("Could not obtain response");
           }
            ....
         Is there any reason for this condition? I cannot find it in ISO
        7816-4 (2005 edition).

        Right now, a workaround is to set the undocumented system
        property "sun.security.smartcardio.t1GetResponse" to "false"
        (I'm using a T=1 card) and handle the chaining outside smartcardio.

        Cheers,
        Ming