The above techniques relates to the card and the application program.
Programming the application and the reader interface must also be considered in the same way.
The solution to this is to manage the readers separately from the application(s) and provide a common reader API interface. Reader vendors in turn can conform to this API enabling them to readily enter the market.
This is the PC/SC Interface Specification (V1.0) published by the PC/SC
Workgroup. More details about this workgroup and the specification is given in 3.5, “PC/SC” on page 32. At the time of writing, PC/SC only addresses the PC Windows 9x/NT 32-bit platforms (PC/SC requires multithreading). Support for 16-bit Windows is not available and would depend on future customer demand.
The architecture of PC/SC is shown in Figure 40 on page 132.
Figure 40. PC/SC Architecture
The PC/SC consists of a Resource Manager, which is responsible for all the readers attached to the workstation, and Service Providers, which are
responsible for providing a high level common interface to the smart cards and cryptographic functions. The reader vendors would provide the device drivers (IFD Handlers) in the diagram and the operating system would supply the Service Providers with their smart cards. At the time of writing, PC/SC is strongly associated with the Resource Manager, the reader management interface. The Service Provider Interface is available as a recommended way in which to code the high-level API for software vendors and developers to
implement. The Service Provider is dispatched using the ATR (See 8.3.1,
“Answer to Reset (ATR)” on page 96).
The reader interfacing problems are solved by the PC/SC specification by providing:
• A high-level common reader programming interface for the application developer
• The programming specification for vendors to conform, in order to construct PC/SC compatible reader device drivers
The following example illustrates the commands used in the PC/SC Interface code:
SCardEstablishContext: command issued by your application to the PC/SC interface, establishes a context for subsequent calls to the PC/SC Resource Manager.
SCardEstablishContext(SCARD_SCOPE_USER, ..., hContext);
SCardListReaders: command provides a list of available readers within a group.
SCardListReaders(hContext, Groups, Readers,...);
SCardConnect: command establishes a link to the card in the selected reader. If no card is present this is passed back through a return code.
SCardConnect(hContext, ReaderName, SCARD_SHARE_EXCLUSIVE, SCARD_PROTOCOL_T1, hCard,...);
SCardGetAttrib: gets the reader attributes, for example the reader vendor′s name.
SCardGetAttrib(hCard, SCARD_ATTR_VENDOR_NAME,...);
SCardGetAttrib: gets the card′s attributes, in this instance the card′s ATR response.
SCardGetAttrib(hCard, SCARD_ATR_STRING,...);
SCardTransmit: is an example where you might want to issue a raw APDU command to the card.
SCardTransmit(hCard, MY_SCARD, SELECT_3F00, ...);
SCardDisconnect: terminates a previously connected card.
SCardDisconnect(hCard, SCARD_EJECT_CARD);
SCardReleaseContext: closes an established context to the Resource Manager, freeing up any resources allocated under that context.
SCardReleaseContext(hContext);
There are many other commands available. For more details, see Table 11 on page 137 for PC/SC reference information and software development kit.
The PC/SC Interface allows a developer to handle any PC/SC compliant reader without the need to include reader-specific APIs.
10.5 OpenCard Framework
The next question is whether we can improve things further for the developer by providing a consistent interface, not only to the card operating system, reader and cryptographic interfaces, but also to the applications on the smart card card.
We could wrap up everything nicely if our application could be freed from having to keep checking for a particular card insertion or trying to monitor what′s happenning with the card reader.
Well, you′ve guessed right. This is the OpenCard Framework.
The OpenCard Framework hides the complexities of smart card programming from the user by clearly encapsulating the technological components. The OpenCard Framework is coded in Java; its target platforms are network computers, Web browsers, or any future platform that runs Java and has to interact with smart cards.
More information about the OpenCard Framework is described in Appendix D,
“Overview of OpenCard Framework” on page 185 and information on programming is listed in Table 11 on page 137.
The two most important layers of the OpenCard Framework are:
• The CardService (handles different card operating systems and allows sharing of the smart card)
• And the CardTerminal component (handles different readers; for instance, what to do when a card with a particular ATR is inserted)
All the components in OCF are implemented as Java class libraries. For
example, the CardService package is opencard.core.service class library and the CardTerminal package is opencard.core.terminal class library.
These packages have specific interfaces to supply functions for the application developer. For example, to read the cardholder′s name, we need access to the smart card′s file system, which is provided by the FileSystemCardService interface (CardService package). Access to the card reader is provided by the CardTerminalRegistry interface (CardTerminal package), which knows about the addition and removal of card terminals..
The starting point for most applications is perhaps the SmartCard class, which presents the physical smart card to the application developer. OCF supports both the application-driven model, for example waitForCard() or the event-driven model, for example, by implementing the event listener interface.
If the event-driven model is used, the application informs the
CardTerminalRegistry that it is interested in receiving information about cards being inserted and uses the method addCTListener() method of the
CardTerminalRegistry. If the application-driven model is used, the application passes along a CardRequest and specifies what kind of card, which card terminal, whether to use an already inserted card, and even what kinds of CardServices the card should support.
With these basic OCF services, we have written a sample program; see Appendix E, “Sample OCF Code - GTTEmployeeCard.java.” on page 191.