FV's Borenstein discovers keystroke capture programs! (pictures at 11!)

Is this the most transparent media attention grab or what?  FV's
"Chief Scientist" writes a killer application to destroy
Internet commerce and it is really only a keystroke capture
program with a bit of credit card number recognition code tacked
on.

I don't think this has any "implications for Internet commerce".
If you run any number of virus protection programs on your
computer, and you get your software from reliable sources,
you never need worry about clandestine number snarfing.

I readily admit that there is a larger issue about viruses and
being able to trust your software, but the presentation from FV
of this announcement as a "fatal flaw" in internet commerce is
remarkably disingenuous.  They are really saying, "We have the
only safe approach" quietly between the lines.

And before pm. says it, this has very little to do with
cryptography.

Skeptically yours,

	David Macfarlane.

Well, the mis-conceptions are flying fast and furious.

1.  I didn't write the program.

2.  It has nothing to do with viruses.  No current virus protection
program will ever detect this thing, and if you write a program that
detects one instantiation of the attack, the program can be easily
changed to require a new "detector" program.  This means you can only
protect against the last attack, not the next one.

> I readily admit that there is a larger issue about viruses and
> being able to trust your software, but the presentation from FV
> of this announcement as a "fatal flaw" in internet commerce is
> remarkably disingenuous.  They are really saying, "We have the
> only safe approach" quietly between the lines.

You're twisting our words.  We believe it is a truly fatal flaw in those
internet commerce schemes that are based on software encryption of
credit card numbers.  There are several schemes for Internet commerce
that are unaffected:

	-- First Virtual (of course)
	-- Hardware encryption (e.g. consumer card-swipe machines)
	-- Smart cards
	-- Digital cash (unless the tokens are made too easy to recognize)

We say this VERY EXPLICITLY in our web pages. We are NOT saying we have
the only safe approach.  We have one of four safe approaches that we
know of.  But software encryption of credit card numbers is so easy to
circumvent that it is, in practice, useless.  (The only threat it really
protects against is network-based sniffers, which are harder to write
and more traceable than the attack we have just outlined.)

> And before pm. says it, this has very little to do with
> cryptography.

Agreed 100%.  I never claimed otherwise.  It does, however, emphasize
the *limits* to the security provided by cryptography, something that
cypherpunks are well aware of but that the general public is not aware
of.  -- Nathaniel

-----BEGIN PGP SIGNED MESSAGE-----

In list.cypherpunks, nsb@nsb.fv.com writes:

> Well, the mis-conceptions are flying fast and furious.

And not just from the rest of us.  Your model is a malicious program
that is installed on a user's machine (through whatever method, be it
viral, trojan horse, black bag job, whatever).  Fine, let's explore it a
bit.

> There are several schemes for Internet commerce
> that are unaffected:
>
>         -- First Virtual (of course)

If all my malicious program does is sniff keystrokes, FV accounts are
less vulnerable.  So I'll make my malicious program not only sniff
keystrokes, but I'll hook your Winsock stack and intercept the POP3
queries.  That way, I can catch the FV verification messages and confirm
them.  You'll never see anything happen.

>         -- Hardware encryption (e.g. consumer card-swipe machines)

So I'll get my malicious program to look for blocks of seemingly random
data from the keyboard (where many swipe systems wedge in) or the com
ports not used by mouse and modem.  (on a PC platform, that's not likely
since heroic measures are needed to run more than 2 com ports)  Unless
seeded by the transaction, these blocks should be vulnerable to a replay
attack.

>         -- Smart cards

Smart cards may not be vulnerable to replay attacks, so you may be
correct here.

>         -- Digital cash (unless the tokens are made too easy to recognize)

Or the site initiating the transaction is recognizable, prompting the
malicious program to take notice.  And since I've hooked all your net
services, I can steal your coins easily... the transactions you send
will never reach their destination.

The "fatal flaw" here is that you haven't extended your threat model to
its logical conclusion.  If you assume a malicious program with access
to the keyboard at the hardware level, that program could also access
and manipulate the TCP/IP stack, as well as data flowing to/from
networked applications of all sorts.

> We say this VERY EXPLICITLY in our web pages. We are NOT saying we have
> the only safe approach.  We have one of four safe approaches that we
> know of.

I only see one approach that's safe from local eavesdropping, and FV
isn't it.
- -- 
           Roy M. Silvernail     [ ]      roy@cybrspc.mn.org
PGP Public Key fingerprint =  31 86 EC B9 DB 76 A7 54  13 0B 6A 6B CC 09 18 B6
                Key available from pubkey@cybrspc.mn.org

-----BEGIN PGP SIGNATURE-----
Version: 2.6.2

iQCVAwUBMQ4Vihvikii9febJAQH6QgP/UaIlgQEmRgfS27DoOtr30BpTtR3H24bL
6fQRV1c99S7hPCAo3LPK28JH5HLC5WgoLZZBnNfu9eE4YcaSdOgC2Ok4Un3uSI2i
ZFOGP+OPN7BQRE/7iLF9nLT9NmktGiZ0mFffCzqIKGWP/PH87/YJtJzJwlqdTNp4
BCJsnFlX04w=
=osLe
-----END PGP SIGNATURE-----

In message <9601292041.AA14422@zip_master2.sbi.com>, 
  David Macfarlane wrote:
> Is this the most transparent media attention grab or what?  FV's
> "Chief Scientist" writes a killer application to destroy
> Internet commerce and it is really only a keystroke capture
> program with a bit of credit card number recognition code tacked
> on.
> 
> I don't think this has any "implications for Internet commerce".
> If you run any number of virus protection programs on your
> computer, and you get your software from reliable sources,
> you never need worry about clandestine number snarfing.

I especially liked the bit about being available under all sorts of
Microsoft OSs but not yet implemented under Unix. (which doesn't in
general *have* APIs or screen savers or all the other guff.

If secure input is needed then it shouldn't be too much of a
problem. I doubt the program would recognize either of INTERCAL input
or output (as a random example)

> I readily admit that there is a larger issue about viruses and
> being able to trust your software, but the presentation from FV
> of this announcement as a "fatal flaw" in internet commerce is
> remarkably disingenuous.  They are really saying, "We have the
> only safe approach" quietly between the lines.

But it's hardly *new* as you say. All in all, a quite convincing
little article. Could almost be worth modifying and posting to the
Germans about something or other.

> And before pm. says it, this has very little to do with
> cryptography.

Or trees.

--
Packrat (BSc/BE;COSO;Wombat Admin)
Nihil illegitemi carborvndvm.

-----BEGIN PGP SIGNED MESSAGE-----

Hello dmacfarlane@zip.sbi.com (David Macfarlane), cypherpunks@toad.com
  and packrat@tartarus.uwa.edu.au
        (ie Bruce Murphy <packrat@ratbox.rattus.uwa.edu.au>)
 
BM wrote:
> In message <9601292041.AA14422@zip_master2.sbi.com>, 
>   David Macfarlane wrote:
...
> If secure input is needed then it shouldn't be too much of a
> problem. I doubt the program would recognize either of INTERCAL input
> or output (as a random example)
...

Original INTERCAL had numbers spelled out in English as input, and
output in butchered roman numerals. I guess you can get people
to do the input (four or eight digits at a time only), but I don't think
the roman numerals are going to cut it, somehow...  and anyway it's
not that much more secure.

C-INTERCAL is less anglo-centric, allowing numbers to be input in
eight languages (eight = ashtan = zortzi = walo = chicue = rva =
malhgwenalh = j"ol). But do you really think people will be willing
to spell their credit-card number in classical Nahuatl for the
sake of security (the *bank's* security)?

If you mean INTERCAL as a programming language, then I guess you
can use the C-INTERCAL binary I/O (character deltas, output reverse),
but then it's no different to any other programming language (except
nobody bothered to implement file and network I/O for it yet so you'd
have to invent it yourself).

...
> > And before pm. says it, this has very little to do with
> > cryptography.
> 
> Or trees.

Well, how about security through INTERCAL? Would anyone be able to
figure out what an INTERCAL encryption program is doing?

What does the following fragment do?

        PLEASE DON'T GIVE UP
        DO .3 <- !3~#15'$!3~#240'
        DO .3 <- !3~#15'$!3~#240'
        DO .2 <- !3~#15'$!3~#240'

(Hint: it's from the "cat" program, ie copy stdin to stdout verbatim.)


Anyone have a bignum library in the said language?
 

For the person who was worried about his Linux box, perhaps the 
virus runs under WINE? (And you *know* how dangerous these viruses
can get when they are drunk :-)


I think I'll put [NOISE] into the subject line...

Jiri
- --
If you want an answer, please mail to <jirib@cs.monash.edu.au>.
On sweeney, I may delete without reading!
PGP 463A14D5 (but it's at home so it'll take a day or two)
PGP EF0607F9 (but it's at uni so don't rely on it too much)

-----BEGIN PGP SIGNATURE-----
Version: 2.6.2i

iQCVAwUBMQ7/OyxV6mvvBgf5AQEofgQA7cU//xtzW6/A0uRvMSPi7zrBKDoE+q5a
WpHR2VW7V9fCWfC4dj2MtIVgk/5L90C0lLcEIeYLwJUoPf9+NspWrIG7glWVv3Oj
55ctRz0682ZIBuRXr+OzxSQXfa8QlpjynHtPi9kHnWHFSXzJBeZeAe80lYllLLzK
am1pu+ky53k=
=EVVx
-----END PGP SIGNATURE-----