...

This work was supported in part by Defense Advanced Research Project Agency (ARPA contract F33615-93-1-1330), the National Science Foundation (NSF cooperative agreement IR-9411299), the US Postal Service, and Visa International. This work is the opinion of the authors and does not necessarily represent the view of their employers, funding sponsors, or the US Government.

.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.

...[2].)

In his First Virtual work [14, 8], Borenstein and his colleagues argue for a system where a consumer would enter a First Virtual account number, rather than directly entering credit card information. Consumers would have the opportunity to review and decline charges that were improperly made on their account. While this certainly protects the credit card account, there is still an issue of providing maximum protection of the First Virtual account number from trojan horse attack.

.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.

...retrieval.

Strictly speaking, this type of attack is not limited to electronic commerce protocols. Indeed, there appears to be no limit to the possible mischief that can be caused by trojan horse programs that infiltrate a consumer's machine. A trojan horse might emulate a word processor, causing (potentially sensitive) text to be transmitted to an adversary. It might infect an e-mail system allowing messages to be read by third parties. It might infect a compiler allowing trojan horses to be inserted in locally compiled programs [17]. Ultimately, any application program might be emulated. However, the case of electronic commerce is particularly compelling since there is a well-defined target of attack - the consumer's credit card numbers or bank account information.

.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.

...security

Recently, Dean, Felton, and Wallach [5] and others have argued that substantial flaws exist in the Java API library and in the methods used to check type safety. These flaws lead to direct attacks that can be implemented in Java applets. Our work is orthogonal to these flaws: even a hypothetical ``perfectly secure'' version of Java would permit these types of attacks. We discuss this further in section 2.

.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.

...code

Java source code for our applet is available at http://blind.trust.cs.cmu.edu/spoof.class.

.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.

...number.

Note: This differs substantially from the way that ATM machines operate. Typical ATM authentication today relies only on local encrypted information stored on a single ATM card. No central database query is done until after authentication is complete [4]. The solution discussed here would require an initial lookup by a centralized machine of the user's particular window personalization style, making the ATM protocol less efficient.

.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.

...attack.

Even smartcards can not completely solve these problems; for a discussion of the difficulties with the smartcard approach to solving the POS integrity problem, see [9].

.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.