Local trojan horses

A consumer may have a local trojan horse running on her machine. This type of local trojan horse can:

• imitate remote pages, or
• grab keystrokes (such as SET entry keystrokes) from the local machine. (The possibility of this type of attack has been known in the computer science folklore for many years; recently Nathaniel Borenstein gave a dramatic demonstration of trojan horse keystroke grabbing [2].)

In the past, consumers have been protected by the relative difficulty of loading trojan horse applications onto arbitrary workstations. If the consumer took moderate care to protect herself from loading untrusted software (including viruses and worms), she could reduce the risk of attack to a manageable level.

However, local trojan horses are particularly dangerous for electronic commerce protocols that depend on the local client interfaces to obtain and securely handle confidential information. Examples of systems that use these features include SET (discussed above) and NetBill[16, 3] For example, if a trojan horse emulation of the SET interface is very well done, it may be difficult or impossible for the consumer to determine whether she is dealing with the true program or not. Such a rogue program could transmit the consumer's credit card number directly to the adversary; alternatively, it could store it for later retrieval.

Java applets[10] have changed the balance of power -- increasing the possibility of untrusted software and local trojan horses being transferred to a workstation. Java applets are usually loaded onto a workstation without requiring explicit applet-by-applet consent by the consumer. If a Java applet created by an adversary is loaded onto the consumer's workstation, the applet can put arbitrary images on the screen within the browser window and can communicate keyboard information back to a host. A consumer may not be able to distinguish the trojan horse applet display from a valid information request. Thus, Java applets can easily serve as trojan horses that mimic electronic commerce applications. Java is not the only culprit. Other remote execution mechanisms such as Omniware [1], Telescript [12], and Dyad [18] provide ample opportunities to download programs to a consumer's computer that can display arbitrary graphical interfaces and transmit information to an adversary. In section 3 below, we discuss an example trojan horse Java applet that we developed which performs its own emulation of a standard Netscape dialogue box. Normally, consumers expect Java applets to display windows and dialogue boxes only with a warning bar underneath them. By writing our own graphics routines, we were able to make our applet bypass the standard Java window library and write directly to the screen. This makes our Java applet output bit-for-bit indistinguishable from the standard Netscape I/O display boxes. As we discuss in section 2 below, standard Java security mechanisms are useless for protection against this type of attack.