2013/7/22 Hans-Martin Haase <[email protected]>: > Hello,
Hello, > we discovered a bug in the ccid driver. > > For a Cherry GmbH SmartBoard XX44 [Smart Card Reader USB] Model RS 6700 > USB the ReadBinary command apdu executed on a German E-Health Card fails. The reader you are using do not support extended APDU but short APDU only. See http://pcsclite.alioth.debian.org/ccid/readers/CherryXX44.txt and http://pcsclite.alioth.debian.org/ccid_extended_apdu.html And your application is sending an extended APDU: 00 B0 00 00 00 00 00 >From the pcscd log: 00000010 winscard.c:1581:SCardTransmit() Send Protocol: T=1 00000015 APDU: 00 B0 00 00 00 00 00 00000010 ifdhandler.c:1265:IFDHTransmitToICC() usb:046a/0010:libudev:1:/dev/bus/usb/003/002 (lun: 0) 00000008 commands.c:1627:CmdXfrBlockTPDU_T0() T=0: 7 bytes 00000020 -> 000000 6F 07 00 00 00 00 31 00 00 00 00 B0 00 00 00 00 00 00003609 <- 000000 80 00 00 00 00 00 31 40 F6 00 00000040 commands.c:1401:CCID_Receive Protocol not supported 00000008 SW: 00000007 ifdwrapper.c:527:IFDTransmit() Card not transacted: 612 00000007 winscard.c:1606:SCardTransmit() Card not transacted: 0x80100016 > We used the openecard app https://github.com/ecsec/open-ecard . > The problem is not the java smart card IO because we tested it > successfully on a Window 7 with the current java version. Maybe the Windows driver is from the reader manufacturer (Cherry) and know a proprietary way to send an extended APDU. I guess you find have the same problem if you use the Windows CCID driver instead. Maybe you can find a reader firmware upgrade to make the reader support extended APDU in the standard CCID way. Another solution is to do some reverse engineering on the Cherry Windows driver to know how that is managed under Windows. But that will take time to implement a non CCID standard solution. Bye -- Dr. Ludovic Rousseau _______________________________________________ Muscle mailing list [email protected] http://lists.musclecard.com/mailman/listinfo/muscle_lists.musclecard.com
