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 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.
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:
These APIs, then, will typically be used:
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.
Copyright © 2001 O'Reilly & Associates. All rights reserved.