Academia.eduAcademia.edu

Secure Smart-card Technologies used in e-Commerce

Profile image of Catalin BojaCatalin Boja

SAMPLE DEVELOPMENT ON JAVA SMART-CARD …

Abstract
sparkles

AI

The paper provides a comprehensive overview of secure smart-card technologies utilized in e-commerce, highlighting different classifications of smart cards based on communication methods and integrated circuits. It discusses the importance of project management in e-commerce, emphasizing integration management and the essential project management knowledge areas including scope, time, cost, and risk management. Key technologies and tools for effective project management are identified, asserting the significance of a structured approach in enhancing communication and project effectiveness.

Figures (34)
In figure 1 is depicted a complete Java card application:
In figure 1 is depicted a complete Java card application:
The methods by which the applet life cycle is realized and that the applet shoulc implement are presented in figure 4: 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. be ed Ee oy po may rey ee a rn woe OF Oe a a! | a ro TD oe een Oe oS ee’ py ee ee pe |
The methods by which the applet life cycle is realized and that the applet shoulc implement are presented in figure 4: 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. be ed Ee oy po may rey ee a rn woe OF Oe a a! | a ro TD oe een Oe oS ee’ py ee ee pe |
Practically, for the Wallet-electronic wallet application, there are given several models o APDU Commands designed by those who wrote the source code of the applet: « PIN verification 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;
Practically, for the Wallet-electronic wallet application, there are given several models o APDU Commands designed by those who wrote the source code of the applet: « PIN verification 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;
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 O 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;
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 O 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;
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.
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.
ANNEX 1: Source code of electronic wallet applet for Java Card platform
ANNEX 1: Source code of electronic wallet applet for Java Card platform
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 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 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. 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.
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. 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.
The authentication and card access procedure is presented in figure 4:
The authentication and card access procedure is presented in figure 4:
Fig.4 Card Access and Authentication Procedure [1]
Fig.4 Card Access and Authentication Procedure [1]
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. 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.
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. 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.
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.
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.
Fig.10 Access Bits combination for value block access [1] The figure 10 specifies the access bits conditions for data blocks in value mode (C1j, C2;, C3; where i = 0,1,2).
Fig.10 Access Bits combination for value block access [1] The figure 10 specifies the access bits conditions for data blocks in value mode (C1j, C2;, C3; where i = 0,1,2).
Figure 11 specifies the access bits conditions for trailer blocks (C13, C23, C33). 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).
Figure 11 specifies the access bits conditions for trailer blocks (C13, C23, C33). 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).
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. 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.
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. 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.
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.
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.
For details regarding cryptographic algorithms and encryption/decryption mechanism please consult [TOMA06] and [TOMAO8]. 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:
For details regarding cryptographic algorithms and encryption/decryption mechanism please consult [TOMA06] and [TOMAO8]. 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. 2. Steps used in dual signatures
Fig. 2. Steps used in dual signatures
Fig. 3. Payment request by cardholder
Fig. 3. Payment request by cardholder
Fig 4. Verification process by merchant
Fig 4. Verification process by merchant
Fig. 1. E-Cash payment system architecture The E-Cash architecture is depicted in figure 1:
Fig. 1. E-Cash payment system architecture The E-Cash architecture is depicted in figure 1:
Fig. 3. E-Cash secured algorithm
Fig. 3. E-Cash secured algorithm
It is the project manager’s duty to balance these three often competing goals. The idea of this constrains is depicted in figure 1:
It is the project manager’s duty to balance these three often competing goals. The idea of this constrains is depicted in figure 1:
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:
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:
The system architecture is shown in figure 1. User authentication
The system architecture is shown in figure 1. User authentication
Fig. 2. Balance sheet submission flow
Fig. 2. Balance sheet submission flow
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.
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.

Key takeaways

  • In the following sections will be implemented step by step an electronic wallet implemented on a smart card as a Java card applet.
  • A Java card application is an applet which is running in smart card.
  • 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.
  • 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.
  • 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.

Related papers

Software and Hardware Issues in Smart Card Technology
Apostolos Fournaris

IEEE Communications Surveys & Tutorials, 2009

An efficient and strongly secure smart card mechanism involves the use of a technological background taken from the fields of computers, VLSI design and material science. The result of such a mixture is a miniature, fully operational, computation system. The nature of the data involved in smart card transactions and smart card intended uses, introduce another important factor in the smart card design mechanism which is security. The evolution of VLSI technology allows the efficient implementation of costly cryptographic operations in the smart card design methodology. Apart from the traditional cryptographic algorithms, additional techniques and special design materials have been introduced in order to protect the smart card system from cryptanalytic attacks. New architectures of software design, like object-oriented programming, give the opportunity to implement programmable multi-application cards. Thus, smart cards are transformed into highly secure devices and their establishment in the modern computer market can be considered certain. This establishment is bound to finance upcoming research in smart cards so that this product can become the basic component of electronic commerce worldwide.

View PDFchevron_right
2nd Smart Card Research and Advanced Application (CARDIS)
Jean-jacques Quisquater

1996

View PDFchevron_right
Smart Card Security
Damien Sauveron

2007

View PDFchevron_right
Smart Cards - Present and Future1
Berta István
View PDFchevron_right
C2OS, A New Cryptographic Operating System for Smart Cards
Hisham Dahshan

The International Conference on Electrical Engineering

Smart card is a miniature computer with very limited hardware and software resources. Like any computer, an operating system is needed to manage the card hardware and software resources. Several smart card operating systems of different types were developed for this purpose. The basic functions of these operating systems are: handling the card input/out process, managing the file system, managing communication with card users/ application programs and data exchange with the cryptographic algorithms embedded in the card, if any. The user/application is allowed to interact with cryptographic algorithms with their default parameters and with no possibility of cryptographic parameters customization. This paper aims to make the smart card smarter by presenting a new type of smart card operating system that covers a new area of commands. The new set of cryptographic commands enables the applications/developer to deeply access the cryptographic primitives and customize their building blocks at run time. In order to test the new command set and demonstrate its features, the new operating system has been developed in embedded C language and implemented on an open platform card. Smart Card, Operating System, Cryptographic Primitives. Today, smart cards are widely used in our daily life. Their technology is being used in many fields like: credit cards, passports, health cards, ID cards, driving licenses, SIM cards for mobile phones, etc. Smart cards are originally known as integrated circuit cards (IC cards). The reason for naming IC cards with smart cards is that the card functions are not limited to those functions defined only at build time. The set of card functions could be extended in run time according to the system they work in and also according to user requirements. Smart cards with processor chip need an operating system known as Card Operating System (COS). The basic functions of COS are: managing the card resources, and enabling instructions execution and communication with the outer world. A variety of card operating systems have been developed. * Egyptian Armed Forces.

View PDFchevron_right