Embed Size (px)
Citation preview
Chapter 2
Review of Literature
In this era on internet and e-commerce, world becomes smaller as more and more
people, organization, businesses are connected closely with each other with network and
ultimately are dependent on this infrastructure. This raises the question of security, smart card
now days called as the secure tamperproof device and use of this is unlimited. It is just as
carrying a tiny computer in pocket.
This chapter gives the details of the work carried out by different researches on
smartcard in the area of architecture, security based on smartcard, use in ecommerce and
payment system.
1
2.1 Smart Card
Smartcard is secure tamper proof device. Use of smartcard is increasing day by day
because of the security and its application multiple areas examples, ID card, Health card,
Loyalty card, Electronic Purse, and cryptographic card for signing, and much more.
2.1.1 Smartcard Evolution, History and Development
The origin of smart cards began when consumer requirements for convenience and
security out spaced the capabilities of magnetic stripe cards. Providing increased data storage
and added security, smart cards were introduced in Europe in the early 1970’s as stored value
cards for payphones. These early smart cards were disposable and were an effective means to
reduce losses. Today's advanced contact less and dual-interface smart card technologies -
together with emerging digital signature laws and the development of biometric techniques -
can bring a range of services to life on a single piece of silicon
Since the 1970s, the history of smart cards has reflected steady advances in chip
capabilities and capacity, as well as increases in the number and variety of applications. In
1970, Dr. Kunitaka Arimura of Japan filed the first and only patent on the smart card concept.
On 25 March 1974 Roland Moreno called father of microchip from France, filed the original
patent for the IC card, later dubbed the "smart card". The later development is summarized in
the following
Table 2. 1
S.N. Year Development
1 1977 Began developing the IC card product by Bull CP8, SGS Thomson, and
Schlumberger
2 1979 Developed the first secure single chip microcontroller by Motorola for use
in French banking.
3 1982 The world's first major IC card field testing of serial memory phone cards
2
took place in France,
4 1984 Field trials of ATM bank cards with chips were successfully conducted
5 1986 Use of card by Banks of Virginia, Maryland National Bank, National Palm
Beach Bank and the Mall bank.
6 1987 U.S. Department of Agriculture's nationwide Peanut Marketing Card
7 1991 First Electronic Benefits Transfer (EBT) smart card project launched for
the Wyoming Special Supplemental Nutrition Program for Women,
Infants, and Children (WIC)
8 1992 A nationwide prepaid (electronic purse) card project (DANMONT) was
started in Denmark.
9 1993 Multi-function smart card applications in Rennes, France,
10 1994 Europay, MasterCard, and Visa (EMV) published joint specifications for
global microchip-based bank cards (smart cards).
11 1995 Multi-functional, multi-technology MARC cards with chips were issued to
U.S. Marines in Hawaii.
12 1996 Interoperability issues addressed by MasterCard and Visa, JavaCard Multi-
application Operating System (MULTOS)
2.1.2 Notable Smart Card Projects in India
Use of smart card stared in India very recently. Following paragraph outlines the use of
smart card in India. Employee's Provident Fund to issue smart cards soon for its 2.6 crore
subscribers, which would be accessed through its 267 offices. Smart Cards for Government
employees & Labour in Goa will be issued soon. ICICI Bank plans to launch smart cards with
real time online integration for facilitating transactions, payments to utilities and services etc.
Brihanmumbai Electric Supply and Transport (BEST) has decided to introduce contactless
cards for ticketing across its entire network. Metro railway, Kolkota is going to issue smart
season tickets instead of magnetic strip cards.
3
Amongst the other notable and successfully implemented projects are
Gujarat State Smart Card Driving License project
Delhi's traffic police is planning to introduce smart card driving licence.
Rajasthan milk card project –
Watsan information system launched by Indian government & UNICEF
which ensures the construction and maintenance of the wells.
Petro cards - BPCL Prepaid cards used in cyber cafes of HPCL (and many
more Smart Loyalty Programme as in the case of Snowhite Apparels,
HomeSaaz etc Smart dealership loyalty programme in the case of Hewlett-
Packard India Ltd Smart Employee Management as in the case of LML
Ltd, TVS Electronics, TVS Suzuki etc.)
Smart Health Management as in the case of Wockhard Hospitals,
Bhopal Gas Relief Project
SMARS (Smart Rupee) project sponsored by the Reserve Bank of India
(RBI). The project was launched in 1997 at the Indian Institute of
Technology; the consortium includes banks such as the State Bank of
India, Canara Bank and Citi Bank, terminal manufacturers like VeriFone
India Pvt Ltd, systems integrators like, Aplab Limited, Ascom India Pvt
Ltd, CMS Computers Ltd, and card manufacturers like Gemplus and
Schlumberger. Mumbai Campus Scheme the SMARS (smart rupees)
project involves the issue of smart cards to students and staff for use in
around 150 on-campus merchants and retailers. [2,3]
2.1.3 Smart Card Technology & Architecture
Over the last 20 year use of smart card in the various fields of applications has
increased exponentially. This growth of smart card raises challenges to the technologist for
developing various aspects of smart card hardware and software.
4
Basic smart card is a plastic card of xx x xx size(credit card size)[15] embedded with
the microprocessor chip, traditionally have the 8-bit Processor attached with memory, and I/O
interface, where memory is divided in three part RAM, PROM and EEPROM and used for
temp storage, storing operating system and place for application on card respectively (Fig
2.1) Depend on the application smart card comes with contact and contact less type where in
contact less card user need to swipe the card in front of reader, card take power from internal
antenna and communicate with IFD with the same antenna.
Figure 2. 1 Smartcard Architecture
Recent development in processor allows use of RISC a 32 bit processor in smart card
(PicoRISC), which features less power dissipation, smaller and simple architecture for contact
less smart cards and allows real OS with DES and RSA algorithms in less instruction, it also
allows to use memory access in supervisory and protected mode to get the better memory
accessing security [4, 28]. ARM7 is being used in "CASCADE " (Chip Architecture for Smart
CArds and portable intelligent DEvices) by European Commission through the Esprit
Program (EP8670).[5] whose objectives are have better computing power with less power
consumption, to execute modern complex cryptographic algorithms which are too complex or
too long for existing CISC processor along with the a biometric voice profile reorganization.
Simultaneously to enhance the security aspect of smart card Public-Key Cryptography
co-processor for handling complex cryptographic function on card is being used on CISC and
RISC base processor, application specific instruction were invented for RISC base smart card
who does the long integer arithmetic in single instruction [7].
5
Flash RAM has been introduced in the non volatile memory for getting more capacity
in small space [8].
The Card Operating System which resides in the ROM plays key role in the operation
and functionality of the card. Traditionally card OS helps card to communicate to the external
world with set of secure commands [19] and helps maintain the data and application securely
on the card.
Even though major changes takes place in smart card operating systems from last
twenty years still it lacks in many of the features needed for this generation application like
working in distributed computing environment [9]. Word has entered in the era of web
services where today’s smart card open operating systems facing flexibility in secure post
issuance application management. Today’s smart card operating system is in forth generation
phase where hardware abstraction level, a virtual machine concept, is used between hardware
and application to comply interoperability issues between many manufacturer. The
application layer frame work now uses virtual machine layer to execute the application on
processor. This new architecture makes application code independent of processor type. Java
Card [??] by SUN Microsystems, Multos [??] and Windows for smart card by Microsoft are
some examples.
2.1.3.1 Java CardSun Microsystems invented the Java Card architecture to overcome the short comings
of the earlier monolithic card, where card issuer or the third party developers are allowed to
develop the application for the card after card produced and multiple applications can reside
on single card. (theoretically) as per the users need.
JavaCard technology enables programs written in the Java programming language to
be run on smart cards and other small, resource-constrained devices. Developers can build and
test programs using standard software development tools and environments, then convert
them into a form that can be installed onto a Java Card. Application software for the Java
Card platform is called an applet, or more specifically, a Java Card applet or card applet (to
distinguish it from browser applets). While Java technology are far too underpowered to
support the full functionality of the Java platform on the card.
6
Java Card platform supports only a carefully chosen, customized subset of the features
of the Java platform. This subset provides features that are well suited for writing programs
for small devices and preserves the object-oriented capabilities of the Java programming
language. The standards that define the Java platform allow for binary portability of Java
programs across all Java platform implementations. This “write once, run anywhere” quality
of Java programs is perhaps the most significant feature of the platform.
Figure 2. 2 Java Card Architecture
Fig 2.2 shows the architecture of Java Card. [33]. A clear separation is maintained
between application and card operating system by adding a Java Card Virtual Machine
(JCVM) layer between processor and application. Java is object-oriented (with single
inheritance), statically typed, multithreaded, dynamically linked and has automatic garbage
collection with 201 instruction but because of constrain in card environment, Dynamic class
loading arrays, 32-bit and 64-bit integers, Unicode character support threads, Float and double
data types, cloning and automatic garbage collection are not the part of Java card platform.
The Java Card Virtual Machine is the key to providing binary portability. The JVM
Specification defines a Java virtual machine as an engine that loads Java class files and
executes them with a particular set of semantics. The class file is a central piece of the Java
architecture, and it is the standard for the binary compatibility of the Java platform. The Java
Card Virtual Machine Specification also defines a file format that is the standard for binary
compatibility for the Java Card platform defined as the CAP (Card Applet) file format. It is
7
the form in which software is loaded onto devices that implement a Java Card virtual
machine.
The integrity and security of the Java programming language are widely recognized.
Java compilers provide extensive, stringent error checking when the program is compiled. All
references to methods and variables are checked to make sure that the objects are of the same
type. The compiler also checks to ensure that a program does not access any un-initialized
variables. This means that the JVM ensures that no applet method or function is allowed to
access another method or an instance variable outside of the boundaries of the applet.
Malicious programs cannot forge pointers to memory because there are no pointers that can
be accessed by programmers or users.
Java accesses variables only through references to them from the Java stack. Malicious
programs are also prevented from “snooping” around in the Java heap because the values of
the local variables are unavailable after every method invocation. A method cannot access
resources it shouldn't. All access to methods and instance variables in a Java class file is
through access modifiers. These modifiers define a level of access control for each method.
Method can be declare to be public (no limitations), protected (accessible by methods in the
same subclass or package), or private (no access by other classes). If no declaration is made,
the default allows the method to be accessed by any class in the same package.
The standard VM can only guarantee the security if the Java byte code is guaranteed to
be well constructed by the conformant compiler and well behaved. This is why the VM
contains a class file verifier. The class file verifier verifies all class files before execution
through a 4-phase process. Since the verification of the class file is a complex task, it was not
included in the Java Card. Instead all of the tests that do not require run time information are
performed outside of the card and the resulting byte code is signed [33]. Some attempts have
been made to develop on-card byte code verifier in [34, 35, and 36] to reduce the security
attacks on the verified byte code before signing.
2.1.3.2 MultOSMULTOS is a secure Multi application operating system that has been specifically
designed for smart card systems. The MULTOS Operating System provides the underlying
communications, memory management and Virtual Machine. The MULTOS OS handles the
8
loading and deleting of Applications, application selection and the sending/receiving of
APDU command-responses. MULTOS is responsible for managing the interaction of
application, the Security manager, the basic processor functions and the cardholder with each
other. Each entity can send events to MULTOS that it will translate in a series of events for
other entities or handle the event itself when the requested (system) resources are under its
own control. Fig 2.2 gives the details of MULTOS architecture [??]
Figure 2. 3 MULTOS Card Architecture
MULTOS Virtual Machine consist of the Application Programming Interface (API)
and Application Abstract Machine (AAM)[15]. This is the only platform that has an easy to
use assembler language. MULTOS smart card applications were originally developed in MEL
(MULTOS Executable Language), which contains typical assembler instructions plus “smart
card friendly functions” called primitives. Applications are ultimately executed in a language
called MULTOS Executable Language (MEL). MEL is a byte code language normally written
using Assembly Language notation. The applications may be written in a higher-level
language, such as C, Java and VB6. SwiftC and SwiftJ are the compilers that translate the
code in to MEL assembly language code. To make MULTOS accessible to the VB
community SwiftCard Technology are currently working on a Visual Basic to MEL
translator. As MULTOS OS support C, Java and VB, whether the choice of the OS is
dependent on Language or not is the issue under consideration.
9
Payment Loyalty Identity
API (Application Programming Interface)
AAM (Application Abstract Machine)
OS OS
Hardware Hardware Hardware
OS
Virtual Machine
Application Firewall
MULTOS allows multiple applications that may be developed by diverse parties to co-
reside on one smart card both independently and securely. The platform independence of
MULTOS applications is achieved by the implementation of a ‘virtual machine’ on which the
applications are run. Effectively, there is a standard Application Programming Interface (API)
between applications and the operating system. This feature allows applications from different
vendors and industries which may be written using different standards to co-exist on a single
operating system and co-reside on the same card. It also allows application developers to
write an application once, and run it on different hardware platforms without modification.
Operating system or platform services are available to application program in the form
of application abstract machine. This abstract or virtual machine enable applications to call
upon to interact with a clearly defined set platform services with out any knowledge of the
underlying hardware implementation, which may very from manufacturer to manufacturer.
Viewed from highest level the AAM consist of two separate address spaces, one for code and
one for data. The data address space is divided in to three segments.
Seven address registers and two control register
Two addressing modes, segment and tagged
31 instructions
The core architecture is extended by
A set of mandatory primitives
A set of optional primitives
These cover system control, flow control, and stack, literal, unary block and binary
block operators. The instruction set together with the mandatory primitives is sufficiently rich
to code applications efficiently. The address space is divided into separate code and data
spaces, and are both limited to 64K each. MULTOS guarantees that private data is visible
only to the owner of the data. MULTOS provides the possibility to pass data from one
application to another application through the use of a public buffer and a mechanism called
Delegation.
10
The security and integrity of each application residing on a MULTOS card is
guaranteed by ‘fire walls’ that isolate applications, ensuring that the malfunctioning of any
one application, or even a ‘hostile’ application, can in no way affect the operation of another
application. This in turn means that a card issuer can be safe in the knowledge that an
application requiring a high degree of security and type approval, can co-reside with
applications for which security is not of paramount importance. MULTOS application
providers do not need to trust each other’s products, nor even have any relationship with each
other. The security target for the MULTOS Platform is ITSEC E6 high, and this has been
achieved. The OS manages all system resources and controls the access. The VM relies on the
OS to achieve isolation between applications.
An application Load /Delete Certificate needs to be obtained from the MULTOS
Certificate Authority for each application and each card. Application code and associated data
can be encrypted before transmission to the card over a possible insecure network. The card
decrypts the application after it has been received. The card and the application mutually
authenticate each other before the application is accepted. To securely download or delete
applications, MULTOS uses Application Load Certificate (ALC’s) and Application Delete
Certificate (ADC’s), By using ALC’s MULTOS verifies that application is initiated correctly
after download. It Check the validity and integrity of the application, allocates a protected and
isolated memory area and lock the new program into this new space. This way the
applications are strictly separated from each other so they cannot interfere with each other.
The issuer can manage applications on his card. The MULTOS OS is exclusively issuer
centric.
The unique design of MULTOS enables applications to be securely downloaded to the
card either by Service provider or remotely over insecure networks (i.e. by going on-line to
the issuer via a telephone, ATM, or via a PC across the Internet). Applications can
subsequently be securely deleted and others added over the lifetime of a card without the card
ever leaving the cardholder’s possession. MULTOS is unique in supporting both the loading
and deletion of applications. This product feature brings benefits to both the issuer (or service
provider) and to the cardholder. The issuer can introduce new products and services faster to
market as there is no need to recall or re-issue cards to add new functionality. Similarly,
11
upgrades and fixes to existing applications can be undertaken remotely and at reduced cost.
Finally, MULTOS can provide a seamless migration path from, for example, an existing
industry standard being phased out and replaced by a newly adopted standard or from a
national electronic purse standard to an international standard such as CEPS. As for the
consumer, the possibilities are endless. Cardholder’s can now have individually tailored
products and services which change as their needs change. Take a business traveler with a
MULTOS card for example. The traveler can decide to load his electronic airline ticket, an
electronic purse and a metro travel card local to his business destination via the Internet, and
upon his return, he can discard these applications freeing space on his card for the next trip.
2.1.3.3 Windows For Smart Card Microsoft has launched a new business unit promoting a chip card OS, named
‘Windows for Smart Cards’ (WFSC). The platform model is mixed. The terminal can call
applications written in OS-dependent language. The security is achieved by the fact that only
Microsoft is able to write and download such applications onto the card. Currently, only basic
ISO 7816 commands seem to be available. This system’s functionality is comparable to the
traditional systems of the different vendors and as such yielding equivalent memory / cost as
the current existing operating systems. The terminal has direct access to files stored in the
card. In this case, the card acts as a file server. The terminal can call applications written by
third parties. As Microsoft doesn’t verify them, they are interpreted by a virtual machine
called ‘Run Time Environment’ (RTE).
As it has been stated in the status report by Europay International, WFSC isn’t a fully
multi-application platform in the sense we defined in chapter 2. If two applications on the
card can accept the same command, the processing must be the same for said command for
both applications. The development system consists of an environment to both create a
custom version of the operating system and create applications. The operating system is put
into ROM while the applications can be put into ROM or EEPROM. The target applications
include. Identification, authentication, encryption, decryption: Windows 2000 logon, e-
banking, e-mail, e-commerce. Closed user groups: campus schemes, loyalty, citizen cards
GSM
Finance: debit/credit, E-purse
Pay-TV
12
Transportation (contactless)
The current system consists of a library of operating system functions that can be
assembled in a modular fashion. The user selects the required functions and security level in
his development environment and compiles the operating system functions into an executable
form. This can be loaded in ROM or EEPORM. This can be done for multiple target
platforms with different target chips. The virtual machine is optional in this system.
The security of the applications depends on the type of platform model used. The
security of applications written in OS-dependent language is achieved by the fact that only
Microsoft is able to write and download such applications onto the card. In such a model no
virtual machine is used, therefore the security of the applications depends on the inspection of
the code by Microsoft. The security of files is guaranteed by access control lists (ACLs). The
security of the applications unverified by Microsoft is guaranteed by the virtual machine. A
Memory Management Unit could be needed to partition the memory into different
independent sections depending on the user requirements and the way the user wants the
applications to be certified.
It is up to the card manufacturer or issuer to determine whether to the platform is
required to be ITSEC or CC certified. Microsoft would like implementations to be ITSEC E4
certified but no certification has been obtained yet.
Dynamic application management is possible with WFSC. However, there is no
definition of secure card management (loading / execution / locking / unlocking / deleting of
card applications / software) in WFSC, and hence the use of auxiliary, proprietary
specifications is needed.
WFSC is only a platform; a business model to choose a complete back office for
downloading applications isn’t imposed nor advised. Consequently, WFSC can be used in a
cardholder centric, issuer centric or PC centric model. The issuer needs to define his security
mechanisms for the card management.
13
2.1.3.4 MAOS In mid 2000 Europay International published report MAOS Platform, which gives the
comparison of the JavaCard, Multos and Windows multi-application smart card [32]. The
major issues targeted are about security, application codes on multifunction platforms are
processor base require verification of the code, while application code on multi-application
platform is independent of the processor and its security is garneted. Application
independence if achieved in the multi-application platforms by interpreter and memory
manager. MAOS addresses following criteria
Dynamic application management
Issuer involvement
Security
Model
Cost
Open vs proprietary governance
Cross industry support
Availability
Performance and development environment
??????
2.1.4 Recent/Current work in Smart Card Architecture
University of Lille and Gemplus are together developing the CAMILLE and AWARE
operating system, where theses current issues in operating system could be solved [9].Camille
is based on MIT-Exo-kernel architecture which is designed without hardware abstraction but
on secure (de)multiplex access. The embedded code is expressed using dedicated intermediate
language FACADE [31] which is compiled using Just in Time technique. It provides
portability as application can be written in any higher level language and can be compiled to
the intermediate language FACADE, extensibility is achieved as no predefined abstraction
level is used application has to import or built the abstraction required and security is insured
by code-safety checking [10, 11, 12].
14
SCOSTA an indigenous operating system is developed for smart card in the driving
license card in India [13]
2.1.5 Smart Card Standards
Smart Card Standards for the basic smart card are available with ISO. Primarily, smart
card standards govern physical properties includes plastic card dimensions, toxicity, physical
characteristics, location of contacts & electrical signals and communication characteristics of
the embedded chip are covered through the ISO 7810 & ISO 7816-part 1,2,3. [15,16,17,18].
Smart card interindustry commands numbering system, registering procedure for application,
data element & Structured Card Query Language (SCQL) are defined in the ISO 7816 part
4,5,6,7[19,20,21,22], Security related command, synchronous card, biometrics method &
Cryptographic information application are defined in ISO 7816 part 8,9,10,11,15. [23, 24, 25,
26, 27].
2.1.6 Smart Card Operations & Life cycle
Basic operations of the smart cards are specified in the ISO standards. Use of smart
card is only possible through the interface device called IFD (Interface Device); This IFD
should also have the compatible with the ISO standards for communication to the smart card.
Smart card communicates to the IFD through two type protocol T1 and T2. After inserting the
card to the IFD giving power, card return the ATR (Answer To Reset) which provides the
information to the IFD the type of protocol it uses and other information. IFD select an
appropriate application from card to invoke the use of card for the specified application.
Through its life smart card has to go to the different phases i.e. from the chip manufacturer to
the card holder. There are five phases in the Life Cycle of card.
Chip and card Manufacturing phase: where a processor chip is manufacture
and embedded on the card with some manufacturer’s data on the in.
15
Pre Personalization: This phase is also done by the card supplier where
chip is mounted the card with proper contact and card operating system is
installed. On this phase the functionality of the card is defined.
Personalization Phase: is done by the card issuing agency. In this phase
issuer initialize the card for pre operating data structure is installed on the
card and personal information of the card holder is printed or embossed on
the card.
Application phase: This phase is user’s phase where he makes use of the
card as per his need
Termination Phase: Either card will get physically damaged by user or
because of the miss use of the card System blocks permanently.[??]
Figure 2. 4 Cash base Payment Model
2.2 Electronic Payment System
Electronic payment system is the alternative to the coin or paper based cash payment
system to easy the user to make payment for their purchased goods or services over the
network or internet and in absence of the physical (entity) presence. Initially cheque in bank
payment systems are used to serve the purpose of the same but now in the era of internet and
e-commerce paying securely over the internet is important task for the electronic payment
system. Currently credit card are also in use for the payments over the network but still users
are doubting about trustworthy and the security of their money because of the increase in the
16
Semiconductor Manufacturer
Smart Card Manufacturer
Smart Card Issuer
Service Provider User
Smart Card Production life cycle
Produce & Load Init / Instanciate
Use
Smart Card software life cycle
frauds [38] which ultimately causes loss of value(money) either of users, merchant or
participating banks.
Present electronic payment system are to far from ideal payment system because of the
higher transaction cost, more fraudulent activities, and multiple parties are involved in the
payment processing simultaneously lacks users acceptance, proper application plans and
incompatible standards/specifications. The good payment system should satisfy the user’s
acceptance and merchants in the mass scale.
Present electronic payment system can be divided in two group electronic cash and
credit/debit system [39] or token based and account based system [40]. Tokens or electronic
cash are like the physical cash which represent the value and credit/debit or account based
system does not carry value but a message to transfer value.
2.2.1 Characteristics of Electronic Payment System
Characteristics of electronic payment system are looked from various points of view as
technology, user, market and more. [40] [41]
Applicability: acceptance of the user where he/she can use the method to
buy goods or services.
Easy to use: the system should not be complex particularly in Indian
context a user from the remote area should be able to use the system.
Security: is concerned with unforgeability of the value(money). Creation,
modification and over spending of the value(money) should be protected.
Integrity of the value as well as authorization for value should be spent by
the concerned user only.
17
Reliability: Smooth running of the system.
Trust: degree of the confidence that the money and the personal
information is safe
Scalability: system should be scalable by timely changes in the underlying
infrastructure
Convertibility: money conversion may be possible from one method to
another like loyalty point convertible to the money
Interoperability: system should be operable in between multiple service
providers.
Efficiency: reasonable cost of the handling micro-payment.
Anonymity: is basically privacy to protect the identity of the user
Traceability: traceability of the money in the system who and when it occurs with
anonymity cause to built trust.
Authorization type: whether offline or online transactions can be made in same
way.
2.2.2 Architecture/ Structure/Model of Electronic Payment System
User a payers always spends the money and the merchant receives the money for the
goods or the services he has given to users. In traditional system user spends his own physical
money and merchant receives direct physical money no third party come in between
transaction but in electronic payment system variety of models are specified by different
organization / researchers, which are summarized here. Ahmad-Reza Sadeghi & Markus
Schneider, in Electronic Payment Systems[41], presented four types of payment systems
electronic cash, Cheque or credit card, Remittance and Debit orders base system.
In cash base transaction users withdraw his e-cash or an electronic token, from the
bank where he has his account for this bank debit same amount from users account. User does
purchase it as per his requirements and the need by using this e-cash. Merchant receives the e-
18
cash and deposit in bank on his own account. Afterward its merchant bank, who sends the
request to user’s bank for transfer of money and deposit in merchant account. Figure 2.5
Figure 2. 5 Cash base Payment Model
In Cheque and credit card payment system user stage 1 withdrawal is not present,
merchant deposit cheque or credit card slip to bank settlement between banks transfer value in
respective merchant account Figure 2.6
Figure 2. 6 Cheque/Credit card based Payment Model
In other two types user and merchant give payment order to their respective banks for
transfer of money [42]. User bank and merchant banks are called Issuer and Acquirer
respectively in [42].
19
3-Deposit
Users Bank
User Merchant2-Payment
Merchant Bank4-Settlement
3-Deposit
Users Bank
User
1-Withdrawal
Merchant2-Payment
Merchant Bank4-Settlement
2.3 Payment System Standards
MasterCard and Visa international have derived the standards for the global
application of smart card in payment system. Initially started with EMV specification in 1996
and subsequently updated with latest version EMV2000, This specifies the specification for
Card based on the ISO 7816 compliance, and further specification needed for electronic
payment/purse. It also specifies the security criteria for the and authentication methods.
2.4 CEPS
The Common Electronic Purse Specifications (CEPS) developed by the Europium
country in October 1999 by the CEPSCO, LLC, which define requirements for all
components needed by an organization to implement a globally interoperable electronic purse
program, while maintaining full accountability and auditability. CEPS states overall system
security, certification and migration. CEPS have paved the way for the creation of an open,
de facto, global electronic purse standard and has no associated royalty costs.
The lack of interoperability is the single greatest obstacle to the growth of smart cards
in payment system. The proliferation of electronic purse programs has resulted in many non-
interoperable, proprietary systems. The need for scaleable solutions, international usage and
cost-effective ways of implementing programs has highlighted the importance of a globally
interoperable set of electronic purse specifications.
CEPS requires compatibility with the EMV (Europay MasterCard Visa) specifications
for smart cards and defines the requirements for an interoperable card application, the card-to-
terminal interface, the terminal application for point-of-sale and load transactions, data
elements, and recommended message formats for transaction processing. CEPS also provides
functional requirements for electronic purse scheme participants and uses public key
cryptography for enhanced security. CEPS builds on the EMV foundation by extending
20
global interoperability to electronic purse schemes worldwide and is committed to its global
proliferation has no associated royalty cost.
Currently, organizations from over 30 countries, representing more than 90 percent of
the world's electronic purse cards have agreed to implement CEPS. India is also one of them,
who decided to accept CEPS as the national specification for smart card based electronic
purse [??]. In addition, over 200 organizations have signed license agreements for CEPS and
have received the specifications.
CEPS come in three part Business requirement Specification, Functional requirement
Specification and Technical Specification. CEPS was developed with the following goals in
the mind.
Provide consumers and merchants worldwide with payment products that
are faster, easier, less expensive and more convenient than cash,
particularly in small value transactions (micro-payment).
Provide an interoperable environment for different technology platforms or
schemes.
Offer merchants a means to offer electronic purse services to both domestic
and internationally traveling cardholders.
Enable issuers and acquirers to offer international electronic purse services
to cardholders and merchants.
Ensure that the electronic purse application may coexist with other applications on
the same chip to use on Multiplication Card.
2.4.1 Electronic Value Transfers in CEPS
a. Electronic Purse – Merchant: Electronic value may be transferred from an
electronic purse card to a merchant terminal/PSAM. (Purchase)
b. Merchant - Electronic Purse: Electronic value must only be transferred from a
merchant terminal/PSAM to an electronic purse card to support a cancel last
purchase transaction or a purchase reversal transaction.
21
c. Merchant – Merchant Acquirer - System Operators – Networks: Value may
be transferred from a merchant terminal/PSAM through to a merchant acquirer,
system operator(s) and network(s) as part of the clearing and settlement process.
(Transaction Batch Download )
d. Electronic Purse - Electronic Purse: Electronic value must not be transferred
from one electronic purse card to another.
e. Merchant – Merchant: Electronic value must not be transferred from one PSAM
or merchant terminal to another except in environments where a controller
terminal acts as a transaction consolidator for other terminals of the same
merchant.
f. Card Issuer - Electronic Purse: Value may be transferred from an electronic
purse card issuer to an electronic purse to perform a load transaction.
g. Electronic Purse - Card Issuer: Electronic value may be transferred from an
electronic purse to an electronic purse card issuer to perform an unload transaction.
h. Electronic Purse - Other Non-Financial Application On the Same Card:
Electronic value may be transferred from the purse application to nonfinancial
application(s) on the same chip on the card.
22
2.4.2 Payment System (Model..?) in CEPS
A distributed entity model is used in CEPS for electronic payment system. The Figure
2.7 shows entities Scheme provider, Processor, Fund issuer, Card issuer, Load acquirer,
Figure 2. 7 CEPS Architecture/Model..??
Me
rchant acquirer, Merchant (POS Device). Card Holder (CEP Card) participating in the CEPS.
2.4.2.1 Scheme ProviderThe scheme provider is the authority who establish the scheme for electronic purse and
is responsible for
Establishment of the scheme and its Rules & Regulation.
Establishing an infrastructure for the overall functionality and security of a
CEP system.
Establishing policies and procedures to ensure that all transactions are
secured
Procedure for completion of transaction if other scheme entity is
interacting with the own scheme
Establishing Certification Authority (CA) for the over all scheme
Fraud detection and risk prevention policies and procedures for the scheme
23
Scheme Provider
Card Issuer Fund Issuer
Load deviceMerchant Acquirer
Processor
Card HolderMerchant
POS with PSAM
2.4.2.2 Card IssuerIt is the main entity responsible for issuing the CEPS card to the cardholder. The card
issuer may issue CEP card for more than one CEP scheme.
The card issuer has the liability for all value loaded onto the CEP card and
the management of the funds pool
The card issuer is responsible for monitoring transactions received to
ensure that a valid CEP card issued by the card issuer made the transaction.
The card issuer authenticates the CEP card for all load transaction
2.4.2.3 Fund IssuerManages the funds in the card and keeps a log of the transaction. Fund issuer
coordinates with the card issuer to load/unload the amount in the card with help of loading
device.
2.4.2.4 Load acquirerThe load acquirer is the entity responsible for establishing a business relationship with
one or more CEP scheme providers & to load the amount in the card in coordination with the
card issuer.
2.4.2.5 Merchant acquirerThe merchant acquirer is the entity responsible for establishing a business relationship
with one or more CEP scheme providers to clear and settle Purchase transaction and also for
the creation and distribution of the PSAMs. Merchant acquirer must do the following.
Collect and validate all transactions and provide acknowledgments of
successful collection to the POS device or to the merchant.
Ensure that each batch of transactions is cleared and settled once and only
once.
Ensure that CA public keys, aggregation parameters, certificate revocation
lists and optional blocking lists from the scheme providers are sent to the
POS devices.
Make payment to the merchant and participate in settlement with the
recipient of all transactions forwarded for card issuer processing.
2.4.2.6 MerchantThe merchant has responsibility for the use of a POS device to accept CEP cards for
payment of goods and services.
24
2.4.2.7 ProcessorNormally transaction flows directly from merchant acquirer or load acquirer to card
issuer but some times an additional node is added in between merchant acquirer and the card
issuer. These nodes are called processors. The processor must do the following tasks,
Send transactions to other processors in the agreed format.
Participate in a financial transaction with the connecting processors at the
time that the transaction is sent or received.
Participate in the scheme provider dispute resolution process with connecting
processors to resolve any issues related to invalid transactions.
2.4.2.8 Card RequirementsThe Common Electronic Purse Specifications specifies the requirements of card either
single or multi-application card with its business requirement strategy. Either card
should be used with in the boundaries of nation or worldwide with single electronic
purse or co-exist with other financial and non- Financial application. The following
are the card requirements:
Card must be contact-based integrated circuit technology with serial number,
support system-specific card numbering standards and PIN verification.
Card must be able to be authenticated at a load device by the Issuer and point-of-
sale terminal by the PSAM.
Card must require a form of cardholder identification for electronic value load
from accounts in both a proprietary environment and a shared network
environment unless loading from cash.
Card must support purchase reversal transactions, cancel last purchase transaction
capability.
Card must support unattended load device
Card must be able to support off-line locking and unlocking, enabled at issuer
option.
Card must able to use multi currency slot, log the transaction. And should have the
expiry date
2.4.2.9 Point of SalesPoint of sales devise must be user friendly with and able to accept variety of CEPS
compliance Cards. Purchase and purchase reversal, incremental purchase, and cancel last
purchase transactions should able to process off-line. The following are the card requirements:
25
EMV Compatible
Support to have PSAM
POS must have Date & Time, display card balance & transaction acceptance key.
Place for Revocation list
In built communication facility to download transaction to merchant acquirer ?
2.4.3 CEPS Security: Authentication Process, Keys & Signature
Security and successful authentication is a prerequisite for the processing of any CEPS
card transactions, since it takes place in multi-application environment. CEPS specify the
security on loading amount in CEPS card by load acquirer with the help of card issuer which
is online transaction and purchase transaction done at merchant place with POS device which
is offline transaction; other part security is not defined in the CEPS and kept on the scheme
provider discretion. For purchase (offline) transaction Two-way mutual authentication
between the CEP card and POS terminal is necessary. Asymmetric cryptography is used for
authenticating CEP card with PSAM and exchange of secret key. RSA is the public key
algorithm chosen for CEPS. Dynamic data authentication is necessary for load, unload,
purchase, incremental purchase, and cancel of last purchase. Symmetric cryptography is used
for on line transaction to protect the integrity of the data by generating the MAC’s.
Signatures are generated & used at various levels in CEPS transaction to validate the
transactions. The card uses a unique diversified secret key, personalized into the card, to
generate and authenticate transaction signatures for load, unload, currency exchange, purchase
and cancel last purchase transactions. In load & unload transaction S1, S3 are generated by the
CEP card for validating transaction data and sends to Card Issuer and Load acquirer
respectively. S2 is generated by Card Issuer and sends it to the CEP card.
During purchase CEP card and PSAM authenticate each other and POS device
generate PS2 signature and S3, S4, S5, S6 MAC’s generated during purchase transaction.
26
Figure 2. 8 CEPS Architecture/Model..??
Batch of each complete POS transaction, which is attached with MAC by the PSAM,
is kept in the POS device memory until collected by the merchant acquirer. This batch in POS
contains the total count and amount of the transactions for ensuring the integrity by merchant
acquirer. The count and amount of the transactions in the batch must be protected by the S4
MAC.
2.4.4 Processing
The Fig xx.xx shows an overview of processing take place in the payment system, path
1, 2 and 3 are the transaction between CEP Card & POS, POS & Merchant Acquirer and
Merchant Acquirer & Issuer.
27
2.4.4.1 Path-1 : Purchase, Incremental Purchase, Reversal Purchase & Cancel last Purchase Transaction
After inserting CEP Card in POS Terminal, CEP card authenticate it self to PSAM and
PSAM to CEP Card using a combination of public key and symmetric cryptography. Value in
the CEP card is then adjusted after confirmation from the user. After completion of
transaction POS terminal validate the transaction and batch of transaction to store in the POS
terminal data store. Figure xx.xx shows detail steps in the purchase transaction. After reset,
POS initiate the purchase transaction by selecting the EMV application on the card with
specific currency slot, followed by the exchange and verification of certificates to authenticate
mutually to each other. After confirmation from the card holder about the value of purchase,
PSAM sign data DS using public key of CEP Card (VKPCEP) where DS contain header,
Figure 2. 10 Purchase Transaction
am
ount to be debited (MPDA), session key produced by PSAM for authentication purpose along
with hash result of DS Hash [section 10.1.4, of ??], encrypted by private key of PSAM and
send to CEP card to debit the amount. In response to debit command CEP Card decrement the
amount and return S3 MAC and card issuer S6 MAC to POS Device to validate the transaction
completion or return status condition if command fails to debit the value. CEP card also Logs
the transaction details.
Initiate Command
Exchange Certificates
Confirm amount and send
debitValidate PSAM decrement amount
1
2
3
4
Send MAC S6, S35
5
5Validate Card using S3
Compute S4, S5 and Log
CEP Card POS Device
28
In case of incremental purchase; another debit command along with S2 MAC computed by
PSAM, is sent to the card in response to this gets S3 and S6 MAC, reversal purchase; POS
device send reversal commands along with S2 MAC and log the transaction details and in case
of cancel last purchase additional processing is needed [Section 4.5.4 of 44]
After completion of valid mutual authentication by PSAM the amount of a purchase is
added to the total amount for the batch (MTOTBATCH ), and the count of transactions in the
batch is incremented by one(NTBATCH ) in batch summary record. The PSAM in the POS
device generates a merchant acquirer S5 MAC to complete the transaction and logs the
transaction [Table 65, of 45]. PSAM protect count and amount of the transactions in the batch
by S4 MAC. This transaction batch is kept in data store of the POS device for transferring to
the merchant acquirer [Table 2.2].
Table 2. 2 Batch Summary Record
Field Value Length (bytes)RIDPSAM Identifier of the RID owner that assigned the
PSAM creator Identifier 5
IDPSAMCREATOR Identifier of the PSAM creator 4IDPSAM PSAM Identifier assigned by the merchant
acquirer 4
IDBATCH Batch Number 2MTOTBATCH Net amount of all transactions (purchases less
cancel last purchases) in batch - this includes both aggregated and non aggregated transactions
4
NTBATCH Total number of transactions in the batch. This includes a count of all detail transactions plus the NTAGG from each aggregation record.
2
S4 MAC - created using the PSAM MAC key - the minimum contents of the S4 are the data listed in this table (excluding the S4 MAC)
8
Table 2. 3 Transaction data Log in POS data store
Field Contents Length (bytes)
IDSCHEME Usually the AID from the CEP card but may be a
reference number
var
29
IDISS,CEP Issuer Identifier 4
IDCEP Card serial number 6
TIPDA Transaction Indicator - set by POS device 1
DTHRPDA Date & Time stamp from transaction initiation 5
CNTRYPDA Country of the POS device 2
DOMPDA Domain of the POS device 1
CURRPDA Currency 3
AMCEP Authentication method supported by the CEP card 1
NTCEP Card transaction number 2
RIDPSAM Owner of the RID that assigned the PSAM creator id 5
IDPSAMCREATOR Identification of the PSAM creator 4
IDPSAM PSAM Identifier assigned by the merchant acquirer 4
IDACQ Acquirer ID; usually the actual IDACQ but may be a
reference number
4
NTPSAM PSAM transaction Number 4
MTOTPDA Net value of transaction 4
MPDA Value of last increment (either debit or recredit,
depending on TI)
4
S6 MAC over Issuer-defined data 8
BALCEP New Card Balance 4
DDCEP Issuer discretionary data 0-16
DEXPCEP Expiration date for transaction 3
IDBATCH Batch Number 2
VKPCA,ISS,CEP Version of the CA Public Key the PSAM must use
for card authentication
1
IDREG,ISS Identifier of the issuer region - zeros if no region 4
VKPREG,ISS Version number of the region public key used to
create the issuer certificate
1
CSNISS,CEP Identifier of the Issuer’s certificate contained in the
card
3
CCPDA Transaction status 2
30
S5 MAC – created by PSAM MAC key 8
2.4.4.2 Path-2 : Transaction between Merchant & Merchant Acquirer.
Periodically, Merchant Acquirer collects the transactions from the POS device’s data
store and complete verification of S5, S4 MAC created by the PSAM and consolidation of
transactions from multiple POS devices. CEPS does not provide the detail information or
procedure for collecting the transaction batch from merchant to merchant acquirer in terms of
protocol and the medium for transmission [Section 9.1 of 45] but insist on the minimum data
to be transferred, Table 2.2 and Table 2.3.
Possibilities of the different type flows between POS device and Issuer are given in
CEPS [Section 4.3.2, 43]. Theses possibilities are depend on the nature, structure and setup of
the business by the scheme provider, which may includes intermediate processor between
POS device and Issuer. Processing rules and the flows are decided by the scheme provider to
deploy smooth operation of the scheme with achieved system security and data integety.
Figure 2. 11 Batch Transfer Transaction
31
Either POS device, Merchant or Merchant Acquirer initiate the batch collection
process by closing the batch in POS device and mark it ‘closed batch’, while after closing
batch, no transaction should be added in to this.
Closed batch along with the batch summery record is then sent to merchant acquirer.
Contents of the transaction data and batch summery record is given in table 2.2 and table 2.3.
POS device wait for acknowledge from the merchant acquirer, till that closed batch remain in
POS device. Merchant acquirer validates the batch using S4 MAC, logs batch and validate the
each transaction using S5 MAC.
Merchant acquirer divides the batches by card issuer and arranges them for settlement
with card issuers.
2.4.4.3 Path-3 : Transaction Between Merchant Acquirer and Card Issuer.
Merchant acquirer sends the transaction to issuer for settlement and managing the fund
Figure 2. 12 Batch Transfer Transaction
po
ol. Card issuer validates the batch, validate each transaction done by CEP card by verifying S6
MAC and logs the batch. After validation issuer send acknowledgment back to the merchant
acquirer. CEPS does not specify any detail in this path also but gives minimum data
requirement same as stated in [section xx.xx]
32
2.5 Electronic Payment System Specification/standards for India
MIT report
Smars IIT Bombay
More transaction of lower value,??
2.6 Protocol Design and Verification
Success of electronic payment system is based on the design principals and its
correctness.
Rules, formats, and procedures that have been agreed upon between participating
parties are collectively called a protocol. The protocol, then, can contain agreements on the
methods used for:
Initiation and termination of data exchanges
Synchronization of senders and receivers
Detection and correction of transmission errors
Formatting and encoding of data
A protocol specification consists of five distinct parts. To be complete, each
specification should include explicitly:
1. The service to be provided by the protocol
2. The assumptions about the environment in which the protocol is executed
3. The vocabulary of messages used to implement the protocol
4. The encoding (format) of each message in the vocabulary
33
5. The procedure rules guarding the consistency of message exchanges
2.6.1 Characteristics of protocol
2.6.1.1 Simplicity — the case for light-weight protocolsA well-structured protocol can be built from a small number of well-designed and
well-understood pieces. Each piece performs one function and performs it well. To
understand the working of the protocol it should suffice to understand the working of the
pieces from which it is constructed and the way in which they interact. Protocols that are
designed in this way are easier to understand and easier to implement efficiently, and they are
more likely to be verifiable and maintainable. A light-weight protocol is simple, robust, and
efficient. The case for light-weight protocols directly supports the argument that efficiency
and verifiability are not orthogonal, but complementary concerns.
2.6.1.2 Modularity — a hierarchy of functionsA protocol that performs a complex function can be built from smaller pieces that
interact in a well-defined and simple way. Each smaller piece is a light-weight protocol that
can be separately developed, verified, implemented, and maintained. Orthogonal functions are
not mixed; they are designed as independent entities. The individual modules make no
assumptions about each other’s working, or even presence. Error control and flow control, for
instance, are orthogonal functions. They are best solved by separate light-weight modules that
are completely unaware of each other’s existence. They make no assumptions about the data
stream other than what is strictly necessary to perform their function. An error-correction
scheme should make no assumptions about the operating system, physical addresses, data
encoding methods, line speeds, or time of day. Those concerns, should they exist, are placed
in other modules, specifically optimized for that purpose. The resulting protocol structure is
open, extendible, and rearrangeable without affecting the proper working of the individual
components.
2.6.1.3 Well-formed protocolsA well-formed protocol is not over-specified, that is, it does not contain any
nreachable or unexecutable code. A well-formed protocol is also not under-specified or
34
incomplete. An incompletely specified protocol, for instance, may cause unspecified
receptions during its execution. An unspecified reception occurs if a message arrives when the
receiver does not expect it or cannot respond to it. A well-formed protocol is bounded: it
cannot overflow known system limits, such as the limited capacity of message queues. A
well-formed protocol is self-stabilizing. If a transient error arbitrarily changes the protocol
state, a self-stabilizing protocol always returns to a desirable state within a finite number of
transitions, and resumes normal operation. Similarly, if such a protocol is started in an
arbitrary system state, it always reaches one of the intended states within finite time. A well-
formed protocol, finally, is self-adapting. It can adapt, for instance, the rate at which data are
sent to the rate at which the data links can transfer them, and to the rate at which the receiver
can consume them. A rate control method, for instance, can be used to change either the speed
of a data transmission or its volume.
2.6.1.4 RobustnessIt is not difficult to design protocols that work under normal circumstances. It is the
unexpected that challenges them. It means that the protocol must be prepared to deal
appropriately with every feasible action and with every possible sequence of actions under all
possible conditions. The protocol should make only minimal assumptions about its
environment to avoid dependencies on particular features that could change. Many link-level
protocols that were designed in the 1970s, for instance, no longer work properly if they are
used on very high speed data lines (in the Gigabits/sec range). A robust design automatically
scales up with new technology, without requiring fundamental changes. The best form of
robustness, then, is not over-design by adding functionality for anticipated new conditions,
but minimal design by removing non-essential assumptions that could prevent adaption to
unanticipated conditions.
2.6.1.5 ConsistencyThere are some standard and dreaded ways in which protocols can fail. We list three of
the more important ones. Deadlocks — states in which no further protocol execution is
possible, for instance because all protocol processes are waiting for conditions that can never
be fulfilled.
Livelocks — execution sequences that can be repeated indefinitely often without
ever making effective progress.
Improper terminations — the completion of a protocol execution without
satisfying the proper termination conditions.
35
2.6.1.6 Ten rules of designThe principles discussed above lead to ten basic rules of protocol design.
1. Make sure that the problem is well-defined. All design criteria, requirements and
constraints, should be enumerated before a design is started.
2. Define the service to be performed at every level of abstraction before deciding which
structures should be used to realize these services (what comes before how).
3. Design external functionality before internal functionality. First consider the solution as a
black-box and decide how it should interact with its environment. Then decide how the
black-box can internally be organized. Likely it consists of smaller black-boxes that can
be refined in a similar fashion.
4. Keep it simple. Fancy protocols are buggier than simple ones; they are harder to
implement, harder to verify, and often less efficient. There are few truly complex
problems in protocol design. Problems that appear complex are often just simple problems
huddled together. Our job as designers is to identify the simpler problems, separate them,
and then solve them individually.
5. Do not connect what is independent. Separate orthogonal concerns.
6. Do not introduce what is immaterial. Do not restrict what is irrelevant. A good design is
‘‘open-ended,’’ i.e., easily extendible. A good design solves a class of problems rather
than a single instance.
7. Before implementing a design, build a high-level prototype and verify that the design
criteria are met.
8. Implement the design, measure its performance, and if necessary, optimize it.
9. Check that the final optimized implementation is equivalent to the high-level design that
was verified.
10. Don’t skip Rules 1 to 7.
The most frequently violated rule, clearly, is Rule 10.
Design and validation of computer protocol by Gerard J. Holzmann Bell Laboratories
Murray Hill, New Jersey 07974
Verification using spin
36
2.7 Authentication Method and Attacks on Protocol
security of the system at various levels, both for off-line and on-line transaction in
CEPS, Authentication and security mechanism is clearly stated in CEPS for purchase
transaction between CEP Card and POS Terminal. Authentication and security of the
transaction between Merchant and merchant acquirer are kept at the implementers decision.
Transaction between merchant and merchant acquirer is off line transaction and
attempt is made here to solve the problem by giving innovative design for this transaction for
requirements in Indian payment system stated in section 2.5
Two-way, or mutual, authentication must be performed for off-line transactions is the
general requirement in CEPS,
37
Reference
1. http://www.cardwerk.com/smartcards/smartcard_history.aspx
2. http://www.exibitionindia.org/smart-industryupdate.html
3. http://www.mit.gov.in/smartcard/index.asp
4. C. Cormier and G. Grimonprez, “A RISC Microprocessor for Contactless Smart Cards”,
23rd EUROMICRO Conference '97, New Frontiers of Information Technology,
September 01 - 04, 1997, Budapest, HUNGARY, page 658
5. http://www.dice.ucl.ac.be/crypto/cascade/description.html
6. James Goodman, and Anantha P. Chandrakasan, “An Energy-Efficient Reconfigurable
Public-Key Cryptography Processor”, IEEE Journal Of Solid-State Circuits, Vol. 36, No.
11, November 2001, page 1808-1820
7. Grossschadl, J., “Instruction Set Extension for Long Integer Modulo Arithmetic on RISC-
Based Smart Cards”, 14th Symposium on Computer Architecture and High Performance
Computing (SCAB-PAD'02), October 28 - 30, 2002, Vitoria, ES, Brazil, page 13 -19
8. http://www.st.com/stonline/press/news/year2002/p1249m.htm, STMicroelectronics
Debuts World's Most Advanced Smart Card Memory Technology New "Page Flash"
technology will benefit Mobile Access Networks and Mobile Multimedia Services,
Geneva, November 5, 2002 - STMicroelectronics (NYSE: STM)
9. Damien Deville, Antoine Gallandz, Gilles Grimaud and Sebastien Jean, “Assessing the
Future of Smart Card Operating Systems”, Proceedings of e-smart 2003 conference on
Future of smart card, September 17 - 19, 2003 at Sofia Antipolis, France Rivera.
10. Damien Deville, Antoine Galland, Gilles Grimaud, and Sebastien Jean, “Smart Card
Operating Systems: Past, Present and Future”, Fifth USENIX/NordU Conference,
Vasteroas, Sweden, February 10–14, 2003.
11. Gregory Bussard, “Next generation JAVA card Frame work”, In 4th Gemplus Developer
Conference, Singapore, November 12-14, 2002
12. Laurent Lagosanto, “Next-generation embedded Java operating system for smart cards” ,
In 4th Gemplus Developer Conference, Singapore, November 12-14, 2002
13. S.K.Sinha,, “SCOSTA – An implementation of ISO-7816 Security Model”, Proceedings
of e-smart 2003 conference on Future of smart card, September 17 - 19, 2003, Sofia
Antipolis, France Rivera
38
14. Pierre Paradinas and Jean-Jacques Vandewalle, “New directions for integrated circuit
cards operating systems”, ACM SIGOPS Operating Systems Review archive, Volume 29 ,
Issue 1 (January 1995) , ISSN:0163-5980, ACM Press New York, NY, USA, pages: 56 –
61,
15. ISO/IEC 7810, Defines the characteristics of the plastic card (card dimensions, toxicity of
plastic etc) on which smart card chip id bounded.
16. ISO/IEC 7816-1:1998 Identification cards -- Integrated circuit(s) cards with contacts --
Part 1: Physical characteristics
17. ISO/IEC 7816-2:1999 Information technology -- Identification cards -- Integrated
circuit(s) cards with contacts -- Part 2: Dimensions and location of the contacts
18. ISO/IEC 7816-3:1997 Information technology -- Identification cards -- Integrated
circuit(s) cards with contacts -- Part 3: Electronic signals and transmission protocols
19. ISO/IEC 7816-4:1995 Information technology -- Identification cards -- Integrated
circuit(s) cards with contacts -- Part 4: Interindustry commands for interchange
20. ISO/IEC 7816-5:1994 Identification cards -- Integrated circuit(s) cards with contacts --
Part 5: Numbering system and registration procedure for application identifiers
21. ISO/IEC 7816-6:1996 Identification cards -- Integrated circuit(s) cards with contacts --
Part 6: Interindustry data elements
22. ISO/IEC 7816-7:1999 Identification cards -- Integrated circuit(s) cards with contacts --
Part 7: Interindustry commands for Structured Card Query Language (SCQL)
23. ISO/IEC 7816-8:1999 Identification cards -- Integrated circuit(s) cards with contacts --
Part 8: Security related interindustry commands
24. ISO/IEC 7816-9:2000 Identification cards -- Integrated circuit(s) cards with contacts --
Part 9: Additional interindustry commands and security attributes
25. ISO/IEC 7816-10:1999 Identification cards -- Integrated circuit(s) cards with contacts --
Part 10: Electronic signals and answer to reset for synchronous cards
26. ISO/IEC 7816-11:2004 Identification cards -- Integrated circuit cards -- Part 11: Personal
verification through biometric methods
27. ISO/IEC 7816-15:2004 Identification cards -- Integrated circuit cards with contacts -- Part
15: Cryptographic information application
28. V. Cordonnier, C. Cormier, and G. Grimonprez, “Picorisc:A risc approach for smart
cards”, Euromicro Proceedings, September 1995. Como, Italy
39
29. Hardware and software symbiosis helps smart card evolution
30. MASSC A Generic Architecture for Multi Application Smartcard
31. Gilles Grimaud, Jean-Louis Lanet, and Jean-Jacques Vandewalle, “FACADE: A Typed
Intermediate Language Dedicated to Smart Cards”, In Software Engineering–ESEC/FSE,
volume 1687 of LNCS, 1999.
32. 2_32_europay-maos-report
33. 2_33_CYBERFLEX™ ACCESS Java Programmeble smart card
34. 2_34_Formal Development of an Embedded Verifier for Java Card Byte
35. 2_35_Increasing Smart Card Dependability
36. 2_36_building-an-impossible-verifier on java card
37. 2_37_application programers reference mannual
38. Lynch D C and Lundquist L Digital money: The new era of Internet commerce Wiley,
1996.
39. 2_39_NetCash-A design for practicle electronic currency on internet
40. 2_40_Classification and Characteristics of Electronic Paymet Systems
41. E. Becker et al. (Eds.): Digital Rights Management, LNCS 2770, 2003,page no. 113–137,
Springer-Verlag Berlin Heidelberg 2003
42. N. Asokan, Phillipe A.Janson, Michael Steiner, Michael Waidner, “The State of the Art in
Electronic Payment Systems” IEEE Computer, Volume: 30, Issue: 9, September 1997,
page 28-35
43. Common Electronic Purse Specification, Business Requirements, Version 7, March,
2000,Copyright CEPSCO 1999
44. Common Electronic Purse Specifications, Functional Requirements, Version 6.3,
September 1999, Copyright CEPSCO 1999
45. Common Electronic Purse Specifications, Technical Specification, Version 2.3, March
2001, Copyright CEPSCO 1999, 2000, 2001.
46.
40
