1996-01-30 - Re: FV Demonstrates Fatal Flaw in Software Encryption of Credit Cards

Header Data

From: Nathaniel Borenstein <nsb@nsb.fv.com>
To: andreas@horten.artcom.de (Andreas Bogk)
Message Hash: 565d1f1dce96af785013f9094d19120a8a63af502ad0f4e41af7ba1e74fa77c5
Message ID: <Yl3XRQCMc50e5Ir7pt@nsb.fv.com>
Reply To: <Al3GYGSMc50eQWYAdR@nsb.fv.com>
UTC Datetime: 1996-01-30 18:00:25 UTC
Raw Date: Wed, 31 Jan 1996 02:00:25 +0800

Raw message

From: Nathaniel Borenstein <nsb@nsb.fv.com>
Date: Wed, 31 Jan 1996 02:00:25 +0800
To: andreas@horten.artcom.de (Andreas Bogk)
Subject: Re: FV Demonstrates Fatal Flaw in Software Encryption of Credit Cards
In-Reply-To: <Al3GYGSMc50eQWYAdR@nsb.fv.com>
Message-ID: <Yl3XRQCMc50e5Ir7pt@nsb.fv.com>
MIME-Version: 1.0
Content-Type: text/plain

Excerpts from mail: 30-Jan-96 Re: FV Demonstrates Fatal F.. Andreas
Bogk@horten.artc (2677)

> First, pray tell, what prevents me from writing a virus that patches,
> say, Eudora and Netscape, so they automatically reply to all FV-mails?

Nothing at all.  But it's still not an automated mass-scale attack,
because that's only one piece of the mechanism (which we spell out) for
breaking FV.  The essence of FV's security is that we don't believe that
there's any single bit of technology or magic (cryptographic or
otherwise) that provides security, and that real security comes from a
series of complex defenses.  This approach is particularly good at
discouraging automated attacks.

Moreover, this attack is almost guaranteed to leave traces and be
detected within a single billing cycle.  Once the credit card bill comes
in, the patch in Eudora/Netscape will be discovered, and people will
start looking for its source.  In contrast, the scheme I have outlined
steals credit card numbers without any connection to the point of theft,
which in practice will mean that the attack will go undiagnosed and
without countermeasures for a lot longer, because there will be no
obvious correlation to the Internet as a point of theft.

> > to identify the corresponding email address (which
> >is not public knowledge, cannot be determined from the account
> >identifier, and will not be released by First Virtual); 

> ... which is in the header of said E-Mail ...

Typically, they flow over the web, where there's no email address
present.  You need traffic analysis.  Just makes it harder to automate,
that's all.

> And while I'm at it, it doesn't take much to be more secure than
> credit card payments. You shouldn't be too proud of that.

We're very proud of it because it's the competition.

> And it shouldn't take an experienced programmer one whole week to
> write a keyboard sniffer.

That included the user interface and a number of precautionary
mechanisms, with very careful coding to make sure that there weren't
hidden problems that would bite us.  The engineer who wrote it is very
good, but I also know that several people have since duplicated the
basic mechanism in a day or two.

> But I think it's not too pessimistic to say that _any_ software-based
> payment scheme can be hacked using malicious programs.

Right.  And the key, as I keep saying, is automation.  You have to
defend against an automated attack.

> Oh, wow, it's your secret. I would post a message containing the
> credit card number encrypted with a public key cipher to
> alt.foo.bar. Or to the IRC. And it's not too difficult to hack
> university computers, so I could even receive mail there without being
> traceable. Not to speak of remailer chains. Any other ideas?

Actually, one of your methods is very close to my preferred method, but
there are still some better wrinkles possible.  I prefer to leave them
as an exercise for the reader -- my academic background, I guess.  :-)  
 -- Nathaniel
Nathaniel Borenstein <nsb@fv.com>
Chief Scientist, First Virtual Holdings
FAQ & PGP key: nsb+faq@nsb.fv.com