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!
