Computer Networks 36 (2001) 473487

www.elsevier.com/locate/comnet

Standards in the smart card world

Dirk Husemann
IBM Research Division, IBM Zurich Research Lab, Sumerstrasse 4, 8803 Rschlikon, Switzerland a u

Abstract In this paper, I take you on a guided tour through the world of smart card standards. We briey touch ISO 7816, the dening standards for smart cards; then we take a longer look at current de-facto standards for smart card operating systems (SCOSs) such as JavaCard, MULTOS, BasicCard, and Windows for Smart Cards. The paper concludes with a discussion of PC/SC, MUSCLE, and the OpenCard Framework which are smart card middlewares for smart cardapplication communication. 2001 Elsevier Science B.V. All rights reserved.
Keywords: Smart card; Smartcard; ISO 7816; JavaCard; MULTOS; Mondex; Windows for Smart Card; BasicCard; PC/SC; OpenCard Framework; OCF; MUSCLE; Linux

The nice thing about standards is that there are so many to choose from. Andrew Tanenbaum Smart cards have been with us for the last quarter of a century Roland Moreno [1] not only obtained a patent in 1974 on the concept of a smart card as we know it today but also patents on how to produce smart cards eciently [2,3]. 1 The features that make them so appealing for application developers are next to their small size their ability to store data in a secure manner and to run small programs. Whereas originally used for banking and telecommunication applications (e.g., as phone cards), in the last couple of years we have come to use smart cards in a much broader sense; they have become enablers for a wide range of e-business systems.
E-mail address: hud@zurich.ibm.com (D. Husemann). The earliest research into smart cards was probably done by two German inventors, Jrgen Dethlo and Helmut Gr trupp. u o In 1968, they patented their idea of using plastic cards as a carrier for micro chips.
1

You might expect that with such a long history (using Internet time we would be talking about mid 18th century technology here) the world of smart cards would be a fairly well established and standardized aair. Well, not quite. In fact, looking at the plethora of smart card systems and `standards' that either are deployed or are proposed, we rather might come to the conclusion that the terms smart card and standard do not really go well together. Indeed, we have not even agreed on a common way of spelling: some use smartcard, others smart card. 2 To make matters even more confusing, we might be talking about two dierent things when we speak of smart card standards. We might talk about standards for the smart card, the piece of plastic, itself yet we could also be speaking about the software, the middleware, that an application requires to communicate with the smart card.

For this article I shall use the separated spelling.

1389-1286/01/$ - see front matter 2001 Elsevier Science B.V. All rights reserved. PII: S 1 3 8 9 - 1 2 8 6 ( 0 1 ) 0 0 1 6 7 - 0

474

D. Husemann / Computer Networks 36 (2001) 473487

Fig. 1. Standards for smart cards. We destinguish between standards (de-facto and de-jure) that deal with the actual smart card itself (e.g., ISO 7816, JavaCard, MULTOS, etc.) and those that enable applications running on a host to communicate with a smart card (e.g., OCF and PC/SC).

My goal with this article is to take you on a tour through some of the smart card standards, shown in Fig. 1, that enjoy a wide spread support in the industry. We shall take a look at ISO 7816 in Section 1, the dening standard for smart cards, then, in Section 2, discuss standards that specify the smart card operating system (SCOS) and applications on the smart card. We shall conclude in Section 3 with an overview of the two currently available middleware standards that specify an Application Programming Interface (API) for communicating with a smart card. 1. Common ground The basis of all smart card standards is the international standard ISO 7816. It denes physical characteristics of smart cards (ISO 7816-1), the location and dimension of the contacts (ISO 78162), electrical signals along with low-level transport (ISO 7816-3) and high-level application (ISO 78164) communication protocols. Other parts of ISO 7816 (parts 510) address issues such as numbering systems and registration procedures for smart card applications, tag-length-value data structures, enhanced smart card commands (mutual authentication, Structured Query Language (SQL) access, encryption), and more. Part 4 of ISO 7816 is from an application developer's point of view the most important part of ISO 7816 as it species the standard communication protocol data units, termed Application Protocol Data Units (APDUs). Moreover, ISO 7816-4 describes how the data storage on a smart card might be organized as a le system.

Although ISO 7816 does a very good job of laying the ground work for smart cards, it is not very specic where the really interesting part is concerned: interoperability. Most of the APDU denitions contained in ISO 7816-4 are optional, and being a true ISO standard ISO 7816-4 leaves a lot of loopholes open so that we can create a smart card for which we can claim compliance to ISO 7816, yet, aside from our own application no other application will be able to talk to our card. In addition, nobody can force any given smart card provider to implement any of the later parts of ISO 7816. It is illustrative of the fractured nature of the smart card world, that the European Telecommunications Standards Institute (ETSI) has issued its own set of smart card protocols, CEN726, that denes very much the same things as ISO 7816. Fortunately, CEN726 and ISO 7816 agree on the format of the APDUs, basic instruction set and return codes. 2. Smart card OS standards As the smart card is a computer en miniature it contains an operating system (OS) to run applications and to provide resources for those applications. The SCOS controls the serial interface to the outside world (i.e., the card terminal) and, thus, the communication between applications running on the card and applications running on the host attached to the card terminal (see Fig. 2). In addition, the SCOS implements features such as an ISO 7816-4 le system or SQL access. Until recently, smart card programming typically has been the domain of the smart card manufacturers. Each manufacturer provided its own, proprietary version of an ISO 7816 compliant SCOS. Very rarely would you encounter the same SCOS on cards from dierent manufacturers (and even then each manufacturer would in all likelihood have added extra features obliterating the compatibility). Programming both on-card and external applications required fairly intimate knowledge of the SCOS on a particular card. Switching smart card suppliers meant reimple-

D. Husemann / Computer Networks 36 (2001) 473487

475

Fig. 2. SCOS. The SCOS supports applications running on the smart card (on-card applications) and controls the communication between on-card applications and external applications running on a host computer.

menting your on-card applications from scratch depending on the SCOS, the host application could be concerned in addition. Once a smart card was issued to the customer it was rather dicult and most often next to impossible to update a smart card or even install new on-card applications on it. Smart cards with multiple applications on-card meant that all parties concerned had to get together and create the smart card image in a cooperative eort often requiring the creation of special legal entities along with the multi-application smart card. Thanks to recent industry eorts the situation has changed, however. Eorts such as the JavaCard Forum [4] or the Maosco consortium [5] dene standard smart card platforms that allow independent application developers access to the smart card without requiring them to enter into a tight contractual relationship with the respective smart card manufacturer. Other eorts are Microsoft's Windows for Smart Cards [6] but also the BasicCard by ZeitControl [7]. All of the mentioned SCOS platforms utilize a virtual machine (VM) concept: on-card applications are developed on a host system, compiled to some form of bytecode, and then downloaded to the smart card. The VM that is part of the SCOS interprets the bytecode and executes it. Also applications can only be installed on the smart card if signed with an appropriate cryptographic key. The ideas behind these eorts are quite simple and appealing:

Instead of having a plethora of dierent SCOSs along with a wide variety of dierent APIs and various programming languages, a standard smart card platform allows application developers to use a portable language to write their applications against a standardized set of APIs. Furthermore, the VM concept allows for smart card updates in the eld; that is, applications can be exchanged or added after the smart card has been issued. As none of the proprietary SCOS never really gained the status of being even an industry standard, we shall concentrate on the open development platforms JavaCard, MULTOS, BasicCard, and Windows for Smart Cards and discuss them in the following sections. Of particular interest are the languages being used, the ability to host multiple applications at the same time, whether the SCOS supports dynamic download, the development model imposed, the way the card protects itself (if at all), the functional components available with the various SCOS, and whether the code is portable. We shall start o with the JavaCard platform as that platform is well published, deals with most of the issues arising with this kind of smart card platform, and lends itself well as the yard stick to compare the other platforms against. 2.1. JavaCard The best known of the four platforms is probably the JavaCard platform. The JavaCard Forum, originally founded in 1997 by Gemplus and Schlumberger, has dened a set of APIs and a stripped down version of the Java virtual machine (JVM) for use on smart cards. In addition to the features that I mentioned in the previous section the main idea behind the JavaCard was that one would have one language across the whole platform spectrum: from the mainframe to the PC to the Network Computer down to the smart card. In comparison with the standard Java (as known from the PC) JavaCard in its current version 2.1 does impose quite a few restrictions on the Java programmer: several data types, such as Float, Double, and Long, are not available; threading is not supported; the bytecode is

476

D. Husemann / Computer Networks 36 (2001) 473487

dierent [8]. Considering the resources that a typical smart card can oer (anywhere between 16 and 32 KB or ROM, between 8 and 16 KB of EEPROM, and 2561024 B of RAM) these restrictions are not surprising and do not seem to be too restrictive on the programmer. Viewed from the outside a JavaCard behaves just like any other ISO 7816 compliant card (see Fig. 3). You talk to it using the standard transport protocols (T 0, T 1) and the standard APDU formats. Conceptually, the JavaCard is a server: instead of an RPC message or an HTTP request we send a Command APDU to the JavaCard; the JavaCard examines the received Command APDU and then either activates an on-card application (called applet in the JavaCard world) or just forwards the Command APDU to a previously activated applet. Either the applet or the smart card OS itself returns one or more response APDUs. The two main promises of JavaCard are the ability to install or update applets dynamically even after the card has been issued to the customer, and portability of code. Strangely enough, however, both issues were addressed rather late. In April 1998 Visa, not being satised with the situation, introduced the Visa Open Platform (VOP) specication now part of the GlobalPlatform organization to dene an architecture for installing and managing applets on multi-application cards. The main thrust of VOP is to dene standard methods to install applications in a secure manner.

Fig. 3. JavaCard architecture. The smart card functions similar to a normal server: instead of remote function invocations or messages it receives Command APDUs and passes them on to the on-card applications (applets). The applets utilize standard class libraries and return response APDUs to the outside world.

In contrast to the normal Java runtime environment (as found, for example, on a PC) the JavaCard JVM does not verify the downloaded bytecode as a rule. The current version of JavaCard allows for optional bytecode verication but relies for security on code signing and a rewall mechanism: as part of the secure install process the applet is evaluated and converted to the format understood by the JavaCard; after conversion it is signed with the secret key of the card issuer. In addition to code signing JavaCard uses a rewalling mechanism where objects on the JavaCard are tied to the applets that `own' these objects. Access to these objects can only take place after the JVM has checked for proper access rights. Another issue that was hampering JavaCard until the advent of the 2.1 specication was the question of the load le format: anybody familiar with Java knows that Java source code is compiled into Java class les. The class les contain the bytecode that the JVM can interpret and run. With JavaCard we have to go one step further as the normal class le format contains a lot of information that is not required for execution on a smart card or that would simply not t the constricted space provided by current smart card. Thus, we need to convert and compress the class les into converted applet les (CAP les). Each CAP le comprises classes belonging to one package. With the Open Platform install method and the JavaCard 2.1 CAP le format specication we now have a smart card platform that allows for secure installation and upgrade of portable applets. The applet development process for JavaCard (see also Fig. 4) is rather similar to the normal Java development process: the Java source code for an applet is compiled using the normal javac compiler, the resulting Java class les then need to be evaluated and compressed into a CAP le and signed. Most JavaCard development environments oer JavaCard simulators that allow you to test and debug your applet before you actually install it to the JavaCard. The basic JavaCard APIs provide access to functionality such as APDU handling, application

D. Husemann / Computer Networks 36 (2001) 473487

477

Fig. 4. JavaCard development process. Developing for JavaCard is not very dierent from normal Java program development. The Java source code for the applet is compiled using the run-of-the-mill javac Java compiler. Most JavaCard development kits include a simulation environment that can be used to debug the applet without actually going to the JavaCard itself. Following the compilation step all class les constituting the applet package are converted into a JavaCard CAP le and signed. The CAP le can then be installed onto any JavaCard 2.1 compliant card.

identiers (as specied by ISO 7816-5), transaction support, shareable interfaces, and utility functions for array operations. The transaction support is particularly notable as we have to expect the normally unexpected to happen when we program applications for smart cards: the smart card can be pulled from the card terminal at any moment and, thus, lose power at any moment. The design of our on-card application (and sometimes of the host application as well) needs to take this factor into account; transaction support by the SCOS therefore is quite important. Note, that support of cryptographic capabilities currently seems to be a matter of implementation: some JavaCard implementations oer a range of cryptographic functions (comparable to those oered by MULTOS, see Section 2.2), others for export control reasons oer either no cryptographic support or just very little. 2.2. MULTOS MULTOS is another initiative aimed at providing a common SCOS platform. Originating with Mondex, the electronic payment card scheme, it is now owned and being driven by the MAOSCO Consortium [5]. MULTOS comprises the API, the OS, and the silicon chip. Also part of the MULTOS story is the assembler language MEL (MULTOS Executable Language) in which all MULTOS applications are (ultimately) written. Like JavaCard, MULTOS is a true multi-application smart card that supports dynamic and secure download. Similar to JavaCard, on-card applications need to be signed cryptographically. Also MULTOS claims the same level of security as

JavaCard does and employs a rewall mechanism as well. MULTOS claims to be broader in its scope than JavaCard. This claim seems to be true in as much as MULTOS not only species the APIs but also the OS and provides, in addition, type certication and a certication authority. Although, the MAOSCO consortium calls MULTOS an open standard, access to the API documentation or a developer's guide is license controlled in contrast to JavaCard. The currently available MULTOS smart card implementations from Hitachi and Siemens oer cryptographic function support for DES, triple DES, and up to 1024 bit RSA as well as transaction support. Three dierent development environments are available: MDS from GTI-UK, MULTOS Development Environment from Hitachi, and SwiftCard/MEL from SwiftCard Technologies. The SwiftCard/MEL tools support not only the MULTOS assembler language MEL but also C and Java as input language. 3 The requirements of MULTOS on the smart card platform are similar to those of JavaCard: 32 KB of ROM for the SCOS, 16 KB of EEPROM for applications, and about 1.2 KB of RAM. 2.3. Windows for Smart Cards Announced in 1998, Windows for Smart Cards (I shall use the shorter term WindowsCard for
3 As the Java API of the MULTOS smart card is dierent from JavaCard's APIs one unfortunately cannot just crosscompile JavaCard applets for MULTOS.

478

D. Husemann / Computer Networks 36 (2001) 473487

the remainder of our discussion) is Microsoft's approach to providing a standardized smart card platform [9]. Available only in small numbers since the CardTech/SecureTech 2000 conference, WindowsCard is not yet widely available. From what Microsoft has published on their Web site [6] we can infer that WindowsCard rst of all is a customizable SCOS that the application provider can adapt to her requirements, adding in specic components and leaving out others that are not needed. A runtime environment for supporting downloadable applets is one of those components that can be added, others are SET or EMV functionality, cryptographic function support, and a lesystem modeled on the Microsoft FAT lesystem. As JavaCard species Java as the programming language so does Microsoft specify VisualBasic and the Visual Studio development environment. WindowsCard development appears to be tightly integrated with the Visual Studio, allowing the programmer to debug her WindowsCard application while it is running on the smart card alternatively, a simulator is part of the development environment. Not surprisingly Microsoft emphasizes that Windows for Smart Cards is just a logical extension of the Windows family. In contrast to the JavaCard and MULTOS efforts Microsoft exerts strict control over WindowsCard and seems to be the only party porting WindowsCard to new smart card architectures and processors. Microsoft rather boldly claims that WindowsCard will be less expensive (by a factor of 2 to 3) than either JavaCard or MULTOS, stating that WindowsCard places less requirements on the smart card platform it remains to be seen whether this statement can be validated. The current WindowsCard version seems to be on par with JavaCard and MULTOS with regards to its hardware requirements. 2.4. BasicCard BasicCard is, like WindowsCard, not controlled by an industry interest group but by a single company, the Germany-based ZeitControl. Like

all the other platforms it employs a VM for running bytecode ZeitControl's version is called PCode. 4 ZeitControl oers the BasicCard in various congurations starting with a Compact BasicCard featuring 1 KB of EEPROM up to an Enhanced BasicCard with 16 KB of EEPROM. Also ZeitControl has announced the CombiBasicCard supporting both the ISO 7816 contact-based and the contactless RFID interface according to ISO 14443/B. The programming language is a Basic dialect supporting procedure denitions and various commands to deal with smart card specics. ZeitControl provides a free Windows-based development kit and even source code for tools such as the application loader thus, allowing for development of application loaders for other non-proprietary development platforms. The development kit includes a debugger host application and BasicCard code, a BasicCard simulator, and various utility tools. The BasicCard per se is not really a multi-application card as one can install only a single application onto the card. However, the Enhanced BasicCard (as well as the CombiBasicCard) also support a DOS-like le system complete with access protection on a per-le basis, so that one could support multiple o-card host applications through one on-card Basic application. Another dierence to the other platforms is the fact that BasicCard does not really provide for a dynamic and secure install and update facility. A BasicCard can be in one of three states: LOAD, TEST, and RUN. In the LOAD and TEST states one can reinstall the Basic application as often as one wishes to. Once the card is switched to the RUN state, however, it is `nalized' and the application cannot be exchanged or updated. The same restrictions apply for the BasicCard le system. Aside from the DOS-like lesystem BasicCard oers cryptographic function APIs for the 161-bit elliptic curve encryption following the IEEE standard P1363, for SHA-1, DES, and IDEA. In

4 ZeitControl's P-Code does not seem to have anything to do with other P-Codes such as the UCSD P-Code (see [10] for an overview of the UCSD P-System).

D. Husemann / Computer Networks 36 (2001) 473487 Table 1 Comparison of smart card platforms: JavaCard, MULTOS, Windows for Smart Cards, and BasicCard JavaCard Language(s) Code Multi-app support Dynamic install Secure install Base functionality InputOutput Basic requirementsb Development environment
a b

479

MULTOS MEL, C MEL Yes Yes Yes: signed code File system, cryptographic functions T 0, T 1 32K/16K/1K MSD, Swift, Hitachi

WindowsCard VisualBasic Object code Yes ?a Yes File system, cryptographic functions ? ? Visual Studio

BasicCard Basic P-Code No No ? File system, cryptographic functions T 1 ? BasicCard DE

Java Java bytecode Yes Yes Yes: signed code Transaction support, cryptographic functions T 0, T 1, contactless 32K/816K/1K Java DE, simulator, CAP tool

? denotes unobtainable information. The rst number indicates the amount of ROM required, the second the amount of EEPROM, and the third the amount of RAM.

addition, BasicCard provides for `digital certicates' based on shared secret keys: in essence the BasicCard application signs some data string using DES and triple DES encryption and returns a signature that anyone in the possession of the secret key can check [11]. Of all the smart card platforms that we have discussed here BasicCard is probably the least demanding smart card platform: the Compact BasicCard version requires just about 9 K of ROM, 1 K of EEPROM, and 256 B of RAM. Yet, even the Enhanced BasicCard requires just 17 K of ROM, up to 32 K of EEPROM, and 256 B of RAM. 2.5. Comparison JavaCard currently seems to be enjoying most of the limelight; the widespread adoption of Java in the last couple of years certainly has contributed to this eect. While the MULTOS platform was announced almost at the same time as JavaCard it has yet to be as successful in capturing the mindshare of the application developers. Microsoft's WindowsCard has yet to prove itself (and Microsoft's bold claim that it will be less expensive than JavaCard or MULTOS) and become available in larger numbers; both JavaCard and MULTOS have been demonstrated to work in large-scale pilots. BasicCard nally is kind of the underdog of the four platforms: it is inexpensive, easy to program,

and easy to understand. The fact that it is not upgradeable once it is in the RUN state is probably not a problem for deployment in a geographically contained area with a limited number of clients for a single application (or at least a limited number of applications). In Table 1, I have tried to provide you with a comparison of the four smart card platform we have discussed in the previous sections. 5 3. Smart card middleware standards As we noticed in the introduction and discussed in Section 2 developing a smart card application entails not only the on-card application but also the host application. The host application needs to talk to the on-card application by exchanging APDUs with the SCOS (see again Fig. 2). The physical interface usually is a serial link interface running at speeds between 9.6 KB/s up to 115 KB/s. Rarely will the host application interface directly to the smart card, instead it will talk to a card terminal that holds the smart card and provides power to it as long at is inserted. 6 Unfortunately, mirroring

Based on what information is currently publically available. As smart cards come in a wide variety of form factors it need not necessarily be a `card' but can, for example, be a ring, such as the Dallas Semiconductor JavaRing; or it could come in the disguise of a USB dongle.
6

480

D. Husemann / Computer Networks 36 (2001) 473487

the fragmented nature of the smart card world at large, we have a plethora of card terminals with dierent communication protocols to follow. To relieve the application developer from having to deal with this variety of card terminals and also to shield her from the various SCOS currently available, two middleware eorts have been established as de-facto industry standards in the last couple of years: the Windows-based PC/SC toolkit [12] and the Java-oriented OCF [13]. Both middlewares address the following issues enabling the nonsmart-card specialist programmer to utilize the power of smart cards. First, both de-facto standards introduce highlevel APIs encapsulating low-level communication: the format and the sequence in which command APDUs are sent to the smart card and response APDUs are returned depends very much on the specic SCOS and the on-card application that we wish to communicate with. In some cases, the way we have to code and decode the APDUs depends not only on the SCOS itself but also on the card terminal used. High-level APIs shield the application developer from these details and variances. Second, card terminals come in an astonishing variety of form factors and functionality: plain terminals sporting just a slot and a serial cable; terminals with more than one slot; terminals with a built-in display and keypad or even keyboard; terminals with biometric identication facilities (such as ngerprint recognition, eye retina scanners or voice analyzers); terminals that use wireless communication protocols for APDU exchange with the host system or even for talking to the smart card itself; or even terminals that talk to smart cards in unusual form factors (for example, a JavaRing). To the extent possible both frameworks, PC/SC and OCF, provide abstractions that allow us to either ignore these dierences or access special features in well-dened ways. Third, each framework is extensible and allows the addition of new functionality and new APIs to cater to new smart card applications. As both middlewares, PC/SC and OCF, address the same set of issues, the question is whether and where they do dier. Well, they do dier both in functionality and in scope, and in the following sections we shall take a closer look at both.

However, before we proceed I do have to declare a bit of a bias, being one of the architects of OCF. . . 3.1. OpenCard Aside from the issues mentioned in the beginning of Section 3, OCF addresses additional objectives: concurrency of access, support for multiple applications, portability, and card issuer transparency. With modern runtime environments we increasingly have threaded applications. When designing OCF we wanted to support the threading programming approach. An Internet screenphone running Java, for example, could use the le system to store user prole information (layout of the desktop, POP3 server, last seen email message ID, etc.) and, at the same time use the electronic signature functions of the smart card to sign an email; in this example, two applications running inside the Java runtime environment access the smart card concurrently. Likewise, as we have seen in Section 2, more and more SCOS are multi-application now. Clearly, a modern smart card middleware should not only allow for multi-application cards but also support and encourage multi-application cards. Not wanting to tie ourselves to a proprietary OS, portability was an important issue: we wanted to minimize the eort required to port our smart card-enabled applications once we had written, debugged, and tested them. Naturally, Java seemed like a good idea to achieve this goal: Java incorporates portability by design; once we compile a Java application to Java bytecode, we can expect that application to run on every platform sporting a JVM. In addition, Java has established itself as one of the linguae francae of the Internet: the major browser platforms include JVMs, and a very large number of programmers are already uent in Java. Also Java has become a very wellbehaved player regarding interoperability: the basic system classes already include functionality to access the World Wide Web (even rewalls are not a problem), and you can get extension packages that provide interoperability with CORBAbased systems [14]. Thus, we decided OCF would

D. Husemann / Computer Networks 36 (2001) 473487

481

Fig. 5. OCF Architecture. OCF has a layered architecture: the CardTerminal layer (lower part) and the CardService layer (upper part). Applications communicate with a smart card mainly through CardService components supported by the CardService layer. The CardService layer allocates resources from the CardTerminal layer and carries out low-level APDU exchanges with a smart card.

be Java-based, and the current reference implementation is an all-Java one. Another issue with portability and multi-application cards is card issuer transparency. By that I do not mean to have see-through card issuers but instead that we want to be able to locate and access the same application on smart cards issued by dierent card issuers (e.g., dierent banks might use the same home-banking application, just with dierent parameters). Since card issuers and not the application programmer determine where the smart card related part of an application ends up on a particular smart card we needed suitable abstractions and mechanisms to support locating our application on the smart card and to do so in a transparent manner, hiding the dierences between the various known and (as yet) unknown schemes of providing meta information. 7 As you can see in Fig. 5, OCF, similar to PC/ SC, has a layered architecture. The lower layer, the CardTerminal layer contains software abstractions for card terminal related tasks and objects; the upper CardService layer provides abstractions for smart card functionality and applications as well as mechanisms to support concurrent smart card access. By employing the abstract factory and the singleton pattern [15] we achieve extensibility:

7 Meta information is information about the applications and their data residing on a smart card.

factory objects contributed by manufactures and card application developers register with special registry singletons. CardTerminal factory objects can identify card terminals and can produce CardTerminal objects that know how to communicate with the physical card terminal; likewise CardService factory objects can identify smart cards and the applications located on those smart cards and can instantiate CardService objects that oer a more or less comfortable API for to the application running on the host and translate the API calls into sequences of APDUs. Through the registry singletons we can easily add support for new card terminals or new smart card functionality. Note, that OCF places no restrictions on the factory objects themselves: we have not only factories that instantiate already installed card service objects but also factories that can install new or updated code by communicating with a server somewhere on the Internet. This feature of OCF is particularly useful for small and memory restricted environments (such as set-top-boxes, for example): We need to install only an OCF core and a couple of Internet-enabled factory objects, once this slim version of OCF encounters a smart card it does not yet `know', our Internet-enabled factories will download the required code over the Internet. The CardTerminal layer allows for secure albeit primitive (APDU-based) access to a card terminal and to an inserted smart card. An application can send command APDUs and receive an appropriate

482

D. Husemann / Computer Networks 36 (2001) 473487

response APDU from the smart card. Applications can either poll the card terminal for status changes or utilize an event mechanism to nd out whether the user has inserted a smart card (or removed it; see Fig. 6). OCF makes sure that once an application has gained access to a smart card that no other application can interfere (e.g., by inserting rogue command APDUs or intercepting response APDUs). The CardTerminal abstraction of OCF assumes a rather primitive card terminal: one can check whether a smart card is present and send a command APDU and receive the response APDU. In contrast to PC/SC we did not specify anything with regards to the permissible lower layer protocols and it turns out that we gain exibility as it is fairly easy to implement CardTerminal classes that talk to non-standard `smart cards'; the Dallas Semiconductor JavaRing, for example, or to First Access's contact-less smart tokens. Another possibility is a remote card terminal that is attached to our local system via the Internet. A more interesting implementation that is available together with OCF is a small adaptation layer that runs on top of PC/SC on Windows platforms and maps PC/SC into OCF allowing for coexistence between OCF and native Windows applications that use PC/SC directly. To cater for card terminals with features such as keypads, displays or biometric input factories OCF allows for optional interfaces (i.e., Java in-

terface) that a terminal can implement. In case an application requires a certain feature it can then check whether any of the registered CardTerminal objects implement the Java interface representing that particular feature. We view any smart card provided functionality as a service of that smart card examples of such services include le system services, electronic signature services, and so forth. However, OCF's CardService layer does not include concrete service denitions: it only contains the necessary infrastructure to register services, to allow concurrent access for multiple CardService object to the smart card (through the CardServiceScheduler, shown in Fig. 5), and to specify which kind of smart card an application is interested in (see also Fig. 7). One of the nice features of OCF is that in addition to waiting for the user to insert a smart card into one of the attached readers, we can also specify that we are interested only in smart cards that provide a certain functionality: OCF will check the inserted card and (try to) nd out whether it matches the requirements of any of the waiting applications. Although ISO 7816 species that a smart card could support multiple inputoutput channels and, thus, talk to several card external application at once, cards with multiple inputoutput channels are extremely rare. However, for multi-application

Fig. 6. CardTerminal layer. Card terminals in OCF are represented through the CardTerminal and the Slot class. Both static (shown here for a card terminal attached via the serial port) and dynamic congurations (in this case, PC/SC IFDs) are possible with OCF.

Fig. 7. CardService layer. CardService factory objects instantiate CardService objects; a particular CardService object implements a specic API for example, an electronic signature API. Through the CardServiceRegistry singleton we keep track of the available factory objects in the system.

D. Husemann / Computer Networks 36 (2001) 473487

483

cards the ability to support concurrent access is in our opinion vital. In OCF the CardServiceScheduler arbitrates access to the inputoutput channel of the card: card services acquire access to the card inputoutput channel from the CardServiceScheduler, communicate with the card, and release the card inputoutput channel back to the CardServiceScheduler. OCF has from start on been an open source eort 8 and consequently not only documentation (such as an introductory document to OCF [13] or a programmer's guide [16]) but also demo code, binaries, Java packages, and the complete source code of the framework have been available through the OCF Web site. OCF is available free of charge with a license that grants a perpetual, irrevocable right to use it in whatever context you wish. OCF is by no means a nished middleware; currently the consortium is working on issues such as support of very small and memory limited platforms, and on various extensions of the framework to address, for example, JavaCard applet management. OCF is successfully deployed in a variety of products (e.g., Gemplus's GemXpresso, Sun Microsystem's Solaris OS, and various customer projects). 3.2. PC/SC The PC/SC industry standard is driven by Microsoft and, similar to OCF, denes an API for communicating with smart cards [17]. Being a Microsoft driven eort it is Windows 9X/2000based and well integrated with the Windows runtime environment. A number of card terminal manufacturers support PC/SC through appropriate interface drivers, and most of the PC Cardbased card terminals can be accessed through PC/ SC. Currently, the only full-blown reference implementation comes from Microsoft and is tightly integrated with the Windows 9X/NT/2000 platform. Fig. 8 shows the architecture of PC/SC. Smart cards in PC/SC parlance are called integrated cir8

Fig. 8. PC/SC architecture. PC/SC uses the term IFD for card terminals, IFD handler for the card terminal driver, and ICC for the smart card. Central to PC/SC is the ICC Resource Manager that controls access to smart cards and card terminals.

OCF's license is modeled on the BSD license.

cuit cards (ICC) and card terminals are interface devices (IFDs). Central component of the PC/SC architecture is the ICC Resource Manager. The resource manager controls all IFDs as well as the ICC service providers. An ICC service provider is the interface to on-card applications and other functionality oered by a smart card; it keeps track of the communication and smart card state in general. A special ICC service provider is the optional crypto service provider (CSP) containing all required cryptographic function for carrying out encrypted communications with the card and for authentication. Other service providers oer interfaces to le system and cryptographic functions on a smart card. The PC/SC specication comprises several parts that describe the PC/SC architecture, specify how compliant smart cards and card terminals (IFDs) should behave and look like, provides a recommended implementation for PS/2 keyboards with integrated smart card readers, describes the functionality and API of the resource manager, touches on ICC service provider design and APIs, discusses application programming issues, and provides specications for general purpose cryptographic and storage server provider components. According to the PC/SC workgroup's Web site, the workgroup is currently working on an updated version of the over three year old PC/SC 1.0 specication; the update is supposed to address issues such as support for contactless cards,

484

D. Husemann / Computer Networks 36 (2001) 473487

mechanisms for application selection, and to provide extensions for card terminals with additional features such as pinpads and displays. Compared with OCF, PC/SC really excels through its large range of supported card terminals: mostly every card terminal vendor is by now supporting PC/SC on the Windows platform (though, OCF incorporates that advantage on the Windows platform through the OCFPC/SC adapter). Generally speaking OCF and PC/SC address similar concerns and at a high-level view provide similar functionality. However, scope of platforms that OCF and PC/SC target dier: PC/ SC addresses the Windows/Intel 9X/2000/NT systems only, whereas OCF runs on (but also requires) any Java providing system. Not surprisingly, PC/SC is very well integrated with the Windows runtime environment. The main purpose of PC/SC seems to be providing access to cryptographic functions implemented on a smart card. While its tight integration with the Windows OS probably allows for a good utilization of the smart card by various Windows services and applications, it also ties any PC/SC-based application to the Windows platform which, depending on your point of view, might be something you value. PC/SC does currently not oer concurrent access to the smart card. 3.3. MUSCLE Aside from Microsoft's full-edged implementation of PC/SC for the Intel-based Windows platform a reimplementation of PC/SC for the Linux OS is underway, called MUSCLE (Movement for the Use of Smart Cards in a Linux Environment). The stated goals of MUSCLE are among others the implementation of a PC/SC compliant resource manager for Linux, pluggable authentication module (PAM) modules for cardbased authentication, a smart card encrypted lesystem, and Netscape S/MIME email integration. Recently, MUSCLE released a PC/SCOCF adaptation layer similar to the adaptation layer available for the Intel-based Windows platforms. MUSCLE provides two dierent approaches for enabling application for smart cards: the rst

Fig. 9. Linux MUSCLE system. At the core of MUSCLE is the pcscd system daemon. Processes access card terminals through the libpcsclite shared library which connects to pcscd.

approach is that the developer links the application with the MUSCLE library to obtain a standalone application that directly talks to one card terminal. The second, more exible approach, illustrated in Fig. 9, employs a distributed approach: at the core of the distributed system is the pcscd system daemon that talks to the smart card terminals available on the system. Any application that wishes to interact with a smart card incorporates the pcsclite shared library by linking to it. The shared library provides the MUSCLE API as RPC calls to the pcscd system daemon. Currently any process can connect to pcscd and establish a channel to a smart card MUSCLE just allows us to disable non-local access to pcscd (by setting an environment variable). However, in general, it is not a good idea to rely on the host system to protect a smart card from malicious users, the application on board the smart card needs to protect itself adequately, so this characteristic is not really a serious shortcoming. MUSCLE does try to protect the system against denial-of-service attacks by doing simple sanity checks. The design of MUSCLE mimics to some extent the resource manager centric architecture of PC/ SC: the resource manager is replaced by pcscd on the Linux platform. Also as with PC/SC's resource manager, MUSCLE does allow multiple application to access smart card readers, but at any one point in time only one application can access a

D. Husemann / Computer Networks 36 (2001) 473487

485

particular card reader; concurrent access of multiple applications to a single card is not possible. Several MUSCLE-based applications already exist: a GSM SIM card reader, a smart card analyzer, and a command line utility for batch processing smart cards. The most interesting application is in my view the combination of MUSCLE and Linux's PAM system: instead of using Linux's normal password le-based authentication scheme, the Linux host will generate a random challenge nonce, encrypt it using the user's public key (stored in a le in the user's home directory on the host), and then send it to the smart card (currently either a Schlumberger Cyberex Access or Cryptoex for Windows card) to decrypt it. The smart card if it belongs to the user has the private key of the user stored on it and will be able to decrypt the challenge nonce and return it to the host; the host can then verify the decrypted nonce with the original and grant access to the system if both are equal. Thanks to Linux's use of the PAM mechanism, it is rather simple to switch to a smart card-based authentication system. Another MUSCLE `application' is the MUSCLEOCF bridge: as mentioned in Section 3.1, OCF contains code to utilize PC/SC on Windows platforms as just another kind of card terminal. The MUSCLEOCF bridge provides the necessary glue to run the OCF PC/SC adapter on top of MUSCLE on Linux systems. Thus, you can utilize both OCF and MUSCLE on Linux concurrently. MUSCLE, similarly to OCF, is available under an open source license. 9 4. Summary In the previous sections, we have covered smart card standards for the smart card itself JavaCard, MULTOS, BasicCard, and Windows for Smart Cards and for communicating with smart cards PC/SC, MUSCLE, and OCF.

Of the smart card platforms, JavaCard and MULTOS seem to enjoy support throughout the industry; Windows for Smart Cards has yet to leave its mark. The most open eorts appear to be BasicCard and JavaCard: for both one can readily access programmer's guides and How-To articles. The most promising platforms with regards to application security and upgradeability seem to be MULTOS and JavaCard. BasicCard, while easy to program and to comprehend, suers from not supporting dynamic in-the-eld upgrade, but is probably a good candidate for small-scale deployment or for applications that are rather simple and not likely to change. Both PC/SC and OCF are well established and employed in various products, OSs, and projects. Whether to use OCF or PC/SC is both a question of taste and of your objectives. OCF provides for portability across a wide range of platforms but requires that you use Java; PC/SC on the other hand allows for dierent programming languages but is tied to the Windows platform. OCF's open source nature allows for code inspection and independence from its provider in contrast to PC/SC where Microsoft controls and owns the code for the Windows platform. 5. Links JavaCard is rather well published: in addition to Sun's JavaCard Web site you can nd a couple of rather well-written, step-by-step articles on how to program for JavaCard and develop corresponding OCF CardService components on the JavaWorld Web site. Likewise OCF oers documentation for the framework as well as for writing applications using OCF. Again, the JavaWorld web site oers several articles on how to develop OCF card services and OCF-based applications [1821]. MULTOS oers developer documentation on their Web site, though you have to register as a MULTOS developer before you can access it [5]. ZeitControl oers the BasicCard documentation along with source code free of charge via their web site [7]. Windows for Smart Cards nally is

9 The core of MUSCLE uses a BSD-like license, parts of the applications are available under GNU Public License.

486

D. Husemann / Computer Networks 36 (2001) 473487 [4] JavaCard Forum, JavaCard Forum. http://www. javacardforum.org/, April 1999, cited on 19 April 1999. [5] Maosco, Multos the smartcard gets smarter. http:// www.multos.com/, 1998, cited on April 19, 1999. [6] Microsoft Corporation, Windows for smart cards. http:// microsoft.com/smartcard/, July 2000, cited on 26 July 2000. [7] ZeitControl, BasicCard the rst smart card you can program in Basic. http://www.plastikkarten.de/indexe. htm?zc-easye.htm, 1999, cited on 19 April 1999. [8] M. Baentsch, P. Buhler, T. Eirich, F. H ring, M. Oestreio cher, JavaCard from hype to reality, IEEE Concurrency 7 (OctoberDecember) (1999) 3643. [9] Microsoft Corporation, Microsoft Announces Smart Cards for Windows, Press release. http://www.microsoft. com/presspass/press/1998/oct98/smrtcdpr.htm, October 1998, cited on 19 April 1999. [10] J. Foust, The UCSD P-System museum in the west wing of the Jeerson Computer Museum. http://www.threedee. com/jcm/psystem/, 2000, cited on 22 September 2000. [11] T. Guilfoyle, The Compact and Enhanced BasicCards, Version 3.03, ZeitControl cardsystems GmbH, Siedlerweg 39, D-32429 Minden, Germany, February 2000. [12] PC/SC Workgroup, Interoperability specication for ICCs and personal computer systems. http://www.smartcardsys.com/, December 1997, cited on 16 April 1999. [13] OpenCard Consortium, http://www.opencard.org/; OpenCard Framework General Information Web Document, October 1998. Available also via http://www.opencard.org/ docs/gim/ocfgim.html. [14] The Source For Java Technology. java.sun.com; http:// java.sun.com/, July 1999. [15] E. Gamma, R. Helm, R. Johnson, J. Vlissides, Design Pattern Elements of Reusable Object-oriented Software, Addison-Wesley, Reading, MA, 1994. [16] OpenCard Consortium, http://www.opencard.org/; OpenCard Framework 1.1.1 Programmer's Guide, April 1999. Also available via http://www.opencard.org/docs/pguide/ PGuide.html. [17] PC/SC Workgroup, PC/SC Workgroup. http://www.pcscworkgroup.com/, 2000, cited on 22 August 2000. [18] R.D. Giorgio, M. Montgomery, Write OpenCard services for downloading Java Card applets. http://www.javaworld. com/javaworld/jw-02-1999/jw-02-javadev.html, February 1999. [19] R.D. Giorgio, Smart cards and the OpenCard Framework. http://www.javaworld.com/javaworld/jw-01-1998/ jw-01-javadev.html, January 1998. [20] T. Schaeck, R.D. Giorgio, How to write opencard card services for java card applets. http://www.javaworld.com/ javaworld/jw-10-1998/jw-10-javadev.html, October 1998. [21] M. Wendler, S. Breideneich, R.D. Giorgio, How to write a CardTerminal class for simple and complex readers in an OpenCard environment. http://www.javaworld.com/javaworld/jw-01-1999/jw-01-javadev.html, January 1999. [22] M.U.S.C.L.E. Movement for the Use of Smart Cards in a Linux Environment. http://www.linuxnet.com/smartcard/ index.html, 1999.

accessible via Microsoft's Smart Card pages [6], whereas PC/SC is available through the PC/SC Web site [17]. The MUSCLE Website [22] contains documents and source code for the Linux platform along with links to applications and other smart card sites. Another interesting Web site is the smart card projects site of the center for information technology integration at the University of Michigan [23]. You can nd out more about the Visa-initiated GlobalPlatform initiative via GlobalPlatform's Web site [24]. Finally, two books are worth mentioning. The rst one by Scott Guthery and Tim Jurgensen is the Smart Card Developer's Kit [25], that, to quote the author, ``strives to be both a detailed description of smart card technology for system designers and a reference and resource manual for programmers''. The other book is Smart Card Application Development Using Java by Uwe Hansmann et al. [26] that contains everything you need to know to develop Java-based smart card applications.

Acknowledgements I should very much like to thank Markus Kuhn of the Computer Laboratory of the University of Cambridge (UK) for his insights into BasicCard and Marcus Oestreicher of the IBM Zurich Research Laboratory for his information on JavaCard.

References
[1] R. Moreno, Methods of data storage and data storage systems, United States Patent 3,971,916, July 1976, Filed as French patent application FR 7410191 on 25 May 1974. [2] J. Ferrari, R. Mackinnon, S. Poh, L. Yatawara, Smart cards: a case study, IBM International Technical Support Organization. http://www.redbooks.ibm.com/, October 1998. [3] Analyses & Synthses, The smart card museum. http:// e www.cardshow.com/museum/, 1999, cited on 15 April 1999.

D. Husemann / Computer Networks 36 (2001) 473487 [23] Center for Information Technology Integration, University of Michigan, Citi: Projects: Smart cards. http://www.citi. umich.edu/projects/smartcard/, 2000. [24] GlobalPlatform, GlobalPlatform advancing standards for smart card growth. http://www.globalplatform.org/, 2000. [25] S. Guthery, T. Jurgensen, Smart Card Developer's Kit, Macmillan Technical Publishing, New York, 1998. [26] U. Hansmann, T. Schaeck, F. Seliger, M. S. Nicklous, Smart Card Application Development Using Java, Springer, Berlin, December 1999.

487 Dirk Husemann joined IBM's Research Division in 1996 and has since then been working on pervasive computing projects. Currently, he is involved in the DEAPspace project as well as in datacasting over digital audio broadcast channels. He received both an MS (Diploma, 1991) and a Ph.D. (Dr.-Ing., 1995) in computer science from the University of Erlangen-N rnberg, Germany. Husemann u is a member of IEEE, IEEE Computer, USENIX, TUG, and the German GI.