Entries Tagged "credit cards"

Page 4 of 9

Cybercrime as a Tragedy of the Commons

Two very interesting points in this essay on cybercrime. The first is that cybercrime isn’t as big a problem as conventional wisdom makes it out to be.

We have examined cybercrime from an economics standpoint and found a story at odds with the conventional wisdom. A few criminals do well, but cybercrime is a relentless, low-profit struggle for the majority. Spamming, stealing passwords or pillaging bank accounts might appear a perfect business. Cybercriminals can be thousands of miles from the scene of the crime, they can download everything they need online, and there’s little training or capital outlay required. Almost anyone can do it.

Well, not really. Structurally, the economics of cybercrimes like spam and password-stealing are the same as those of fishing. Economics long ago established that common-access resources make for bad business opportunities. No matter how large the original opportunity, new entrants continue to arrive, driving the average return ever downward. Just as unregulated fish stocks are driven to exhaustion, there is never enough “easy money” to go around.

The second is that exaggerating the effects of cybercrime is a direct result of how the estimates are generated.

For one thing, in numeric surveys, errors are almost always upward: since the amounts of estimated losses must be positive, there’s no limit on the upside, but zero is a hard limit on the downside. As a consequence, respondent errors—­ or outright lies—cannot be canceled out. Even worse, errors get amplified when researchers scale between the survey group and the overall population.

Suppose we asked 5,000 people to report their cybercrime losses, which we will then extrapolate over a population of 200 million. Every dollar claimed gets multiplied by 40,000. A single individual who falsely claims $25,000 in losses adds a spurious $1 billion to the estimate. And since no one can claim negative losses, the error can’t be canceled.

[…]

A cybercrime where profits are slim and competition is ruthless also offers simple explanations of facts that are otherwise puzzling. Credentials and stolen credit-card numbers are offered for sale at pennies on the dollar for the simple reason that they are hard to monetize. Cybercrime billionaires are hard to locate because there aren’t any. Few people know anyone who has lost substantial money because victims are far rarer than the exaggerated estimates would imply.

Posted on May 2, 2012 at 7:10 AMView Comments

PCI Lawsuit

This is a first:

…the McCombs allege that the bank, and the payment card industry (PCI) in general, force merchants to sign one-sided contracts that are based on information that arbitrarily changes without notice, and that they impose random fines on merchants without providing proof of a breach or of fraudulent losses and without allowing merchants a meaningful opportunity to dispute claims before money is seized.

It’s the first known case to challenge the heart of the self-regulated PCI security standards ­ a system that requires businesses accepting credit and debit card payments to implement a series of technological steps to secure data. The controversial system, imposed on merchants by credit card companies like Visa and MasterCard, has been called a “near scam” by a spokesman for the National Retail Federation and others who say it’s designed less to secure card data than to profit credit card companies while giving them executive powers of punishment through a mandated compliance system that has no oversight.

The PCI standards are probably the biggest non-government security standard. It’ll be interesting to see how this turns out.

Posted on January 16, 2012 at 9:58 AMView Comments

Multiple Protocol Attacks

In 1997, I wrote about something called a chosen-protocol attack, where an attacker can use one protocol to break another. Here’s an example of the same thing in the real world: two different parking garages that mask different digits of credit cards on their receipts. Find two from the same car, and you can reconstruct the entire number.

I have to admit this puzzles me, because I thought there was a standard for masking credit card numbers. I only ever see all digits except the final four masked.

Posted on December 20, 2011 at 6:24 AMView Comments

Biometric Wallet

Not an electronic wallet, a physical one:

Virtually indestructible, the dunhill Biometric Wallet will open only with touch of your fingerprint.

It can be linked via Bluetooth to the owner’s mobile phone ­ sounding an alarm if the two are separated by more than 5 metres! This provides a brilliant warning if either the phone or wallet is stolen or misplaced. The exterior of the wallet is constructed from highly durable carbon fibre that will resist all but the most concerted effort to open it, while the interior features a luxurious leather credit card holder and a strong stainless steel money clip.

Only $825. News article.

I don’t think I understand the threat model. If your wallet is stolen, you’re going to replace all your ID cards and credit cards and you’re not going to get your cash back—whether it’s a normal wallet or this wallet. I suppose this wallet makes it less likely that someone will use your stolen credit cards quickly, before you cancel them. But you’re not going to be liable for that delay in any case.

Posted on February 18, 2011 at 1:45 PMView Comments

Trojan Steals Credit Card Numbers

It’s only a proof of concept, but it’s scary nonetheless. It’s a Trojan for Android phones that looks for credit-card numbers, either typed or spoken, and relays them back to its controller.

Software released for Android devices has to request permissions for each system function it accesses—with apps commonly requesting access to the network, phone call functionality, internal and external storage devices, and miscellaneous hardware functions such as the backlight, LED, or microphone. These requests are grouped into categories and presented to the user at the point of installation—helping to minimise the chance of a Trojan slipping by.

Soundminer takes a novel approach to these restrictions, by only requesting access to ‘Phone calls,’ to read phone state and identity, ‘Your personal information,’ to read contact data, and ‘Hardware controls’ to record audio—none of which will ring alarm bells if the app is marketed as a voice recording tool.

Research paper here. YouTube demo. Another blog post. Research paper; section 7.2 describes some defenses, but I’m not really impressed by any of them.

Posted on January 29, 2011 at 7:45 AMView Comments

Data at Rest vs. Data in Motion

For a while now, I’ve pointed out that cryptography is singularly ill-suited to solve the major network security problems of today: denial-of-service attacks, website defacement, theft of credit card numbers, identity theft, viruses and worms, DNS attacks, network penetration, and so on.

Cryptography was invented to protect communications: data in motion. This is how cryptography was used throughout most of history, and this is how the militaries of the world developed the science. Alice was the sender, Bob the receiver, and Eve the eavesdropper. Even when cryptography was used to protect stored data—data at rest—it was viewed as a form of communication. In “Applied Cryptography,” I described encrypting stored data in this way: “a stored message is a way for someone to communicate with himself through time.” Data storage was just a subset of data communication.

In modern networks, the difference is much more profound. Communications are immediate and instantaneous. Encryption keys can be ephemeral, and systems like the STU-III telephone can be designed such that encryption keys are created at the beginning of a call and destroyed as soon as the call is completed. Data storage, on the other hand, occurs over time. Any encryption keys must exist as long as the encrypted data exists. And storing those keys becomes as important as storing the unencrypted data was. In a way, encryption doesn’t reduce the number of secrets that must be stored securely; it just makes them much smaller.

Historically, the reason key management worked for stored data was that the key could be stored in a secure location: the human brain. People would remember keys and, barring physical and emotional attacks on the people themselves, would not divulge them. In a sense, the keys were stored in a “computer” that was not attached to any network. And there they were safe.

This whole model falls apart on the Internet. Much of the data stored on the Internet is only peripherally intended for use by people; it’s primarily intended for use by other computers. And therein lies the problem. Keys can no longer be stored in people’s brains. They need to be stored on the same computer, or at least the network, that the data resides on. And that is much riskier.

Let’s take a concrete example: credit card databases associated with websites. Those databases are not encrypted because it doesn’t make any sense. The whole point of storing credit card numbers on a website is so it’s accessible—so each time I buy something, I don’t have to type it in again. The website needs to dynamically query the database and retrieve the numbers, millions of times a day. If the database were encrypted, the website would need the key. But if the key were on the same network as the data, what would be the point of encrypting it? Access to the website equals access to the database in either case. Security is achieved by good access control on the website and database, not by encrypting the data.

The same reasoning holds true elsewhere on the Internet as well. Much of the Internet’s infrastructure happens automatically, without human intervention. This means that any encryption keys need to reside in software on the network, making them vulnerable to attack. In many cases, the databases are queried so often that they are simply left in plaintext, because doing otherwise would cause significant performance degradation. Real security in these contexts comes from traditional computer security techniques, not from cryptography.

Cryptography has inherent mathematical properties that greatly favor the defender. Adding a single bit to the length of a key adds only a slight amount of work for the defender, but doubles the amount of work the attacker has to do. Doubling the key length doubles the amount of work the defender has to do (if that—I’m being approximate here), but increases the attacker’s workload exponentially. For many years, we have exploited that mathematical imbalance.

Computer security is much more balanced. There’ll be a new attack, and a new defense, and a new attack, and a new defense. It’s an arms race between attacker and defender. And it’s a very fast arms race. New vulnerabilities are discovered all the time. The balance can tip from defender to attacker overnight, and back again the night after. Computer security defenses are inherently very fragile.

Unfortunately, this is the model we’re stuck with. No matter how good the cryptography is, there is some other way to break into the system. Recall how the FBI read the PGP-encrypted email of a suspected Mafia boss several years ago. They didn’t try to break PGP; they simply installed a keyboard sniffer on the target’s computer. Notice that SSL- and TLS-encrypted web communications are increasingly irrelevant in protecting credit card numbers; criminals prefer to steal them by the hundreds of thousands from back-end databases.

On the Internet, communications security is much less important than the security of the endpoints. And increasingly, we can’t rely on cryptography to solve our security problems.

This essay originally appeared on DarkReading. I wrote it in 2006, but lost it on my computer for four years. I hate it when that happens.

EDITED TO ADD (7/14): As several readers pointed out, I overstated my case when I said that encrypting credit card databases, or any database in constant use, is useless. In fact, there is value in encrypting those databases, especially if the encryption appliance is separate from the database server. In this case, the attacker has to steal both the encryption key and the database. That’s a harder hacking problem, and this is why credit-card database encryption is mandated within the PCI security standard. Given how good encryption performance is these days, it’s a smart idea. But while encryption makes it harder to steal the data, it is only harder in a computer-security sense and not in a cryptography sense.

Posted on June 30, 2010 at 12:53 PMView Comments

Man-in-the-Middle Attack Against Chip and PIN

Nice attack against the EMV—Eurocard Mastercard Visa—the “chip and PIN” credit card payment system. The attack allows a criminal to use a stolen card without knowing the PIN.

The flaw is that when you put a card into a terminal, a negotiation takes place about how the cardholder should be authenticated: using a PIN, using a signature or not at all. This particular subprotocol is not authenticated, so you can trick the card into thinking it’s doing a chip-and-signature transaction while the terminal thinks it’s chip-and-PIN. The upshot is that you can buy stuff using a stolen card and a PIN of 0000 (or anything you want). We did so, on camera, using various journalists’ cards. The transactions went through fine and the receipts say “Verified by PIN”.

[…]

So what went wrong? In essence, there is a gaping hole in the specifications which together create the “Chip and PIN” system. These specs consist of the EMV protocol framework, the card scheme individual rules (Visa, MasterCard standards), the national payment association rules (UK Payments Association aka APACS, in the UK), and documents produced by each individual issuer describing their own customisations of the scheme. Each spec defines security criteria, tweaks options and sets rules—but none take responsibility for listing what back-end checks are needed. As a result, hundreds of issuers independently get it wrong, and gain false assurance that all bases are covered from the common specifications. The EMV specification stack is broken, and needs fixing.

Read Ross Anderson’s entire blog post for both details and context. Here’s the paper, the press release, and a FAQ. And one news article.

This is big. There are about a gazillion of these in circulation.

EDITED TO ADD (2/12): BBC video of the attack in action.

Posted on February 11, 2010 at 4:18 PMView Comments

Online Credit/Debit Card Security Failure

Ross Anderson reports:

Online transactions with credit cards or debit cards are increasingly verified using the 3D Secure system, which is branded as “Verified by VISA” and “MasterCard SecureCode”. This is now the most widely-used single sign-on scheme ever, with over 200 million cardholders registered. It’s getting hard to shop online without being forced to use it.

In a paper I’m presenting today at Financial Cryptography, Steven Murdoch and I analyse 3D Secure. From the engineering point of view, it does just about everything wrong, and it’s becoming a fat target for phishing. So why did it succeed in the marketplace?

Quite simply, it has strong incentives for adoption. Merchants who use it push liability for fraud back to banks, who in turn push it on to cardholders. Properly designed single sign-on systems, like OpenID and InfoCard, can’t offer anything like this. So this is yet another case where security economics trumps security engineering, but in a predatory way that leaves cardholders less secure. We conclude with a suggestion on what bank regulators might do to fix the problem.

Posted on February 1, 2010 at 6:26 AMView Comments

Sidebar photo of Bruce Schneier by Joe MacInnis.