Understanding Java Card 2.0 - JavaWorld March 1998
Tutorial Details:
Understanding Java Card 2.0
Understanding Java Card 2.0
By: By Zhiqun Chen , with special contribution by Rinaldo Di Giorgio
Learn the inner workings of the Java Card architecture, API, and runtime environment
his article begins with an overview of smart cards and a brief review of ISO 7816, the smart card standard. Given the background on smart cards in previous Java Developer columns, this installment will begin with an answer to the question, "What is a Java Card?" and 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. We'll close with an illuminating example: An electronic wallet application written just for the Java Card.
From here on, all references to Java Card implicitly refer to the Java Card 2.0.
What is a smart card?
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. There are two basic kinds of smart cards: An intelligent smart card contains a microprocessor and offers read, write, and calculating capability, like a small microcomputer. 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.
All smart cards contain three types of memory: persistent non-mutable memory; persistent mutable memory; and non-persistent mutable memory. ROM, EEPROM, and RAM are the most widely-used memory for the three respective types in the current smart cards. Persistent memory is also called non-volatile memory. We will use the terms persistent and non-volatile interchangeably in this article.
ISO 7816 part 1-7, defined by International Standard Organization, contains a set of standards that covers various aspects of smart cards. ISO 7816 consists of:
Physical characteristics (part 1)
Dimensions and location of the contacts (part 2)
Electronic signals and Transmission protocols (part 3)
Inter-industry commands for interchange (part 4)
Application identifiers (Part 5)
Inter-industry data elements (Part 6)
Inter-industry commands for SCQL (Part 7)
The following diagram illustrates the physical characteristics of a smart card, which are defined in ISO 7816, part 1.
For more on ISO 7816 and smart cards, see " Smart cards: A primer ."
Normally, a smart card does not contain a power supply, a display, or a keyboard. It interacts with the outside world using the serial communication interface via its eight contact points. The dimensions and location of the contacts are covered in part 2 of ISO 7816. This diagram shows the contacts on a smart card.
A smart card is inserted into a Card Acceptance Device (CAD), which may connect to another computer. Other terms used for the Card Acceptance Device are terminal , reader , and IFD (interface device). They all provide the same basic functions, namely to supply the card with power and to establish a data-carrying connection.
When two computers communicate with each other, they exchange data packages, which are constructed following a set of protocols. Similarly, smart cards speak to the outside world using their own data packages -- called APDU (Application Protocol Data Units). APDU contains either a command or a response message. In the card world, the master-slave model is used whereby a smart card always plays the passive role. In other words, a smart card always waits for a command APDU from a terminal. It then executes the action specified in the APDU and replies to the terminal with a response APDU. Command APDUs and response APDUs are exchanged alternatively between a card and a terminal.
The following tables illustrate command and response APDU formats, respectively. APDU structure is described in ISO 7816, part 4.
Command APDU
Mandatory Header
Conditional Body
CLA
INS
P1
P2
Lc
Data field
Le
The header codes the selected command. It consists of four fields: class (CLA), instruction (INS), and parameters 1 and 2 (P1 and P2). Each field contains 1 byte:
CLA: Class byte. In many smart cards, this byte is used to identify an application.
INS: Instruction byte. This byte indicates the instruction code.
P1-P2: Parameter bytes. These provide further qualification to the APDU command.
Lc denotes the number of bytes in the data field of the command APDU; Le denotes the maximum number of bytes expected in the data field of the following response APDU.
Response APDU
Conditional Body
Mandatory Trailer
Data field
SW1
SW2
Status bytes SW1 and SW2 denote the processing status of the command APDU in a card.
What is a Java Card?
A Java Card is a smart card that is capable of running Java programs. The Java Card 2.0 specification was published at http://www.javasoft.com/javacard . It 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).
The system architecture on the Java Card is illustrated in the following figure.
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
Read
Tutorial at: Click here to view the tutorial
Rate Tutorial: Understanding Java Card 2.0 - JavaWorld March 1998
View Tutorial: Understanding Java Card 2.0 - JavaWorld March 1998
Related
Tutorials:
 3D graphics programming in
Java, Part 3: OpenGL
3D graphics programming in
Java, Part 3: OpenGL
|
How to write
a Java Card applet: A developer's
guide
How to write
a Java Card applet: A developer's
guide
|
Container-managed relations for the
21st century
Container-managed relations for the
21st century
|
J2SE 1.4
breathes new life into the CORBA community, Part
1
J2SE 1.4
breathes new life into the CORBA community, Part
1
|
Sun boosts
Sun boosts enterprise Java
|
Once again, only
introduction
Once again, only
introduction
|
PGP Java API 2.0
PGP Java API 2.0
|
JXMLAppKit 2.0
JXMLAppKit is a pure Swing java framework for editing an XML document with multiple XML editors.
|
JSP 2.0: The New Deal, Part 4
JSP 2.0: The New Deal, Part 4
In this final part of the "JSP 2.0: The New Deal" series, we look at two new features that make it much easier to develop custom tag libraries: tag files and the new simplified tag-handler Java API.
|
Rome
Rome
Rome is a set of Atom/RSS Java utilities that make it easy to work in Java with most syndication formats.
|
Software Download Central
compatible.
GNU getopt - Java port
A while back I found myself in need of a Java command line option parser. Unsatisfied with free versions I was able to find on the net, I volunteered to port the GNU getopt family of functions from C to Java. The current release
|
Garbage Collection in the Java HotSpot Virtual Machine
Garbage Collection in the Java HotSpot Virtual Machine
Gain a better understanding of how garbage collection in the Java HotSpot VM works, and learn to take full advantage of it when designing, developing, and deploying your Java applications.
|
Java Resources
There are all Java freebies. Some of these are old, and not under maintenance. Download and use them at your risk. In case of queries, mail subrahmanyam_avb@technologist.com or varalakshmi_a@techie.com.
|
Project Looking Glass: Its Architecture and Sneak Preview of the API
Bring a richer user experience to the desktop and to applications, through 3D windowing and visualization capabilities. This article covers Project Looking Glass' main features and API, its basic organization, and the functionality of important classes.
|
USB FAQ
FAQ topics include recommended USB patches for the Solaris OS, the USBA 1.0 Framework, libusb support, and more.
|
UML 2.0 Sequence Diagramming
Modeling Complex Code in SunONE Studio with Embarcadero's Integrated Modeling Developement Environment, Describe.
|
Struts, JavaServer Faces, and Java Studio Creator:
The Evolution of Web Application Frameworks Sun Microsystems' Craig McClanahan, the creator of the Apache Struts Framework, co-specification lead for JavaServer Faces 1.0, and prime architect for Sun Java Studio Creator's new release, explains all three.
|
Writing your First WAP Application.
Writing your First WAP Application.
Tutorial
Writing your First Application.
N ow it's time to mould your Internet Data for the entire Unwired World!
Our "Welcome to Unwired World" application will familiarize you with the WML code.
As
|
Writing more than one cards in a WML deck.
Writing more than one cards in a WML deck.
Tutorial
First Card
Writing more than one cards in a deck.
In this lesson we will write application that uses two cards in a deck. First card is displayed only for some time and after that it directly
|
SDE for Eclipse
[[http://www.visual-paradigm.com/sdeec.php][The SDE 2.0 for Eclipse (SDE-EC)]] is a powerful, yet the most easy-to-use UML Modelling plugin for Eclipse.
|
|
|
|
