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