Java Card

Java Card (JC) refers to a technology that allows small Java-based applications (applets) to be run securely on smart cards and similar small memory footprint devices. Java Card is the tiniest of Java targeted for embedded devices. Java Card gives the user ability to program the device and make them application specific. It is widely used in SIM cards (used in GSM mobile phones) and ATM cards. The Java Card was invented in 1996 by Schlumberger [U.S. provisional application Serial No. 60/029,057, filed Oct. 25, 1996, non-provisional application No. 957512 filed on 10/24/1997, issued as patent US patent reference
number = 6308317
y = 2001
m = 10
d = 23
inventor = Wilkinson, Timothy J., Guthery, Scott B., Krishna, Ksheerabdhi, Montgomery, Michael A.
title = Using a high level programming language with a microcontroller] , and presented publicly October 29, 1996 ["Sun Microsystems Announces Java Card API ", Business Wire, Oct. 29, 1996] by several companies including former Schlumberger's card division (later Axalto) and Gemplus (both merged in [http://www.gemalto.com Gemalto] ). Java Card products are based on the Java Card Platform specifications developed by Sun Microsystems. Many Java card products also rely on the GlobalPlatform specifications for the secure download of applets on the card.

The main design goals of the Java Card technology are portability and security.Fact|date=July 2008

Portability

Java Card aims at defining a standard smart card computing environment allowing the same Java Card applet to run on different smart cards, much like a Java applet runs on different computers. As in Java, this is accomplished using the combination of a virtual machine (the Java Card Virtual Machine), and a well-defined runtime library, which largely abstracts the applet from differences between smart cards. Portability remains mitigated by issues of memory size, performance, and runtime support (e.g. for communication protocols or cryptographic algorithms).

Security

Java Card technology was originally developed for the purpose of securing sensitive information stored on smart cards.Security is determined by various aspects of this technology:
* Data encapsulation. Data is stored within the application, and Java Card applications are executed in an isolated environment (the Java Card VM), separate from the underlying operating system and hardware.
* Applet Firewall. Different applications are additionally separated from each other by an applet firewall which restricts and checks access of data elements of one applet to another.
* Cryptography. Commonly used encryption algorithms like DES, 3DES, AES, RSA (including elliptic curve cryptography) are supported. Other cryptographic services like signing, key generation and key exchange are also supported.
* Applet.The applet is a state machine which processes only incoming command requests and responds by sending data or response status words back to the interface device.

Java Card versus Java

Language

At the language level, Java Card is a precise subset of Java: all language constructs of Java Card exist in Java and behave identically. This goes to the point that as part of a standard build cycle, a Java Card card program is compiled into a Java class file by a Java compiler, without any special option (the class file is post-processed by tools specific to the Java Card platform).However, many Java language features are not supported by Java Card (in particular types char, double, float and long; the transient qualifier; enums; arrays of more than one dimension; finalization; object cloning; threads); and some features are a runtime option missing in many actual smart cards (in particular type int which is the default type of a Java expression; and garbage collection of objects).

Bytecode

Java Card bytecode run by the Java Card Virtual Machine is a functional subset of Java [Java 2 - Standard Edition] bytecode run by a Java Virtual Machine, but uses a different encoding optimized for size. A Java Card applet thus typically uses less bytecode than the hypothetical Java applet obtained by compiling the same Java source code. This conserves memory, a necessity in resource constrained devices like smart cards. As a design tradeoff, there is no support for some Java language features (as mentioned above), and size limitations. Techniques exist for overcoming the size limitations, such as dividing the application's code into packages below the 64 KB limit.

Library and runtime

Standard Java Card class library and runtime support differs at lot from that in Java, and the common subset is minimal. For example, the Java Security Manager class is not supported in Java Card, where security policies are implemented by the Java Card Virtual Machine; and transients (non-persistent, fast RAM variables that can be class members) are supported via a Java Card class library, while they have native language support in Java.

Development

Coding techniques used in a practical Java Card program differ significantly from that used in a Java program. Still, that Java Card uses a precise subset of the Java language speeds up the learning curve, and enables using a Java environment to develop and debug a Java Card program (caveat: even if debugging occurs with Java bytecode, make sure that the class file fits the limitation of Java Card language by converting it to Java Card bytecode; and test in a real Java Card smart card early on to get an idea of the performance); further, one can run and debug both the Java Card code for the application to be embedded in a smart card, and a Java application that will be in the host using the smart card, all working jointly in the same environement.

JavaCard 3.0

The version 3.0 of the JavaCard specification (released in March 2008) is separated in two editions: the "Classic Edition" and the "Connected Edition".
* The "Classic Edition" is an evolution of the Java Card Platform Version 2.2.2 and supports traditional card applets on more resource-constrained devices.
* The "Connected Edition" provides a new virtual machine and an enhanced execution environment with network-oriented features. Applications can be developed as classic card applets requested by APDU commands or as servlets using HTTP to support web-based schemes of communication (HTML, Restful, SOAP ...) with the card. The runtime supports volatile objects (garbage collection), multithreading, inter-application communications facilities, persistence, transactions, card management facilities ...)

References

See also

* GlobalPlatform
* Java Card OpenPlatform

External links

* [http://java.sun.com/products/javacard/specs.html Java Card Platform Specification (Sun Microsystems)]
* [http://java.sun.com/products/javacard/3.0/specs.jsp Java Card 3.0 Platform Specification (Sun Microsystems)]
* [http://www.javacardforum.org/ Java Card Forum]
* [http://globalplatform.org/ GlobalPlatform Specifications (GlobalPlatform)]