Personal Identification Numbers, or PINs, are supposed to provide secure authentication for bank cards. Unfortunately, they are increasingly failing to do so. - Chad Perin from the Tech Republic Blog
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.
Chad Perrin is an IT consultant, developer, and freelance professional writer. He holds both Microsoft and CompTIA certifications and is a graduate of two IT industry trade schools. Read his full bio and profile. 
