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

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:

[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:

[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]

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.

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

[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: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.

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...

[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.

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

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

[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.

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!

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: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

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.