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