On Sep 7, 2010, at 4:56 PM, Viktor TARASOV wrote: > Martin Paljak wrote: >> Hello, >> On Sep 7, 2010, at 12:45 PM, Viktor TARASOV wrote: >> >>> in r4668 the APDU validity condition >>> 'apdu->le > 256' was replaced by 'apdu->le > card->max_recv_size'. >>> >>> It's comprehensible but revealed the ambiguity of the 'max_recv_size'. >>> The unique card's max_recv_size cannot be used to validate all the APDUs >>> of card. >>> >>> For example, not all the cards accept Le = 256 for the 'READ BINARY' >>> command, >>> but the same card returns 256 bytes of the signature with RSA key 2048bit. >>> >> >> Do you mean Le encoding of 0x00 == 256 and "If Le=0x00, within the limit of >> 256 for a short Le field , all the available bytes should be returned." >> > > In the 'init' of some card drivers there is something like > "card->max_recv_size = 255", for example MyEID . > This card has to return 256 bytes of signature computed with 2048 bit key, > but cannot, because APDU do not pass the "apdu->le > > card->max_recv_size" control.
OK. I see what you mean. MyEID interprets Le=0x00 for read binary as "send zero bytes please" and returns 0x9000 with no data. Thus the 255 limit. card-entersafe sets both to 224, works fine without it with a PKI card but fails with epass 3000. So the limitation should be set for SC_CARD_TYPE_ENTERSAFE_3K only. I propose to revert r4668 and clarify it even further. Currently card->max_*_size is always initiated from the reader driver defaults, which are 255/256 unless overridden in opensc.conf. Thus the only previously existing check for card->max_recv_size being >0 in apdu.c was always triggered. All modifications done by card drivers is limiting max_send_size and max_recv_size further to values <255 and <256 (128, 224, 240, 244, 248 and 128, 224, 240, 244, 248, 252, 255 respectively). In 2010 and onwards, we'll have more readers supporting extended APDU-s (where we'll probably not hit the practical limits of readers any time soon) than ones that might need tuning to buffers < 256. I doubt it is a major issue any more with readers/tokens, but apparently an existing card driver issue. Maybe some exotic tokens have limitations, but modern CCID readers and tokens probably don't care, 25 of them in the list of 177 [1] in the list of CCID reader claim to not support payloads < 271. I suggest to let card drivers blindly set max sizes and only further limit them in card.c if reader has also limitations. Fetching SCARD_ATTR_MAXINPUT [2] from pcsc-lite/ccid could also be an option (on Unix). Another option could be removing the limiting capabilities from reader drivers altogether and leaving it to card drivers.
4668-fix.patch
Description: Binary data
Do you know anyone who actually uses the reader level payload restriction configuration? [1] http://pcsclite.alioth.debian.org/ccid/dwMaxCCIDMessageLength.html [2] http://www.opensc-project.org/pipermail/opensc-devel/2006-November/009199.html -- Martin Paljak @martinpaljak.net +3725156495
_______________________________________________ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
