General Java

Last week a friend of mine who lives in Hong Kong was telling me how advanced the business environment is there. Folks that have Internet access actually use the business facilities the Internet offers. For example, people use the Internet for their regular grocery shopping. They place orders via the Internet, use their credit cards for the transactions and have the goods delivered to their home. Everyday business is conducted on the Web. For some reason commerce in the United States hasn't advanced to that level. The technology is here and has been for a while; however, people don't completely trust the Web for business transactions.

Security is the primary concern of people and businesses that commit to using the Internet for conducting business transactions. An Internet transaction is conducted between two parties, and each party needs to have a certain level of trust in the other. For electronic transactions to be the primary mechanism for conducting business, the level of trust needs to be as high as ­ if not higher than ­ that of person-to-person transactions. The parties involved in electronic trade also need to have a high degree of trust in the medium used for the information transfer, namely the Internet.

This month we'll take a look at the security issues involved in electronic trade, some of the technologies used for providing security in distributed systems and how Java leverages these technologies. Although my focus is on Java and doesn't cover Internet security in detail, I've provided a brief introduction to some of the related concepts where required.

Security Concerns for Business Applications
Internet commerce typically involves two or more machines connected via a public medium. Some of the security issues in this environment are:

• Private and sensitive information exchanged between the two machines may by viewed by some third party that's monitoring the transmission channel.
• The originator of the transmission may not be who he or she claims to be.
• The recipient of the information may not be who he or she claims to be.
• The data may be corrupted for malicious purposes during transmission.

Business applications in general have the following categories of security concerns:

• Security of content: This addresses the protection of data at its point of origin, before it's transmitted or received. Parties conducting a business transaction need to be sure that the data isn't available to unsolicited parties for viewing or manipulation.
• Security of communications: The data needs to be protected against tampering and visibility during the process of transmission.
• Security of the corporate computing infrastructure

The above concerns address the integrity of the data during the electronic transaction across the Internet. The data itself could have malicious programs embedded in it. Thus, even after it passes the security checks for correctness, it could cause harm to the local environment. This usually happens in the case of newly installed or downloaded software.

Ensuring an acceptable level of security for each of these categories requires the following:

• Proof of identity (authentication): Confirm that the source and destination parties are who they say they are.
• Data integrity: Ensure that the data hasn't been tampered with since the originator created it.
• Privacy: Ensure that the data isn't available to a third party (one not involved in the trade) for reading or manipulating during the transaction.
• Nonrepudiation: Retain proof that a business transaction did take place. Nonrepudiation prevents a party from denying its participation in a transaction.

AAA
When the acronym AAA is used in the context of security, it doesn't stand for American Automobile Association (although different security concerns are addressed by that organization). AAA stands for authentication, authorization and accounting ­ three mechanisms to ensure the security of a distributed computer system during remote access.

• Authentication: Authentication is required on secure systems to ensure that persons logging in are who they say they are. Authentication is also required for a message exchange to verify that a particular message has not been fabricated or altered in transit.
• Authorization: Authorization determines what users can do once they are authenticated. Once the person is logged in, authorization controls are used to restrict their access to various resources based on the rights and privileges assigned to their user accounts or the objects they access.
• Accounting/logging: Auditing is the collecting and monitoring of events on servers and networks for the purpose of tracking security violations and keeping track of how systems are used. A network auditing system logs details of what users are doing on the network so that malicious and unintended activities can be tracked.

Security Concerns in the Java Platform
The Java platform supports a new paradigm for distributed computing. While this enables the creation of very powerful and extensible applications, it also introduces new concerns about Internet security for applications written in Java. These concerns are addressed by Java's Security APIs and by the Java Virtual Machine.

Java provides rich support for distributed commerce by being the application building platform for full-scale client/server systems. Java components that constitute a complete commerce application may exist as a combination of applets on the client, servlets on the server and client or server Java applications. Commerce services may be exposed in a distributed topology via CORBA or RMI. Data may be transmitted between tiers of an n-tier application via IIOP (Internet Inter-ORB Protocol), HTTP or raw sockets. Figure 1 illustrates a distributed topology in the Java environment.

These different facets of a Java application give rise to several potential security loopholes. A security solution for a distributed application needs to address all these loopholes since the system is only as strong as its weakest link. In other words, a security solution needs to be holistic. The Java Security APIs, the Java Cryptography Architecture (JCA) and the Java sandbox, ClassLoader and SecurityManager all work together to ensure security in a Java application.

Protecting the Java Client Environment
The ability to dynamically download and run Java applets over the Internet is one of Java's most powerful features supporting distributed computing. However, downloaded code is untrusted code from the client's perspective, and this opens up the following kind of security risks:

• System modification: The applet can make changes to the browser or the client system in a harmful way.
• Privacy invasion: The privacy of restricted information on the client system could be compromised.
• Denial of service: The downloaded code could use up system resources and thus interfere with the normal operation of the system by denying service to other, more critical system processes.

Java's sandbox model addresses these security risks. The ClassLoader, SecurityManager and bytecode Verifier ensure that untrusted code executes only within a restricted environment. Within this environment the code can't access resources in a system that's sensitive from the security viewpoint. The code executing within the sandbox has no local disk access, linkage to local code or printing facilities.

However, placing these restrictions also prevents applets from performing more useful functions and severely limits their capabilities. The Java security model is built around the concept of a protection domain. The applet sandbox is a protection domain with very tight controls. Java applications, on the other hand, execute in an environment with no control other than those imposed by the underlying operating system. Java 1.1 relaxes the security model by introducing the concept of digitally signed applets. Signed applets are treated as trusted code since the signature ensures that the applet was downloaded from a source trusted by the client.

Data Encryption in Java
Encryption is the process of converting data from a readable to an unreadable format. Decryption is the opposite process. Data is encrypted when transmitted from the sender to the receiver, the premise being that only the intended recipient knows how to decrypt the message. Thus data encryption ensures data integrity and privacy. A discussion of the protocols involved in encrypting and decrypting data is beyond the scope of this article. However, we'll briefly discuss Java's support for data encryption.

The Java security architecture allows security algorithms for encrypting data to be plugged in using a java.security.Provider interface. A security provider is a package that implements a set of security algorithms, including message digest, signing and encryption algorithms -- three mechanisms for encrypting/decrypting data.

JDK 1.1 provides general-purpose APIs that support encryption ­ Java Cryptography Extensions (JCE) and Java Cryptography Architecture (JCA). JCE comprises a set of additions for the java.security package that implements cryptographic streams.

JDK1.1 also introduced the JAR (Java Archive) format for distributing code. JAR files are single files with the .jar extension that package multiple Java files. The files in the JAR can be digitally signed prior to distribution. This allows the end user to authenticate the code running on his or her client machine. The package javax.security.cert is a Java extension API that provides support classes for X.509 certificates.

Java Support for SSL
Several communications protocols used in network communications today add a security layer to existing communications protocols. The most popular of these is the Secure Socket Layer (SSL) protocol used to create secure connections between the client and the server in a networked environment. SSL was developed by Netscape to allow their browser and server products to conduct electronic commerce securely, and with the confidence that the customer's financial data, such as credit card information, could be transmitted over the Internet without being compromised. SSL attempts to solve end-to-end transmission security by providing authentication for both the client and the server.

SSL support for Java-based applications is included in many popular Web browsers and servers. These programs depend on SSL to provide the necessary encryption when transmitting data across the Internet. In order to use SSL, "https://" is used in the URL instead of the traditional "http://". The "s" in "https" implies SSL communications.

Similar to Netscape's SSL, several vendors also provide SSLSocket and SSLServerSocket classes that extend the java.net package's Socket and ServerSocket classes, respectively. The javax.net.ssl is an SSL API, which is a standard extension to JDK 1.1 core API. The classes in this API resemble the java.net socket classes; the difference is that when sockets from this package are used, they establish secure connections.

Java Servlets
Java servlets are Java classes that are loaded and run by Web servers. While they aren't subject to the same restrictions as applets, they're only capable of serving HTML to the client. Servlets are a popular mechanism for accessing system resources and services on the server. Since they run within the Web server, the built-in safety features of the server ensure secure execution. Since they're not downloaded classes, they don't have the "trust" issue that applets do.

Java Access Through a Firewall
A firewall is a computer service that links two or more networks and enforces some access control policy between them. It can be implemented in hardware, software or a combination of both. Companies implement a firewall as a front end to their corporate intranet to control access to their computer resources. These resources are said to sit "behind" the firewall.

When working with a Java-based architecture, firewalls control the loading of Java applets to a client and network accesses by Java applets to a server. Java applets are accessed using HTTP as the transport protocol. If the security policy of the firewall is to allow HTTP traffic to pass through, the applet or the JAR housing the applet will be like any other component of a Web page. If HTTP is disallowed, then downloading class files is going to be very difficult. Most firewalls allow protocol access via well-known ports (e.g., HTTP via port 80, FTP via port 21). If an application needs to communicate using other protocols, they'll have to "tunnel" that protocol within the HTTP connection.

In firewall tunneling the communication protocol used by the application is wrapped in another protocol (like HTTP) so it can pass through the firewall. Behind the firewall a special program, called a gateway, is used to extract the contents of the actual protocol. For example, in the case of RMI, JavaSoft provides the RMI-CGI Gateway, a program that allows the RMI connection to pass through firewalls. Firewall tunneling in the context of a Java environment is illustrated in Figure 2.

RMI Security
Java's RMI allows distribution of Java objects across different machines. RMI's RMISecurityManager and RMIClassLoader can be used to impose strict security policies on Java objects exchanged across the network. Since encryption and authentication are not part of RMI, new security issues are opened up when RMI is used across the Internet.

Additional issues need to be considered when the RMI client and server are connected through one or more firewalls. As mentioned earlier and illustrated in Figure 2, JavaSoft's RMI-CGI Gateway may be used for firewall tunneling. Typically, RMI is tunneled over HTTP. However, if a CORBA environment is used, RMI may be tunneled over IIOP. A detailed discussion on RMI tunneling warrants a separate discussion and is beyond the scope of this article.

Trading Places
This has been a quick whirlwind tour of some of the security issues involved in using Java for distributed architectures. Security has many other aspects I haven't even begun to cover. One of the main things to remember is that the designers of the Java platform treated security as one of their primary design criteria. Hence Java tends to address these issues in a much better and more holistic way than other computing platforms. That's one of the many reasons Java is being used to design various tiers of distributed commerce systems.

Add Your Feedback

In order to post a comment you need to be registered and logged in.

Register | Log in

Please wait while we process your request...