[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 <Sean.Mullan at sun.com 
> <mailto:Sean.Mullan at sun.com>> 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
> 
> 
> 
> 
>