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

Thanks to Sandy Sandfort for bringing this to my attention.

   Date: Mon, 29 Jan 1996 15:07:46 -0500 (EST)
   From: Nathaniel Borenstein <nsb@nsb.fv.com>

   As you may already have heard via the popular press, First Virtual
   Holdings has developed and demonstrated a program which completely
   undermines the security of every known credit-card encryption mechanism
   for Internet commerce.

I'm breaking my silence in cypherpunks to respond to what must be the
most self-serving and fatuous expression of "concern" I've seen in a
while.

To wit:  Ohmygod!  PC's don't have perfect integrity!

Will someone please write a filter for common email packages which
automatically removes selected First Virtual transactions from the
confirmation messages?  Encryption isn't the issue, Nathaniel, and you
know it.  Me, I prefer bad faith over stupidity as an explanation for
this latest outpouring.

To all those Internet payment analysts out there:
   Financial institutions are in the business of risk transfer.  If
you don't transfer risk in some form, you're not a financial
institution but rather a service bureau.  Managing endpoint integrity
risk is just one of the kinds of risk an Internet payments provider
has to deal with.  First Virtual has demonstrated time and again that
they're pretty clueless about the whole subject of risk.  As a result,
I don't give them more than about two years longer before they go
belly up.

Eric

Excerpts from mail: 29-Jan-96 re: FV Demonstrates Fatal F.. Eric
Hughes@remailer.net (1441)

> I'm breaking my silence in cypherpunks to respond to what must be the
> most self-serving and fatuous expression of "concern" I've seen in a
> while.

It's a pity, Eric, that before coming down off the mountain, you didn't
stop to understand the real attack we're outlining.  I expected that
even if you didn't like what we were doing, you'd take the time to
understand it rather than embarass yourself.

> To wit:  Ohmygod!  PC's don't have perfect integrity!

The fact that PC's don't have perfect integrity is only *one* of the
four known vulnerabilities -- keyboard sniffing being another -- that we
have combined into a comprehensive, devastating attack that has never
been publicly mentioned before.

> Will someone please write a filter for common email packages which
> automatically removes selected First Virtual transactions from the
> confirmation messages?  

I've already written it.  So what?  Stealing or forging a single
transaction is EASY in almost ANY commerce system ever invented.    The
flaw we've uncovered in encrypted credit cards allows a single criminal
to automate the theft of millions of card numbers.  That's a very
different story.

> Encryption isn't the issue, Nathaniel, and you know it.  

Not only do I know it, I ***SAID*** it.  It's painfully obvious that you
didn't read our announcements very carefully, so I'll excerpt the
relevant paragraph:

> Encryption has high value in protecting sensitive information while in 
> transit. We strongly believe in encryption and use PGP, as licensed 
> users, daily. But it is clear that software-based encryption cannot 
> ensure secure credit card transactions. Encryption remains an important 
> part of computer security and is very important for protecting privacy. 
> But recognition of credit card numbers at the keyboard is trivial, and 
> therein lies the fatal flaw to software-based encryption of credit cards 
> -- sensitive information can be intercepted before it ever gets 
> encrypted. 

The issue is definitely not encryption.  The issue is that credit card
numbers are self-identifying one-way payment instruments, and there's no
way to make such instruments safe to use on insecure consumer computing
platforms.  The only reason that encryption even enters the discussion
is that there are OTHER parties who are claiming that their software
encryption products make such payment instruments safe.  They don't. 
That's all we're pointing out.

> To all those Internet payment analysts out there:
>    Financial institutions are in the business of risk transfer.  If
> you don't transfer risk in some form, you're not a financial
> institution but rather a service bureau.  Managing endpoint integrity
> risk is just one of the kinds of risk an Internet payments provider
has to deal with.  

Yes.  But the BIGGEST risk that an Internet payments provider has to
deal with is the threat of large-scale, systematic, automated fraud. 
And *that* is the hole we have just blown in the
software-encryption-of-credit-card schemes, and which you clearly didn't
take the time to understand.

> First Virtual has demonstrated time and again that
> they're pretty clueless about the whole subject of risk.  

Well, I think our financial industry partners will take our "clueless"
level of risk management any day.  We have fraud and chargeback rates so
low that they're scarcely believeable, because nearly all fraud AND
dissatisfied customers are caught by the email loop and never make it
into the credit card system in the first place.  Our acquiring bank
thinks that's pretty neat, I think.  In fact, it's worth noting that
after being our acquiring bank for over a year of live operation, and
having the most inside information possible about how our system works,
First USA Bank (one of the nation's largest credit card banks) made a
large equity investment in us last month.  Do you really think they
didn't do any risk analysis? -- Nathaniel
--------
Nathaniel Borenstein <nsb@fv.com>
Chief Scientist, First Virtual Holdings
FAQ & PGP key: nsb+faq@nsb.fv.com

My mailer insists that Nathaniel Borenstein wrote:
> Excerpts from mail: 29-Jan-96 re: FV Demonstrates Fatal F.. Eric
> Hughes@remailer.net (1441)
> > First Virtual has demonstrated time and again that they're pretty
> > clueless about the whole subject of risk.
>
> Well, I think our financial industry partners will take our
> "clueless" level of risk management any day.

Glad we're not a partner.

---
Paul M. Cardon
System Officer - Capital Markets Systems
First Chicago NBD Corporation

MD5 (/dev/null) = d41d8cd98f00b204e9800998ecf8427e