If you are using Java in your products, and rely on its security features, you will probably find 2017 to be an interesting year. Java is expecting major changes and upgrades with the long awaited release of Java 9, as well as Enterprise Edition 8, which hopefully won't get any additional delays. With security being a topic with ever-increasing importance in today's businesses and related IT solutions, what does Java bring with regard to it? Here is a short overview.
The Cryptography Roadmap
Oracle maintains its Java Cryptography Roadmap, showing an overview of what changes can be expected in future releases regarding JRE/JDK security algorithms and related policies. Weaker algorithms are constantly being deprecated and are no longer accepted as valid. For example, signed JARs using MD2, or RSA with keys shorter than 1024 bits, are being treated as unsigned since 8u111, and MD5 is finally expecting the same fate with next release targeted for this April.
Various other things are changing, and sometimes not all changes are obvious or transparent. This January we got the 8u121 update and there are many features listed in the area of Security, most having to do with restricting lower-sized keys and weaker algorithms. But if, for example, you are using the Microsoft Crypto API provider for accessing certificates stored in Windows, you may have noticed that this old piece of code got some TLC as well. Java has finally stopped showing those relentless “insert a smart card” pop-ups to confused end-users each time your app tried to list available keys. Another issue with MSCAPI, where it was not able to work with duplicate alias names (and for some reason Microsoft allows this) had already been resolved a couple of months ago in 8u92.
While all these improvements are pretty much the result of natural evolution of algorithms and core code, one small gem is to be released this October (8u152), and also as standard in Java 9. Unlimited crypto policies (JCE) should finally be shipped with JDK updates, without the need to download them separately. If you are working with strong cryptographic algorithms - and, if not, you should - this is a very important upgrade. The unlimited crypto policy will not be enabled by default, but at least you should be able to enable them dynamically by setting the appropriate security property at runtime.
The Death of the Applet
You are working with Java? But isn’t Java insecure?
I was quite surprised to be asked this question by a CISO of a somewhat larger bank not long ago. It turns out he was thinking of Applets, being quite unaware of what Java as a technology actually is, or how much it is relied upon in most enterprise systems. Many overhyped articles regarding Java (Applet) (in)security did not help much.
Applets did their job when they had to, but stayed in business for a lot longer than they should have. Over the years, to many end-users Java itself became synonymous to security risks because of its “Java Plugin” technology. Chrome stopped supporting it a long time ago, and Mozilla plans to do the same with Firefox 52 this March (unless you are using their Extended Support Release - then the plugin should be available until May 2018). Nevertheless, Oracle itself is deprecating Applets with Java 9, which should be released and made available to the general public by the end of July.
“Moving to a plugin-free web” is great, but if you are dealing with security and cryptography - for example for document signing - you may be facing a problem. Accessing smart cards or usb tokens does not have a developed and stable web-centric alternative. Working with keys is either a pain or impossible. There is the Web cryptography API, but smart cards are out of its scope. And WebCrypto Key Discovery API is not helping either.
What are the alternatives? You may resort to building browser plugins or standalone apps, however this results in increased development effort and maintenance costs. You might also try and force users to keep an older browser version to continue running your applets, but good luck with that.
Oracle suggests moving to Webstart - and this may turn out to be the best choice. From the end-user perspective, Webstart has been much easier to launch since 8u72, and is much more secure with mandatory code signing and the removal of weaker algorithms. What you get to keep is the “code once, run everywhere” paradigm, but, on the downside, you also keep those “please update Java” popups (which are finally becoming more user-friendly).
A New Security API for Java Enteprise
Java Enterprise approach to security is getting old and should get a significant upgrade with the release of EE 8. The Java EE Security API - JSR 375 - should be the answer to modern challenges.
The new API was proposed back in 2015 with the aim of removing the need for vendor-specific Java EE security configurations and modernizing approach to security by providing a new and standardized Security API. The API uses programming approaches such as expression language, contexts and dependency injection in an attempt to simplify and standardize the Security API across the platform. Self-contained security declaration also significantly improves application portability.
Standardized user management, password aliasing, role mapping, as well as multiple authentication and authorization enhancements represent many features that Java EE Security API promises to bring. It is important to note that traditional “declarative and programmatic” security approaches will not be removed. They will however get a much more appealing alternative, perhaps not to the full extent with version 1.0, but definitely in years to come.
The reference implementation for Java EE Security API is called Project Soteria. If you wish to explore and play with new features, Soteria test page contains nice samples demonstrating how the API works and what the framework can do.
With rising security challenges and projects of ever-increasing complexity, it seems that Java is going strong in its 22nd year. It’s going to be interesting to see how things develop.