2010/11/21 Andre Zepezauer <andre.zepeza...@student.uni-halle.de>: > On Sun, 2010-11-21 at 09:44 +0100, Ludovic Rousseau wrote: >> 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. > > As state above, I excluded the devices with dwMaxCCIDMessageLength=261. > These devices are most probably USB tokens and have always a card > present. Limitations of cards are handled separately. And they can be > adjusted to match the limitations of the connected reader. The reader is > always the same for a given USB token and therefore max_x_sizes are > adjusted by card capabilities. > > All the remaining devices are willing to receive at least 271 bytes. And > therefore are able to handle Short APDU:s of every size. > > Command APDU: > 10 CCID header > 5 CLA INS P1 P2 LC > 255 Data > 1 LE > ---- > 271 > > Response APDU: > 10 CCID header > 256 Data > 2 SW1 SW2 > --- > 268 > > What's wrong?
Nothing is wrong. It was not clear for me that you excluded reader with dwMaxCCIDMessageLength=261 A CCID reader (not a token or ICCD device) that is not able to handle Short APDU:s of every size should be in the "unsupported" list [1]. I don't know of any such reader. Bye [1] http://pcsclite.alioth.debian.org/ccid/unsupported.html -- Dr. Ludovic Rousseau _______________________________________________ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
