SMART CARDS .1 History

Today one of the greatest objectives in the computer field is that of mobile computing, trying to bring the usefulness of computers on the go. Some obvious examples of this are PDAs, laptops and smart-phones that offer to their users the ability to load their most important programs and data wherever they are. But one of the most widespread methods for mobile computing is the smart card. Smart cards are different from the more traditional mobile devices in the sense that they work locally, keeping the information and programs always accessible for the user [45]. The smart cards are already being widely used in Europe and USA where they are being employed to store information about medical history or bank account of the owner. But the smart cards proponents aim higher, with the objective to be a centralized medium of information, where it would store all the data about its owner (not only medical and bank info, but also driver license, ID, etc), and eventually all we would need would be just one card that would replace the half-dozen cards that we carry in our wallet nowadays.

The term smart card usually refers to a plastic card (of the size of a credit card) with a chip that holds a micro-processor and a data storage unit. The development on smart cards started back in the 60s, where, in 1968, two German inventors patented their idea of using plastic cards as a carrier for micro chips, but it was not until 1976 that the industry was capable of producing such cards with an acceptable price. In 1981 the first field experiments were conducted around the globe using banks, telepayment and identification cards, among other projects. After that the smart cards usage spread fast with companies like MasterCard, Visa and France T´el´econ adopting it. Today, smart cards are used in a wide variety of applications ranging from building access systems to

18

electronic payment schemes, from conditional access methods for satellite TV to electronic signature applications, and from loyalty programs to public transportation applications [38], not to mention the use of them in the current GSM mobile phones in the form of SIM cards [66].

As defined in [73] the smart cards can fit into three possible categories, these being:

Memory cards are cards that possess a chip that can store an average of 4KB of in-formation, but do not have a processor inside it. Because of the absence of a processor they must be used with an external reader to access these data and per-form the required operations. The typical usage of memory cards is with pre-paid disposable-cards, like phone cards;

Optical memory cards look like a CD glued on top of a card and can store an average of 4MB of data. As CD-Rs, once the data is written it can not be erased. It main usage is to keep non-changeable information, like medical or driving records;

Microprocessor cards are the ones that are really “smart”, since they do not have just a memory chip, but also a processor that can perform operations on the data stored on the card.

In the rest of our work, we will be focusing on microprocessor cards, and whenever we say smart card we will be referring to them. In the next sections we will present some more details about this kind of card, showing its components, its limitations and the standards that guide the industry of smart cards.

2.1.2 Characteristics of smart cards

A microprocessor smart card differentiates itself from the traditional magnetic strip card and memory card in the sense that while the latter is used just to store information, the former can make computations on that information. The microprocessor card can add, delete, and manipulate information on the card, while a memory-chip card can only undertake a pre-defined operation [38, 73].

The main components of a smart card are: an operating system that controls access to the card’s data and functions; data stored in EEPROM; and RAM for transient results.

Typically, the CPU of choice was old 8 bits processors, but nowadays some cards are already shipping with 16 or 32 bits, RISC or CISC CPUs [19]. Some smart cards also offer additional features, such as fingerprint sensors, wireless interface, or even displays. Some cards will not even appear to be a card, such as the JavaRing [38]. The main constraints we face when dealing with these devices are the low-power CPU, low throughput serial I/O and little memory (typically 1-4 KB RAM, 32-128 KB ROM and 16-64 KB Flash RAM) [18].

The use of smart cards is beneficial over traditional magnetic strip cards specially when dealing with secure data. Typically the cards ship with a cryptographic co-processor, that is used to ensure the security of the data through the use of crypto algorithms (such as DES and RSA) [66]. As said above smart cards can ship with a fingerprint sensor that

may be used in authorization process, such as building access. They can also be contact or contactless. Contact smart cards work by communicating via physical contact between a card reader and the smart card. Contactless smart cards communicate using a radio frequency signal, with a typical range of less than 2 feet [66].

Smart cards do not contain any battery and become active just when inserted in a card reader. When in the reader, the smart card initializes itself and stays in a passive mode waiting to receive a command from the reader (these commands are transferred using the APDU protocol that will be presented in Section 2.1.4). After it receives the command, it makes the necessary processing and sends back the result to the reader.

The typical participants in the life cycle of a smart card are illustrated in Figure 2.1, and are [18]:

Semiconductor manufacturers are in charge of chip design and mass production;

Smart card manufacturers are associated here with smart card software producers and are responsible for embedding issuers’ requirements;

Card issuers traditionally have more business/behavioral considerations while deploy-ing and managdeploy-ing smart card-based solutions;

Service providers design and deploy (under the control of issuers) value-added services;

and

Users benefit from those services.

Figure 2.1. Smart card production life cycle (from [18]).

The first smart cards were developed as monolithic systems, that is, all the require-ments for its functionality were already embedded during manufacturing and there was no possibility of reuse. This approach incurred high maintenance costs, and, with the years, the developers came to see that the best approach was to make the cards as modular as possible and add the possibility to do post issuance, that is, to add new functionalities to the card after it has been shipped. This kind of cards usually rely on a virtual machine, both for portability (a single application can be loaded into several different cards, i.e.

relying on different hardware, without needing to be modified) and for security (it is usually easier to prove or ensure the safety with intermediate codes) [18]. With these ideas in mind the life cycle of the smart card software can be seen in Figure 2.2 with each stage described as follows [18]:

Produce & Load: enclose the software from the moment that it is produced (using any methodologies/language necessary) until it is downloaded into the card;

Init/Instantiate: is done after the download, depending on the nature of the application (ready-to-run or ready-to-load applications). With this, the application registers itself on the card, and makes any necessary initializations (since the card is always running it is done only once);

Use: after that the application is ready for use by the client.

Figure 2.2. Life cycle of the smart card software (from [18]).

2.1.3 Standards

One of the most known problems for the wide acceptance of smart cards was the lack of a standard. When the smart cards started being mass commercialized, an application developed to run in one card could not run on the other without having to be rewritten from scratch. This is a great problem when considering that if the smart cards are really intended to be used as a unique device for all companies, there should be a standardization for the cards and on the software/platform in which they will run.

The main standards used today come from the International Organization for Stan-dardization (ISO). Those standards rule nearly all smart card features from physical char-acteristics to application management. These standards are under the name of ISO7816-x and cover physical characteristics (ISO 7816-1); contact location and dimension (ISO 7816-2); and electrical signals along with low-level transport (ISO 7816-3) and high-level application (ISO 7816-4) communication protocols (the APDU protocol that will be ad-dressed later). The ISO7816 also addresses other issues such as numbering systems and registration procedures for smart-card applications, taglength-value data structures, en-hanced smart-card commands (mutual authentication, SQL access, and encryption), and more [38, 18, 73].

But the ISO is not the only standard that is on the market, there are also others, such as that from European Telecommunications Standards Institute, Groupe Sp´eciale Mobile subscriber identity module (GSM SIM), EMV Payment System specification by Europay, MasterCard, and Visa, Visa’s Open Platform specification and the international Common Electronic Purse Standard (CEPS) [38, 73].

2.1.4 The APDU protocol

The Application Protocol Data Units (APDU) is defined by ISO7816-4 and is the com-munication format between the card and the outside world (usually a terminal reader).

The communication happens in a client-server like manner, where the card reader sends the requests for the smart card, which in turn processes the request and answers accord-ingly. There are two categories of APDUs: command APDUs and response APDUs. The

former is sent by the reader to the card when requesting an operation, and the latter is sent by the card to the reader in response to the request (if no error occurs the card should always send a response APDU, even if it contains no data) [32].

The structure of the command APDU is shown in Figure 2.3. As seen in the figure, the first four fields are always mandatory and their representation is as follows [66]:

CLA (1 byte, required): identifies an application-specific CLAss of instructions. Valid CLA values are defined in the ISO 7816-4 specification:

0x0n, 0x1n: ISO 7816-4 card instructions, such as for file access and security operations

20 to 0x7F: Reserved

0x8n or 0x9n: ISO/IEC 7816-4 format you can use for your application-specific instructions, interpreting ’X’ according to the standard

0xAn: Application- or vendor-specific instructions

B0 to CF: ISO/IEC 7816-4 format you can use for application-specific instruc-tions

D0 to FE: Application- or vendor-specific instructions FF: Reserved for protocol type selection

INS (1 byte, required): indicates a specific INS truction within the instruction class identified by the CLA field (a table showing the possible INS when CLA is 0x0n is shown in [66]).

P1 (1 byte, required): defines a P arameter (1 ) for the instruction, used to qualify the INS field, or for input data.

P2 (1 byte, required): defines an additional P arameter (2 ) for the instruction, used to qualify the INS field, or for input data.

Figure 2.3. Command APDU (from [66]).

The next three fields are optional and are used when there is need to exchange data with the card. They are defined as follows:

Lc (1 byte, optional): the Length (in bytes) of the data field of the command;

Data field (variable, Lc number of bytes, optional): holds the command data.

Le (1 byte, optional): the maximum Length (in bytes) of the data field of the expected response.

The response APDU format is given in the Figure 2.4 and has two required fields and one optional. Their meanings are the following:

Data field (variable length, determined by Le in the command APDU, optional):

contains the data returned by the applet.

SW1 (1 byte, required): the S tatus W ord 1.

SW2 (1 byte, required): the S tatus W ord 2.

The value of the status words varies depending on the result of the computation, so to indicate if the operation terminated normally or if an error happened. A representation of the possible values for SW1 and SW2 is given in Figure 2.5.

Figure 2.4. Response APDU (from [66]).

Figure 2.5. Status Words response code (from [66]).

All cards developed nowadays are supposed to follow this standard if they want to guarantee interoperability. But this is not enough, since the ISO standards do not define anything about the software that will be used on the cards. This is where JavaCard comes into play and shows itself as a solid and versatile approach, offering all the power of the Java language to the development of smart cards applications. In the next sections we will give a brief overview of the history and functionalities of JavaCard.

2.2 JAVACARD 2.2.1 History

The adoption of the Java technology in the smart card market has been pushed over the years because of the advantages that it would bring, such as giving the ability to the well established Java community to quickly start developing smart card applications, the possibility to download new “applets” (as JavaCard programs are known) to an already issued card (post-issuance), not to mention Java portability and security. These factors have made Java the language of choice to extend the smart cards possibilities, even considering that it is an interpreted language and could slow down the system [3, 73].

The history of JavaCard [3, 73] begins in 1996 when the first steps to bring the Java technology to smart cards were taken, with the first JavaCard API specification being given by Sun based on the work made by Schlumberger [3, 62]. This first JavaCard Specification was limited only to the description of the general goals and the architecture of JavaCard. In the next year Gemplus and Schlumberger joined forces and founded the JavaCard forum. Still in this year smart card manufacturers such as De La Rue, Bull, and Gieseke & Devrient (G&D) joined the forum and released the version 2.0 of JavaCard specification at the end of 1997. This new version of the specification was a lot more detailed since it contained more details about the API, such as how to access the underlying memory and cryptographic functions and the JavaCard Virtual Machine (JCVM), a smaller and simpler JVM that sheds many of standard Java’s features. Even then the first release of version 2 was still incomplete in the sense that lots of details were still missing leaving most of the design decisions still in the hands of the developers. The result of this was that lots of applets were still incompatible, even at source code level [3].

In 1998 Visa introduced the Visa Open Platform (VOP) smart card specification, defining an architecture for managing applications on multi application smart cards (that is, the possibility to download and install an applet in a secure way). Since the beginning this platform was aimed to the JavaCard products and with security in mind. When, in 1999, Visa opened this standard and renamed it to Open Platform 2.0 neither Sun nor the JavaCard forum had any security platform specified, so Visa’s Open Platform was chosen as the de facto standard for the matter [3].

In 1999, when Sun introduced the JavaCard 2.1 specification, it offered the support for byte code verification using the scheme of code signing [3]. Even then Sun did not claim to completely trust this method and introduced the use of software firewalls. With this, objects are explicitly associated with their owning applets, and additional checks are done in the JCVM to ensure proper access rights for each object. In this version security was also a concern with the cryptographic API being extended to numerous classes. Also, for the first time, any applet could run in any smart card that was compliant with the JC2.1 specification using Converted Applets (CAP).

The newest release of JavaCard is version 2.2.1 [77] and it highlights improvements like support for wireless products, improved memory management and next-generation security enhancements, among others. According to current researches JavaCard should

continue to be the dominating technology with respect to high-end microprocessor-based smart cards [33]. To follow this increasing demand there is already work on the specifica-tion of JavaCard 3.0 that aims to bring the JavaCard technology closer to the standard Java. The objective with this is to make a better use of the new hardware technologies (32 bits processors), to enable a wider development of JavaCard by developers already famil-iar with standard Java and to bypass the bottleneck of the specific smart card ISO7816 communication protocols [33].

2.2.2 JavaCard Overview

A JavaCard is a regular smart card in the sense that it conforms to all the smart card standards, the only difference is that it possesses a Java Virtual Machine implemented on its ROM. The JCVM (JavaCard VM) controls the access to all smart card resources, such as memory and I/O, and thus essentially serves as the smart card’s operating system.

The JCVM is able to run applets that were written in a subset of the full Java language.

Since the processing and storage power of smart cards is a lot inferior when compared to desktops, some restrictions needed to be made in the JavaCard design. So some features present in the standard Java were wiped out of JavaCard. The main unsupported components, for JC2.0, as stated in [79, 66], are:

Dynamic Class Loading: A JavaCard system is not able to load classes dynamically.

Objects are created in the card either into the card’s ROM during manufacturing or through post-issuance;

Security Manager: The security model of JavaCard systems differs from standard Java in fairly significant ways. Language security policies are implemented by the virtual machine. There is no Security Manager class which makes policy decisions on whether to allow operations;

Threads: The JavaCard Virtual Machine does not support multiple threads of control;

Cloning: JavaCard does not support cloning of objects. JavaCard’s version of class Object does not implement a clone() method, and there is no Clonable interface provided.

Garbage Collection & Finalization: Usually the JCVM does not implement a garbage collector, since objects once created will live “forever” in the card. Explicit dealloca-tion of object is forbidden, like in the regular version of Java. The method finalize() of the classes will not be necessarily called, and thus the developers should not rely on this behavior.

Also JavaCard does not offer support for some keywords (native, synchronized, tran-sient, volatile, strict), for some data types (char, double, float and long, support for int is optional) and not even multidimensional arrays. Most of the core Java classes are not supported as well, and even those that are, do not possess all their methods (like the Object and Throwable classes).

The main package of the JavaCard API is the javacard.framework. This package defines the interfaces, classes, and exceptions that compose the core JavaCard Framework.

It defines important concepts such as the Personal Identification Number (PIN), the Application Protocol Data Unit (APDU), the JavaCard applet (Applet), the JavaCard System (JCSystem), and a utility class. It also defines various ISO7816 constants and various JavaCard-specific exceptions. Other packages that are related to the JavaCard are java.io, java.lang, java.rmi and javacard.security. A complete list of these classes can be seen in [66].

The VM for the JavaCard platform is implemented in two parts, one external to the card and the other running inside the card itself. The on-card virtual machine is the

The VM for the JavaCard platform is implemented in two parts, one external to the card and the other running inside the card itself. The on-card virtual machine is the