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

Ming Yung ming.yung1 at gmail.com
Wed Jul 30 17:02:06 PDT 2008

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

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.


On Tue, Jul 29, 2008 at 1:14 AM, Sean Mullan <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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.openjdk.java.net/pipermail/security-dev/attachments/20080731/2fad818e/attachment.html 

More information about the security-dev mailing list