Tomcat
Professional
- Messages
- 2,689
- Reaction score
- 915
- Points
- 113
Namiot D.E.
Sikhovets L.B.
This article begins a series of materials prepared by Inetique staff on smart card technology and, in particular, Java Card technology.
About the authors: Ph.D. Dmitry Namiot has been working with Java technologies for the last 6 years. Lev Sikhovets is a Sun Certified Programmer for the Java Platform 2 with over five years of experience working with Java. Currently, both authors are collaborating with Inetique, a Java development company. You can contact the authors and get additional information through the website http://www.inetique.ru/.
The Java Card API allows programs written in Java to run on smart cards and other resource-constrained devices.
Smart cards (smart cards) are one of the smallest computing devices today. For example, you may come across a device with 24 Kb of memory. Naturally, in such conditions it is possible to support only a certain subset of the Java language.
The virtual Java Card machine consists of two parts, one of which runs directly on the card itself, and the other on the host machine outside the card. Outside the Java Card, processes such as class loading, bytecode checking, optimization, etc. are executed. The criterion for such division is the presence or absence of restrictions on the execution of the process while the program is running.
In addition to the Java language itself, Java Card technology supports the runtime environment, which includes issues related to card memory management, data transfer, security, and program execution. For Java Cards, this framework complies with the ISO 7816 standard.
The main task of this environment is the strict separation of the smart card itself and the Java application. The environment serves as a kind of proxy server, hiding the details of its own implementation from the application. Interaction with the program is carried out through standardized high-level interfaces.
Applications written for the Java Card platform are called applets. The name was chosen due to the similarity of the execution model to standard applets that run in a web browser's Java Virtual Machine (JVM).
The Java Card platform includes three parts:
For example, what is supported:
Not supported:
The converter exists outside the smart card. This is a Java application running on the user's computer. The converter converts regular .class files (standard bytecode) into a special CAP (converted applet) format
The CAP file is loaded into the smart card and then executed by the interpreter. In addition to the converted bytecode, the converter creates a so-called export file that describes the available interfaces of the converted class. All programming language options that are not supported by the Java Card specification are removed during conversion.
The CAP file itself contains the binary representation of the classes in the custom package. In fact, this file is a Java archive (.jar file). The archive contains information about classes, executable bytecode, binding information, etc. The bytecode defined by CAP is built on standard Java bytecode and is optimized for execution under resource-constrained smart card environments. The CAP file defines the binary compatibility of applications on the Java Card platform.
Export files are not loaded directly into the smart card and therefore are not used by the interpreter. Their purpose is to support the verification process. In some ways, they are similar to header files in C.
The export file contains the interfaces for the package being converted. Description It contains the names and scopes for the classes, as well as the scopes and headers for all methods. The file also contains linking information necessary to resolve links between application packages.
Like a header file in C (or an interface definition in Java), an export file does not contain an implementation. This makes it possible to freely distribute export files, without disclosing implementation details
During this conversion, the converter performs tasks normally performed by the standard JVM during application loading. For Java Card, these tasks are not feasible on the card itself due to lack of resources. That is why the composite nature of the Java virtual machine on the Java Card platform was discussed above. The converter (as one part of JCVM) performs its part of the overall application execution process. In particular, the converter:
The converter can also use export files as input information. This occurs if the package being converted imports classes from other packages. In this case, these packages will be represented by their own export files to the container.
As noted above, in addition to the CAP file itself, the converter creates an export file for the entire package.
Sikhovets L.B.
This article begins a series of materials prepared by Inetique staff on smart card technology and, in particular, Java Card technology.
About the authors: Ph.D. Dmitry Namiot has been working with Java technologies for the last 6 years. Lev Sikhovets is a Sun Certified Programmer for the Java Platform 2 with over five years of experience working with Java. Currently, both authors are collaborating with Inetique, a Java development company. You can contact the authors and get additional information through the website http://www.inetique.ru/.
The Java Card API allows programs written in Java to run on smart cards and other resource-constrained devices.
Smart cards (smart cards) are one of the smallest computing devices today. For example, you may come across a device with 24 Kb of memory. Naturally, in such conditions it is possible to support only a certain subset of the Java language.
The virtual Java Card machine consists of two parts, one of which runs directly on the card itself, and the other on the host machine outside the card. Outside the Java Card, processes such as class loading, bytecode checking, optimization, etc. are executed. The criterion for such division is the presence or absence of restrictions on the execution of the process while the program is running.
In addition to the Java language itself, Java Card technology supports the runtime environment, which includes issues related to card memory management, data transfer, security, and program execution. For Java Cards, this framework complies with the ISO 7816 standard.
The main task of this environment is the strict separation of the smart card itself and the Java application. The environment serves as a kind of proxy server, hiding the details of its own implementation from the application. Interaction with the program is carried out through standardized high-level interfaces.
Applications written for the Java Card platform are called applets. The name was chosen due to the similarity of the execution model to standard applets that run in a web browser's Java Virtual Machine (JVM).
The Java Card platform includes three parts:
- Java Card 2.1 Virtual Machine (JCVM). The specification defines a subset of the Java language and a JVM specification suitable for smart cards.
- Java Card 2.1 Application Programming Interface (API). The specification describes Java packages and classes for programming smart cards
- Java Card 2.1 Application Programming Interface (API). The specification describes Java packages and classes for programming smart cards
Subset of a programming language
As noted above, due to available memory limitations, the Java Card platform only supports a selected subset of the Java programming language. Only the most necessary options for programming are left. However, it is still an object-oriented language, and it is still Java.For example, what is supported:
- short primitive data types: boolean, byte, short
- one-dimensional arrays
- packages, classes, interfaces and exceptions
- object-oriented properties of Java: inheritance, virtual functions, method overloading, dynamic object creation, scope.
Not supported:
- long primitive data types: long, double, float
- characters and strings
- multidimensional arrays
- dynamic class loading
- garbage collection
- multi-threading
- serialization and cloning of objects
Java Card Virtual Machine
The main difference from a regular Java virtual machine is that JCVM is a set of two components: what is on the card itself (the interpreter) and what is outside the card (the converter).The converter exists outside the smart card. This is a Java application running on the user's computer. The converter converts regular .class files (standard bytecode) into a special CAP (converted applet) format
The CAP file is loaded into the smart card and then executed by the interpreter. In addition to the converted bytecode, the converter creates a so-called export file that describes the available interfaces of the converted class. All programming language options that are not supported by the Java Card specification are removed during conversion.
The CAP file itself contains the binary representation of the classes in the custom package. In fact, this file is a Java archive (.jar file). The archive contains information about classes, executable bytecode, binding information, etc. The bytecode defined by CAP is built on standard Java bytecode and is optimized for execution under resource-constrained smart card environments. The CAP file defines the binary compatibility of applications on the Java Card platform.
Export files are not loaded directly into the smart card and therefore are not used by the interpreter. Their purpose is to support the verification process. In some ways, they are similar to header files in C.
The export file contains the interfaces for the package being converted. Description It contains the names and scopes for the classes, as well as the scopes and headers for all methods. The file also contains linking information necessary to resolve links between application packages.
Like a header file in C (or an interface definition in Java), an export file does not contain an implementation. This makes it possible to freely distribute export files, without disclosing implementation details
Converter
The entire package, which is the user application, is always converted. As usual, the Java compiler produces standard bytecode. Next, the converter converts all received .class files.During this conversion, the converter performs tasks normally performed by the standard JVM during application loading. For Java Card, these tasks are not feasible on the card itself due to lack of resources. That is why the composite nature of the Java virtual machine on the Java Card platform was discussed above. The converter (as one part of JCVM) performs its part of the overall application execution process. In particular, the converter:
- checks the correctness of the bytecode
- checks for violations of the Java Card standard (subsets of Java)
- performs initialization of static variables
- resolves symbolic links for classes, methods, and class fields and puts them into a more compact form better suited to the constraints of the smart card environment
- optimizes bytecode
- allocates memory and creates JVM structures to represent classes
The converter can also use export files as input information. This occurs if the package being converted imports classes from other packages. In this case, these packages will be represented by their own export files to the container.
As noted above, in addition to the CAP file itself, the converter creates an export file for the entire package.
Interpreter
As usual, the interpreter provides support for the Java language (bytecode) at runtime. Interpretation itself (as opposed to compilation) ensures the independence of the applet code from the hardware. The interpreter performs, for example, the following tasks:- bytecode execution
- memory management and object creation
- security
Conclusion
This review discussed the main aspects of the implementation of the Java Card platform. In subsequent parts we will focus on installing applets, describing JCRE and the Java Card APILiterature
- Smart Card Application Development Using Java by Uwe Hansmann (Editor), et al
- Java Card (tm) for Smart Cards: Architecture and Programmer's Guide (The Java Series) Zhiqun Chen
- Java Card for E-Payment Applications by Vesna Hassler, et al
- Smart Card Handbook, 2nd Edition by W. Rankl, W. Effing
Authors: Namiot D.E. and Sikhovets L.B.
iNetique - Java разработки: J2ME, J2EE
Программирование и разработки для Java: JEE, J2EE, J2ME, Java cards, веб-приложения и мобильный веб
www.inetique.ru
