Re: Memory Card support under MUSCLE
Hi The ATR is parsed because the Resource Manager has to determine which protocols can be used on the card and is in charge of sending a PTS when the application has the choice of T=0 or T=1 and chooses the one that is not default. The driver could also do this instead of the RM but when I proposed that I didn't get very positive results from the responses : ) ATRDecodeATR() should ignore any ATR that does not start with 3B or 3F and should assume a memory card instead. Most memory/logic cards support the ISO7816-3 ATR for synchronous cards. This is either 16 or 32 bits long. For cards not supporting the ATR (e.g. card with I2C bus protocol) it is common practice to read the ATR from the first 4 bytes in memory. For memory cards it is the responsibility of the reader driver to select the appropriate protocol, but it still is important for the application to receive the ATR. Quite often the application uses the ATR to determine the size of memory available. The MCT specification contains a definition for the ATR. I think an easy way to do this is to send back a bogus ATR such as Say your ATR for a memory card is: AD FE AC DE 3B 04 ad fe ac de 1) You must send 3B. 2) Then send the memory card's ATR as historical bytes in this bogus ATR . IMHO it should not do that. The most common memory cards (I2C, 2Wire, 3 Wire) return either 8x, 9x or Ax in the first byte. I have not yet seens a memory card that returns 3B or 3F in the ATR. 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 ***
Re: RE :MUSCLE memory-cards and muscle?
Hi Dave I never really understood the reason for handling the transmission protocols at application level. For the application it should not matter, if the card uses T=0, T=1 or a memory card interface, it should just handle command and response APDU's. I suggest to introduce a PROTOCOL_GENERIC, that handles T=0, T=1 or memory card translation internally in the PC/SC (or reader) driver. Maybe that is what PROTOCOL_RAW was initially invented for. Or is anyone out there able to explain the use of the PCI data structure to me ? 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 ***
Re: MUSCLE detect cardtype cardsize
Hi Michael You can determine the size of memory by inspecting the 4 byte ATR returned in the REQUEST_ICC command. Now obviously, this requires a card reader that has this kind of support. If not, you can read the first 4 bytes of memory, which typically contains the ATR. If coded properly, then the second byte contains the size of memory. In our reader driver we use the following code segment to determine the memory size: help = (ctx-ATR[1] 0x78) 3; if(ctx-ATR[1] == 0xff) help = 0x00; if (help) pt-Number_of_Data_Units = 64 help; else pt-Number_of_Data_Units = 256; Hope this helps. Additional information is contained in the MCT specifications. You will find a link on our website. 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 New release of ECO 5000 driver
Hi everyone We've released a new version of the ECO 5000 driver at www.cardcontact.de -- 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 ***
Re: MUSCLE standards
should have 6 historical bytes reserved for identification. 2 for manufacturer id, 2 for manufacturer mask, and 2 for user definition. That makes 65,000 manufacturers, 65,000 masks and 65,000 user defines. The user can only change their 2 bytes. Thus the card can still be identified by it's core OS 2 bytes manufactuer/2 bytes mask. And who is going to register and maintain these identifier ? And why would I need the ATR to identify the card ? What I need is a mechanism to identify the application on the card and I can do that using the AID stored in EF_DIR. PC/SC introducted the concept of identifying the card with the ATR and as you can see, that doesn't really work well. Why do I want Microsoft Plug and Play with a SmartCard ? In most cases I know what I want to do with the card before I insert it into the reader. The ATR is for the pure purpose of defining the interface characteristics for communication between the card and the terminal. Everything else is application. The historical bytes shall be used to offer some proprietary information about the chip, that can be used for diagnostic purposes. ISO7816-4 contains all thats needed in sections 8 - Historical bytes and 9 - Application independent card services. It's up to the application developer to make use of that. 3) ISO-7816 should include a command for the creation of a transparent file and a command for the listing of files. ISO7816 Part 9 - Additional interindustry commands and security attributes does that. 4) Card manufacturers need to be ISO compliant. Class instructions should be standardized to either 00 or C0 or whatever. I should be able to list the directory of files on the card in 1 way on any card. Just pick a card that implements the latest standards that. 5) There must be a standard for putting the keys on the card. If RSA is used then do pq... whatever but in the same order on each card. Also, cards should have the same endianness. This is crazy that people haven't learned their lessons on this one yet. That's a little bit more tricky, as the keys are usually stored in specific areas in the card. This would clearly be the job of a card service provide in PC/SC. On top of that a PKCS#11 layer will do the rest. 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 Status ORGA ECO 5000 Driver
Hi Dave We are currently wrapping up the implementation of support for I2C and SLE4418/4428 cards. With that support we have Serial Data Access Protocol (SDAP, S=8) used for I2C bus chips 3 Wire Bus Protocol (3WBP, S=9) used for SLE4418 and SLE4428 2 Wire Bus Protocol (2WBP, S=10) used for SLE4442,SLE4432, PCB2032 and PCB2042 implemented in the driver. We are also adding PPS at the moment to support a faster communication interface with the new Micardo 2.0 smart card from ORGA. If you need an intermediate version of the driver (probably because you suspect an error in the 0.9.2 version from the web), just let me know. 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 Problem with Parameters in CT-API Interface
Hi all I encountered a severe problem with the current CT-API interface used in MUSCLE. The skeleton defines the interface to be int CT_init(unsigned int Ctn, unsigned int pn) int CT_data(unsigned int ctn, unsigned char *dad, unsigned char *sad, unsigned int lc, unsigned char *cmd, unsigned int *lr, unsigned char *rsp) and int CT_close(unsigned int Ctn) whereas the original CT-API specification defines char CT_init(unsigned short Ctn, unsigned short pn) char CT_data(unsigned short ctn, unsigned char *dad, unsigned char *sad, unsigned short lc, unsigned char *cmd, unsigned short *lr, unsigned char *rsp) and char CT_close(unsigned int Ctn) Most of the type conversions are handled automatically by the compiler, but the problem comes up with the lr parameter in CT_data. Usually the compiler will warn about the size conflict if the program declares a variable unsigned short rlen; CT_data(.., rlen,...) but if it goes undetected it may have severe results, because it overwrites data objects on the stack located beside the rlen variable (As happend in my case and which cause a fairly long debugging session). I know that this is an ugly problem, but I would still recommend to change the interface declaration to archive cross platform compatibility and avoid hard to find errors as the one above. Any comments ? -- 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 ***
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 Data SW1 SW2 Case 3: CLA INS P1 P2 Le Data SW1 SW2 Case 4: CLA INS P1 P2 Lc Data Le Data 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 Data SW1 SW2 Case 3: CLA INS P1 P2 P3=Le Data SW1 SW2 as said before a Case 4 command would be handled like Case 4: CLA INS P1 P2 P3=Lc Data SW1 SW2 CLA INS='C0' P1='00' P2='00' P3=Le Data 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 ***
