Subverting PIN Encryption For Bank Cards

An anonymous reader sends in a story at Wired about the increasingly popular methods criminals are using to bypass PIN encryption and rack up millions of dollars in fraudulent withdrawals. Quoting: "According to the payment-card industry ... standards for credit card transaction security, [PINs] are supposed to be encrypted in transit, which should theoretically protect them if someone intercepts the data. The problem, however, is that a PIN must pass through multiple HSMs across multiple bank networks en route to the customer's bank. These HSMs are configured and managed differently, some by contractors not directly related to the bank. At every switching point, the PIN must be decrypted, then re-encrypted with the proper key for the next leg in its journey, which is itself encrypted under a master key that is generally stored in the module or in the module's application programming interface, or API. 'Essentially, the thief tricks the HSM into providing the encryption key,' says Sartin. 'This is possible due to poor configuration of the HSM or vulnerabilities created from having bloated functions on the device.'"

Comments

Re:Wow

[Anonymous Coward]

but ATMs already have their own security mechanisms that predate SSL by a long shot, and the use of SSL, at least culturally, is tied pretty closely with TCP/IP.

Pshaw. Son, you'd be surprised how many things can go wrong, even if we're talking about a program that sends out tcp/ip packets, waits for the response, and displays stuff on screen. What if you rely on the fact that you can draw a line in your window, from a positive coordinate to a negative coordinate? And what if older versions of Windows had a bug that causes the entire screen to become corrupted? Oops, should have tested that.

What if you implemented code in the installer which registers Firefox in Windows Firewall, but forgot to write fallback code for when Windows Firewall is not available? Oops, should have tested that. You could say "just develop on older versions of Windows!" What if you develop for XP-SP0, and rely on the fact that Windows's Unicode engine converts invalid data into "?". What if this later turns out to be unspecified behavior, and they got rid of that in order to optimize some things in Windows, and now the invalid data makes the entire program crash? Oops, should have tested that on newer Windows versions!

All of these are made up scenarios, but they *could* be true. The biggest software that I'm developing right now is a web application deployment platform built on top of Apache, and you'd be surprised how many corner cases there are that I have to consider. Fixing something on one version of Apache can break older versions, and fixing something on older versions can break things on newer versions. You are seriously underestimating how much effort it takes to test software and how easily things can break. Sorry for the rant but you deserved it, fag.