Page 2 of 6
The structure of a smart card applet then became clear: The applet sits in a virtual loop, like a network service waiting
for packets to arrive on its network interface. The method that handles this loop is named process and is one of four required smart card applet methods. The other three are install, select, and deselect.
The install method must instantiate a new object that represents the applet. Like the main method in a Java application class, the install method is static so that it can be invoked by the smart card JVM before an object exists (it's invoked directly from the
class definition).
In the simplest sense, the select and deselect methods tell the applet to either "get ready" or "go to sleep." Actually, the select method has the option of refusing to be selected. For example, a personal identification number (PIN) or some other authorizing
information might need to be passed from the client program to the method (by way of the APDU) before the applet would allow
itself to be selected.
The deselect method, on the other hand, doesn't have the ability to deny being deselected -- it provides more of a courtesy to the applet,
telling it that it won't be getting any more packets. When a smart card is yanked from the reader before the client is finished,
the deselect method isn't even called. The next thing the applet will see will be another invocation of select.
Missing from all of this was, in my mind, support of Java objects. I had hoped that in the APDU one could just dump an object or two and have them show up in the ring. But object support isn't part of the package. Instead you get a byte array that you can copy data into, send, receive, and then copy the data back out of. Not as sophisticated as I might hope, but it's still more than enough for my little encryption engine.
After determining exactly what an APDU was and was not, I began to design the Java classes that would simulate an ENIGMA machine. Of course I first needed to figure out exactly how an ENIGMA machine worked, but that wasn't too difficult with the World Wide Web at my fingertips.
I surfed around and found pictures, a decent description of how it worked, a Java applet that was a pretty cool emulation of the machine, and even a patent relating to the machine (see Resources for links to these items). I found the patent to be particularly interesting because it was filed in 1944 but it didn't issue until 1976, over thirty years later! Curiously, 1976 is the same year that the U.S. Government officially adopted the Data Encryption Standard (DES) as its official encryption technology of choice. My guess is that the ENIGMA patent was classified as top secret until 1976, when the government stopped using cryptography based on the ENIGMA technology.
The basic algorithm behind the ENIGMA is known as a substitution cipher. A substitution cipher takes each input letter and substitutes a different letter for it. The resulting text looks like gibberish unless you know the secret substitution table that was originally used to scramble the message. This fact makes the ENIGMA a particularly good choice for my ringlet -- the secret decoder rings that we used to get in cereal boxes and Cracker Jacks-brand caramel popcorn were also based on substitution ciphers.