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

[Roger Riggs]

+1

On 2/11/20 3:24 PM, Ivan Gerasimov wrote:
> Thank you Roger!
>
> We do have a manual test that performs some sanity verification that a 
> transmit call works [1].
>
> I have also received a confirmation from a submitter of the bug that 
> the patched JDK now allows to retrieve data larger than 32k, which was 
> not possible before the fix.
>
> I'll add a noreg-hard label to the bug.
>
> [1] 
> http://hg.openjdk.java.net/jdk/jdk/file/73bcb3e4e596/test/jdk/sun/security/smartcardio/TestTransmit.java
>
> With kind regards,
>
> Ivan
>
>
> On 2/11/20 6:46 AM, Roger Riggs wrote:
>> Hi Ivan,
>>
>> Raising it to work up to the spec'd limit is a good approach.
>>
>> Do we have a way to test this?  Aka: There should be a test.
>>
>> Roger
>>
>>
>> On 2/10/20 8:07 PM, Ivan Gerasimov wrote:
>>> Thank you Michael!
>>>
>>> It's a good point about maximum length.
>>>
>>> Here's the updated webrev with the new System property dropped and 
>>> the increased number of iterations:
>>>
>>> http://cr.openjdk.java.net/~igerasim/8163251/01/webrev/
>>>
>>> With kind regards,
>>> Ivan
>>>
>>>
>>> On 2/10/20 4:18 PM, Michael StJohns wrote:
>>>> 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
>>>>
>>>>
>>>>
>>>>
>>>>
>>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/security-dev/attachments/20200212/304107a8/attachment.htm>