IBM Crypto Up For Grabs?

An Anonymous Coward writes: "BBC Newsnight have tonight shown an article about a groups of hackers who are about to release details of the vulnerability of the IBM Cryptographical processors. ( Details here.) The BBC article can be watched online here. Alan Cox makes a starring role ;)" windowlicker adds some detail: "Mike Bond and Richard Clayton, from Cambridge University, have cracked IBM's 4758 crytoprocessor running the 'Common Cryptographic Architecture' (CCA). You can do the same with $1000-worth of hardware and the info from here. Many banks use this system for protecting PINs." The video file requires Real software; here's the BBC's article online for those of us without.

Comments

Hacker divas suck.

[perdida]

If you're gonna release some shit for purely knowledge reasons, then why are you advertising your intention to release it before releasing it?

Knowledge is knowledge. If you want to propagate effective computer security, don't badger and pressure corporations to cow to your wishes with publicity stunts like this one.

Instead, just release the hole, and let the damage be done. The damage itself will be far more instructive to the company. It will also be a better influence on computer security as a whole -- damaging releases will, perhaps, induce large corporations to practice better preventative security.

Re:Hacker divas suck.

[demaria]

And screw all the people who are using the systems or products in question.

I'm all for full disclosure, but blind siding is not ethical.

Re:Hacker divas suck.

[SquierStrat]

See, this is the problem...no upgrade. IBM was notified about the problem a year ago, with no fix. In reality a firmware update should do it (I believe the card is capable of it...) but they've done nothing. They didn't say the banks didn't know they just didnt say they did. Also you have to have physical access to the machine with the chip in it to do it. That's alot of banks to notify also!

Re:Hacker divas suck.

[xmedar]

If you saw the program you'd know that it was cracked by someone at a lab Microsoft set up with Cambridge University, this is the same Microsoft that calls on security experts to "end information anarchy" and stop releasing sample code that exploits security holes in Windows and other operating systems. AKA MS Hypocracy 3.51

Re:Hacker divas suck.

[TeraCo]

Yes, but there are two different levels of 'open'. The argument was that they should have provided detailed information on how to exploit it. I said 'no, that ideal is criminally negligent'. There is a difference between saying publically 'there is a problem with your system X' and saying 'there is a problem with your system X, and we have just put the details of how to exploit it on the internet'.

Re:Hacker divas suck.

[SquierStrat]

If they had not told IBM about it ahead of time, I'd agree, it's negligent. But a year is plenty of time for IBM engineers (sad fact now that I think about it...i might be an intern at IBM this time next year...sorry off topic) to fix the problem. If they choose not to fix it (and I doubt that they were not warned that the informationw ould be released) they are the ones being negligent. Now, if IBM recieved no warning, I'd agree with you, it's negligent to say hey guess what! But, then again, more than just banks use this hardware....Alan Cox state "This is really military grade hardware...." I'm sure many large corp.'s use it, and the best way to let them know instead of just trying to call downa customer list is to say hey this exists, protect yourself. Also, it's a fairly easily blocked attacked until a fix is released. Which will hopefully be quick, as I just got a new Visa! ;-)

Re:Hacker divas suck.

[sql*kitten]

Knowledge is knowledge. If you want to propagate effective computer security, don't badger and pressure corporations to cow to your wishes with publicity stunts like this one.

Actually, the knowledge of hardware DES cracking is already pretty old.

Lessons to be learned:

[alewando]

1. Hardware encryption will always be more difficult than software-based encryption to patch when vulnerabilities arise. There are advantages that can offset this when deciding whether or not to go with hardware, but contingency plans must be put in place for yanking the hardware back when a vulnerability is discovered.
   
2. Homogeneity in network environments is nearly always bad. This particular vulnerability wouldn't be nearly as critical if it weren't for the fact that all banks who use these cryptoprocessors either use the same ones or use ones that are similar enough that vulnerabilities like these can be used on more than one "different" type. It's much harder to crack one and then crack another and another than it is to crack one and have therefore cracked them all.
   

At least I have high hopes that this vulnerability will be patched forthwith -- not only does IBM have a better track record than certain other corporations, banks have both the money and the clout to demand and receive.

Re:Lessons to be learned:

[swillden]

Hardware encryption will always be more difficult than software-based encryption to patch when vulnerabilities arise.

Actually this is incorrect. The 4758 is eminently software-patchable because it's a software device inside a secure hardware module. In fact the most difficult and complex part of the 4758 design is the support for secure upgrades of critical software components in a hostile environment. It uses a combination of carefully designed boot stages coupled with hardware interlocks (they call it a "ratchet") that gradually increase the complexity and decrease the access of the software that can be loaded. Thus they start with a miniature boot PROM whose code can be thoroughly proven (in the mathematical sense) to be correct, but whose only purpose is to be able to load the next stage after validating the signature on it. After that second stage is loaded, the "ratchet" is moved and the region of memory that has been loaded is now unwritable. It's very cool stuff, you can read about it in the design whitepaper.

Homogeneity in network environments is nearly always bad. This particular vulnerability wouldn't be nearly as critical if it weren't for the fact that all banks who use these cryptoprocessors either use the same ones or use ones that are similar enough that vulnerabilities like these can be used on more than one "different" type.

I agree in principle, but in practice (1) 4758s are still fairly rare in the banking environment and (2) the reason that the 4758 was an interesting device to attack is because the CCA API is far *more* secure than the APIs provided by comparable devices from other vendors. The authors of the crack paper even mention that they've cracked other devices this way. The 4758 was interesting because it's the best of them.

Note, BTW, that I work for IBM and I know the guys who created the 4758, so I have some obvious biases. I also know my way around the boards :) The real weakness uncovered was not in the 4758, but in a thoughtless patch to the 20+ year old CCA API. The "patch" was the addition of 3DES. CCA is the only (AFAIK) formally-designed API for symmetric key management, and it's really well done. When it was created, though, 3DES was unnecessary. It's now obvious that a little more thinking needed to be done when it was "extended" to support 3DES.

This weakness is very easy to close. I don't know what fix they'll choose to implement, but there's a really obvious and simple one: Don't allow a replicate key part (3DES key with identical halves) to be combined with a non-replicate key part to create a non-replicate whole that is an export key.

What I am certain of, though, is that the entire "patched" CCA API is going to be going back to IBM's cryptographers for formal modeling, so that the integrity of the structure can tweaked until the structure can once again be proven to be mathematically correct. This won't happen again; IBM takes security very seriously and has the people that know how to do it.

While I'm on the subject, Linux freaks will be interested to know that the next-generation OS for the 4758 is... Linux! Well, a stripped-down, thoroughly validated version of Linux, anyway. Dunno if the source will be published or not, but I think so. Linux is already running on the boards, but getting the validated version will take some time.

Re:Lessons to be learned:

[Old Wolf]

Banks around here (New Zealand) use 3DES for PIN encryption (which is a bit of a joke because most PINs are only 4 digits). They also use 3DES (with the same master key) for message checksumming.

Banks make a big hullabaloo about security, more to scare people off than for real security.

Re:Lessons to be learned:

[Anonymous Coward]

Mod this parent up, he knows exactly what he's talking about

This group has some misconceptions about the FIPS 140 process. First, they rightly point out that the level 4 cert on the IBM 4758 does not cover the CCA software, and then they go on to talk about how a bug in this (admittedly, non-evaluated software) shows the weakness of FIPS 140-1.

Hmm... Well, interesting, but wrong. First, as they point out, the CCA software is not covered by the FIPS cert. Once you install the CCA software on the 4758, the 4758 is no longer a FIPS 140-1 module, level 4 or otherwise. The FIPS cert only applies to the module as it was evaluated. As this post's parent points out, the 4758 allows arbitrary code to be uploaded into the module. This means that as soon as you load unevaluated (ie: non-FIPS 140-1 evaluated) code into the module, it looses its FIPS 140-1 level 4 status.

So, what is evaluated? Examining the NIST FIPS 140 validated modules list you'll see there are several pertinent certificates that apply to the IBM 4758 card. First, there is the level 4 certification of the 4758 and the boot code (Miniboot layers 0 and 1) (certificates # 35 and 116). Next you see the FIPS 140-1 level 3 certificates involving the 4758 with its onboard OS (CP/Q++) at layer 2 (certificates #122, 122). Note that as soon as you add the OS the certification drops to at most level 3. And that's without any application code at all; no CCA, no other libraries, and no applications.

You'll also note, that the CCA is not evaluated under any of these certificates. If you think that this is an oversight on IBM's part, I have a lovely patch of land to sell you.

Now, just to put all this 4758 bashing into perspective: The IBM 4758 is an amazingly secure cryptographic module. It is by far the most well designed and implemented cryptographic module I have ever worked with, and that says a hell of a lot. Sure, there may be more secure modules out there, but not in the civilian market. The 4758 is, to put it plainly, The Shit. The reason this module is such an interesting target is that it defines the state of the art of cryptographic modules. To put it another way, virtually every other cryptographic module (software or hardware) is less secure than the IBM 4758.

When someone demonstrates a possible attack against an IBM 4758, you shouldn't just say to yourself "Oh, this doesn't matter, I don't own/use/deal with one of these". Because the IBM 4758 is the commercial state of the art, the work factor associated with breaking every other cryptographic module out there is less. So, if it only takes an a few days compromise the 4758, it is a fairly good bet that it takes less time than that to compromise any other commercial cryptographic module.

Ain't it grand?

Re:Lessons to be learned:

[sql*kitten]

It's very cool stuff, you can read about it in the design whitepaper

The correct URL for the white paper is here.

Re:Lessons to be learned:

[swillden]

Please read the GNU license... for the answer to your question. If IBM wanted to keep it secret... use a bsd derived kernel instead.

Duh. I was thinking about security implications of publishing or not publishing, without even considering the license. Yes, obviously the source will have to be given to the purchasers of the boards, who can then do what they like with it, so clearly the source will be published.

BTW, the whole "open source is secure" notion has valid arguments both for and against. In environments where the system cannot be updated in the field (smart card operating systems, for example), secret systems are clearly more secure. In environments where the system can be patched immediately, openness is clearly more secure. In spaces in between, which covers most of the real world, the security situation is, well, in between.

Re:Lessons to be learned:

[Ami Ganguli]

But there can be restrictions placed on re-publishing the source. So IBM cannot make anybody sign an NDA or other agreement to keep it secret. One of the thousands of people who receive the code from IBM will publish it openly.

Re:Lessons to be learned:

[swillden]

It has been argued that security via obsurity is not really secure at all... just secret. Yet clearly obscurity is secure.... however... its biggest weakness is the obscurity.

Security by obscurity is security, until the veil of obscurity is lifted. There is no question whatsoever that the absolute best in security is achieved by building something that would be completely secure if published, and then keeping it a complete secret. Obscurity creates an enormous extra work factor for would-be attackers.

Openness actually weakens the security of systems that cannot be modified, however, because it removes the work factor created by security, but the systems cannot benefit from the quick defect corrections provided by openness. Maybe for sufficiently simple non-modifiable systems the best approach is still openness, with substantial public analysis and discourse before any systems are fielded.

These systems undergo the best scrutiny..... the enemy

No, I disagree. The enemy does not provide the best scrutiny, for one simple reason: the enemy won't tell you if your system is broken.

I wonder if it would be possible to add Blowfish to the kit? YOu say you knwo the guys that work on this.... have they said anything about using non-DES (aka non-IBM and the goverment with their backdoors) type of ciphers??

It would be trivial to add additional ciphers like Blowfish. The purchaser of a 4758 can buy a developer's kit and do it himself, even.

However, I would not recommend Blowfish for high-security applications. It's too young. Although slow, 3DES is actually the best cipher we have right now. DES has withstood almost 30 years of intensive cryptanalysis by the best academic cryptographers in the world. Not only has it not been broken, it hasn't even showed the tiniest hint of a hairline fracture. Sure, the keys are too small these days, but 3DES fixes that up nicely, and its properties are very well understood.

If you need a more modern, faster block cipher, I would actually recommend AES or the AES candidates, not Blowfish. Twofish is Bruce Scheier's successor to Blowfish and although it is a couple years newer than Blowfish it has almost certainly had more intense scrutiny thanks to its status as an AES finalist.

Finally, every professional cryptographer I know put that old spectre of NSA backdoors in DES to bed years ago. It is almost inconcievable that the NSA 30 years ago was so far ahead of the current state of public cryptanalytic art that something as significant as a back door could still escape notice. Also, the NSA didn't *need* a back door. They forced a small key size, and they have more computers than anyone.

It is vaguely possible that 3DES is crackable now by the NSA using a meet-in-the-middle attack, which is computationally feasible but requires truly phenomenal storage requirements. If you're trying to keep secrets from governments, though, good luck, because cipher strength is the least of your worries.

Re:Lessons to be learned:

[swillden]

it removes the work factor created by security I meant "the work factor created by obscurity", of course.

Re:Lessons to be learned:

[swillden]

BTW- I wanter if smart cards have a FIPS rating?

I'm not aware of any that are formally certified under FIPS 140-1, but they would be level 3 at best. All known smart cards are vulnerable to clever but expensive hardware attacks, and always will be as long as they're externally powered. Boards like the 4758 have their own power supply and can actively monitor their environment for break-in attempts. Good smart card designers focus on making the cheap attacks impossible, and good smart card system designers focus on making sure that the value of breaking a card is less than the cost.

That's the hardware. Smart card software is also generally not certified, though there are a few exceptions. I'm aware of work that is going on to produce an EAL level 6 or level 7 certified smart card operating system, but I don't know if I'm allowed to say which company is doing it or what exactly is being done. ObMSBash: It's obviously *not* Microsoft, though ;-). Their brief foray into the world of smart card OSes produced the least secure I've ever seen.

Re:Lessons to be learned:

[swillden]

Thanks for responding... I enjoy our talks... to bad we have to use slashdot as a medium......

Welcome. You can judge from the ludicrously large number of posts I've made to threads under this article just how much I like talking about this stuff :) And my e-mail address should be on the header of all my posts.

I only read the Applied Crypto book by Bruce

Not a bad place to start, although it's a bad place to end. As Schneier says in his intro to "Secrets and Lies", "Applied Cryptography" has cause more bad cryptography to be implemented than any other book. It's a good book, but people read it and then think they're qualified to build stuff. I highly recommend the self-study course in block cipher cryptanalysis he has on his web site. Not that I've completed it, but just working through a little bit of it really gives you some insights, both into the world of crypto and into your own lack of knowledge of the same.

I sure wish this type of tech were marketed to the small fry, like myself.... if IBM were smart... they could capitalize on this press coverage to their advantage.

The boards are cheap relative to their class, but not cheap by consumer standards. Most of the competition is (or was, at least, they're being forced to lower their prices) in the $25-$50K range, per device. The 4758 is $2K-$3K, depending on whether you get the level 3 or level 4 version. Based on the complexity of manufacturing the level 4 boards, I doubt they'd be much under a grand even if volumes were huge. I can see that the level 3 boards could get down to consumer price levels (say, $200), though, if volumes were large enough. Note that I'm a software guy, so these are wild guesses.

RealVideo Coverage

[guru_steve]

I'm watching the video right now, and its taken a bit of time to find out where this segment is on the bbc news.

So, for those of you who don't feel like jumping around the video for this segment, it starts at about 22 minutes in the broadcast.

No

[sulli]

That's where the money is!

Re:The Great Game!

[John Miles]

Cool. It looks like parents are letting their kids watch Fight Club before they know how to read.

Insiders

[Embedded Geek]

I'm glad they pointed out that most thefts are perpetrated by insiders (at banks or other companies) due to the other (physical) security measures. I can only hope that other media outlets don't drop the ball on this and start shouting "hackers can steal your cash" on the 6PM news.

Then again... I guess you'd only need to be an insider at the phone company (or whatever company might be leasing a cable to a phone company) to exploit ATM transfers. You wouldn't need to be a bank employee (who undergo background checks, etc).

Re:Insiders

[maladroit]

It seems like it would be tough for even an insider to exploit this. Supposing the would-be thief has managed to (a) tap into the (leased) line (b) separate out the transaction data being sent from the ATM and (c) decrypt it, then they have a set of card numbers and pins. Now what ? I don't think you can get any money without the physical ATM card.

Maybe the debit cards or other transactions they mention are more vulnerable ...

Re:Insiders

[swillden]

Then again... I guess you'd only need to be an insider at the phone company (or whatever company might be leasing a cable to a phone company) to exploit ATM transfers.

Nope, read the article. Performing the attack requires that the insider have permission to use the Combine_Key_Parts function of the board. That means, essentially, that you have to have an "account" on the board with a username and password, and that your account has to have those permissions. Generally, only a very small number of people will have accounts, and only two or three at will have this permission.

Re:Insiders

[gorilla]

If you have the card number and the pin, then you can write your own card with that number on it, put it into any machine, and enter the pin.

ATM's are more prone to stone age methods

[number one duck]

I'm not too worried about this. An electronic fraud is something that can be reasonably gotten out of, its the *banks* fault if their system eats your money. (Admittedly, I haven't read the small print of my own bank, but hey, its not the article, anyway).

The big problem I have with my bank, however, is the location and layout of their ATM machines to begin with:

1) ATM's are built into the wall, rather than in any kind of nook. The line generally forms directly behind the user. (This isn't so much of a problem for e.g. drive through atms, as the bulk of the car is obscuring view of the transaction).

2) The buttons on the keypad are almost two inches across! I know they have to make them 'easy to use', and big happy buttons are important for that, I imagine... but having to move my entire hand around to enter the code makes it trivial to watch someone's movements...as opposed to normal sized buttons where what is being pushed is generally obscured by your hand itself.

3) This is a general problem. Cards are *inserted* rather than *swiped*, which makes it almost trivial for people to rig the machines to prevent the card from being returned. A card swipe, where the card never leaves my hand, would be infinitely preferred to leaving my bank card at the mercy of any hoodlum with a bottle of soap and a pair of pliers.

4) Apparently the ATM card I recieved is more than I asked for... it is also a credit card AND a debit card AND who knows what all else... if they acquire it they can run me down even if I don't have any money left in the account proper.

Re:ATM's are more prone to stone age methods

[3263827]

In a previous life, I worked as a teller at a bank. Not only are most tellers underpaid, they are continually dumped on by rude customers. Anyways, for giggles, some tellers would go to the cabinet/closet where our ATM was housed, and when someone put a card in, they'd pull it into the reject bin. They'd do this when the bank was closed, so the luser would have to come into the branch the following morning to get the card back. Pretty funny to watch peoples faces on the camera when they realize their card isn't going to pop back out...

Re:ATM's are more prone to stone age methods

[dragons_flight]

Blind people might want to use ATMs too. Suppose a blind person needs to get some cash, he or she can get someone else to read the screen instructions, but can punch in the PIN directly, without having to give it out to anyone else. Of course being certain the other person isn't watching your fingers might be a trick, but in theory a blind person should be able to conduct his transaction without revealing his PIN to anyone.

Re:ATM's are more prone to stone age methods

[gorilla]

Many modern ATMs are coming equiped with an audio output socket, which allows the blind person to plug in a headset and have the screen instructions read to her by the ATM directly. Here is a link to a bank which has this in some of their ATMs. NCR has said that all future ATMs they produce will be audio enabled by default. I hope that other ATM manufacturers will follow.

Question...

[srvivn21]

So they article says that this is really only exploitable by "insiders". At first I felt safe. "Well, at least my money is Federally protected". Then I got to thinking about it. How would I prove that I wasn't the one who used my PIN at an ATM (or several) to clear out my account? Anyone have an answer that can put my mind at ease?
(Not like I'm going to take all my money from the bank, and stuff it in a jar. Just idle thoughts of threat)

Re:Question...

[srvivn21]

Two problems with that.

1)Not all of the ATM's in my home city have cameras.

2)I also live in a cold climate. There would be nothing odd with someone being bundled up with a ski mask on making use of an ATM...

Re:Question...

[psavo]

2)I also live in a cold climate. There would be nothing odd with someone being bundled up with a ski mask on making use of an ATM...

I used to live in poor country, there was nothing odd with someone being bundled up with a ski mask on making use of an ATM...

Re:Question...

[sachmet]

Because most banks that I am aware of have a $300 limit on account withdrawls; also, with enough witnesses willing to provide affidavits, you can prove you were not in the location you said you were in at the time the withdrawl took place. The withdrawl limit is to prevent a person from physically accosting you from ATM to ATM trying to take all your money.

Re:Question...

[dazed-n-confused]

How would I prove that I wasn't the one who used my PIN at an ATM (or several) to clear out my account? Anyone have an answer that can put my mind at ease?

In a word, no. Here in the UK, there was an unpleasant case some years back when the banks tried to do just that -- covering up security flaws in their ATM machines and prosecuting the man who had suffered from their errors when he protested about unauthorised withdrawals from his account.

There's a selection of relevant papers on Ross Anderson's website: read up on the subject here. "Why Cryptosystems Fail" is probably the most immediately rewarding, given your concerns.

Re:Question...

[mpe]

Here in the UK, there was an unpleasant case some years back when the banks tried to do just that -- covering up security flaws in their ATM machines and prosecuting the man who had suffered from their errors when he protested about unauthorised withdrawals from his account.

It actually turns out internal fraud by bank employees is a common cause here. This need not involve any hacking. Simply something as simple as ordering additional cards attached to an account can do it. Since statements generally don't indicate which card is used or even how many cards are attached to the account.

Re:Question...

[mpe]

All atms have cameras on them to record the physical person who removed the cash. If they show a withdrawl at 1pm and their is no one standing in front of the machine at that time then I would think yuo have a case.

All the bank then has to do is say "well the cardholder must have lent their card to someone else".

Re:Question...

[armb]

> you can prove you were not in the location you said you were in at the time the withdrawal

That doesn't help if the banks response is "then you must have given your PIN to someone else - our system is perfect so the money must have been withdrawn by someone with your PIN".
_You_ know they are lying, but how do you prove it?

Back to this attack, there are details at http://www.cl.cam.ac.uk/~rnc1/descrack/ and http://www.cl.cam.ac.uk/~mkb23/research.html

Re:Question...

[gorilla]

The banks can do the opposite. All ATMs are fittable with a camera, and can be programmed to take a picture of the person making the withdrawal. When this is produced, almost certainly it's someone known to the cardholder, if not the cardholder themselves.

Re:Question...

[Cato]

This is exactly what has happened in the UK with 'phantom withdrawals' - one poor guy was on holiday with his bank card in a drawer at home (no-one else with access to house) when one withdrawal happened, and he was *still* accused of defrauding the bank.

The most important feature of any bank is the small print in their contract with you - check to see whether they assume that a fraud is nothing to do with you, and must prove that you committed it. For far too long, at least in the UK, banks assumed their customers guilty until proven innocent...

Re:Question...

[armb]

> The banks can do the opposite. All ATMs are fittable with a camera,

Only relevent if the cash was actually taken out of an ATM. If the bank are trying to cover up a fraudulent transaction by an insider, which was the context under discussion, there will be no photo. But since not all ATMs actually have cameras taking pictures of every transaction, the banks failure to produce a photo doesn't help you prove the withdrawal didn't happen.

Re:Question...

[armb]

> I can prove where all copies of my card were

Which is fine if you are in the habit of frequently asking witnesses to note that you have your ATM cards with you just in case someone is creating a fraudulent transactions supposedly using it at the time. Most people aren't.
(Or the fake transaction clashing with a real transaction somewhere else, which requires luck and the person creating the fake transaction not being able to see the real ones).

Just another case of security by obscurity?

[imrdkl]

Like ssh-agent, this chip seems to be secure keyholder. It is a little unnerving that an hardware implementation could be so easily broken, but I also suspect that, unlike ssh-agent, this was not ever an open-source implementation. :-)

The news (I liked Real links) claims that development took 20 years, and that normal banking procedures would prevent this type of attack. But Alan Cox, of course, strongly suggests that publishing the algorithm behind the chip would have helped to avoid this calamity.

Pretty focussed branch manager...

[WasterDave]

"banks are vulnerable to a dishonest branch manager whose teenager has $995 and a few hours to spend in duplicating our work."

If you have a teenager who can hack FPGA's sufficiently well to brute force into a cash machine, you're really not going to have any problems making money in years to come. Either that or your problems are just beginning.

Dave

Re:bad slashdot

[Alan Cox]

Well its their heads under the DMCA 8)

Only a matter of time

[CmdrTroll]

My brother used to work as a contractor for Cirrus. He said that the PIN encryption was a private joke amongst all of the engineers there. The suits all believed that cryptographic mumbo-jumbo and really expensive chips sold by "connected" salespeople at IBM would protect the banks' assets. But, he said, the problems with the PIN were nearly impossible to solve. Consider:

• The PIN is four decimal digits = 10,000 combinations ~= somewhere between 13 and 14 bits of security. It is entirely feasible for a quick P4 to encrypt every single PIN within an hour, with time left over to play Unreal Tournament.
• There is no trusted path between the user's memory and the bank. Fake ATMs have been installed in shopping malls, collecting PINs and ATM cards from unsuspecting victims. Do you *really trust* every single PIN keypad at every shady gas station, grocery store, and Wal-Mart, not to have logging devices installed? Replay attacks are not rocket science.
• Embedding DES keys inside a chip will inevitably lead to compromise. One needs to look no farther than the DirecTV access cards (particularly the H and F cards) to see the amount of damage that a few determined hobbyists can do. Imagine if there are billions of dollars at stake rather than just a little free TV.

Regardless, this is not a widespread problem. It is a weak system and it was always a weak system. But it's not worth thieves' time to steal PINs yet (for the most part anyway) just because PINless credit card fraud is still so easy.

-CT

Re:Only a matter of time

[WasterDave]

10,000 combinations ~= somewhere between 13 and 14 bits of security. It is entirely feasible for a quick P4 to encrypt every single PIN within an hour, with time left over to play Unreal Tournament.

But if you read their page about how PIN works it becomes aparrent that you still need the derivation key, which is the hard bit to get.

Fake ATMs have been installed in shopping malls, collecting PINs and ATM cards from unsuspecting victims

LOL! Someone did a whole bunch of these in the UK a couple of years ago. Looked and smelled like an ATM, but took the PIN then complained that the card was borked, or something. Easy EASY kill.

because PINless credit card fraud is still so easy.

Exactly. 1e6+1 easier ways of stealing money than opening an ATM with an oxy-acetylene, spending two days cracking it with an FPGA and using all that to hack the banks comms. Easier to just look over some lamers shoulder then pick their pocket. Not that I would know. Not at all.

Dave

Re:Only a matter of time

[Black Acid]

The PIN is four decimal digits = 10,000 combinations ~= somewhere between 13 and 14 bits of security.

For those interested, you can find how many bits a key with x values is using logarithms:

bits = log(x) / log(2), or

bits = d / log(2)

Where d is the number of decimal digits the key is. Therefore, a 4-digit PIN has 4/log(2) or precisely 13.287712379549449391481277717958 bits of cryptographic strength. Not much compared even to weak encryption such as 64-bit DES, or the 56-bit des-ii cracked by d.net.

Re:Only a matter of time

[Glytch]

Do you *really trust* every single PIN keypad at every shady gas station, grocery store, and Wal-Mart, not to have logging devices installed?

I work at a Walmart. Don't give me ideas. :)

Re:Only a matter of time

[mpe]

Exactly. 1e6+1 easier ways of stealing money than opening an ATM with an oxy-acetylene, spending two days cracking it with an FPGA and using all that to hack the banks comms.

If you are going to crack one open far easier to simply pinch a machine just after it has been filled...

Re:Only a matter of time

[gorilla]

You're assuming that all 10,000 combinations are valid. Most systems exclude 'first guess' combinations such as 0000,1234, etc. This reduces the number to 9000 and some.

Is your parent a bank manger?

[Quizme2000]

Until IBM fix the CCA software to prevent our attack, banks are vulnerable to a dishonest branch manager whose teenager has $995 and a few hours to spend in duplicating our work.

I like the tech about hacking the processor, very clever. The rest is better read as bad fiction. Chalk this one up under the anarchist cookbook. Sure you may be able too, but you'll get thrown into jail or blow off a limb.

Not relevant on both counts...

[Moooo Cow]

At least, not relevant for this particular story.

1) The hackers themselves say "Until IBM fix the CCA software to prevent our attack...". According to the experts here, the fix is a software patch, not a hardware change-out.

2) This particular vulnerability only needs access to any single IBM 4758 running IBM's ATM. It does not depend on a whole set of them working together. In fact, given that you only need one, increased heterogeneity would increase the overall chance that a given network/organization has one exploitable system somewhere (although it does indeed decrease the overall chance that ALL your elements are exploitable).

Re:Mountain out of a molehill

[Quikah]

You only neeed access to the ATM for 20 minutes to download the keys. You then spend a couple days decrypting the keys offline.

I don't know about the rest of you but I have more than $20 in my bank account.

Re:33mkeys/sec ? Slow!

[man_ls]

Problem is, banks don't want to replace outdated hardware and networks, as long as their customers don't know they should be scared where their money is going.

Should their customers really be scared? How likely is it that the technology to do the hardware cracking is easily available? Not too likely, I'd assume.

For a janitor to even have access to a server room is relatively unlikely, especially in a bank; I can't imagine they would let minimum-wage grunts in the same room as the financial data of their customers. For said janitor to have $1000 of specialized computing hardware is another thing. For him to know how to hook up that hardware to the IBM Encryption Coprocessor is even more difficult. Then he would have to actually go grab the PINs - all he'd have at this point is the DES key which they are encrypted with.

Sure, one person may exploit it - but seeing as most janitors aren't reading Slashdot, and probably don't even know it, or an IBM cryptocard exists, there is very little to worry about.

You'd be more likely to win the lotto than to have your money stolen by a janitor who cracked IBM's encryption.

Re:The Great Game!

[Codifex Maximus]

Hmm.. I don't know. Sounds to me like you want to remove the very mechanism that drives innovation?

Competition breeds better products and more goodies for the consumer.

Some corrections

[hearingaid]

I live in Canada. Some of this may not apply to your jurisdiction.

My bank uses a PIN which is a minimum of 4 digits long. I believe the maximum is 12. This solves the length problem. I have a 4-digit PIN, but that's mainly because I'm a grad student, and anybody who steals my bank card and gives me money has my thanks. Unfortunately, no luck yet. :)

We have Interac cops. Interac is the Canadian banking network; the ATMs you see in malls in Canada are usually run by chartered banks, and when they're not, they're run by somebody on the Interac network. These devices get policed, and they have some pretty serious security measures on them.

There's still the basic vulnerability of the encryption scheme to consider, of course. But the other concerns you bring up can be dealt with.

Re:Some corrections

[Nate Eldredge]

12 digits is still not very much. It's only about 32 bits.

Re:33mkeys/sec ? Slow!

[Lally Singh]

Yeah, but it's pretty easy for a smart theif to be hired as a janitor.

Re:The Great Game!

[1010011010]

Yeah! It worked for the Soviets! And Mao! Let's go!

Ri-yot! Ri-yot! Ri-yot!

reduce the competitive nature of modern society and consequently the technological encryption/decryption competitive paradigm

Not to mention the free society paradigm, the able to feed oneself paradigm, and the use-the-forebrain paradigm. Rubbish!

Finally!

[LinuxHam]

Maybe now I can get my hands on one of these using my employee discount ;) Imagine a pair of these hacked into supporting VPN endpoints? Or hardware-assisted GnuPG?

If having physical access to the card is a prereq to cracking it, I'm not too worried about my mother-in-law coming by while I'm at work. Now, the black van down the street that never seems to move.. that's a different story..

Related technical paper

[dazed-n-confused]

If you want more technical detail, check out the
paper on API-Level Attacks on Embedded Systems by Mike Bond and Ross Anderson.

Ross Anderson is the author of "Security Engineering" -- if you're interested in this story but haven't read the book, consider this a strong recommendation. More details inc. sample chapters at his website. Plus other fascinating stuff.

Most worring aspect

[Martin S.]

The most worring aspect of this is that if this discover had been made by American academics (rather than British) it would have been squashed by the DMCA.

A nice real world example, that you should be able to exploit, to beat the politicians, to our collective benefit.

Jesus Jackie! And it runs Linux too.

[opkool]

I used to work with some of those cards at my former employee.

Ther are actualy 2 models, well, there were 2 models when I was there. They are called cryptographic 4758 and 4758-II.

The first (and older model) wasn't that good at being a fast crypto card. That good for 2001 standards, that's it. Back when they were developed were pretty darn good.

The newest model was better and more powerfull. It supports more and tougher encryption keys. It offloads any machine of the heavy-cpu-load encryption burden. And it is pretty good piece of technology.

Their mision is to take over the CPU when dealing with encryption. That is, encrypt stuff before being sent or decrypt stuff received. It can seen not a big deal. But think of e-commerce and/or bank transactions: litearly hundreds of encrypt/decrypt processes.

The card is (was) a computer-in-a-card. It has a CPU with the power of a 486 (it does not use a 486 cpu). And it costs lotsa money.

Not so long ago, I heard that IBM was considering dumping the propietary OS of those cards, and use instead embeded secure Linux.

Now, I want to believe that they have craked the older model. If it is the newer model, well, it is pretty bad. This banks means not being able to trust each other. And I'm serious.

Nevertheless, to access one of those cards installed in a sensitive system, you must have phisycal access to the card. And this is not easy. It's like a real-life ,a href="http://www.missionimpossible.com/">Missio n Impossible kind-of-thing.

If there's any problem with it, I'm pretty sure that the crypto team has worked and solved this thing.

Re:Yeh, but that cost half a million dollars

[maroberts]

Whilst the EFF Cracker cost $500,000, they recognised that now the research had been done you could build one for about $50K or so. Also FPGA tech has come a long way since then, so I reckon with a little forethought $10-20K may not be an impossible target, which if you can get a few million out of a bank for the effort is a good investment/ return ratio!

The EFF device was only cracking DES, not 3DES.

Just after EFF cracker came out I wrote a letter to the UK Daily Mail (National newspaper) about the security of credit card trading on the net.

Before you reply about it bear in mind:
a) the letter got edited heavily
b) this was when Euro browsers only had 40/56 bit encryption, and
c) yes the photo isn't of my good side! =-0 ]

And after you've stolen the cash

[Mwongozi]

The last question in the FAQ will help you out.