[cryptography] PKI "fixes" that don't fix PKI (part III)

Ian G iang at iang.org
Sun Sep 11 08:58:38 EDT 2011

On 11/09/2011, at 7:50, Steven Bellovin <smb at cs.columbia.edu> wrote:

> On Sep 10, 2011, at 4:14 00PM, John Levine wrote:
>>> This makes no sense whatsoever.  Credit card numbers are *universally*
>>> encrypted; of course there's no interception of them.
>> There's a fair amount of low-level ecommerce by e-mail.  They don't
>> seem to be intercepted there, either.
>>> In 1993, there was interception of passwords on the Internet.
>> This strikes me as another example of "make your password totally
>> obscure and change it every week", advice that was specific to a long
>> ago environment that's been passed along as received wisdom.
>> In the early 1990s there was still a fair amount of coax Ethernet, and
>> twisted pair was usually connected to hubs rather than switches, so it
>> was easy for a bad guy on your network or intermediate networks to
>> snoop on the traffic.  These days, the only shared media are hotel and
>> coffee shop wifi.
>> While we've certainly seen evidence that bad guys snoop on open wifi,
>> it's not my impression that they're particularly looking for credit
>> cards, more often passwords to accounts they can steal.  The price of
>> stolen credit cards in the underground economy is very low, so there's
>> no point.  The chokepoint to using stolen cards isn't getting the card
>> numbers, it's to find cashers or money mules.
>> So while I agree that it's a good idea in general to encrypt your
>> traffic, I don't see any evidence that card numbers are at particular
>> risk.
> You're missing my point.  Let's take the definition of "threat" from the
> National Academies study "Trust in Cyberspace": an adversary that is
> motivated and capable of exploiting a vulnerability.  There are three
> keywords, "motivated", "capable", and "vulnerability".

Right. But the existence of a threat (actor or agent) does not result in a risk (one that needs to be mitigated).

To get from threats to risks, we gave to analyze the motivations (intents), capabilities, opportunities, effectiveness, vulnerabilities, likelihoods, consequences of actors, assets and scenarios.

Then, we get risks, from which we can divine mitigations.

(some will recognize I'm copying from the risk textbook here :)

> In 1993, the
> adversaries demonstrated that they had the capability to intercept
> traffic.  While we certainly don't use coax Ethernet today, we do use
> unencrypted or poorly encrypted wireless, quite regularly.  The
> link-layer vulnerability thus persists.

Yes, threat (actors) exist, as do vulnerabilities.

> The issue, then, is one of
> motivation -- given the current market price for stolen credit card
> numbers, are they motivated to try to steal them?  That answer in turn
> depends on the return per unit of effort expended.

Right. Easy to show motivation by attack scenario:

An eavesdropping attack is o(1) in work factor. That is, it's a hack, or script kiddie process.

(forget MITM)

Now, a breach is also o(1) work, as it's the same sort of hack / script kiddy thing.

But, a breach returns o(1000) units of value. An eavesdrop returns o(1) units.

Mix with standard math. QED. No actor in his right mind will bother to eavesdrop while breaches are possible.

Another way of seeing this is that only mass-production techniques will be considered. This explains phishing.

>  It is precisely
> because of SSL that the actual vulnerability rate is very low, which in
> turn removes the incentive.

Two opposing claims!  It seems that the encryption claim is a prediction based on theories of security.

Whereas, the no-encryption claim is based on economics. It also has the merit that the economics are supported by the prices and actions in the market for batches of stolen card sets.

> Thought experiment:

Good idea!

> suppose that SSL or other generally-effective
> encryption did not exist.  What is the likelihood that today's generic
> malware would contain a credit-card sniffing module as well as keystroke
> loggers, account/password stealers, etc?  I suspect that the odds are
> very high -- it's easy code to write, it's just another payload that
> they've demonstrated they have the capability to build, and -- absent
> SSL or equivalent -- it would likely be productive enough.

Ok, my analysis suggests the probability is low (or more accurately, its efficacy would be low). Others have pointed out that the cost if CCs reflects that. Therefore, the need for encryption is unsupported.

(thought experiment: would 40 bits be enuf? Would zero bits work, if SSL delivered strong authentication?)

Just one addition: note that the value of a validated CC is far in excess of an unvalidated CC. This also tips the balance towards CC numbers held in SQL-armoured files at secure merchants.


More information about the cryptography mailing list