Vol 1, No 2

Table of Contents
SAMPLE DEVELOPMENT ON JAVA SMART-CARD ELECTRONIC WALLET

APPLICATION .................................................................................................................................... 3
CRISTIAN TOMA................................................................................................................................ 3
1. INTRODUCTION .................................................................................................................................. 3
2. COMPLETE APPLICATIONS FOR JAVA SMART CARDS ...................................................................... 4
3. ISSUES IN THE DEVELOPMENT AND LIFE CYCLE OF A JAVA CARD APPLET .................................... 7
4. PRACTICAL SAMPLE OF DEVELOPING A JAVA APPLET CARD ....................................................... 10
5. CONCLUSIONS .................................................................................................................................. 15
REFERENCES.................................................................................................................................... 15
SECURE MECHANISMS FOR E-TICKETING SYSTEM........................................................... 23
CRISTIAN TOMA.............................................................................................................................. 23
1. INTRODUCTION ................................................................................................................................ 23
2. CONCEPTS OF THE SECURE AUTOMATIC TICKETING SYSTEM .................................................... 24
3. NXP PHILIPS MIFARE MEMORY CARDS ........................................................................................ 26
4. SATS ARCHITECTURE AND DATA STRUCTURES ........................................................................... 32
5. CONCLUSIONS .................................................................................................................................. 35
REFERENCES.................................................................................................................................... 35
SECURE SMART-CARD TECHNOLOGIES USED IN E-COMMERCE .................................. 37
CATALIN BOJA................................................................................................................................. 37
1. INTRODUCTION ................................................................................................................................ 37
2. SMART CARDS TECHNOLOGIES ...................................................................................................... 38
3. JAVA CARD TECHNOLOGIES FEATURES ........................................................................................ 39
4. E-COMMERCE FEATURES ............................................................................................................... 40
5. ANALYSIS OF SET – SECURE ELECTRONIC TRANSACTIONS ........................................................ 41
6. CONCLUSIONS .................................................................................................................................. 48
REFERENCES.................................................................................................................................... 48
ON-LINE PAYMENT SYSTEM SURVEY – ECASH ................................................................... 50
MARIUS POPA, ADRIAN CALUGARU...................................................................................... 50

1. INTRODUCTION ................................................................................................................................ 50
2. ELECTRONIC MONEY AND PAYMENT ELECTRONIC SYSTEM FEATURES....................................... 51
3. ELECTRONIC MONEY PAYMENT MECHANISMS .............................................................................. 52
4. ECASH PAYMENT SYSTEM............................................................................................................... 54
5. CONCLUSIONS .................................................................................................................................. 57
REFERENCES ........................................................................................................................................ 57
E-COMMERCE PROJECT MANAGEMENT ISSUES ................................................................. 58
MIHAI DOINEA............................................................................................................................... 58
1. INTRODUCTION ................................................................................................................................ 58
2. THE INVOLVEMENT OF PROJECT MANAGEMENT IN COMPANIES................................................ 59
3. THE DIMENSIONS OF PROJECT MANAGEMENT IN E-COMMERCE PROJECTS ............................. 60
4. CONCLUSIONS .................................................................................................................................. 63
REFERENCES ........................................................................................................................................ 64
DECWEB - INTERNET FISCAL STATEMENT SUBMISSION ............................................... 65
MIHAI IANCIU, COSTIN BURDUN, IONUT FLOREA ............................................................................ 65

1. PROJECT OVERVIEW AND OBJECTIVES ......................................................................................... 65
2. PROJECT DETAILS ........................................................................................................................... 66
3. THE IMPACT OF THE PROJECT ....................................................................................................... 69
4. OUTLOOK ......................................................................................................................................... 70
REFERENCES ........................................................................................................................................ 71
Sample Development on Java Smart-Card Electronic
Wallet Application
Cristian TOMA
Faculty of Cybernetics, Statistics and Economic Informatics
Department of IT&C Technologies
Academy of Economic Studies Bucharest, Romania
cristian.toma@ie.ase.ro
Abstract: In this paper, are highlighted concepts as: complete Java card application, life cycle of an applet, and
a practical electronic wallet sample implemented in Java card technology. As a practical approach it would be
interesting building applets for ID, Driving License, Health-Insurance smart cards, for encrypt and digitally sign
documents, for E-Commerce and for accessing critical resources in government and military field. The end of this
article it is presented a java card electronic wallet application.
Key-Words: smart card, Java Card application, ISO 7816, JCRMI.
1. Introduction
The cards are classified in magnetic strip cards and smart cards. The smart ones are
divided after many features. For instance, if we consider the way how they communicate
with the card reader device, those are contact-less – the communication between card
reader and smart card is made through radio wave, with contact – the smart card make
a physical contact with the smart card, or combined.
Concerning the type of integrated circuit that a smart card could have, the smart cards
are classifying in:
Cards with microprocessor chip, short term chip cards, contains a
microprocessor which is used for computations. Besides this microprocessor
with 8, 16 or 32 bits register, the card could contain one or more memory
chips which is using for read-only memory and for random access memory –
RAM. This features offer to a card almost the power of a desktop computer.
This type of cards are used in different informatics systems like banking credit
cards, cards for access control in institutions, SIMs – Secure Identification
Module – for mobile phones and cards for accessing digital TV networks.
Cards with memory chip, contains different data but can not compute the
store data because the card don’t have a microprocessor. They are fully
depended by the host application.
In our days most of the specialists agree on the idea, that a card is smart only if it can
compute, only if it has a microprocessor or a microcontroller. Keeping on this approach,
the difference between a smart card and a card only with memory chips or magnetic
strips, is that the last one only can store data and can not compute the data. The
informatics systems which are interacting with smart cards have an advantage because
the access to the different data bases and the time of transactions could be considerably
minimized. More than that, some smart cards contain non-volatile memories which
provide a great advantage regarding the development of secure systems and
applications, because in those memories they can store sensitive information like digital
certificates, symmetric and asymmetric private keys. In order to improve the speed of
computations, this kind of cards have also specialized cryptographic coprocessors. The
coprocessors execute complicate cryptographic algorithms like RSA, AES-Rijndael, 3DES
or algorithms based on elliptic curves. In the following sections will be implemented step
by step an electronic wallet implemented on a smart card as a Java card applet.
2. Complete applications for Java smart cards
A Java card application is an applet which is running in smart card. But often the applet
needs to interact with different systems and applications. That’s why in specialty
literature a complete application for Java smart card is composed from the java applet
which is running on smart card, a host application and back-end application systems
which provide to the end-user a service.
In figure 1 is depicted a complete Java card application:

Desktop, Laptop,
Server Intelligent Card
Applications
for business
logic Applet Applet
TCP/IP or IPC Electrical
communication device for
interaction
with cards APDU Vendor
APDU
Command Command Extensions
HOST CAD
Application JCRE JCAPI
APDU APDU
Response Response JCVM
Card OS
The link is through serial or The contact is realized through

parallel cable, USB, infrared or pins, ISO/IEC 14443-4:2001- radio
even Bluetooth wave or Bluetooth
Legend:
JCVM=Java Card Virtual Machine CAD=Card Acceptance Device

JCAPI=Java Card Advanced Programming Interface IPC=Inter-Process Communication
JCRE =Java Card Runtime Environment APDU=Application Protocol Data Unit
Fig. 1 Complete Java smart card application
With more details, informatics systems that use smart cards will have the following items
from point of view of a complete Java card application:
Back-end Applications – the ones that implement the business logic and
connects to the data bases and web services;
Host or off-card Applications – the ones that communicate with the card
reader, they are the interface between Back-end applications and the card
reader. These applications run on the desktop which is connected with the
card reader. Also they can run on specialized terminal like ATM-Automatic
Teller Machine or can run on a mobile phone which is used as a smart card
reader;
Card Reader Applications – these are running in the card reader and are
responsible for the accomplishment and the coordination of the interaction
with card’s applications. The physical equipment, the card reader, plus with
the applications that are running on it, is called CAD – Card Acceptance
Device. The CAD is responsible how is realized the physical connection with
the card, through electrical contact or radio wave. Also the card is responsible
for providing energy for the card. The CAD takes APDU-Application Protocol
Data Unit- commands – standard strings of bytes – from host applications and
are forwarded to the smart cards;
Smart cards’ Applications – in Java Card platform can be in the same time
many applications, applets. The applets are run in JCRE – Java Card Runtime
Environment.
There are three models which can be used in order to realize the communication
between host application and Java applet. First model is quite simple and is supposing to
send and receive template strings of bytes in typical format – Message-Passing Model.
The second model is Java Card Remote Method Invocation – JCRMI, which is a set of
classes and procedures likely with the ones from J2SE – Java 2 Standard Edition RMI,
but basically this model use the first model. The third model for the communication
between host and the applet from the card, is SATSA – Security and Trust Services API.
SATSA defined in JSR 177, provide to the developers to use whatever model as base –
Message-Passing Model or JCRMI, but is a more abstract API based on GFC – Generic
Connection Framework API. So, most of developers use the first two models in order to
develop smart cards complete applications.
2. 1 Message-Passing Model
This is the reference model and represents the base for the other two existent models,
JCRMI and SATSA for developers. The communication between host application and the
applets from smart card suppose to transmit some APDU – Application Protocol Data Unit
from host to CAD – Card Acceptance Device, and then the same bytes strings are sent
from the CAD to the card applet. The applet receive those bytes strings, is parsing the
bytes and then will send back following the reverse path: Applet-CAD-Host. An APDU is
composed from standard bytes blocks conform ISO/IEC 7816-3 and 7816-4. Respecting
the standards the applet receives directly from CAD, APDU Commands and sends back to
CAD, APDU Responses. The communication between the card reader and the card is
physically realized through data link protocol. This protocol is likely data link level
protocol from protocol stack ISO/OSI. The link protocol, defined in ISO/IEC7816-4, has
four alternatives: T=0 – byte oriented, T=1 – bytes arrays oriented, T=USB – oriented
Universal Serial Bus or T=RF – radio wave oriented, Radio Frequencies. The classes from
Java Card API and JCRE specifications embed the physical details for APDU
communication protocol.
2.1.1 APDU Commands
The general template for an ADPU Command is depicted in figure 2:
APDU Command
CLA INS P1 P2 Lc Data Field Le
Header-mandatory Body-optional
Fig. 2 General structure for an APDU Command
There are other four specific structures for an APDU Command, but these structures are
used only in data link protocol T=0.
The explication for the fields from the APDU command is the following:
CLA – is one byte – 2 hexadecimal digits, and has different predefined values
conform standard ISO7816. For instance, between the value 0x00 and 0x19
are values for accessing file system and security operations, from 0x20 to
0x7F are reserved for future using, and from 0x80 to 0x99 can be used for
applets’ specific instructions implemented by developers but between 0xB0
and 0xCF are specific instructions for all applets and not for a particular one.
As matter of fact the most used value for this field is 0x80;
INS – is one byte, and the standard defines a specific instruction in the field
CLA. For instance, when CLA has the value between 0x00 and 0x09, but INS
has the value 0xDC – means card’s records update. In personal applications
which are installed on the card, the field INS could have predefined values
established by developers but according with the standard. For example, the
developer chooses for this field the value 0x20 for checking sold amount from
card if and only if the CLA field is 0x80;
P1 – this represents the first parameter for a instruction and has one byte.
This field is used when the developers want to send some parameters to the
applet or want to qualify the INS field;
P2 – this is the second parameter for an instruction and has one byte. Is used
for the same scope like P1;
Lc – has one byte, is optional and represents the bytes length for the field
Data Field;
Data Field – is not fixed and has a bytes’ length equal with the value from the
field’s value Lc. In this field are stored data and parameters which are send
from host application to applet;
Le – stores the maxim number of bytes that should have Data Field from
APDU Response (the number of bytes from response could be any value from
the range 0 and the value from this field).
Practically a host application sends to the CAD but the CAD sends to the applet the same
APDU commands with structures and values which respect the standards.
2.1.2 APDU Responses
The structure for an APDU Response is simple and is depicted in the figure 3:
APDU Response
Data Field SW1 SW2
Body-optional Trailer-mandatory
Fig. 3 Structure for an APDU Response
The fields’ explication for APDU Response is the following:

Data Field – has variable length which is determined by the value of the byte
field Le from the APDU Command;
SW1 – has one byte and represent the status word 1;
SW2 – has one byte and represent the status word 2.
The fields SW1 and SW2 are parsed and interpreted together, but a communication
process is called complete if there were no problems (SW1=0x61 and SW2=0x90 or any-
0xnn) or if there were only warnings (SW1=0x62 or SW1=0x63 and SW2 contains the
warning code). A communication process is called failed if there were execution errors
(SW1=0x64 or SW1=0x65 and SW2 has the error code for execution) or checking errors
(SW1=from 0x67 to 0x6F and SW2 has the code for checking error).
In message passing model there is all the time a selected applet in the card and when is
receiving an APDU Command (if this command’s request is not for switching the applets
execution) JCRE calls automatically the applet method process() and passing the bytes
values as argument for the method. In the method process(), the applet must parse and
process the command and must generate an APDU Response. After that the methods
return the control to the JCRE. In the section regarding the Life cycle for a Java applet
are discuss all the steps which are made by an applet in order to communicate with the
card reader conform to the protocol standard.
2.2 JCRMI Model

The second model represents a distributed object oriented model subset – J2SE RMI. In
this model, even if behind the scene, physically, the communication is realized through
APDU, the developer should not be aware by protocol details. The developer is focusing
only on the problem and is not interested in the idea that on level below this model is
using the message passing model.
In the JSE RMI model – Java Standard Edition Remote Method Invocation, a client
application obtains references using an interface to the Java objects which are running in
others JVM-Java Virtual Machine eventually on the different computers in network. Once
the reference-pointer is obtained, the application forces the execution of an object’s
specific method which is running in other JVM. If a card applet knows to add two
numbers, the developer only sends the two numbers as method’s parameters to the card
and the method from card is executing the add operation and return the results to the
developer’s application. So, the card is not store equipment, it is also an important tool
for computing.
For instance, if an applet object implement the X(int p1) method then a host application
which is running on a desktop computer obtains the reference to the object that
implement method X. Using the reference the application is calling the method with a
proper parameter, X(5). The parameter and others details are sending through APDU
and the received APDU Responses are embedded respecting RMI technology.
3. Issues in the development and life cycle of a Java card applet
For an Java card applet-application is involved a series of elements and concepts, of

which the most important are: Java Card Virtual Machine – JCVM, Java Card Advanced
Programming Interface – JCAPI, Java Card Runtime Environment – JCRE, the life cycle of
JCVM and of the Java card applet, the Java Card sessions, logical channels, isolation and
partition of the applet objects, memory and memory objects management and persistent
transactions.
For the Java Card platform, JCVM is divided in two parts. One part is external to the
physical card and is used as a developing tool. This part converts, uploads and verifies
the Java classes that have been compiled with a normal Java compiler. The finality of
this external part is that from a class normally compiled Java-byte code, results a binary
execution CAP file – Converted Applet, which will be executed by the JCVM on the card.
The other part of JCVM resides on the card and is used to interpret the binary code
produced by the first part and for the management of objects and classes. The card part
of the JCVM has, analogically, approximately the same use as a JVM – Java Virtual
Machine for a desktop computer. Of course JCVM has a series of limitations of syntax
language as well as of organization structure. For instance, as limitations of syntax-
language it is possible to mention the lack of support for some key words (native,
synchronized, transient, volatile, strictfp), for some types (double, float, long) and for
some classes, interfaces and exceptions (the majority of the classes, interfaces and
exceptions from the packages java.io, java.lang, java.util). As limitations of organization
structure language, it is mentioned the fact that a package cannot contain more than
255 classes and a class cannot directly or indirectly implement more than 15 interfaces.
More details are presented in the specifications of the virtual machine for Java Card
platform [JCVM03].
JCAPI defines a subset of classes, interfaces and exceptions from Java 2 Standard
Edition. There is no support for the multi-string execution programming, for important
classes such as String, Boolean, Integer or BigInteger. The packages that work with by
JCAPI are the following: java.io, java.lang, java.rmi, javacard.framework,
javacard.framework.service, javacard.security, javacardx.crypto, javacardx.rmi.
It is mentioned as follows:
From the package java.io there is kept only the IOException class to complete
the hierarchy of classes concerning the exceptions from Remote Method
Invocation;
From the package java.lang there is kept the simplified version of the classes
Exception, Object şi Throwable and it is introduced the class CardException;
From the package java.rmi there is kept the Remote interface and the
RemoteException class;
There is introduced the package javacard.framework that contains interfaces
(ISO7816 – contains constants used by the standard, MultiSelectable – used
by the applets that accept competitive selection, PIN – represents Personal
Identification Number, Shareable – used for objects that can be partitioned on
the card applets), classes (AID – identifies according to ISO7816-5 the unique
identifications for Application Identifier applets, APDU – embeds Application
Protocol Data Unit, that have been presented in the above paragraphs, as in
ISO7816-4, Applet – abstract class that defines the application-applet which
resides on the card, JCSystem – contains specific methods for controlling the
life cycle of an applet, OwnerPIN – an implementation of the PIN interface,
Util – contains methods such as arrayCompare() and arrayCopy() for editing
the octet strings from the smart card memory) and exceptions
(APDUException, ISOException, SystemException, TransactionException,
CardException) intensively used for developing the applets for the Java Card
platform;
It is introduced the package javacard.framework.service that contains
interfaces (Service – it is an interface for the basic service used by the applet
for processing the APDU Commands and Answers by methods such as
processCommand(), processDataIn() and processDataOut(), RemoteService –
interface for the remote access to the card services by RMI, SecurityService –
it extends the Service interface and provides methods such as
isAuthenticated(), isChannelSecure() or isCommandSecure() for verifying the
current security state), classes (BasicService – the pre-defined
implementation of the Service interface and provides helping methods for
collaborating with different services and for APDUs editing, Dispatcher – used
when the same APDU Command is intended to be edited by different services)
and exceptions (ServiceException) for the different services management;
It is introduced the package javacard.security that contains interfaces (Key,
PrivateKey, PublicKey, SecretKey and sub-interfaces specialized in algorithms
such as AESKey, DESKey, DSAKey, DSAPrivateKey, DSAPublicKey, ECKey,
ECPrivateKey, ECPublicKey, RSAPrivateCrtKey, RSAPrivateKey,
RSAPublicKey), classes (Checksum – abstact class for algorithms used for the
cyclic check of errors, KeyAgreement – normal class for algorithms based on
the exchange of keys of Diffie-Helman type, KeyBuilder – assures the way of
key creation, Keypair – a container, such as a vector, that holds the pairs of
private and public keys, MessageDigest – basic class for algorithms of hash
type, RandomData – basic class for random numbers, Signature – abstract
class for electronic signature) and exceptions (CryptoException) for different
cryptographic algorithms with public and private keys, digital signatures, hash
functions and for the cyclic verification of redundancy (CRC);
It is introduced two extension packages javacardx.crypto and javacardx.rmi.
For a better documentation it is recommended the developer’s and user’s guides

[MANU03], [MANU03a] and the specifications Java Card API [JCAP03].
JCRE is the connection component, the interface, between the native operating system
of the smart card and the applet for the Java Card platform, as in Figure 3. JCRE assures
for the applets the access to the services of the card operating system. JCRE is
composed of JCVM, JCAPI and the extensions specific for the card producers. For a
complete documentation concerning JCRE and the actions it is responsible for: the life
cycle of JCVM, the persistency and partition of the objects in the card memory, the
allocation of logical channels, the selection and isolation of applets, refers to the JCRE
specifications [JCRE03].
The life cycle of JCVM and of a Java Card applet should be understood by any
developer of such applications. The life duration of JCVM is the same with that of the
card. If the power supply of the card stops, the entire content of JCVM is saved in the
persistent memory, non-volatile. Everything in the internal memory-RAM-volatile of the
card at the moment of the interruption of power is lost. Moreover, the objects created in
the Java Card platform are non-volatile, and if it is sometime intended that an octet
string should be in the volatile memory because, for instance, it holds only temporary
data, we should use the method makeTransientByteArray() of the class
javacard.framework.JCSystem.
The methods by which the applet life cycle is realized and that the applet should
implement are presented in figure 4:
Applet Java Card
1. install()
2. register()
3. select() 5. deselect()
4. process()
JCRE
Card operating system
Fig. 4. Methods to be implemented by an applet to execute the complete life cycle
Each applet is uniquely identified by an octet string – between 5 and 16, as defined in
ISO7816-5. The octet string is named AID – Application ID in the standard. As well, each
applet should extend the abstract Applet class and implement the methods – install(),
register(), select(), process(), deselect(), that represent the applet life cycle.
The applet life cycle starts immediately after it is downloaded into the card and JCRE
forces the execution of the static method Applet.install() and at its turn the applet is
registered in JCRE by calling the static method Applet.register(). After the applet is
installed and registered, it exists on the card as „not selected”, the equivalent
denomination being inactive applet. An applet is activated to process APDU Commands
only after the host type application sends to JCRE by CAD an APDU command of type
SELECT or MANAGE CHANNEL. JCRE complies and notifies the concerned applet by
forcing the execution of select() method which the applet implements. After the selection
is done, all the APDU commands received from the host type application by CAD of JCRE
are sent to the applet by forcing calling the method process() implemented by the
applet. The life cycle of the applet ends when the host application intends to select
another applet for processing the APDU commands, moment when JCRE notifies the
applet by forcing the execution of deselect() method of the applet.
In what concerns the Java Card sessions and the logical channels, these concepts
are explained in the specifications of JCRE [JCRE03]. Starting with Java Card 2.2, a card
may have up to 16 sessions simultaneous opened, if a session occupies just one logical
channel. In what concerns the specifications, a session is the time period since the card
is power supplied up to when it is disconnected from the power supply, time period when
it exchanges APDU commands and answers with the card reader. The host type
application sends an APDU command in sequence to JCRE, but according to each value
from the one octet field-CLA, JCRE sends it to one applet or another without selecting
and deselecting the applet each time. At its turn, an applet may receive several APDU
commands pseudo-simultaneously because it may be designed to be multi-selectable
meaning that it will implement the methods of the interface
javacard.framework.MultiSelectable. Practically, this means that if there are two different
APDU commands, each one on a different logical channel, an applet may interpret both
of them, or, as well, two different applets may separately process a command of the
two.
Isolation and partition of the applet objects is an important concept because on a

card can co-habitat several applets produced by different developers. The main idea is
that the objects created in the memory that belong to the same package are placed in a
neighboring memory zone that is separated of another memory zone by a firewall. In the
same memory zone separated by the firewall – in the same context according to the
specific literature – con not co-exist objects from different packages. This has major
implications for the applet development, because an object in the memory and belongs
to a package cannot access the methods of a different object from another package,
even if the methods are public. The access is made by JCRE. For instance, the object
Applet1 requests to the JCRE access to the public methods of the object Applet2 by
calling the system method JCSystem.getAppletShareableInterfaceObject(). Immediately
JCRE asks the object Applet2 to give sharing interface to the object Applet1, by the
automatic calling by JCRE of the method getShareableInterfaceObject(), implemented by
the class of the object Applet2. If the object Applet2 admits the sharing, then Applet1
will obtain a reference to Applet2 by which it may access the public methods of the
object Applet2. If Applet1 and Applet2 are in the same context, meaning that they
belong to the same package, it is not necessary to take the steps described above in
order to cooperate with the intermediary JCRE.
Memory and memory objects management is an important concept because the

smart card memory is quite small and restrictive. Moreover, some implementations of
the Java Card platform do not provide Garbage Collector – a program that cleans the
memory occupied by objects not used any more. So, when an object is created it is
created in the non-volatile memory. If it is desired that an octet string or an object
should be moved to the volatile memory, meaning to become „transient”, it is used one
of the methods: static byte[] makeTransientByteArray(short length, byte event), static
Object makeTransientObjectArray(short length, byte event), static short[]
makeTransientShortArray(short length, byte event). It must be taken into account that
an object or an octet string that is „transient” has a series of disadvantages such as: it
does not persist in the memory if something bad happens along the card sessions and
cannot have it fields update during the transactions.
An important concept available for the Java Card platform is that concerning the
persistent transactions. Similar to databases, for the card operating system it should
be applied the atomic modification of some memory zones, meaning that the fields of an
object in the non-volatile memory wheather modify all in the same time or they do not
modify at all. This can be achieved by: JCSystem.beginTransaction(),
JCSystem.commitTransaction(), JCSystem.abortTransaction(). In the specifications it is
mentioned that JCRE cannot sustain imbricate transactions.
4. Practical sample of developing a Java applet card
This practical example will be deployed as in the Message-Passing model. In what

concerns the models JCRMI and SATSA, because of the space limits, they will be
analyzed in future approaches. In order to develop a Java Card application it is needed a
Java 2 Standard Edition compiler, preferably version 1.4.1 [J2SE04], a Sun Java Card
Development Toolkit – SJCDT [JCDT04], [JCDT04a] and optionally an integrated
developing environment – IDE such as Borland JBuilder, Net Beans or IntelliJ IDEA. The
source code with explanations in English is taken of the examples provided by SJCDT
and is entirely presented in the annexes. The source code, whether it contains several
syntax modifications, is as in the license property of Sun Microsystems. This paragraph is
spitted in two parts: one which explains the way of compiling, converting and uploading
on the card the example and one which explains significant parts of the code and
interprets results.
4.1 Steps taken for compiling and uploading an applet on the card
After it is downloaded and extracted Sun Java Card Development Toolkit – SJCDT
[JCDT04], the source code entirely presented in the annexes is written in a text file
named Wallet.java. We set the Environment Variables, according to the user’s guide for
the developing kit [MANU03a] so that JC_HOME should contain the path for the kit
distribution – the directory that includes the bin directory with the batch files
apdutool.bat, cref.exe, converter.bat; and JAVA_HOME should contain the distribution
J2SE 1.4.1 [J2SE04] – the directory which includes the bin directory with programs such
as java.exe, javac.exe.
There are two ways to compile, develop and test the applets for the Java Card platform.
The first is that which uses the Java simulator included in the developing kit named –
JCWDE – Java Card Workstation Development Environment, and the second is that which
uses – C-JCRE – C-language Java Card Runtime Environment. C-JCRE represents the
reference interpretation written in C by Sun Microsystem as to simulate and implement
JCRE according to the specifications. The most “real” way, for which the procedure is
similar to that in the practice is thoroughly described in this chapter and represents the
way it is used C-JCRE.
The steps taken for compiling, uploading and simulating a card applet are:
Saving the source code as in the annex into the file Wallet.java in the
directory structure
‘Wallet1\com\sun\javacard\samples\wallet’;
Step 1 – Compilation – Positioning into the directory ‘Wallet1\com\sun\
javacard\samples\wallet’ and subsequently introducing the commands:
o SET
_CLASSES=.;%JC_HOME%\lib\apduio.jar;%JC_HOME%\lib\apdutool.jar;
%JC_HOME%\lib\jcwde.jar;%JC_HOME%\lib\converter.jar;%JC_HOME%\l
ib\scriptgen.jar;%JC_HOME%\lib\offcardverifier.jar;%JC_HOME%\lib\api.j
ar;%JC_HOME%\lib\installer.jar;%JC_HOME%\lib\capdump.jar;%JC_HOM
E%\lib\javacardframework.jar;%JC_HOME%\samples\classes;%CLASSPAT
H%;
o %JAVA_HOME%\bin\javac.exe -g -classpath %_CLASSES%
com\sun\javacard\samples\wallet\Wallet.java
Step 2 – Editing the configuration file for card uploading – in the
directory Wallet1 in the directory structure mentioned for step 1 it is created a
text file for configuration named ’wallet.app’ that includes the following:
o // applet AID
com.sun.javacard.installer.InstallerApplet 0xa0:0x0:0x0:0x0:0x62:0x3:0x1:0x8:0x1
com.sun.javacard.samples.wallet.Wallet
0xa0:0x0:0x0:0x0:0x62:0x3:0x1:0xc:0x6:0x1
Step 3 – Conversion of the java byte code class into a binary file that
can be interpreted by the JCVM on the card – with the configuration file
from step 2, it is called in the command prompt, also from the directory
Wallet1, the following instruction:
%JC_HOME%\bin\converter.bat -config com\sun\javacard\samples\wallet\ Wallet.opt

If the conversion has ended without any error, then in the directory
(Wallet1\com\sun\javacard\samples\wallet) where there is the normal bytecode class
(Wallet.class) and the configuration file (wallet.opt) there will appear a new directory
that contains three files. The file with the extension CAP – Converted Applet – is the
binary form which will be understood by the card JCVM. The file with the extension JCA –
Java Card Assembly – is the text-assembler representation of the binery-compressed file
CAP that will be uploaded on the card. The file with the extension EXP – export –
differently from the CAP and like the JCA it is not uploaded on the card. EXP is used by
the conversion instrument (converter.bat) to also convert the necessary elements from
the classes or packages which are imported from the bytecode class (Wallet.class).
Step 4 – Verifying the CAP, JCA, EXP files – this is OPTIONAL. It is
separately executed for each of the EXP and CAP files, resulted in step 3, but
not before copying all the structure of EXP files including the directories from
the directory api_export_file of the distribution SJCDT [JCDT04], [JCDT04a]
into the directory Wallet1. Of course it is possible also generate from the
“assembler source code” – of the JCA file an equivalent CAP file with the
command
%JC_HOME%\bin\capgen.bat com\sun\javacard\samples\wallet\ javacard\wallet.jca

The commands for verifying the EXP and CAP files are:
o %JC_HOME%\bin\verifyexp.bat com\sun\javacard\samples\wallet\
javacard\wallet.exp
o %JC_HOME%\bin\verifycap.bat com\sun\javacard\samples\wallet\
javacard\wallet.exp %JC_HOME%\api_export_files\java\lang\
javacard\lang.exp %JC_HOME%\api_export_files\javacard\
framework\javacard\framework.exp
com\sun\javacard\samples\wallet\ javacard\wallet.cap
Step 5 – uploading the binary execution file into the permanent
memory of the card when this one is manufactured – it is EXCLUSIVE.
EXCLUSIVE means that whether it is executed step 5 and stop, or it is not
executed step 5 and we pass directly to 6. In the step 5, it is generated from
the JCA file (resulted in step 3) a masking-file that is uploaded in the non-
volatile memory of the card when this is manufactured and which will
disappear from the memory only after the physical destruction of the card.
The command (the file maskgen.bat is available only in some distributions
directly colaborating with the card producers but may also be downloaded
from the) for generating the masking file is:
%JC_HOME%\bin\maskgen.bat cref com\sun\javacard\samples\wallet\
javacard\wallet.jca
Step 6 – uploading the binary execution file in the volatile memory of
the card – it is executed only if step 5 was excluded. It is run the so-called
off-card installer. The first command is:
o %JC_HOME%\bin\scriptgen.bat -o Wallet.scr com\sun\javacard\
samples\wallet\javacard\wallet.cap
This command creates the script command file APDU – Wallet.scr with the help of the
binary file CAP (wallet.cap). The resulting file – Wallet.scr – must be adjusted and it
contains the APDU Commands necessary to upload the applet into the card memory. The
content of the file Wallet.scr will be briefly explained in this chapter. The adjustment is
made by the text editing of the file Wallet.scr. It is added the line ’powerup;’ at the
beginning of the file and ’powerdown;’ at the end of the file.
Then, in a new command prompt window it must be started the program which emulates
JCRE. There are two programs that can emulate a JCRE: one Java implemented
(jcwde.bat) and one C implemented (cref.exe). The one in C, called C-JCRE, is the most
important and in the same time it represents the refference implementation of JCRE.
This implementation is executed from the file cref.exe in the ’bin’ directory, from the
development kit distribution Java Card [JCDT04a]. So, in the new command prompt
window it is wrote the command:
o cref.exe –o eeprom1
The command is meant to save the EEPROM memory of the card, after it is modified it
by APDU commands. The command launches the JCRE emulation, and JCRE listens to
TCP/IP on the pre-defined port 9025, in order to receive APDU commands. The
emulation of JCRE stops when it receives a powerdown; by the APDU command script file
(extension scr).
Now in the old command prompt window it is run the command:
o %JC_HOME%\bin\apdutool.bat Wallet.scr > Wallet.scr.out
By this command, with the help of the program launched with cu apdutool.bat, it is
transmitted APDU commands from the host-type application to JCRE. For the moment
JCRE runs in a window and after the APDU commands received modifies the EEPROM
memory and the content is saved in the file eeprom1. The file Wallet.scr.out includes the
APDU Answers from the applet that runs over C-JCRE.
Step 7 – simulating the action between the host application and the
card applet by CAD – it is executed after step 6. At step 6, the JCRE
simulation has ended. Now it must be relaunched by the command:
o cref.exe –i eeprom1 –o eeprom1
The command takes on the memory image from the eeprom1 file, modifies it according
to the received APDU commands and saves it again with the modifications in the same
eeprom1 file. On the same JCRE port it simulates receiving APDU commands and by the
command
o %JC_HOME%\bin\apdutool.bat demoWallet.scr >
demoWallet.scr.cjcre.out
it is sent the APDU Commands for test and simulation of the applet, and the APDU
Answers are in the file demoWallet.scr.cjcre.out.
In order to completely understand the process, we should understand from step 6

the content of Wallet.scr and Wallet.scr.out, and from step 7 the content of
demoWallet.scr and demoWallet.scr.cjcre.out, i.e. to understand the user’s guide
[MANU03a] from the Java card kit. The content of demoWallet.scr and
demoWallet.scr.cjcre.out is presented in the annexes.
4.2 Interpretation of the code and results
As can be seen in the source code presented in the first annex, the applet has to import
the package javacard.framework.*, to extend the Applet class and to implement the
methods mentioned for the life cycle of an applet. In Table 1 is presented the draft of the
application:
Table 1. Source code for the application draft

package com.sun.javacard.samples.wallet;
import javacard.framework.*;
public class Wallet extends Applet {
...
//constructor
private Wallet (byte[] bArray,short bOffset,byte bLength) {...}
//Life-cycle methods – specifice fiecarui applet
public static void install(...) {...}
public void select() {...}
public void deselect() {...}
public void process(APDU apdu) {...}
//private methods – specifice doar acestui applet
private void credit(APDU apdu) {...}
private void debit(APDU apdu) {...}
private void getBalance(APDU apdu) {...}
private void verify(APDU apdu) {...}
...
}
When the source code is written, the developer should decide in what concerns the
structure of the APDU Commands and Answers. The structure of commands depends
mostly upon the service that the applet-application provides. For instance, if it is an
applet providing a service of electronic wallet, it should provide sub-services such as
debit or credit transactions for the amount of money on the card, verifying the balance
sheet of the card, assuring the security of the access to the applet by PIN. If it is about a
loyalty applet for a gym hall or about a medical insurance applet, then it should offer
services such as: personal identification information, access number in locations, and the
person legally reliable for the card owner, diseases.
Practically, for the Wallet-electronic wallet application, there are given several models of
APDU Commands designed by those who wrote the source code of the applet:
PIN verification
Java CLA INS P1 P2 Lc Data Field Le
private 1 1 1 1 1 5 bytes
method byte byte byte byte byte
verify() 0x80 0x20 0x00 0x00 0x05 0x01 0x02 0x03 0x04 0x05 0x02
CLA with the value 80 hex means that we intent to access the application electronic
wallet; INS with the value 20 hex means that it is desired to execute the method
verify(); P1 and P2 are not defined; Lc has the value 5 i.e. the Data Field field will have
5 octets; the Data Field field has octets and clearly contains the PIN 12345, although in
the real applications this should be encrypted; and Le has the value 2 that means that it
is expected maximum 2 octets as an answer;
Interrogation to find which amount of money the card contains

Java private CLA INS P1 P2 Lc Data Field Le
method 1 byte 1 byte 1 byte 1 byte 1 byte 5 bytes
getBalance() 0x80 0x50 0x00 0x00 0x00 Nothing 0x7F
The interpretation is the following: INS with the value 50 hex means that we intent to
execute the method getBalance(); P1 and P2 are not defined; Lc has the value 0 that
means that the field Data Field will not be defined; the field Data Field holds 0 octets;
and Le has the value 2 i.e. it is expected a maximum of 2 octets as an answer;
APDU command for debit – e.g. to deposit money on the card –

usually executed by a bank
Java private CLA INS P1 P2 Lc Data Le
method 1 byte 1 byte 1 byte 1 byte 1 byte Field
5 bytes
debit() 0x80 0x40 0x00 0x00 0x01 0x64 0x7F
The interpretation is the following: INS with the value 40 hex means that it is desired to
execute the method debit(); P1 and P2 are not defined; Lc has the value 1 i.e. the field
Data Field will have one octet; the field Data Field 1 octet and contains the value 100 in
decimals –means that the amount on the card should be increased with 100 monetary
units; and Le has the value 0x7F meaning that it is expected a maximum of 127 octets
as an answer;
It can be noticed in annex 1 that in the builder are allocated the objects needed for the
entire life cycle of the applet. Then the static method install() should directly or indirectly
call the static method register(), because JCRE, after installing the applet, this must at
his turn register into JCRE. In this case, the register method is indirectly call by the
builder by the install() method. Each time that JCRE receives an APDU command from
the host-type application, it will call the process() method. The source code in the annex
is readable and „self-explained” for a Java programmer – it self-explains by the
comments.
In annex 3 are presented the APDU commands sent by the host to JCRE and
immediately having the separator ’,’ follows the APDU answer. It considers the lines in
Table 2:
Table 2. Interpretation of APDU commands and answers from the log file in Annex 3.
CLA: 80, INS: 40, P1: 00, P2: 00, Lc: 01, 64, Le: 00, SW1: 6a, SW2: 85
CLA: 80, INS: 30, P1: 00, P2: 00, Lc: 01, 64, Le: 00, SW1: 90, SW2: 00
It is obvious that by the first command we intended the extraction from the card of 100
monetary coins units from the card – INS=0x40 intends the execution of the debit()
method and DataField=0x64 means 100 in decimal. The operation has been a failure
because of the octets as answer status (SW1=0x6Abut SW2=0x85). The value of the
answer is at the free choice of the developer when he throws the exception by the
sequence „if ((short)( balance - debitAmount ) < (short)0)
ISOException.throwIt(SW_NEGATIVE_BALANCE);” where SW_NEGATIVE_BALANCE has
the value 0x6A85 defined by the sequence „final static short SW_NEGATIVE_BALANCE =
0x6A85;” as in the source code in annex 1. This is the way we observe and interpret all
the results and the source code in the annexes of this presentation. The chosen example
is quite simple and does not use specific cryptography elements or atomic transactions
as normal for a practical application.
5. Conclusions
Before Java Cards appear, smart card software was depended on the manufactures.
Most smart card development kits were card and reader specific. Some have
externalized the card and reader descriptions so that the buyer of the kit can adapt the
software to new cards and readers. Also, most smart card systems had been closed
systems, consisting of a specific card from a card manufacturer working with a specific
terminal from a terminal manufacturer. Sometimes the same company manufactured
both the card and the reader. As a result, standard-specified, paper interoperability had
rarely proved. Now, the developers should no more be afraid about the diversity of
smart cards manufactures and operating systems, as long as they are using Java card
platform.
References
[CHEN00] Zhiqun Chen, „Java Card Technology for Smart Cards: Architecture and
Programmer's Guid”, Addison Wesley Publishing House, USA, June
2000.
[ENRI03a] C. Enrique Ortiz, May 2003, on-line article:
http://developers.sun.com/techtopics/mobility/javacard/articles/javacar
d1/
[ENRI03b] C. Enrique Ortiz, September 2003, on-line article:
http://developers.sun.com/techtopics/mobility/javacard/articles/javacar
d2/
[IVAN02] Ion Ivan, Paul Pocatilu, Marius Popa, Cristian Toma, “The Digital
Signature and Data Security in e-commerce”, The Economic Informatics
Review Nr. 3/2002, Bucharest 2002.
[JCDT04] Tools Sun Java Card Development Toolkit 2.2.1:
http://java.sun.com/products/javacard/index.jsp
[JCDT04a] Sun Java Card Development Toolkit 2.2.1:
http://java.sun.com/products/javacard/dev_kit.html
[ISOI04] http://www.ttfn.net/techno/smartcards/iso7816_4.html
[J2SE04] Java 2 Standard Edition Software Development Kit:
http://java.sun.com/products/archive/j2se/1.4.1_07/
[JCVM03] Virtual Machine Speification 2.2.1, Octomber 2003:
http://java.sun.com/products/javacard/specs.html
[JCRE03] Runtime Environment Specification 2.2.1, Octomber 2003
[JCAP03] Application Programming Specification 2.2.1, Octomber 2003:
[MANU03] Programming Manual, Octomber 2003, Application Progaming Notes
2.2.1 included in [JCDT04a]
[MANU03a] User Manual, Octomber 2003, Development Kit User Guide 2.2.1
included in [JCDT04a]
[POCA03] Paul Pocatilu, Cristian Toma, Mobile Applications Quality, International
Conference “Science and economic education system role in
development from Republic of Moldavia”, Chişinău, September 2003,
pg. 474-478
[SCTI98] Scott Guthery, Tim Jurgensen, „Smart Card Developer’s Kit”, Macmillan
Computer Publishing House, ISBN: 1578700272, USA 1998:
http://unix.be.eu.org/docs/smart-card-developer-kit/ewtoc.html
[TOMA05] Cristian TOMA, Secure Protocol in Identity Management using Smart
Cards, Revista “Informatica Economica”, vol. 9, Nr. 2, Bucuresti, 2005,
p. 135 – 140
[TOMA08] Cristian TOMA - Security in Software Distributed Platforms, AES
Publishing House, Bucharest, 2008, ISBN 978-606-505-125-6.
ANNEX 1: Source code of electronic wallet applet for Java Card platform
package com.sun.javacard.samples.wallet;
import javacard.framework.*;
//import javacardx.framework.*;
public class Wallet extends Applet {
/* constants declaration */
// code of CLA byte in the command APDU header
final static byte Wallet_CLA = (byte) 0x80;
// codes of INS byte in the command APDU header
final static byte VERIFY = (byte) 0x20;
final static byte CREDIT = (byte) 0x30;
final static byte DEBIT = (byte) 0x40;
final static byte GET_BALANCE = (byte) 0x50;
// maximum balance
final static short MAX_BALANCE = 0x7FFF;
// maximum transaction amount
final static byte MAX_TRANSACTION_AMOUNT = 127;
// maximum number of incorrect tries before the PIN is blocked
final static byte PIN_TRY_LIMIT = (byte) 0x03;
// maximum size PIN
final static byte MAX_PIN_SIZE = (byte) 0x08;
// signal that the PIN verification failed
final static short SW_VERIFICATION_FAILED = 0x6300;
// signal the the PIN validation is required
// for a credit or a debit transaction
final static short SW_PIN_VERIFICATION_REQUIRED = 0x6301;
// signal invalid transaction amount
// amount > MAX_TRANSACTION_AMOUNT or amount < 0
final static short SW_INVALID_TRANSACTION_AMOUNT = 0x6A83;
// signal that the balance exceed the maximum
final static short SW_EXCEED_MAXIMUM_BALANCE = 0x6A84;
// signal the the balance becomes negative
final static short SW_NEGATIVE_BALANCE = 0x6A85;
/* instance variables declaration */
OwnerPIN pin;
short balance;
private Wallet (byte[] bArray,short bOffset,byte bLength){

// It is good programming practice to allocate
// all the memory that an applet needs during
// its lifetime inside the constructor
pin = new OwnerPIN(PIN_TRY_LIMIT, MAX_PIN_SIZE);
byte iLen = bArray[bOffset]; // aid length
bOffset = (short) (bOffset+iLen+1);
byte cLen = bArray[bOffset]; // info length
bOffset = (short) (bOffset+cLen+1);
byte aLen = bArray[bOffset]; // applet data length
// The installation parameters contain the PIN initialization value
pin.update(bArray, (short)(bOffset+1), aLen);
register();
} // end of the constructor
public static void install(byte[] bArray, short bOffset, byte bLength){

// create a Wallet applet instance
new Wallet(bArray, bOffset, bLength);
} // end of install method
public boolean select() {

// The applet declines to be selected if the pin is blocked.
if ( pin.getTriesRemaining() == 0 ) return false;
return true;
}// end of select method
public void deselect() {

// reset the pin value
pin.reset();
}
public void process(APDU apdu) {

// APDU object carries a byte array (buffer) to
// transfer incoming and outgoing APDU header
// and data bytes between card and CAD
// At this point, only the first header bytes

// [CLA, INS, P1, P2, P3] are available in
// the APDU buffer.
// The interface javacard.framework.ISO7816
// declares constants to denote the offset of
// these bytes in the APDU buffer
byte[] buffer = apdu.getBuffer();
// check SELECT APDU command
buffer[ISO7816.OFFSET_CLA]=(byte)(buffer[ISO7816.OFFSET_CLA]&(byte)0xFC);
if((buffer[ISO7816.OFFSET_CLA]==0)&&
(buffer[ISO7816.OFFSET_INS]==(byte)(0xA4))) return;
// verify the reset of commands have the
// correct CLA byte, which specifies the command structure
if (buffer[ISO7816.OFFSET_CLA] != Wallet_CLA)
ISOException.throwIt(ISO7816.SW_CLA_NOT_SUPPORTED);
switch (buffer[ISO7816.OFFSET_INS]) {
case GET_BALANCE: getBalance(apdu); return;
case DEBIT: debit(apdu); return;
case CREDIT: credit(apdu); return;
case VERIFY: verify(apdu); return;
default: ISOException.throwIt(ISO7816.SW_INS_NOT_SUPPORTED);
}
} // end of process method
private void credit(APDU apdu) {

// access authentication
if (! pin.isValidated())ISOException.throwIt(SW_PIN_VERIFICATION_REQUIRED);
// Lc byte denotes the number of bytes in the
// data field of the command APDU
byte numBytes = buffer[ISO7816.OFFSET_LC];
// indicate that this APDU has incoming data and receive data starting // from the offset
ISO7816.OFFSET_CDATA following the 5 header bytes.
byte byteRead = (byte)(apdu.setIncomingAndReceive());
// it is an error if the number of data bytes

// read does not match the number in Lc byte
if (( numBytes != 1 ) || (byteRead != 1))
ISOException.throwIt(ISO7816.SW_WRONG_LENGTH);
// get the credit amount

byte creditAmount = buffer[ISO7816.OFFSET_CDATA];
// check the credit amount

if (( creditAmount > MAX_TRANSACTION_AMOUNT) || ( creditAmount < 0 ))
ISOException.throwIt(SW_INVALID_TRANSACTION_AMOUNT);
// check the new balance

if ((short)(balance + creditAmount) > MAX_BALANCE)
ISOException.throwIt(SW_EXCEED_MAXIMUM_BALANCE);
// credit the amount
balance = (short)(balance + creditAmount);
} // end of deposit method
private void debit(APDU apdu) {

// access authentication
if (!pin.isValidated())
ISOException.throwIt(SW_PIN_VERIFICATION_REQUIRED);
byte numBytes = (byte)(buffer[ISO7816.OFFSET_LC]);
if (( numBytes != 1 ) || (byteRead != 1))
ISOException.throwIt(ISO7816.SW_WRONG_LENGTH);
// get debit amount
byte debitAmount = buffer[ISO7816.OFFSET_CDATA];
// check debit amount
if ((debitAmount > MAX_TRANSACTION_AMOUNT)|| ( debitAmount < 0 ))
ISOException.throwIt(SW_INVALID_TRANSACTION_AMOUNT);
// check the new balance
if ((short)( balance - debitAmount ) < (short)0)
ISOException.throwIt(SW_NEGATIVE_BALANCE);
balance = (short) (balance - debitAmount);
} // end of debit method
private void getBalance(APDU apdu) {

// inform system that the applet has finished
// processing the command and the system should
// now prepare to construct a response APDU
// which contains data field
short le = apdu.setOutgoing();
if (le < 2) ISOException.throwIt(ISO7816.SW_WRONG_LENGTH);

//informs the CAD the actual number of bytes returned
apdu.setOutgoingLength((byte)2);
// move the balance data into the APDU buffer starting at the offset 0
buffer[0] = (byte)(balance >> 8);
buffer[1] = (byte)(balance & 0xFF);
// send the 2-byte balance at the offset 0 in the apdu buffer

apdu.sendBytes((short)0, (short)2);
} // end of getBalance method
private void verify(APDU apdu) {
// retrieve the PIN data for validation.
// check pin, the PIN data is read into the APDU buffer
// at the offset ISO7816.OFFSET_CDATA, the PIN data length = byteRead
if (pin.check(buffer, ISO7816.OFFSET_CDATA, byteRead) == false)
ISOException.throwIt(SW_VERIFICATION_FAILED);
} // end of verify method

} // end of class Wallet
ANNEX 2: APDU commands and expected responses from the test-simulation file
demoWallet1.scr
/////////////////////////////////////////////////////////////////////
// Select all installed Applets
/////////////////////////////////////////////////////////////////////
powerup;
// Select the installer applet

0x00 0xA4 0x04 0x00 0x09 0xa0 0x00 0x00 0x00 0x62 0x03 0x01 0x08 0x01 0x7F;
// 90 00 = SW_NO_ERROR
// create wallet applet

0x80 0xB8 0x00 0x00 0x14 0x0a 0xa0 0x0 0x0 0x0 0x62 0x3 0x1 0xc 0x6 0x1 0x08 0 0
0x05 0x01 0x02 0x03 0x04 0x05 0x7F;
/////////////////////////////////////////////////////////////////////
// Initialize Wallet
/////////////////////////////////////////////////////////////////////
//Select Wallet
0x00 0xA4 0x04 0x00 0x0a 0xa0 0x0 0x0 0x0 0x62 0x3 0x1 0xc 0x6 0x1 0x7F;
//Verify user pin

0x80 0x20 0x00 0x00 0x05 0x01 0x02 0x03 0x04 0x05 0x7F;
//90 00 = SW_NO_ERROR
//Get wallet balance

0x80 0x50 0x00 0x00 0x00 0x02;
//0x00 0x00 0x00 0x00 0x90 0x00 = Balance = 0 and SW_ON_ERROR
//Attemp to debit from an empty account

0x80 0x40 0x00 0x00 0x01 0x64 0x7F;
//0x6A85 = SW_NEGATIVE_BALANCE
//Credit $100 to the empty account

0x80 0x30 0x00 0x00 0x01 0x64 0x7F;
//0x9000 = SW_NO_ERROR
//Get Balance
0x80 0x50 0x00 0x00 0x00 0x02;
//0x00 0x64 0x9000 = Balance = 100 and SW_NO_ERROR
//Debit $50 from the account

0x80 0x40 0x00 0x00 0x01 0x32 0x7F;
//Get Balance
0x80 0x50 0x00 0x00 0x00 0x02;
//Credit $128 to the account

0x80 0x30 0x00 0x00 0x01 0x80 0x7F;
//0x6A83 = SW_INVALID_TRANSACTION_AMOUNT
//Get Balance
0x80 0x50 0x00 0x00 0x00 0x02;

0x80 0x40 0x00 0x00 0x01 0x33 0x7F;
//0x6A85 = SW_NEGATIVE_BALANC
//Get Balance
0x80 0x50 0x00 0x00 0x00 0x02;

0x80 0x40 0x00 0x00 0x01 0x80 0x7F;
//0x6A83 = SW_INVALID_TRANSACTION_AMOUNT
//Get Balance
0x80 0x50 0x00 0x00 0x00 0x02;
//Reselect Wallet applet so that userpin is reset

0x00 0xA4 0x04 0x00 0x0a 0xa0 0x0 0x0 0x0 0x62 0x3 0x1 0xc 0x6 0x1 0x7F;
//Credit $127 to the account before pin verification

0x80 0x30 0x00 0x00 0x01 0x7F 0x7F;
//0x6301 = SW_PIN_VERIFICATION_REQUIRED
//Verify User pin with wrong pin value

0x80 0x20 0x00 0x00 0x04 0x01 0x03 0x02 0x66 0x7F;
//0x6300 = SW_VERIFICATION_FAILED
//Verify user pin again with correct pin value

//0x80 0x20 0x00 0x00 0x08 0xF2 0x34 0x12 0x34 0x56 0x10 0x01 0x01 0x7F;
0x80 0x20 0x00 0x00 0x05 0x01 0x02 0x03 0x04 0x05 0x7F;
//Get balance with incorrrect LE value

0x80 0x50 0x00 0x00 0x00 0x01;
//0x6700 = ISO7816.SW_WRONG_LENGTH
//Get balance
0x80 0x50 0x00 0x00 0x00 0x02;
// *** SCRIPT END ***

powerdown;
ANNEX 3: Received APDU responses from the C-JCRE when this was asked with APDU
commands – file demoWallet1.scr.cjcre.out
Java Card 2.2.1 APDU Tool, Version 1.3

Copyright 2003 Sun Microsystems, Inc. All rights reserved. Use is subject to license
terms.
Opening connection to localhost on port 9025.
Connected.
Received ATR = 0x3b 0xf0 0x11 0x00 0xff 0x00
CLA: 00, INS: a4, P1: 04, P2: 00, Lc: 09, a0, 00, 00, 00, 62, 03, 01, 08, 01, Le: 00,
SW1: 90, SW2: 00
CLA: 80, INS: b8, P1: 00, P2: 00, Lc: 14, 0a, a0, 00, 00, 00, 62, 03, 01, 0c, 06, 01, 08,
00, 00, 05, 01, 02, 03, 04, 05, Le: 0a, a0, 00, 00, 00, 62, 03, 01, 0c, 06, 01, SW1: 90,
SW2: 00
CLA: 00, INS: a4, P1: 04, P2: 00, Lc: 0a, a0, 00, 00, 00, 62, 03, 01, 0c, 06, 01, Le: 00,
SW1: 90, SW2: 00
CLA: 80, INS: 20, P1: 00, P2: 00, Lc: 05, 01, 02, 03, 04, 05, Le: 00, SW1: 90, SW2: 00
CLA: 80, INS: 50, P1: 00, P2: 00, Lc: 00, Le: 02, 00, 00, SW1: 90, SW2: 00
CLA: 00, INS: a4, P1: 04, P2: 00, Lc: 0a, a0, 00, 00, 00, 62, 03, 01, 0c, 06, 01, Le: 00,
SW1: 90, SW2: 00
CLA: 80, INS: 30, P1: 00, P2: 00, Lc: 01, 7f, Le: 00, SW1: 63, SW2: 01
CLA: 80, INS: 20, P1: 00, P2: 00, Lc: 04, 01, 03, 02, 66, Le: 00, SW1: 63, SW2: 00
CLA: 80, INS: 20, P1: 00, P2: 00, Lc: 05, 01, 02, 03, 04, 05, Le: 00, SW1: 90, SW2: 00
CLA: 80, INS: 50, P1: 00, P2: 00, Lc: 00, Le: 00, SW1: 67, SW2: 00
Secure Mechanisms for E-Ticketing System
Cristian TOMA
cristian.toma@ie.ase.ro
Abstract: The paper presents a secure authentication and encryption scheme for an automatic ticketing system
based on symmetric and asymmetric cryptography. Some concepts and terms used in development of secure
automatic ticketing system are presented. It is depicted an architecture of the secure automatic ticketing system
with its components and their roles in this architecture. The section five presents the authentication and
encryption scheme used for secure information from RFID cards. The authentication scheme is based on RSA
and AES algorithms and it is inspired from SSL. Parts of this paper are in publishing process in [6], but the
authentication and encryption scheme is described exclusivelly in this paper. The necessity of authentication and
encryption scheme is given by the attack described in [7].
Key-Words: ticketing system, secure distributed system, RFID cards, cryptographic authentication and
encryption
1. Introduction
This section presents concepts that are used in the designed solution for Secure
Automatic Ticketing System – SATS. SATS has several major objectives:
to implement the secure use of the electronic cards and tags instead of paper
tickets in any kind of information integrated system;
to supervise the actions and the behavior of the subscribers within the ticketing
system in order to prevent the frauds and to increase the subscribers and the
clients satisfaction;
to improve the management of the company providing complete and proper
information about the components of the system;
to improve the commercial offers to the subscribers and to the clients;
to improve the quality of commercial services.
SATS operates with various new terms as it follows:

Charging – the action of the registering and paying a service in advance at a
Point of Sale – POS; for backward compatibility with the old ticketing systems,
the SATS accepts the acquisition of paper tickets; for instance, in a public
transportation system, the client buys 20 Euros credit and the amount is stored in
E-Pocket from the E-Card; the client is free to use the amount whenever and
wherever the one wants; he/she can pay the journey with the bus number 300,
from the station A to B (1 Euro), and the next day, he/she can pay another
journey with bus 301, from station C to D (2 Euros); after these actions the client
would still have 17 Euros credit in the E-Pocket;
Client – person who is gone to use the services provided by the system which
choose to implement SATS as ticketing system; a client can be pre-pay (make a
charging), post-pay (make a subscription) or both (he/she is also a pre-pay and a
post-pay client);
E-Card – the integrated circuits contactless card, memory chip card – Mifare,
which is used as base for actions such as subscription and charging; it replaces
the paper ticket use in the current ticketing systems;
E-Personal-Area – it is a memory area in the E-Card where the information about
the client is stored, such as ID Number, Social Security Number, Personal
Number Identification, first and last name and so forth;
E-Pocket – it is a memory area in the E-Card where the money of the client is
stored; the E-Card includes the E-Pocket;
E-Subscription – it is a memory area in the E-Card where the information about
the subscription is stored; the E-Card includes the E-Pocket;
E-Validation Device – it is combo equipment, hardware and software, which has
usually an operating system (Windows CE), a LCD colour touch screen, a contact-
less reader, an incorporated printer, green and red light with sound warnings for
validation/invalidation and a Secure Application Module – SAM;
Pre-pay Client – a client who chooses to make a subscription at a POS;
Post-pay Client – a client who chooses to make a charging at a POS;
Point of Sale POS – a location where a client can make a subscription or a
charging;
Personalization – the process of printing on the card the picture of the client’s
face and various identification items; the personalization process usually take
place into a POS with the personalization;
Subscription – the action of the registering and entering into a medium/long term
billing arrangement for a service in a certain period of time; for instance, in a
public transportation system, the client buys access for travelling with the buss
number 300 between 15 May and 16 June this year.
SATS is inspired as terminology from the mobile applications environment and is

designed for contactless integrated circuits cards with memory chip – Mifare.
2. Concepts of the Secure Automatic Ticketing System
The SATS handles pre-pay, post-pay and both types’ clients. Also, SATS has the
availability to works with e-Cards as well as with paper tickets. The clients who buy
paper tickets are considered pre-pay clients.
For a better view about of the types of the clients it is recommended to see the
definitions from first chapter of this paper and figure 1. In figure 1, the clients’ types of
SATS are presented:
<<must have>>
E-Subscription
Post-pay Clients From
E-Card
E-Pocket
<<should have>> From
E-Card
<<can be>>
Clients Pre-pay Clients
Old Paper
<<could have>> Ticket
E-Subscription
<<must have>> From
E-Card
E-Pocket
Pre and Post-pay <should have> From
Clients E-Card
Old Paper
Ticket
<<could have>>
Fig.1 SATS Clients types
The ideal case all the SATS clients are not using old paper ticket. In order to validate the
E-Subscription or E-Pocket, SATS uses E-Validation devices.
The SATS implements only one rating method for E-Subscription (post-pay clients). The
rating method is based on checking the E-Subscription against the E-Validation Device.
The SATS implements two rating methods for E-Pocket (pre-pay clients):
Fixed rate – the rate for each access to the service will be the same; for instance,
in a public transportation system, the client is paying only a fixed amount no
matter the station he/she is going to get in or out;
Variable rate – the client is paying differentiated by the achieved service level; for
instance, in a public transportation system, the client is paying a variable amount
of money, depending the bus line and the area of the journey.
The priority of the E-Validation device for checking an E-Card is first to checkout if it is
an E-Subscription area. After that, it checks the existence of the E-Pocket area.
The E-Pocket allows various services such as:

The payment for any journey payment in a public transportation system;
The payment for more than one client journey from a single card;
The payment of other scalable systems such as:
o Parking tickets;
o Zoo, Cinema, Museums tickets;
o Loyalty cards for the gym access;
The support for clearing activities via a Clearing Authority.
The E-Card could be use also by other persons involved in a SATS. For example, in a
public transportation system, E-Cards could be used also by the following categories of
personnel:
The clients: pre-pay, post-pay or both;
The drivers: for authentication purposes and for working hours checking;
The inspectors from the bus lines;
The operators from the POS.
The suggested solution for E-Card is Philips Mifare memory card detailed in the below
section.
3. NXP Philips Mifare Memory Cards
The MIFARE Classic card is fundamentally just a memory storage device, where the
memory is divided into segments and blocks with simple security mechanisms for access
control. They are suitable for: Public transportation; Access control; Event ticketing;
Gaming and Identity. Figure 2 shows how the contact-less cards transfer data with the
reader using Radio Frequency and in the same time they are charging with electrical
power in order to perform various computing actions.
Fig.2 Mifare Card Communications [1]
The Philips Mifare card structure is shown in figure 3. As functional modules the Mifare
cards have an RF Interface which is able to handle with RF – Radio Frequency – ISO/IEC
14443 specifications.
There is an Anti-collision module which is responsible with interacting with one reader
but with more than one Mifare cards in the proximity area. Authentication module helps
the developer to establish a set of keys for enabling only the applications that “knows”
the key to be able to read/write data in EEPROM through EEPROM interface.
There is also Crypto module which is encrypting the data before going through RF
interface.
Because recently the Mifare encryption of data from the card to the reader has been
broken it is recommended to encrypt the data in computer application and to store the
encrypted data into the memory card.
Fig.3 Mifare Card Structure [1]
The authentication and card access procedure is presented in figure 4:
Fig.4 Card Access and Authentication Procedure [1]
The security is achieved through three mechanisms:

Mutual three pass authentication (ISO/IEC DIS 9798-2) – after selection of a card,
the reader specifies the memory location of the following memory access and uses
the corresponding key for the three pass authentication procedure; after a successful
authentication all memory operations are encrypted;
Individual set of two keys per sector (per application) to support multi-application
with key hierarchy;
Unique serial number for each device.
It is recommended to encrypt the content of data in Mifare cards because the three
mechanisms could have some issues regarding data security.
The mechanism how is ensured data integrity, three pass authentication sequence and
memory operations are more intelligible after the memory organization is presented in
figure 5.
The Philips Mifare Cards 1K have 1024 bytes of EEPROM memory. The 1024 x 8 bit
EEPROM memory is organized in 16 sectors with 4 blocks of 16 bytes each. In the erased
state the EEPROM cells are read as a logical “0”, in the written state as a logical “1”. In
the memory blocks cannot be read/written a value as long as the authentication process
is not successful.
Fig.5 Memory Chip Pattern [1]
The first data block (block 0) of the first sector (sector 0) from figure 5 is “Manufacturer
block”. The “Manufacturer block” is presented in figure 6.
Fig.6 Manufacturer block [1]
The “manufacturer block” has 16 bytes (128 bits) and it contains the IC manufacturer
data: Unique Serial Number 4 bytes, Check Byte and Manufacturer Data. Because of the
security and system requirements, this block can be only read after having been
programmed by the ICC – Integrated Circuits Card manufacturer at production. After the
“Manufacturer Block” there are “Data Blocks” or “Trailer Blocks” organized in sectors.
All the sectors, not including the first one, have (4 blocks * 16 bytes):
3 “data blocks”
1 “trailer blocks”.
The “data block” can be can be configured by the access bits from the sector trailer
block:
to store/read binary data blocks (e.g. binary representation of ASCII data);
value blocks (e.g. electronic purse applications), where there are additional
commands like increment and decrement for direct control of the stored value.
An authentication command has to be submitted by the reader before any memory

operation in order to allow further commands. A value block is represented in figure 7:
Fig.7 Value block [1]
The value blocks allow performing minimal mathematic functions as increment or

decrement. The valid commands for value block are: read, write, increment, decrement,
restore, transfer. A value block can only be generated through a write operation in the
value block respecting the format from figure 8:
Value – it is a signed 4-byte value; the lowest significant byte of a value is stored
in the lowest address byte;
Negative values are stored in standard 2´s complement format; for reasons of
data integrity and security, a value is stored three times, twice non-inverted and
once inverted;
Adr – it is a 1-byte address, which can be used to save the storage address of a
block, when implementing a powerful backup management; the address byte is
stored four times, twice inverted and non-inverted; during increment, decrement,
restore and transfer operations the address remains unchanged; it can only be
altered via a write command.
For instance, if a program writes the value 5 in the value block, then the value block will
have the following hex values (little endian bytes order and big endian bits order):
0x05 0x00 0x00 0x00|0xFA 0xFF 0xFF 0xFF|0x05 0x00 0x00 0x00|00FF00FF
The sector “trailer block” is presented in figure 8:
Fig.8 Sector trailer block [1]
Each sector has a sector trailer containing the:

Secret keys A and B (B is optional), which return logical “0”s when read;
The access conditions for the four blocks of that sector, which are stored in bytes
6...9.
The access bits also specify the type (read/write or value) of the data blocks. If key B is
not needed, the last 6 bytes of block 3 can be used as data bytes. Byte 9 of the sector
trailer is available for user data. For this byte apply the same access rights as for byte 6,
7 and 8.
The access conditions for every data block and sector trailer are defined by 3 bits, which
are stored non-inverted and inverted in the sector trailer of the specified sector figure 9
and 10. The access bits manage the rights of the memory access using the secret keys A
and B. The access conditions may be modified but with each memory access the internal
logic verifies the format of the access conditions.
Fig. 9 Access Bits [1]
If it detects a format violation the whole sector is blocked irreversible. In the description
from figure 9, the access bits are mentioned in the non-inverted mode only. The internal
logic of the Mifare ICC ensures that the commands are executed only after an
authentication procedure or never.
The figure 10 specifies the access bits conditions for data blocks in value mode (C1i, C2i,
C3i where i = 0,1,2).
Fig.10 Access Bits combination for value block access [1]
Depending on the access bits for data blocks (blocks 0...2) the read/write access is
specified as ‘never’, ‘key A’, ‘key B’ or ‘key A|B’ (key A or key B). The setting of the
relevant access bits defines the application and the corresponding applicable commands
as it follows:
Read/write block – the operations read and write are allowed;
Value block – allows the additional value operations increment, decrement,
transfer and restore; in one case (‘001’) only read and decrement are possible for
a non-rechargeable card; in the other case (‘110’) recharging is possible by using
key B;
Manufacturer block – the read-only condition is not affected by the access bits
setting;
Key management – in transport configuration key A must be used for
authentication.
Figure 11 specifies the access bits conditions for trailer blocks (C13, C23, C33).
Fig.11 Access Bits combinations for Key Access [1]
Depending on the access bits for the sector trailer (block 3 from each sector) the
read/write access to the keys and the access bits is specified as ‘never’, ‘key A’, ‘key B’
or key A|B’ (key A or key B).
For instance, if after personalization the Mifare 1k card will be used for writing and
reading mode, the values for access bits it will be:
C13, C23, C33 - trailer block -> 1 0 0 Byte6 = 0xFF = 1111 1111
C12, C22, C32 - data block -> 1 1 0 Byte7 = 0x07 = 0000 0111
=>
So the sector trailer which have KeyA = 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF and keyB =
0x00 0x00 0x00 0x00 0x00 0x00 (default from manufacture) it will have the following
structure:
FF FF FF FF FF FF | FF 07 80 00 | 00 00 00 00 00 00
The three pass authentication sequence takes place whenever the reader wants to store
or read data from a specific block. The authentication procedure:
1. The reader specifies the sector to be accessed and chooses key A or B;
2. The card reads the secret key and the access conditions from the sector trailer; then
the card sends a random number as the challenge to the reader (pass one);
3. The reader calculates the response using the secret key and additional input; the
response, together with a random challenge from the reader, is then transmitted to
the card (pass two);
4. The card verifies the response of the reader by comparing it with its own challenge
and then it calculates the response to the challenge and transmits it (pass three);
5. The reader verifies the response of the card by comparing it to its own challenge;
after transmission of the first random challenge the communication between card and
reader is encrypted.
Figure 12 shows the memory access for various sectors and the three pass
authentication procedure place for reading/writing data blocks in value or binary mode.
After the three pass authentication procedure, any of the following operations may be
performed: reading/writing binary blocks; decrementing the contents of a block and
stores the result in a temporary internal data-register; incrementing the contents of a
block and stores the result in the data-register; restoring the contents of a block into the
data-register or transferring the contents of the temporary internal data-register to a
value block.
Fig.12 Memory Access [1]
The following mechanisms are implemented in the contact-less communication link

between reader and card in order to ensure data integrity in RF transmission:
16 bits CRC per block;
Parity bits for each byte;
Bit count checking;
Bit coding to distinguish between "1", "0", and no information;
Channel monitoring (protocol sequence and bit stream analysis);
The Philips Mifare cards are very good for storing sensitive data but in encrypted mode
because there are mechanism how to break Mifare data security over RF communication.
These types of cards are considered ICC cards and are not used as 100% smart cards
because they do not provide API for any kind of processing except
incrementing/decrementing values. They are very strong linked with the data structures
used by the host application.
4. SATS Architecture and Data Structures
The overview architecture is presented in figure 13. The components are described in
following sections.
Fig.13 The overview of the SATS [4]
The architecture of SATS has three layers. Each layer is responsible for certain functions
and in each layer location the E-Card has a status in terms of life-cycle:
A. Back-end layer – it is responsible with business logic of SATS; it contains the
following elements:
Back Office Headquarter (location 1) – it receives the ordered cards from the
supplier, and it provides the cards to the Back Office E-Cards Formatting and
Branding; it contains the following components:
o SATS Server – runs applications which are receiving data from the middleware
and from the Front-end applications via Web Server; it has some enterprise
software components for increasing the distributed processing and scalability of
the SATS;
o Key Management Server – is used for generating access key for E-Cards, X509
certificates and for storing the keys; it could be assimilated with a Certificate and
Registration Authority;
o Web Server – contains the web applications and web services; most of the
applications from Front-End are web based or they access web services;
o Database Server – contains the database of the clients (pre-pay, post-pay or
both), the validation device data and other kind of involved personnel data;
Back Office E-Cards Formatting and Branding (location 2) – it receives the blank
cards from the Back Office Headquarter and it formats the cards with special keys for
access; a formatted E-Card may be branded with the commercial signs required by
the SATS beneficiary; location 2 has the following components:
o Apps for E-Cards Formatting and Branding Server – runs applications which are
able to handle to format and brand the E-Cards;
o Card Reader/Writer for E-Card formatting – is initializing the E-Cards with the
access keys;
o Card Printer for E-Card branding – prints on both faces of the plastic over E-Card
various commercial signs or advertising.
B. Front-end layer – it is responsible about the interface with the clients; it has the
following components:
Sales Front-end (location B.1) – the place where the E-Cards are sold to the client;
location contains:
o POS with Personalization (location 3.1) – it receives the formatted and/or
branded cards in order to be personalized with the proper data structures and
eventually with the client picture and identification number;
o POS without Personalization (location 3.2) – it receives the formatted and/or
branded cards in order to be personalized with the proper data structures;
o Validation Front-end (location B.2) – is the place where the E-Cards are validated
before the client to get access to the services or system’s resources; it contains
Services Access Validation Area (location 5) that includes the E-Validation devices
which are decrementing or checking out the access rights of the clients;
C. Middleware layer – it is responsible with secure communication between Front-End
and Back-End.
The security is ensured on the most important layers in TCP/IP stack:
Application layer through Key Management Server and through encryption of data
structure used for validation purposes by E-Card and E-Validation devices; E-
Validation devices have also a Secure Application Module – SAM which is a smart
card and it used for generating the session keys and the digital signatures.
Transport layer through Secure Socket Layer – SSL with implications at application
layer of using Hyper Text Transfer Protocol Secure - HTTPS for the web services
access from POS locations;
Internetworking layer through using Internet Protocol Secure – IPSec and Virtual
Private Network – VPN in order to minimize the risks of eaves dropping and to
support data integrity and confidentiality.
The security policies are implemented at firewall level for each location in order to filter
all network packets and to accept only the proper network packets.
In right side of the figure 13 are the card’s status in various locations. The architecture
from figure 13 is generic and could be implemented in any kind of information system
based on access cards (E-Cards). There are particularities for each system and therefore
it is recommended to analyze very well the specific area of beneficiary system in order to
achieve the best results.
The personal, charging, wallet, subscription and last usage data is in ASN.1 and stored
encrypted information of ASN.1 DER. The choice of ASN.1 DER is made because of
memory limitations of the RFID cards and the overload of information using XML for data
structuring is too big.
The process of validation the information from the card consits of few steps:
The CAD – reader/validator reads the RSA encrypted session key;
Only the validator has the company’s RSA private key stored into a SAM – Secure
Access Module; Therefore only the validator is able to obtain the session key in
clear;
The session key decrypts critical information for validation process such as wallet
and subscription;
The validator checks out the information and grand or not the clients’ access.
A sample of ASN.1 of the personal and wallet data structure is:
PersonalData ::= SEQUENCE {
ID_Citizen OCTET STRING,
First_Name OCTET STRING,
Last_Name OCTET STRING,
Address OCTET STRING,
Occupation OCTET STRING
}
WalletData ::= SEQUENCE OF {

Credit OCTET STRING, -- 32 bits float
Currency IA5String -- 3 UTF-16 chars
--in little endian=6 bytes
}
The brute force attack of RFID Mifare cards is almost impossible because of its
authentication process with keys lengh of 6 bytes, 48 bits. But, the authentication and
encryption algorithm is used at application level because the MIFARE communication
protocol between the reader and RFID cards has been broken. The attack is described in
[7].
5. Conclusions
The security issue of a secure automatic ticketing system is a very important one
because the payments in such systems must be safe and the client must safely keep its
money and personal data in the system.
The security of the suggested architecture is assured on different levels: application

(session keys, the digital signatures), transport (SSL, HTTPS) and internetworking
(IPSec). The security policies are implemented at firewall level for each location to
accept only the proper network packets.
References
[1]
http://www.nxp.com/acrobat_download/other/identification/M001053_MF1ICS50_rev5_
3.pdf
[2] W. Stallings, Cryptography and Network Security, 3/E, Prentice Hall, 2003
[3] D. Stinson, Cryptography – Theory and Practice, 2nd Edition, Chapman & Hall/Crc
Publishing House, New York, 2002
[4] C. Toma, Security in Software Distributed Platforms, ASE Publishing House,

Bucharest, 2008
[5] C. Toma, C. Boja, M. Popa, Solution for Non-Repudiation in GSM WAP Applications,
The 7th WSEAS International Conference on SOFTWARE ENGINEERING, PARALLEL and
DISTRIBUTED SYSTEMS (SEPADS '08), Advances on Software Engineering, Parallel and
Distributed Systems, University of Cambridge, UK, February 20-22, 2008, pp. 212 – 219
[6] M. Popa, C. Toma, Secure Automatic Ticketing System, WSEAS International
Conference on DATA, NETWORKS, COMMUNICATIONS, COMPUTERS (DNCOCO '09),
Baltimore, USA, November 7-9, 2009.
[7] Gerhard de Koning Gans, Jaap-Henk Hoepman, and Flavio D. Garcia, A Practical
Attack on the MIFARE Classic.
Secure Smart-card Technologies used in e-Commerce
Catalin BOJA
catalin.boja@ie.ase.ro
Abstract: Most of the systems require a high level of security. From the point of view of security, the smart card
technologies are very important, because the same card could be use to access a network resource or to crypt
and sign an electronic confidential message. In this paper, are highlighted the diversity of smart cards’ software
development kits and operating systems. In the last part is presented a new technology that is used for
developing applications which run on smart-cards. Also are highlighted some security patterns which can be used
in such information systems that involves mobile applications and smart cards.
Key-Words: e-commerce, e-payment, smart cards, SET.
1. Introduction
In our days most of the specialists agree on the idea, that a card is smart only if it can
compute, only if it has a microprocessor or a microcontroller. Keeping on this approach,
the difference between a smart card and a card only with memory chips or magnetic
strips, is that the last one only can store data and can not compute the data.
The term E-Business and E-Commerce have many definitions in IT fields. One of
definition is that the E-Business is the integration of a company's business including
products, procedures, and services over the Internet [ANIT00]. Usually and in practice a
company turns its business into an E-Business when it integrates the marketing, sales,
accounting, manufacturing, and operations with web site activities. An E-Business uses
the Internet as a resource for all business activities.
Also for this paper the concern is security pattern used in E-Commerce and E-
Government. We can understand E-Commerce as a component, a part of an E-
Business.
The term of Electronic commerce or "E-Commerce" is related with a wide variety of on-
line business activities for products and services, of different type business-to-business –
B2B and business-to-consumer – B2B, through the Internet or even through IntraNets –
private networks, including mobile ones.
After the opinions of different specialist, eCommerce is divided in two components:

Online Shopping - the activities that provide to the customer or to the
business partner the information about products or services traded. This
information helps them to be informed and to take the proper decision
regarding the buying process.
Online Purchasing - “E-Payment” - the activities through a customer or a
company actually purchase a product or a service over the Internet or private
networks. Also another type of using for on-line purchasing is described in
[Anne00] like “a metaphor used in business-to-business eCommerce for
providing customers with an online method of placing an order, submitting a
purchase order, or requesting a quote”.
Regarding E-Government are almost clear. Some of the specialists agree that “the
application of e-business technologies and strategies to government organizations”
represents E-Government. Another specialists consider that “the transformation of
internal and external business processes toward customer-centricity based upon service
delivery opportunities offered by new communication technologies (such as web-based
technologies) to better fulfill the purposes of government to provide efficiency and
effectiveness as well as fairness and equitability” means E-Government. We consider
that E-Government represents the services offered by government to the citizens using
electronic technologies whether the services are accessed through a PC, digital TV,
phone, PDA or other device.
2. Smart Cards Technologies
Most smart card programming consists of writing programs on a host computer that
send commands to and receive results from application-specific smart cards. These
applications read data from and write data to the smart card and use of the computing
features of the processor on the smart card.
There are different providers for software and hardware platform for cards and for host
applications. Sometimes the vendors of the operating system, provides tools in order to
extend capabilities of smart card. Examples of such situations include a closed system
application where cost or a particularly high level of security is a critical factor, or where
a particular encryption algorithm is needed to connect the smart card to an existing host
system. In these situations, smart card programmers write new operating system
software for smart cards partially in different programming languages or completely in
the assembly language of the processor on the smart card.
A growing number of smart card software development kits – SDKs and application
programming interfaces – APIs make this an easy task – table 1. Some of these are card
or card-reader specific, but opening of the smart card application development
marketplace is beginning to force interoperability standards on the makers of smart card
system components, so that this is becoming less rather than more of a problem.
Table 1. Table with SDK and API technologies for smart cards
Product Company WWW
CryptOS Litronic www.litronic.com
JavaCard SDK Sun java.sun.com/products/javacard/in
Microsystem dex.jsp
PC/SC Microsoft www.pcscworkgroup.com
IC-XCard HealthData www.hdata.com
Resources
EZ Component Strategic www.sainc.com
Analysis
IBM Smart IBM www.chipcard.ibm.com
Card
Kapsch Card Kapsch www.kapsch.co.at
Development
Tools
There are scenarios when developing with SDK or API is useless. That means the
developer can extend the operating systems. A number of companies produce and
license smart card operating systems that can serve as starting points for personalizing
the card – table 2.
Table 2. Table with operating systems for smart cards

Product Company WWW
ACOS Advanced Card Systems www.acs.com.hk
ISOS GIS www.gis.co.uk
OSCAR GIS www.gis.co.uk
SOLO STMicroelectronics www.st.com
SPYCOS Spyrus www.spyrus.com
Schlumberger’s SOLO smart card operating system is written in the C programming

language and thus is easily ported to any smart card chip. SOLO consists of a Java
Virtual Machine on top of a collection of general-purpose ISO 7816 native functions.
SOLO is the operating system in Schlumberger’s Cyberflex series of smart cards. Smart
card chips containing SOLO can be purchased from Motorola, SGS-Thomson, Texas
Instruments, and Hitachi.
3. Java Card Technologies Features
The Java technologies for smart cards are compatible with all existent standards. From
the point of view of vendor, Java technologies represent a reliable, secure and
interoperable platform, which can store and run many applications on the same card.
This is very important, because the same card could be used in the same time for health
insurance information system but also as a passport or drive license. On the card is
possible to reinstall a new application without modification from vendor’s card side. From
the point of view of developers that use the platform Java Card, the applications, called
generic applets, becomes more and more easy to debug, test and install. These things
increase the scalability and decrease the cost for development and maintenance for
applications.
Most of important smart card vendors and producers implement and have licenses for
technology-platform Java Card. The vendors are encouraged to have their own Java Card
implementations through Java Card Technology Compatibility Kit (TCK). Sun
Microsystems provide recurrently a reference implementation for java Card technology-
platform, plus development tools, grouped in Java Card Toolkit – JCT and Java Card
Protection Profile – JCPP. Practically Java Card Toolkit is the simulator and the debugger,
but Java Card Protection Profile provides a set of especially security tools.
Sun Microsystems publishes on the web site, Java Card Platform Specification – the
specifications which the producers of smart cards must respect and implement them.
Also, the company publishes Java Card Development Kit – represent the reference
implementation of those specifications.
For moment, the specifications are divided in three big parts:

The specifications for Java Card Virtual Machine – JCVM, define how must be a
Java virtual machine which will be implemented in a smart card plus the
structure of “executable” files – applets files, and the used Java language
subset;
The specifications for Java Card Runtime Environment – JCRE, define how
should behave the applets when are running in JCVM. JCRE consists from
JCVM, Java Card Framework and the libraries with classes hierarchies which
can be used by applets;
The specifications for Java Card API – Advanced Programming Interface,
define which syntax can be used and with which classes and packages the
developers should work.
All these specifications must be implemented by the smart cards producers. Any
producer-vendor that respect and implement the specifications for a specific smart card,
can say that the card is „java enable” or the card have a Java Card platform
implemented.
A special category of smart cards are „Java Card S”. These cards are identical with Java
ones. The only difference is that once the cards are on the market, is impossible to add
new applications-applets or delete existing ones.
The community of vendors and producers try to implement this platform because it
presents a lot of advantages:
Interoperability – once the applet is ready to run in a Java card platform, this
applet can run on any card that have java card platform. This means if a
company wants to modify the information system that they used is not
necessary to buy another brand of cards;
Security – is inherited from the structure of object oriented language Java.
Plus, there are standard libraries for cryptography which can be used in order
to offer high degree of security;
Scalability – many applets can stay in the same time on the same card in
secure manner. If the developed information system request a new
application, simply the new applets is load on the smart card;
Dynamicity – connected with the needs of end-users, can be upload on the
card new applets even after this one is on the market;
Compatibility with existing standards – Java platform do not eliminate any of
existent standard for smart-cards, like ISO7816 or EMV – Euro-Master-Visa.
The java smart-card do not depend by physical link with the card reader, if is
made through ISO/IEC 14443-4:2001 or not, and do not depend of the
microprocessor or chip memory from the smart card;
Transparency – all specifications are made public and are for free, also the
development tools from the web site.
Regarding the developers, it is obvious that they have also important advantages. They
can take advantage of the higher productivity provided by a object oriented
programming language like Java. They can reuse the source code and they can program
within modules using classes’ hierarchies. Also, the mode in which is building an applet
and how is simple is to be tested reduce the time of developing applets for smart-cards.
4. E-Commerce Features
Before taking in account eCommerce models and implicitly E-Payments, models is better
to have a general view about eCommerce:
Conceptual Frameworks: REA Meta model, UMM;
General Frameworks: Biztalk Framework, Building Blocks, ebXML Technical
Architecture, FIPA, eCo Framework Specification, IMPRIMATUR Business
Model, STEP, Java EC Framework, J2EE Framework, MPEG-21, OMG
eCommerce Domain Specifications, Open-EDI Reference Model (ISO 14662),
SPIRIT, TOGAF;
Trading Models: Ad Hoc Functional and Process Models, Global Commerce
Initiative & Protocol, cXL, Internet Open Trading Protocol (IOTP), Open
Applications Group Integration Specification, Open Buying on the Internet
(OBI), OBI Express, RosettaNet, Secure Electronic Market Place for Europe
(SEMPER);
Payment models:
o Macro-payment electronic schemes:
3D Secure – VISA last technology – credit card based
solution;
SET – Secure Electronic Transaction – Mastercard / VISA
credit card based solution;
iKP – IBM, credit based solution;
CyberCash – CyberCash Inc., credit based solution;
DigiCash – DigiCash Inc., eCash – cash solution;
NetBill – CMU, e-payment transfer over Internet – direct
fund transfer;
FSTC E-check – Financial Services Technology Consortium,
eCheque – cheque solution;
Other – credit card, cash, cheque, direct fund transfers
schemes.
o Micro-payment electronic schemes:
Millicent – DEC-Digital Equipment Corporation, eCash;
PayWord – Rivest and Shamir, eCash;
MicroMint – Rivest and Shamir, eCash;
NetCard – Anderson 1995, eCash;
NetBill – CMU, e-payment transfer over Internet;
Mobile commerce models: OMA – MeT.
There is no software product in our days which dominate the market. A common thing in
practice is to analyze which model or framework will be chosen. Any E-Commerce
project/solution have o provide at least two parts: “online shopping” and “online
purchasing”. So if for “online shopping” is enough to have a good organized web
application or portal solution, for “online purchasing” – E-Payment is more complicated.
Usually if E-Commerce solutions are forced to work with banks they have to include
credit card schemes of macro-payment models. So this are constrains so the manager is
faced with serious problems because he can not choose the proper technological solution
for his problem. All E-Commerce architectures have particular frameworks and provide
differed secure technology to get a safe E-Payment process. All E-Commerce
architectures have particular frameworks and provide different secure technology to get
a safe E-Payment process, which is the most important part regarding the security and
reliability of an eCommerce solution. For instance in this paper, is briefly present SET
payment scheme. SET Macro-Payment Scheme – credit card based solution is
fully described in [INTE03].
5. Analysis of SET – Secure Electronic Transactions
For details regarding cryptographic algorithms and encryption/decryption mechanism

please consult [TOMA06] and [TOMA08]. SET is a security specification designed to
protect credit card transaction on the Internet. It is not a payment protocol but rather a
set of security protocols for users to carrying out credit card transaction in an insecure
network such as the Internet. It is supported by a wide range of companies including
Visa, Master card, Microsoft, Netscape. In figure 1 is depicted SET Network Architecture:
Fig. 1. SET Network Architecture
The SET Participants as they are described in original document specification are:
Cardholder – an authorized holder of the credit card issued by the issuer;
Merchant – a person who has some goods/services to sell;
Issuer – a financial institution that issues the credit card;
Acquirer – a financial institution that establishes an account with the merchant
and process payment card authorizations and payments. It provide the
interface between multiple issuers and a merchant so that the merchant does
not need to deal with multiple issuers;
Payment gateway – connected to the acquirer, the payment gateway
interfaces between SET and existing payment networks for carrying out
payment functions;
Certification authority – an trusted authority which issues X.509v3
certificates.
Before talking about the details of the SET protocol, is important for a developer to know
and understand the dual signature method introduced in SET:
Dual signature is an innovative method for resolving the following problem:

The customer needs to send the order information (OI) to the merchant and
the payment information (PI) to the bank;
Ideally, the customer does not want the bank to know the OI and the
merchant to know PI;
However, PI and OI must be linked to resolve disputes if necessary (e.g., the
customer can prove that the order has been paid);
For a better understanding is strongly recommended to read about public key and
symmetric key cryptography paper, and especially the asymmetric key crypto system
RSA – original description or the one from [IVAN02] – contain a comprehensive sample
and a special design protocol for eCommerce payment.
The steps for dual signatures are:
The message digests – using one of MD5, SHA-1 message digest function – of
PI and OI are found : PIMD=MD(PI), OIMD=MD(OI);
The message digests are combined and the resultant message digest is found:
POMD=MD(PIMD +OIMD);
POMD is encrypted by using the customer’s private key to produce the dual
signature: DS=E(POMD, Priv_key).
The steps are depicted in figure 2:

Priv_key
PI MD
PIMD
II E Dual
POMD
Signature
OI
MD OIMD
Legend: PIMD = Payment Information message digest

PI = Payment Information OIMD = Order Information message digest
OI = Order Information POMD = Payment Order message digest
MD = Message digest function E = Encryption (RSA)
II = Concatenation Priv_key = Customer’s private key for RSA
Fig. 2. Steps used in dual signatures
Now we can discuss and interpret the figure 2:
The merchant is provided with OI, PIMD and DS. The signature can be verified
by computing MD(MD(OI)+PIMD);
The payment gateway is provided with PI, OIMD and DS. The signature can be
verified by computing MD(MD(PI)+OIMD);
By using dual signature, the customer can provide the linkage between OI and
PI;
How and why?
Merchant only knows OI but not PI;
Payment gateway only knows PI but not OI;
Nevertheless if either the OI or the PI is changed, the dual signature will be
changed;
That means, OI and PI are linked together.
In figure 3 and 4 are comprehensive to depict how is created a payment request by
cardholder and verification by merchant.
PI Request message
E(DES) Encrypt
Dual
data
Signature
Ks Send to payment
gateway via merchant
OIMD Digital
E(RSA) Envelope
KUb PIMD
OI Send to merchant
Legend:
PI = Payment Information
OI = Order Information
OIMD =OI message digest Dual
PIMD = PI message digest Signature
E(DES) = Encryption by DES
Cardholder
E(RSA) = Encryption by RSA
Certificate
Ks = Temporary symmetric key
Kub = Bank’s public key-exchange key
Fig. 3. Payment request by cardholder
Request message
Encrypt Legend:
data PI = Payment Information
Send to payment OIMD =OI message digest
gateway via merchant POMD = Payment order message digest
Digital MD = Message Digest
Envelope KUc = Customer’s public signature key
II MD POMD
PIMD
OI
MD OIMD
COMPARE
Dual
Decrypt POMD
Signature
KUc
Cardholder
Certificate
Fig 4. Verification process by merchant
In figure 5 is highlighted the entire SET protocol:

Card Merchant Payment
Holder Gateway
Payment initialization request

Anytime after Payment Request
Payment initialization response
Payment request
Payment response Authorization request
Authorization response
Inquiry request
Inquiry response
Capture request
Capture response
Fig.5 SET Protocol Overview.
The SET protocol detailed steps are briefly depicted in figure 9.9:
Payment initialization:
o Request:
Having decided to buy something, the cardholder sends a
purchase initiation request to the merchant;
o Response:
Merchant returns a response to the cardholder. The
response is signed digitally by using merchant’s private key;
Merchant also send its certificate and payment gateway
certificates to the cardholder;
Payment:
o Purchase Request:
After receiving the initiate response, the cardholder verifies
the certificates and obtain the corresponding public keys;
The cardholder can then verify the merchant’s response
(how?);
(By using merchant’s public key, decrypt merchant’s
signature to get the message digest. Compare the extracted
message digest with the message digest of the response);
Cardholder prepares order info. (OI) and payment
instruction (PI);
Cardholder generates a dual signature for OI & PI;
Cardholder encrypts PI with a randomly generated
symmetric key A. Key A and cardholder information is then
encrypted with the payment gateway public key;
Cardholder transmits to the merchant – figure 9.6:
• OI + dual signature + PIMD,
• PI + dual signature + OIMD (all encrypted by using
key A),
• key A + cardholder information (all encrypted by
using payment gateway public key): refer to as PI’s
digital envelope,
• cardholder certificate;
o Purchase Response:
After receiving the purchase request, merchant verifies
cardholder certificate and cardholder dual signature on OI;
(Merchant decrypts OI by using cardholder’s public key. The
merchant is provided with OI and PIMD so the dual
signature can be verified by comparing the previous result
with MD(MD(OI)+PIMD) – Figure 6);
Merchant processes the request and forward PI to the
payment gateway later;
Merchant creates digitally signed purchase response and
forward it to the cardholder together with its certificates;
After receiving the purchase response, the cardholder
verifies the certificate and the digital signature and stores
the purchase response;
Authorization:
o Request:
During the processing of the order, the merchant will
authorize the transaction by creating an authorization
request.
The authorization request includes the amount to be
authorized, the transaction identity and other information
about the transaction.
The authorization request is encrypted by a newly generated
symmetric key B. Key B is then encrypted by using the
public key of the payment gateway.
Note: only the payment gateway can get key B and use it to
decrypt the authorization request.
The merchant sends to the payment gateway:
• the encrypted authorization request and the
encrypted key B.
• the encrypted payment instructions as received from
the cardholder.
• cardholder’s and merchant’s certificates.
o Response:
After receiving the authorization request, the payment
gateway obtains key B by means of decryption and uses it to
decrypt the authorization request;
It also verifies the validity of the merchant’s certificates and
the digital signature of the request;
The payment gateway also obtains key A and cardholder
information by means of decryption and uses key A to
decrypt the payment instructions, dual signature and OIMD;
It then verifies the dual signature (how?);
The payment gateway is provided with PI and OIMD so the
dual signature can be verified by computing
MD(MD(PI)+OIMD);
Also, the payment gateway verifies that the transaction
identifier received from the merchant matches with the one
in the cardholder PI;
Upon all successful verifications, the payment gateway then
sends an authorization request to the issuer via existing
payment system;
After receiving the authorization response from the issuer,
the payment gateway generates an authorization response
message to the merchant. The message includes:
• Issuer’s response,
• Payment gateway certificate,
• optional capture token (to be explained later);
The response is encrypted by a new symmetric key which is
in turn encrypted using the merchant public key;
The authorization response is signed by using payment
gateway’s private key and is then encrypted by a random
symmetric key C;
Key C is then encrypted by using merchant’s public key;
A capture token is generated, signed and encrypted by using
a random symmetric key D;
Key D is encrypted by using payment gateway’s public key;
Payment gateway sends to merchant:
• Signed authorization response (encrypted by key C),
• Key C (encrypted by merchant’s public key),
• Signed capture token (encrypted by key D),
• Key D (encrypted by payment gateway’s public key);
After receiving the message from the payment gateway, the
merchant obtains key C by decryption and uses it to decrypt
the authorization response;
The merchant verifies the payment gateway certificate and
the digital signature of the authorization response;
The merchant stores the authorization response and the
capture token to be used for the later capture request;
The merchant also completes the merchant order by
shipping the goods or performing the services;
Capture:
o Request:
Eventually the merchant will request payment or perform
this payment capture stage;
The merchant generates a capture including: final amount of
the transaction and transaction identifier from the OI;
The capture request is then encrypted by a newly generated
symmetric key E. Key E is then encrypted by using the
public key of the payment gateway;
The merchant sends to the payment gateway:
• Signed capture request (encrypted by using key E),
• Key E (encrypted by using payment gateway’s public
key),
• Signed capture token (encrypted by using key D)
• Key D (encrypted by using payment gateway’s public
key) ,
• Merchant’s digital certificates;
o Response:
After receiving the capture request, the payment gateway
obtains key E by decryption and uses it to decrypt the
capture request;
The payment gateway also verifies the digital signature of
the capture request by using merchant’s public key;
If there are capture tokens, the payment gateway also
decrypts it;
After all successful verification, the payment gateway sends
a clearing request to the issuer via the existing system;
The payment gateway creates a capture response. The
response is encrypted by a random symmetric key F. Key F
is encrypted by using merchant’s public key;
Payment gateway sends to the merchant: encrypted capture
response, encrypted key F and its digital certificate;
After receiving the capture response, the merchant decrypts it accordingly and store it
for reconciliation with payment received form the acquirer.
Some important characteristics of E-Payment schemes are and any developer should be
aware of them:
System security – ability to protect against various forms of fraud e.g.,
repudiation and authentication in payment process;
Transaction cost – the big expenses needed to process the payment;
Traceability of payment – ability to find out who has involved in the payment;
Acceptability – whether the payment can be accepted in different environment
e.g., not only by the issuer;
Transferability – the ability to transfer payment without the need of a third
party e.g., a bank;
Divisibility – the ability to divide a value V to an arbitrary number of smaller
values - “banknotes” with a total value of V.
6. Conclusions
The informatics systems which are interacting with smart cards have an advantage
because the access to the different data bases and the time of transactions could be
considerably minimized. More than that, some smart cards contain non-volatile
memories which provide a great advantage regarding the development of secure
systems and applications, because in those memories they can store sensitive
information like digital certificates, symmetric and asymmetric private keys. In order to
improve the speed of computations, this kind of cards have also specialized
cryptographic coprocessors. The coprocessors execute complicate cryptographic
algorithms like RSA, AES-Rijndael, 3DES or algorithms based on elliptic curves. The
interesting approaches for information systems are the one witch involves m-applications
and smart cards applications in E-Business and E-Government.
Considering these aspects, the developers can take advantages in development of smart
card application by Java card technology. As a practical approach it would be interesting
building applets for ID, Driving License, Health-Insurance smart cards, for encrypt and
digitally sign documents, for E-Commerce and for accessing critical resources in
government and military field.
References
[ANIT00] Anita Rosen, “The E-Commerce Question and Answer Book: A Survival Guide for
Business Managers”, AMAcom Publising House, 2000.
[CHEN00] Zhiqun Chen, „Java Card Technology for Smart Cards: Architecture and
Programmer's Guid”, Addison Wesley Publishing House, USA, June 2000.
[ENRI03a] C. Enrique Ortiz, May 2003, on-line article:
http://developers.sun.com/techtopics/mobility/javacard/articles/javacard1/
[ENRI03b] C. Enrique Ortiz, September 2003, on-line article:
http://developers.sun.com/techtopics/mobility/javacard/articles/javacard2/
[IVAN02] Ion Ivan, Paul Pocatilu, Marius Popa, Cristian Toma, “The Digital Signature and
Data Security in e-commerce”, The Economic Informatics Review Nr. 3/2002,
Bucharest 2002.
[JCDT04] Tools Sun Java Card Development Toolkit 2.2.1:
http://java.sun.com/products/javacard/index.jsp
[JCDT04a] Sun Java Card Development Toolkit 2.2.1:
http://java.sun.com/products/javacard/dev_kit.html
[ISOI04] http://www.ttfn.net/techno/smartcards/iso7816_4.html
[POCA04a] Paul Pocatilu, Cristian Toma, “Securing Mobile Commerce Applications”,
communication in – “The Central and East European Conference in Business
Information Systems”, “Babeş-Bolyai” University, Cluj-Napoca, May 2004.
[TOMA05] Cristian TOMA, „Secure Protocol in Identity Management using Smart Cards”,
Revista “Informatica Economica”, vol. 9, Nr. 2, Bucuresti, 2005, p. 135 – 140.
[TOMA05a] Cristian Toma, "Smart Card Technologies in military information systems", The 36-
th International Scientific Symposium of METRA, Editura METRA, Bucuresti, Mai
2005, p. 500-506.
[TOMA05b] Cristian Toma, "Secure architecture used in systems of distributed applications",
The 7-th International Conference on Informatics in Economy, Academia of
Economic Studies Bucharest, Editura Economica-INFOREC, Bucharest, May 2005,
p. 1132-1138.
[TOMA08] Cristian TOMA - Security in Software Distributed Platforms, AES Publishing House,
Bucharest, 2008, ISBN 978-606-505-125-6.
nd
[TOMA09] Ion IVAN, Cristian TOMA – INFORMATICS SECURITY HANDBOOK 2 Edition,
ASE Publishing House, Bucharest, Ion IVAN, Cristian TOMA - coordinators, 2009,
pp. 680
On-line Payment System Survey – eCash
Marius POPA, Adrian CALUGARU
marius.popa@ase.ro
Abstract: The paper presents the main aspects regarding an on-line payment system. Some characteristics of
such system are presented and an existing system is analyzed. On its fundamental sense, the electronic
commerce is a concept that represents the purchase and sale process or exchange of products, services,
information, using o computer network, inclusively the Internet. In the most part of the cases, the electronic
commerce imply on-line payments that lead to creation of some kinds of electronic money and some specific
payment systems. There are described the some electronic payment mechanisms and the architecture and the
functions of the on-line payment system E-Cash are depicted.
Key-Words: on-line payment, e-cash, e-payment, security of electronic money.
1. Introduction
Digital economy development determined electronic commerce widely enhancement. The

traditional payment methods are still found on electronic commerce web sites, especially
in the countries that have not a good developed electronic payment system.
The cash is represented by banknotes and coins, being the most spread payment
method in retail trade. The cash using supposes the simultaneous physical presence of
the two transaction partners. This thing leads to impossibility to use the Internet
transactions.
The cheque represents a document used by a person who gives an order to a bank to
pay a sum of money to a beneficiary. It is one of the most insecure payment methods,
especially because the Romanian law doesn’t specify a very simple method to retrieve
the money in case of which the buyer issues an uncovered cheque.
The payment order represents a document issued by payer addressed to the bank that
has its account. Through this document the bank has to pay a fix amount to a
beneficiary.
The promissory note represents a commitment of the issuer to pay himself to the
beneficiary a sum of money at an established date.
The letter of credit has as aim the replacement of the credit given to a buyer with the
credit and the fame of a bank that is replaced to this buyer in the obligation to pay to
the seller the merchandise price. The payment is conditioned by the bringing of a
delivery proof of the merchandise to a buyer.
The traditional payment methods are boiled down to money transfer as cash or through
the documents: cheques, payment orders etc. The payment supposes an account
opening, the going to the bank to deposit and/or to initiate the transfer in trader’s
account. The payment confirmation can be or not asked by fax. The last and the most
extensive stage is delivery through trader’s distribution network or specialized postal
service.
2. Electronic money and payment electronic system features
In electronic commerce, it is not necessary to go to the bank to pay the suppliers of

goods and services. The role of the bank is to transform the cash in bits. The cash
cannot be completely erased, but they will be transformed more and more in the
electronic format.
At present, there are many payment systems. The most important problem is the
security one. The most part of the messages sent by e-mail are not crypted, that is
anyone can intercept the message. The actual electronic payment standards use the
crypting and digital signatures. Through electronic signature using can be make the
identity proof of a person who accesses a bank deposit or a credit card.
The electronic money can be divided in two classes:

with identity;
anonymous.
If a buyer uses the money with identity, then the bank reconstitutes the transaction and
the transferred money trace. If the anonymous money are used then nobody can
reconstitutes the spent money trace.
In electronic commerce a transaction is perceived as an action succession developed by

three participants: the client, the trader (supplier) and the bank. At electronic
transaction initiation, the trader and the bank come to terms how the money transfer is
made, using one or more payment electronic systems. Then the client orders some thing
on the trader’s web site. After the order launching, some actions are carrying out: the
trader sends to the client a confirmation by e-mail, the client transfers its credit card
number to the bank, the bank verifies the credit card information and the buyer’s
solvency and if all things are in order the value of the bought goods is transferred in the
seller bank account.
The bought article is delivered to the buyer and the transaction is finalized. Depending of
the agreement between the bank and the supplier, the last can access the identification
data of the buyer or these ones are secret.
As well as traditional systems, the biggest problem consists in the assurance that nobody
cannot copy the digital money or take the credit card information. The electronic
financial transactions between the banks were made before of Internet - SWIFT (Society
for World-wide Interbank Financial Communication).
The payment electronic systems must accomplish the following requirements:

secure – it must permit the safe financial transaction making in opened
networks as Internet. Unfortunately, the electronic money are resumed to a
simple file that can be copied. Copying or “double spending” of the same sum
of money must be prevent by electronic payment systems;
anonymous – the clients’ and made transaction identity must be protected;
convertible – the system users work with different banks, being necessary as
a currency issued by a bank to be accepted by another one;
useable – the payment system must be easy to used and accepted. The
traders who want to sell on-line the products have not any chance in case in
which the clients don’t agree the idea to make business on web;
scalable – a system is scalable if it can support new users and resources
without to have performance failures. The payment system must permit to the
clients and traders to integrate themselves in the system without alter its
infrastructure;
transferability – it refers to the capacity of a electronic bill to start the money
transfer from an account in another one without a bank direct contact by
supplier or client;
flexible – it is necessary that the system to accept payment alternative forms
in function of the guarantees asked by the parts involved in transaction, the
needed time to payment making, performance requirements and transaction
value. The infrastructure must support different payment methods, including
credit cards, personal cheques and anonymous electronic money. These tools
and payment methods must be integrated in a common framework;
efficient – the term of efficiency refers to the cost necessary to make a
transaction. An efficient electronic payment system must be capable to assure
small costs in comparison with the benefits;
integrable – it imposes that the system has to support the existent
applications, to offer the means for integration with other applications
indifferently of hardware platform or network;
reliable – the payment system must be permanent available and to prevent
the possible errors.
The presented characteristics must be assured in order to obtain with a high-level

quality.
3. Electronic money payment mechanisms
The electronic commerce will evaluate beyond of certain level when the ordinary
consumers will percept as an electronic payment mechanism as well as sure than the
traditional one.
Internet payment – when a on-line selling system is set working, the trader sells 24
hours per day, 7 days per week everywhere when the Internet has came. The potential
buyers and clients will have access to last information referring the products, services,
prices and their availability. The trader will have to assure that the informatics system is
always available and he will operate the order management, invoicing, payment
processing and money delivery.
Real-time payment solutions – with the exception of the off-line cases, the money
getting resulted as an on-line selling supposes interaction processes succession with
banks and other financial institutions. In present, the invoice payment is made with
credit cards, electronic money (e-cash), electronic-cheques or smart cards that are the
most important payment methods used in electronic commerce. The payment methods
are integrated at trader’s level in its informatics system or they are offered as outsource
by a commerce services provider. This one manages or intermediates the payments from
the third parts.
Credit card – it represents the most used payment form on Internet. The its using is
simple: the clients who browse in a web site and decide to buy a product or service must
introduce the credit card information through HTML form. The completed content as card
type, number card, owner’s name and card expiring date is sent to web site where the
information are collected and sent to the bank. If the trader’s site has a direct
connection with the bank then it is possible the real-time payment when the credit
covers the ordered goods value. The on-line transactions that use payment with cards
are cryptographic protected and the crypting way assures that only the bank and
services provider for credit cards will access the credit card information.
A first phase implies some agreements with financial institutions, using cryptographic
and authentication advanced technologies for messages securing sent through Internet.
The trader must open a bank account, offering on-line transaction services based on
cards. The cryptographic technology currently used SSL (Secure Socket Layer) erases
the possibility that an intruder gets the card number, supposing that he intercepts the
crypted data. The disadvantage is that SSL doesn’t permit to the trader that a person
who uses the card in a transaction is the card owner.
Also, SSL doesn’t offer any way to the client to know if the trader’s web site is
authorized to accept the credit card payments and the site is not a pirate one, designed
in order to collect data about cards.
The problem was resolved through new technology appearance called SET (Security
Electronic Transaction), developed by MasterCard and Visa. SET resolves the
authentication problem through digital certificates assigned to the client and trader. SET
offers a biggest security than the traditional one. To interdict the trader’s access to the
client’s card number, SET crypts it in a way that assures the access only for the client
and authorized financial institutions.
Each of the actors involved in a transaction as trader, client or financial institution uses
the private SET certificates that has the role of authentication in addition to public keys
associated to the certificates that identifies the other actors. In practice, a third company
(Verysign) offers the service for digital certificates providing to its clients, that is the
credit card owners. Regarding the seller, the process is similar: in the moment of on-line
shopping carrying out, before data interchange accomplishment for transaction starting,
the software that includes the SET technology validates the trader’s identity and credit
card owner. The validation process consists of certificate verification issued by
authorized providers of some kind of services.
E-invoice – the credit cards represent the most common solution in B2C and B2B
models. In B2B sector, the transaction volume is biggest than transaction volume made
through credit cards. Another reason is that the most part of the companies have
already used this tool in its classical form and payment method changing would need a
reorganization of the economic process that implies biggest costs. The payment
procedure through e-invoice is following: the transaction value is automatic sent to the
suppliers through an informatics system. These one respond with an invoice that will be
paid by different instruments. Secured methods are needed in order to filter the access
to the internal databases of the company. The EDI (Electronic Data Interchange)
standard offers an infrastructure for this aim. The major problem consists of commercial
law of each country that should recognize the electronic invoice validity.
Electronic cheques (Internet cheques, NetCheque) – it is a system developed at

Information Sciences Institute of the University of Southern California. The buyer and
the seller must have an account opened on the site of NetCheque. To assure the secure
it is used the identification through the Kerberos protocol and password. To pay through
cheque, it must install a special software at the client. The software works as a cheque
book. A client can send a crypted cheque through this software. The trader can encash
from the bank or he can use the digital cheque for another transaction with a supplier. A
special account from the network verifies the cheque validity and send an acceptance
message to the trader that will deliver the goods. PayNow
Debit cards – they need a personal identification number (PIN) introduction and a
hardware device using that reads the information on the cards. It is possible to be
replaced with the electronic chips used for smart cards that will replace the credit cards.
E-cash – they use a software application to save to the disk the cash equivalent in a
digital form. The advantage of this system is given by the money transfer cost that is
almost zero. To receive money it is necessary to access a virtual pay office available on
web or a ATM machine where the money are encashed. The difficulty of this system is
represented by the security implementation that guarantees that the money cannot be
altered. The using of cryptographic technologies, digital signatures and electronic
signatures helps to reduce the fraud possibilities. Another condition is that the e-cash
must reveal the identity of the person who paid them. The payment system has not to
have the bank as intermediary. Some examples are offered on [www3].
4. Ecash Payment System
E-Cash was implemented by the company DigiCash and it represents a payment system
on Internet based on the real money principle. It was invented by David Chaum in
Holland and it uses the cryptography with public keys that assure both the digital
signatures, and blind signatures. The system is focused on electronic money anonymity
assurance, and the buyer and the seller must have an account opened at the same bank.
The electronic payment systems have some essential requirements that must be
accomplished. From these, the following are parts:
security – this means that two payments are not made in the same time
without falsification also the protocol atomicity;
offline operability – if the system has offline operability, then the transaction
are executed only two parts: the buyer and the seller;
transferability – if the system has transferability, the users can use the coins
without to be necessary accessing of coin issuer in order to verify them. The
transferability implies the anonymity in the most part of the cases;
anonymity – it is a very important element for some users;
hardware independence – some working systems use equipments to prevent
the intrusions, double payment or to protect the master key of the system;
scalability – if the system is scalable then it supports a bigger users number.
Also, it is important the facility of adding and erasing the users in or from the
system;
efficiency – the efficiency of each process, payment, money retiring is an
important factor for all the parts;
easy to use – the interface with the user is not a cryptographic problem, but
the payment system is important to be more practical.
The E-Cash system asks the following participants:
participant – any participant in the system;
issuer – participant who issues the e-coins;
user – participant who uses the e-coins to buy or sell merchandise;
payer – participant who uses the e-coins to buy merchandise;
payment beneficiary - participant who receives the e-coins in order to sell
merchandise;
certification authority – participant who certificates the public keys of the
participants.
The E-Cash architecture is depicted in figure 1:
E-Cash Bank
validation
cash depositing or
withdrwing coins
coin depositing
Client’s payment Trader’s

Virtual Wallet Software
goods
Fig. 1. E-Cash payment system architecture
Coins generating – The coins in E-Cash are simple pairs of two integer numbers. The first
value is the serial number of the coin and the other is its value obtaining through a
calculation. The bank signs the coin when it computes the second value. For instance,
the bank uses the RSA algorithm and its private key in order to sign.
The coin is (a, f(a)) where a is the serial number of the coin and f is a hash function. An
user must prepare the coin before that bank signs it. Thus, he prepares a demand let’s
say 50 coins for 50$ each of them. He envelopes the following information:
sum: 50$;
serial number: a;
identification number: 11, 12, 13, …, 1100.
The serial number a must be different for each coin of the 50. The identification number
is a combination of two parts that are generated using a separating secret protocol. The
identification information is separated in two parts.
When the bank receives these ones prepared money, it uses the cut-and-choose protocol
and opens 40 from the 50 coins and verifies if the sum is the same, the serial number is
different and the identification number is valid.
Signing process using the blind signature – it is made because the bank has not to
associate the serial number and the person who wants to sign the coin. It is introduced
the bling factor r. It is a random integer number that can be multiplied in coin before
that the bank signs it. The person can eliminate it after the signing.
The process has take place as follows: the person sends to the bank f(a) * r instead of
f(a). When the bank signs it, only the person knows what it is the value after the r will
be eliminated. It is eliminated nay identification trace after the coin is spent.
Example: the person A has some money and A wants that the person B signs them
using blind signature. The person B has the public key e, the private key d and a public
module n. Person A selects a random number k from 1 to n. After that, A blinds the
value a, computing t = a*ke(mod n). The person B signs t with his private key d:
td=(a*ke)d (mod n). The person A can reveal the money when the previous result is
divided by k.
After this process, person A has the money signed by person B without person B to
know what he or she signed.
f d (a * k e ) d (mod n) a d * k (mod n)
= = = a d (mod n)
k k k
The spending of a E-Cash coin is made following the next steps, in accordance with the
figure 2:
1. the trader asks the payment – if the buyer agrees then the E-Cash
coins are selected and erased from the buyer, invalidating the
numerical series. Then, each coin is sent to the trader;
2. the trader sends the coins to the bank to see if the coins were spent
another time;
3. the bank verifies the signature and informs the trader if the coins are
valid;
4. if the coins are valid, the trader receives a confirmation and the value
of the coins is transferred in the trader’s account;
5. the goods are transferred to the buyer.
BANK CLIENT
Coin of 50$ Client’s 1 E-Cash wallet

public key
Generate coin of 50$
Private key of the bank SN Value
2
12345 50$
Signed coin
of 50$ 3
Signed coin
SN Value Bank
12345 50$ Signature
Record in the
database of
the bank
Fig. 2. One E-Cash coin spending
The secured exchanges are made in accordance with the following algorithm, as it is
depicted in figure 3:
1. the buyer generates the number n, selects a random number r and he
sends x=nre, where e is the public key of the bank in order to
certificate a certain sum of money;
2. the bank withdraws the sum of money from the buyer’s account and
uses its private key d to certificate the sum. The certificate is:
y=xd=(nre)d=ndred=ndr. The bank send y to the buyer;
3. the buyer computes z=y/r=nd;
4. in order to buy, the buyer send z to the trader;
5. the trader sends z to the bank and it he computes ze=n;
6. the bank computes ze=n and records n to avoid double spending.
5
CLIENT
TRADER 1 Virtual Wallet

Signed coins:
2 CoinCoin
of 50$
of 50$
Coin of SN Value Bank
50$
4 Confirmation
Spent 50$ Signature
Bank
Coin signature
3
database
Fig. 3. E-Cash secured algorithm
The advantages of the E-Cash system are the anonymity and security. The electronic
money is impossible to trace them because the blind signatures used in coin generating.
Secure protocol using that utilize public cryptographic keys RSA determines that the E-
Cash system to be secure against the eaves-dropping attacks.
The coins cannot be stolen while they are in transit. However, the coin protection in a
local computer can be improved by passwords and crypting.
In E-Cash system, the main disadvantage is the spent coin database dimension. If a big
number of persons starts to use the system, the database dimension becomes very large
and the database is hard to manage. Keeping the serial number of each coin spent in the
system is not a scalable solution.
Another disadvantage is that the system is not a standard one. There are many
companies that offer a complete property on the E-Cash system without an interaction
among them.
5. Conclusions
In present, it ascertains a big using of the electronic commerce, especially the on-line
payment way using. In the first on-line payment systems it took place the system E-
Cash developed by DigiCash. The system was focused on electronic money anonymity
assurance, and the buyer and the seller had to have an account at the same bank.
The system was not used long time because the main disadvantage of the very large
databases for the signatures. But the model E-Cash can be checked up in order to build
a more reliable system.
References
[ATLU03] Vijay Atluri, “Secure Payment & E-commerce Security Guide”, 2003
[CARL05] Georg Carle, E-Cash: “Cash-like Systems”, Seminar
Mobilkommunikation SoSe, 2005
[DONA01] Donal O’Mahony, Michael Peirce, Hitesh Teware, “Electronic Payment
Systems for E-Commerce”, Artech House, 2001
[POCA04] Paul Pocatilu, Cristian Toma, Securing Mobile Commerce Applications,
communication in “The Central and East European Conference in Business
Information Systems”, “Babeş-Bolyai” University, Cluj-Napoca, May 2004
[TOMA05] Cristian Toma, “Secure architecture used in systems of distributed
applications”, The 7-th International Conference on Informatics in
Economy, Academia of Economic Studies Bucharest, Editura Economica-
INFOREC, Bucuresti, Mai 2005, p. 1132-1138
E-Commerce Project Management Issues
Mihai DOINEA
mihai.doinea@ie.ase.ro
Abstract: In the first part of this paper is established the role of eCommerce project management in company
life. Also are highlighted the dependences and the differences between e-Business and e-Commerce projects and
implicit the management of those projects. There are presented the major area of knowledge management
where a eCommerce project manager should activate, eCommerce architectures and tools to achieve the best
solution for such kind of projects.
Key-Words: Project Management, e-Commerce, e-Business, security features.
1. Introduction
The term eBusiness and eCommerce have many definitions in IT fields. One of them is
that the eBusiness is the integration of a company's business including products,
procedures, and services over the Internet [ANIT00]. Usually and in practice a company
turns its business into an eBusiness when it integrates the marketing, sales, accounting,
manufacturing, and operations with web site activities. An eBusiness uses the Internet
as a resource for all business activities.
This paper concerns eCommerce. We can understand eCommerce as a component, a

part of an eBusiness.
The term of Electronic commerce or "eCommerce" is related with a wide variety of on-
line business activities for products and services, of different type business-to-business –
B2B and business-to-consumer – B2B, through the Internet or even through IntraNets –
private networks, including mobile ones.
After the opppinion of different specialist, eCommerce is devided in two components:
Online Shopping - the activities that provide to the customer or to the
business partener the information about products or services traded. This
information help them to be informed and to take the proper decision
regarding the buying process.
Online Purchasing - “ePayment” - the activities through a customer or a
company actually purchases a product or a service over the Internet or
private networks. Also another type of using for Online purchasing is
described in [Anne00] like “a metaphor used in business-to-business
eCommerce for providing customers with an online method of placing an
order, submitting a purchase order, or requesting a quote”.
E-Commerce project management means more than a simple project management

because we are talking about particular features or characteristics of eCommerce
activity. The CEO – Chief Executive Officer and staff are concerned not only about
eCommerce activities but also about the integration of eCommerce projects and their
management with all the important departments and activities from a company.
2. The Involvement of Project Management in Companies
The companies and corporations that are involved in “normal” Businesses to Business –
B2B and Business to Client – B2C activities become eBusinesses when the organization
succeed to integrate standard activities with their electronic information system. This
electronic information system could be an outsourcing solution for web and mobile sites
or portals or an “in house” developed system. For example, someone who work in sales
department could consider the web and wap – wireless application protocol – site a sales
tool. When he or she speaks with a customer, he/she shows to the customer the product
and service presentations on company’s web or even wap site, goes with the customer in
virtual tours of the newest products and services. The Marketing Department releases
products and services on the web and wap site first, providing eLearning courses, online
presentations and brochures. Another department like Customer Support host FAQ –
Frequently Asked Questions, support chat lines, and moderate newsgroups on the web
site. Purchasing uses the web to obtain prices on necessary components and place
orders, and Shipping uses the web to schedule deliveries and notify customers of
product arrival. So if a company “is making” in eBusiness way, then for each
department the web site, wap site and electronic infomation distributed open systems
are important tools they can use to be “number 1” in business. E-Commerce in the
previous case have an important role in sales and accounting department but is bound
with all departments concerning the input/output information that can provide. The
customer or the company’s client use eCommerce “channel” for achieve services and
products, faster, more secure and with less costs than before.
Also, someone who is involved in eCommerce Project Management have to take care of
and to be connected with following fileds-departments: package selection, business
intelligence, knowlege management, customer relationship management, project
portofolio management, services-application-solutions development and research,
process improvment, audit management and human resources management; especially
if this tasks are in a big entreprise environment.
Package selection – some software companies have already focused on several real
business problems. They created some remarkably solutions in markets like Supply
Chain Management (SCM), Customer Relationship Management (CRM), Enterprise
Resource Planning (ERP), E-Procurement, e-Commerce and m-Commerce – mobile
commerce. It is difficult to choose and select the proper software/hardware solutions
from the given number of vendor and choices. The challenge for a company is to select
the vendor and package solution from hundreds of products, philosophies and solutions
in order to make the right choice when implement them. The solution is designed to
provide to the company the resources on how to confront with the challenges –
processes and methodologies, tools – templates and software/hardware, and an
opportunity to learn from what others have done – articles, books and discussions
[PACK04].
Business Intelligence – means the procedures and techniques used in order to achieve
information about company’s customers, competitors and internal business processes.
Now many companies are in transition between traditionnal business models towards
eBusiness models, and they are forced to interact with customers and competitors in
digital competitivness. By using business intelligence, organizations can analyze client
and customer trends, evaluates the effectiveness of internal processes and study
competitor patterns. To enable effective business intelligence practices, organizations
need to use a wide variety of tools and techniques and integrate those with existing
business processes [BUSI04].
Knowledge Management – is the ability of company’s staff and employees to search and
find out in their company's electronically stored documents the information which they
need. Technologies used for Knowledge Management include: Search engines – with
artificial intelligence features, Databases – relational or object oriented ones, Meta tags
like XML, Classifications – maybe using neuronal networks [KNOW04].
Customer Relationship Management – this is the interactive and knowledge based age,
where success of the company, could depend on its ability to learn how to treat each
customer as an important individual.
Project portofolio management – this one have a great impact over the C-level –CEO,
CIO, CTO – decision maker. Important thing here is how managers can analyse projects
both on an individual and in an aggregate manner, metrics and corporate strategy. Also
important is to know how to use tools and technologies to choose the best project for
improving company skills and competitveness even if that project don’t make so much
profit for company.
Services-application-solutions development and research – this is about how to provide

software and hardware solutions in time into the market. It means the company have to
handle with Time to Market (TTM) problem. Nevertheless, managers' answer to the
problem is usually to shorten the development schedule and place even more pressure
on developers. But this is not the proper approach on TTM problem. This department
must explains strategies and technologies that will help department manager to optimize
TTM. The managers involved in this field have to find out best practices that will help
them to meet challenging schedules, and technologies such as Web services and
distributed systems that enable software on computers and mobile devices to connect
and interoperate with each other across platforms, programming languages and
applications [SOFT04].
Process improvment – stakeholders are concerned about the company rank in the
market and about the amout of profit that can be done by company. If is done correctly,
it can align the organization's operations with its strategic objectives. Process
Improvement have the scope and the goal to improve products and services all the time
in order to achieve desired outcomes.
Audit and evaluation risk management – this kind of management is used to aproximate
and establishes the economic and social implications of the company decisions in the
future, based on observations done during the examinations on business activities.
Human resource management – that means people-management. The people that are in
this field have to take care how they hire the best human people for the company
interests in order to get commitment without any problems from production teams,
stakeholders and upper management when is working in a project. An important thing is
to avoid conflict and project obstacles by discovering and working with company's
personality.
So, even if the eCommerce is part of eBusiness now we can see how many implications
have eCommerce projects in company life and of course how important is to have the
best management for such kind of projects.
3. The Dimensions of Project Management in e-Commerce Projects
Even in our days many IT projects and of course many eCommerce projects are not
successful. Also can be observed that the need for IT and eCommerce projects is
increasing all the time. Any project is a temporary effort undertaken in order to
accomplish a unique purpose. The management goal is to distributed resources during
the time in order to accomplish this task.
Some specialists consider that a project has to have following attributes: have unique
purpose, is temporary, require resources often from different fields, should have a
primary sponsor and/or customer, involve uncertainty.
In real life every eCommerce project, even every project, is restricted in different ways
by its:
Scope objectives
Time objectives
Cost objectives
Quality objectives – client satisfaction
It is the project manager’s duty to balance these three often competing goals. The idea
of this constrains is depicted in figure 1:
Scope, Time, Cost Distribution Management
40
35
30
25
20
Scope
15
Time
10
Cost
5
0
Cost
1
Time
2
Scope
Fig. 1. The Triple Constraint of Project Management
Project management is “the application of knowledge, skills, tools, and techniques to

project activities in order to meet or exceed stakeholder needs and expectations from a
project” [PMBK96]. So now we have the idea what means at least conceptual a
eCommerce Project Management.
The framework of eCommerce project management contains briefly the following

knowledge areas: Scope Management, Time Management, Cost Management,
Quality Management, Human Resources Management, Communication Management,
Risk Management, and Procurement Management. Those knowledge management areas
are bound through Project Integration Management using appropiate tools and
techniques. The project managers of such projects have to use diffrent tools like: Project
Charter and Work Breakdown Structure for Scope Management; Gantt charts, PERT
charts, critical path analysis for Time Management; Cost estimates and Earned Value
Analysis for Cost Management. Another important thing in eCommerce project
management is that the stakeholders – people involved in or affected by project
activities – to know all the time the state of project. Sometimes eCommerce project
manage could be tougher than every project management or general management. A
project manager must have experience an knowledge in general project management,
general management and in application area of project, ussualy have to know very good
eCommerce models patterns and the technologies within can develope the model. Of
cours the last thing but not the least is that a project manager has to obey to project
management code of ethics developed by Project Management Institute. So any
eCommerce Project that is developed with adeqvate have many benefits: improved
communication among participants, mechanisms for performance measurments,
identification of problems areas, clarification of project goals, clear understanding of
project scope and quantification of project risk.
All knowledge area has to be passed through all phases: Concept, Development,
Implementation and Close-Out. Also these phases are a common project’s life cycle.
Many new project managers have trouble looking at the “big picture” and want to focus
on too many details. In each knowledge area the Project Plan Development is important
because it must taking the results of other planning processes and putting them into a
consistent, coherent document named the project plan. Project Plan Execution must
carry out the project plan and Overall Change Control must coordinating changes across
the entire project.
E-Commerce Project Plan is a document used to coordinate all project planning

documents. The main scope of this plan is to guide project execution. E-Commerce
Project Management Plan Manual assist the project manager in leading the project
team and assessing project status. Those activities – and project plan – are parts of
integration management, the liant between all ohter knowledge areas.
The content of Project Management Plan as a result of Integration Management –

essensial part – coordinating manual in eCommerce Project Management is highlighted
in picture 2:
Chapters Section Contains

1.Introduction Overview, evolution of project plan,
reference materials, definitions.
2.Project Process model, organizational
Organization structure, common and standard
interfaces, project responsabilities.
3.Managerial Management objectives and priorities,
Process assumptions, dependencies and
constrains, risk management,
monitoring and controlling procedure.
Also here is depict the links between
other management documents from
Project different knowledge area: Scope, Time,
Management Cost, Quality, etc.
Plan – 4.Technical Process General technical framework, B2C and
Sections B2B features, eCommerce model
adopted highlighted in 2 different
position “online shopping” and “online
purchaising – ePayment”, methods,
tools and techniques, documentation
and project support functions and link to
technicals papers that contains the
software development cycle described
eventually in UML – Unified Modelling
Language.
5.Schedule and Dependences and resource
Budget requirements, budget and resource
allocation and schedule.
Fig. 2. Content of project plan management

These are the most important chapter from the main paper of an eCommerce Project. If
the implications within knowdledge areas are big, then it can be created every project
plan for every knowledge area. In this document and in other documents is
recommended to be used different management procedures described in this section.
Also, we strongly recommand to use a software application – Project Management

Software that helps the manager work. As annexes to this documents or at Scope
Management Document it is a common use to attach Stakeholder Analysis Document
that contains: A stakeholder analysis documents important (often sensitive) information
about stakeholders such as: stakeholders’ names and organizations, roles on the project,
unique facts about stakeholders, level of influence and interest in the project,
suggestions for managing relationships and a resume of each participant.
Another important thing is that if the eCommerce project is made in “outsourcing” or “in
house”. If is developed by you for a special company – even if is “developed in house” is
recommanded – that in “Technical Chapter” from Project Plan Management to exist links
to technical papers like: “User Specifications”, “Design Manual”, “Development Manual” –
contains software libraries and packages also class hyerachies description used in
eCommerce project, “Acceptance Tests Manual” and “Maintenance Manual”.
Project Plan Execution involves managing and performing the work described in the
Project Plan Manual. The majority of time and money is usually spent on development
and deployment. The application area or the project directly affects project execution
because the services offered by the project are produced during execution.
Overall change control involves identifying, evaluating, and managing changes
through the project life cycle. Three main objectives of change control: influence the
factors that create changes to ensure they are beneficial, determine that a change has
occurred and manage actual changes when they occur.
Of course, the management process depends of technological constraints and by the

expierience and knowledge of the project manager.
A project manager has to create as many projects as it is possible and to pay interes at
all knowdlege area managements. This helps him or her to collect funds and support
because have very solid financial arguments highlighted in Scope Management through
financial analysis methods: NPV – Net Present Value Analysis, ROI – Return of
Investments analysis and Payback analysis.
4. Conclusions
All the time the team leader and project manager have to realize that is better to use as
much as is possible standard technologies and solutions. There are special requirements
about communications, knowledge background and flexibility of the project manager in
order to ensure a good development environment. In the paper was presented only hints
and general ideas, and a person who is involved in management staff should discover
the management practice in a special field like eCommerce solutions.
It is recommended that in project management activities the project managers, team

leaders, general and department managers and C-staff to use proffessional specialized
tools like: Microsoft Project Server 2003, Replicon Web Time Sheet, SmartDraw
Management, Change Management System 2.0.1, ConceptDraw Project 1.1, Intellisys
Project Desktop 1.22; specialized techniques and technologies in order to make a
complete genuine management – containing the most important knowledge
management areas: scope, time, cost, quality, human resources, communication, risk,
procurement and integration management.
A proper project management of eCommerce solution have many advantages and in this
kind of project is worthing to do a high professional project management than an
“empirical” development and deployment of such solutions. Some advantages of a
proper project management are:
Good project management provides assurance and reduces risk;
PM provides the tools and environment to plan, monitor, track, and manage
schedules, resources, costs, and quality;
PM provides a history or metrics base for future planning as well as good
documentation;
Project members learn and grow by working in a cross-functional team
environment.
All the time we have to keep in mind that the company staff, customers, and other
stakeholders do not like failed projects and the project management in generally is not a
simple task, and in particularly – eCommerce field – requires special knowledge and
skills.
References
[ANIT00] Anita Rosen, “The E-Commerce Question and Answer Book: A Survival
Guide for Business Managers”, AMAcom Publising House, 2000
[BUSI04] http://www.gantthead.com/departments/departmentPage.cfm?ID=1
[KNOW04] http://www.gantthead.com/departments/departmentPage.cfm?ID=3
[PACK04] http://www.gantthead.com/departments/departmentPage.cfm?ID=4
[PMBK96] Project Management Institute – www.pmi.org , “PMBOK Guide – Project
Management Body of Knowledge”, 1996.
DECWEB - Internet fiscal statement submission
Mihai Ianciu, Costin Burdun, Ionut Florea
UTI Bucharest, Romania
mihai.ianciu@uti.ro, costin.burdun@uti.ro, ionut.florea@uti.ro
Abstract: The latest technologies are used not only in business, considered the most dynamic field of activity,
but also in Governmental strategies of interaction with the civil society and the business environment. The
governmental functional and technological requirements created new concepts and approaches of electronic
business (G2G, G2B, and G2C). In Romania, the Ministry of Communications and Information Technology was
the trend setter. It developed a large number of proofs of concept and pilot projects covering a wide area of
services that needed to evolve electronically. Together with the Ministry of Public Finance, it defined the
requirements and specifications for DECWEB, the programme that allows companies to submit their fiscal
statements via Internet.
DECWEB system is a keystone programme for the Ministry of Public Finance on its way towards moving
administration and services for society to information age. Highly awarded, the first DECWEB initiative was a
successful proof of concept and it needed to be upgraded to a new professional version with extended
functionalities, higher flexibility and advanced security mechanisms. This paper describes the DECWEB project
and how technology and professional services enhanced Governmental activities, why the project was such a
success and how it will evolve.
Key-Words: Fiscal Submission, Internet payment, digital invoice.
1. Project Overview and Objectives
The latest technologies are used not only in business, considered the most dynamic field
of activity, but also in Governmental strategies of interaction with the civil society and
the business environment. The governmental functional and technological requirements
created new concepts and approaches of electronic business (G2G, G2B, and G2C).
Once the trend was set, many of the Governments were keen to adhere to it. From e-
Procurement solutions to e-Administration and new electronic services to enhance the
communication and interaction with the society, they begin to define requirements, to
interconnect systems, to ask for standards and to make the industry interested to get
involved in this process.
In Romania, the Ministry of Communications and Information Technology was the trend
setter. It developed a large number of proofs of concept and pilot projects covering a
wide area of services that needed to evolve electronically. Together with the Ministry of
Public Finance, it defined the requirements and specifications for DECWEB, a G2B system
that allows companies to submit their fiscal statements via Internet.
Goals:
Transparency and efficiency for the activities of the Ministry of Public Finance
Efficient and standardized work procedures
Decreasing public expenses and bureaucracy
Assurance of a very high security and trust environment for performance of
public funds administration activities
Automatic and faster submission, taking over, processing and interaction
between Companies and Fiscal Administration office
Eliminated fraud or subjectivism
Encouraged introduction of IT and integrated applications for finance and
accounting at Company level, independent of their size
As a result and a benefit of the project, the Ministry of Public Finance can now better
concentrate its resources and activities for the primary purpose of verifying, balance
sheet synthesis, budget planning, instead of investing important resources of public
servants in teller’s work, data key in, verifications of correlations and solving frequent
situations of incorrect information into forms.
DECWEB system is a keystone program for the Ministry of Public Finance, on its way
towards moving administration and services for society to information age. Highly
awarded, the DECWEB initiative was a successful proof of concept and it needed to be
upgraded to a new professional version with extended functionalities, higher flexibility
and advanced security mechanisms.
From the security point of view, DECWEB is a major challenge, the information inside is
highly sensitive and the system is exposed to all type of attacks, from denial of service
to social engineering and personnel persuasion.
One major threat for balance sheet submission operations is represented by the risk of
processing malformed information for which there is no guarantee regarding its
authenticity and integrity. This is a major problem from a legal point of view:
if the Company is not able to prove the information authenticity and integrity
there may be charges caused by the submission of forged documents
if the MoPF is not processing the correct data, it may begin legal actions
against Companies without sound pieces of evidence; this may lead to
important image and trust damages for both the Ministry and the Company
Special attention was paid to this issue during DECWEB design phase as MoPF was
concerned about the problems that may rise. The proposed controls consisted of digital
signatures on all submitted documents together with the delivery receipts to notify
companies about transmission errors or forged messages. Moreover, the successful
delivery receipts were the evidence that the company submitted the correct documents
on time and in compliance with MoPF requirements.
2. Project Details
DECWEB is an integrated system, designed with a built in high availability architecture,

ensuring a high level of system security, the system being a mixture of proprietary and
open-source technologies.
The project consisted of:

Definition of a standard needed to set up secured communications and
information transmission between fiscal administration offices and the
companies/tax-payers
Setting up a secured portal for the access of companies to the Ministry of
Public Finance application and for the Financial Inspectors, to access the data
submitted by the companies
Implementation of a Certification Authority within the Ministry of Public
Finance to support authentication based on digital certificates and advanced
encryption
Setting up an assistance software for the generation, verification and
electronic signature of balance sheets
The system has two categories of users: companies that submit their balance sheets and
financial inspectors that verify the submitted documents. All the users were confident
and comfortable with the paper-based submission mechanism and reluctant to changes.
There were specific demands to allow parallel submission of the balance sheets (paper-
based and electronically) and to provide a graphical interface for the electronic forms
identical with the image of the printed ones.
An intensive user awareness program was initiated to explain the differences between
the systems, the benefits of the electronic techniques and the basic knowledge about
electronic signatures and information protection.
Technical headlines of the system:

High availability and scalability to face heavy loading periods before
submission deadlines
Advanced security characteristics which ensure confidentiality, authenticity,
integrity and non-repudiation
Open solution, flexible, scalable, and able to interface with other systems.
System architecture
The architecture is multi-tier model, with a central level (Ministry of Public Finance –
MoPF) and local levels (Financial Administrations – FA). There are two types of
communication with different security controls:
Internet, to enable the communication between Companies and the MoPF
portal
Intranet, for communication between MoPF and FAs
The system architecture is shown in figure 1.
Fig. 1. System Architecture
User authentication
In order to submit the Financial Statements, the Company has to access via Internet the
MoPF portal where it authenticates using its digital certificate; a 128 bits SSL connection
is established between the portal and the Company computer. Then, based on
company’s access rights, the MoPF server opens a link via MoPF Intranet to the local FA
to which the Company is affiliated, using a SSL tunnel between the servers. The
submitted declarations are stored first in the FA databases and then the information is
updated in the central database. Thus, the application provides a single point of access
and, simultaneously, local management of statements at the FA level while redirection is
performed transparently for the Company.
The Financial Inspectors use the same portal, via MoPF Intranet, and mechanisms to
authenticate within the system, each of them being redirected to access the information
of interest for the Fiscal Administration he/she belongs to.
Prior to user authentication, the portal identifies with its WEB server certificate; when a
user presents its digital certificate the portal queries a LDAP server to check the
certificate status. The digital certificate can be issued by the DECWEB project CA or by
other CA that has an agreement with the MoPF, as the system is open standard
compliant and designed to allow interconnection with other entities. As a result, when
the National Electronic System was implemented, DECWEB services were available also
through www.e-guvernare.ro portal.
Balance sheet submission and control
The success of DECWEB project was determined by the feedback of the users regarding
the new mechanism of balance sheet submission. The system had to provide a ground
breaking solution to demonstrate its efficiency and to convince users to choose it as the
preferred way to send documents to the MoPF.
The flow of the submission process from the company perspective is described in figure
2.
Fig. 2. Balance sheet submission flow
The assistance application that helps Companies to fill in the balance sheet files is the
main contact between the system and the end-user. The use of the assistance software
provides the following advantages:
easy to get (download from the Ministry of Public Finance site) and easy to
use
easy to use interface
direct copy from Microsoft Excel tables or ERP (enterprise resource
management) applications
verification of correlations and explicit display of errors
verification of the application integrity for each use
digital signature on balance sheet documents
easy display and printing for the documents the balance sheet consists of
(What You See Is What You Get – WYSIWYG)
The balance sheets must be submitted twice a year and their structure is evolving. The
application was designed independent of the structure of balance sheet files and, in
order to be able to send the correct information to the MoPF, Companies need to
download solely the balance sheet definition file, in XML format, signed by the MoPF and
to fill in the new forms. The application self checks its integrity and the integrity of the
XML files at start-up and allows user to sign the documents and prepare them to be
submitted, only when all the mathematical correlations are correct and all the files
contain valid information; this is a very convenient mechanism for end users and
financial inspectors as they don’t need to double-check and compute the correlations by
hand.
When receiving the documents, the application engine from DECWEB portal checks the
integrity of the files, verifies the status of the signing certificate and the correspondence
with the certificate of the logged-in Company and then stores the data into the database
of the Fiscal Administration where the Company is affiliated to. All the actions are logged
and at the end of the submission process the Company receives a receipt as proof of
successful operations or notification of the transmission errors.
Once a balance sheet is submitted, the Financial Inspector can verify the documents
(analyze them versus other submitted documents, Company’s financial history, etc.) and
notify the Company if they need more details, supplementary information or if the
balance sheets need to be submitted again.
The Companies can log-in anytime into the portal and check the status of their
documents (submitted, reviewed/not reviewed by a Financial Inspector) and the
messages from the inspectors.
3. The Impact of the Project
The project represents a corner turn for the MoFP, as it changes the paper-based way of
conducting activities with a state-of- the-art system that allows the organization to
decrease its front office manned operations and to have a better focus on the core
business of the Ministry.
The main impact of DECWEB was over the human element of the system. As everything
within the balance sheet submission was changed, it was needed a sound system able to
gain the confidence of the users that no data is lost, operations are faster and more
reliable, the integrity and confidentiality of information is preserved, everything with less
effort and lower costs.
At a glance, the advantages of using the DECWEB system are:

The Ministry of Public Finance work patterns are preserved.
The activity of companies is simplified.
The operation is legally similar (the same legal value) as the classic document
system.
The solution assures IT control requirements needed to adequately protect information:

availability, authorization, authenticity, confidentiality, integrity, non-repudiation and
privacy. For such a demanding program, it was not enough to integrate COTS
(Commercial Off-The-Shelf) products, but a great deal of research, analyses and product
customization was also needed, while keeping the interoperability and following the
standards. When the DECWEB system went live, it had an impressive information
security infrastructure and tools at the hands of its operators and its clients:
PKI architecture: certSAFE Certification Authority offering, besides the digital
certificates management, the possibility to further implement key recovery,
time-stamping and online digital certificate status and validation modules. It
was provided with dedicated hardware security devices (HSM) for key
management and policies, practices and procedures tailored for DECWEB and
the needs of the Ministry of Finance.
Authentication and authorization system: gateSAFE, a versatile and feature-
rich identity management product for user log-in on portal, covering the
following functionalities: PKI enabling of legacy applications, secure
connection over insecure lines (Internet/Intranet), SSO, SSL Acceleration, OSI
level 7 load balancing, accounting and virtual WEB server, web services
security, identity control
Mechanisms to offer IT security controls for information protection on user
side: offline application to fill in, check and digitally sign the balance sheets
User training, documentation and security awareness programs
User training and support was a key element for the success of the project, as long as
they needed to be able to understand the characteristics and functionalities of the new
system. As they became aware of the new mechanisms, they became confident in using
DECWEB.
If in the beginning the electronic signature was nothing more than a scanned hand
signature pasted into a document, after a short time the Companies began to ask the
MoFP if they could sign e-mails and contracts using the digital certificates provided for
DECWEB.
DECWEB is a modern system, with an open architecture, able to support the

development of new functionalities and modules.
As a consequence of DECWEB success and upon the request of the companies, the
Ministry of Public Finance decided that the system needs to be developed and extended
year by year and it became a “de facto” ”standard” when the Ministry set the
requirements for new systems implementations.
4. Outlook
One of the first steps forward for DECWEB was the integration within the National
Electronic System, a unified access point to and electronic service provider for G2B and
G2C activities.
The project needs to be further developed to keep the pace with evolving technologies.
There are two approaches to achieve this: introduction of new services within DECWEB
or creating a new and more complex system that includes and develops DECWEB
functionalities; the evolution of DECWEB must be analyzed from the point of view of the
technology and from the point of view of the services it offers to its clients and it
requires from third parties.
The elements needed to keep DECWEB on the frontline of Romanian Governmental on-
line services should include:
time stamp mechanisms to enhance the benefits of digital signatures
certificate validation services for the MoPF Certification Authority and open
standards requirements for third parties to be able to offer such services when
issuing digital certificates to DECWEB users
electronic series system to assign a unique serial number to each submitted
document, as required by the legal framework
electronic notifications mechanisms to offer a reliable and secure way to
exchange electronic messages between Companies and MoPF
electronic forms workshop to allow MoPF to design any type of forms and
other documents that will be filled in and submitted by tax payers
electronic payment system, to allow Companies to pay their fiscal debts on-
line
enhanced receipts issuance system, using digital signature and time stamp
mechanisms
archiving system to store the submitted documents for the period of time
required by the legal framework
The electronic notification system described in figure 3 is a functionality needed by MoPF

to be able to send electronic messages to tax payers and to receive delivery receipts
with legal value. Moreover, the Ministry needs such a system to be able to receive
electronic offers for its bids, as this is able to provide all the functional characteristics as
the paper-based bids (proof of bid submission before certain time, confidentiality and
integrity of the offer, authenticity and non-repudiation of the bidder, etc.).
Fig. 3 Electronic notifications mechanism
The analysis to implement these elements already began and there is a positive feed-
back from the MoPF, as they are interested to create framework to be available for the
electronic services they plan to develop and to set the basic references for other systems
that will be connected in the future with MoPF to exchange information or offer services.
References
[DONA01] Donal O’Mahony, Michael Peirce, Hitesh Teware, “Electronic Payment

Systems for E-Commerce”, Artech House, 2001

Vol 1, No 2

Diunggah oleh

Informasi Dokumen

Deskripsi Asli:

Judul Asli

Hak Cipta

Format Tersedia

Bagikan dokumen Ini

Bagikan atau Tanam Dokumen

Opsi Berbagi

Apakah menurut Anda dokumen ini bermanfaat?

Apakah konten ini tidak pantas?

Hak Cipta:

Format Tersedia

Vol 1, No 2

Diunggah oleh

Hak Cipta:

Format Tersedia

Table of Contents

SAMPLE DEVELOPMENT ON JAVA SMART-CARD ELECTRONIC WALLET

SECURE MECHANISMS FOR E-TICKETING SYSTEM........................................................... 23

SECURE SMART-CARD TECHNOLOGIES USED IN E-COMMERCE .................................. 37

ON-LINE PAYMENT SYSTEM SURVEY – ECASH ................................................................... 50

MARIUS POPA, ADRIAN CALUGARU...................................................................................... 50

DECWEB - INTERNET FISCAL STATEMENT SUBMISSION ............................................... 65

MIHAI IANCIU, COSTIN BURDUN, IONUT FLOREA ............................................................................ 65

Key-Words: smart card, Java Card application, ISO 7816, JCRMI.

2. Complete applications for Java smart cards

In figure 1 is depicted a complete Java card application:

The link is through serial or The contact is realized through

JCVM=Java Card Virtual Machine CAD=Card Acceptance Device

Fig. 1 Complete Java smart card application

2.1.1 APDU Commands

The general template for an ADPU Command is depicted in figure 2:

Fig. 2 General structure for an APDU Command

2.1.2 APDU Responses

Fig. 3 Structure for an APDU Response

The fields’ explication for APDU Response is the following:

2.2 JCRMI Model

3. Issues in the development and life cycle of a Java card applet

For an Java card applet-application is involved a series of elements and concepts, of

For a better documentation it is recommended the developer’s and user’s guides

Applet Java Card

Fig. 4. Methods to be implemented by an applet to execute the complete life cycle

Isolation and partition of the applet objects is an important concept because on a

Memory and memory objects management is an important concept because the

4. Practical sample of developing a Java applet card

This practical example will be deployed as in the Message-Passing model. In what

%JC_HOME%\bin\converter.bat -config com\sun\javacard\samples\wallet\ Wallet.opt

%JC_HOME%\bin\capgen.bat com\sun\javacard\samples\wallet\ javacard\wallet.jca

In order to completely understand the process, we should understand from step 6

4.2 Interpretation of the code and results

Table 1. Source code for the application draft

Interrogation to find which amount of money the card contains

APDU command for debit – e.g. to deposit money on the card –

private Wallet (byte[] bArray,short bOffset,byte bLength){

public static void install(byte[] bArray, short bOffset, byte bLength){

public boolean select() {

public void deselect() {

public void process(APDU apdu) {

// At this point, only the first header bytes

private void credit(APDU apdu) {

// it is an error if the number of data bytes

// get the credit amount

// check the credit amount

// check the new balance

private void debit(APDU apdu) {

private void getBalance(APDU apdu) {

if (le < 2) ISOException.throwIt(ISO7816.SW_WRONG_LENGTH);

// send the 2-byte balance at the offset 0 in the apdu buffer

} // end of verify method

// Select the installer applet

// create wallet applet

//Verify user pin

//Get wallet balance

//Attemp to debit from an empty account

//Credit $100 to the empty account

//Debit $50 from the account

//Credit $128 to the account

//Debit $51 from the account

// * SCRIPT END *