Platinum Edition Using HTML 4, XML, and Java 1.2
(Publisher: Macmillan Computer Publishing)
Author(s): Eric Ladd
ISBN: 078971759x
Publication Date: 11/01/98

Some system information is available to applets, however. Access to this information depends on the specific Java implementation. A method of the System object is called getProperty. By calling System.getProperty(String key), an applet can learn about its environment. The information available to the applet is as follows:

•  java.version—The version of Java currently running

•  java.vendor—The name of the vendor responsible for this specific implementation of Java

•  java.vendor.URL—The URL of the vendor listed in java.vendor

•  java.class.version—The Java class version number

•  os.name—The name of the operating system

•  os.arch—The architecture of the operating system

•  file.separator—The file separator (for example, /)

•  path.separator—The path separator (for example, :)

•  line.separator—The line separator (for example, CRLF)

Other pieces of information that may or may not be available, depending on the implementation, are

•  java.home—The Java home directory

•  java.class.path—The Java class path

•  user.name—The logon name of the current user

•  user.home—The location of the user’s home directory

•  user.dir—The user’s current directory

Making and Using Signed Applets

Starting in JDK 1.1, Sun introduced several new APIs to the core set of Java APIs. One of these is Security and Signed Applets, a subset of the Security API. This API provides for digital signatures and message digests (in accordance with the industry standard X.509v3). These signatures are based on public/private key pairs.

To sign your applets or to prepare your system to use signed applets, you need the jar, keytool, jarsigner, and appletviewer tools included with JDK 1.2. You make and access Java archives with jar, make keys with keytool, sign archives with jarsigner, and test and develop using the appletviewer mini-browser.

Before getting started, you might want to see what happens when an applet throws a security exception. Sun provides a harmless sample applet that does just that. You can try it by running

appletviewer <http://java.sun.com/security/signExample/writeFile.html>

at a command prompt.

Digital Signature Enhancements in JDK 1.2

As you’ve seen throughout this chapter, tight security is one of Java’s distinctives. It’s not surprising that JDK 1.2 includes some major improvements in security. These changes include

•  Policy-based access control—The capability to grant rights to software is based on an external configuration file.

•  Support for X.509v3 certificates—You can use the latest industry-standard encryption technology to sign the Java archives in which you distribute your classes.

•  New security tools—These include tools to manage certificates and write your security policy file.

Policy-Based Access Control

If you’ve used the UNIX operating system, then you’re familiar with the concept of permissions. The owner of a file can grant other users (or programs) the right to read, write, or execute a file. Processes take on the rights of the person who started them—although some users will choose to restrict the rights of programs they launch. (Web servers are often started by someone with root authority, for example, but run as the nonprivileged user nobody.)

Beginning in version 1.2, Java developers have similar choices with their applications and applets—although the level of control is finer grained than that offered by many UNIX implementations.

Computer resources include files, directories, hosts, and ports. The person responsible for a computer that will be running Java can set up a security policy that specifies who is allowed to access each resource. Access includes read and write permission (for files and directories) and connect permission (for hosts and ports). The security policy is specified in an external security configuration file.

When a Java class is loaded, the JVM examines the security policy currently in effect. If the code is signed, then permissions may be granted on the basis of the identity of the signer. Permissions may also be granted based on the location of the class file. (A file loaded from the local host might be given more access, for example, than one loaded from the Internet.)

Certificate Interfaces and X.509v3 Implementation

Not so long ago, the only way for a server to identify a client was to ask the user for a username and password. If the username and password matched those stored in the password file, the server granted the user access.

Several problems occur with password-based authentication. First, the password often has to travel over a non-secure network. If an adversary is able to “sniff” the username and password from the Net, he or she will be able to masquerade as a valid user.

Another problem is that most users access more than one system and have more than one username and password. Users find it difficult to keep these names and passwords straight, so they either write down the names and passwords or use the same name and password on every system. Either solution is subject to abuse.

A better solution is for the user to generate a special kind of cryptographic key, called a public/private key pair. These keys work together—if you encrypt something with my public key, only a person with my private key can decrypt it. If I keep my private key secret, you can be sure that I am the only one who can read your message.

In an ideal world, we could all post our public keys on servers somewhere and begin to communicate securely with each other. That practice is subject to abuse, too—an opponent could put a public key on the server with my name on it. If my opponent can trick you into using the bogus key, he or she will be able to read messages intended for me. (This strategy is a variation of the man-in-the-middle attack described earlier in this chapter, in the section entitled “The Java Approach to Security.”)

The solution is simple—I generate my public/private key pair, making sure I keep my private key secret. I send my public key to a “public key certifying authority,” who requires that I prove my identity. After I’ve satisfied the certifying authority that I am who I say I am, they sign my key with their private key. Now anyone who wants to be sure that a public key with my name on it really belongs to me can check the signature of the certifying authority. If you find that the signature is valid, and you’re satisfied with their policy for checking my identity, then you can trust my public key.