When we refer to Java as a safe language, we are referring to the fact that you cannot "shoot yourself in the foot." There are no memory leaks, out of control threads, or chance of ending up in the dark spiral of C++ debugging. Make no mistake—Java is a powerful language, and you will always end up with the possibility of sitting in an infinite loop. You can still freeze your Java code with thread deadlocks, and you can certainly end up accessing parts of an array that aren't really there. In short, Java is safe, but it isn't idiot-proof. The fact remains that, in order to screw up your Java programs, you still have to make a major effort.

Most Java programmers are pleased that Java has no pointers to memory locations. This makes program debugging much easier, and it also makes security verification possible. It cannot be verified at compile time that a pointer will do no harm. It can be loaded at runtime with a naughty address to poke a hole in the password file or branch to some code that sprinkles at-signs all over a disk. Without pointers, Java ensures that all mischief is done within the downloaded applet running inside a Java Virtual Machine. Moreover, memory is not allocated until runtime, and this prevents hackers from studying source code to take advantage of memory layout because it is not known at compile-time. Attempts to write beyond the end of an array, for example, raise an ArrayIndexOutOfBoundsException. Had the C language had this feature (array bounds checking), the infamous Morris Internet worm would not have been able to trick the sendmail daemon (running with root privileges) into giving root access to the worm.

Garbage collection, exceptions, and thread controls are part of Java no matter how you try to use it. But, security and safety are two entirely different things. Safety refers to protecting ourselves from our own misadventures. Security refers to protecting ourselves from other people's devices. Because Java objects are loaded dynamically, Java ensures that the objects are "trusted." Java's class security mechanism makes sure that your applications are using the proper objects and not an object that someone has slipped into the download stream to wreak havoc on your machine.

The Java security model has been a constantly evolving part of Java. In the JDK 1.0 model, the "sandbox" concept was introduced. In the sandbox model, all local code (JDK-provided code) was run as part of the Java Virtual Machine, and all code retrieved from remote servers (applets) was run in a "sandbox" area of the JVM that provided only a limited set of services. The reason for doing this was based on the fact that any remotely retrieved code could be hostile. To protect the local machine the sandbox provided only minimal access to the machine resources (Figure 13-1).

Figure 13-1. JDK 1.0 sandbox model.

The JDK 1.1 added to the JDL 1.0 security model the concept of "trusted applets" that could run with the same privileges with respect to the local hosts system resources as local code. This was done through the advent of the Java Archive file format and the inclusion of a correctly signed digital signature in the JAR file. Unsigned applets in JDK 1.1 sill run in the sandbox (Figure 13-2).

Figure 13-2. JDK 1.1 security model.

The JDK 1.2 evolves the security model by changing the goals to make it:

Java's security model is made up of three major pieces:

The Class Loader

Each imported class executes within its own name space. There is a single name space for built-in classes loaded from the local file system. Built-in classes can be trusted, and the class loader searches the local name space first. This prevents a downloaded class from being substituted for a built-in class. Also, the name space of the same server is searched before the class loader searches other name spaces. This prevents one server from spoofing a class from a different server. Note that this search order ensures that a built-in class will find another built-in class before it searches an imported name space. So, when classes are downloaded, the client's built-in classes are used because they are trusted (See Figure 13-4).

Figure 13-4. Downloaded Java objects use the local built-in classes rather than their own.

Grant [SignedBy "signer names"] [, CodeBase "URL"]
{
    permission "permission_class_name" ["target name"]
        [, "action"] [, SignedBy, "signer names"];
    permission. . ..
}

grant codeBase "file:${java.home}/lib/ext/*" {
    permission java.security.AllPermission;};

// default permissions granted to all domains

grant
{
   // Allows any thread to stop itself using the
   // java.lang.Thread.stop() method that takes no argument.
   // Note that this permission is granted by default only to remain
   // backwards compatible.
   // It is strongly recommended that you either remove this
   // permission from this policy file or further restrict it to code
   // sources that you specify, because Thread.stop() is potentially
   // unsafe. See "http://java.sun.com/notes" for more information.
   // permission java.lang.RuntimePermission "stopThread";
   // allows anyone to listen on un-privileged ports
   // permission java.net.SocketPermission "localhost:1024-", "listen";
   // "standard" properties that can be read by anyone

  permission java.util.PropertyPermission "java.version", "read";
  permission java.util.PropertyPermission "java.vendor", "read";
  permission java.util.PropertyPermission "java.vendor.url", "read";
  permission java.util.PropertyPermission "java.class.version", "read";
  permission java.util.PropertyPermission "os.name", "read";
  permission java.util.PropertyPermission "os.version", "read";
  permission java.util.PropertyPermission "os.arch", "read";
  permission java.util.PropertyPermission "file.separator", "read";
  permission java.util.PropertyPermission "path.separator", "read";
  permission java.util.PropertyPermission "line.separator", "read";
  permission java.util.PropertyPermission "java.specification.version","read";
  permission java.util.PropertyPermission "java.specification.vendor", "read";
  permission java.util.PropertyPermission "java.specification.name", "read";
  permission java.util.PropertyPermission "java.vm.specification.version", "read";
  permission java.util.PropertyPermission "java.vm.specification.vendor", "read";
  permission java.util.PropertyPermission "java.vm.specification.name", "read";
  permission java.util.PropertyPermission "java.vm.version", read";
  permission java.util.PropertyPermission "java.vm.vendor", read";
  permission java.util.PropertyPermission "java.vm.name", read";
};

// this policy file should only be used for testing and not deployed
grant
{
    permissionjava.security.AllPermission;
};

In this section, we describe some of the techniques commonly used to provide privacy during data exchanges between two parties. Data traveling through the Internet can be captured (and possibly modified) by a third party. Certainly, you do not want your credit card number to be revealed to a third party and you probably also want the merchandise you purchased to be delivered to your address and not to a different address inserted by a third party. Data encryption ensures that a third party will not be able to decipher any message sent between a client and a server.

A very simple algorithm used to scramble "sensitive" jokes on the Internet is called "rot13" because it rotates each character by 13 positions in the alphabet. That is, "a" is mapped to "n," "b" is mapped to "o," and so on. This algorithm also decrypts a message that was scrambled by it. This is adequate for its purpose: to protect people from reading a joke that they might feel is offensive. This is an example of symmetric key encryption, where both sides use the same key (13) to encrypt and decrypt a scrambled message (see Figure 13-5).

Figure 13-5. Symmetric key encryption decodes messages with a key on both the sending and receiving ends.

In its most commonly used mode, data encryption standard (DES) uses a 56-bit key to scramble message blocks of 64 bits; in this form DES encrypts large amounts of data relatively fast. DES is currently one of the encryption algorithms used by Secure Sockets Layer (SSL). Recent research has shown that 56-bit DES is becoming insufficient for providing robust encryption for security-sensitive applications. Many companies now use "triple DES," which encrypts each block of data three times with three different keys.

One problem with symmetric key algorithms such as DES is key distribution (i.e., how do I share the private key securely among the participants?).

Public key, or asymmetric cryptography, uses a pair of mathematically related keys for each user. Everyone can know a user's public key, but the private key must be kept secret. To send data to another user, the sender encrypts the data using the recipient's public key and sends the encrypted message to the recipient. The recipient decrypts the message using his or her private key. Because only the recipient knows the private key, data privacy is ensured. Asymmetric algorithms are inherently slower than their symmetric counterparts. The key distribution problem of symmetric algorithms is overcome through the use of the public/private key pairs because the public key can be widely distributed without fear of compromise. There is still one problem with key management in public key encryption schemes. Namely, how do I know that the key I am using for Joe is really Joe's public key? It could be possible for a network interloper to substitute his or her public key for Joe's public key. A variety of trust models have risen to combat this problem. For corporations, the most prevalent model is the hierarchical trust model, which relies on the use of digital certificates and certificate authorities to validate users' public keys.

Real-world cryptographic implementations utilize a combination of public and private key encryption to provide not only data privacy but also nonrepudiation (via digital signatures), access control, and authentication. These solutions use the strengths of both public key (key distribution) and private key cryptography (speed); an example follows.

John creates a document and wants to send it to Mary. John first encrypts the document using a symmetric algorithm (like DES) and a randomly selected key. The randomly selected key is then encrypted using an asymmetric algorithm (like RSA) and Mary's public key. A message digest function (one-way mathematical function (like MD5) is performed on the original document producing a fixed-length message digest. This message digest is encrypted using an asymmetric encryption algorithm using John's public key. These three elements are then sent to Mary over some unsecured communications link. This is shown in Figure 13-6.

Figure 13-6. A combination of symmetric and asymmetric encryption.

The process of decrypting and verifying the encrypted document is shown in Figure 13-7 and goes something like this: Mary uses her private key to retrieve the random symmetric key used to encrypt the document. Because Mary is the only one who knows her private key, she is the only one who can open the "digital envelope," thus ensuring data privacy. The retrieved symmetric key is used to decrypt the document. Using the same message digest function as John, Mary produces a message digest for comparison to the one sent by John. Mary now uses John's public key and the asymmetric encryption (RSA) to retrieve the message digest sent with the document. By using John's public key to retrieve the message digest, Mary has also verified that the message was sent by John (i.e., retrieved his digital signature) because only John's private key could have been used to encrypt the message digest. The message digest sent with the document is compared with the one computed by Mary. This comparison ensures the data integrity. If the digests match, the document was unaltered during transmission.

Figure 13-7. Decryption of example.

In many applications, it is important to authenticate the identity of a client making a request for a service. Examples include banking, financial, real estate, medical records, and ISP (Internet Service Provider) applications. An ISP, for example, wants to ensure that Internet access is being provided to a paying customer and not the customer's housekeeper. The online stock trading application wants to make sure that it is the portfolio owner who is making trades.

The usual way to do this is to require an account number or customer name and a password. This is adequate for workstations and time-sharing systems and client/server sessions such as calling Charles Schwab to manage your stock portfolio. In a distributed system, many different servers provide services. Instead of a single authentication to a single server or application, that server must authenticate each service request sent over the network.

One obvious requirement of such an authentication system is that it be transparent to the user. The user does not want to type in a password for each service each time it is requested. Another requirement is that it be available at all times because, if a server cannot authenticate a request, it will not provide the service. When the authentication service is unavailable so are all the services that use it. A less obvious requirement is that authentication must be protected against capture and playback by another user on the network. Capture cannot be prevented on broadcast media such as an Ethernet cable, so the authentication procedure must be able to prevent a playback by an impostor.

Kerberos

One popular authentication system is Kerberos, which is named after a three-headed guard dog in Greek mythology. It depends on a third party that is trusted by both client and server (see Figure 13-8). Clients request a ticket from the third party. The ticket is encrypted using the server's secret password, so the server trusts the client when it can decrypt the ticket. The server's password is known only to itself and the third party. The third party knows everyone's password! This means that all systems are vulnerable if the trusted third party is compromised.

Figure 13-8. Servers can trust clients only if they can decrypt the ticket from the Kerberos server.

A well-known bank has two major data centers, one in San Francisco and the other in Los Angeles. Each center backs up its data at the other site. In this way, the bank can resume operation soon after serious damage to either data center. The Kerberos servers are replicated at both sites and kept behind "the glass wall." In fact, there is a sealed walkway with locked doors at both ends and a badge reader with a video camera in the middle. If your face doesn't resemble the one on the badge, you are not allowed into the room that houses the Kerberos servers. In fact, two or more very large people will promptly escort you out of the building.

Including a timestamp in the ticket thwarts playback. That is, the Kerberos server encrypts the client's IP address, a session key, and a timestamp using the server's key. The client encrypts its service request message with the session key and sends it, along with the ticket, to the server. The server uses its key to decrypt the ticket. If the IP address in the ticket matches the IP address in the IP packet header and the timestamp is within a few milliseconds of the current time, then the server accepts the client's request. It uses the session key to unscramble the request and perform the service. It's as simple as that. Playback is impossible because the encrypted timestamp will have "timed out" before an impostor can capture and try to replay the request. Also, the IP address of the impostor will not match the IP address encrypted in the ticket.

By far the most widely used authentication and encryption on the Internet in general and on the Web specifically is Secure Sockets Layer. SSL can be used with any connection-based protocol. It's called a layer because we essentially insert an additional protocol layer between TCP and the Application layer of the TCP/IP stack (see Figure 13-9).

Figure 13-9. Secure Sockets Layer.

SSL adds the following features to the reliable stream provided by TCP/IP:

Netscape Corporation designed SSL as a way of ensuring secure communications between its browser and server products. SSL has become the de facto standard for secure communications between Internet clients and servers.

For a look at the SSL v3.0 specification, see http://home.netscape.com/eng/ssl3/ssl-toc.html. To use SSL requires cooperation between the client browser and the server. At the server, a secure instance of the Web server must be running on the well-known port 443. (Some Web sites run both an unsecure and a secure instance of the Web server on the same machine. The unsecure instance is listening on port 80, while the secure instance is running on port 443. Some sites run the unsecure and secure instances on completely separate hosts.)

At the browser end, all references to the URLs of documents or applications must be preceded with the protocol https rather than http. As long as the protocol notation is https, the port is defaulted to 443 (the secure server port).

The attachment of an SSL client to an SSL server starts off with what is known as an SSL handshake. During the handshake, the client and server agree on the protocol version to be used, select the cryptographic algorithm they will use to protect data transmission, optionally authenticate one another, and use public-key encryption to generate shared secrets. After this has been done, the rest of the transmission takes place in an encrypted manner using the parameters selected during the handshake.

The issue of security on our computers is greatly affected by the restrictions on security technology placed on a company by its home government. Because this is not by any stretch of the imagination a comprehensive text on security, we instead outline the two major controversies concerning government intervention in computer security. We attempt not to pass judgment on either the government or the security community; you can make that determination for yourself. Instead, in this section, we simply point out the two sides to the arguments of governmental control of security export and the government's right to possess keys to domestic security apparatuses.

Secure, networked transmissions are of the utmost importance to many people. If the Internet is truly to become the focus of all our communication in the next century, then we must all have confidence that no one can intercept and decode our innermost thoughts. Although we have very briefly outlined the concerns of the U.S. government, we hesitate to endorse or criticize any one position. In the end, the debate over the involvement of government authorities will be settled in another, more appropriate, forum. For now, as application programmers, you should be keenly aware of the position of your government, whatever it may be, on how you can send secure transmissions.

With this solid base of network programming underneath us, we must now make a decision about which alternative to choose. Each has its advantages and disadvantages, and we will discuss them in detail in the next chapter.