RFR 8163251 : Hard coded loop limit prevents reading of smart card data greater than 8k
Ivan Gerasimov
ivan.gerasimov at oracle.com
Tue Feb 11 20:24:51 UTC 2020
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
>>>
>>>
>>>
>>>
>>>
>
--
With kind regards,
Ivan Gerasimov
More information about the security-dev
mailing list