Java Card

Java Card

Java Card is a smart card that is capable of running programs written in Java. A smart card is a credit card sized plastic card with an integrated circuit (IC) inside. The IC contains a microprocessor and memory so the smart card can process and store information. The Java Card platform lets smart card developers standardize on a common card platform.

Java Card technology combines a subset of the Java programming language with a runtime environment optimized for smart cards and similar kinds of small-memory embedded devices. The goal of Java Card technology is to bring many of the benefits of Java software programming to the resource-constrained world of smart cards.

The Java Card API is compatible with international standards, such as ISO7816, and industry-specific standards, such as Europay/Master Card/Visa (EMV).

  Java Card is a smart card that is capable of running programs written in Java. For this a new Java platform, Sun's JavaSoft division has made available the Java Card 2.0 API specification, and several licensees are now implementing this API on smart cards. In order to program Java Cards that are 2.0-compliant, developers need to understand what a Java Card is architecturally, what its core classes are, and how to develop applications for the card. This article gets inside a Java Card, providing you, the developer, with technical guidance on the system architecture, application programming interface, and runtime environment of the Java platform in a smart card.

This article begins with an overview of smart cards and a brief review of ISO 7816, the smart card standard. Then we will answer to the question, "What is a Java Card?" and gives an overview of the Java Card system architecture. Next, we'll focus on the many issues specific to the Java Card, including the Java Card lifecycle; the Java Card 2.0 language subset and API library classes; and Java Card security. Then we'll discuss the Java Card runtime environment and show how a Java Card runs.

     Identical to the size of a credit card, a smart card stores and processes information through the electronic circuits embedded in silicon in the plastic substrate of its body.

Types of smart cards
 There are two basic kinds of smart cards:

 1. Intelligent smart card :
  An intelligent smart card contains a microprocessor and offers read, write, and calculating capability, like a small microcomputer.

2.Memory card:
   A memory card, on the other hand, does not have a microprocessor and is meant only for information storage. A memory card uses security logic to control the access of memory.

Types of memory in smart cards
    All smart cards contain three types of memory:
1.ROM-persistent non-mutable memory.
2.EEPROM- persistent mutable memory.
3.RAM- non-persistent mutable memory.
   Persistent memory is also called non-volatile memory. We will use the terms persistent and non-volatile interchangeably in this article. 

     A Java Card is a smart card that is capable of running Java programs. The Java Card 2.0 specification  contains detailed information for building the Java Card virtual machine and application programming interface (API) in smart cards. The minimum system requirement is 16 kilobytes of read-only memory (ROM), 8 kilobytes of EEPROM, and 256 bytes of random access memory (RAM). A Java Card is shown below.
As shown in the figure, the Java Card VM is built on top of a specific integrated circuit (IC) and native operating system implementation. The JVM layer hides the manufacturer's proprietary technology with a common language and system interface. The Java Card framework defines a set of Application Programming Interface (API) classes for developing Java Card applications and for providing system services to those applications. A specific industry or business can supply add-on libraries to provide a service or to refine the security and system model. Java Card applications are called applets. Multiple applets can reside on one card. Each applet is identified uniquely by its AID (application identifier), as defined in ISO 7816, part 5.
An important point to keep in mind is what smart cards are not: They are not personal computers. They have limited memory resources and computing power. Users should not think of Java Card 2.0 as simply a stripped-down version of the JDK.

The lifetime of a Java Card
The Java Card lifetime starts when the native OS, Java Card VM, API classes libraries and optionally, applets are burned into ROM. This process of writing the permanent components into the non-mutable memory of a chip for carrying out incoming commands is called masking.

        Before it lands in your wallet, a Java Card needs to go through initialization and personalization. Initialization refers to loading general data into a card's non-volatile memory. This data is identical across a large number of cards and is not specific to an individual; an example might be the issuer or manufacture's name.

The next step, personalization, involves assigning a card to a person. It can occur through physical personalization or through electronic personalization. Physical personalization refers to embossing or laser engraving your name and card number on the plastic surface of a card. Electronic personalization refers to loading personal data into a card's non-volatile memory, for example, your personal key, name, and pin number. Initialization and Personalization vary from vendor to vendor and issuer to issuer. In both, EEPROM (a type of non-volatile memory) is often used for storing data.

        At this point, the Java Card is ready for use. You can get a Java Card from an issuer or buy it from a retailer. Cards sold by a retailer are general-purpose, in which case personalization is often omitted. Now you can insert your Java Card into a reader and send APDU commands to the applets residing on the card or download more applets or data onto the card.  A Java Card remains active until it is expired or blocked due to an unrecoverable error.

Lifetime of a Java Card virtual machine
Unlike the Java virtual machine (JVM) in a PC or workstation, the Java Card virtual machine runs forever. Most of the information stored on the card must be preserved even when the power is removed -- that is, when the card is removed from the reader. The Java Card VM creates objects in EEPROM to hold the persistent information. The execution lifetime of the Java Card VM is the lifetime of the card. When the power is not provided, the VM runs in an infinite clock cycle.

The lifetime of Java Card applets and objects
An applet's life starts when it is properly installed and registered with the system's registry table and ends when it is removed from the table. The space of a removed applet may or may not be reused, however, depending on whether garbage collection is implemented on the card. An applet on a card is in an inactive stage until it is explicitly selected by the terminal.

Objects are created in the persistent memory (for example, EEPROM). They could be lost or garbage-collected if other persistent objects do not reference them. However, it's a thousand times slower to write to EEPROM than to RAM. Some objects are accessed frequently, and the contents of their fields need not be persistent. The Java Card supports transient (temporary) objects in RAM. Once an object has been declared as transient, its contents can not be moved back to the persistent memory.

Java Card 2.0 language subset
Java Card programs are, of course, written in Java. They are compiled using common Java compilers. Due to limited memory resources and computing power, not all the language features defined in the Java Language Specification are supported on the Java Card. Specifically, the Java Card does not support:
·         Dynamic class loading
·         Security manager
·         Threads and synchronization
·         Object cloning
·         Finalization
·         Large primitive data types (float, double, long, and char)

  It's no surprise that keywords that support those features are also omitted from the language. VM implementers may decide to support 32-bit integer type or native methods for post-issuance applets if they are working on a more advanced smart card with more memory. Post-issuance applets are those applets that are installed on a Java Card after the card is issued to a card holder.

The Java Card 2.0 framework
Smart cards have been in the market for 20 years, and most of them are generally compatible with ISO 7816 Parts 1-7 and/or EMV. We've already looked at ISO 7816. What's EMV? The EMV standard, defined by Europay, MasterCard, and Visa, is based on the ISO 7816 series of standards with additional proprietary features to meet the specific needs of the financial industry. The Java Card Framework is designed to easily support smart card systems and applications. It hides the details of the smart card infrastructure and provides Java Card application developers with a relatively easy and straightforward programming interface.

Java Card security
Java applets are subject to Java security restrictions, however, the security model of Java Card systems differs from standard Java in many ways. The Security Manager class is not supported on Java Card. Language security policies are implemented by the virtual machine.  Java applets create objects that store and manipulate data. An object is owned by the applet that creates it. Even though an applet may have the reference to an object, it cannot invoke the object's methods, unless it owns the object or the object is explicitly shared. An applet can share any of its objects with a particular applet or with all applets.

        An applet is an independent entity within a Java Card. Its selection, execution, and functionality are not affected by other applets residing on the same card.

How things work together inside a Java Card
Inside a Java Card, JCRE (Java Card Runtime Environment) refers to the Java Card virtual machine and the classes in the Java Card Framework. Each applet within a Java Card is associated with unique AID assigned by JCRE. After an applet is correctly loaded into the card's persistent memory and linked with the Java Card Framework and other libraries on the card, JCRE calls the applet's install method as the last step in the applet installation process. A public static method, install, must be implemented by an applet class to create an instance of the applet and register it with JCRE. Because memory is limited, it's good programming practice, at this point, to create and initialize the objects the applet will need during its lifetime.

        An applet on the card remains inactive until it is explicitly selected. The terminal sends a "SELECT APDU" command to JCRE. JCRE suspends the currently selected applet and invokes the applet's deselect method to perform any necessary cleanup. JCRE then marks the applet whose AID is specified in the "SELECT APDU" command as the currently selected applet and calls the newly selected applet's select method. The select method prepares the applet to accept APDU commands. JCRE dispatches the subsequent APDU commands to the currently selected applet until it receives the next "SELECT APDU" command. 

 Java Card can be used in all fields where the smart card is now being used. Java Card can be used as an ID card which contains personal information, as a medical card which stores medical information, as a credit/debit bank card, as an electronic purse etc. Multi-Application Java Cards, that is, more than one application in a single card is also available.

  The Java Card adds a new platform to the world of Java. Widespread adoption and deployment of the Java Card will require marketing promotion, more applications and tools development, and time. At the same time, the number of Java Cards in existence could easily extend into the millions within the next few years. Which means you may soon be storing your personal information and downloading applications using a little card you carry around in your wallet or purse.

No comments:

Post a Comment

leave your opinion