On Fri, 2009-11-20 at 20:13 +1300, Peter Gutmann wrote:
> Because (apart from the reasons given above) with business use specifically
> you run into insurmountable PC <-> device communications problems. Many
> companies who handle large financial transactions are also ones who, due to
> concern over legal liability, block all access to USB ports to prevent
> external data from finding its way onto their corporate networks (they are
> really, *really* concerned about this). If you wanted this to work, you'd
> need to build a device with a small CMOS video sensor to read data from the
> browser via QR codes and return little more than a 4-6 digit code that the
> user can type in (a MAC of the transaction details or something). It's
> feasible, but not quite what you were thinking of.
So the model of interaction is:
Software displays transaction on the screen (in some
predetermined form)
Device reads the screen, MACs the transaction, and
displays MAC to user
User enters MAC to confirm transaction
Transaction, with MAC, is submitted to user's bank.
Bank checks MAC to make sure it matches transaction
and performs transaction if there's a match.
Malware that finds the user account details lying around
on the hard drive cannot form valid MACs for the transactions
it wants to use those details for, so the user and the bank
are protected from "credit card harvesting" by botnets.
Malware that attempts to get a user authorization by displaying
a different transaction on the screen is foiled by not being
able to MAC the transaction it's really trying to do. etc.
But a four or six digit MAC isn't nearly enough.
You see, there's still the problem of how you handle fraudulent
transactions. If the black hats start submitting transactions
with random MACs in the certain knowledge that one out of ten
thousand four-digit MACs will be right, all that happens is
that they have to invest some bandwidth when they want to drain
your account. They will do it, because it's more profitable
than sending spam.
If there is some "reasonable" control like freezing an account
after a thousand attempts to make fraudulent transactions or
not accepting transaction requests within twenty seconds after
an attempt to make a fraudulent transaction on the same account,
then you have created an easy denial-of-service attack that can
be used to deny a particular person access to his or her bank
account at a particular time of the attacker's choosing.
Denying someone access to their money makes them vulnerable at
an unexpected time - they can't get a hotel room, they can't get
a cab, they can't get a plane home, they can't buy gas for their
car and get stranded somewhere, and they become easy pickings
for physical crimes like assault, rape, theft of vehicle, etc.
That's not acceptable.
In order to be effective the MAC has to make success so unlikely
that submitting a fraudulent transaction has a higher cost than
its amortized benefit. Since the botnets are stealing their
electricity and bandwidth anyway, the absolute cost to black
hats of submitting a fraudulent transaction is very very close
to zero. What we have to look at then is their opportunity cost.
Consider the things a botted machine could do with a couple
kilobytes of bandwidth and a couple milliseconds of compute time.
It could send a spam or it could send a fraudulent transaction
to a bank with a random MAC. It will do whichever is considered
most profitable by the operator of the botnet.
Note: with spamming there's almost no chance of arrest. Receiving
money via a fraudulent transaction submitted to a bank *MIGHT* be
made more risky, so if that actually happens then there's an
additional risk or cost associated with successful fraud attempts,
which I don't account for here. But ignoring that because I don't
know how to quantify it:
In late 2008, ITwire estimated that 7.8 billion spam emails were
generated per hour. (http://www.itwire.com/content/view/19992/53/)
Consumer reports estimates consumer losses due to phishing at a
quarter-billion dollars per year.
(http://www.consumerreports.org/cro/magazine-archive/june-2009/
electronics-computers/state-of-the-net/phishing-costs-millions/
state-of-the-net-phishing-costs-millions.htm)
Check my math, but If we believe those sources, then that puts
the return on sending one spam email at 1/546624 of a dollar,
or about one point eight ten-thousandths of a penny. If we can
make submitting a fraudulent transaction return less than that,
then the botnets go on sending spams instead of submitting
fraudulent transactions and our banking infrastructure is
relatively safe. For now. (Just don't think about our email
infrastructure - it's depressing).
If a fraud attack seeks to drain the account, it'll go
for about the maximum amount it expects the bank to honor,
which means, maybe, a couple thousand dollars (most checking
accounts have overdraft protection that allows a fraudster to
drain a credit card up to its limit). Assume that, with a
correct MAC, half these transactions will still fail due to
insufficient funds.
So if the botnet has a choice between sending 546624
spams to make a dollar and submitting 546624 fraudulent
attempts to take $2000 out of a bank account, which is more
profitable? The profit on an attempt to take $2000 out of a
bank account is $1000 x the MAC false-positive rate. A 4-
digit MAC has a false-positive rate of 0.0001, which leaves
the profit level at about ten cents per attempt. A 6-digit
MAC reduces profit to a tenth of a cent per attempt - which
is still a vastly more profitable use of a botnet than
sending spam.
A nine-digit MAC will get the profit down to one ten-
thousandth of a cent; that's the smallest MAC that puts the
profit of submitting fraudulent transactions to banks lower
than the profit of using the same botted machine to send a
spam. I would add a couple of digits just in case the sources
I cited were wrong, or talking about different subsets of data,
and the return on spam is actually lower.
Still, there are qualitative differences. In order to be
profitable, spam requires human attention, and fraudulent
transactions have to evade human attention. There's only so
much human attention per hour available in the world. An
infrastructure of robots accepting or rejecting transactions
does not require human attention to defraud. The resources
it requires are essentially electricity and bandwidth, which
the botnets have in vast quantities because they steal it.
So we can expect the costs of submitting both spam and
fraudulent transactions to drop with Moore's law. But the
return on spamming will rise only with the amount of available
human attention that isn't already captured by other spam,
whereas the return on fraudulent transactions would approach
a relatively constant ratio as available human attention to
combat fraud relative to the number of fraud attempts drops.
At some point the two curves intersect, fraudulent transactions
become more profitable than spam, and the following week half
the botnets in the world are attacking banks instead of
spamming. I think we'd want to add another three digits
and make a 14-digit MAC just to keep that day at least
15 years in the future.
Also, we wind up in the unenviable position that if we do
anything that successfully reduces the return on spamming,
and it reduces the spamming rate of return below the rate
of return on fraudulent transaction attempts, then within
the space of just a week or so, the botnets will be refocused
on fraudulent transactions as having a higher rate of return,
and the banks won't be ready for the million-fold or billion-
fold increase in bandwidth that they have to sift through in
order to find their legit transactions. On the bright side,
I'm sure they'll be able to buy or lease the required networks
cheap, from people who've been handling email....
Bear
---------------------------------------------------------------------
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to majord...@metzdowd.com
