You have a privilege to create a quiz (QnA) related to this subject and obtain creativity score...
How to Program JavaCards
A single Identity Key serves us to illustrate JavaCard Programming.
Let us review the application goals and briefly talk about JavaCard Architecture.
A single JavaCard works with a card reader at any door or for any service. The same card can also help identify a driver, rent a movie, order dinner, or use distributed knowledge and service networks. The card can exchange data with a card reader and provide you with secure access to any computerized services where your identity data are important.
The service may require an interactive interface, which may be provided by a terminal application – for example, one running on a Tablet PC geared to a pen and voice interface. A card reader on a Tablet PC may be placed on any wall in a store, hotel, or airport, or in a car or on public transportation.
The single identity key would provide access to the world of all public services paid for by digital money and to the world of distributed private services owned by groups and ruled by group memberships, roles, and virtual currency (contribution/consumption score) data.
From the description of the application in business terms let us move to more technical world. We still try to keep close connections to business descriptions by properly naming the main components and operations. We introduce the VirtualCurrency and DigitalMoney applets.
It is possible for the VirtualCurrency applet to pass control to the DigitalMoney applet – for example, in a case in which the requested knowledge service is not pleased with my current virtual score and requires cash instead.
The applets interact via APDU packets with the card reader and further with terminal applications running, for example, on a Tablet PC (geared to a pen/voice interface) located on a hotel or airport wall, at the video store, in the car, at home, or connected over a wire or wireless device to service provider networks.
Each applet has a unique application identifier (AID). An AID consists of two pieces: a registered ID (RID) and a proprietary extension (PIX). The RID is a 5-byte company ID assigned by ISO. The PIX is a variable-length (0 to 11 bytes) ID assigned to each applet by the company. This rule, established by ISO, helps to uniquely identify any JavaCard program.
The JavaCard API includes the AID class with RID and PIX properties that support this rule. Later in the chapter, there is an example of how the AID class can be used in the JavaCard applet for other purposes.
Was it clear so far?
A JavaCard applet interacts with the JCRE via the applet’s public methods that reflect the applet’s life cycle: install, select, deselect, and process. (Regular Java applet life cycle methods are init, start, stop, and destroy.)
A programmer must implement at least the install method, which is called once by the JCRE when the applet is installed on the smart card.
The install method usually calls an applet constructor to create an instance of the applet, allocate its memory, and register this instance with the card reader or CAD. The constructor is private, and JCRE never calls it directly.
The applets are still not active until they are explicitly selected when the JCRE receives a SELECT FILE APDU command in which the name data matches the AID of the applet, or a MANAGE CHANNEL OPEN command. In either case, JCRE deselects the previously selected applet and calls the select() method on the currently selected applet. The default select() method returns true, but this method can be overridden and, for example, can check if the PIN is not blocked. If the applet returns true, JCRE will call the process() method and pass the actual SELECT FILE APDU command to the method.
The process() method can examine the APDU packet data, perform data handling, change persistent storage, and send and receive more APDU packets if exchange with the CAD is needed.
To program the JavaCard, we use a limited Java language and manipulate several primitives and objects.
Sun Microsystems provides the JavaCard 2.2 Runtime Environment (JCRE) Specification and the JavaCard Development Kit [1] free of charge.
Java programs that run on JCRE are applets, but they are different from regular Java applets running on PCs. Unlike a JVM running on a PC, the JavaCard Virtual Machine appears to run forever. It stops only temporarily when the power is off; when the power is back on, it starts up again and recovers its previous object heap from persistent storage.
When the card is inserted in the card reader and powered up, the card session begins; when the card is removed, the session ends. The card reader is often called the card acceptance device (CAD). The mechanism of data transfer between the CAD and the card is defined by the ISO 7816 specification. Java programmers work with its implementation in the Application Protocol Data Units (APDUs), the messaging structure that is used by JavaCard applets to interact with a card reader.
A JavaCard can contain one or more applets, as in the illustration below. The DigitalMoney applet is responsible for cash management. Each time I buy or sell a product or service, this applet manages the cash balance and makes it persistent. The VirtualCurrency applet is responsible for my access to the world of distributed knowledge and other services that accept virtual currency.
Each time I contribute to this world or consume its data or services, the VirtualCurrency applet sends information related to my memberships and privileges to the system (these data can influence “price”) and keeps track of my virtual currency score and makes it persistent.
The DigitalMoney applet gives us easy access to public services, while the VirtualCurrency applet opens the doors of group-owned private services. We often feel more secure behind gated communities where members are well known. Groups and collaborative services might serve as an escape from the urban areas of the public Internet.
