Developing Smart Card-Based ApplicationsUsing Java Card?Jean-Jacques Vandewalle and Eric V�etillardGemplus Research GroupE-mails: fjeanjac,ericg@research.gemplus.comAbstract. In this paper we describe a methodology for developing smartcard-based applications which accounts for both internal and externalsoftware production: on-card and client programs. This developmentmethodology is based on the application of distributed object-orientedprinciples to Java Card. We design a model in which a card application isviewed as a remote object accessed through method invocations handledby a proxy object executing on the terminal. With a simple example, weshow how this model enhances the development of smart card-based ap-plications by allowing Java programmers to rapidly design and developon-card and o�-card programs without worrying about the speci�c smartcard features. This scheme has been implemented as the core technologyin the Gemplus Java Card application development environment GemX-presso RAD.Keywords. Java Card software production, Smart card-based applica-tion design, Object-oriented framework.1 Background and ObjectivesIn this section we review the emergent and promising open smart card devel-opment platform based on the Java Card speci�cation. We give an overviewof the processes involved in the creation of a Java Card-based application. Weoutline the limits of the Java Card speci�cation as a model for the interac-tion between Java Card applets and the outside world. We then show how thislimit has brought us to de�ne a development methodology based on distributedobject-oriented principles applied to Java Cards.1.1 Java Card Brings Objects to Smart CardsDuring the past twenty years smart cards have evolved from simple dedicateddevices (phone cards, french \Carte Bleue") to open computing platforms [14,? Java and Java Card are trademarks of Sun Microsystems Inc. GemXpresso RAD is a trademark of Gemplus. Allother product names mentionned herein are the trademarks of their respective owners.

6, 9]. Research was focusing on providing programmable smart cards to enableprogrammers to write themselves card applications on top of a card virtualmachine executing the code in a portable and secure environment [1, 5]. Withthe advent of Java Card [17], promoted by Sun and the Java Card Forum, smartcard technology has been made accessible to a wide body of programmers, mostof them new to smart card programming.A Java Card is simply de�ned as a smart card that is capable of runningJava programs. Java Card brings the object-oriented programming model thatis enforced by the usage of the Java programming language. Object orientationbrings to card programming the same advantages that it brings elsewhere, byencouraging the development of code in small and self-contained units. Thisapproach brings modularity, encapsulation and information hiding to card ap-plications. This leads to more independence between objects, and a restrictionof the interactions between objects to well-de�ned interfaces.Nevertheless, the Java Card object-oriented approach only addresses \on-card" software production. A complete smart card application also includes the\o�-card" software (the application running on a host/terminal as a client pro-gram of a smart card applet). The Java Card standard has kept the traditionalcommunication model between a smart card and its clients, which is well-suitedfor the resolution of legacy problems, linked to the continued use of existing cardapplications standards. As such, it does not propose a standard object-orientedway to de�ne a high-level interface between a card applet and its client program.In typical smart card-based applications the communicationbetween the cardapplication and the client is de�ned by commands (to card) and responses (fromcard) embedded in Application Program Data Units (APDUs). In Java Card, acard application communicates with the outside world through an instance of theclass javacard.framework.Applet that provides a method to process APDUs.1.2 More Object OrientationThe Java Card speci�cation describes a limited version of the Java languageand platform well dedicated to smart cards and legacy applications. De�ningthe communication between the card application and the outside world as ex-changes of APDUs forces programmers to design a proprietary protocol for ev-ery application they write. Both the client program and the card applet haveto implement a signi�cant amount of tedious code to encode and decode theinformation exchanged accordingly with the protocol de�ned. This approach iscumbersome to program, and it forces the developer to focus on the de�nitionof a smart-card dedicated low-level protocol rather than on the object design ofthe whole application.In this paper we propose a development methodology which allows the cardand client programmers not to worry about the protocol between the card andthe host. This methodology is based on the representation of the client/serverarchitecture made by the host and the card as a distributed object system. TheJava Card is considered as a server running an application that is described by aninterface. The card applet is a class that implements this interface. The client

program communicates with the card applet accordingly to the remote objectinterface. The interface is a kind of contract that binds a server to its clients.The server guarantees that it will respond, as expected, to the methods de�nedin the interface.For the communication between client programs and card applet we havede�ned a protocol called Direct Method Invocation (DMI), which encapsulatesclient requests to the card applets. The DMI protocol links the card to the hostand de�nes the way in which the card applet and the client program communi-cate. The protocol is handled by the Java Card operating system, making thecard applet source code enterely independent of it. On the client side the pro-tocol is handled by a proxy program which is automatically generated from theinterface. The proxy represents the remote object (the card applet) on the clientside by o�ering to the client program the interface implemented by the applet.The proxy implements the card applet interface but it contains the code requiredto invoke the card applet methods using the DMI protocol (see Figure 1).Appletimplementsinterface

Card

DMI

Terminal

Client program

ProxyimplementsinterfaceFig.1.: Distributed object-oriented smart card-based application1.3 Outline of the PaperSection 2 explains in detail how to develop a Java Card-based applications usingthe protocol-oriented approach de�ned by the Java Card speci�cation. A cardapplet and a client program will be provided on the basis of an applicationbuilt around a simple \counter"1. Section 3 illustrates our approach with thesame example. The design patterns, the processes and the tools implied in ourarchitecture are described. Finally, we outline some pespectives to enhance ourmodel in two directions: security and reference passing between cards and clients.1 A lightweight version of an electronic purse, since it can be incremented or decre-mented by an amount, but does not perform any security control.

2 Developing Java Card-Based ApplicationsThis section describes how to develop an application with a Java Card. The twomain tasks are, to implement a Java Card applet, and to implement a clientapplication using the Java Card applet when it is inserted in a reader [18, 7, 8].But, before to detail these implementations, it is necessary to examine howcommunication with smart cards is realized, and how communication is handledby the Java Card API.2.1 Communicating with a Smart CardTo communicate with a smart card you need to write an application that sendscommands to a smart card connected to your host through a reader. >From thehost to the reader, and from the reader to the smart card data (commands and re-sponses) are transported using protocols. The communication protocols betweensmart cards and readers are de�ned by an ISO standard [12] as T=0 (characterprotocol) or T=1 (block-chaining protocol). The problem is that there is no stan-dardized protocol between the host and the reader. To permit the description ofcard commands independantly of host-reader and reader-card protocols a formathas been standardized [11, 12]. This format de�nes the command message sentfrom the client application, and the response message returned by the card tothe client application as Application Protocol Data Units (APDUs). Each man-ufacturer provides a driver to transport APDUs with its proprietary host-readerprotocol (see Figure 2).1 byteCLAINS LeDataInP1 P2 Lc

Lc bytes

SW1SW2

Command APDU with data sent to the card

Response APDU with data returned by the card

Host-Reader Protocol T=0/T=1 Protocol

Processes APDUs

Host

Client application

Reader driver Reader Card application

CommandAPDU APDU

Response

DataOutLr bytes

APDUs APDUsFig. 2.: Communication with Application Protocol Data UnitsThe meaning of the APDU message bytes can be set by a standard, by a man-ufacturer, or by a designer regarding the application requirements. Some com-

mandAPDUs are standardized by various standards according to the capabilitiesprovided by smart card applications. For example, ISO 7816-4 de�nes commandsfor �le management, ISO 7816-7 de�nes commands for database management,and EMV de�nes commands for general-purpose payment management. O�-the-shelf smart cards sold by manufacturers and proprietary smart cards deployedby national organisms or consortiums de�ne also their own command APDUsfor their application's needs.In fact, to communicate with a smart card from a client application thefollowing steps must be followed:1. Have knowledge of the card command set, in fact the list of commandAPDUsthat smart cards can process, the possible values for their paramaters, andthe format of data.2. Build the command APDUs sent to smart cards regarding the applicativedata retrieved from local variables, databases, user inputs, etc.3. Use a driver to transport APDUs from the host to the smart card througha reader.4. Decode the response APDUs regarding the format of data returned by thecard and analyse the di�erent possible values of the status bytes.2.2 Handling Communication in Java Card AppletsPrinciples Java Card does not specify how a card applet has to be loadedor initialized, or how the terminal may obtain information about a smart card.The Java Card speci�cation is a standard for programmers, whose goal is toguarantee the interoperability of Java Card applications at the source codelevel. To support this level of integration, a Java Card applet is de�ned as ajavacard.framework.Applet object with a set of methods (see Table 1) en-abling the applet to communicate through javacard.framework.APDU objects.Processing APDU Objects The argument used in an applet's install andprocess methods is an APDU object. This object is used to encapsulate thecommand and response APDUs exchanged by the card with both the T=0 andT=1 protocols. An APDU object is handled as a bu�er in which the applicationcan �rst read the command APDU received, and then can write the response tobe sent back (see Fig 3).The \End" state is reached by setting the response APDU's status bytes.Three cases may occur:1. If the process or install method executes and �nishes normally, then theJCRE sends the status code 0x9000 (normal completion) as the status bytesof the response APDU.2. If the process or installmethod throws an ISOException, then the JCREsends the reason for that exception as the status bytes of the response APDU.

Method Descriptionvoid install(APDU apdu) Static method called by the JCRE during the�nal stage of applet installation. Allocates andinitializes the applet. A command APDU canserve to provide initializationparameters to thismethod, and a response APDU can returnedinformation on the processing of this method.void deselect() Called by the JCRE when the applet is des-elected (i.e. when another applet is selected).Contains code that must be executed at the endof each session with the applet.boolean select() Called by the JCRE when the applet is selected.Contains code that must be executed at the be-ginning of each new session with the applet.void process(APDU apdu) Main method, which receives and processes allthe APDUs for the applet, while it is selected.Table 1.: Main methods of the class javacard.framework.Applet3. If any other exception has been thrown, the behaviour of the underlyingoperating system is unde�ned. In fact, the JCRE may decide to mute thecard, block the applet, or perform any number of operations to ensure thefuture security of the applet or the card itself.2.3 Writing a Java Card AppletApplet Design This section is intended to illustrate the Java Card developmentprocess with a simple \counter" card applet, which stores an int value thatcan be read, and can be incremented and decremented by a given amount (seeFigure 4). The counter is installed in the card by calling the constructor of theapplet, which sets the counter with an initial value to 0 and registers this appletwith the JCRE (the APDU parameter of the applet's installmethod is not used).Applet Operations and APDUs Other operations are handled by the ap-plet's process method, which decodes them with their arguments and returnsresults according to the APDU mapping described in Table 2.Implementation of the Applet Operations The source code of the decre-ment operation (see Figure 5) illustrates what has to be implemented to realizea processing on APDU data. First it is necessary to retrieve the incoming datafrom the APDU bu�er (line 3). As data are in a byte array, it is necessary to for-mat them accordingly to the type used within the Java applet; in our example,

APDU AppletJCRE

Incoming

setIncoming

Idle

Init

End

Outgoing

Response APDU

Client

sendBytes

processes

ReceiveBytes

reads data

setOutgoing

process(apdu)

getBuffer

terminates

initializes

setOutgoingLength

Command APDU

command

Fig. 3.: Java Card APDUs processing event trace diagraman int must be retrieved in the 4 bytes of the command APDU data (lines 6 to9). Then, the processing can be performed with the applet's instance variablesand the incoming data (line 12). To send back data to the outside world, theymust be stored in the APDU bu�er as bytes (lines 13 to 17).If a protocol error occurs, a standardized status word can be returned in aresponse APDU by throwing an ISOException with a constant value providedby the class ISO (lines 4 and 5). For an applicative error (for example, an illegalnegative value, lines 10 and 11), the developer can return a response APDU witha speci�c status word value to signal this error to the client application.2.4 Writing a Java Card-based Client ApplicationAs we have seen while developing the Java Card \counter" applet, the commu-nication between a card applet and the outside world is encapsulated in APDUdata structures. Thus, writing a client application that runs with a card appletconsists in developing code, which deals with the command APDUs acceptedand the response APDUs returned by the card applet method process. A client

1 import javacard.framework.*;23 public class Counter extends Applet f4 private int value;56 public Counter() f value = 0; register(); g7 public static void install(APDU apdu) f new Counter(); g89 public void process(APDU apdu) f10 byte[] buffer = apdu.getBuffer();11 if (buffer[ISO.OFFSET CLA] != 0xAA)12 ISOException.throwIt(ISO.SW CLA NOT SUPPORTED);13 switch(buffer[ISO.OFFSET INS]) f14 case 0x01: // Performs the read operation15 case 0x02: // Performs the increment operation16 case 0x03: // Performs the decrement operation17 default: ISOException.throwIt(ISO.SW INS NOT SUPPORTED);18 g19 g20 g Fig. 4.: Java Card Counter class source codeOperation APDUint read() Command: AA 01 XX XX 00 04Response: RV3 RV2 RV1 RV0 90 00int increment(int) Command: AA 02 XX XX 04 AM3 AM2 AM1 AM0 04Response: RV3 RV2 RV1 RV0 90 00int decrement(int) Command: AA 03 XX XX 04 AM3 AM2 AM1 AM0 04Response: RV3 RV2 RV1 RV0 90 00Table 2.: APDUs mapping for the \counter" operationsapplication is a front-end for a card applet, which must perform the followingtasks when communicating with the card applet:� To select the card applet using its AID. This selection is performed by send-ing a \SELECT APDU" command.� To prepare command APDUs compliant with the ones accepted by the ap-plet's method process. The data sent with the command APDU can be re-trieved from various sources (application data, user interface, database, etc.)and must be converted to match with the format de�ned for the APDU'sDataIn �eld of bytes (see Table 2 for the format of data sent with \counter"

1 case 0x03: // Performs the decrement operation2 f3 byte byteRead = (byte)(apdu.setIncomingAndReceive());4 if (byteRead != 4) ISOException.throwIt(ISO.SW WRONG LENGTH);6 int amount = (buffer[ISO.OFFSET CDATA]<<24) |7 (buffer[ISO.OFFSET CDATA+1]<<16) |8 (buffer[ISO.OFFSET CDATA+2]<<8) |9 buffer[ISO.OFFSET CDATA+3];10 if (amout<0 || value-amount<0)11 ISOException.throwIt((short)0x6910);12 value -= amount;13 buffer[0]=(byte)(value>>24);14 buffer[1]=(byte)(value>>16);15 buffer[2]=(byte)(value>>8);16 buffer[3]=(byte)(value);17 apdu.setOutgoingAndSend((short)0, (short)4);18 g Fig. 5.: Counter \decrement" operation source codecommand APDUs).� To use a reader driver library to send command APDUs to the card appletand to get back response APDUs from the card applet� To decode response APDUs according to the format of the data returned inthe APDU DataOut �eld of bytes (see also Table 2 for the format of datareturned by the \counter" response APDUs). The client application mustalso check if the status bytes in the response APDU indicate an error.The overall design of a Java Card-based application (see Figure 6) shows thatthe main tasks of both the client application and the card applet are to processcommand and response APDUs to exchange information. The JCRE is the mainserver process to activate the card applet selected. It also provides the incomingcommand APDUs to the card applet's method process, and sends back theoutgoing response APDUs to the client application.2.5 SummaryDeveloping a Java Card-based application requires �rst to implement a JavaCard applet with the Java Card API. The applet code is essentially a code ma-nipulating card communication packets which are APDU data structures. Then,the Java Card applet is compiled using a regular Java compiler. The output isconverted in order to produce a byte code, which can suitably be downloaded ona Java Card, and run on the JCVM. Applet conversion and installation are notdiscussed in this article because they are yet to be standardized, and because

Client

select()

JCRE

decodes

Applet

commandprepares

APDU

responseAPDU

activates

"90 00" response APDU

Select "applet" APDU

Applet command APDUprocess(apdu)

processescodes response

terminatesApplet response APDU

decodes paramsFig. 6.: Java Card-based client application trace event diagramwe focus here on the whole Java Card-based application development method-ology rather than on the tools implied. Finally, it is necessary to implement theclient part of the Java Card application that is the code requesting operations tothe Java Card applet. This code communicates with the Java Card applet withAPDU data structures which must conform to those \understood" by the JavaCard applet method process.3 Developing GemXpresso-Based ApplicationsIn this section, a development methodology2 is de�ned in order to help Java pro-grammers to include Java Cards into the information systems they develop. Thismethodology is based on the de�nition of a distributed object system dedicatedto Java Card in which a client application accesses a Java Card applet throughan object interface. It is not an alternative to the Java Card speci�cation sinceit is built over it, and allows Java Card applets to operate with both modes.3.1 Distributed Object Programming with Java CardJava Card applets are objects residing in a di�erent machine (a smart card)from the terminal application. In Java Card, terminal and card programs form2 This methodology is herein referred by the word GemXpresso since it has been �rstimplemented in the Gemplus GemXpresso RAD product.

a client-server system where communication is de�ned by exchanges of low-levelcommunication packets (APDUs). By applying distributed programming tech-niques [4] { namely, Remote Procedure Call (RPC) { and object methodologyto Java Card, GemXpresso provides a development methodology which allowsdevelopers to abstract their design and code from communication protocol con-siderations.Remote Procedure Calling In client-server programmingmodel, the RemoteProcedure Call (RPC) mechanism has been introduced in order to abstract thecommunication interface to the level of a procedure call [15, 16]. Request mes-sages are regarded as procedure calls from a caller (the client), and reply mes-sages are regarded are return values from the callee (the server) which executesthe procedure body. Like a regular or local procedure call, an RPC is a syn-chronous operation requiring the requesting program to be suspended until theresults of the remote procedure are returned. The interesting feature of RPCis that it is a protocol that one program can use to request a service from aprogram located in another computer without having to understand commu-nication details. Instead of working directly with communication packets, theprogrammer has the illusion of calling a local procedure, when in fact the ar-guments of the call are packaged up and shipped o� to the remote target ofthe call. Generally, RPC systems encode arguments and return values using alanguage-neutral and machine-independant data representation. In distributedobject-oriented systems object interfaces provide a means for client and serverto agree on exactly which server's methods can be invoked through RPC. Eachinterface contains the de�nitions for the methods and their parameters expressedin an Interface De�nition Language (IDL).When a client invokes a remote method, the call is handled by a client stubrunning on the client host (see Figure 7). The client stub converts the method'sparameters into a form suitable for transmission (a process called marshaling)and causes one or more communication packets to be sent to the server. At theserver, a server stub unmarshals the parameters, putting them in the correctformat for that system, and invokes the requested method. The method executes,then sends any results back via the same path, that is, through the stubs. Oncecomplete, the called method returns from the client stub back to its caller likean ordinary method call. Throughout this process, remote calls are embodiedin RPC protocol's messages (containing the marshaled parameters and results)which are transported on top of communication protocols.Creating a distributed application with RPC-based systems, then, requiresspecifying all interactions between clients and servers in one or more interfaces.These interfaces are used to produce stubs, which in turn are combined withthe actual application code. Whatever the distributed application is doing, RPCruntime routines provide a foundation for interaction between its components.Therefore, RPC-based systems make the developer's work easier by hiding thecumbersome task of communication management thanks to:� The computed generation of client and server stubs from the interface. Gen-

Client machine

Receiverequest

Server stub

Selectmethod

Methodimplem.

Unmarshal

Receivereply

results

Dispatcher

Localreturn

Localcall Marshal

parameters

Sendrequest

moduleComm.

moduleComm.

Marshalresults

Executemethod

Return

parametersUnmarshal

Client stubClient

Server machine

Sendreply

RPC reply

RPC request

Com

mun

icat

ion

Pro

toco

l

Fig. 7.: Typical RPC moduleserated codes are speci�c to the client and server languages and platforms.� The integration in client and server machines of RPC runtime libraries, whichhandles the communication (transmittion and reception of RPC request andreply messages) and the binding of client and server.Java Card Applets as Remote Objects The development methodologypromoted by GemXpresso extends the Java Card concept (a card that can beprogrammed in the object-oriented Java language) to a distributed object-basedsystem where communication between card applets and client applications isabstracted from low-level protocols. The main characteristics of this approachis that it relies on an RPC-based system dedicated to smart cards. A GemX-presso card applet is a server object, which is developped without any concernabout communication protocols; it just has to be de�ned by a Java interface.For the client application, card applets are like remote objects in a distributedsystem; it invokes applet methods through a client stub handling the communi-cation interface. GemXpresso is built on the following facilities which supportthe infrastructure for building such distributed applications (see Figure 8):

parametersUnmarshal

results

Com

mun

icat

ion

prot

ocol

Marshal

JCRE

Rea

der/

Car

d

Terminal application

Unmarshal

Receivereply

resultsLocalreturn

Localcall Marshal

parameters

Sendrequest

Client Applet proxy Reader/CardAPI

DMI request

DMI reply

Receiverequest

moduleComm.

Local call

Card applet

Local return

replySend

GemXpresso card

Fig.8.: GemXpresso DMI modules� A card applet must be de�ned by a Java interface. An interface speci�esthe methods provided by a card applet that are visible to the card applet'sclients.� The card applet interface de�nition is used as a basis on which to constructthe client stub of the client (called proxy) and to provide applet descrip-tion to the JCRE. The provided information will be used by the proxy andthe JCRE (some kinds of client and server stubs) for the marshaling andunmarshaling processes of the method invocations.� An RPC-like communication protocol, called Direct Method Invocation (DMI),is used for transporting method calls and return results as request and replymessages exchanged between the terminal application and the smart card.The following sections show the GemXpresso development methodology inaction, using the \Counter" card applet. The card applet design and implemen-tation is described in section 3.2. Section 3.3 describes how to use the generatedapplet proxy to build a client application.

3.2 Writing a GemXpresso AppletCard Applet Design The �rst step in creating a GemXpresso card applet isto de�ne an interface describing the methods that are available remotely. Thisinterface de�nes the entry points for the card applet with a list of methods thatwill be available to client program through DMI. For example, the ICounterinterface (see Figure 9) de�nes three methods with their parameter and returntypes, and the exceptions they may throw. Those are method signatures thatwill be used by DMI to marshal and unmarshal method invocations from clientapplications to the implementation of ICounter. As a card applet interface isused to describe what is handled by the DMI protocol, the DMI's characteristicsimpact on what can be described in the applet interface. Current limitations areoutlined below:1 import javacard.framework.*;23 public interface ICounter f4 public int read();5 public int increment(int amount) throws UserException;6 public int decrement(int amount) throws UserException;7 g Fig. 9.: GemXpresso ICounter interface source code� Parameter and return types: byte, boolean, short, int, and unidimensionalarrays of the previous basic types (void is available for methods which donot return a result).� Exception types: those de�ned in the Java Card speci�cation.Card Applet Implementation In Java Card the javacard.framework.Appletclass is the basic class which must be extended by a card applet to implement itsprocessing of APDUs and its interactions with the JCRE. In GemXpresso, aninterface is used to represent the contract which binds an applet to its clients.Thus, a card applet must be declared as an implementation of this interface.The processing of APDUs and the interactions with the JCRE do not need tobe explicit since they are taken in charge by the DMI mechanism provided withthe JCRE. Moreover, GemXpresso card applets do not have to implement themethod install, the invocation of one of the constructors is su�cient for in-stantiating and installing the applet object in the card. These features enablethe programmer to implement an applet like an ordinary Java class without con-siderations about the communication of data between the card applet and theclient applications (see Figure 10).

1 import javacard.framework.*;23 public class Counter extends Applet implements ICounter f4 private int value;56 public Counter() f value = 0; register(); g78 public int read() f return value; g910 public int decrement(int amount) throws UserException f11 if (amount<0 || value-amount<0) throw new UserException((short)1);12 value -= amount; return value;13 g1415 public int increment(int amount) throws UserException f16 if (amount<0) throw new UserException((short)1);17 value += amount; return value;18 g19 g Fig. 10.: GemXpresso Counter class source codeIn order to keep an upward compatibility with Java Card a GemXpressocard applet also extends the class Applet. The methods of Applet keep thesame semantics and can be overriden to work with the JCRE like an ordinaryJava Card applet.3.3 Writing a GemXpresso-based ApplicationWith GemXpresso a Java Card proxy is generated from the card applet interfaceby the development environment (called GemXpresso RAD). The proxy is a pieceof code that takes in charge the communication between the client applicationand the card applet. This design pattern [2] is the foundation of RPC-baseddistributed system in which the client invokes methods on a local object (theproxy), which represents the original object (the card applet) on the client-side.The proxy is used by the client like the original applet since both the proxy andthe applet are implementations of the same interface (see Figure 11).The proxy processes each method invocation on the applet interface in thefollowing way:1. It prepares a DMI invoke message with the parameter values provided bythe client.2. It sends this message to the GemXpresso card, which decodes the messageto invoke locally the method on the card applet. The return value of the

method1 (...) : ...method2 (...) : ...

method1 (...) : ...method2 (...) : ...

Proxy

Client

task()

communicates

extends

attributes...

method1 (...) : ...method2 (...) : ...

Original

AbstractOriginal

invokes Fig. 11.: GemXpresso client application designmethod is returned to the proxy as a DMI response message.3. It decodes the response message and returns the applet return value to theclient like a local return call.>From the client application point of view the code needed to communicatewith the card is encapsulated in the proxy and programmers just have to invokeinterface methods to request a service from the card applet. In GemXpressoclient application, invoking a decrement operation on the \Counter" card appletcan be written as in Figure 12.1 // Create the card applet proxy with the class GxCabCounter generated2 // by the GemXpresso RAD3 ICounter counter = new GxCabCounter(...);4 // Select the applet5 if ( counter.select() == true ) f6 // Use counter to communicate with the card7 System.out.println("Balance = " + counter.read());8 System.out.println("New balance = " + counter.decrement(10));9 g Fig. 12.: GemXpresso client application implementation4 ConclusionIn the Java Card client-server model all the exchanged messages are based onAPDUs directly handled by the client application and the card applet at the

level of their application code. APDUs require the client application and the cardapplet to engage in application-level protocols to encode and decode messagesfor exchange, and the design of such protocols is cumbersome and can be error-prone.The GemXpresso approach is in fact similar in spirit to Java's RMI (RemoteMethod Invocation), or more precisely to the DCE's RPC (Remote ProcedureCall) mechanism. The client program gets a reference to a local object (theproxy) which represents the remote object (the card applet), and then uses thislocal object to call the remote object, by invokingmethods de�ned in the applet'sinterface. A speci�c protocol (DMI) between the host and the card is used forthis purpose. The DMI protocol is handled by the card operating system on theserver side and by an automatically generated proxy program on the client side.The aim of our framework is to simplify the task of a developer who wants todesign and write new application in which a smart card is used. Seeing the cardas a component in a distributed object system relieves programmers from dealingwith protocol issues, and allows them to spend more time on the application'score functionality.To conclude, we can say that Java Card is well suited for card developers andGemXpresso for Java developers. Java Card enables the re-development of legacyapplications in Java with processing of legacy APDUs, whereas GemXpressoenable the development of new card-based applications with distributed objecttechnologies.References1. Biget, P., George, P., and Vandewalle, J.-J. How Smart-Cards Can TakeBene�ts From Object-Oriented Technologies. In Hartel et al. [10], pp. 175{194.2. Buschman, F., Meunier, R., Rohnert, H., Sommerlad, P., and Stal, M.Pattern-Oriented Software Architecture - A System of Patterns. John Wiley &Sons, 1996.3. CardTech/SecurTech, Inc., Ed. CardTech/SecurTech 1997 conference proceed-ings, May 19 to 22, 1996, Orlando, Florida, U.S.A. (May 1997).4. Coulouris, G., Dollimore, J., and Kindberg, T. Distributed Systems: Con-cepts and Design, seconde ed. Assison-Wesley Publishing Company Inc., 1994.[http://www.dcs.qmw.ac.uk/research/distrib/book.html#guide].5. de Jong Frz, E. K. How to make a Java Card. In CardTech/SecurTech, Inc. [3],pp. 89{102.6. Dreifus, H., and Monk, J. T., Eds. Smart cards - A guide to building andmanaging smart card applications. John Wiley & Sons, 1998.7. Giorgio, R. S. D. Smart Cards: A primer. Java World 2, 12 (Dec. 1997).[http://www.javaworld.com/javaworld/jw-12-1997/jw-12-javadev.html].8. Giorgio, R. S. D. Understanding Java Card 2.0. Java World 3, 3 (Mar. 1998).[http://www.javaworld.com/javaworld/jw-03-1998/jw-03-javadev.html].9. Guthery, S. B., and Jurgensen, T. M., Eds. Smart Card Developer's Kit.Macmillan Technical Publishing, 1998.[http://www.scdk.com/].

10. Hartel, P. H., Paradinas, P., and Quisquater, J.-J., Eds. Proceedings ofthe 2nd International Conference CARDIS 1996 CWI, Amsterdam, The Nether-lands, September 16-18, 1996 (Amsterdam, Sept. 1996), Stichting MathematischCentrum.11. International Organization for Standardization (ISO). Draft Interna-tional Standard ISO/IEC 7816: Integrated circuit(s) cards with contacts { Part 4:interindustry commands for interchange. P.O. Box 56, 1211 Geneva 20, Switzer-land, 1994.12. International Organization for Standardization (ISO). InternationalStandard ISO/IEC 7816: Integrated circuit(s) cards with contacts { Part 3: elec-tronic signals and transmission protocols. P.O. Box 56, 1211 Geneva 20, Switzer-land, Nov. 1994.13. Khanna, R., Ed. Distributed Computing. Prentice-Hall Inc., 1994.14. Rankl, W., and Effing, W. Smart Card Handbook. John Wiley & Sons, 1997.15. Rosenberry, W., Kenney, D., and Fisher, G. Understanding DCE. O'Reilly& Associates, Oct. 1992.[http://www.ora.com/catalog/udce/].16. Sun Microsystems, Inc. Network Programmming Guide, Mar. 1990. Manual setfor SunOS 4.1.x.17. Sun Microsystems, Inc. Java Card 2.0 Language Subset and Virtual MachineSpeci�cation, Programming Concepts, and Application Programming Interfaces,Oct. 1997.[http://java.sun.com/products/javacard/].18. Sun Microsystems, Inc. Java Card Applet Developer's Guide, July 1998.[http://java.sun.com/products/javacard/JCADG.html].This article was processed using the LATEX macro package with LLNCS style