RFR 8163251 : Hard coded loop limit prevents reading of smart card data greater than 8k

Michael StJohns mstjohns at comcast.net
Tue Feb 11 00:18:18 UTC 2020


On 2/10/2020 6:49 PM, Ivan Gerasimov wrote:
> Hello!
>
> Current implementation of the method 
> javax.smartcardio.CardChannel.transmit() has an internal limitation on 
> the maximum allowed amount of the transmitted data.
>
> This limitation is dictated by the maximum number of iterations to 
> transmit data from a card:  Each iteration can transmit up to 256 
> bytes of data, and we have a hardcoded limit of 32 iterations.
>
> Over time, we've received requests to increase this limit, as there 
> are occasions when the effective limit of 8k is not enough.
>
> Would you please help review a proposal:  First, it is proposed to 
> increase the default limit of iteration to 128 (so that up to 32k of 
> data can be transmitted);  Second, the limit of iterations is made 
> configurable via a System property.  This limit can be increased up to 
> 4096 (so that the total amount of transmitted data can be made up to 1m).
>
> BUGURL: https://bugs.openjdk.java.net/browse/JDK-8163251
> WEBREV: http://cr.openjdk.java.net/~igerasim/8163251/00/webrev/
>
> If there is an agreement on the proposal, I'll file a CSR to document 
> a new System property.
>
> Thanks in advance!
>
Given that the maximum length for an extended APDU is 64K (65536) (hmm 
+7 for the header and +2 for LE), and for its return is 64K + 2 bytes,  
I'm not quite sure why you'd up the number to 4096/1M - I'd set the 
default and fixed value to 257  (64K) and leave it at that.

Mike







More information about the security-dev mailing list