The Pre ALPHA version of the mostly implemented PC/SC Resource Manager is available under code.html of the MUSCLE site. The following is it's README. Please send me any comments, suggestions, and help on fixing this up and finishing it. And heres the README . . . . ************************************************************** This is published under the GNU Public Licence. Please visit http://www.gnu.org for more information. Please see the file LICENSE for more information about the LICENSE for this code ************************************************************** PC/SC Resource Manager ( Part 5 of the Specification ) Version Pre Pre Alpha 0.0.1 Author: David Corcoran PLEASE SEND COMMENTS TO: [EMAIL PROTECTED] This framework is not finished. It is a collaborative effort now and needs ALOT of suggestions and work to be successful. This is part of the framework for the Unix PC/SC Resource Manager. This is one section of a larger infrastructure specified under the documents listed at http://www.smartcardsys.com. Why PC/SC ? Simply, compatibility with the rest of the world. Applications will be more easily ported from Microsoft machines over to Unix and other machines with the PC/SC implementation. While OCF provides a nice framework for Resource Management under Unix, a Java based resource manager is not the solution. This is why a C/C++ based PC/SC resource manager is being built for Unix. What is currently done ? Most of the databasing dealing with smartcards and readers is finished. This databasing keeps track of cards, readers, and groups of readers. These are all done using linked list structures which can be found under the files: ReaderList.c, CardList.c, GroupList.c These classes have static data members so that higher level classes can access the same data elements. The resource manager uses the classes RESOURCEQUERY and RESOURCEDB to perform administrative actions upon this database. RESOURCEQUERY is responsible for querying information about cards, readers, and groups from the database. RESOURCEDB is responsible for adding and removing information from the database. When you insert a reader you must insert a reader with the appropriate Device Name. This reader must exist in the reader.conf configuration file. Some of these functions are NOT fully implemented yet - especially those dealing with cards. The class RESOURCEMANAGER is mainly used to keep track of scope. Eventually when multiple applications will utilize the resource manager we will use the RESOURCEMANAGER class to control this. This is NOT used currently. The class SCARDCOMM is used to open connections to smartcard readers. The function Connect ( which works ) allows you to pass in a friendly reader name and connect to that reader. It will query the database for that readername and grab the appropriate library path and desired port number for that reader from the configuration file reader.conf. Port number is described in Part 3 of the document series. It is actually a few bytes such as: 0x0103F0 is COM1 0x0102F0 is COM2 where the last 16 bits determine the port and the first determine what interface to use (scsi, serial, usb, etc).It will then power up the reader and grab the ATR. Eventually we will use this information to determine which Card Libraries are loaded. msstr.c is a file for doing Microsoft String Array conversions to fixed width arrays. Basically a Microsoft String Array is the following: "value1\0value2\0value3\0value4\0\0" configfile.c helps parse through the configuration file grabbing key/value pairs. This does not work well and should be really looked over. Here is a general overview of the PC/SC infrastructure (SCARDCOMM) (RESOURCEDB,RESOURCEQUERY) ***************************** ********************* * Resource Manager *<------>* Resource Database * ***************************** ********************* | | | ********* ********* ********* * IFD * * IFD * * IFD * (IFD_Handler) ********* ********* ********* | | | READER READER READER | | | CARD CARD CARD The resource manager which controls the readers is actually SCARDCOMM. The IFD's are IFD_Handler interfaces which are vendor specific and OS specific reader drivers conforming to an upper level API called the IFD_Handler API. These IFD_Handler's are dynamically loaded when an appropriate Friendly Reader Name is presented to SCARDCOMM::Connect and the handle to this connection is stored in that object. You will need the following documents from http://www.smartcardsys.com to follow along with what is currently implemented: Part 3: Requirements for PC-Connected Interface Devices Part 5: ICC Resource Manager Definition An IFD_Handler interface has been created for the Reflex 62/64. More readers will soon follow. Note: Card Insertion and Card Removal should generate an event that is thrown to SCARDCOMM. This is not yet done on the Reflex 62/64 IFD_Handler as of now. Please send me any comments on this. Again this is way pre ALPHA stuff and is not finished. Please send all comments to [EMAIL PROTECTED] Thanks Dave ************************************************************* David Corcoran Internet Security/Smartcards Work: Home: Schlumberger Limited 2252 US Highway 52 West 205 Industrial Blvd West Lafayette, IN 47906 Sugar Land, TX 77478 (281) 240-7054 (765) 463-2455 http://www.cs.purdue.edu/homes/corcordt http://www.linuxnet.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 ***************************************************************
