Triple-DES Upgrade Adding Insecurities?

It’s a provocative headline: “Triple DES Upgrades May Introduce New ATM Vulnerabilities.” Basically, at the same time they’re upgrading their encryption to triple-DES, they’re also moving the communications links from dedicated lines to the Internet. And while the protocol encrypts PINs, it doesn’t encrypt any of the other information, such as card numbers and expiration dates.

So it’s the move from dedicated lines to the Internet that’s adding the insecurities.

Tags: ATMs, banking, DES, encryption, network security, vulnerabilities

Posted on April 17, 2006 at 6:48 AM • 29 Comments

Comments

kamagurka • April 17, 2006 7:36 AM

head -> desk

Student • April 17, 2006 7:42 AM

Two observations:

1: They have been running unencrypted data on dedicated lines. This seems like a rather bad security policy to me. It might thwart the causal attacker, but an insider (say at the telephone company) could easily tap those lines. And I think insiders are a larger threat. So it’s good that this gets uncovered.

2: Well, we all know that strong encryption makes all applications secure. Otherwise it wouldn’t be such a silver bullet… 😉

pinano • April 17, 2006 7:42 AM

Bad media! Bad!

Redspin seems to be handling it fairly responsibly, though, and not blowing it too far out of proportion. Basically, they’re saying “Yes, there is a problem, and you should pay us to help you fix it,” instead of saying “This is Y2K! For real this time!!!!1111111111! Everybody panic!”

D • April 17, 2006 7:49 AM

If you’re a financial institution in the US (read: corporation with $$$$$), why can’t you upgrade A) to a newer, better algorithm B) and encrypt everything C) while transitioning to the Internet?

Oh, yeah, because the insecurity of this data is an externality.

From a financial standpoint, if you’re a small bank, you’re outsourcing your ATM support to a larger company – so the “I can’t afford it” excuse isn’t acceptable to me.

Paul Johnson • April 17, 2006 7:57 AM

Two things strike me about this:

1: The data is not going to go across “The Internet”: its still going to be on private lines. The only change is that it will be on the general bank TCP/IP network instead of a dedicated ATM-only network. This does increase the vulnerability, but not as much as sending it on the general Internet.

2: I hope that the encrypted PINs have some kind of nonce added. Otherwise there are going to be only 10,000 unique possible cyphertexts, which can easily be cracked with a dictionary attack.

Paul.

billb • April 17, 2006 8:16 AM

Paul:

Wells-Fargo lets me have an 8-digit PIN. It’s still brute-forceable with a nonce, but it’s better than 4-digits by a few CPU seconds. 😉

billb • April 17, 2006 8:17 AM

@Me:

That, of course, should say “…without a nonce, …”.

Phil • April 17, 2006 8:59 AM

I’d check the Wells-Fargo implementation. A long long time ago I did my undergraduate thesis on ATM networks and their security. I distinctly remember the fact that while I had an 8-digit PIN, I only needed to enter the first 4 to ever gain access to the account at an ATM machine. Perhaps they can support 8-digits “in network”, but outside of that I’d assume that it would be least common denominator (either that or you can’t access your account). I have an account at a bank whose ATM’s only allow 4 digits to be entered.

Brian • April 17, 2006 9:05 AM

Paul:

The distinction between “The Internet” and the bank’s general TCP/IP network isn’t worth what it used to be. I don’t have much faith in very many places’ internal networks these days. Every time some Microsoft virus or worm breaks out, way too many places you’d think would be better protected fall to it. ATMs should be on a private net, air-gapped from general-purpose user nets, IMHO.

I hope they’re at least going to be on their own tightly screened VLANs. Are banks generally set up with the switch gear to enable that?

André • April 17, 2006 9:44 AM

@Paul & Phil

My bank (TD, Canada) let’s me have a 6 digit Pin. But they strongly suggested that I only use a 4 digit Pin, for “compatibility reasons”. I took that to mean that they suport the 6 digits on their network, and only 4 elsewhere.

Haven’t tried though.

Jungsonn • April 17, 2006 9:50 AM

“To be compromised is to let everyone knows which security methods you use.”

So their claim seems to be correct.

If they just use other encrytion methods and let no one know which they use, their wouldn’t be this fuss.

Joseph • April 17, 2006 9:51 AM

“If you’re a financial institution in the US (read: corporation with $$$$$), why can’t you upgrade A) to a newer, better algorithm B) and encrypt everything C) while transitioning to the Internet?”

Hardware, Hardware, Hardware. Rewriting the software is easy. Getting it into 200,000 ATM machines, from a hundred different manufacturers, is very difficult. I work for a large corporation with hardware installations, and trust me, it’s much more difficult than it seems to be at first glance.

paul • April 17, 2006 10:00 AM

I guess the “reasonable person” standard is pretty much dead. Maybe this is slightly less stupid that sending the entire packet out in cleartext. But I wonder what this should have to do with the ATM boxes at all? Since you’re replacing the network connection with a new one, and presumably replacing the box that does the connecting, why not just (!) use a network-connection box that transparently encrypts the whole session, and let the ATM contintue thinking whatever outdated thoughts it prefers? (Yes, there are some obvious physical security risks, but these are banks we’re talking about.)

Pat Cahalan • April 17, 2006 10:19 AM

@ Brian

The distinction between “The Internet” and the bank’s general TCP/IP network
isn’t worth what it used to be.

It never was what it used to be 🙂

Does anyone remember when Slammer took most/all of the Bank of America ATMs offline in southern California, when Slammer hit the wild?

Rob • April 17, 2006 10:48 AM

Something not right about this report … who are “they” … all banks, a bank, a few banks. I wouldn’t think all ATM networks are the same…

Sargon • April 17, 2006 11:36 AM

This is not really new. A lot of stuff in the banking world is moving to TCP/IP, from POS terminals to ATMs. Most of it has to do with reducing costs by using COTs equipment. Also ATMs have been moving to Windows systems for some time now, and as support for OS/2 has ended this has just been increasing. As far as I know ATMs don’t make banks much money, so a lot of companies are trying to pack in features, which will add complexity and potential vulnerabilities. If you look at many banking standards many times only the PIN is required to be encrypted, so you are just seeing the effect of that. Good manufactures will facilitate a layer of encryption on top of that (e.g. SSL), but its still up to the individual banks to enable it. Clearly they are not really being informed.

Andrew • April 17, 2006 11:49 AM

The data is not going to go across “The Internet”: its still going to be on private lines. The only change is that it will be on the general bank TCP/IP network instead of a dedicated ATM-only network. This does increase the vulnerability, but not as much as sending it on the general Internet.

This is the same network that branch managers, salespeople, etc. will plug their personal laptops into in the morning, after their kids run file-sharing software on it the previous evening.

Instead of having only a few, hardened connections — this network has links all through the bank interiors, in some cases accessible from non-bank leased space. Until they armor the doors of the telco rooms as well as they armor the ATM itself, this cannot help but be less secure.

Compatibility is not always a good thing.

Joseph • April 17, 2006 11:55 AM

“Since you’re replacing the network connection with a new one, and presumably replacing the box that does the connecting, why not just (!) use a network-connection box that transparently encrypts the whole session, and let the ATM contintue thinking whatever outdated thoughts it prefers?”

This would be the best approach, but it still requires having a high-paid, bonded bank tech upgrade all the machines…

I’m stepping out of my usual role as an engineer and into the position of management. Doing upgrades are expensive-

Mark • April 17, 2006 2:39 PM

I did some work on what I thought was a non-privileged network at a large Chinese bank with a solid U.S. presence, and when one of our boxes at a bank branch started spewing data as fast as it could, guess what happened? The saturated upstream wedged the teller terminals. Ahh, the air gap that wasn’t. I shudder to think what I’d have seen had I shifted a port into promiscuous mode and run tcpdump.

Jeremy h • April 17, 2006 3:04 PM

This is from a failure to consider the end-to-end principle [http://en.wikipedia.org/wiki/End-to-end_principle].

Previously, the ATM network was considered to be mostly secure. Now that it runs over IP (a dumb forwarding network) it isn’t. The ATM endpoints should have originally handled the security concerns themselves, rather than relied on the network.

It’s sad that this is a solved problem. The ATMs should be using VPN, TLS, or at least, SSL.

Davi Ottenheimer • April 17, 2006 3:05 PM

“Most of it has to do with reducing costs by using COTs equipment. Also ATMs have been moving to Windows systems for some time now”

Heh, they always say that. Unfortunately the new systems usually end up costing more than maintaining the old, which is then used to justify spending money to reduce costs…and the cycle repeats. The real reason for moving to newer systems has to do with the target marketing and other sales strategies embedded in the new ATM interfaces: “Want to buy more security for your data? Press here”

trsm.mckay • April 17, 2006 5:54 PM

In one way I’m amused, why is a company that does financial reviews just learning about this? This is the way “it’s been done” for a long time, and nobody who knows what they are doing (in the way of judging financial security) should be surprised. On the other hand this also shows how slowly the financial systems react to changes, and how the hardware (ATM and POS-Terminals) really needs to be updated.

At the time of the current protocol designs (early 80’s), the information on the magnetic card stripe was considered “public??? (at least from a cryptography standpoint) – the compromise would be potentially embarrassing for traffic analysis reasons but it would not endanger the system. That is why the ATM did not encrypt traffic, and indeed even the use of MAC was considered optional (Canada often uses it, but rarely used in the US). Historically, the ATM was not encrypted because (1) slows down the transactions, (2) makes it harder to support, and (3) the US government strongly discouraged any type of data encryption (until the early 90’s when it finally dawned on enough people that a weak financial system was not in their best interests).

Since than a number of assumptions have changed. Indeed some of these changes are very practical, based on a review of how systems failed, and intended to minimize the impact of future compromises. An early issue was discovered when people committed fraud using a combination of insider crypto knowledge and recorded transactions, which led to the current prohibitions against storing transaction data (sounds familiar – a recent story occurred when a POS vendor forget this).

Credit card fraud has also grown exponentially, but the ATM system largely ignored this set of problems. This is despite direct tie-ins to credit card issues– for example the introduction of the “debit??? card which can be used either for ATMs or credit-card transactions (suddenly the account number is much more useful to obtain). The more recent emphasis on privacy has also raised the bar on how “sensitive??? information is stored and transmitted. Because of privacy concerns the rest of the magnetic track information has shifted from “public??? (the 80’s view) to “sensitive??? (the privacy view).

It is ironic that best practices for protecting sensitive data has now caught up and passed the PIN based transactions (ironic because this was the first commercial use of cryptography for protecting data – e.g. the PIN). Still I’m not surprised, as my struggle to get the banks to upgrade to 3DES clearly shows me why this is happening (ANSI started recommending this in the mid-90’s, and it was not until Visa/MasterCard started threatening to raise transaction fees that most the ATM’s converted to 3DES in the last couple of years!). @Joseph clearly points out one of the reasons: hardware! Throw in a bunch of other reasons too; mission-critical fault-tolerant systems running on legacy hardware, fleet management issues, transaction gateways, stand-in processors, etc. etc. Making changes to this type of system is not trivial!

trsm.mckay • April 17, 2006 6:09 PM

@Rob: I’m aware of a few banks using SSL to communicate with their ATM’s (the ATM itself is becoming fairly sophisticated – basically a PC running a Windows), but not very many. Even the ones using SSL are not doing it as well as I might wish (ideally the host side of the SSL should terminate within a TRSM that does additional policy enforcement).

@Paul: Nonces are not a magic cure-all. The PIN system designers use a variety of techniques to prevent exhaustive attacks on the short password. Some of this comes from protocol design (for example the PIN is XOR’ed with a customer unique account block to prevent cross account correlation), the PIN crypto processing occurs only within TRSM hardware, the TRSM is logically designed to resist a variety of oracle attacks, and the use of operational countermeasures (velocity checking, etc.).

That is not to say that the system does not have problems, but just blindly throwing a nonce into the protocol is not going to help things. The real problems are usually systemic (slow transition to 3DES, not encrypting the whole transaction, crypto limitations of hardware clients, etc.) or of poor execution (allowing a single person to know a key, loading the same key into multiple devices, etc.).

There have been a few interesting cryptographic attacks too — like Michael Bond/Ross Anderson’s attack on the IBM 3624 PIN-Verification-algorithm, which used manipulation of the decimalization table to create an oracle attack against a banking TRSM. As a former financial TRSM designer, I can tell you the primary design goal (logical security) is to not give anybody access to exhaustive PIN attack.

Nocturn • April 18, 2006 2:33 AM

@Jungsonn

“If they just use other encrytion methods and let no one know which they use, their wouldn’t be this fuss.”

This would mean that you make the algorithm part of the key and that has the consequence that you have to guard it like you do the key.

And that is not possible because a lot of people like subcontractors are going to know what you use, it’s going to be discussed on blackhat irc channels.

In short, if knowing the algorithm without the key leads to your data being compromised, your model is wrong.

gotpasswords • April 18, 2006 6:43 PM

I hope they’re at least going to be on their own tightly screened VLANs. Are banks generally set up with the switch gear to enable that?

I can’t speak for other banks, but we have our workgroup printers on VLANs, separate from regular desktop PCs, so I’d like to think we have critical things like ATMs on other VLANs.

Just because our new ATMs are “web-based” doesn’t mean you can use them to surf the web.

nprfreak • April 18, 2006 6:45 PM

I don’t really see anything new in this article/white paper/marketing tool. Whether in flight or at rest, accessibility of the cleartext data that comprises part of the PIN block is an old risk. The big change with the move to the internet is inside access may no longer be required to obtain that data.

At this point, fraud may still be cheaper than prevention. Unless and until full message encryption is mandated by the MC/Visa/Star/Pulse big boys, that will remain customer driven and mainly restricted to government processing. The incident in February may have been a wake up call but it was pretty successfully buried and so the industry has slept through the ring.

BillH • April 19, 2006 7:25 AM

Just a thought – another reason for not seeing some of the changes suggested above – neither the banks nor customers are losing enough money to the ATM vulnerabilities being posited to justify the expense. trsm.mckay makes the statement that ‘credit card fraud has grown exponentially’ … grown yes … exponentially no … $2.3B in 2003 to $2.7B in 2005 … however online fraud has decreased as a % of transaction value from 2.5% to 2.2%.

Jon • April 19, 2006 3:16 PM

As far as I understand no one really knows how much they are lossing due to fraud. At least this is what I have heard coming from the payment industry.

trsm.mckay • April 19, 2006 4:23 PM

“Exponentially” is probably not an accurate term for the annual rate of credit card fraud – but that was not my claim. I was trying to compare the level of credit card fraud in early 80’s (when most of the ATM/POS protocols were designed) as opposed to where it is now. I don’t have the exact numbers, but the years of cumulative growth will add up to big increase in the monetary losses at least.

If nothing else, I’m sure that we can agree that the potential loss from a single perpetrator of credit card fraud is exponentially higher. In the early 80’s we just did not have the same level of potential exposure. This is somewhat due to internet transactions and external hacking; but probably due more to increased use of credit cards, more knowledgeable attackers and tools, increased interconnections between IT systems, and so on.

The take home point is that threat model (including vulnerabilities and payoffs) for attacking magnetic stripe information (and other data communicated during an ATM transaction) has gradually changed over the years, and the cumulative results of these changes has been quite dramatic. Since the ATM/POS transaction acquirers and issuers have not changed quickly enough, the result is security practices that are mostly out-of-whack with the current security risks.

Schneier on Security

Triple-DES Upgrade Adding Insecurities?

Comments

Leave a comment Cancel reply