start page | rating of books | rating of authors | reviews | copyrights

Chapter 13. Encryption

In this chapter, we'll examine the Java Cryptography Extension, which provides (among other things) an engine to perform encryption of arbitrary data. This engine allows developers to send and receive encrypted streams of data over the network or through a filesystem (subject to some export restrictions we'll also discuss).

The encryption engine we'll discuss in this chapter does not come with the JDK. Information in this chapter is based on the early access 2 release for JDK 1.2[1] of the Java Cryptography Extension (JCE); because it is an early access release, the information is subject to change when JCE is officialy released (tentatively scheduled for mid-1998). The JCE introduces four new engine classes to the Java security architecture--one to perform encryption, and three that handle keys for encryption--and it comes with a new security provider to implement those classes. We'll discuss all of these features in this chapter.

[1]1.2 is now Java 2.

13.1. Export Restrictions

Use of the JCE is strictly limited by the export restrictions of the U.S. government. Sun Microsystems is headquartered in the United States, so the export of the JCE is controlled by the U.S. government. Because this implementation is capable of strong encryption, the only countries where it may be used are the United States and Canada.

There are ongoing legal challenges to this position as well as increasing negotiations with the U.S. government to change this policy; at the same time, there are increasing efforts to prohibit the use of this technology even within the United States. The official policy regarding export of encryption software has changed a few times over the past few years and is likely to change frequently in the next few years as various parties attempt to reach a coherent policy. Right now, the U.S. government will grant an exemption for certain types of companies to use encryption in their global business; what will happen in the future is anyone's guess.

In addition, the U.S. is not the only government that is hostile to the use of encryption, and encryption software can face import restrictions as well as export restrictions. In France, for example, it is illegal to import the JCE without a license. Other countries have regulations for cryptography, but in most cases they are less onerous than those of the United States. However, it is always wise to check your local policies to be sure (see Appendix C, "Security Resources" for resources to find more information about these limitations).

According to the letter of the restrictions, technical information regarding the JCE also cannot be exported except in the form of published books such as this one (because the book is protected by the first amendment to the U.S. Constitution). This has not prevented several companies and groups outside the United States from reimplementing the JCE encryption APIs, with the result that there are now several third-party security providers that include their own implementations of the JCE and are available outside the United States (the list of third-party security providers in Appendix C, "Security Resources" includes some of these implementations).

Many of the popular algorithms that are used by the encryption engine (and some of the other cryptographic engines that we've looked at) are patented algorithms, which also restricts their use. RSA Data Security, Inc., holds a patent in the U.S. on several algorithms involving RSA encryption and digital signatures; Ascom System AG in Switzerland holds both U.S. and European patents on the IDEA method of performing encryption. If you live in a country where these patents apply, you cannot use these underlying algorithms without paying a license to the patent holder. In particular, this means that many of the third-party security providers and third-party implementations of the JCE cannot be used within the United States because of patents held by RSA (although some of them have reached a licensing agreement with RSA Data Security, Inc.--again, it is best to check with the provider to see what restrictions might apply).

For at least the time being, then, Java programmers are faced with the following restrictions on use of the JCE:

The JCE must be procured separately from the JDK. The official JCE from Sun may only be procured by citizens of the United States and Canada, but third-party implementations of the JCE may be obtainable elsewhere.
Electronic documentation of the JCE is subject to the same restriction. In practice, the restriction about electronic documentation of encryption techniques--which applies to many things other than the JCE--is rarely enforced and widely violated.
Code that uses the APIs we are going to discuss in this chapter and that was developed inside the United States or Canada may not be distributed electronically outside the United States and Canada. Hence, if you are a resident of the United States or Canada, you cannot use these APIs to develop applets that you put on the Internet, or to develop applications that you send outside the United States and Canada.

Since no browser currently implements the JCE, the impact of this restriction on browsers is somewhat muted. However, some third-party implementations of the JCE will be compatible with popular browsers; these third-party implementations could be downloaded and installed manually by the user, who could then use cryptography only in applets that were developed outside the United States and Canada or that are available only on private networks wholly within the United States and Canada.

This restriction also means that, unlike the other examples in this book, the examples in this chapter may not be downloaded from the O'Reilly ftp site.
Questions about these APIs cannot be answered via email (although this is another rule that applies in general to encryption algorithms and is--again, at least presently--rarely enforced in the general case).

These APIs, then, will typically be used:

To develop applications for use on a private intranet that is located wholly within the United States and Canada. XYZ Corporation may want to use this technology for their payroll application; without this technology, although payroll data may only be retrieved upon a valid signed request, that data is still shipped over the network unencrypted, where an inside corporate spy could snoop the wire and obtain the data.

With the APIs we'll discuss in this chapter, we could encrypt the payroll data as it is passed over the network. This completes the security protection that such an application really needs. We are assured that the payroll data is only being sent to an authorized user, and we are assured that no one can decode the data while it is in transit.
By developers outside the United States, who are effectively in a much better position to take advantage of them than are their U.S. counterparts. These developers, however, will be dependent upon third-party implementations of the JCE.

Encryption and Weaponry

The prohibitions we've been discussing here occur because strong encryption is considered by the U.S. government to be a munitions-grade weapon. While this position is often questioned, it comes from a long tradition in computer science.

During WWII, the Allies waged a successful and pivotal campaign in the Atlantic against the Axis navy. The success of this campaign was greatly due to the work of Alan Turing, who with his colleagues broke the German encryption algorithm known as Enigma. Turing was also one of the founding fathers of modern computer science, much of which was based on the work he developed in service to his country during the war.

Ironically, the reward that Turing reaped for his efforts was that some years after the war, he was arrested and forced to undergo harmful chemical treatments because he was gay. There's an odd parallel here: many of the harsh restrictions that are presently placed on encryption technology make no more sense in a world with a global Internet than did England's persecution of Alan Turing in the 1950s. But the links between encryption and military security run deep and are not likely to be broken anytime soon.

You'll notice that this is the only part of this book where we've discussed export restrictions. Somewhat surprisingly, that is because this is the only instance in which the export restrictions of the U.S. government apply. Encryption of arbitrary data is considered a weapons-grade munition, but message digests and digital signatures are not. Hence, the APIs that allow us to calculate a message digest and a digital signature are freely exportable, but the APIs that allow us to encrypt and decrypt data are not.

Note also that the restriction here is not only on the algorithms that perform encryption, but on the APIs themselves. Like other engines we've examined, the encryption engine allows us to plug in any arbitrary algorithm to perform the encryption. This includes a weak encryption algorithm (that is, one that can be broken) that by itself would be exportable. But since the API allows a strong encryption algorithm to be used as well, the export restrictions apply to the API itself, even if the strong encryption implementation is not provided. Hence, the JCE may not be exported in its present form.


12.4. Summary		13.2. The Sun Security Provider in the JCE

Chapter 13. Encryption

Contents:

13.1. Export Restrictions

Encryption and Weaponry