Driver Utimaco Card Man Usb
These are some notes on my experience in getting Linux tocommunicate with the University Smartcard, together with assortedlinks and background information. The object of the exercise is partlyto gain familiarity with the technology, but also to investigate thepossibility of using the smartcard to provide authentication servicesto OpenSSL.
Driver Utimaco Card Man Usb
My conclusions to date is that Linux smartcard support is flaky atbest, and there is little that works 'out of the box'. However it isclear that the technology can be made to work under somecircumstances. I suspect that this is because, while the variouselements (cards, readers, interface software) are well standardized,these standards are complex and rarely completely and correctlyimplemented. As a result a particular combination of card, reader andsoftware may work for a particular application (perhaps afterconsiderable work) but an arbitrary choice of components may beproblematic.
The behavior of smartcards incorporating CPU chips, such as theCambridge card, is defined in ISO7816 (and some other standards). Thereis a summary of parts 1-3 of the standard (covering Physicalcharacteristics, Dimensions and location of the contacts, andElectronic signals and transmission protocols) at ,and what looks like a bad OCR of part 4 (Interindustry command forinterchange) at a better general reference work is Smart Card Handbook, Wolfgang Rankl and Wolfgang Effing, 2nd Edition, John Wiley and Sons Ltd; ISBN: 0471988758. Unfortunately it's both big and expensive.
In essence, a card and card reader communicate using a byteorientated serial protocol. The reader sends a command along withparameters and optional data, and the card replies with a statusindication and optional reply data. Documents commonly refers to thesecommands as APDUs (Application Protocol Data Units). Thesecommands are defined in ISO7861 part 4, and there is a useful summaryof the commands that the Cambridge card accepts at -APDU.html. Understandingthese APDUs is important, since most of the programming APIsprovide, in essence, a means of sending APDUs to the card andof retrieving the responses.
ISO7816 cards implement permanent data storage as a tree-like'file system'. Nodes in the tree are either 'Dedicated Files'(DF), which roughly correspond to directories, or 'ElementaryFiles' (EF) containing actual data. Nodes are identified bytwo byte 'file identifiers', and the root of the structure is aDF called the 'Master File' (MF) with fileidentifier '0x3f00'. There is a useful diagram showing this(for a different card from the Cambridge one) at _seminar/6.html. Commandsexist for navigating this tree, retrieving and setting data values,etc. There are also commands for non-file relate actions such as keyretrieval, data signing, etc. Files can also have access controlsapplied to them. These can, for example, require that a particular PINbe supplied to the card before a particular file can be accessed.
There appears to be little standardization of what various 'files' areused for, leaving such definition up to each smartcardapplication. The files used on the Cambridge card are documented at -files.html. [Notethat 'sfi' as shown in this list is a 'short file identifier' thatprovides direct access to selected files].
Card readers interface with cards as described above, and interfacewith computers over RS323 serial lines, USB, PCMCIA, etc. There is nostandardization of this interface (except sometimes within onemanufacturer's products). To avoid making programs reader-dependent, itis usual to implement a reader-dependent driver that exposes areader-independent programming API.
Under Windows, the 'winscard' interface provides such an API, andis supported by operating system services and device drivers. winscardis 'standardized' by the PC/SC Workgroup, ,and the API is commonly referred to as PC/SC (Personal Computer/Smart Card).
Under Linux, a cut-down version of PC/SC calledPCSC-Lite has been implemented by the MUSCLE(Movement for the Use of Smartcards in a Linux Environment)project. PCSC-Lite consists of a user-callable library(libpcsclite) which implements the PC/SC interface -see -lite-0.7.3.pdf. Thiscommunicates over a Unix domain socket with a daemon (pcscd),which in turn talks to one or more card readers using 'IFD'drivers. These drivers are shared libraries loaded by pcscdas required; their specification is at Notethat, while I have been unable to find any documentation for this,there appear to be two versions of the IFD specification:version one that used routines with names beginning 'IO_' and'IFD_', and version two that uses routines beginning'IFD'. pcscd is able to use drivers based on eitherversion.
An alternative API is provided by the sc7816 librarydeveloped by the Centre for Information Technology Integration at theUniversity of Michigan - see Thisuses the same IFD drivers as pcscd, though hasapparently only been tested with Michigan's own driver for the TodosArgos Mini reader. It also appears to only support IFDversion 1 drivers. A number of utility programs are available thatwork against this interface, though much of the work is based onJava-capable cards, which ours isn't. Note that with this interfacethe serial port (or other interface) connecting the card reader mustbe accessible by the id under which the client program runs; usingpscd it's only necessary for the port to be accessible by theid under which the daemon runs.
There is a Perl interface to pcsc: -perl-1.0.8.tar.gz.Cambridge card utilitiesGraham Phillips, currently from the Centre for Applied Research inEducation Technology (CARET) (graham@caret.cam.ac.uk),wrote a set of utility programs for the Cambridge card that run underWindows: Change PIN, View card, Quick identifier, Extract certificate(see ).He also wrote a module that implements a pkcs#11 interface toallow Windows Netscape to use the certificate on the card for SSLauthentication.
Rich Wareham (richwareham@users.sourceforge.net)has produced a similar set for Linux - see (and rjw57/sc/and rjw57/sc/software/).Rich's libcamcard C++ class library provides a usefulreference for the APDUs needed to work with the Cambridgecard. I found some of Rich's programs problematic:
As mentioned above, getting Linux programs to talk to the Cambridgecard is something of a hit-and-miss affair, and depends onexactly which reader, driver and software you are using. Myexperience with a number of example readers is set out below.
The 'standard' driver for this reader appears to belibGemPC410.so ( -GemPC/ifd-GemPC.html),which now replaces the earlier libgp-core.so ( -core-2.4.0.tar.gzand/or -core/gp-core.html).While both drivers (version 2.4.0 of libgp-core.so andlibGemPC410 from version 0.5.9 of ifd-GemPC)appeared to be able to talk to the reader, neither would talk to theCambridge card.
It looks as if this is the same problem Rich discovered, and whichresulted in him producing libcamgemcore.so, a modifiedversion of libgp-core.so that addresses some problems withthe original driver (see thismessage, thisentire thread and this message from the sclinux mailing list for somefurther details of this). Using v. 1.1.0 of libcamgemcore.soit was indeed possible to successfully communicate with theCambridge card and extract useful information.
This is a different serial reader from GemPlus. It looks verysimilar to the GemPC410, and seems to be considered by many people tobe identical. However there is no doubt that this is not the case:while all of libgp-core.so, libGemPC410.so andlibcamgemcore.so appeared to be able to communicate with thereader, none would communicate with the Cambridge card. If ithelps to distinguish between the two versions, my GCR410 was marked onthe base 'M/N: GCR410-2', while the PC410 was marked 'M/N:GemPC410'. The GemPC version also had a 'Designed for WindowsNT/Windows98' sticker on the back. It identified itself as containingfirmware version GemCore-R1.10-0M8.
This is a USB reader from GemPlus. It appears to be supported by thelibGemPC430.so library from ( -GemPC/ifd-GemPC.html).The copy from v. 0.5.9 of IFD-GemPC appears to at least initially beable to communicate with the reader. However attempts to communicatewith the card result in timeout error messages and the following in thesystem log:
With this I had some but limited success. A cut-down version ofRich's scardkbd will read the user-id field from the cardfairly reliably. However kcardview appears to work butreports a user-id of "Card" and an expire date of "Empty" (consistentwith the attempt to communicate with the cardfailing). scardkbd works the first time a card is insertedbut causes pcscd to hang when the next card is inserted. Thislatter seems to be somehow related to the SCARD_RESET_CARD state usedwhen disconnecting from the card, changing this to SCARD_EJECT_CARDseems to work around the problem. I suspect that many of theseproblems may be due to shortcomings in the CyberMouse reader itselfand/or the IFD driver. The SCEZ website notes:
The pl2303 driver does seem to be present in kernel version2.4.9-21. However attempts to use the reader resulted in the testmachine repeatedly hard-hanging the second time pcsc was started aftereach reboot, and so further tests were discontinued.
However this does look like a nicereader, and the driver code looks (at a first glance) to be of goodquality. And it includes a CT-API for good measure. The only problemso far is with driving the USB interface and virtually identicalreaders are available with a serial interface. I think a serialTowitoko reader would be worth a further look.
The driver consists of a shared library (libcm2020.so) anda kernel module, which are supplied ready-compiled withoutsource. Unlike other USB Muscle drivers which are auto-detected, thisdriver requires configuration in the /etc/readers.conffile normally used for serial configurations.
Infineon`s security solutions serve applications ranging from smart cards to new, emerging use cases. Our core competencies include tailor-made security, contactless technology as well as embedded control.