This week, we're looking forward again, so to speak. Even though it may be months before the new version of Java comes out of beta and into your latest version of Netscape, it's almost a certainty that it will, and probably any amount of attention paid to the ramifications of this (which are many and varied) is not enough.
In our last issue on this subject, we talked in broad strokes about some of the most important revisions to Java--speed-related, AWT-related, and otherwise. There are other major new additions that we need to mention before we dive into specific examples.
Arguably another one of the most important changes in 1.1 is the new layer of security measures added in Java. We've talked about security in the past; we didn't expect a miracle, and we didn't get it. We did, however, get another quite sensible set of security measures, implemented with some amount of penache.
In the distant past, we've actually gone so far as to make a small comparison between Java and ActiveX. We hinted at but didn't really explore previously the difference between their security models. One similarity between these two products is that they're frequently used as arbiters for the prodigious automated transfer of program fragments from one machine to another; yet they both take very different approaches to making sure the code they transfer is unlikely to do any harm.
Let's be blunt. We take the position (and we're quite ready to defend it) that Java's approach was probably a far better one, even from the outset. Java, as you know, takes a (academically speaking) strong and thorough approach to access control between applets and their host system, whereas ActiveX doesn't even make an attempt--instead, there is simply a protocol for verifying (with a cryptographically questionable system) where your ActiveX objects are coming from. Microsoft's justification for this is that, just as when you purchase software from a store in the mall, you trust the supplier and take the rest on faith.
This is all well and good, but personally our advice is trust as little as you have to. We think the Java team must agree; in the new version, they've provided the ability to digitally sign your code, providing (theoretically at least) assurance of its origin, in addition to Java's primary security measures. Not only that, but it's also possible (and easy) to sign entire JAR archives (which we mentioned recently) so that you can sign entire sets of classes (and their associated data files, which is frequently just as important) all together.
To implement digital signatures in a scalable, flexible, and platform-independent fashion, they wrote everything in Java--and you, the end-Java programmer, get to reap the fringe benefits. Almost all of the classes written to make the change happen are available for you to use yourself as well: data structures suitable for access control systems, classes that implement key and certificate management by the X.509v1 protocol (a going standard), one-way hashing and encryption functions of all kinds, and something called the "Security Provider Architecture." All are part of a system for easily and automatically abstracting various security techniques such as encryption and certification from your (and the JVM's) code. This last item would make it easy for new cipher and hash routines to be written by others (whether in Java or not) and to be seamlessly integrated.
These new features are, of course, as timely as they are pleasant. More field testing by the Java Jolt team will be necessary before we can give a firsthand report on their reliability, but thus far we've found nothing amiss. Perhaps even more hearteningly, as evidenced in the updated Java Security FAQ, Sun has been fairly scrupulous about repairing all of the more obscure, low-level security problems in Java 1.0 in the new release. Specifically, Sun claims to have repaired the weaknesses that those stout of heart who write their own bytecodes by hand had uncovered in the class loader and typing system.
Of course, lest someone construe that we've endorsed the techniques used in JDK 1.1's security model, let us clarify that, although this is arguably the best integrated security model we've seen in this venue, it still has acknowledged flaws--some of which are philosophical, and we've already talked about them. More than that, however, as any true techno-snob can tell you, no encryption (and certainly, by extension, no certification system) is provably secure. And a false sense of security is probably the most dangerous security hole of all.
Although it's somewhat beyond our purview, let us briefly mention that a group of European students are reputed to have already managed to factor a Netscape "commercially secure" private cryptographic key. Admittedly this is not entirely surprising, as U.S. export restrictions prevent the widespread use of adequately strong encryptions in publicly available software. More recently, however, researchers at Bellcore have begun to publicize a technique known as Differential Fault Analysis, enabling them to exploit certain flaws in solid-state computer architectures to break codes previously thought to be completely secure in the nonmilitary world--codes, incidentally, reputed to be so secure that the nuclear arsenal of the United States is protected with them. Our point? Your security, on the Internet or off, is not only never assured, but usually worse than you think it is. Just something to keep in mind.
Next week, we'll continue to examine the issues on the road to the Java upgrade. Check out the new Java Security Overview page, and check back next week for some more commentary on the cutting edge of Java.
