You could take your argument even further and ask whether any crypto was needed at all. After all, most attacks have worked by compromising the endpoint, not by sniffing network traffic. I'll let you decide whether to count this as a success story for SSL, or as indication that the crypto wasn't needed in the first place. (I'm a little skeptical of this argument, by the way, but hey, if we're playing devil's advocate, why not aim high?)
I assert that there may be more sites that transmit credit card numbers w/o crypto, as sites that use SSL (although transaction rates are highly skewed so they even if it were ten times the number of sites, it might represent fewer actual transmissions). I don't have actual numbers, but I am aware of significant number of sites. However, I would contend that harvesting numbers from end-point merchant files has significantly higher return (ROI, expected results for the effort) than any sort of network evesdropping ... and that it is practically impossible to provide the necessary armoring as countermeasure for this vulnerability; end point attacks by either insider and outsider (historically, insider attacks on financial infrastructure have represented vast majority of incidents. While it may be possible to do a single armored site .... it isn't practical to do a million such sites (for one thing, people make too many mistakes) ... as per previous ref to security proportional to risk (and the merchant file risk is proportional to the credit limits of the accounts, not the specific merchant transaction).
I would expect that network evesdropping would be employed where vulnerability was something other than kind of fraud do'able by attacking the end-point merchant file. Note however, skimming (various kinds of electronic & non-electronic recording) does go on in the physical world. Part of the issue may be that the target object (account number) has much lower occurance in general internet traffic (physical world skimming involves traffic that is almost solely account numbers). If you just have to skim, there are some number of points that are much more target rich environments (better fraud ROI) than internet traffic.
There is some phrase that if the only thing you know how to use is a hammer, then every solution may involve a nail.
The fundamental problem with account numbers is that they are effectively a kind of shared-secret .... acquiring/harvesting the numbers enables fraud. There are significant number of business processes that require the availability of the account numbers. This is one of the reasons for the end-point merchant files and also why "SET" (with significantly more complex crypto infrastructure and essentially only, also addressing data in-flight) offered very little additional over what my wife and I were involved with setting up the original SSL for e-commerce.
http://www.garlic.com/~lynn/aadsm5.htm#asrn2
http://www.garlic.com/~lynn/aadsm5.htm#asrn3
The point of x9.59 wasn't to add even more layers of crypto and information hiding to protect these shared-secrets .... but to change the business model so that the account numbers were no longer shared-secrets. X9.59 uses simple digital signature for authenticated payment transactions and a business rule that account numbers used in x9.59 transactions can't be used in non-authenticated payment transactions.
http://www.garlic.com/~lynn/index.html#x959
aka just by evesdropping an x9.59 transactions or harvesting account numbers used in x9.59 transactions doesn't enable a crook to initiate a fraudulent payment transaction.
--
Anne & Lynn Wheeler http://www.garlic.com/~lynn/
Internet trivia 20th anv http://www.garlic.com/~lynn/rfcietff.htm
--------------------------------------------------------------------- The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
