Re: FV Demonstrates Fatal Flaw in Software Encryption of Credit Cards

[Nathaniel Borenstein <nsb@nsb.fv.com>]

Excerpts from mail: 29-Jan-96 Re: FV Demonstrates Fatal F.. Jonathan
Rochkind@cs.obe (3157*)

> 1) I remember Mr. Borenstein saying a year or two ago, something like "We
> have nothing against encryption; we're just using a non-encrypting
> technique for the moment, becuase it can be quickly, easily, and safely
> deployed by us. Eventually,  we'll probably use encryption."    Apparently,
> this propaganda piece marks a change of strategy.

No, what it marks is a growing understanding.  When I said that, over a
year ago, I still thought that software encryption of credit card
numbers could be a workable solution.  I no longer do, based primarily
on my very recent realization that we could mount a multi-stage fully
automated attack on such systems.

> 3)  I believe that FV works by assigning the user some sort of id number.
> They send the id accross the net, FV has a database with "FV-ID" <->
> credit-card-number correspondences, the merchant sends FV the id, FV bills
> your card and pays the merchant.  Now, if I'm correct about how FV works,
> we could clearly write a program that searches your HD for FVs data files,
> extracts your FV-ID from it, and steals it.  It could be a virus, it could
> send the FV accross the net, whatever.  We could then use your FV-ID to
> make fraudulently make purchases through the FV system that would be billed
> to you.  This is essentially the same attack as FV "demonstrates" against
> software encrypted credit cards over the net: that is, the "You have an
> insecure system and if we can put evil software on it, we can get you."
> attack.

This is wrong on two main counts:  the ID's are harder to find than
credit cards, and they're not as directly useful as credit cards.  These
two facts combine to make the attack more or less irrelevant to FV.

First of all, the Virtual PIN (FV-ID) is much harder to extract from a
large data stream because it is arbitrary text, unlike credit card
numbers, which are self-identifying.

Second, a Virtual PIN is not a one-way payment instrument, like a credit
card.  To use FV to buy something on your credit card, you need to
combine the theft of a Virtual PIN with the compromise of the buyer's
email account, for confirming transactions.  We all know this can be
done -- we actually even spell out how to do it in our paper, "Perils
and Pitfalls of Practical CyberCommerce" -- but it is very hard to
combine these steps on the large scale that would be needed to mount an
automated attack, which is the most serious threat to the credit card
system.

> True, we wouldn't have your credit card number, and we couldn't order stuff
> from LL Bean billed to you.  We could just order stuff from FV merchants.
> So maybe it's marginally better.  Maybe.  But I can't see any way FV could
> be immune to an attack of this sort.  I believe that all they do is give
> you a first virtual ID number sent accross the net (in the clear!) in lieu
> of your card number.      With an insecure PC as an assuption (and it is
> probably a good one, actually), I can't see how FV could be immune from an
> attack of this sort.   If Mr. Borenstein or anyone else thinks it is,
> please explain how.

I hope that I jut did.  My guess is that you didn't understand the email
confirmation that is required for every purchase in the FV system.  For
more information, please see our web pages at http://www.fv.com.  --
Nathaniel
--------
Nathaniel Borenstein <nsb@fv.com>
Chief Scientist, First Virtual Holdings
FAQ & PGP key: nsb+faq@nsb.fv.com