Re: MUSCLE Bull PC/SC Test Card
On Don, 09 Mär 2000, you wrote: > Hello, > The following command came from IFD_TEST.EXE on Windows. > Does anyone know what the following command does on the Bull PC/SC test card ? > > bc c4 00 This clearly violates ISO7816/4. It is either a test to very the handling of invalid APDUs, or is a proprietary Bull command. > bc a0 00 00 Case 1 command APDU, but otherwise probably Bull proprietary. > > These are only 3 and 4 byte commands. Any clues > > On the IBM card test there are these commands > > a4 a4 00 Maybe just test to verify handling of invalid APDUs ? > a4 a4 00 00 SELECT command with secure messaging, but should return error from the card as file id is missing. > b6 42 00 40 IBM internal case 1 command ? > > On the Schlumberger there is > > 00 d6 00 00 - Is this a special case of update binary ? Could be, but I assume it is a negative test. > > Any clues what each of these command is supposed to do and how PC/SC is > supposed to handle them since they are under 5 bytes ? ISO7816/4 defines command and response APDUs to be used between the application and the card. This APDU format is independent of the transmission protocol, it works for T=0 and T=1: Case 1: CLA INS P1 P2 SW1 SW2 Case 2: CLA INS P1 P2 Lc SW1 SW2 Case 3: CLA INS P1 P2 Le SW1 SW2 Case 4: CLA INS P1 P2 Lc Le SW1 SW2 Using this format, an application can be independent of the transmission protocol used. Still any intermediate layer in the protocol can determine from the length of the APDU and the Lc/Le field the format of the command. The transmission protocol must map the command APDU to a command TPDU and convert a received response TPDU to a response APDU. For T=1 this is trivial, as both formats are identical. Exception to the rule is a case 1 command, where a P3=00 needs to be added. For T=0 this is a little bit more complicated: First T=0 is not capable of handling Case 4 APDU's directly, instead the command is send as a Case 2 command, whereby a subsequent GET RESPONSE command will fetch the result from the card. In an ideal world, this would be done by the protocol stack in the IFD directly. Unfortunately, there are some cards around, that have problems with this automatic GET REPONSE mode, so it should at least be possible to disable such a feature. T=0 defines the TPDU to be Case 1: CLA INS P1 P2 P3=00 SW1 SW2 Case 2: CLA INS P1 P2 P3=Lc SW1 SW2 Case 3: CLA INS P1 P2 P3=Le SW1 SW2 as said before a Case 4 command would be handled like Case 4: CLA INS P1 P2 P3=Lc SW1 SW2 CLA INS='C0' P1='00' P2='00' P3=Le SW1 SW2 Things get even more complicated with the extended length fields, but I haven't seen a card with T=0 that uses extended length fields. For T=1 it work O.K. So, PC/SC should do nothing with these APDU's expect to pass them to the IFD handler. The IFD handler needs to do the mapping and shall return an error if he is not successfull. Andreas -- Andreas Schwier Tel. +49 171 8334920 CardContact Software & System Consulting http://www.cardcontact.de *** 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 Bull PC/SC Test Card
Mahlzeit Dunno about the 3 byte command, but 4 bytes is the "normal" form for Case 1 commands. They are transmittet in this form by T=1. For T=0 the must be filled by a zero byte to 5 bytes. Mahlzeit endergone Zwiebeltuete *** 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 Bull PC/SC Test Card
Hello, The following command came from IFD_TEST.EXE on Windows. Does anyone know what the following command does on the Bull PC/SC test card ? bc c4 00 bc a0 00 00 These are only 3 and 4 byte commands. Any clues On the IBM card test there are these commands a4 a4 00 a4 a4 00 00 b6 42 00 40 On the Schlumberger there is 00 d6 00 00 - Is this a special case of update binary ? Any clues what each of these command is supposed to do and how PC/SC is supposed to handle them since they are under 5 bytes ? 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 Chipdrive Mobile?
actually.. there should be something on the website about it.. I saw it there (at least) a year ago.. ehhe maybe they took it down but.. *shrug*.. it would be a nice lil' toy to have tho.. :) tda On Wed, 8 Mar 2000, Jim Rees wrote: > Anyone know anything about the Towitoko Chipdrive Mobile? It has an Irda > interface, which could be useful with a Pilot, except that it uses a > "proprietary protocol." There is nothing about it on the Towitoko web site, > which hasn't been updated in a year, but here is a data sheet: > > http://www.zonedevelopment.com/datmobile.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 > *** > *** 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 New Drivers
Hello, I have released the drivers for the Schlumberger Reflex 72 and the SCM RS110 serial readers on the web site. They are in library form but should work on most Linux machines. The Reflex 72 seems to work with most cards - I have not yet tested T=1 (I didn't write this driver) but seems to have problems with the Cyberflex Access card. The SCM-RS110 works fine on all cards in the PC/SC test suite except the AMMI card. The American Biometric's CardDrive reader driver is also posted on the web site. And another coming soon is the Utimaco serial reader driver which should work with the standard, plus, and their keyboard version I'm going to do some work on pcsc-lite this next week such as Case 4 commands in T=1 and deprecation of SCardReadMemory and SCardWriteMemory and addition of memory card support through MCT specs. Let me know if there is anything else I can add. 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 Chipdrive Mobile?
Hi Jim, The ChipDrive mobile should be a pretty neat unit. It currently only supports i2c memory cards I believe but they are working on a version that will work with CPU cards. There is an onboard irda. There also exists a compiler that allows you to write programs for the ChipDrive mobile for Windows but I think the docs are still in German. Axel from Towitoko might be able to help you out a bit more. I have a couple here and some demo cards for German health cards. They are really nice devices. 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 ***
