Hello, 2010/11/20 Andre Zepezauer <andre.zepeza...@student.uni-halle.de>: > at the moment I'm investigating the max_x_size problem. Here is a short > preview of things I found so far. More detailed results will be attached > to #269. > > Current state of affairs: > > 1. currently I concentrate only on USB CCID devices > 2. there are in fact three different kinds > * TPDU > * Short APDU > * Short and Extended APDU > 3. TPDU and Ext-APDU devices don't need special handling. > It's for sure that these devices would at least transmit EVERY > Short APDU (255/256) (A fact to remember) > References that confirm that fact: [1] [2] > 4. looking closer at the third kind of devices (only Short APDU), > let to an interesting result. The following list will show. > * fist column is dwMaxCCIDMessageLength > * second column is a file under pcsclite/trunk/Drivers/ccid/readers
Keep in mind that dwMaxCCIDMessageLength also includes the CCID header: 10 bytes. So the maximum useful data length sent to the card is dwMaxCCIDMessageLength-10. With my CCID driver you can get the maximum usable size using SCardGetAttrib(..., SCARD_ATTR_MAXINPUT, ...) [3] I also try to push, in the PC/SC workgroup, a way to know at the application level if a reader+driver supports extended APDU or not. But it is not yet done. Maybe I should start a discussion also on the opensc-devel list. [3] http://svn.debian.org/wsvn/pcsclite/trunk/Drivers/ccid/SCARDGETATTRIB.txt > 261 Aktiv_Rutoken_Magistra.txt > 261 Gemalto_PDT.txt > 261 GnD_StarSignCardToken550.txt > 261 JCOP41V221.txt > 261 Oberthur-CosmoCard1.txt > 261 Oberthur-CosmoCard.txt > 261 Philips_SmartMX.txt > 271 ACR122U_PICC.txt > 271 Akasa_AK-CR-03.txt > 271 Aktiv_Rutoken_ECP.txt > 271 Alcor_SCR001.txt > 271 ATMEL_AT91SC192192CT-USB.txt > 271 ATMEL_AT91SO.txt > 271 ATMEL_AT98SC032CT.txt > 271 ATMEL_VaultIC420.txt > 271 ATMEL_VaultIC440.txt > 271 ATMEL_VaultIC460.txt > 271 AU9520.txt > 271 CardMan3021.txt > 271 CardMan3121.txt > 271 CardMan3621.txt > 271 CardMan3821.txt > 271 CardMan4321.txt > 271 CardMan5121.txt > 271 CardMan5125.txt > 271 CardMan5321.txt > 271 CardMan6121.txt > 271 CherrySmartBoardXX1X.txt > 271 CherrySmartTerminalXX1X.txt > 271 CherrySmartTerminalXX7X.txt > 271 CherryST1044U.txt > 271 CherryXX33.txt > 271 CherryXX44.txt > 271 Covadis_Auriga.txt > 271 FujitsuSiemens_SmartCard_Keyboard_USB_2A.txt > 271 FujitsuSiemens_SmartCard_USB_2A.txt > 271 GemPC433_SL.txt > 271 KAAN_SIM_III.txt > 271 mIDentity.txt > 271 Omnikey_noname1.txt > 271 Sitecom_MD-010.txt > 271 Smart_SBV280.txt > 271 SpringCard_CrazyWriter.txt > 271 SpringCard_CSB6_Basic.txt > 271 SpringCard_CSB6_Secure.txt > 271 SpringCard_CSB6_Ultimate.txt > 271 SpringCard_EasyFinger_Standard.txt > 271 SpringCard_EasyFinger_Ultimate.txt > 271 SpringCard_Prox_N_Roll.txt > 271 Teo.txt > 271 Todos_AGM2_CCID.txt > 271 Todos_Cx00.txt > 271 Vasco_DP905.txt > 271 Xiring_Leov2.txt > 271 Xiring_XI-SIGN_6000.txt > 271 Xiring_XI-SIGN.txt > 278 GemProxDU_contactless.txt > 278 GemProxSU_contactless.txt > 280 GnD_StarSignCardToken350.txt > 512 TianYu_CCID_SmartKey.txt > 512 VMware_Virtual_USB_CCID.txt > 2048 GoldKey_PIV_Token.txt > > Assuming that devices with dwMaxCCIDMessageLength=261 are all USB_Tokens > and not readers. Then it looks like that all these readers of third kind > can also handle 255/256. It think you forgot to count the 10 bytes of CCID header. > All in all this let to the conclusion that all known USB CCID devices > can handle at least 255/256. (data set is retrieved from libccid source > code) > > And this in turn would make the description in opensc.conf very brief. > Maybe like this: "If you have a usb device, then you can go with the > defaults." > > Regards > Andre > > [1] http://www.usb.org/developers/devclass_docs/DWG_Smart-Card_CCID_Rev110.pdf > [2] http://pcsclite.alioth.debian.org/ccid_extended_apdu.html -- Dr. Ludovic Rousseau _______________________________________________ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
