Welcome!

Java IoT Authors: TJ Randall, Liz McMillan, Zakia Bouachraoui, Pat Romanski, Elizabeth White

Related Topics: Java IoT

Java IoT: Article

Unlimited Encryption on Limited Devices

Unlimited Encryption on Limited Devices

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!

Mobile Security
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 being used.

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 CLDC­compatible 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.

More Stories By Bill Ray

Bill Ray, former editor-in-chief (and continuing distinguished contributor to) Wireless Business & Technology magazine, has been developing wireless applications for over 20 ears on just about every platform available. Heavily involved in Java since its release, he developed some of the first cryptography applications for Java and was a founder of JCP Computer Services, a company later sold to Sun Microsystems. At Swisscom he was responsible for the first Java-capable DTV set-top box, and currently holds the position of head of Enabling Software at 02, a UK network operator.

Comments (2)

Share your thoughts on this story.

Add your comment
You must be signed in to add a comment. Sign-in | Register

In accordance with our Comment Policy, we encourage comments that are on topic, relevant and to-the-point. We will remove comments that include profanity, personal attacks, racial slurs, threats of violence, or other inappropriate material that violates our Terms and Conditions, and will block users who make repeated violations. We ask all readers to expect diversity of opinion and to treat one another with dignity and respect.


IoT & Smart Cities Stories
At CloudEXPO Silicon Valley, June 24-26, 2019, Digital Transformation (DX) is a major focus with expanded DevOpsSUMMIT and FinTechEXPO programs within the DXWorldEXPO agenda. Successful transformation requires a laser focus on being data-driven and on using all the tools available that enable transformation if they plan to survive over the long term. A total of 88% of Fortune 500 companies from a generation ago are now out of business. Only 12% still survive. Similar percentages are found throug...
AI and machine learning disruption for Enterprises started happening in the areas such as IT operations management (ITOPs) and Cloud management and SaaS apps. In 2019 CIOs will see disruptive solutions for Cloud & Devops, AI/ML driven IT Ops and Cloud Ops. Customers want AI-driven multi-cloud operations for monitoring, detection, prevention of disruptions. Disruptions cause revenue loss, unhappy users, impacts brand reputation etc.
At CloudEXPO Silicon Valley, June 24-26, 2019, Digital Transformation (DX) is a major focus with expanded DevOpsSUMMIT and FinTechEXPO programs within the DXWorldEXPO agenda. Successful transformation requires a laser focus on being data-driven and on using all the tools available that enable transformation if they plan to survive over the long term. A total of 88% of Fortune 500 companies from a generation ago are now out of business. Only 12% still survive. Similar percentages are found throug...
Atmosera delivers modern cloud services that maximize the advantages of cloud-based infrastructures. Offering private, hybrid, and public cloud solutions, Atmosera works closely with customers to engineer, deploy, and operate cloud architectures with advanced services that deliver strategic business outcomes. Atmosera's expertise simplifies the process of cloud transformation and our 20+ years of experience managing complex IT environments provides our customers with the confidence and trust tha...
The Japan External Trade Organization (JETRO) is a non-profit organization that provides business support services to companies expanding to Japan. With the support of JETRO's dedicated staff, clients can incorporate their business; receive visa, immigration, and HR support; find dedicated office space; identify local government subsidies; get tailored market studies; and more.
At CloudEXPO Silicon Valley, June 24-26, 2019, Digital Transformation (DX) is a major focus with expanded DevOpsSUMMIT and FinTechEXPO programs within the DXWorldEXPO agenda. Successful transformation requires a laser focus on being data-driven and on using all the tools available that enable transformation if they plan to survive over the long term. A total of 88% of Fortune 500 companies from a generation ago are now out of business. Only 12% still survive. Similar percentages are found throug...
As you know, enterprise IT conversation over the past year have often centered upon the open-source Kubernetes container orchestration system. In fact, Kubernetes has emerged as the key technology -- and even primary platform -- of cloud migrations for a wide variety of organizations. Kubernetes is critical to forward-looking enterprises that continue to push their IT infrastructures toward maximum functionality, scalability, and flexibility. As they do so, IT professionals are also embr...
In his general session at 19th Cloud Expo, Manish Dixit, VP of Product and Engineering at Dice, discussed how Dice leverages data insights and tools to help both tech professionals and recruiters better understand how skills relate to each other and which skills are in high demand using interactive visualizations and salary indicator tools to maximize earning potential. Manish Dixit is VP of Product and Engineering at Dice. As the leader of the Product, Engineering and Data Sciences team at D...
As you know, enterprise IT conversation over the past year have often centered upon the open-source Kubernetes container orchestration system. In fact, Kubernetes has emerged as the key technology -- and even primary platform -- of cloud migrations for a wide variety of organizations. Kubernetes is critical to forward-looking enterprises that continue to push their IT infrastructures toward maximum functionality, scalability, and flexibility.
Today's workforce is trading their cubicles and corporate desktops in favor of an any-location, any-device work style. And as digital natives make up more and more of the modern workforce, the appetite for user-friendly, cloud-based services grows. The center of work is shifting to the user and to the cloud. But managing a proliferation of SaaS, web, and mobile apps running on any number of clouds and devices is unwieldy and increases security risks. Steve Wilson, Citrix Vice President of Cloud,...