IBM Crypto Up For Grabs? 230
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.
Hacker divas suck. (Score:2, Insightful)
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. (Score:1, Informative)
Re:Hacker divas suck. (Score:1)
It's also criminally negligent behavior, you idiot. Do you really want them being held responsible for banks and other high security installations being 'hacked'?
Or maybe you just don't want your money to be secure..
Re:Hacker divas suck. (Score:1)
Re:Hacker divas suck. (Score:1)
Or should it be presented to the banks first, to give them a chance to upgrade?
Re:Hacker divas suck. (Score:3, Informative)
Re:Hacker divas suck. (Score:1)
I think the middle ground they selected to follow [ie: informing the media that there was a problem and letting them hype it up] raised just as much public interest as releasing the details would do, while not providing exploitable information for John Q Public.
Re:Hacker divas suck. (Score:1)
Re:Hacker divas suck. (Score:2, Interesting)
Re:Hacker divas suck. (Score:2, Insightful)
Re:Hacker divas suck. (Score:3, Interesting)
I'm all for full disclosure, but blind siding is not ethical.
Re:Hacker divas suck. (Score:3, Interesting)
Re:Hacker divas suck. (Score:1)
Re:Hacker divas suck. (Score:2)
Actually, the knowledge of hardware DES cracking is already pretty old [eff.org].
Crypto (Score:1)
The Great Game! (Score:1, Insightful)
The problem is the competitive nature of modern business. Despite what the hackers and libertarians may say, the home user has no real need of encryption - encryption is the technology of big government and big business. The home user does not need it for his emails to Aunt Beth and porn downloading, but Big Government and Megacorp(TM) most certainly do, for their official secrets and industrial espionage.
The development of encryption is rather like the development of weapons - it is at it's fastest in a cuthroat society of vicious competition.
If we really want secure communication, we must not treat the symptoms by encrypting, but rather effect a radical cure - we must render all motivations for evesdropping redundant.
How?
Simple. Just attack the basis of competitive society by encouraging greater global cooperation (some sort of 5th International?), smashing big business, nationalise the worst, most competitive industries leaving only the big, lumbering and safe monopolies to do their thing. This way, we reduce the competitive nature of modern society and consequently the technological encryption/decryption competitive paradigm.
It would be tough, but is eminently possible. We just need the will to power!
Re:The Great Game! (Score:2)
Re:The Great Game! (Score:1)
Re:The Great Game! (Score:1)
Ok, sure. I can agree with that.
The problem is the competitive nature of modern business. Despite what the hackers and libertarians may say, the home user has no real need of encryption - encryption is the technology of big government and big business. The home user does not need it for his emails to Aunt Beth and porn downloading, but Big Government and Megacorp(TM) most certainly do, for their official secrets and industrial espionage.
Hmmmm. Nope.
The development of encryption is rather like the development of weapons - it is at it's fastest in a cuthroat society of vicious competition.
So, the common folk have no right to protect themselves or their communication? Just the bigwigs of CorporateSociety and those in high places of power within the governments of the world? Huh-uh. Government exists to serve us, and neither would the Corporations of the world exist without consumers to fleece.
Re:The Great Game! (Score:1)
In order to make it impossible to break ones privacy, you propose to just drop privacy ourself?
Another possibility to reduce the motivation for evesdropping would be to encrypt everything. Let the individuals decide which one they like :)
Re:The Great Game! (Score:2)
Competition breeds better products and more goodies for the consumer.
Re:The Great Game! (Score:2)
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!
Lessons to be learned: (Score:4, Insightful)
Re:Lessons to be learned: (Score:1)
2. Related to time of testing. If you get one processor that is 99.99% tested or 10 processors that are 80% tested, which would you rather have? Either the bug is very, very hard to find and it gives you access to all doors or there are a number of implementations all of which are easy to crack.
Not relevant on both counts... (Score:2, Informative)
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:Lessons to be learned: (Score:5, Interesting)
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 [ibm.com].
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: (Score:4, Interesting)
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 [nist.gov] 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: (Score:2)
The correct URL for the white paper is here [ibm.com].
Re:Lessons to be learned: (Score:2)
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: (Score:3, Informative)
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: (Score:2)
it removes the work factor created by security I meant "the work factor created by obscurity", of course.
Re:Lessons to be learned: (Score:2)
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: (Score:3, Informative)
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.
Re:Lessons to be learned: (Score:2)
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: (Score:2)
Banks make a big hullabaloo about security, more to scare people off than for real security.
I question the point of advertising your hack.... (Score:1)
RealVideo Coverage (Score:5, Informative)
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.
Re:RealVideo Coverage (Score:1)
Re:RealVideo Coverage (Score:1)
If it was a local file, seeking wouldn't be bad, but even on my DSL connection, it takes ~ 6-10 seconds to buffer every time you jump around the file. Very, very annoying.
Thank goodness i already had RealVideo installed. (ugh.)
Re:RealVideo Coverage (Score:1)
... and Alan Cox at about 30 minutes.
Insiders (Score:5, Interesting)
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 (Score:2, Interesting)
Maybe the debit cards or other transactions they mention are more vulnerable
Re:Insiders (Score:1)
A magnetic stripe recorder can be had for a few hundred dollars, so it's not too hard to create a replica of the "physical ATM card."
Re:Insiders (Score:1)
As someone else has pointed out, the more likely way to use this would be transfer money into an account they can abscond with, but simulating those transactions is yet another hurdle to overcome. The risk seems relatively low
Re:Insiders (Score:1)
More dangerous than decrypting any individual transaction would be decrypting the keys used to encode the transactions (which is what the article says they've done).
So, you make up your own set of transactions tranferring funds from one place to another, perhaps using the credit card and account numbers you collected along the way, encrypt them with the discovered keys, and send them off to be processed.
Re:Insiders (Score:3, Interesting)
Re:Insiders (Score:1)
I was 19 at the time, in generic t-shirt and jeans sort of attire, not exactly 'professional' looking. As far as thievery goes it's probably easier to generate a check card number (they should be within a certain range, and credit card generation is public knowledge).
Re:Insiders (Score:3, Insightful)
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.
When will they learn... (Score:1, Offtopic)
ut-oh (Score:1)
Oh man, I can see it now
Banker's son: "Hey dad, I need a new computer. I hear Alteras are pretty good...."
ATM's are more prone to stone age methods (Score:4, Informative)
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 (Score:1, Informative)
3) It's not that easy to screw around with an ATM without getting caught. Otherwise you would see a lor more criminals stealing cash directly from within the machine.
4) Don't get a debit card if you don't want one. In the US a debit card is usually also on the Maestro/Mastercard networks, while ATM cards are on only (e.g.) Cirrus and NYCE. See the logos on the back. Also a debit card will have a hologram and usually a network logo on the front.
Re:ATM's are more prone to stone age methods (Score:2)
Re:ATM's are more prone to stone age methods (Score:2)
Re:ATM's are more prone to stone age methods (Score:2)
Mountain out of a molehill (Score:1, Insightful)
Frankly if you have gone that far why not just rob the vault? The money is right their. Ultimatly with this stealth run of encryption you have a bunch of PIN numbers.... Ok great but you don't have any of the cards or the card info that is needed even. Even if you some how extract the contents of the cards magnetic strip you still have to manufacture a card, then you have my pin number. Great now you can withdraw the total sum of my bank account which is
This is really not all that different than me saying I can crack a PCs bios password if I can get access to the physical machine and have a screwdriver. the amount of effort that precedes the hack negates the hacks effectiveness.
I applaud their inginuity, and I hope IBM buys the idea off of them as a handy tool to recover lost data, but if I was IBM I would not be in any big hurry to change all of this hardware.
Re:Mountain out of a molehill (Score:2)
I don't know about the rest of you but I have more than $20 in my bank account.
Re:Mountain out of a molehill (Score:1)
With these keys you could forge inter-bank or bank-atm traffic at will! Just choose some account and transfer as much money as you need.
Well, you shouldn't use an account that can be traced back to you... ;)
Question... (Score:5, Interesting)
(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... (Score:1)
Re:Question... (Score:3, Interesting)
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... (Score:2, Funny)
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... (Score:2)
All the bank then has to do is say "well the cardholder must have lent their card to someone else".
Re:Question... (Score:2, Informative)
Re:Question... (Score:2)
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... (Score:2)
Re:Question... (Score:2)
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... (Score:2)
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).
Re:Question... (Score:3, Interesting)
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 [cam.ac.uk]. "Why Cryptosystems Fail" is probably the most immediately rewarding, given your concerns.
Re:Question... (Score:2)
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... (Score:2)
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...
Just another case of security by obscurity? (Score:2)
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.
typical (Score:1)
Pretty focussed branch manager... (Score:4, Funny)
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
Old news (Score:1)
Well, it's a worry but... (Score:1, Insightful)
to check my balance regularly.
So anyone could tap my phone,
or just use an AM radio.
But chances are it will never happen to me...
Only a matter of time (Score:4, Insightful)
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 (Score:5, Insightful)
But if you read their page about how PIN works [cam.ac.uk] 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 (Score:2)
If you are going to crack one open far easier to simply pinch a machine just after it has been filled...
Some corrections (Score:4, Insightful)
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 (Score:2, Interesting)
Re:Only a matter of time (Score:5, Informative)
For those interested, you can find how many bits a key with x values is using logarithms:
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 [distributed.net].
Re:Only a matter of time (Score:3, Informative)
Re:Only a matter of time (Score:2)
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. :)
From the FAQ on their site (Score:1)
Where can I go to book tickets to Bermuda?
Go to http://www.bermuda-online.org/airlines.htm
Funny stuff.
Is your parent a bank manger? (Score:4, Funny)
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.
33mkeys/sec ? Slow! (Score:1)
So, yeah, it sucks that these people found a weakness that lets them guess key bits, but DES should have been tossed years ago. At least for 3DES, which doubles the effective key size. But isn't the AES standard finalized now?
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.
Re:33mkeys/sec ? Slow! (Score:2)
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:33mkeys/sec ? Slow! (Score:2)
Re:Yeh, but that cost half a million dollars (Score:2)
The EFF device was only cracking DES, not 3DES.
Just after EFF cracker came out I wrote a letter to the UK Daily Mail [pipex.com] (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 ]
Finally! (Score:2)
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 (Score:4, Informative)
paper on API-Level Attacks on Embedded Systems [ross-anderson.com] 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 (Score:3, Insightful)
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. (Score:3, Informative)
Ther are actualy 2 models, well, there were 2 models when I was there. They are called cryptographic 4758 and 4758-II [ibm.com].
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. [ibm.com]
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
If there's any problem with it, I'm pretty sure that the crypto team has worked and solved this thing.
And after you've stolen the cash (Score:2)
No (Score:2)
Re:bad slashdot (Score:2)
Re:bad slashdot (Score:1)
Re:bad slashdot (Score:1)
Sure, it's a small number, but even one is too many.
Re:bad slashdot (Score:1)