Slashdot Mirror
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.'"
Are they talking about my PIN number for the ATM machine? I guess I should go RTFA article now.
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.
"linux is just DOS with a UNIX like syntax" -- Galactic Dominator (944134)
It's long been known that the PCI standards are nowhere near complex or secure enough to be trusted with protecting your data. Heck, they're just getting around to mandating encryption (128 bit, so as not to punish the early adopters of encryption technology). We moved too quickly to offer services without bothering to make sure we had the security in place to protect end users, and the criminal underground moves very quickly to exploit openings.
First, doesn't using a PIN require the physical debit/credit card? I didn't there was any way to use them on their own.
I've seen a lot of my friend's and family's PINs by pure happenstance. They usually make absolutely no effort to hide it, and most of their PINs are absolutely trivial 1-2-3-4 sort of thing.
I think whoever's taking these is going about it the hard way... any Supermarket Cashier with a pad of sticky notes could theoretically have hundreds of PINs.
The problem, I would think, is "How are they getting the physical cards to use them?" Or am I missing something fundamental?
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
"I opened my eyes, and everything went dark again"
Have you ever tried to get, say, three competing companies to agree to a standard? Well, now try the same with a few hundred. Also, get international and you might get an idea what the problem could be.
Here something we dubbed the "St. Florian principle" strikes (from the old German saying "Holy St. Florian, you saint with the water bucket, spare our houses and burn down others"): As long as it only affects our competitors, why should we agree to increase the overall security?
Besides, even if they could agree that something has to be done, things like that tend to be quite expensive. And banks currently definitly have other problems than losing a few million dollars, they're loosing billions every day.
We used to have a Bill of Rights. Now, with the rights gone, all we have left is the bill.
This is partly why I don't use debit cards or authorize any institution to direct debit my bank accounts.
You want me to use auto bill pay then take my credit card number.
I get a faster dispute resolution with them then my bank.
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.
According to the payment-card industry, or PCI, standards for credit card transaction security, PIN numbers 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 (hardware security module) 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."
Sartin says HSMs need to be able to serve many types of customers in many countries where processing standards may be different from the U.S. As a result, the devices come with enabled functions that aren't needed and can be exploited by an intruder into working to defeat the device's security measures. Once a thief captures and decrypts one PIN block, it becomes trivial to decrypt others on a network.
- seems that one part of a problem is the requirement itself to decrypt/re-encrypt PINs in every HSM.
Other kinds of attacks occur against PINs after they arrive at the card-issuing bank Once encrypted PINs arrive at the HSM at the issuing bank, the HSM communicates with the bank's mainframe system to decrypt the PIN and the customer's 16-digit account number for a brief period to authorize the transaction.
During that period, the data is briefly held in the system's memory in unencrypted form.
Sartin says some attackers have created malware that scrapes the memory to capture the data.
- this is another problem in itself, there shouldn't be a need to decrypt PIN if a correct hash function is used, compare the hash instead, this way PINs don't need to be unencrypted anywhere.
--
This shows that some banking systems are outdated when it comes to security. Another problem that is identified is that there are too many ways for thieves to access and install unauthorized software on these systems.
"Memory scrapers are in as much as a third of all cases we're seeing, or utilities that scrape data from unallocated space," Sartin says. "This is a huge vulnerability."
He says the stolen data is often stored in a file right on the hacked system.
"These victims don't see it," Sartin says. "They rely almost purely on anti-virus to detect things that show up on systems that aren't supposed to be there. But they're not looking for a 30-gig file growing on a system."
- it is not clear what exactly types of systems are mentioned here? If it's the mainframe, where unencoded PINs are compared, then what anti-virus is he talking about? So it's not mainframes, then what, the HMS? Why should a virus be able to cross from a machine that can be affected by a virus to such a device?
Does anyone here know whether these so called 'HMS' machines are in actuality windows 95 boxes connected to the web or something?
Seriously though, the banks need to retrofit.
Also it seems that holding money in a bank is becoming quite troublesome.
You can't handle the truth.
If at any one point, there is an HSM that allows the keys to be brought out of the HSM, then that HSM should NOT be used.
Plus if the "hacker" has that level of access to the transaction network meaning talk to the HSM directly, you are hosed to be honest.
Strangely enough, about 2 weeks ago I got a call from my bank saying they had noticed some "odd" transactions on my debit card (which is a chip and pin deal).
Very small amounts of money, somewhere between £1.40 and £1.70 had been transferred from my account to various accounts in America, via this card. The strange thing was that this was a brand new card, I had to get my old card replaced just after christmas as an unfortunate wallet incident had cracked the old one in half.
Between January and March, I had bought nearly nothing with the card, certainly nothing out of the ordinary and until now, I was slightly perplexed as to how my card could have been compromised.
I'm glad my bank were on the ball, I've only lost somewhere around £4, which is lucky considering I had a few hundred pounds in my account at the time.
+1 IDisagreeSoHeMustBeATrollOrAnAstroturferOrAShill
It's ridiculous that we are even having this conversation. With all of the "free money" banks are getting from ATM transaction fees, securing the transaction should never be a concern.
Transaction Completed !
1,000,000 AK-47
10 High-speed skiffs
KKKOOOOWWWWAAAABBBBBUUUUNNNNGGGAAAA
Yours In Piracy,
Kilgore Trout
I agree this is scary, and I also agree that there are techical solutions to be developed and implemented the important bit that people are missing here is that these are very sophisticated attacks and require access to HSM hardware, the internal bank networks, and APIs. All these require insider knowledge and access. The banks need to find these leaks and deal with them as well as update the system as no system can completely defend against the inside job.
Assume you can hack a major supermarket chain's pin pads. On the 1st day you try everyones code with 0001. On average you will lockout a small number of customers (who lock them selves out all the time anyway). Yet you have one in 10000 odds of hitting any given card and considering that 10,000 to a few million cards have gone through in a day, thats not bad odds. If you don't use 0001, 0002 and use things more people are likely to take like 1074 (oct 74) or 4321 you will find that your hit rate is far higher.
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.
Do we know if it is safer to use the ATM at your bank branch office?
What about CC. CC often have a pin to get cash. If they can copy cards, what is to stop them from brute-forcing the pin?
Is plastic dead?
you may find the PIN in 3 tries, instead of 15 http://www.theregister.co.uk/2003/02/21/how_to_get_an_atm/
$god = null;
if($god) echo 'I believe!';
I never use the Debit Option when using my bank card in a transaction. I always choose credit for two reasons: A) When you use credit, the store pays the transaction fee, if any. I don't know if it's true anymore but last I checked, using a debit card and entering a PIN resulted in a small fee charged to the customer for the transaction. B) The purchase and fraud protections granted by Visa (even on check cards) are reduced or even disappear when you use the Debit option and enter your PIN. If you don't transmit the PIN, you don't need to worry about a MITM decrypting it.
Until the banks get their collective shit together, why not legislatively fix this.
Make it so debit cards have the exact same protections as credit cards.
To decrypt the information at each interchange. I think I a better solution would be to just re-encrypt the encrypted data at each exchange as well as the key to decrypt the previous encryption round. That way, when the data finally gets to the end of the line, the machines can just unpeal the layers of encryption.
This is an incredibly stupid problem. But it should be over when all bank cards are smart cards. With smart cards, the PIN is required to make the card work, and a secure (encrypted and MACed) session is established between the card and the Visa (or whatever) server using session keys. No PIN is in transit ever.
Just ditch the old magnetic stripe cards and get yourself smart cards.
Both my debit and credit cards are smart cards. So, no problem for me.
If you think is easy to "trick the devices into giving the master key", then you know nothing about really bad procedures and the threat they are to information security. Until about two years ago in my country every ATM of every and each of the Banks were used to have a static DES key to encrypt the PIN. This key was trivial as hell AND EVERYONE KNEW IT!. Decrypting the PIN was a matter of ... NOTHING, just walk away with your track2 info + DES encrypted PIN and start manufacturing fake cards. Here that's not a problem anymore. PLEASE BANKS, you have to change the scheme to a dynamic and ever changing and unique-for-each-ATM 3DES (at least) key. This 'technical' approach mitigates a little the procedures flaws like giving such a critical information to some unconscious technician.
But that is only a part of the problem, what about credit cards? (which usually doesn't use a PIN). In the article they mention that the Master Key is stored in several modules. In my experience that's not true (anymore, maybe 4 or more years ago it was true), the keys are used to be stored in a special tamper-proof memory which is located in the keypad of the ATMs (EPP, Encrypted Pin Pad) and in "encryption boxes" placed in the bank, secure enough if you ask me. The flaw here, again, has been a thing of really stinking procedures and lack of vision of future (nobody asks what-if anymore???).
Other thing is that the ATMs providers KNOWS THAT ALREADY (and since 2 years ago at least) and they seems to do nothing about spreading the word and proposing solutions to their customers around the world. That's an amazing business oportunity!!!.
If anyone would like to give me a job to help solve this scheme...I'm more than pleased to help!!!
Sorry for the long comment guys...
Yup. I can tell you that until about three months ago there were some ATMs live that were still running Windows 3.1. Nonetheless, you'd have thought that the banks would have had the sense to encrypt the PIN using the key of the destination bank to begin with. It isn't substantially harder and that way they don't have to be quite as paranoid as to what other banks are doing with the PINs of their customers.
From the title, I thought this was going to be a how-to.....
"HSM" sounds like a character from a conspiracy-oriented TV show, like a cross between "HRG" and "CSM".
You are in a maze of twisty little passages, all alike.
I recently saw a presentation from a Rhode Island bank. They were going to allow their business customers to install on-site check scanners, the same kind you see in the banks. One of the touted features was that these scanned deposits would be credited instantly, instead of on the next business day.
In exchange for saving them manual labor (their tellers currently have to scan the checks), they would charge you only $75/month for having the scanner! And just think of the extra interest from that day of deposit. They genuinely believed that this was a financial technology revolution, on par with the ATM.
(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.)
ny
Enjoy life! This is not a dress rehearsal.
What makes this even more egregious is that these are exactly the same transactions that we now routinely pay up to $3 for.
In other words, if you're not a customer of the bank which owns the ATM you are using, you're getting ripped off *and* exposing your PIN to man-in-the-middle attacks. And let's not forget that your $3 also buys you up to $50 of liability for any theft against your account.
Bankers are more evil than spammers.
Ok first and foremost you all have apparently not realized just what the 'Processor's' (the first tier HSM) is dealing with. In the ATM world alone there are hundreds of manufacturers, some of which made one model, then went bankrupt/stopped importing/whatever. The most common type is probably from Triton Systems, and indeed many machines use what is known as 'Triton Protocol' (over dial-up). Bank machines are simpler in some ways as initially they usually used Leased lines (usually ISDN) so they were private network end to end.
The problem with the Triton Protocol (to start with) is that it is an encryption and transmission scheme built on an ATM powered by a Z80 microprocessor. You are seriously talking about trying to run SSL on a device dumber than most High School kids' calculators.
Now that you understand that the legacy devices are still in service, maybe some of the problems become clear. If not I will spell it out for you : Most cell phones are smarter, and more powerful than 98% of all ATM's you use.
basic peer encryption itself was a huge challenge alone and only recently were all ATM's even 3DES compliant.
However, non-bank ATM's use a two tiered encryption sequence. A manually entered 'Master Key' (now 3DES, dual 32bit keys) which establishes commmunication. After the Master Key is verified, then the Processor (HSM) and the ATM exchange 'Working Keys' (this is not ever seen by human eyes, they are usually a function of the transaction sequence number, to exchange at intervals or some other calculation as determined by the HSM).
Bank based machines by Diebold, NCR, Nixdorf etc. use a slightly different scheme based on their origins. The entire encryption sequence is sent to the machine as part of it's 'load'. The load contains paramaters such as surcharge information, encryption, and graphics (or at least it can).
Also many of these HSM's also provide processing for Credit Card and POS devices that are so common these days that you are damn near tripping over them.
ATM's however do NOT all cost $30k. the more common ones (at convenience stores and groceries) are usually sub $4k machines now. This is part of the problem. It is a distinctly NON-HOMOGENEOUS group of equipment.
Notwithstanding other issues, Authoritative Douche's advice is good, is it not?
Somebody care to expand HSM?
The Federal reserve banks should be pushing for a standardized way to handle the communication between all the competing banks, much like how they handle checks with Check21.
In the article the example is based on the information gathered when "TJ Maxx and other U.S. retail networks" were hacked and yet all of the comments are about bad BANK security. There is a huge difference between a windows based POS terminal that collects data that it is not supposed to store and an ATM on a banking network.
I got rid of my debit card and replaced it with an ATM card (for getting cash directly from my bank) and credit cards (for everything else) for reasons related to this, but more generally referred to as rational paranoia.
it goes something like this:
1. I don't like entering my bank account's PIN in the local Try-N-Save. it just feels like a bad idea. now, according to the very brief amount I've read on this here, it is;
2. debit cards are linked directly to your bank account. someone uses it even as a Visa card (no PIN necessary!), not even as a debit card, and that money comes straight from your bank account, not from a credit card buffer (which you can contest, and for which you aren't necessarily liable). and I don't know about you, but I'd rather contest a charge on my credit card than get a call from my bank telling me that my mortgage payment failed due to insufficient funds;
3. I prefer using credit cards instead of debit cards anyway as it helps improve my credit rating, and I get perks like discount airline tickets (AMEX's Blue Sky card is pretty sweet). all you gotta do is remember to pay your bill every month and you're good to go.
Due to the financial crisis, I have no cash left to steal.
Many /. posters have described various aspects of this issue. The paper by Graham Steel:
http://blog.wired.com/27bstroke6/files/Steel-tcs06.pdf/
provides a more thorough explanation of how the scheme works. This is a relatively new attack, so I expect we will see efforts to harden this network, but there are obstacles, as Steel describes.
It's not that banks are just careless. For example, there is a business analytics software company with over $2 billion in annual revenue. One of their largest customers is a (big) bank, who retains them to run massive, nonstop analytical scans looking for suspicious transactions. It's a very costly effort.
There is security on many layers, some will inevitably be compromised, and the bad guys are relentless.
I did work with ATM machines long ago, and they were heavily dependent on the Data Encryption Scheme. As I remember the important transactional packets were encrypted at least three times (not triple des) and packets traveled over SNA networks using SDLC which is a synchronous method (a long stream of bits without obvious boundaries and zero insertion to protect flags. I thought at the time that this was very secure and never heard otherwise until much later when massive horsepower became available to anyone. DES was still in use as recently as a decade ago, although triple-des was an improvement. SInce then NIST has made significant progress on better encryption methods. What is true is that in the old days, those packets traveled over point to point leased lines, and not a packet switched network, and that was by definition more secure.
At this point the receiver has the decrypted data, and an MitM can't ever actually see the unencrypted data... it only exists unencrypted at the end points. The only way to bypass it would be for the MitM to pose as the bank to a terminal, and as a terminal to the bank. This is significantly harder, but probably still doable, so, we build on the above protocol (which is hereafter referred to as 2-pass encryption for brevity). The following protocol is completely MitM foolproof unless the MitM has also managed to obtain a copy of the victim's card.
The terminal sends info on whose card it has read and a code for the terminal using it to the bank via 2-pass encryption. It does not send any pin info.
The bank responds to the message via 2-pass encryption with a key that the bank picked which is uniquely generated for that transaction but which can be verified by the bank to belong both to that particular user and coming from that particular terminal This key includes a unique value that is encoded onto the card that the terminal reads but does ever not send (the bank knows it because it issued the card. The unique value is generated on the card when the bank issues the card for use to the client).
The terminal compares the value it got from the bank with the value on the card. If they do not match, the transaction is refused. Otherwise, the terminal collects the PIN and packages it with the key it received from the bank and sends it to the bank via 2-pass encryption.
The bank verifies the pin and the key, and authorizes or denies the transaction. The result is sent back to the terminal via 2-pass encryption.
If at any point the above sequence is interrupted or one side takes too long to respond, the transaction is aborted.
In a use-case where the MitM manages to pose as the bank to the terminal, unless the MitM has previously obtained a copy of the person's card, they cannot possibly know what value they need to package into their response, to the terminal, so the terminal will know to refuse the transaction. The only way this could be remotely dangerous for the end user is if the MitM had actually compromised a *VERY* large number of cards and was simply waiting for one that was in its database to show up. If they only had a smaller set of cards to examine, they may never actually see those cards at a particular terminal. A security compromise of significant magnitude is often quickly caught by a bank and corrected, often without the client ever noticing a thing.
Is plastic dead?
Netcraft can't confirm, they're not up to plastic yet ....
--- I am known for the ones who want to find me on the net. Is that a privacy risk or a privilege? One might wonder..
ID theft doesn't bother with your bank account - they find ways to get credit and use that. By the time you find out, the money has gone (typically in the way of easily converted goods) and you'll be facing the long and arduous journey of explaining it wasn't you. And in this case, the companies will hold you responsible (read: guilty) until you prove your innocence.
This, BTW, is also the biggest con job played on CC-using public with the introduction of PIN: with a signature, the liability was with the bank proving it was indeed you who paid. With PIN, you have to prove it was NOT you - much harder.