Software Development

Programming smart cards with the Java Card platform

Java Card is an open, interoperable platform for smart cards and secure tokens. Learn about the main features of this technology (portability and security), as well as its language restrictions.

The Java Card platform is the tiniest of Java targeted for embedded devices. It is an open, interoperable platform for smart cards and secure tokens; the technology is also widely used in SIM cards (it's used in GSM mobile phones) and ATM cards.

Java Card gives users the ability to program a device and make it application specific and lets smart card developers use a common card platform. Smart cards, unlike magnetic stripe cards, can carry all necessary functions and information on the card; therefore, they do not require access to remote databases at the time of the transaction.

The latest version of the Java Card is 2.2.2; it is ready for the next generation of smart card standards, and it's fully backward compatible with previous versions. Key benefits of Java Card 2.2.2 include: improved interoperability for cards with multiple communication interfaces; richer cryptography and security features; and standardized biometry support. It also provides a series of new APIs for a more memory efficient application development.

Applets

Java Card products are based on the Java Card platform specifications developed by Sun Microsystems. Applications written for the Java Card platform are named applets, just like Web applications. The term applet was chosen because of similarities in execution model with the standard Web-based applets.

Java Card aims to define a standard smart card computing environment, allowing the same Java Card applet to run on different smart cards (much like how 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 and security

The main features of the Java Card technology are portability and security. Portability remains mitigated by issues of memory size, performance, and runtime support (e.g., for communication protocols or cryptographic algorithms).

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, which include the following:

  • Applet: The applet is a state machine that processes only incoming command requests and responds by sending data or response status words backs to the interface device.
  • Cryptography: Commonly used encryption algorithms like DES, 3DES, AES, and RSA are supported. Cryptographic services like signing, key generation, and key exchange are also supported.
  • Applet firewall: Different applications are separated by an applet firewall that restricts and checks access of data elements of one applet to another.
  • Data encapsulation: Data is stored within the application. Java Card applications are executed in an isolated environment (the Java Card Virtual Machine), separate from the underlying operating system and hardware.

Differences in Java language

Due to strict hardware limitations, Java Card can support only a certain subset of Java languages. All language constructs of Java Card exist in Java and behave identically. As part of a standard build cycle, a Java 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).

Many Java language features are not supported by Java Card, such as types char, double, float, and long; the transient qualifier; enums; arrays of more than one dimension; finalization; object cloning; and threads. Also, 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.

Java Card bytecode run by the Java Card Virtual Machine is a functional subset of J2SE bytecode run by a Java Virtual Machine, but it uses a different encoding optimized for size. A Java Card applet typically uses less bytecode than the hypothetical Java applet obtained by compiling the same Java source code. This conserves memory, which is 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 there are size limitations. Techniques exist for overcoming the size limitations, such as dividing the application's code into packages below the 64 KB limit.

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; the Java Card Virtual Machine implements security policies. Transients (non-persistent, fast RAM variables that can be class members) are supported via a Java Card class library; they have native language support in Java.

Coding techniques used in a practical Java Card program differ significantly from what is used in a Java program. Java Card uses a precise subset of the Java language; this speeds up the learning curve and enables using a Java environment to develop and debug a Java Card program. Even if debugging occurs with Java bytecode, you should make sure that the class file fits the limitation of Java Card language by converting it to Java Card bytecode. Also, test in a real Java Card smart card early on to get an idea of the performance.

Additional resources about Java Card

Peter V. Mikhalenko is a Sun certified professional who works as a business and technical consultant for several top-tier investment banks.

---------------------------------------------------------------------------------------

Get Java tips in your inbox Delivered each Thursday, our free Java Developer newsletter provides insight and hands-on tips you need to unlock the full potential of this programming language. Automatically subscribe today!
8 comments
tucsongroup
tucsongroup

I am a recruiter working Java cards. Need more clients. I currently have a Java card developer that is looking. Please let me know if someone is interested in this candidate. Thanks. Tom Townsend of The Tucson Group (641) 923-2891 tucsongp@ncn.net

Jaqui
Jaqui

they finally came out with a decent Java version, FOR USE ON ANY COMPUTER, EXCEPT A PALMTOP. sorry, but a palmtop device, like a smartcard or smartphone, anything other than the base os, is BLOATWARE and needs to be thrown into the bit bucket where it belongs. any other version of Java, is bloatware and needs to be thrown into the bit bucket.

jessicap01
jessicap01

hi all, It has lot of useful and interesting data. ************** jessica, smart card

dgs010243
dgs010243

Pragmatic observations ! O, mon Java-girl, tu es une miragge. By the way, I can't explain the reduced number of free java hosting servers ! Can you recommend me such a FREE JSP/java hosting URL ? Sincerely, Dan Gheorghe

Shepps
Shepps

I like this article, but saving the link causes problems. It would seem that your tags field has a maximum length and hence all the tags which you suggest for this article cannot be saved. Thought I would point that out...

dawgit
dawgit

I'm glad that you've pointed out that small Java has been around for a while. (especialy over here in Europe) That being said, establishes Java as a reliable platform for small devices. It is "Tried and Proven". Your article / blog serves to keep such technology fresh in peoples minds. A Thanks for that. I wonder however, if the crypto that you say is going to be built-in, isn't a bigger library than that of the Java itself. In this: "Commonly used encryption algorithms like DES, 3DES, AES, and RSA are supported. Cryptographic services like signing, key generation, and key exchange are also supported.". That can be a rather large stack in itself. A question here, how does this differ from the Java ME that has been in devolopment for some time? You stated here "Coding techniques used in a practical Java Card program differ significantly from what is used in a Java program. Java Card uses a precise subset of the Java language...". I would like a comparision between those two. Again, (it)"is a functional subset of J2SE bytecode run by a Java Virtual Machine, but it uses a different encoding optimized for size. A Java Card applet typically uses less bytecode than the hypothetical Java applet...", isn't that the purpose of the Java ME? Strange that I haven't seem much of this on the Sun site. (Hence, some of my questions above.) Which makes your article /blog even more important. Good Work. Thanks for the additional resource list as well. (I've got some more reading to do this week-end). -d

Justin James
Justin James

Just as a heads up, J2ME is disappearing. Just thought I'd throw that out there, since you mentioned "small Java". J.Ja

dawgit
dawgit

for the tip. I haven't seen that yet. I'll keep an eye out. -d