JavaHow secure is the Java Wallet

How secure is the Java Wallet

Developer.com content and product recommendations are editorially independent. We may make money when you click on links to our partners. Learn More.


From time to time, we hear that electronic commerce, particularly via the World Wide Web, will revolutionize the way that business is done. Yet the financial industry has been slow to embrace, or even to acknowledge, the forecast revolution, and many people, fearing electronic fraud and imposture, remain suspicious of the technologies involved and refrain from using them. In an effort to allay such fears and to offer a secure environment for electronic transactions, Sun Microsystems is developing the Java Wallet, which it believes will provide solutions to the manifold problems of electronic commerce.

Most readers are probably aware of the numerous security problems discovered in the past two years in Java-enabled Web browsers. Hostile applets remain a threat, even in the latest browsers, and third parties who claim to offer tools to bolster security frequently fail to do so. Thus there is a real need to scrutinize all types of Java-based products for security problems and to candidly report those problems in a public forum. This has the desirable dual effects of alerting users to potential threats and bringing market pressure to bear on vendors who continue to offer flawed products as secure solutions.

In keeping with this line of thinking, we have recently taken a close look at Sun’s Java Wallet. Our examination revealed a number of problems that allow untrusted applets to exploit systems on which the Java Wallet is installed. Among our examples are applets such as the following:

  • Pickpocket: an applet which steals information and passwords from the Java Wallet

  • BookMarker: an applet which alters the behavior of the Java Wallet’s “Help Contents” button

  • DemonDialer: an applet which can gain full access to your modem.

Since the Java Wallet is a recent and evolving product, we begin with an overview of its key components before moving on to consider several of its problems. For more details, the reader is invited to consult The Java Wallet Architecture White Paper and the Java Commerce Business Perspective from Sun Microsystems which are linked from the bottom of this article.

What is the Java Wallet?

There are at least two distinct senses in which the term Java Wallet is used. In its broadest sense, the Java Wallet is simply the Java Electronic Commerce Framework (JECF). In a non-O’Reilly nutshell, the JECF is designed to be an open, extensible architecture for developing secure electronic commerce applications in Java. It consists of a number of application programming interfaces (APIs) that extend those of the Java Developer’s Kit (JDK) as well as a suite of tools to assist developers in building electronic commerce applications with those APIs. (These APIs are sometimes collectively referred to as the Java Commerce Client (JCC) Framework.) In its narrower sense, the Java Wallet is a program with a wallet-like graphical user interface that can be used for on-line purchasing and numerous other financial transactions. As such it is one of the JECF tools developed by Sun using the JECF API’s. It is in this narrower sense that we consider the Java Wallet.

In order to better understand how the Java Wallet can fail, we first review some of its key concepts and components. We may enumerate these briefly as follows:

  • Gateway Security Model: The Gateway Security Model is the foundation of the Java Wallet’s security. It defines such concepts as roles, permits, gates and contexts which the Java Wallet implements and uses to enforce security restrictions.

  • Instruments, Protocols and Operations: Instruments are objects that represent confidential user data and, more significantly, a Java Wallet user’s relationships with businesses and financial institutions. The classic example of an instrument is a credit card. Protocols are fixed sequences of actions, agreed upon in advance, that allow two or more parties to complete a task. Operations are procedures which utilize protocols and instruments to complete significant tasks, such as the electronic transfer of payments.

  • Commerce JavaBeans: Commerce JavaBeans are modular components that extend the JavaBeans model in three ways: they are typed, they offer an extended version of JavaBean Info and they support the Gateway Security Model.

  • Cassettes: Cassettes are signed Java archive (JAR) files that may contain JavaBeans as well as the resources required for their operation. In order to be useful, cassettes must be signed for the proper roles and installed in the Java Wallet. Operations can require specific cassettes, which can be installed dynamically, and cassettes can depend on other cassettes being installed in order to function.

  • Java Commerce Messages: A Java Commerce Message (JCM) is a block of text sent from a commerce server to the user. JCMs use a specific format to convey information about operations, protocols and instrments. They can be downloaded from static files, generated by scripts and invoked by applets. In every case they are used to activate the Java Wallet which parses them, instantiates the necessary Commerce JavaBeans and carries out the requested operations.

  • Java Wallet GUI: The Java Wallet’s GUI is typically invoked when a JCM is downloaded. This allows a user and a commerce server to interact effectively. Though designed to be almost completely customizable by developers, the user interface should always contain three main areas: the selector area, the service area and the frame. Of these, the frame, which contains the TrustedSeal indicating commnication with a secure server, is not designed to be manipulated by developers for security reasons.

  • JCC Database and its properties: Installing the Java Wallet and creating a wallet user sets up a relational database, the JCC Database, in a file with a name of the form wallet_login.wlt. Since the JCC Database contains sensitive data about registered cassettes and may contain credit card numbers, PINs and passwords, it is encrypted and should be accessible only to the wallet owner who logs in to the Java Wallet. Other important configuration information can be stored in file called jecf.properties in a .jcc folder under the user’s home directory. When a user chooses to save a default login name and password for the Java Wallet, that information is stored here in plain text. As we will see, this can lead to a certain amount of applet mischief.

This review of the Java Wallet’s main components, while perhaps too brief, should be sufficient to understand its problems. Though a commerce server can invoke a user’s Java Wallet in a variety of ways, most of these will not concern us here. Our main interest lies in exploring what untrusted applets can do when the Java Wallet is present. Two of our applets will simply employ the Java Wallet’s classes to obtain unauthorized access to sensitive information and services on the user’s machine. Though a third applet will invoke the Java Wallet, it will do so in trivial way in order to induce a careless user into using a “Help Contents” button whose behavior the applet has altered.

Applet exploits

We are now ready to take a look at three examples of untrusted applets that exploit weaknesses in the Java Wallet. In order to develop these applets, we downloaded the Java Wallet (Early Access Release 1) and installed it according to the instructions. Since the Java Wallet required Sun’s Java Plug-in 1.1 to be installed, we downloaded and installed that as well. We later learned that the Java Wallet does not always work properly with the Java Plugin, and so we also installed it with the Project Java Activator (Early Access Release 3). Unfortunately, our example applets work with both the Activator and the Plugin-in.

Pickpocket: an applet which steals information and passwords from the Java Wallet

Applications that save login and password data for your convenience are always tempting targets. Unfortunately, Sun’s Java Wallet offers this feature, and we found that it is easy for an untrusted applet to recover any saved information. Our first example shows how an applet can discover the Java Wallet’s home on a user’s machine. This necessarily contains the user’s home directory (according to the user.home property). The example also shows that an applet can read the Java Wallet’s properties file (jecf.properties). This allows the applet to gather saved user login data and “decrypt” saved passwords.

To test this applet, you first need to set up Sun’s Java Plug-in (or Activator) and Java Wallet, and you need to create and save a wallet as the default for auto-login. We set up a wallet with a login name “dummy” and password “easy2read,” and then we ran our applet. This yielded some very interesting information. You can also read the source code to see how applets can easily access the jecf.properties file. Clearly some restrictions will need to be placed on this applet capability. Using a BASE64Encoder to “encrypt” passwords is also not a very good idea.

BookMarker: an applet which alters the behavior of the Java Wallet’s “Help Contents” button

Our second example demonstrates how an untrusted applet can alter the behavior of the Java Wallet’s “Help Contents” button. On Solaris systems this allows the applet to execute commands via Netscape’s Communicator when that button is pressed.

In order for the “Help Contents” button to function at all, the user must have already set the property jecf.browser.path in the file jecf.properties. Since this is an apparently unadvertised feature of the Java Wallet, a second applet runs on the same page as the BookMarker and prompts the user to set that property. Note that this applet runs via the Communicator’s own Java Runtime and that it uses Netscape’s security apparatus to display Netscape’s certificate along with its own message.

In order to try these applets, you need to set up Sun’s Java Plug-in (or Activator) and Java Wallet along with Netscape’s Communicator (4.04 or 4.05) on a Solaris system. You should also have Sun’s Purchase 1.1 Java Wallet cassette and a Java Wallet user set up. Then you should be able to run the applets.

Helper.java retrieves private information about Netscape’s System Principal by creating a handy encoder. It then creates a fake System Principal and uses that to display Netscape’s certificate along with a message asking you to verify that jecf.browser.path is properly set in jecf.properties. If this social engineering effort works, the Java Wallet’s “Help Contents” button will function and be able to do the applet’s bidding.

BookMarker.java first downloads a bogus Java Commerce Message to start the Java Wallet. Once the Java Wallet is started, the applet can gain access to the field JECF.globals.releaseBundle and set that to a new ListResourceBundle of its own construction. The bogus Java Commerce Message causes the Java Wallet to display a phony message about an internal test along with instructions to press the “Help Contents” button for more information. If you do so, the applet then adds a bookmark to the Hostile Applets Home Page to your bookmarks.

Note that on Solaris systems lots of other options are available to the applet. Using the -remote flag allows the applet to run any of the Communicator’s xfeDoCommand options. Using the -java flag allows the applet to have the Communicator’s Java Runtime execute any Java program in your CLASSPATH. For example, this particular ListResourceBundle allows the applet to set up a ServerSocket and echo server on your machine. Clearly the ability to change the behavior of the “Help Contents” button can lead to much mischief.

DemonDialer: an applet which can use your modem

Our third example shows how an untrusted applet can exploit the Java Wallet to access the serial and parallel ports on your machine. This particular example, DemonDialer.java, first looks at all of the available ports on your machine. When it discovers a serial port, it lists some of that port’s properties. If a given serial port is free, the applet opens it and looks to see if a modem might be attached. If so, the applet sets some modem properties and then dials out. If the serial port is not free, or if something goes wrong, the applet sleeps for 10 seconds before trying again. The applet also resurrects itself in case of ThreadDeath and keeps going.

While this applet merely dials a toll-free number and waits 60 seconds before hanging up, it is easy to make the applet run up charges on your phone bill, connect to an evil modem with a computer waiting to attack your machine, and many other nasty things. Note that the applet will keep dialing out, so you will have to exit your browser in order to bring it to a halt. If you download the applet over your modem, the applet will lurk in the background and attack once your modem is not in use.

To try this applet, you first need to set up Sun’s Java Plug-in (or Activator) and Java Wallet on a machine running Windows NT or Windows 95. It works for both Netscape’s Communicator (4.04 and 4.05) and Microsoft’s Internet Explorer (4.0 and later). If you still want to try this applet, you’ll have to do so at your own risk.

The Java Wallet and its problems

While troubles like these are serious and embarrassing for vendors of any product that touts itself as a secure solution to the problems of electronic commerce, they need not be fatal for the Java Wallet. It is clear that they can all be corrected by properly restricting public access to methods in the Java Wallet’s classes. (Saving login and password information, while perhaps convenient for the user, is a foolish feature that should be removed from future releases of the Java Wallet.) All of these problems may, however, give another black eye to electronic commerce and leave lingering doubts in the public’s mind about the wisdom of trusting products like the Java Wallet. In that regard the Java Commerce team may be shooting itself in the foot by releasing a product with too many obvious flaws. We can only hope that as electronic commerce, Java Security and the Java Wallet all mature, we will see fewer and fewer such problems in Java-based products.

Links on this article:

Mark D. LaDue is currently a senior systems engineer at GTE in Irving, Texas. There he works on designing secure electronic commerce products for corporate clients. You can contact him at mladue@mindspring.com and Mark.LaDue@ap.bdi.gte.com.

Get the Free Newsletter!

Subscribe to Developer Insider for top news, trends & analysis

Latest Posts

Related Stories