Who's afraid of Mallory Wolf?

[Anne & Lynn Wheeler]

At 10:02 PM 3/24/2003 +0000, David Wagner wrote:
>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 majordomo at wasabisystems.com