On Tuesday, April 30, 2002, at 04:32 pm, Arno Wilhelm wrote:
> Hello, > > >> 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. > > Does that mean that the TPDU ignores the Le field of any APDU? If by Le you mean the length of the expected response, the first TPDU (command) ignores it, but the Get Response can use it (or use the length in 61 xx). > But in this case the 0x03 at the end belongs to the cryptographic > checksum and not to the Le field of the APDU, I think !? Maybe that's > the problem? Maybe the wording in the card documentation is ambiguous and the 0x03 should not be added? >> 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. > > Hmm, that means that the reader should issue a GetResponseCommand() by > itself when it get's a return value of 0x61xx? If you send a TPDU (which you should not ideally), the driver should probably let you do the Get Response. If you send a proper APDU, the driver should do it for you. If you send APDUs, your application will work on T=1 or T=0 cards without modifications. > >> At any rate a TPDU with Lc < to the length of the data is not 7816 >> compliant. >> 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. > > But that would mean that the Towitoko driver and the description in the > GPK Reference Manual is not conforming to the standard? I don't know for the Towitoko driver (maybe it conforms to the PCSC standard which might say that you should send TPDUs but then would not be really ISO). For the card, it probably is an error in the documentation. > >> 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. > > That sounds very sensible. Think I am going to test that out and post > the results on this mailinglist. ( That might last till the beginning > of next week, since I am out of the house for the rest of the week. ) I hope it works! 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 ***************************************************************
