Fundamentals of Smart Cards with Pcs

Fundamentals of smart cards with PCs – the view in autumn 2002

Author:Peter Tomlinson ()

Date:10 October 2002

Historically, there is a typical software model when using a PC to handle a microprocessor smart card (a card conforming to ISO/IEC 7816 parts 3 and 4, or to an equivalent such as EMV’s card spec). During operation (i.e. after card startup and application selection) the model is:

PC application software

Card driver

Card reader driver

(Physical interface to card reader)

Card reader software

(Physical interface to card)

Card OS I/O functions (more like a BIOS)

Card command interpreter (part of card OS)

(which passes most commands through to the card application software as soon as an application is selected)

Card application software

Card OS internal functions (more like a BIOS)

Within this model, it is the PC application software that needs to communicate with the card application software for the desired result to be produced. Logically, messages pass between those two layers in order to carry out the required functions. These messages pass through all the layers in between, and the application in the card refers to the Card OS for support services.

Card startup works differently from card operation:

1.The card reader software detects the card and starts it up. Card startup is an electrical process, during which the card reader software sequences power and signals to the card. Once the card is started, it sends the Answer To Reset (ATR), which is a string of up to 32 bytes – note that this is normally the only time that the card sends unsolicited information to the card reader (i.e. after this, the card is always a slave to the card reader), although it is possible for the reader to cycle the card through only part of the startup process (a ‘Warm reset’ instead of a ‘Cold Reset’) in order to reset the card and cause it to send an ATR again. The card reader uses parameter bytes from the ATR (see 7816-3) to configure the reader and, if necessary and possible, sends a command to the card to request it to reconfigure its interface (e.g. change data transmission speed). The ATR also has ‘historical bytes’, which may be structured according to a definition in ISO/IEC 7816-4, or may, after a 7816-compliant first byte, have a private structure.

2.The card reader then makes the ATR available to the PC. Information in the ATR may be used by any of the software layers in the PC – for example, the application may be interested in the cash balance returned in the historical bytes by a Mondex card.

Once all the layers of software are satisfied with the status of every other layer and of the card, the application layer in the PC can proceed to select an application in the card and communicate with it. But if any layer is not satisfied, it is likely that the applications in terminal and card will not be able to function together. Since there is no overall control, the situation where one or more layers are not satisfied may give rise to imprecise or misleading error messages, or even just a refusal to function.

Some schemes work differently: they do not have application software in the card, but instead just store data in the card, using ISO/IEC 7816-4 commands. 7816-4 gives so much freedom to implement commands that each card type is usually different from every other card type in this area, and a particular card type may change details of its spec as new versions are released. With other parts of 7816-4 defining other commands (e.g. for security processes such as PIN handling), the problems become very complex. And, of course, some schemes have both data (held in files) and application software in the card, although it should be understood that the 7816 model is that data stored at the same level as application code (under the same Directory File (DF) or daughter DFs) is accessible only via the application.

Some configurations of card, card reader and PC software are going to work, some are not. Typically, if card and card reader come from the same supplier, the supplier will ensure that all the software layers up to and including the card driver in the PC will work with each other and with the hardware. If the developer of a card scheme wishes to purchase, say, the card from one supplier and the card reader from another supplier, then the purchaser has to negotiate with suppliers in order to (a) find out if between them they are supplying software that will make the configuration work, or (b) find out how to alter the software (usually only the software in the PC) to make the configuration work. If solution (b) is the route chosen, the developer has to obtain all the necessary specifications and arrange for software development to be done.

The first big warning: those attempting to develop card schemes have to ensure that they obtain detailed specifications of interfaces and understand how their configuration works. There is no such thing as a software and hardware suite that insulates the scheme developer from the underlying technology in the way that, for example, Visual Basic does for standard peripherals. Microsoft intended to provide such a suite within the WfSC offering, but abandoned WfSC last year.

At a lower level, numerous attempts have been made, and are being made, to make the matching of card, card reader, and software easier. Part of this is also dealing with the problem of being able to use more than one type of card with a particular combination of PC software and card reader.

PC/SC and OCF software both aim to provide wrappers for the combination of card driver and card reader driver, so that adapting to different cards and different card readers becomes easier. But both PC/SC and OCF libraries are incomplete, because development support was discontinued about 2 years ago.

The MUSCLE work aims to do the same as PC/SC and OCF, although in some cases MUSCLE software gets combined with versions of PC/SC in an even more complex configuration. But MUSCLE is Open Source, and so there is no group or company that takes legal and commercial responsibility for the software. That said, as with other Open Source groups who are active, software developers for MUSCLE have an excellent reputation for quality and support of their software.

The Java card consortium aims to make life very simple once the card has been started up: it mandates a single method for selecting an application in a card (where 7816 allows several methods), and further mandates that, after application selection, all commands received by the card (except another application selection command – and there is a version of app select which is effectively ‘deselect’) must be sent straight to the application. Unfortunately, the Java card spec fails to understand that some card security management processes require certain commands to be interpreted by the card platform (the OS) – commands such as ‘block the card’ to stop it operating – and therefore different cards continue to work differently at this management level. For conformance with the Java card spec, the card OS has to be compliant with the Java Card Run-time Environment (JCRE) spec (and some cards on the market are not compliant, even if they allow applications to be written in java).

Global Platform tries to allow both Java cards and more general ISO cards to be handled by a common set of software in the card reader and PC, but again the card OS has to be compliant, and very few cards on the market claim to be compliant. GP’s specification development work is not complete, so it is not yet guaranteed that GP cards from different manufacturers are interchangeable. Also, there is no test and certification service available for GP cards, so you cannot get independent proof of compliance. (By contrast, when a card claims compliance with the JCRE, it can be checked against a reference model developed by Sun, who are the owners of the JCRE; maintenance of the JCRE spec is unusual, because it is in the hands of a group of volunteers, yet Sun takes ownership of the result.)

Where does this lead the developer of a scheme using smart cards?

Evaluation of a concept can be carried out by obtaining cards, card readers, and PC support software from a single supplier. The application software developer then writes the application software using the API provided by the supplier. Evaluation may also proceed using PC/SC, OCF or MUSCLE software in the PC (for the risks, see the next paragraph) – MUSCLE, when you use the recommended combinations of card and card reader, seems to be particularly appropriate as long as the PC runs linux.

Development of a small scale scheme that may have to change to other suppliers or types of cards and/or card readers can be carried out in the same way as for an evaluation project, but the risk is that the scheme owner is tied into one supplier. This tie-in is historically the position that suppliers prefer. At the next level, the scheme developers can use a support package such as PC/SC, OCF, or MUSCLE. This (a) allows a limited selection of card and card reader (limited to the list of products supported by the package, or supported by suppliers for developers using those packages), and (b) means that the developer must understand that support for software in the packages is not guaranteed (so developers may have to fix problems themselves).

At this point there is the second big warning: if more than one type of card is to be used in a scheme, there is no guarantee that the card reader and PC will be able to recognise which type of card has been presented to the reader, and there is usually no guarantee that the next batch of any one type of cards purchased will not be different from the previous batch of supposedly the same type of card. You cannot rely on the ATR to provide a guaranteed way of identifying a card type. The attitude of major suppliers is that every supplier of cards should migrate to Global Platform compliance, and then the problem will go away. The attitude of the EMV (payment scheme specs) consortium is that all cards hosting a payment application defined by them must start in the way that EMV mandates, allow application selection using the mechanism that EMV mandates, and do some other things in the way that EMV mandates – not every supplier of multi-application card platforms wants to do this. (Since there are a whole range of differences between the EMV spec and the ISO/IEC 7816 standard, we have a stand-off that the industry refuses to resolve in any agreed manner.)

Allied to that warning is the problem that there are no general-purpose plugins that enable popular web browsers to use a variety of smart card types.

In the general case of emerging commercial and citizen card schemes, a scheme has to accept that its application will be hosted on a range of multi-application cards, alongside other applications, as well as possibly being hosted on single application cards issued by the scheme. This means that the scheme must be able to recognise the card platform (and know how to drive it), and then find its own application among several others – this has to be done quickly, reliably, and without interfering with other schemes. This general problem has not been solved, although a good deal of work is being done to try to solve it, and also to try to persuade legislators to help by making rules governing this situation. In Europe, the e-Europe Smart Cards initiative (eESC) is coming to the end of its 3 year life, and will be reporting on the size and scope of a lot of the problems, with recommendations for attacking them. The Japanese are using their national identity card programme to develop interoperability proposals (NICCS). The USA is running behind, with the Global Platform development having wide support, and now their public sector identity card project (NIST’s GSC-IS, and its military implementation as the CAC – Common Access Card) is coming up behind GP.