Crypto dongles to secure online transactions

Ray Dillinger bear at
Sun Nov 22 14:18:28 EST 2009

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. (
Consumer reports estimates consumer losses due to phishing at a 
quarter-billion dollars per year. 

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....


The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to majordomo at

More information about the cryptography mailing list