A couple of weeks ago I joined a project that involved javacard technology. A search for ‘javacard’ on this site returned the rather disappointing ‘Sorry, no posts matched your criteria.’ on my screen. Today, there are literally billions of smartcards on the market and a large portion of them are javacards! Reason enough to add a javacard blog to this site, starting with a quick introduction into smartcards.
A smart card is nothing more than a chip (the ’smart’ portion) on a piece of plastic (the ‘card’ portion). Usually it doesn’t have a power supply, keyboard, mouse or display attached to it. To communicate with the outside world, it is placed in or nearby a ‘card acceptance device’ (CAD) that is connected to a computer. This setup creates all kinds of business opportunities like: identification and physical access (event- and travel ticketing), financial transactions, discount card, membership card, pre-paid cards, etc.
Enter java card. Java card technology enables programmers to write software for smart cards in the java programming language. The javacard programming environment, - virtual machine and - runtime environment can be looked upon as the light versions of their big brothers. Among other things, javacard technology doesn’t support garbage collection, threads, ints, longs, doubles, floats, strings and multi-dimensional arrays. Yikes! Programming javacard applications (applets) made me count my blessings. The normal, well-known java programming environment is really quite fancy! A simple task like subtracting € 3.25 in a javacard e-wallet applet already forces you to juggle with a couple of shorts. No floats or doubles, remember!
Figure 1 - javacard application architecture
However, expressing yourself in a much more primitive environment isn’t so bad at all. It’s amazing how fast you can get used to an environment that lacks the common tools. For example: the java card communicates with a CAD using a byte oriented protocol. The CAD sends a command APDU (Application Protocol Data Unit) to the card and the card sends a response APDU in return. Figure 1 provides the reader with an overview of the components of a typical javacard application. So instead of calling a simple method like ’subtract(3.25)’, you could be sending the lovely APDU byte array ‘80 01 AE 0D 04 00 03 19 05′. When I was demonstrating an applet to a colleague I heard myself saying: ‘You see: the card returns 03 FF 4C 00 19 90 00; it works!’. Of course he thought I had taken leave of my senses, but the point I’m trying to make is that �the human mind’ gets used to these circumstances pretty quickly. Maybe a debug file would be nicer, but when necessary, ‘03 FF 4C 00 19 90 00′ will do.
Taken together, programming with handicaps isn’t so bad. And because there’s such a huge market out there, the next time you feel like surfing the web, I suggest you skip youtube and take a look at some nice introductions into smartcards and javacards. Programming with more tools isn’t always necessarily better, and programming with less tools can be a nice challenge. Remember Maslows quote ‘When all you’ve got is a hammer, every problem starts looking like a nail’. It sure does!
March 23rd, 2007 at 1:55 pm
well, would it be possible to tell what brand and type of card have you used? also i think there is a Java smart card io API available in Sun’s JDK 6.
March 27th, 2007 at 3:02 am
Hi.
Thanks for referring to my article above; I am glad you found it a nice introductions… Yes there are other APIs to consider, such as SATSA and a newer Smart Card API for J2SE (JSR 268, Smart Card I/O API).
You can find more about Java Card, and SATSA at my website thanks.
ceo
March 27th, 2007 at 10:21 am
Hi Afsina,
In our project we’re using a SmartMX card featuring JCOP. The card is integrated into a (yet to be released) samsung phone that has a NFC Chip on board. This setup makes near field communication solutions possible.
And yes, there’s a smart card API available in java 6. Look at it closely and you’ll see it’s filled with byte(array)s. Although the API seems to support ints, the following can be read in the command APDU class comment: �For the header bytes CLA, INS, P1, and P2 the Java type int is used to represent the 8 bit unsigned values. In the constructors, only the 8 lowest bits of the int value specified by the application are significant. The accessor methods always return the byte as an unsigned value between 0 and 255.’