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-----
participants (5)
-
Bruce Murphy
-
dmacfarlane@zip.sbi.com
-
Jiri Baum
-
Nathaniel Borenstein
-
roy@sendai.cybrspc.mn.org