On Tuesday, April 30, 2002, at 08:24 am, Arno Wilhelm wrote:
> Hello Jean-Luc, > > >> If you look at your command, the length byte you send is wrong (it >> should be 0x10). Normally, I think the driver would unterstand your >> command as a fully qualified APDU (ie CLA, INS, P1,P2, Lc, Data, Le) >> and issue the Get Response automatically. The response you read could >> be the first 2 bytes of a 5 bytes answer (3 bytes of Data SW). >> -> pcsc_create_dir_crycs() returned 0x0: >> [CMD] [ 0x84 0xE0 0x01 0x00 0x0F 0x10 0x00 0x38 0x00 0x00 0x00 0x00 >> 0x00 0x00 0x00 0x00 0x00 0x8F 0x03 0xE5 0x03 ] >> [RSP] [ 0x78 0x1E ] >> Error: pcsc_create_dir_crycs() no checksum to read ! > > > It is also strange that the Towitoko driver does not seem to have any > problems with this command and returns the awaited response whereas > both drivers for the GemPC reader return some strange data, that does > not seem to be related to any documented return values. I am not so > deep into smartcard programming, but for me it still seems to be > related to the reader/driver. Or the GPK card might not be ISO7816 > conform? I believe this card is 7816 compliant. You should try to send the command without the 0x03 in the end. I think the Towitoko driver expects you to send a TPDU (i.e. transport level commands for T=0 and not applicative level commands (APDU)). It therefore ignores the final 0x03. In fact, for a case 4 command (Data IN and OUT), the proper APDU is CLA, INS, P1, P2, Lc, Data, Le. The Get Response is a transport level command used in the T=0 protocol (it does not exist in T=1) and the application should ideally not have to send it. At any rate a TPDU with Lc < to the length of the data is not 7816 compliant. > > I think the driver would unterstand your command as a fully > qualified > APDU (ie CLA, INS, P1,P2, Lc, Data, Le) and issue the Get > Response > > automatically. The response you read could be the first 2 bytes of a > 5 > bytes answer (3 bytes of Data SW). > > I have not found any hint in the GPK Reference Manual that the card can > return a response without having issued the GetResponseCommand() > before. And I do not think that the driver should give the response > instead of the card? > I also cannot understand then why the towitoko driver does return a > valid response like this: The driver does not give the response in place of the card: it just sends the Get Response automatically, if the status byte is 0x61 xx. BTW, the driver is not trying to be helpful, it is just conforming the standard when it receives a complete APDU. For the Gemcore driver, my wild guess is that it allocates memory according to the Lc byte and then complains because there is too much data for the size of the buffer. Cheers, JLuc. *************************************************************** Unix Smart Card Developers - M.U.S.C.L.E. (Movement for the Use of Smart Cards in a Linux Environment) http://www.linuxnet.com/ To unsubscribe send an email to [EMAIL PROTECTED] with unsubscribe sclinux ***************************************************************
