Documenti di Didattica
Documenti di Professioni
Documenti di Cultura
Keywords. Java Card software production, Smart card-based application design, Object-oriented framework.
During the past twenty years smart cards have evolved from simple dedicated
devices (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. All
other product names mentionned herein are the trademarks of their respective owners.
The Java Card specication describes a limited version of the Java language
and platform well dedicated to smart cards and legacy applications. Dening
the communication between the card application and the outside world as exchanges of APDUs forces programmers to design a proprietary protocol for every application they write. Both the client program and the card applet have
to implement a signicant amount of tedious code to encode and decode the
information exchanged accordingly with the protocol dened. This approach is
cumbersome to program, and it forces the developer to focus on the denition
of a smart-card dedicated low-level protocol rather than on the object design of
the whole application.
In this paper we propose a development methodology which allows the card
and client programmers not to worry about the protocol between the card and
the host. This methodology is based on the representation of the client/server
architecture made by the host and the card as a distributed object system. The
Java Card is considered as a server running an application that is described by an
interface. The card applet is a class that implements this interface. The client
program communicates with the card applet accordingly to the remote object
interface. 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 dened
in the interface.
For the communication between client programs and card applet we have
dened a protocol called Direct Method Invocation (DMI), which encapsulates
client requests to the card applets. The DMI protocol links the card to the host
and denes the way in which the card applet and the client program communicate. The protocol is handled by the Java Card operating system, making the
card applet source code enterely independent of it. On the client side the protocol is handled by a proxy program which is automatically generated from the
interface. The proxy represents the remote object (the card applet) on the client
side by oering to the client program the interface implemented by the applet.
The proxy implements the card applet interface but it contains the code required
to invoke the card applet methods using the DMI protocol (see Figure 1).
Terminal
Client program
Proxy
implements
interface
Card
DMI
Applet
implements
interface
A lightweight version of an electronic purse, since it can be incremented or decremented by an amount, but does not perform any security control.
To communicate with a smart card you need to write an application that sends
commands to a smart card connected to your host through a reader. >From the
host to the reader, and from the reader to the smart card data (commands and responses) are transported using protocols. The communication protocols between
smart cards and readers are dened by an ISO standard [12] as T=0 (character
protocol) or T=1 (block-chaining protocol). The problem is that there is no standardized protocol between the host and the reader. To permit the description of
card commands independantly of host-reader and reader-card protocols a format
has been standardized [11, 12]. This format denes the command message sent
from the client application, and the response message returned by the card to
the client application as Application Protocol Data Units (APDUs). Each manufacturer provides a driver to transport APDUs with its proprietary host-reader
protocol (see Figure 2).
Host
Client application
Command Response
APDU
APDU
Le
Processes APDUs
Reader driver
APDUs
Host-Reader Protocol
Reader
APDUs
Card application
T=0/T=1 Protocol
or initialized, or how the terminal may obtain information about a smart card.
The Java Card specication is a standard for programmers, whose goal is to
guarantee the interoperability of Java Card applications at the source code
level. To support this level of integration, a Java Card applet is dened as a
javacard.framework.Applet object with a set of methods (see Table 1) enabling the applet to communicate through javacard.framework.APDU objects
.
1. If the process or install method executes and nishes normally, then the
JCRE sends the status code 0x9000 (normal completion) as the status bytes
of the response APDU.
2. If the process or install method throws an ISOException, then the JCRE
sends the reason for that exception as the status bytes of the response APDU.
Method
Description
void deselect()
boolean select()
void process(APDU
process with a simple \counter" card applet, which stores an int value that
can be read, and can be incremented and decremented by a given amount (see
Figure 4). The counter is installed in the card by calling the constructor of the
applet, which sets the counter with an initial value to 0 and registers this applet
with the JCRE (the APDU parameter of the applet's install method is not used).
Applet Operations and APDUs Other operations are handled by the applet's process method, which decodes them with their arguments and returns
results according to the APDU mapping described in Table 2.
Implementation of the Applet Operations The source code of the decrement operation (see Figure 5) illustrates what has to be implemented to realize
a processing on APDU data. First it is necessary to retrieve the incoming data
from the APDU buer (line 3). As data are in a byte array, it is necessary to format them accordingly to the type used within the Java applet; in our example,
Client
JCRE
Command
APDU
APDU
initializes
Applet
process(apdu)
Idle
getBuffer
Init
setIncoming
Incoming
ReceiveBytes
processes
command
Outgoing
setOutgoing
setOutgoingLength
sendBytes
terminates
End
reads data
Response
APDU
1 import javacard.framework.*;
2
3 public class Counter extends Applet f
4
private int value;
5
6
public Counter() f value = 0; register(); g
7
public static void install(APDU apdu) f new Counter(); g
8
9
public void process(APDU apdu) f
10
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]) f
14
case 0x01: // Performs the read operation
15
case 0x02: // Performs the increment operation
16
case 0x03: // Performs the decrement operation
17
default: ISOException.throwIt(ISO.SW INS NOT SUPPORTED);
18
g
19 g
20 g
Operation
int read()
int increment(int)
int decrement(int)
APDU
Command: AA 01 XX XX 00 04
Response: RV3 RV2 RV1 RV0 90 00
Command: AA 02 XX XX 04 AM3 AM2
Response: RV3 RV2 RV1 RV0 90 00
Command: AA 03 XX XX 04 AM3 AM2
Response: RV3 RV2 RV1 RV0 90 00
AM1 AM0 04
AM1 AM0 04
2.5 Summary
Developing a Java Card-based application requires rst to implement a Java
Card applet with the Java Card API. The applet code is essentially a code manipulating card communication packets which are APDU data structures. Then,
the Java Card applet is compiled using a regular Java compiler. The output is
converted in order to produce a byte code, which can suitably be downloaded on
a Java Card, and run on the JCVM. Applet conversion and installation are not
discussed in this article because they are yet to be standardized, and because
Client
Applet
JCRE
activates
select()
prepares
command
APDU
process(apdu)
terminates
decodes params
processes
codes response
decodes
response
APDU
Java Card applets are objects residing in a dierent machine (a smart card)
from the terminal application. In Java Card, terminal and card programs form
2
This methodology is herein referred by the word GemXpresso since it has been rst
implemented in the Gemplus GemXpresso RAD product.
Client machine
Client
Client stub
Local
call
Server machine
Comm.
module
Comm.
module
Method
implem.
Server stub
Marshal
parameters
Send
request
RPC request
Communication Protocol
Local
return
Dispatcher
Receive
reply
Unmarshal
results
Receive
request
Select
method
Unmarshal
parameters
Execute
method
Return
Send
reply
Marshal
results
RPC reply
erated codes are specic to the client and server languages and platforms.
The integration in client and server machines of RPC runtime libraries, which
handles the communication (transmittion and reception of RPC request and
reply messages) and the binding of client and server.
Terminal application
Client
GemXpresso card
Local
call
Comm.
module
Marshal
parameters
Send
request
DMI request
Reader/Card
Communication protocol
Local
return
Card applet
JCRE
Receive
reply
Unmarshal
results
Receive
request
Unmarshal
parameters
Local call
Local return
Marshal
results
Send
reply
DMI reply
import javacard.framework.*;
public interface ICounter f
public int read();
public int increment(int amount) throws UserException;
public int decrement(int amount) throws UserException;
Parameter and return types: byte, boolean, short, int, and unidimensional
arrays of the previous basic types (void is available for methods which do
not return a result).
Exception types: those dened in the Java Card specication.
1 import javacard.framework.*;
2
3 public class Counter extends Applet implements ICounter f
4
private int value;
5
6
public Counter() f value = 0; register(); g
7
8
public int read() f return value; g
9
10 public int decrement(int amount) throws UserException f
11
if (amount<0 || value-amount<0) throw new UserException((short)1);
12
value -= amount; return value;
13 g
14
15 public int increment(int amount) throws UserException f
16
if (amount<0) throw new UserException((short)1);
17
value += amount; return value;
18 g
19 g
AbstractOriginal
method1 (...) : ...
method2 (...) : ...
Client
task()
extends
Original
attributes...
Proxy
invokes
1
2
3
4
5
6
7
8
9
// Create the card applet proxy with the class GxCabCounter generated
// by the GemXpresso RAD
ICounter counter = new GxCabCounter(...);
// Select the applet
if ( counter.select() == true ) f
// Use counter to communicate with the card
System.out.println("Balance = " + counter.read());
System.out.println("New balance = " + counter.decrement(10));
4 Conclusion
In the Java Card client-server model all the exchanged messages are based on
APDUs directly handled by the client application and the card applet at the
level of their application code. APDUs require the client application and the card
applet to engage in application-level protocols to encode and decode messages
for exchange, and the design of such protocols is cumbersome and can be errorprone.
The GemXpresso approach is in fact similar in spirit to Java's RMI (Remote
Method Invocation), or more precisely to the DCE's RPC (Remote Procedure
Call) mechanism. The client program gets a reference to a local object (the
proxy) which represents the remote object (the card applet), and then uses this
local object to call the remote object, by invoking methods dened in the applet's
interface. A specic protocol (DMI) between the host and the card is used for
this purpose. The DMI protocol is handled by the card operating system on the
server 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 to
design and write new application in which a smart card is used. Seeing the card
as a component in a distributed object system relieves programmers from dealing
with protocol issues, and allows them to spend more time on the application's
core functionality.
To conclude, we can say that Java Card is well suited for card developers and
GemXpresso for Java developers. Java Card enables the re-development of legacy
applications in Java with processing of legacy APDUs, whereas GemXpresso
enable the development of new card-based applications with distributed object
technologies.
References
1. Biget, P., George, P., and Vandewalle, J.-J. How Smart-Cards Can Take
Benets 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 proceedings, May 19 to 22, 1996, Orlando, Florida, U.S.A. (May 1997).
4. Coulouris, G., Dollimore, J., and Kindberg, T. Distributed Systems: Concepts 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 and
managing 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 of
the 2nd International Conference CARDIS 1996 CWI, Amsterdam, The Netherlands, September 16-18, 1996 (Amsterdam, Sept. 1996), Stichting Mathematisch
Centrum.
11. International Organization for Standardization (ISO). Draft International Standard ISO/IEC 7816: Integrated circuit(s) cards with contacts { Part 4:
interindustry commands for interchange. P.O. Box 56, 1211 Geneva 20, Switzerland, 1994.
12. International Organization for Standardization (ISO). International
Standard ISO/IEC 7816: Integrated circuit(s) cards with contacts { Part 3: electronic signals and transmission protocols. P.O. Box 56, 1211 Geneva 20, Switzerland, 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 set
for SunOS 4.1.x.
17. Sun Microsystems, Inc. Java Card 2.0 Language Subset and Virtual Machine
Specication, 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