From: Nathaniel Borenstein <nsb@nsb.fv.com>
Date: Thu, 1 Feb 1996 08:51:38 +0800
To: Pete Loshin <jsw@netscape.com>
Subject: Flaw in Netscape rejoinder (was Re: FV Demonstrates Fatal Flaw in Software Encryption of Credit Cards)
In-Reply-To: <01BAEF34.AA95ECC0@ploshin.tiac.net>
Message-ID: <gl3zCVKMc50e1T2Rsa@nsb.fv.com>
MIME-Version: 1.0
Content-Type: text/plain


I'm way behind on my email, but someone suggested privately that I
should respond to Jeff's mail, so I've bumped it to the top of the queue:

Excerpts from mail.cypherpunks: 30-Jan-96 Re: No FV supporters? Jeff
Weinstein@netscape. (903*)

> I sent a description of an attack against FV based on replacing
> or hacking winsock to cypherpunks last night.  This attack seems
> to meet Borenstein's criteria of being as automated and implementable
> on a mass scale as their keyboard snooping attack.  So far I have not
> seen any response from FV.

Sorry for the delay.  I don't think your attack against FV works
anywhere nearly as well as our attack against software-encrypted credit
card numbers, as I'll explain below.

I should also apologize for the fact that I couldn't resist in pointing
out lots of little problems with your proposed attack, and that I'm
responding to your plan in the order you described it.  This means that
we don't get to the really major flaw in your strategy towards the end,
so what comes at first will seem like nitpicking.

Excerpts from mail.cypherpunks: 30-Jan-96 Re: FV Demonstrates Fatal F..
Jeff Weinstein@netscape. (2739*)

> It would not be much harder than the demonstrated keyboard attack
> to create a hacked version of winsock that would implement an
> attack against First Virtual.  If the attacker had a list of web
> pages that accept FV payments it would be very easy to collect
> the ID numbers.  

A list of stores?  First of all, this attack is already amazingly
focused.  Our DLL to implement the attack on credit cards is 16K, and
doesn't need to target any specific buyers, sellers, or programs.  The
more complex the attack & the bigger the software, the more likely it is
to be noticed.  But this is just a minor nit.  Read on.

> There is no need to attack the large datastream
> of keyboard input when the search can be easily narrowed.  Since
> FV doesn't use encryption the attack could easily be implemented
> in winsock, making it independent of any client software.  

What's really funny (to me, at least) here and in a lot of other aspects
of the cypherpunk reaction to FV is the continuing assumption that the
choice of FV vs encryption is an either/or thing.  Combine FV's Virtual
PIN mechanism with transport encryption and you've indiputably got
something that's a LOT safer than just using credit cards with
encryption, and a bit safer than our current system, too.  But I know,
the correct focus here is FV's current system.  So read on.

At this point in your attack, you skip a step:  You don't explain how
you correlate the FV ID to email address.  This means that your attack
will ONLY work for systems where the user is always using the same PC to
web browse and read his mail.  In practice, even if this is true 99% of
the time, the remaining 1% would probably cause your attack to be
detected pretty quickly if deployed on a large, automated scale.  But,
for the sake of argument, let's imagine that it's true 100% of the time.
 Read on.

> A version
> that infected the win95 IP stack could be quite effective.  The list
> of FV accepting sites would be easily obtainable via a query of
> altavista.  Since the infected system is on the internet and has
> to periodically send its results to the attacker, it could download
> an updated list of FV pages at the same time.  

Seems to me your "not much harder" claim is starting to break down here,
with an automated virus spreading itself all over the net and
downloading lists from altavista weekly.  And the amount of net traffic
you're generating may make this attack a lot more quickly detected than
ours.  (In fact, I imagine that if the folks at AltaVista or Lycos noted
thousands of identical searches focused on merchants accepting First
Virtual, they'd probably contact us, more out of concern for their own
load management than anything else.)  But still, read on -- we're
finally coming to the good part.

> Attacking the e-mail verification step of the FV system could also
> be accomplished via a hacked winsock.  A bit of POP3 aware code
> in the winsock could intercept the verification messages and keep
> the e-mail client from ever seeing them.  It could automatically
> generate "Yes" responses for all such messages.

OK, so you're only interested in POP3 mail tools?  That's wonderful, but
there's also systems that use IMAP, systems that use raw SMTP to locally
resident message stores, and many odder things.  There's also people who
get their mail through AOL, Compuserve, Prodigy, etc.  There's people
who live on a PC or Mac, but who read mail on a UNIX system (e.g. many
Delphi and Netcom users).  

You're not going to catch all of them.  Moreover, even if you say
"that's fine, we only need some of them", your attack is now dead in the
water.  Why?  Because you have no way of telling, in your attack virus,
what kind of technology is going to be used to read mail.  This means
that your attack will inevitably, and quickly, hit some people who DO
receive the mail.  Our fraud department will be quickly notified (when
the user answers "fraud" to our query, a human sees it right away) and
we'll be off to the races, collecting clues.  It will be work tracking
it down, but we'll have a good shot in identifying the attack and
producing a program that helps users spot it on their system (the moral
equivalent of an anti-viral program) in less time than it would take you
to even suspect that the attack FV outlined had taken place in the world
of software-encrypted credit cards.

Your attack would be caught by us relatively quickly because our model
is based not on a single fail-safe piece of security software, but on
*process* security.  The overall process is multifaceted, with many
checks and balances.  What if, for example, I go to someone else's
machine and use their web browser to buy something using MY First
Virtual ID?  Your attack will capture my ID and allow you to try to use
it, but the email confirmation will go elsewhere, quite possibly to an
uninfected machine.  When reproduced on a mass scale, this kind of thing
will be noticed pretty fast.  In contrast, credit cards are a one-way
payment mechanism -- the number (and sometimes some other info typed in
close proximity) is basically all you need.  Just steal that without
getting noticed and the crime is done.

>   I believe that FV is just as vulnerable to these types of
> attacks as any of the encryption based credit card schemes, if
> not more so.  The thing that really protects FV is that it can
> only be used to buy bit, not real goods, and the bad guys don't
> generally care about stealing bits.  This is also what makes FV
> not generally useful to people who want to shop over the internet.

Actually, you're a bit behind the times.  We removed that restriction
from our system a couple of months ago.  There still aren't many people
using our system for physical goods, mostly because of our 91-day fund
holding period, but we have gotten the green light from our financial
partners to waive that for qualified, established merchants, once we
make a few technical changes behind the scenes.

The fact is that our original restriction against physical goods was
never designed to protect against fraud.  Rather, it was a conscious
attempt to do two things:  1) bound the risk our bank perceived in being
the first bank ever to explicitly agree to handle an Internet-based
payment system (this was mid-1994, remember), and 2) to focus the
attention of our prospective users on the situations that were in fact
reasonably well-suited to an economic model in which consumers had the
explicit option of refusing payment.  Some of our sellers very quickly
realized that no matter what we said, it was straightforward to use our
system for physical goods, shipping them only after the consumer said
"yes", and we eventually changed our terms and conditions to reflect
that reality.  The 91 day hold, on the other hand, WAS designed to
protect against fraud -- from the *merchant* side, which is why we have
no qualms about waiving it for qualified merchants.

Now, actually, I want to commend you.  This is as close as I've ever
seen anyone come to constructing a plausible automated attack on FV. 
The IP stack is a very clever attack vector, and I honestly can't claim
to have anticipated it.  However, I do think that the flaw in your
approach reinforces my belief in the importance of multi-layered
defenses.  In fact, a multi-layered security strategy is the ONLY
defense against vulnerabilities you haven't thought of yet.  That's the
real reason why ANY scheme based on one-way instruments like credit card
numbers is particularly hard to make secure.  -- Nathaniel
--------
Nathaniel Borenstein <nsb@fv.com>
Chief Scientist, First Virtual Holdings
FAQ & PGP key: nsb+faq@nsb.fv.com