Welcome!

Java IoT Authors: Liz McMillan, Pat Romanski, Yeshim Deniz, Zakia Bouachraoui, 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) View Comments

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.


Most Recent Comments
Michael Yuan 11/05/02 06:20:00 PM EST

Although I liked NTRU a lot and think their fast PK algorithms have a real future in the mobile space, it is still worth to note that NTRU algorithms are relatively young. A few weaknesses have been found in the past year.

Any new crypto algorithm must go through peer review processes and fix all holes before it is robust. I hope NTRU will go through this quickly. But for users, security is leaving nothing to chance ...

Dave Bowker 11/04/02 05:43:00 PM EST
IoT & Smart Cities Stories
René Bostic is the Technical VP of the IBM Cloud Unit in North America. Enjoying her career with IBM during the modern millennial technological era, she is an expert in cloud computing, DevOps and emerging cloud technologies such as Blockchain. Her strengths and core competencies include a proven record of accomplishments in consensus building at all levels to assess, plan, and implement enterprise and cloud computing solutions. René is a member of the Society of Women Engineers (SWE) and a m...
Early Bird Registration Discount Expires on August 31, 2018 Conference Registration Link ▸ HERE. Pick from all 200 sessions in all 10 tracks, plus 22 Keynotes & General Sessions! Lunch is served two days. EXPIRES AUGUST 31, 2018. Ticket prices: ($1,295-Aug 31) ($1,495-Oct 31) ($1,995-Nov 12) ($2,500-Walk-in)
Andrew Keys is Co-Founder of ConsenSys Enterprise. He comes to ConsenSys Enterprise with capital markets, technology and entrepreneurial experience. Previously, he worked for UBS investment bank in equities analysis. Later, he was responsible for the creation and distribution of life settlement products to hedge funds and investment banks. After, he co-founded a revenue cycle management company where he learned about Bitcoin and eventually Ethereal. Andrew's role at ConsenSys Enterprise is a mul...
Nicolas Fierro is CEO of MIMIR Blockchain Solutions. He is a programmer, technologist, and operations dev who has worked with Ethereum and blockchain since 2014. His knowledge in blockchain dates to when he performed dev ops services to the Ethereum Foundation as one the privileged few developers to work with the original core team in Switzerland.
Digital Transformation and Disruption, Amazon Style - What You Can Learn. Chris Kocher is a co-founder of Grey Heron, a management and strategic marketing consulting firm. He has 25+ years in both strategic and hands-on operating experience helping executives and investors build revenues and shareholder value. He has consulted with over 130 companies on innovating with new business models, product strategies and monetization. Chris has held management positions at HP and Symantec in addition to ...
The challenges of aggregating data from consumer-oriented devices, such as wearable technologies and smart thermostats, are fairly well-understood. However, there are a new set of challenges for IoT devices that generate megabytes or gigabytes of data per second. Certainly, the infrastructure will have to change, as those volumes of data will likely overwhelm the available bandwidth for aggregating the data into a central repository. Ochandarena discusses a whole new way to think about your next...
CloudEXPO | DevOpsSUMMIT | DXWorldEXPO are the world's most influential, independent events where Cloud Computing was coined and where technology buyers and vendors meet to experience and discuss the big picture of Digital Transformation and all of the strategies, tactics, and tools they need to realize their goals. Sponsors of DXWorldEXPO | CloudEXPO benefit from unmatched branding, profile building and lead generation opportunities.
Dynatrace is an application performance management software company with products for the information technology departments and digital business owners of medium and large businesses. Building the Future of Monitoring with Artificial Intelligence. Today we can collect lots and lots of performance data. We build beautiful dashboards and even have fancy query languages to access and transform the data. Still performance data is a secret language only a couple of people understand. The more busine...
All in Mobile is a place where we continually maximize their impact by fostering understanding, empathy, insights, creativity and joy. They believe that a truly useful and desirable mobile app doesn't need the brightest idea or the most advanced technology. A great product begins with understanding people. It's easy to think that customers will love your app, but can you justify it? They make sure your final app is something that users truly want and need. The only way to do this is by ...
DXWorldEXPO LLC announced today that Big Data Federation to Exhibit at the 22nd International CloudEXPO, colocated with DevOpsSUMMIT and DXWorldEXPO, November 12-13, 2018 in New York City. Big Data Federation, Inc. develops and applies artificial intelligence to predict financial and economic events that matter. The company uncovers patterns and precise drivers of performance and outcomes with the aid of machine-learning algorithms, big data, and fundamental analysis. Their products are deployed...