As we mentioned earlier, one obstacle blocking widespread use of smart cards in U.S. markets has been the large number of incompatible and often obscure development languages available for writing smart card applications. Regardless of the ISO 7816 specifications, programming languages for smart cards have traditionally amounted to special-purpose assembly languages. Few developers were familiar with card application languages, the upshot being that only a handful of people could develop smart card code. As cards become computationally more powerful, new application languages are being designed and put into use. One of the most interesting new systems is Java Card 2.x (see www.javasoft.com/products/javacard/index.html).
The problem of multiple, noninteroperable platforms is not limited to smart cards, of course. A major part of Java's appeal is that it was designed as a cross-platform solution. Developers have always wanted a solution to the platform problem (other than the adoption of one single proprietary platform controlled by a monopoly). Java is one good way of addressing the platform problem on smart cards.
A Java card is a smart card that is able to execute Java byte code, similar to the way Java-enabled browsers can. But standard Java with all of its libraries (especially in the Java 2 guise) is far too big to fit on a smart card. A solution to this problem is to create a stripped-down flavor of Java. Card Java is just such a flavor. It's based on a subset of the Java API plus some special-purpose card commands.
Besides providing developers with a more familiar development environment, Card Java also allows smart cards to have multiple applications on them. For the most part, existing smart card products (especially in the financial arena) have only one application per card. This application is automatically invoked when power is provided to the card or the card is otherwise reset. The one-application-per-card paradigm doesn't scale well, to say the least. Who wants to carry 20 credit cards around? Card Java can solve this problem by allowing multiple applications, potentially written by different organizations, to exist on the same card. The idea of multiple applications running on the same VM by potential competitors raises a number of security issues, which we address later in the chapter.
Evolution of Smart Cards:
1878 American Ed Bellamy predicts that by 2000 all transactions will be by credit card
1888 American Express launches a pre-paid newspaper stamp
1901 Conrad Merciers card provides access to public telephones
1918 Western Union provides a metal company card to be used as proof of identity
1951 Diners Club uses pre-paid paper booklet to pay hotel and restaurant bills
1958 American Express launches a paper bank (later plastic) card.
1967 Clients of Societe Marseillaise use a punch card to withdraw cash.
Europay launch their Carte d'or.
First Magnetic Stripe card launched in France for access control.
1974 Robert Morena files a patent for a secure portable electronic device in France.
1980 Historic birth of the chip-based card in France.
The rest is history
Tokyo's 16 million Sica rail cards serve a commuter population of 59 million travelling
between about 500 stations. High transaction speeds are essential with peak passenger
volumes of about 60 passengers / minute / gate. The processing time for a Smart Card to
read / authenticate / transact is 0.1 sec or 106 kbps.
London deployed the Oyster Smart Cards for its groundbreaking London transport
ticketing and payment program, to speed the movement of ticket holders in a system that
services around 6 million passengers a day, and as such set a model for urban travel in
the 21st century.
Traffic Management Branch, eThekwini Transport Authority,
PO Box 680, Durban, 4000.
Smart card is a plastic card with an IC embedded in it, where it is difficult to copy or forge the chip. Hence smart cards are known as tamper resistant device, which can involve in automated electronic transactions, can store data securely and run/host wide range of security protocols and algorithms.
Smart cards were introduced in Europe two decades ago, to protect the theft happening from pay phones. The primary smart cards were memory cards where they were used to store only critical information.
4. Smart Card Technology
This chapter tells about the technology growth of smart cards, particularly this chapter speaks about the Java card technology which is used in most of the smart cards to develop and run applications. This chapter is emphasized on the technical details of the Java card technology.
4.1 Java Technology
Java Technology consists of a Java programming language and a Java platform.
Java programming language is a high level language, which is simple, object oriented, distributed, architecture neutral, portable, robust, secure, multithreading and dynamic [Sun01].In Java programming language the source code is written in plain text files ending with .java file then this file is compiled by using a javac compiler to get .class file, which is in the form of
bytecodes that can be interpreted by the Java Virtual Machine (JVM).
Figure showing MyProgram.java, compiler, MyProgram.class, Java VM, and My Program running on a computer.
A platform is hardware or software environment where a coded program can run. The Java platform consists of two parts
The Java Virtual Machine (JVM)
The Java Application Programming Interface (API)
Today Java has become so popular that they have started developing applications beyond their scope (WWW environment) and are running successfully. Presently there are different flavours of the Java platform: Java SE, Java Embedded, Java EE, Java ME, Java FX, Java DB and Java Card.
Java ME (J2ME) is the Java 2 Micro Edition used for wireless application (to develop and run applications on hand held mobile phones).
Java Card platform is a subset of Java language which is used for developing and running applications securely on smart cards and other memory and processing constrained devices.
Java Intro 2002 Qusay H.Mahmoud
The Java Language Environment; James Gosling and Henry McGilton
4.2 Java Card Technology
Java card technology offers a very good environment to run applications written in Java programming language on smart cards and other memory constrained devices. The Java card technology provides many advantages for application developers: Ease of application development, Hardware independence, Security and ability to store and manage multiple applications.
As we know that smart cards are the smallest computing
platform that are in use today. The memory configuration of a typical smart card would be in the form of 1K of RAM, 16K of EEPROM and 24K of ROM.
The role of Java card technology is to fit the entire Java platform into this smallest memory by conserving space to run applications. The solution for this is to use only the subset of Java programming language and implement the split model of the Java Card Virtual Machine (Java Card Virtual Machine).The Java Card Virtual machine is split into two parts: one that runs off the card and the one that runs on the card.
Java card technology defines a Java Card Runtime Environment (JCRE) that supports smart card memory, communication and application execution model. The JCRE provides a clear separation between the smart card system and applications. The JCRE conforms to the smart card international standard ISO 7816.
4.3 Java Card Virtual Machine
The main functionality of a Java Card virtual machine is to load the class files and execute them by using a particular semantics. The difference between the Java Card virtual machine and Java Virtual machine is that the Java Card virtual machine is implemented in two parts: the off-card section and the on-card section.
The off-card section consists of a converter whose responsibility is to convert the pre-processed class files into a package and produce a Converted Applet (CAP) file. Usually the off-card part runs on a PC or work station. The on-card part of the Java Card virtual machine consists of a byte code interpreter. The CAP file which was produced by the converter is loaded on to the Java smart card and is executed by the interpreter.
4.3.1 CAP file
The Java Card technology is said to be platform independent hence two new binary file formats are defined for the development, distribution and execution of Java Card software. One of such file format is the CAP file (Converted Applet). CAP file contains an executable binary representation of the classes in a Java package. The CAP file contains a JAR file format as a container format hence a CAP file is a JAR file that contains a set of components, each stored in an individual JAR file. Each file describes some aspect of CAP file contents such as class information, executable bytecodes, linking information, verification information and so on.
The Java platform has a unique feature, where the Java programs can be written only once and can be run anywhere whenever it is necessary. The class files play a very crucial role in Java card technology, which is the central piece of the Java architecture and it defines the standard for the binary compatibility of the Java platform. From the definition of Java card we know that the Java card architecture characteristics are distributed, the CAP file sets a standard file format for binary compatibility of the Java card platform. Hence the only file format by which the software can be loaded on to the Java smart cards is the CAP file format. For example CAP files can enable dynamic loading of the applet classes after the card has been made. That is how it gets the name converted applet (CAP) file.
4.3.2 Export file
During the conversion of CAP files from the .class files the converter produces another kind of file know as export file, which represents that the public API of the package been converted. The Export files are not loaded on to the smart card and thus they are not directly used by the interpreter. Export files are generated and consumed only by the converter for verification and linking purposes. The export file defines the access scope and name of the class and access scope and signatures of the methods and fields of the class. As we said it also contains verification information for resolving interpackage references on the card. Since the Export file does not contain any implementation details (bytecodes), it can be freely distribute by the applet developer without revealing the internal implementation details.
4.3.3 Java Card Converter
4.3.4 Java Card Interpreter
4.3.5 Java Card Installer
4.3.6 Off card Installation Program
4.4 Java Card Runtime Environment
4.4.1 JCRE Lifetime
4.4.2 JCRE Operation during Communication
4.4.3 Java Card Runtime Features
4.5 Java Card API's
4.5.1 Java.lang Platform
4.5.2 Javacard.framework Package
4.5.3 Javacard.security Package
4.5.4 Javacardx.crypto Package
4.6 Java Card Applets
4.6.1 Applet Naming Conventions
4.6.2 Applet Development Process
4.6.3 Applet Installation and Execution
4.6.4 Applet Communication