Most of you have probably heard about ATMs with skimmers mounted over the card slot that can read your card on the way in and out of the machine, with carefully placed cameras to read your PIN as you type it in. The person setting up this little trap can then clone the card with the skimmed data, and with the pin gets access to your bank accounts. The first time I remember hearing about that method for cracking PIN security on bank cards was in the early ’90s, so it’s not exactly a new technique.
More recent developments in bank card security cracking include malicious phishing Websites, cross-site scripting, and legitimate Websites that have been directly compromised by security crackers. It’s an especially disturbing phenomenon because bank cards don’t usually have the same zero liability protections as credit cards — a fact most users of debit cards don’t think about when they use their bank cards the same way they’d use credit cards.
A new, and even more disturbing, security vulnerability for bank cards has arisen.
A research fellow at the French National Institute for Research in Computer Science and Control (say that five times fast) named Graham Steel wrote a paper in 2006 that addressed vulnerabilities in the hardware security modules that tie the bank card authentication network together. The paper, submitted to British HSM manufacturer nCipher, provided guidelines for hardware security module configuration that would help mitigate the vulnerability of the devices to attack, but it also pointed out that other aspects of HSM vulnerability were inherent to their design. To really and truly fix the problem of HSM vulnerability, the devices would have to be fundamentally redesigned in a manner that is not backward compatible. Payment processing networks across the globe would have to be reimplemented using a different, improved standard.
HSM manufacturers such as Thales-eSecurity maintain that they address the security vulnerabilities addressed by Steel’s paper, but thus far they seem to be taking an approach remarkably similar to the way Microsoft OSes are “secured” against viruses. Other reassurances that HSM manufacturers are seeing to our security involve statements about how the devices are delivered in a very secure configuration by default, which is all well and good if you don’t need them to actually do much. Unfortunately, most payment processing transactions require functionality to be enabled that exposes the devices to significant potential for compromise. As Brian Phelps of Thales-eSecurity put it, according to the Wired article PIN Crackers Nab Holy Grail of Bank Card Security:
It’s a very difficult challenge to protect against the lazy administrator. Out of the box, the HSMs come configured in a very secure fashion if customers just deploy them as is. But for many operational reasons, customers choose to alter those default security configurations — supporting legacy applications may be one example — which creates vulnerabilities.
He went on to confirm Steel’s estimation of the scope of the problem, saying that redesigning the payment processing system to comprehensively address the current vulnerabilities due to legacy systems compatibility needs “would require a mammoth overhaul of virtually every point-of-sale system in the world.” If this doesn’t send a chill down your spine, either you aren’t paying attention, or you don’t actually use a bank card.
It is only recently that verifiable incidents of PINs being skimmed from HSMs, either gathered unencrypted from the device’s volatile memory or picked up as encrypted PIN blocks and decrypted. In some cases, at least, the decryption is made possible by the fact that the HSMs themselves contain decryption keys, and once one encrypted PIN block is decrypted it becomes much easier to decrypt the rest of them.
At first glance, one might think that the idea of storing decryption keys on devices scattered around the country that relay PINs from point to point using a model conceptually similar to Internet routing itself should have been immediately recognizable as a bad one, thanks to the example of the inherently flawed concept of digital DRM. Of course, the design of payment processing hardware security modules predates the AACS key for HD-DVDs, the Sony DRM rootkit, and Microsoft’s WGA. HSM designers get a free pass on learning from the mistakes of others, although the fact the mistake was made in the first place should have been avoidable.
For the most part, the problem is the way HSMs pass PINs around, tend to have scads of unnecessary features enabled at any given time, and contain the keys needed to decrypt the encrypted PINs. A couple of key points include:
- End-To-End Encryption: The PINs should be encrypted and decrypted only at the end-points. Encrypting and decrypting anywhere between those points just increases the options for unauthorized interception.
- Private Key Encryption: Using standardized encryption keys is tantamount to criminal negligence in this age of private key cryptography. Each and every end-point, including the bank cards themselves and the receiving systems that need to authenticate a request, should have a private and public key set. This way, you’d only be able to read data if you’re one of the unique end-points that is supposed to have access to it.
As things currently stand, however, the likelihood of the system being overhauled is pretty slim due to the immense cost that would be involved in replacing an entire global payment processing network with an incompatible standard. As a result, this problem is likely to be addressed only in a superficial, “it works right now and that’ll have to be good enough” manner. In many cases, it may not even be secured that well. Be extremely careful where you use your bank cards in the future. While liability protection for credit cards tends to be better than for debit cards, even there you should be wary of the potential threat.
I, for one, prefer to use cash anyway. Credit card and ATM transactions often impose fees on the user, and even when they don’t, it’s usually because one financial institution or another involved in a given transaction just “eats” the cost. Such behind the scenes payments contribute to price inflation, depressing the value of my money, which I tend to consider a bad thing.
With the revelation of incidents in the wild where the vulnerabilities discovered by Graham Steel (and others) are exploited to harvest PINs directly from payment processing networks around the world, I have one more reason to prefer cash transactions.
The PCI Security Standards Council has stated that it will begin a hardware security module testing program that focuses on “security properties that are critical to the payment system.” I hope the problem turns out to be more easily solved than the evidence thus far seems to suggest, but I’m not holding my breath. The problem appears to be endemic to the system itself, as it is currently designed and implemented.