Subverting PIN Encryption For Bank Cards 182
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.'"
Wow (Score:5, Informative)
Seriously? This is just incredibly stupid.
What ever happened to accessing the routing information but leaving the data encrypted? SSL really is not that complicated of a concept.
Solvable (Score:5, Informative)
Seems that we have encryption/signing protocols that don't require decryption for all operations... seems we also have public key encryption....
We already have onion routing... where we have end to end and point to point encryption in layers....
Seems the bankers should take a look at other technologies and consider some updates in how they handle it.
-Steve
Re:Why I Hate Debit Cards (Score:2, Informative)
More importantly I can tell the CC company to bugger off where as the bank is not going to put cash back into my account.
My account was compromised a few months back, by fraudulent use of a bank/debit/check card of mine. Interestingly enough, the bank (once made aware (less than 8 hours later) that a string of fraudulent purchases had been made) did provide a credit back to my account for each one that cleared, and then personally took up issue with the individual corporations' fraud departments (Yahoo Personals, Samsclub.com, etc etc). Process-wise, I did have to sign an affadavit for each individual instance and throw them back in the mail.
Re:So this is what my $2.00 buys me? (Score:5, Informative)
That's not free money. ATM's cost in upwards of $30k (for a Diebold Opteva) - then there is circuit cost, depreciation, loading money in the machines (that doesn't earn interest in the financial institution's overnight account), supplies, maintenance, etc. Unless you're in a high traffic or tourist area, making a couple $100 in PROFIT after all expenses on an ATM is good.
Mostly they lose money. It's a cost-center.
Speaking (as AC) as someone who has 12+ years experience in financial institution back-office operations and data processing.
Re:Wow (Score:5, Informative)
Are you really surprised? If someone wants to drain your bank account, they don't even need to break any encryption, all the information they needed is written on your checks. They don't even need to forge a signature [msn.com].
If banks were liable for fraud committed with the systems they designed, they'd design more fraud tolerant systems.
Re:Wow (Score:3, Informative)
Encryption is a two-edged sword. Encrypted data (including pin numbers) are useless until they are decrypted.
Not true. Unix passwords are never decrypted.
Re:outdated banking systems (Score:2, Informative)
As someone who works in the FI-tech industry, I can say that HSM's are effectively sealed, low power, dedicated chipsets. Physically, they resemble a small metal box with spots for inputs. They're supposed to be physically difficult to open and muck around with.
They add about 10-12k USD to the price of an ATM, despite that being nowhere near the unit production cost.
From someone involved on the technical level, it appears that this is the real scam job, but I'm not the one agreeing to follow certain inter-bank standards, so perhaps I'm a bit out of the loop here.
Not in my experience (Score:5, Informative)
I work for a Electronic Payments/ATM/Point of Sale/Card Issuer company. If the PIN is in the clear after being decrypted at the bank/card issuer then that is the bank/card issuers issue and not the payment industries fault. The bank/card issuer needs to look at their software vendor who is not secure, as the PIn should never be in the clear. If the HSM device is giving up the key, then that HSM vendor is not secure. How is the hacker getting access to even itneract with the HSM device. These are usually held in a secure environment network and physical access. If the HSM device is not in a secure area then some one has to be responsible for over looking this. These HSM devices are set to self destruct if tampered with. The article calls for a radical change to the payment industry, but all these issues can be resolved with regulation and I belive these rules are already in place. The PCI auditors should be catching these items.
Re:So this is what my $2.00 buys me? (Score:3, Informative)
Re:Wow (Score:3, Informative)
To expand on the sibling poster, this isn't true, because there are a number of accepted ways of cryptographically proving that two parties both know the same information, without ever actually revealing what the information is.
The example the sibling gives of Unix password hashing works as follows ;
* The user sets their password. A 1-way hash is stored in the password file.
* Later, the user attempts login. The password he enters is put through the same 1-way hash and compared to the contents of the password file. If it matches, he logs in.
At no point is the password stored unencrypted, or decrypted from stored information. The most successful way of attacking this particular technique is called the Rainbow table [wikipedia.org], a precomputed list of all the possible hashes for a given range of values.
For data that was just 4-digit PIN numbers you'd not even need a table, once you'd deduced the hashing used, but there are various tricks to improve this (see article).
Re:Wow (Score:4, Informative)
It doesn't have to do with routing, it's because each point to point connection uses a symmetric encryption key, shared in advance. That's what this boils down to, using symmetric key encryption, and needing to make several hops to the destination, instead of using PKI where you could easily share all keys with everyone and encrypt once. How else would you move encrypted data through a network with symmetric keys? You can't have every single issuer and acquirer exchanging symmetric keys with each other, it would be unwieldy. HSMs protect the keys at all times, and procedures are built around key management to ensure no one person can have all key components. The system is actually pretty sophisticated, and suggesting it could just be replaced with SSL is laughable. There's a lot more to it, especially the whole issue of how to manage trust if such a system were to go PKI. PKI only works if you're absolutely SURE you have the real public key, and this is not typically a problem when you're physically exchanging symmetric key components with the switches.
Re:outdated banking systems (Score:1, Informative)
PIN management systems use DES almost exclusively. Now, if your card is issued by Bank A and you use Bank B's ATM, your PIN is encrypted twice: once by the ATM, where it then goes to a big switch; there the HSM (Host Security Module) decrypts the PIN from the ATM key owned by Bank B and re-encrypts it with the key used by Bank A.
When the encrypted PIN arrives at Bank A it's verified inside Bank A's HSM, which only returns a yes/no.
A properly designed PIN management system NEVER exposes the PIN outside the HSM, EVER.
PINs are formatted into 8-byte blocks (for DES), and the PIN is combined with other data (salts or the PAN) to prevent dictionary attacks.
HSMs have supported these methods for years. The only reason for compromise is rogue insiders or sloppiness.
DPM
Re:Bank deposit latency (Score:3, Informative)
> (I did the math; assuming 5% APR, which nobody gets anymore,
> you'd have to be doing about $550,000 in daily deposits to
> make back the $75/month.)
You forget not having to pay for someone to securely schlep the checks to the bank, once or more a day. At minimum wage, and a 20-30 minute round trip each day, it would become a bit more economical.
But, yes, this sounds like the bank is drinking its own kool-aid, on the scanner rate, unless they are supplying a very nice scanner.