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 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 ***
Re: MUSCLE Is 61xx handled in your driver?
> 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. That is because there is no way for the card to differentiate between a case 3 and case 4 APDU. Independent of whether the application specifies Le or not, the command is always send to the card with P3 = Lc. It is the transport layer T=0, that must detect a Le passed from the application and enable GET RESPONSE processing. On the application level case 1 to case 4 look like Case 1: CLA INS P1 P2 Case 2: CLA INS P1 P2 Le Case 3: CLA INS P1 P2 Lc Data Case 4: CLA INS P1 P2 Lc Data Le In T=1 these APDUs are transported transparently. In T=0 they are mapped to Case 1: CLA INS P1 P2 P3 = 00 Case 2: CLA INS P1 P2 P3=Le Case 3: CLA INS P1 P2 P3=Lc Data Case 4: CLA INS P1 P2 P3=Lc Data and subsequent GET RESPONSE. Andreas *** 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?
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
***
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 ***
Re: MUSCLE Is 61xx handled in your driver?
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. *** 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 ***
Re: MUSCLE Is 61xx handled in your driver?
Hi, I completly agree with Andreas. Get Response is dependant on T=0 transport protocol and must not be handled at application level. This is at least what ISO 7816 says. Towitoko driver 2.0.X handles authomatically the Get Response when the command is Case 3 or Case 4. Also the issues athomatically the Envelope command and cares of extended commands (more that 255 bytes sent/received). --- Andreas Schwier <[EMAIL PROTECTED]> wrote: > > Most of the drivers pass the 61 XX back to the > application to handle. I > > think it is bad practice to handle this in the > driver since it is a card > > specific ISO function. > > GET RESPONSE is a transport level command. It should > therefore be invisible > for the application. The problem arises if you write > applications that work > with cards that support either T=0 or T=1 transport > via PPS. If the reader > hardware is capable of doing either T=0 or T=1, then > the application always > would need to know what protocol is used. If it is > T=0, then it would need > to send GET RESPONSE, if it is T=1 then it would not > send a GET RESPONSE. > > ISO7816-4 was specifically rewritten at some point > in time to eliminate > dependencies on T=0. ISO7816-4 now defines command > and response APDU in the > first part and defines the mapping of these APDUs > onto T=0 or T=1 transport > in the annex. > > Andreas > > *** > 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 > *** __ Do You Yahoo!? Make international calls for as low as $.04/minute with Yahoo! Messenger http://phonecard.yahoo.com/ *** 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 ***
Re: MUSCLE Is 61xx handled in your driver?
When a card returns 61.xx, it means that the card has xx byte to return to host. Does a smartcard reader driver handle this, usually? My Todos driver does. It seemed useful at the time. I would like to know whether this is correct or not. Most other reader drivers I have looked at do not. *** 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 ***
Re: MUSCLE Is 61xx handled in your driver?
> Most of the drivers pass the 61 XX back to the application to handle. I > think it is bad practice to handle this in the driver since it is a card > specific ISO function. GET RESPONSE is a transport level command. It should therefore be invisible for the application. The problem arises if you write applications that work with cards that support either T=0 or T=1 transport via PPS. If the reader hardware is capable of doing either T=0 or T=1, then the application always would need to know what protocol is used. If it is T=0, then it would need to send GET RESPONSE, if it is T=1 then it would not send a GET RESPONSE. ISO7816-4 was specifically rewritten at some point in time to eliminate dependencies on T=0. ISO7816-4 now defines command and response APDU in the first part and defines the mapping of these APDUs onto T=0 or T=1 transport in the annex. Andreas *** 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 ***
Re: MUSCLE Is 61xx handled in your driver?
Hi Naomaru Our driver for the ORGA ECO 5000 automatically sends GET_RESPONSE; if the card returns '61 xx' or '9F xx' and the application passed a case 4 command APDU to the reader. The class byte for GET_RESPONSE is copied from the class byte used for the original command. IMHO this is the way it should be done, because GET RESPONSE (as well as PUT ENVELOPE) is a command of the T=0 transport layer and it should be invisible for the application. The application should never really care whether a card speaks T=0 or T=1. Unfortunately the designer of the PC/SC specification didn't really follow this concept. On the other hand there are (very old) cards out there, which may not work because they require a different GET_RESPONSE. For such cases it might make sense to disable automatic generation of GET RESPONSE. Andreas *** 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 ***
Re: MUSCLE Is 61xx handled in your driver?
Hello, Most of the drivers pass the 61 XX back to the application to handle. I think it is bad practice to handle this in the driver since it is a card specific ISO function. This should happen above the reader abstraction where the card abstraction layer occurs. BTW - has anyone done an OSI like modeling for how a smartcard infrastructure should occur ? Regards, Dave On Mon, 30 Jul 2001, Naomaru Itoi wrote: > When a card returns 61.xx, it means that the card has xx byte to > return to host. > > Does a smartcard reader driver handle this, usually? Does it > automatically send get_response APDU and get the return data, or does > it pass the status code 61.xx to the application? > > I am not trying to find out which the right way is. I am trying to > find out how the actual reader drivers do it. > > Thank you. > > -- > Concentration .. Naomaru Itoi, coding @ home > *** > 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 > *** > *** 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 ***
RE: MUSCLE Is 61xx handled in your driver?
Most readers wont handle this response code. Some POS terminals will. You should send the get response/data command to retrieve the data. John -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] On Behalf Of Naomaru Itoi Sent: Monday, July 30, 2001 6:43 PM To: [EMAIL PROTECTED] Subject:MUSCLE Is 61xx handled in your driver? When a card returns 61.xx, it means that the card has xx byte to return to host. Does a smartcard reader driver handle this, usually? Does it automatically send get_response APDU and get the return data, or does it pass the status code 61.xx to the application? I am not trying to find out which the right way is. I am trying to find out how the actual reader drivers do it. Thank you. -- Concentration .. Naomaru Itoi, coding @ home *** 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 *** *** 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 ***
MUSCLE Is 61xx handled in your driver?
When a card returns 61.xx, it means that the card has xx byte to return to host. Does a smartcard reader driver handle this, usually? Does it automatically send get_response APDU and get the return data, or does it pass the status code 61.xx to the application? I am not trying to find out which the right way is. I am trying to find out how the actual reader drivers do it. Thank you. -- Concentration .. Naomaru Itoi, coding @ home *** 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 ***
