For smart cards to be used in a PC environment, it is necessary to have a terminal that is connected to the PC and to have support from the PC software. The difficulty here is naturally that in the past, each type of terminal required its own software driver to be installed in the PC. Each driver in turn had its own software interfaces, so in practice it was not possible to generate terminal-independent software. In the mid-1990s, work began on developing specifications for terminal-independent integration of smart cards into PC programs. This occurred in various countries and was performed by a wide variety of organizations. Internationally, two industrial standards have come to prevail: Personal Computer / Smart Card (PC/SC) and Open Card Framework (OCF). In Germany, as well as other countries, the Multifunktionales Kartenterminal (MKT) specification has been in place for some time. It has achieved surprisingly widespread used within the German-speaking realm. All three of these specifications are described in summary form below, and they can also be obtained free of charge via the Internet.

The first efforts to generate an international specification for linking cards with PC began in May 1996. The companies Bull, Hewlett-Packard, Microsoft, Schlumberger, Siemens Nixdorf, Gemplus, IBM, Sun, Verifone and Toshiba participated in the development of this specification. Version 1.0 of the ‘Interoperability Specification for ICCs and Personal Computer Systems’ was published in December 1997. It consists of eight parts, which are described in Table 11.2. The working group was known as PC/SC (for ‘personal computer / smart card’), and this abbreviation is also used to refer to the specification. It can be obtained via the Internet from the WWW server of the specification group [PC/SC].  integrated into any desired application in a manner that is largely independent of programming language, since it supports widely used languages such as C, C++, Java and Basic. The only prerequisites are that a suitable driver must be available for the terminal to be used and the smart card must be PC/SC-compatible. However, this compatibility requirement is reasonably non-critical, since the scope has been kept relatively broad. The easiest way to gain an overall understanding of the PS/SC specification is to view it in terms of the defined hardware and software components. The following seven components are described in terms of their functions and mutual interfaces:
–ICC-aware application
–ICC service provider
–Crypto service provider
–ICC resource manager
–IFD handler
The tasks and functions of each of these components are briefly described below, in the order in which they are listed above.

ICC-aware application
This is an application that runs on a PC and that wishes to use the functions and data of one or more smart cards. It can also be an application that runs under a multiuser operating system with multitasking and multithreading.

Service provider
The function of the service provider is to encapsulate the individual functions of a smart card, independent of whatever operating system is used in the smart card. For example, it is possible to select a file via the API of the service provider without knowing the smart card command used for this purpose or having any idea of the coding of this command. The service provider component is split into the ICC service provider and the crypto service provider. This is done to avoid problems with export restrictions that many countries have with regard to cryptographic algorithms. The separate crypto service provider, which handles all functions that can cause export problems, can be omitted. In this case, the PC/SC interface can be used for all functions except cryptographic functions. The service provider does not have to be a single piece of software. It can also consist of multiple software components linked by a network. For example, it is possible to locate the crypto service provider on a cryptographically secure or high-performance computer that is isolated from the remainder of the PC/SC components.

ICC resource manager
The ICC resource manager is the most important component of the PC/SC architecture. It manages all resources that are necessary to integrate smart cards into the operating system. It must provide three important functions. First, it is responsible for recognizing connected terminals and smart cards. It must also recognize when a smart card has been inserted or removed from a terminal, and respond to such events by providing suitable messages. Its second function is to manage the allocation of terminals to one or more applications. For this purpose, a terminal resource can be exclusively assigned to a particular application. However, if several applications access the same terminal simultaneously, this terminal must be identified and managed by the ICC resource manager as a shared resource. The third function is to provide transaction primitives. A transaction primitive is formed by binding the commands related to a particular function into a group. This ensures that these commands will be executed in an uninterrupted sequence. Otherwise, it would be possible for two uncoordinated applications to concurrently access a smart card, each using its own sequence of commands. The problems that this would cause can most easily be illustrated by the following example. In a smart card, only one file can be selected at a time. If two different applications attempt to select different files at the same time using SELECT FILE commands and then read data from the smart card using read commands (such as READ BINARY), it is completely undefined which file will actually be read. This depends only on the order in which the commands arrive at the smart card. A much more complicated situation, but no less tricky, arises when it is necessary to perform complex procedures involving several applications interacting with a single smart card (such as paying using an electronic purse). The ICC resource manager ensures that command sequences that belong together cannot be split up or interrupted by other commands, and so ensures that the individual procedures are executed one after the other.

IFD handler
The IFD handler is a sort of driver that is specific to a particular terminal. Its tasks are to link the terminal to the specified interface of the PC and to map the individual characteristics of the terminal onto the PC/SC interface. In a manner of speaking, the IFD handler represents a data channel from the PC to a particular terminal.

IFD (interface device)
The IFD component of the PC/SC specification is a terminal connected to the PC via an interface. The interface is arbitrary, so the terminal can for example be connected to the
computer via an RS232 interface, a universal serial bus (USB) interface or a PC-card interface. The terminal must meet the ISO/IEC 7816-1/2/3 standards, which among other things means that it must support both of the asynchronous data transmission protocols (T = 0 and T = 1). Optionally, it may support synchronous transmission protocols (2-wire, 3-wire and I2C bus) for memory cards, as specified by the ISO/IEC 7816-10 standard. In the terminal, in addition to a display, the PC/SC specification supports a numeric keyboard, a fingerprint scanner and other biometric sensors for user identification.

ICC (integrated chip card)
Microprocessor smart cards that are compatible with the ISO/IEC 7816-1/2/3 standards are required to be supported by the PC/SC specification. Memory cards that comply with the
ISO/IEC 7816-10 standard may also be used, if this is allowed by the terminal.

The Open Card Initiative [OCF] was founded in 1997 by a group of more than 10 companies active in the smart card and PC areas. The objective was to create a smart card interface on PCs that was independent of the operating system of the PC (Windows, Unix etc.) and independent of whatever application might be present in the smart card. The result is Open Card Framework (OCF), a Java-based interface on PCs that can be used to allow applications running on PCs to access applications in smart cards. OCF has become an industry standard in the Java environment.

In Germany, work on generating a specification for linking smart cards to PCs via software began at a relatively early date. This led to the Multifunktionales Kartenterminal (MKT) specification, which has been published in various versions by Teletrust Deutschland since 1994. It is primarily oriented toward the interests of the health care field, but it is now used as a basis for many other types of terminals within Germany. TheMKTspecification is composed of seven parts. Part 1 describes the basicMKTconcept, which contains a basic overview of the software architecture and the MKT terminal. Part 2 specifies the ‘card terminal – integrated chip card’ (CT-ICC) interface. This is the interface for contact-type smart cards using synchronous and asynchronous data transmission. Part 3 contains a description of an application-independent interface for terminals, which is called the ‘card terminal application programming interface’ (CT-API). This interface is independent of any particular programming language and has a procedural structure. It provides the following three functions: ‘CT init’ for initializing a connection, ‘CT data’ for data exchange using an existing connection and ‘CT close’ for closing a connection. This is complemented in Part 4 by the specification of several basic, application-independent commands for controlling terminals, which are called the ‘application-independent card terminal basic command set’ (CT-BCS). Part 5 describes the ATR and general data fields for smart cards using synchronous data transmission. Part 6 contains the associated transmission protocols, as well as corresponding general commands to be sent to the terminal. Based on this, Part 7 specifies the translation of ISO/IEC 7816-4 commands into commands for smart cards using synchronous data transmission, which means memory cards. The MKT specification was one of the first documents of its type in the world, and it has been given an extremely broad basis in Germany by thousands of terminals used with 80 million medical insurance cards. Although it certainly no longer represents the technical state of the art, it will remain a national industry standard for many years to come.

Suitable drivers are required for using smart cards with Linux, as with all other types of PC operating systems. However, for a long time such drivers were not available, which made it rather cumbersome to use smart cards with Linux for operations such as logging on. The first version of MUSCLE (Movement for the Use of Smart Cards in a Linux Environment), which is intended to fill exactly this gap, was published in 2000. With regard to its architecture, MUSCLE is strongly based on PC/SC, but in contrast to PC/SC the source code is openly available under a GPL license [MUSCLE], which means that it can also be modified and further developed by third parties. MUSCLE defines a Linux API that allows smart cards to be accessed in a relatively uncomplicated manner using a connected terminal.