HomeDigital EditionSys-Con RadioSearch Java Cd
Advanced Java AWT Book Reviews/Excerpts Client Server Corba Editorials Embedded Java Enterprise Java IDE's Industry Watch Integration Interviews Java Applet Java & Databases Java & Web Services Java Fundamentals Java Native Interface Java Servlets Java Beans J2ME Libraries .NET Object Orientation Observations/IMHO Product Reviews Scalability & Performance Security Server Side Source Code Straight Talking Swing Threads Using Java with others Wireless XML

The choice of encryption technologies is not always easy, but fortunately there are often several equally good options. The first step in choosing an algorithm is knowing the purpose to which it will be applied. Is it to ensure privacy, integrity, authenticity or to provide non-repudiation? Will it be used on a small amount of data or files so large that the encryption process could result in an unacceptable processing delay? The strength of an encryption method is dependent upon both the algorithm and the key length and can be understood in terms of the computational resources required to break it. The longer the key, the stronger any given algorithm. It is the value of the data and the length of time it must be protected that determines the necessary encryption strength. As long as the value of the data is lower than the cost of breaking the encryption, it is adequately protected.


Where to Apply Encryption
Although several encryption libraries are now available for Java programmers (see "Java Encryption Libraries Available Today"), the Java programmer is certainly not limited to just Java APIs. As detailed in Figure 1, the Web infrastructure supports encryption technology at several layers in the network model. In general, encryption services are only visible within the layer at which they are applied. HTTP and the lower layers are completely unaffected by the encryption of individual documents. Likewise, Web traffic is oblivious to the existence of a virtual private network (VPN) that securely tunnels packets over the Internet. Be aware that it might be advantageous to provide encryption at one network level and authentication at a different level. Figure 2 shows the most common network encryption configurations.

Figure 1
Figure 1:

Virtual Private Networks
A VPN transparently tunnels normal LAN activities over a wider network and usually is used to support the distribution of a single organization over the Internet. Commonly supported between two firewalls, a VPN is a form of point-to-point encryption. Increasingly, this same technology also is being used to support remote users who access their organization's LAN through the Internet. Usually applied at the perimeter of a network (i.e., the Internet Gateway), a VPN is a network extension tool. It temporarily extends the boundary of a private network either to a single remote user or to another network. As implemented by most firewall vendors, a VPN session is automatically initiated when either network entity attempts to access the other. Firewall vendors usually offer a choice of authentication mechanisms for use by individual remote users (either traditional reusable passwords or one-time passwords generated by a hardware token device). Because it is configured in the transport (TCP) layer, all traffic between two entities flows through a VPN automatically without either the awareness or choice of the user or the application.

Figure 2
Figure 2:

Secure Socket Layer
SSL has become ubiquitous on the Internet. It is widely used to provide privacy for on-line storefronts and other sensitive applications. Developed and implemented by Netscape, SSL is a form of host-to-host encryption that extends encryption all the way from a server to a client workstation. Firewalls are customarily configured to allow both incoming and outgoing SSL sessions. As a transport layer service (more specifically, a service that sits directly above the transport layer), it still cannot provide integrity or non-repudiation services because it does not have direct access to the objects being transmitted through it. It has an advantage over VPN in that it can be invoked from applications which are modified to support it. Most Web browsers have been modified to invoke an SSL session when using URLs starting with http:'. SSL is a convenient way to selectively provide confidentiality between a browser and a Web server. It also provides certificate-based authentication on the server side and optionally for the client. Note that applications which require some other form of authentication, such as a hardware token card, can still use SSL for privacy while taking advantage of an authentication service provided by a Web Server or written as a CGI program. Because it provides the normal socket interface, it is possible for SSL to support virtually any application, as long as that application has been designed to invoke and use SSL instead of the generic TCP socket services. Few SSL applications are available and in practice it is used almost exclusively for Web support.

Application Layer Encryption
Only a service that can operate on discrete objects can sign them or verify them. S-HTTP is a standard set of security services that operates between Web browsers and Web servers. Careful application of the OSI model (as shown in Figure 1) would probably place S-HTTP at the presentation layer, but it offers the same capabilities as application layer encryption, if not the same level of flexibility, because it can directly operate on the objects being served through the Web. S-HTTP is a very useful protocol because it can provide object integrity and digital signature without requiring programmatic support, but unfortunately it is not widely implemented.

Given the lack of widespread S-HTTP support, many Java applications will be written to use their own cryptographics services. Using encryption from within Java provides a number of benefits:

  1. All cryptographic services are available (privacy, authentication, non-repudiation, integrity).
  2. The programmer controls and specifies the encryption service.
  3. No infrastructural support is needed from the server, the client or system administrators.
  4. Java applets can bring encryption services with them, effectively adding encryption services to the client workstation browser without requiring downloading or configuration on the part of the user.
  5. Encryption can be selectively applied, allowing more efficient processing of non-private data.
  6. Because Java programs operate above the network transport layers, they can also take advantage of S-HTTP and SSL.
If end-to-end encryption is not required, it is usually more convenient to allow the Webmaster or network administrator to configure encryption services using the existing infrastructure. In general, the higher in the network stack it is applied, the more specifically cryptographic authentication and verification can be applied. Point-to-point encryption usually only authenticates organizations (everything behind the firewall) to each other, while SSL can authenticate a user on a specific workstation to a specific server. Application level encryption can identify a specific application or data object. It offers the most flexibility and functionality, but requires the most programming effort. The good news is that much of this programming effort has already been done. A number of transaction services and electronic commerce libraries are available to the Java programmer. These higher-level libraries can simplify the implementation of electronic commerce applications and an upcoming article will discuss these products and their use.

Further Reference
Encryption products that can be effectively applied by non-specialists are readily available. If you get involved in a project requiring cryptographic services - and a lot of the most interesting Java applications will require it - get a copy of Bruce Schneier's book, Applied Cryptography (2nd edition; Wiley, 1996). This is the bible of encryption technology for programmers and administrators. It's a great introduction and reference manual to this complex subject and a well-thumbed copy should be on the shelf of anyone with a serious need for encryption.

About the Author
Jay Heiser is the Director of Internet Products for HomeCom Internet Security Services, where he is currently providing network security consulting to several major financial institutions and retail chains. He has lectured on information security in the US and Europe at events such as InfoWarCon, The Internet Conference, and FOSE. Jay also has animated several presentations on basic network security topics and made them available on the Web at http://www.homecom.com/services/hiss/LearnAbout.html. He can be reached at [email protected]


All Rights Reserved
Copyright ©  2004 SYS-CON Media, Inc.
  E-mail: [email protected]

Java and Java-based marks are trademarks or registered trademarks of Sun Microsystems, Inc. in the United States and other countries. SYS-CON Publications, Inc. is independent of Sun Microsystems, Inc.