In a reasonable world, the JDK would contain a standard
java.crypto
package as part
of the core API. Regrettably, U.S. export laws prohibit the export of
cryptographic software without special permission. The regulations that
implement these laws have been loosened recently, but the laws are still in
place. Therefore, Java's security classes are divided between the
java.security
and javax.crypto packages
.
The latter must be downloaded separately from the JDK as part of the
Java
Cryptography Extension in order to comply with U.S. law.
Before you can download it, you have to fill out a form promising you're a resident of the
United States or Canada.
However, several third party implementations of the JCE
have been written outside the boundaries of
the United States and beyond the control of U.S. law,
including at least one open source package,
Cryptix.
These implementations are available around the globe to
anybody who wants them. Sun and the U.S. government
have no control over or involvement in the
development of these packages. At least until now.
Starting with version 1.2.1 of the Java Cryptography API, Sun has taken a new approach to keeping their software within the boundaries of the United States. The JCE uses the proxy design pattern. The interface exposed to the public through the JCE is not the code that actually performs encryption. The encryption and decryption are performed by separate code in a service provider package. Different service providers can offer different algorithms or different implementations of the same algorithms. For instance, a National Security Agency (NSA) service provider could include a backdoor so that the NSA could read all communications that were encrypted with that service provider. Sun includes a default service provider with its implementation of the JCE that supports a few standard algorithms. Since all actual cryptography is performed inside the service providers, whoever controls the service providers controls users' access to cryptography. This, in brief, seems to be Sun's plan.
The JCE 1.2.1 will only use service providers that are digitally signed and verified by a trusted authority. Sun can now bundle the JCE with all distributions of the JDK. However, the default service provider will be limited to export-grade encryption. New service providers can be installed, but only if they're trusted. Sun hasn't announced who the trusted authority or authorities are, but clearly the ultimate authority is Sun. Anybody Sun doesn't trust can't write a service provider for the JDK. More specifically, anybody Sun doesn't like or anybody who can't afford to pay the fees Sun charges won't be able to write service providers for the JCE 1.2.1.
Sun has not yet announced how they will decide who is and is not deserving of their trust. One thing Larry Baron, Senior Product Manager for Java Security at Sun Microsystems, was able to tell me is that "For providers intended to be exported, the provider vendor will first need to go through the U.S. government's export application process. Once the provider vendor has export approval from the government, they can request a JCE code signing certificate which they can use to sign their provider." In other words, only developers who are willing to adhere to U.S. export law will be trusted. This not only applies to U.S. citizens, who are after all already subject to U.S. law, but also to citizens of other countries. A provider in Ireland will only be trusted if it agrees to the U.S. restrictions on encryption strength for products exported outside of the U.S. and Canada.
Baron did tell me that "JCE 1.2.1 providers could be open source projects." However, it's hard to see how the secrecy and export requirements of the technology can coexist with the fundamental openness of free software. I suspect that in practice real open source projects will be locked out of the process.
Who should decide which cryptography providers to trust? Are we really willing to trust Sun to say who is and is not allowed to provide us with cryptography? This is a real concern. The NSA has repeatedly subverted commercial cryptographic providers in many countries. For instance, for many years the U.S. was able to read essentially all encoded Iranian communications because Iran used encryption hardware supplied by Crypto AG. The NSA had talked the allegedly neutral and trustworthy Swiss company into putting a backdoor into their code machines.1
I simply don't trust Sun not to build back doors into their software. A secret agreement between Sun and the NSA to deliberately weaken JCE cryptography is all too plausible. I have no information that any such agreement exists, but given Sun's close ties to the U.S. military-industrial-government complex and given Sun CEO Scott McNealy's avowed disregard for privacy ("You have zero privacy anyway, get over it"2), I'm simply not willing to entrust my confidential communications to Sun and the people it trusts. The NSA wields too much influence over the high-tech industry.
The best description of the NSA's approach to U.S. companies was published by Scott Shane and Tom Bowman in the Baltimore Sun in 1995. They quoted an unnamed government source, allegedly with "long experience in the field":
It is not unheard of for NSA to offer preferential export treatment to a company if it builds a back door into its equipment. I've seen it. I've been in the room. Generally with high-level executives it's an appeal to patriotism - how important it is for us to listen to the world. With the midlevel commercial types, it's, "Do this and we'll give you preferential export treatment." To the real technical people, it's, "Why don't you do this?" And you don't realize what's being suggested until you see the engineers are turning white. There's the threat: You'll never get another export approval if you don't start to play ball.3
There's one flaw in this premise, though, that adds some real hope for reliable, strong cryptography and the privacy it affords. In practice, Sun's control is limited. Although they can restrict which cryptography service providers are allowed to interface with their JCE, they can't restrict programmers from using other APIs to provide unapproved cryptography. To a large extent they can't even stop people from producing independent implementations or hacked versions of the JCE that don't require service providers to be trusted.
However, there's a deeper issue here: Sun can use mathematically strong cryptography to guarantee that third party, clean-room Java implementations are incompatible. For now, they're only doing this for the JCE, and exactly how broadly they intend to wield this big stick remains to be seen. Baron says that Sun has not considered using code signing "for functionality that's in the JDK, because code signing has a cost in terms of runtime performance and administrative overhead." But what happens when CPUs become fast enough that this is no longer an issue? Baron also pointed out that the Java Plug-In already "uses code signing to verify Optional Packages before automatically installing them."
Although this
technique first appeared in the context of the Java Plug-In
and the JCE, there's no technological reason
Sun can't extend this approach to the rest of the JDK and class library. It
would be trivial for Sun to require that not just JCE service providers, but all
classes in the java
and javax
packages be digitally
signed. Then they could stop worrying about annoyances like Kaffe or HP's Chai
VM, and guarantee compatibility and control of Java through technological means.
I doubt they could restrict the Java that's already out there, but they could
certainly do this for future releases.
Open source and other hackers
could simply write JVMs
that didn't perform these checks. However, this would force developers to choose
between writing for official Sun-supported VMs and the unofficial VMs. Given the
relative percentage of Sun-derived VMs vs. open source VMs in the installed
base, the choice most developers would make is obvious. Again, I don't know that
Sun has any plans to do anything like this outside of the JCE, but I do think
doing it in the JCE sets a dangerous precedent.
I am not opposed to digitally signed code. In fact, I think it's critical for high security applications. However, the decision about who to trust and whose signature to accept should be in the hands of the end users, not the software vendors. Letting a software vendor, be they Sun, Microsoft, Apple, or someone else, decide what software you can use is a mistake. The next step would be letting them decide what you can do with the software, something they're still trying (and failing) to enforce through license agreements. We need to establish a clear principle that end users decide who to trust. A software vendor can make suggestions about who it thinks is trustworthy, but it should not be allowed to impose those decisions on other developers and end users unilaterally.
2 This remark was made on January 25, 1999 at the JINI launch and was widely reported in the press including Wired News
3 Reported by Scott Shane and Tom Bowman in Rigging the Game, Baltimore Sun, Sunday, December 10, 1995, p. 1A, Online at News Library for a $1.95 fee.