I have the dubious honor of having written one of the very first
implementations of the RSA cryptographic algorithm in Java some years ago,
and very badly I wrote it too.
With a 4-bit key it worked great, with an 8-bit key it took about 30
minutes to encrypt or decrypt anything, and after three days of trying with
a 16-bit key, we had to use the computer for something else. Just to give
you some idea, even back then 128 bits was considered the minimum for secure
communications, and each bit doubles the time. Cryptography is not fast; its
security is bound up in the complexity of its algorithms. Those who are
writing modern cryptography need to be much better mathematicians than I. Of
course, Java is not a fast language as Java developers, the price we pay
for platform independence and stability is speed so writing cryptography
in Java doesn't make a lot of sense on the surface.
On servers it's a relatively simple matter to add another processor, and
even today's desktop systems have no problems running (efficiently coded)
cryptography routines in Java, but mobile devices have enough trouble just
updating the screen and responding to inputs. Getting Java working is hard
enough in such constrained environments, but adding cryptography to the Java
mix on a mobile device is surely madness!
Getting decent cryptography onto mobile devices has been an aim for a
long time; while SSL (or TLS, as it's now known) provides for most of our
security needs on the desktop, the algorithms and processes it uses are
often beyond the ability of the devices in our pockets. Mobile telephones,
in particular, are changing into mobile payment devices in the first stages
of the long-awaited move to an electronic currency. PayBox is already
offering a service enabling payment, both on- and offline, via a GSM mobile
telephone, while car-parking meters in the north of England can be reset
from a mobile phone. Users are realizing that their mobile phone can do a
lot more for them, but current systems are clumsy and often expensive to
run, not to mention that when I want to buy something from a shop, it's
insane that the shopkeeper and I both have to make phone calls to a central
server to authorize the payment.
Technologies like Bluetooth are providing a conduit for more direct
interaction a mobile wallet in a Bluetooth-equipped mobile telephone could
be used to pay for goods in shops, and even automatically authorize payment
for transport without user involvement. In this environment, mobile
telephones have one great advantage over PDAs: they're always on, ready to
respond to incoming requests or scheduled events.
The barriers to such usage, while temporary, are considerable. The cost
of an infrastructure to implement such a payment system is massive, but the
lack of standardization is the primary problem. Once everyone is using a
standard payment system (perhaps a new Bluetooth profile?), we'll see a mass
deployment of mobile payment systems; until then they'll be limited to
corporate installations and arcologies, but even then only if strong
encryption can be deployed on devices like mobile phones and is available to
application developers. GSM mobile phones have a Subscriber Identity Module
(SIM) that is often capable of dealing with strong cryptography, but it's
also under the complete control of the network operator (for sound
commercial reasons) and is rarely available to anyone else.
Why Use Java?
Speed is not the only thing that counts against Java when considering
cryptography; memory safety is another issue that has never been
satisfactorily resolved. Cryptography is generally based around keys, and
security is managed by limiting access to certain keys and ensuring those
keys are defended against attack. Applications like Pretty Good Privacy
(PGP) store the keys, which are encrypted using a passphrase as a key to
decode them, on a desktop computer's hard drive; but while the keys are
being used they are in memory and could, in theory, be accessed by another
application running at the same time, depending on the operating system
In C it's possible to take steps against such theft, but in Java the
programmer has almost no control of the memory, and keys held in RAM could
conceivably be read by another application. Even worse, if the encryption
program is relying on Java garbage collection, there's no telling how long
those keys will actually exist in memory; they could even find themselves
paged into virtual memory (on the hard drive) where they might hang about
for months before that part of the hard drive is used again!
Java implementations of cryptography generally recommend not using
virtual memory, and a modern desktop operating system should provide some
memory protection to separate processes, but handheld systems rarely have such protection. Even though being paged to a hard drive isn't a problem, having keys hanging about in memory is not an ideal situation.
Working around these problems isn't easy, so there must be a significant
advantage to make Java worthwhile, and it is platform independence that
provides that advantage. On desktop computers we have to deal with two or
three different operating systems. Even on PDAs there are only three or four
to worry about, but on mobile telephones things are a lot more complicated.
Symbian has taken great strides with EPOC (their OS), but Palm and WinCE are
vying for some market share, not to mention the half-a-dozen proprietary
operating systems that are still being used. Even code written in ANSI C
can't be relied on to work with every mobile phone. Java is rapidly emerging
as the true cross-hardware application platform. Many phones don't actually
have the capability to install and remove applications, but even those are
moving toward being able to execute MIDlets, opening Java to everything but
the most basic handsets.
Java cryptography certainly would be useful for limited devices, and the
Connected Limited Device Configuration would seem ideal, but getting RSA, or something similar, working at an acceptable speed would be close to impossible...which brings us to NTRU.
A Different Solution
NTRU was started in 1996 to capitalize on the development by the
founders of a new encryption algorithm designed to minimize processing
requirements and run on limited devices. In the field of cryptography there
are many companies offering "secret" algorithms that they claim are
breakthroughs. However, we generally take "secret" to mean "untested," as
peer review is the only way for an encryption system to be proved secure. It
is, of course, impossible to prove that an encryption system is secure; you
can only prove that you personally can't break it (which, if you are me, is
no great recommendation). When looking at an encryption algorithm it's
important to know that reputable people in the field have attacked it and
can't break it. NTRU has spent a few years doing that, relying on a patent
to protect its IPR and working with the cryptography industry to demonstrate
the strength of its algorithm.
Even with a much-improved algorithm, getting something small enough and
fast enough for CLDC devices isn't easy. Trying to do it in Java isn't
likely to make it any easier. Even NTRU didn't start in Java; it offers
implementations in a variety of languages and on some very small devices,
including RFID tags and Smart Cards. But as already discussed, it's the
mobile phone explosion that presents the most interesting and potentially
profitable application of encryption and Java is the only effective way of
reaching those platforms.
Having decided to work on a Java implementation of NTRU's algorithm,
there's the minor matter of which version of Java to support. The days of
just being "Java compatible" are long gone, and now there seems to be almost
as many versions of Java as there were programming languages that Java was
supposed to replace! Most of the mobile phones support at least the CLDC
specification, so that was a logical place to start.
The NTRU algorithm doesn't require floating point mathematics, which
helps, and being an encryption library it has no graphical requirements so
it should be usable on all versions of Java, once developed for the CLDC.
Indeed, the same core encryption and decryption code is used on both the
server and client sides (the server is designed to run under J2SE and
provides the same cryptographic services as the client).
As the algorithm had already been implemented in several languages, the
port of the core code to Java was completed in a few months by a small team
of developers, though testing and integration took considerably longer.
Embedded developers still have very little choice in terms of working
environment, so the Wireless Toolkit from Sun represents state-of-the-art.
NTRU uses Visual Café for its server-side development, as this appears to
produce faster compiled code, but on the CLDC side, text editors and
command-line compilers are the order of the day.
Worse is the lack of debugging or remote testing environments. While
desktop objects may contain their own test harnesses or be loaded into test
containers, when your whole application is supposed to be under 5KB it's not
easy to get testing in there too. In fact, when you're working under such
constraints there are good arguments against object-orientation, and the
core of NTRU's cryptographic code reflects this philosophy. By explicitly
creating a memory context and managing variables within that context, it
hopes to avoid the persistence problems inherent in Java applications, and
in most cases it should be right. By avoiding object methodologies, NTRU can
also avoid dependence on the Java garbage collector, which can be an
unreliable beast at the best of times especially on embedded platforms.
NTRU also decided not to support the JCE. The Java Cryptographic
Extension is a mechanism that allows suppliers of cryptography to integrate
their libraries in a standard way with Java applications. The API is
certainly flexible, allowing detailed control of the cryptographic process,
but some would claim that flexibility has led to excessive complexity and
made the API difficult to use. People who work in cryptography regularly
might find the JCE pretty intuitive, but Java programmers just want to be
able to encrypt and decrypt without worrying about the messy details. There
is the argument that such programming should only ever be done by
professionals, but back in the real world we all want a simple API. There's
also the issue that the JCE is not supported by the CLDC, and implementing
it would have made the NTRU code much bigger.
Getting cryptographic routines into a 5K CLDCcompatible library is very
impressive, but it's not going to solve most of the problems with the
scenarios discussed at the beginning of this article. The ability to encrypt
communications and provide digital signatures (to enable proof-of-identity,
essential for any m-commerce system) is only part of the problem; there's
still the issue of where and how the keys will be stored. There is no point
in providing wonderfully secure communications when the encryption keys have
to be downloaded over an insecure link, so keys will have to be stored
somewhere on the device and in a secure manner.
Most of the J2ME mobile telephones being launched at the moment have
only the ability to run downloaded Java code. MIDP application installation
and management is generally kept to a minimum to ensure the simplicity of
the user interface, and file management is often nonexistent. MIDP specifies
that data can be stored locally, but the developer has no idea where
(physically) that data will be stored and so can't rely on it being secure.
NTRU is in the process of approaching handset manufacturers about finding
some secure space on their handsets for key storage, but again the lack of
standardization causes problems. Manufacturers will need a lot of convincing
to embed facilities for NTRU in their handsets, especially when NTRU will be
collecting a license on every device using its algorithm. Not to mention,
once we're talking about putting things into the handsets, we might as well
embed some cryptographic hardware.
Doing the encryption in hardware is inherently more secure than leaving
it to the software, and this issue is not limited to mobile devices. As the
recent releases about Palladium make clear, the only way to secure any
system is to embed the cryptography at a hardware level. GSM mobile phones
have a cryptographic chip already embedded in the form of a SIM chip, and if
we're going to add cryptographic functions, this is the sensible place for
them. While the NTRU algorithm may well be a revolution, and getting it
working in Java is spectacular, the practicality and usefulness of a layered
security model remain to be seen. We'll certainly see the NTRU algorithm in
many places, but it's still hard to see Java being one of them.
Bill Ray has worked for several telecommunications companies around Europe, including Swisscom where he was responsible for the development of their Java-compatible DTV platform. He is security editor for Wireless Business & Technology and coauthor of Professional Mobile Java Development, published by Wrox Press.