Slashdot Mirror
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.
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).
"Prepare for the worst - hope for the best."
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.
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)
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
Any sufficiently advanced man is indistinguishable from God
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'.
Not Meta-modding due to apathy.
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.
Note to ACs: I usually delete AC replies without reading them. If you want to talk to me, log in.
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?
12 digits is still not very much. It's only about 32 bits.