Java Network Programming (3rd ed) [Electronic resources] نسخه متنی

11.1 Secure Communications

Confidential communication
through an open channel such as the public Internet absolutely
requires that data be encrypted. Most encryption schemes that lend
themselves to computer implementation are based on the notion of a
key, a slightly more general kind of password that's
not limited to text. The clear text message is combined with the bits
of the key according to a mathematical algorithm to produce the
encrypted cipher text. Using keys with more bits makes messages
exponentially more difficult to decrypt by brute-force guessing of
the key.

In traditional secret
key (or
symmetric) encryption, the same key is used
for both encrypting and decrypting the data. Both the sender and the
receiver have to possess the single key. Imagine Angela wants to send
Gus a secret message. She first sends Gus the key
they'll use to exchange the secret. But the key
can't be encrypted because Gus
doesn't have the key yet, so Angela has to send the
key unencrypted. Now suppose Edgar is eavesdropping on the connection
between Angela and Gus. He will get the key at the same time that Gus
does. From that point forward, he can read anything Angela and Gus
say to each other using that key.

In public key (or asymmetric)
encryption, different keys are used to encrypt and decrypt the data.
One key, called the public key, is used to encrypt the data. This key
can be given to anyone. A different key, called the
private key, is
used to decrypt the data. This must be kept secret but needs to be
possessed by only one of the correspondents. If Angela wants to send
a message to Gus, she asks Gus for his public key. Gus sends it to
her over an unencrypted connection. Angela uses
Gus's public key to encrypt her message and sends it
to him. If Edgar is eavesdropping when Gus sends Angela his key,
Edgar also gets Gus's public key. However, this
doesn't allow Edgar to decrypt the message Angela
sends Gus, since decryption requires Gus's private
key. The message is safe even if the public key is detected in
transit.

Asymmetric encryption can also be used for
authentication and
message integrity checking. For this use, Angela would encrypt a
message with her private key before sending it. When Gus received it,
he'd decrypt it with Angela's
public key. If the decryption succeeded, Gus would know that the
message came from Angela. After all, no one else could have produced
a message that would decrypt properly with her public key. Gus would
also know that the message wasn't changed en route,
either maliciously by Edgar or unintentionally by buggy software or
network noise, since any such change would have screwed up the
decryption. With a little more effort, Angela can double-encrypt the
message, once with her private key, once with Gus's
public key, thus getting all three benefits of privacy,
authentication, and integrity.

In practice, public key encryption is much more CPU-intensive and
much slower than secret key encryption. Therefore, instead of
encrypting the entire transmission with Gus's public
key, Angela encrypts a traditional secret key and sends it to Gus.
Gus decrypts it with his private key. Now Angela and Gus both know
the secret key, but Edgar doesn't. Therefore, Gus
and Angela can now use faster secret-key encryption to communicate
privately without Edgar listening in.

Edgar still has one good attack on this protocol, however. (Very
important: the attack is on the protocol used to send and receive
messages, not on the encryption algorithms used.
This attack does not require Edgar to break Gus and
Angela's encryption and is completely independent of
key length.) Edgar can not only read Gus's public
key when he sends it to Angela, but he can also replace it with his
own public key! Then when Angela thinks she's
encrypting a message with Gus's public key,
she's really using Edgar's. When
she sends a message to Gus, Edgar intercepts it, decrypts it using
his private key, encrypts it using Gus's public key,
and sends it on to Gus. This is called a man-in-the-middle
attack. Working alone on an insecure channel,
Gus and Angela have no easy way to protect against this. The solution
used in practice is for both Gus and Angela to store and verify their
public keys with a trusted third-party certification authority.
Rather than sending each other their public keys, Gus and Angela
retrieve each other's public key from the
certification authority. This scheme
still isn't perfectEdgar may be able to place
himself in between Gus and the certification authority, Angela and
the certification authority, and Gus and Angelabut it makes
life harder for Edgar.

This discussion has been necessarily brief. Many interesting details have been skimmed over or omitted entirely. If you want to know more, the Crypt Cabal's Cryptography FAQ at http://www.faqs.org/faqs/cryptography-faq/ is a good place to start. For an in-depth analysis of protocols and algorithms for confidentiality, authentication, and message integrity, Bruce Schneier's Applied Cryptography (Wiley & Sons) is the standard introductory text. Finally, Jonathan Knudsen's Java Cryptography (O'Reilly) and Scott Oak's Java Security (O'Reilly) cover the underlying cryptography and authentication packages on which the JSSE rests.

As this example indicates, the theory and practice of encryption and
authentication, both algorithms and protocols, is a challenging field
that's fraught with mines and pitfalls to surprise
the amateur cryptographer. It is much easier to design a bad
encryption algorithm or protocol than a good one. And
it's not always obvious which algorithms and
protocols are good and which aren't. Fortunately,
you don't have to be a cryptography expert to use
strong cryptography in Java network programs. JSSE shields you from
the low-level details of how algorithms are negotiated, keys are
exchanged, correspondents are authenticated, and data is encrypted.
JSSE allows you to create sockets and server sockets that
transparently handle the negotiations and encryption necessary for
secure communication. All you have to do is send your data over the
same streams and sockets you're familiar with from
previous chapters. The Java
Secure Socket Extension is divided into four packages:

The abstract classes that define Java's API for
secure network communication.

The abstract socket factory classes used instead of constructors to
create secure sockets.

A minimal set of classes for handling public key certificates
that's needed for SSL in Java 1.1. (In Java 1.2 and
later, the java.security.cert package should be
used instead.)

The concrete classes that implement the encryption algorithms and
protocols in Sun's reference implementation of the
JSSE. Technically, these are not part of the JSSE standard. Other
implementers may replace this package with one of their own; for
instance, one that uses native code to speed up the CPU-intensive key
generation and encryption process.

None of these are included as a standard part of the JDK prior to
Java 1.4. To use these with Java 1.3 and earlier, you have to
download the JSSE from http://java.sun.com/products/jsse/ and
install it. Third parties have also implemented this API, most
notably Casey Marshall, who wrote
Jessie (http://www.nongnu.org/jessie/), an open
source implementation of JSSE published under the GPL with library
exception.

Sun's reference implementation is distributed as a
Zip file, which you can unpack and place anywhere on your system. In
the lib directory of this Zip file,
you'll find three JAR archives:
jcert.jar, jnet.jar, and
jsse.jar. These need to be placed in your class
path or jre/lib/ext directory.

Next you need to register the
cryptography provider by editing your
jre/lib/ext/security/java.security file. Open
this file in a text editor and look for a line like these:

security.provider.1=sun.security.provider.Sun
security.provider.2=com.sun.rsajca.Provider

You may have more or fewer providers than this. However many you
have, add one more line like this:

security.provider.3=com.sun.net.ssl.internal.ssl.Provider

You may have to change the "3" to 2
or 4 or 5 or whatever the next number is in the security provider
sequence. If you install a third-party JSSE implementation,
you'll add another line like this with the class
name as specified by your JSSE implementation's
documentation.

If you use multiple copies of the JRE, you'll need to repeat this procedure for each one you use. For reasons that have never been completely clear to me, Sun's JDK installer always places multiple copies of the JRE on my Windows box: one for compiling and one for running. You have to make these changes to both copies to get JSSE programs to run.

If you don't get this right, you'll
see exceptions like "java.net.SocketException:
SSL implementation not available" when you try to
run programs that use the JSSE. Alternatively, instead of editing the
java.policy file, you can add this line to
classes that use Sun's implementation of the JSSE:

java.security.Security.addProvider(
new com.sun.net.ssl.internal.ssl.Provider( ));

This may be useful if you're writing software to run
on someone else's system and don't
want to ask them to modify the java.policy
file.