Introduction to the Java card under the PBOC specification

Java Cards and smart cards

What is a JAVA card? A Java card is a contactless microprocessor smart card that can run Java programs. In November 1996, the JAVA Card version 1.0 specification was officially released. Now the latest JAVA card specification has reached the 2.1 version.

I believe that the reader of the smart card will certainly ask: the emergence and use of smart cards has been nearly 20 years, why the recent emergence of JAVA card? Why is the JAVA card becoming so popular? To answer this question, let's review the smart card before the JAVA card appears and see what kind of problem it has.

Smart card before the Java card

Early smart cards are primarily in the form of a medium that can store amounts in the card body and can be used on public telephones or vending machines. It accomplishes a kind of storage information application. Then the demand for cards is not big. At the same time the card application is not many. Recently, as smart cards become more and more "smart", due to the advantages of smart cards are increasingly recognized, its scope of application is more and more extensive: from the bank's debit card, the medical card to store personal medical information, to the wired and wireless network security module card and so on. Smart card applications can be said to involve a variety of areas, almost everyone has to deal with smart cards. Demand for the market has risen sharply, and more and more new applications for smart cards have been born.

But the sharp rise in demand for smart cards is contradictory: the development of smart card applications is a complex and lengthy process. Although the size of the smart card and the communication protocol, the international standard ISO7816 has long been stipulated, but the various card manufacturers of smart card development are different. Each card manufacturer has a unique set of instructions for its own smart card operation.
In addition, smart card programming interfaces (APIs) are very complex to program, requiring developers to be very familiar with the details of low-level communication interface protocols, memory management, and some smart card hardware. As a result, developers need to spend a lot of time understanding the complex development environment of smart cards before developing smart card applications, and they will find that there are no modern development tools (tools like Visual Studio). What's worse: there's no common development environment for different smart cards. Every time you develop a new application, you may have to learn a new development environment from scratch.

The situation may not have been so simple. Since all smart cards are developed in a dedicated development environment, cards from different card manufacturers may not be compatible with the same application, making it very complicated to use cards from different manufacturers in the same system.
It is estimated that in 2001, the demand for smart cards was 103 billion tablets. There are few people who know how to program smart cards. The complexity of smart card programming, the non-uniformity will seriously hinder the development of smart cards. The demand of the market has put forward a new request for the development of smart card. However, all this will change with the advent of the JAVA card.

The advent of the Java card

The

java  card is a contactless microprocessor smart card that can run  JAVA  programs, and the program running in the card is called  applet. The applet  can be dynamically loaded onto the  JAVA  card.  api of the java  card (java card 2.1.1 application programming interfaces  specification ) has developed a special subset of  JAVA  languages for smart cards. Today, 95% of smart card manufacturers have supported the  api of  JAVA  cards. The advent of java  card and  JAVA  card  API  makes smart card programming fast and easy, while these card applications (applets) can be in any support  JAVA  card   Run on the api  smart card. It can be said that the appearance of the  JAVA  card immediately resolves the problem with the smart card before the  JAVA  card appears. How does the
java  card accomplish this huge function? It turns out that there is a  JAVA  virtual machine that can execute  JAVA  bytecode (Applet) within the  JAVA  card-it provides a set of standard  JAVA  card programming   API enables developers to develop smart card applications without needing to know the complex smart card hardware and smart card-specific technologies, which greatly reduces development time and reduces development complexity. According to rough statistics, using  JAVA  to program can save  60%  development time by programming in  C  language, such as compared with the Special assembly language of smart card, this advantage will be more obvious. At the same time because of the use of  JAVA  virtual machine,java  card  Applet  can be  jcae in different cards (java card application  environment), that is, the ability to cross-platform is achieved through the mechanism of  JAVA  virtual machines.

JAVA is an object-facing programming language, and the smart card's object-based API greatly simplifies the communication between the Isla Canela Applet and the terminal or background server.

Another great advantage of the JAVA card is that developers can arbitrarily choose the development tools they are familiar with and like. Because Java cards are programmed in the Java language, all of the popular Java development environments, such as Vj++,vcafe, can be used for Java card development almost all of today. That's why applications that quickly complete and debug JAVA cards have become possible. Before that, the application of the debug card was a very complicated and lengthy process, because the application was first loaded into the card's ROM, and the program loaded into the card's ROM could not be updated, so debugging an application would take a lot of time.

And since any Java developer can become a Java Card developer, this provides a powerful guarantee for the development of smart cards.
The JAVA card also has two major advantages: support for one-card multi-purpose and reuse. Support for one-card multi-purpose refers to the JAVA card can exist at the same time several different applications. These applications can come from the same card vendor or from a different card vendor. Such a JAVA card can do different functions, for example, it can have electronic wallet function, but also can have identification function. Reuse refers to the ability of an app on a JAVA card to remove or re-add new applications as needed without replacing new smart cards, greatly enhancing the flexibility of smart cards.
In summary, the advent of the JAVA Card Unified Smart Card Programming Interface (API), unified the smart Card programming language (JAVA language), for the wider use of smart cards to provide a basis for the smart card industry to truly become a unified standard industry.

Structure of the Java card

It can be said that the Java card is the smallest subset of the Java platform. The JAVA Card 2.1 specification can be obtained at the Http://www.javasoft.com/javacard site. Java Card 2.1 Specifications mainly include: Java Card virtual machine specification, Java Card programming Interface (API) and Java Card operating environment specifications.

Java Card is a bit like a full-featured, but small-scale computer, its hardware is mainly to ensure that the JAVA card operating environment needs, its minimum hardware configuration requirements are:

Bytes RAM: used primarily to store stack, staging data, and buffers as I/O when the program executes.

KB ROM: Mainly used for operating system and running environment (runtime Environment), such as JAVA virtual machine, Applet and so on.

8 KB EEPROM: Used to store applets that we have developed and loaded onto the JAVA card.

The 8-bit Processor:java card requires at least 8-bit processor support.

So what is the internal structure of the JAVA card? Based on the above hardware introduction, basically we can imagine the Java card as a miniature of a PC: the internal structure of the Java card by the OS, native functions, Java VMS (Java Virtual machine), the Java framework and the architecture of the application (APPL ET) is constituted. is the JAVA card internal structure:
In this structure, the bottommost OS (operating system) and Native Functions (basic functions) are responsible for the low-level processing, as is the case with the PC's operating system.

The JAVA virtual machine is on the OS and Native Functions, and its existence realizes the unification of the card interface and the programming language. And also hides the card at the bottom of each card vendor different technologies.

The Java Card Framework defines a complete set of programming interface classes for developers, primarily responsible for executing JAVA card applets and providing the environment required for applet execution.

Industry add-on Classes is the class provided by the service provider, which enables companies and companies to provide their own service programs, for example, if this card is a GSM network SIM card, then this layer is the SIM card required interface class.

The top layer of the Java card is the so-called Java Card Applet, which is the application we are going to develop. , a Java card can execute multiple Java card applets. Each Applet is identified by AID (app ID number). However, it is important to note that the JAVA card execution environment does not support multi-threading, so only one applet can be executed at a time, and there is a firewall barrier between the applet and the applet.

Lifetime of the Java card

Lifetime of the JAVA card

When the Java Card OS, virtual machine, programming Interface (API) class library is loaded into the card's ROM, the Java card begins its work mission. The process of putting a fixed component of a JAVA card into a non-overridable area (ROM) of a chip is called a mask. However, there are two necessary procedures for the JAVA card to actually work: initialization and personalization. Initialization refers to the creation of a file structure within the card body (typically in the EEPROM). This file structure is for everyone, and its specific content is related to the functionality of your JAVA card. For example: Your card is a bank card, then the card structure is defined by the banking structure, if the card is a SIM card, then the structure of the card will be based on the GSM specification. Initialization does not involve personal information. If the card is to be issued to a designated person, it is done through the personalization process. Personalization is the attachment of personal information to a card. It can be a physical process, such as printing someone's photo, or an electronic process: Writing personal information to a card. such as your ID number, PIN code and so on. Initialization and personalization can be done by business card makers or distributors. This JAVA card can be used when initialization and personalization are complete. You can insert the card into the reader, issue a APDU instruction to it, or download more applets. The lifetime of the Java card will persist until it is physically compromised, the incorrect operation is locked or the card application expires.

The lifetime of a JAVA card virtual machine
Unlike a Java virtual machine in a PC, a virtual machine in a Java card will run forever. It is feared that the information on the card will be preserved after the power is lost. So the lifetime of the Java Card virtual machine is consistent with the Java card lifetime. When there is no power, the virtual machine runs like an infinitely large clock frequency .

Lifetime of JAVA card Applet
The applet begins with the applet being installed and registered in the card's registry , ending with the applet being unregistered from the registry . The generic applet is not activated in the card, and the applet is activated only when the applet is "selected" by the terminal.

Java Card Java language

Java card programs are, of course, written by the Java language. is also compiled by the generic JAVA compiler. However, due to the Java Card hardware limitations (memory size, CPU capacity), the Java card does not support all Java language features. The following Java language features are not supported for Java cards:

Dynamic class loading (Dynamics class loading)

Safety Management (Security Manager)

Objects cloning (object cloning)

Finalize () method

Some data types: Float,double,long,char

Multithreading

And these keywords are not supported: Native,synchronized,transient,volatile. While almost all Java core API classes are not supported by Java cards, only some classes from the Java.lang package are supported.
Other Java language features, Java cards are supported. For more information on Java Card Java language, see Java Cards 2.1.1 Virtual machine specification.

API for Java Cards

According to the Java Card 2.1 specification (Java Card 2.1.1 Application programming Interface), currently Java cards support a total of 4 Packages (package), now some of the important classes are described:

Java.lang Package: Provides some important classes of the Java language, such as the Object class, because all Java classes inherit it.

Object–class (indicates that its type is class, if write interface, the description type is interface, the following is the same), the base class of all classes

Throwable–class, the parent class for all error and exception, which means that the JAVA card also supports exception

Javacard.framework Package: Is the Java Card API main core package, provides and implements the Java Card Applet basic interface and tools.

Aid–class, the ID number used to represent the JAVA card Applet only

Apdu–class, a byte array buffer is adopted to receive the standard format of the result and status of the instruction and postback Applet executed with the delivery terminal. This process is exactly the same as the APDU we described in the previous article. When we are developing applets, we can imagine that APDU is a buffer in which a card communicates with the terminal, and both the terminal and the card put the information into this buffer for communication.

Applet–class, each JAVA card Applet must inherit this class. In the implementation of the special attention to a few methods, such as Select (), deselect () is the terminal according to the Applet's AID release or not selected. The install () and register () is the method by which the Applet is loaded onto the Java card and registered with the Java Card registry. When the applet installation registration is complete and is selected by the terminal, all the issued APDU commands are processed by the applet's process () method and are responsible for the callback results.

Ios7816–interface, provides the constant value used by the ISO7816

Pin–interface that enables its subclasses to complete the verification PIN function by implementing this interface

Shareable–interface, so that different applets can achieve this interface to communicate with each other function

Jcsystem–class is responsible for managing the system resources of applets and JAVA cards, such as AID and Transaction management.

Ownerpin–class, inherited from pin interface, is responsible for maintaining the PIN code of the card holder and providing the relevant check () and update () methods.

Util–class, a class that provides common tools, such as copy and compare byte arrays.

Javacard.security Package: Provides security mechanisms for packages, several of which are important interface (interfaces) and class (classes) as follows:

Key–interface, is the common interface of Deskey, Privatekey, PublicKey and other interfaces

Keybuilder–class, creating a factory of various secure keys (factory)

Messagedigest–class, an object that can digitally sign information

Javacardx.crypto Package: It contains an object about encryption and security, and this package contains only one interface and one class:

Cipher–class, so that the information in the JAVA card is encrypted and protected

The above is just a simple introduction of the JAVA card API interface, we will be a few examples of detailed introduction, of course, the most complete information and solutions to refer to: Java Card 2.1.1 Application programming Interface specification.

A simple example of an Applet

The following is an example of a very simple applet, which we will look at in the first place, and some of the methods that must be implemented (constructors, the Install () method, the Register () method, the Select () method, Process () method). The function of this example is that when the reader sends a random number of APDU (00 84 00 00 04) Instructions to the Java card, the Java card returns a 4-byte response of a 16-decimal random number. 

Package Random;import Javacard.framework.applet;import javacard.framework.iso7816;import Javacard.framework.isoexception;import Javacard.framework.apdu;import Javacard.framework.jcsystem;import Javacard.framework.util;import javacard.security.*; import Javacardx.crypto.*;/** * @author Administrator **/ Public classRandom extends Applet {/*define the constants used*///CLAFinalStatic byteCla_getchallenge = (byte)0x00;//INSFinalStatic byteIns_getchalleng = (byte)0x84;/*Defining Variables*/Randomdata Random;/*Installing applets*/ Public Static voidInstallbyte[] Barray, ShortBoffset,byteblength) {//gp-compliant Javacard Applet registrationNewRandom (). Register (Barray, ( Short) (Boffset +1), Barray[boffset]);} /*handling instructions from a read-write device*/ Public voidprocess (APDU APDU) {//good Practice:return 9000 on SELECTif(Selectingapplet ()) {return;}byte[] buf =Apdu.getbuffer ();Switch(buf[iso7816. Offset_ins]) { Case(byte) Ins_getchalleng:byteLE =buf[iso7816.    OFFSET_LC]; byte[] Randombuffer =New byte[LE];  ShortRoffset = ( Short)0;  ShortLen = ( Short) LE; Randombuffer=Jcsystem.maketransientbytearray (Len, jcsystem.clear_on_deselect); Random=randomdata.getinstance (randomdata.alg_secure_random);    Random.generatedata (Randombuffer,roffset,len); Util.arraycopynonatomic (Randombuffer, ( Short)0, BUF, ( Short)0, Len); Apdu.setoutgoingandsend (( Short)0, Len); Break;default://good practice:if you don ' t know the instruction, say so:Isoexception.throwit (iso7816.sw_ins_not_supported); }}}

Introduction to the Java card under the PBOC specification