Re: MUSCLE GPR400 ifd and T=0 vs T=1 from the driver perspective
Purchase ISO 7816 parts 3 and 4 to understand the low level communication between card and IFD (Terminal, card reader). Peter T Bristol UK - Original Message - From: Joe Phillips [EMAIL PROTECTED] To: [EMAIL PROTECTED] Cc: Wolf Geldmacher [EMAIL PROTECTED] Sent: Thursday, August 02, 2001 3:43 AM Subject: MUSCLE GPR400 ifd and T=0 vs T=1 from the driver perspective I've got a mostly working GPR400 PCSC IFD. It's based on the PCMCIA driver found in the card-0.9.6.tar.gz file found on the MUSCLE website. By 'mostly working' I mean that I've used formaticc to send a few APDUs to a card and received the expected results. I'm having troubles understanding what the differences are between T=0 and T=1 from the IFD developer perspective. It's not apparent to me from looking through the other IFD source files. I have the Smart Card Developer's Kit and Java Card Technology for Smart Cards books already. I understand that T=0 and T=1 are two different protocols for communication between the reader and the card. It is not clear to me *how* they are different other than one is byte oriented and the other is block oriented. Can anyone offer any insight into the differences, if possible, from the IFD developer perspective? Can you point me to some documentation and/or code that will clear this up for me? Thanks in advance. -joe *** 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 *** *** 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 ***
Re: MUSCLE Re: 61 XX
David Corcoran wrote: Hello, Points well taken. It seems unanimous that the driver should take care of Get Response. I shall update the IFD Handler documentation to reflect this. Thank you so much for your suggestions. Jim rees said: I agree that the application should not have to deal with this. But I don't think the driver should either. Anything that every driver must do in the same way really belongs at a higher level, in pc/sc. And I quite agree with him. The GET RESPONSE must be handle at a higher level between the driver and the application. -- Laurent Boulard perl -e 'print(pack(h38,34f6e67627164757c6164796f6e63702b3d292))' *** 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 ***
AW: MUSCLE Re: 61 XX
One question: How does the reader know which CLA byte to use? In our driver for the ECO5000 we use the CLA byte of the former used command apdu. For example: The command apdu looks like this: 0x00 0xC0 0x00 0x01 0x02 0x3f 0x00 If the driver recognizes that a Get Reponse is neccessary he uses the CLA byte (0x00) of this command. Frank *** 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 ***
Re:MUSCLE 61XX in Microsoft PC/SC implementation
Enviado Thu, 02 Aug 2001 14:47:35 +0200 Axel Heider [EMAIL PROTECTED]Escribió: Hi, some time ago I got this response from Eric Perlin from Microsoft about their PC/SC implementation: ... Since when we use Microsoft as a reference??? Nothing personal, but I would listen to a Gemplus/Shclum/Oberthur/Gieseke/... opinion before lisening to Microsoft. Besides, we are linuxers. Aren't we? Regards. Sergio Rodriguez. Regístrate y obtén un correo gratuito, seguro y de por vida en: www.OficinadeCorreo.com ¡Ahora con capacidad de 10 MB! No olvides visitar el mejor chat de Latinoamérica, ven y conéctate con el mundo en www.barriolatino.com *** 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 ***
Re: MUSCLE Is 61xx handled in your driver?
The clean way to organise this is: (a) An application in the terminal issues APDUs (b) The software layer receiving the APDU knows whether the card is being operated with T=0 or T=1, and sends information down to the card driver as appropriate; if T=0 and a case 4 APDU, the APDU is split into a Case 3 TPDU (which sends data to the card) and a Case 2 GET RESPONSE (c) The card driver interfaces with a card reader driver (d) The card reader driver handles the interface out to the card reader Change the card - change only the card driver in the PC; change the card reader - change only the card reader driver in the PC Write the layer below the application strictly to 7816-4 rules, and cards that don't comply (e.g cards that require a GET RESPONSE as part of processing every APDU (if that really is true)) are not acceptable. Its sad that we cannot yet have a universal card driver, but its going to be true for some time to come. Regards, Peter T Bristol UK - Original Message - From: Laurent Boulard [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Wednesday, August 01, 2001 8:08 AM Subject: Re: MUSCLE Is 61xx handled in your driver? David Corcoran wrote: I think you should handle the Get Response if your APDU looks like the following: CLA INS p1 p2 p3 lentx xx xx xx xx xx lenrx Is this correct ? In the perfect world yes ! but, sadly, people sometimes doesn't follow correctly the ISO7816 or misunderstood it. I have cards (W4SC as an example) which send back a GET RESPONSE even for a APDU without data. This is really annoying as I have to modify my application to take care of this kind of cards. May be the highler level must be modify to hide this behaviour. But, from another point of view, it is interesting to know that you have a card with GET RESPONSE because sometimes those cards must run in terminals without management of the GET REPONSE apdus. -- Laurent Boulard Research Engineer Advanced Research SchlumbergerSema (Louveciennes) Tel: +33 (0)1 30 08 45 97 Fax: +33 (0)1 30 08 45 24 perl -e 'print(pack(h38,34f6e67627164757c6164796f6e63702b3d292))' *** Linux Smart Card Developers - M.U.S.C.L.E. (Movement for the Use of Smart Cards in a Linux Environment) http://www.linuxnet.com/smartcard/index.html *** *** 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 ***
Re: MUSCLE Is 61xx handled in your driver?
CLA INS P1 P2 Lc data Le in 7816-4 speak (section 5.3.1 Fig 3) Peter T Bristol UK - Original Message - From: David Corcoran [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Tuesday, July 31, 2001 9:26 PM Subject: Re: MUSCLE Is 61xx handled in your driver? I think you should handle the Get Response if your APDU looks like the following: CLA INS p1 p2 p3 lentx xx xx xx xx xx lenrx Is this correct ? Dave *** Linux Smart Card Developers - M.U.S.C.L.E. (Movement for the Use of Smart Cards in a Linux Environment) http://www.linuxnet.com/smartcard/index.html *** *** 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 ***
MUSCLE Reflex 72 drivers
Hello! I have just compiled and installed new Reflex 72 driver with pcsc-lite-0.9.3. (I use Mindrake 7.2 Linux) I connected to card normally, but when I transmit to the card any command I get status code 64A0 (undocumented). Where is problem? Thank you! Nikolay Stanchenko JSC TKK *** 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 ***
No Subject
Hello, Sorry for the mistake. I accidentally posted my majordomo password to the site while trying to administer some users. After about 1/2 hour I finally figured out how to configure majordomo again and luckily no-one stole my password. I will have to be more careful I did change passwords, and change some text and also changed some properties so we don't get Un-sub-scribe messages posted to sclinux. BTW - if your message includes the word sub-scribe or un-sub-scribe it will bounce. (That is why I added the -) Again, sorry for the mistake. Regards, Dave *** 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 ***
MUSCLE 61XX in Microsoft PC/SC implementation
Hi, some time ago I got this response from Eric Perlin from Microsoft about their PC/SC implementation: This is no work for the driver. This needs to be handled by the app. I recommend a little layer on top of SCardTransmit to hide the pecularities of T=0 (vs T=1). I think the the MUSCLE implementation should be compatible to this, too. -- With best regards Axel Heider Towitoko AG Haidgraben 2 85521 Ottobrunn Tel: +49-89-66683-0 Fax: +49-89-66683-222 *** 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 ***
MUSCLE Reflex 72 problem (additional info)
Hello! I have just compiled and installed new Reflex 72 driver with pcsc-lite-0.9.3. (I use Mindrake 7.2 Linux) I connected to card normally, but when I transmit to the card any command I get status code 64A0 (undocumented). Where is problem? Thank you! Nikolay Stanchenko JSC TKK Also if I execute sample applicate I get status code 64A6: CT-API Sample - (c) SCM MICROSYSTEMS CT_init : succesful, use /dev/ttyS0 RSR3 Firmware : 1.34 Library Version : X 1.0 Check ICC : ICC inserted ! RESET CT (ATR) : failed, SW1 = 64, SW2 = A6 EJECT CT: ICC disconnected ! *** 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 ***
Re: MUSCLE Re: 61 XX
On Thu, 02 Aug 2001 09:19:53 +0200 Laurent Boulard [EMAIL PROTECTED] wrote: David Corcoran wrote: Hello, Points well taken. It seems unanimous that the driver should take care of Get Response. I shall update the IFD Handler documentation to reflect this. Thank you so much for your suggestions. Jim rees said: I agree that the application should not have to deal with this. But I don't think the driver should either. Anything that every driver must do in the same way really belongs at a higher level, in pc/sc. And I quite agree with him. The GET RESPONSE must be handle at a higher level between the driver and the application. -- Laurent Boulard I don't think that the handling should be done in the driver, either. In our implementation GET RESPONSE is done in the ICC Service Provider functions, where I think it fits best. Erika Suortti Computing Centre Helsinki University of Technology *** 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 ***
Re: MUSCLE 61XX in Microsoft PC/SC implementation
Hi, --- Axel Heider [EMAIL PROTECTED] wrote: Hi, some time ago I got this response from Eric Perlin from Microsoft about their PC/SC implementation: This is no work for the driver. This needs to be handled by the app. I recommend a little layer on top of SCardTransmit to hide the pecularities of T=0 (vs T=1). I think the the MUSCLE implementation should be compatible to this, too. Not if the driver implements IFD Hanlder as a layer over CT-API (as most MUSCLE drivers do). CT-API says: Commands to processor ICC are passed through to the ICC in a transparent mode (i.e. without any changes). Implementation overheads (e.g. transmission protocol) are added automatically. For me this means that the caller application sends a command APDU and expects a response APDU, and don't want to know anything of TPDU's (GetResponse and Envelope only has sense at transport layer). On the other hand, if IFD handler is not implemented over CT-API, I agree the best place to implement the Get Response / Envelope logic is at an ICC abstraction layer (not application layer). -- With best regards Axel Heider Towitoko AG Haidgraben 2 85521 Ottobrunn Tel: +49-89-66683-0 Fax: +49-89-66683-222 *** 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 *** __ Do You Yahoo!? Make international calls for as low as $.04/minute with Yahoo! Messenger http://phonecard.yahoo.com/ *** 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 ***
