Chapter 13. Encryption

Contents:

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.