I like these types of articles... relevant, educational, interesting please publish more of these!
I glanced over the report, this is a hardware fault rather than an OpenSSL one per say.
Honestly I'm not sure if it should be software's responsibility to obfuscate code/data which in theory is secured by the hardware itself. There's no getting around it, the software will always have to trust the hardware it's run on.
The only way to validate the OpenSSL output is correct against hardware errors is to repeat the same operation. If the two results don't match, clearly a hardware error took place. This redundancy comes at a cost, though, and unless there is more than one implementation, then it's possible for the same error to reoccur.
Finally, real science is upon us
After all the pseudoscience discussions about Global Climate Change (or does it have yet another name now) and other "soft" sciences, glad to see some scientists working on really important stuff, like putting frickin laser beams on frickin server power supplies!
Paris, who of course handles frickin beams of another sort altogether...
Your a moran
go away, ta
Ha ha ha ha!
Please tell me this was meant as a joke. Please. It's great!
If you were serious; then....oh dear god. Back to school for you!
what can you not do?
I'd say ... this glitch seems to be a good thing for those trying to crack HDCP and similar DRM crap. Monkeying around with the power supply requires the 'hacker' to have physical access to the server, which makes said attack unfeasible. However, it is a damn good method to crack all that stuff they stuck into HD content, Blu-Ray and similar media. Nice!
Here is the first value in the encryption chain.
OK, so if I spot any dodgy looking characters fiddling with the power switches in the server room for more than 100 hours, I should be worried?
p.s. Why does your big brother avatar look so similar to Rafa Benitez?
The repeated processing of the secret key surely generates emanations, which can be averaged up because they occur millions of times over a few weeks on sites like paypal.com. Averaging can be used to reconstruct a signal even if it is much below the noise floor.
And no fiddling with the power supply, by the way.
Bring back shops!
There was nowt like this to worry about in the days of shops and banks.
All this interweb telesales malarkey's a load of old bobbins.
Please tell me you're not serious?
You've probably got more chance of being on the receiving end of a chip-and-pin scam than get bitten by this!
I think you've got more chance of having your wallet stolen by a poetry-reciting 300lb gorilla wearing a Lester Haines mask and a tutu than having this "exploit" used against you.
Wake me when an actual usable exploit is discovered.
Easy to exploit?
OK, so that is an exploit, but how did they decide it's a severe exploit? Shouldn't a severe exploit be something that would relatively simple to reproduce?
I mean they are talking about power fluctuations causing 4 bit pieces of information that I would guess need to be discovered amongst other gathered information and then put together with 8800 others and run through a special program on a cluster and then run through a specially designed sparc embedded device (custom system by the school? as is the program on the cluster?).
Yeah, I see how that has got to be very worrisome. I think very few governments or organizations could do this and I bet this will be fix before Saturday, in fact if it wasn't a zero day I bet it already is.
This "easy" to exploit only in a system with a physically separate trusted platform module or other crypto chip like a smart card or a crypto token. In most cases these do not use openssl in the first place. Even if they did, the ones that are really of interest like smart cards and crypto-tokens have voltage stabilisation on-chip.
This exploit is impossible to apply to a server or any device that does openssl on its general purpose CPU. As anyone who has had a duff capacitor on a motherboard can testify having your CPU power supply glitch is no fun.
Out of all attacks on SSL over the years this definitely gets the prize for the most esoteric one.
An exploit can be critical for two reasons...
1. It can either be critical because it is easy to implement.
2. Or it can be difficult to implement but, once implemented, can compromise the entire system of operations.
The OpenSSL exploits qualifies under criterium 2 because it is a way to get at confidential data that, if used, can compromise the entire SSL chain of trust and create an authenticated man in the middle that, as far as SSL is concerned, looks exactly like one of the parties.
but how did they decide it's a severe exploit?
If blue-ray is cracked, it will destroy the "Same Old Swill, Yet Another Media"-scam causing the collapse of banks and the end of life as we know it!
@An exploit can be critical for two reasons
That's correct, however because the exploit is physical, it's of limited practical use against general users of openssl. For example, on servers capable of decrypting their own data on bootup, physical access already implies data access.
Therefor a new physical attack vector, especially a difficult one, doesn't increase the group of unauthorized people capable of attacking the system.
This is problematic with DRM because the user who needs to open the content is supposed to be prohibited from knowing the encryption keys, however this goal is incompatible with encryption theory today which requires one to either have the keys or not.
Therefor DRM relies on faulty physical security and software obfuscation, which we already know are broken. We may yet discover an encryption algorithm weakness, but until we do another physical exploit only proves again that DRM is a faulty application of encryption for the purposes of true security.
I know it's in quotes, but I would hardly call this a "severe" vunerability that "busts public key crypto"....It requires fine tuning a power supply, an 81-machine cluster and knowledge of, or inventing another "custom-designed algorithm".
From the title was expecting some major flaw in SSL certs that blew them out the water or something, not an academic attack that virtually no-one could pull off.
private key at danger = severe.
> It requires fine tuning a power supply,
Oh, I can do that... like almost anyone with proper education.
> an 81-machine cluster
of ancient 2.4GHz P4.
I have a pair of POWER 750s inbound, that should do the trick.
> and knowledge of, or inventing another "custom-designed algorithm".
given the interest this message caused with my colleague, it will be only a matter of days.
And for -say- a blue ray player, you have all the time you like to extract the data.
It is severe.
nothing to do with openssl
I find this article is in poor form. This is a hardware attack, and not a new one at that. People have been injecting power supply and clock glitches in to systems for years. There are references all over the net about this, and specific attacks.
To claim that this is anything new is wrong, and to name the openSSL project, and the mozilla foundation software projects in this context is wrong. This is not about a bug in any of them and the bad press is unfounded. Yes you can glitch computers and chips, and that is a matter of hardware/physical security.
OpenSSL are entirely innocent here. They do not have a bug, especially not a 'severe' one.
Blu-ray uses AACS crypto, and has nothing to do with OpenSSL.
You need fine grained control over the power to chip to do this, and you need to know the specific chip. A random 'hot' server is not going to do this. You'd need physical access to the machine, and need to lift the power supply pin to a chip and inject your own fine grained power, and be able to run a controlled crypto test over and over while observing the results.
This smells like someone fishing for publicity, and an article picked up and run by someone who really doesnt understand the subject.
Your words sound good
But when the OpenSSL team says they are applying a fix to eliminate this class of attack it means you're talking turns to dust.
It's entropy-mental, my dear Watson
This problem is almost certainly to do with the entropy gathering in the random number generator of the system being cracked. It is normal to stir in entropy data gathered from the hardware (like minor variations in temperature, or bus noise, or maybe small power fluctuations) to the random number seed process to avoid deterministic sequences of random numbers. If you can guess what a sequence of random numbers will be during key generation (SSL uses transient session keys to encrypt parts of the rest of the key exchange and checking process), then the value of the key is severely reduced.
Exactly how this entropy data is gathered is normally specific to the OS and device, so I suspect that the same technique would have to be significantly varied for each different device you want to attack. If you have a device with good isolation from external variations, then this technique will be virtually useless (although gathering entropy data becomes more difficult). And if you have a really good hardware based random number generator that has it's own entropy gathering mechanism, then this will be impossible.
Mind you, I don't fancy being around if they start using focused beams of radiation to affect systems within Data Centers.
Tinfoil hats anyone!
Now I finally have a use for that 81-machine cluster of 2.4 GHz Pentium-4's I have in my attic.
Mine's the one with "Algorithms For Dummies" in the pocket.
you have to put it in perspective ...
The previous estimates for brute-forcing a 1024-bit RSA are in the neighborhood of a million cpu's and a couple years.
So yeah 100 hours on a 81 computer cluster is amazingly easy.
And their method of attacking the algorithm by causing computation error is amazing.
A thermorectal cryptoanalysis technique for hardware
careful with assumptions
Careful assuming that this attack is too estoic to matter. For many keys all it takes is breaking once to cause all kinds of mayhem (whats that key geeks put on their tshirts). What is ironic and so poetic is any evil DRM loving corporation that had the gull to use open source code to do their dirty work deserves to have their keys posted on the internet. Not good how western society is building up a giant house of cards on a virtual land rush of "ownership" of any idea. My coats the one with the super complicated worthless derivative that I paid a PhD a million dollars so I could fleece my customers with.
Typical research done on a budget
and not even a well managed budget. 81 P4 machines cost how much, and took 104 hrs to work the solution. By anyones money, that would be about 20 mins or less on Amazons EC2. Perhaps a quick course in financial management would be in order for these quacks.
Apart from which, the Lab Tech must have been pretty pissed off that his WOW sessions were interupted for 104 hrs. You have to ask yourselves here, which is the more efficient use of time and money. A happy Lab Tech is worth his weight in gold, 2 weeks without world of warcraft is abject hell as any sys admin would know.
..think of the people conducting this research. Building an 81 node cluster to do this would be FUN. And while the cluster is chuntering away for 100 hours you can play WOW on the new EC2.
I haven't RTFM, but I'd guess the cluster/grid they're using is owned by their or another Uni and available to borrow for research use.
That kind of thing was certainly the norm when I did my CS degree six years ago (God!); especially for cypto stuff. Any unused grid cycles were normally "wasted" on stuff like SETI@Home (what? we are computer geeks)
(Gravestone: feeling old)
104 hours is only
4 days 8 hours - it just feels like 2 weeks without WOW!
How is this _not_ an OpenSSL vuln?
Yes, it's a glitching attack. Yes, they're nothing new. But here, they're using a glitching attack to grab bits of the key as OpenSSL processes it. Therefore, it's an OpenSSL vuln.
Also, if OpenSSL agree it's a bug in OpenSSL and are patching it, then I think we can be fairly safe in saying its a bug in OpenSSL.
Anyway, this is very cool and demonstrates again how subtle and difficult encryption is. Remember kids: never try to roll your own!
Of course - why has no-one tried this before?
"Once they gathered about 8,800 malformed messages from the targeted device, they fed the data into an 81-machine cluster of 2.4 GHz Pentium-4 systems running a custom-designed algorithm. They applied the technique to an embedded hardware device consisting of a Sparc processor running a Linux operating system and were able to extract its 1024-bit private key in 104 hours."
Now that sounds like something that can be done by every hacker out there. My servers are that insecure that anyone can spend enough time fiddling with their power supplies to extract 8,800 messages without anyone knowing. Said attacker also has an 81-machine cluster of 2.4GHz P4 servers that they can use for 104 hours. Oh, and did I mention they've also got the same custom-designed algorithm as these "researchers"?
I'm thinking someone's trying to find a way to make their "research grant" money go to good use, and failing miserably in my books.
Yes, once the fix is out I'll upgrade, but only because it's good practice to stay up-to-date; not because I'm worried of an immediate attack risk.
How much of a power spike does it take?
The article should have been a little bit more detailed about what the "researchers" did with the power supply. If it takes fiddling with the power supply to introduce memory errors, then the system is introducing memory errors INTO EVERYTHING ELSE RUNNING ON THE BOX!! How many times did that box crash while they were doing their test?
The solution for this is to have good power supplies and ECC memory. Thus, no problems.
Open vs Closed
A fascinating insight into just what security researchers get up to in their lunch breaks. Also an excellent comparison between proprietary and Free software:
Requirements for cracking Free Software:
1. Control of the victim's power supply (i.e. have physical access)
2. Fluctuate power > 9,000 times
3. Load results onto an 81 machine cluster
4. Run more than a hundred hours of processing time on that cluster
5. Get it all done before the patch is pushed.
Requirements for cracking 'the OS that shall not be named in security reports':
1. Visit a malicious URL.
Hehe, perhaps I should apply for that job at the Daily Mail...
How can it not be a bug with openssl?
How can it not be a bug?
If power fluctuations are effecting the the data out of the system it seems to me RAM/buffers are not being cleared before and after use! Even if this is a seed problem it still smells of using uninitialised memory.
they are manipulating the power to cause the processor to incorrectly process a calculation. That makes it a hardware attack, and openssl can and are making their code more resistant to certain processing errors, but if you have a controlled environment and can affect the processors operation directly with enough time/effort/money/skill you'll get it eventually.
However the type of attack isnt new, isnt openssl specific, and is the complete opposite of 'severe'.
Single bit error in multiplication?
OK, so if we can force the computing device to have a single bit error, how do we know the multiplication it's doing is part of the SSL calculation and not deciding how much memory to (de)allocate or the address data in an array etc... any of which is highly likely to make the machine so unstable that it falls on it's arse.
So, unless we're really lucky we're going to loose those 4 bits we were looking for (unless it's a sensible machine and does a core dump, which would only be readable by an "admin" priv user, who can read the private key anyway)
So, we've got a machine on it's back. Now wait half an hour for someone to notice, wander in and reboot it.
And they managed to get 8800 of these errors in 100 hours?
Even assuming a rapid reboot cycle of only 5 minutes between shutdowns and assuming that your single bit error always hits SSL processing and you can get the data out (including the time required for the SSL stack to become available and you to initiate a calculation and refiddle the PSU) only gives 1200 instances.
For manufacturers to "get round" the problem, they only need to encrypt half their content (say every other KB or maybe less than half 1K in 10...) and then the chances of you hitting the PSU frig button at the same time as you're doing some SSL calcs are minimised.
Or have I completely misunderstood something?
Put it on Power
Because this architecture has single bit correction and double bit detection on all memory and all the internal system registers. And there are additional checks on the results of any machine operation (I'm led to believe that there are effectively tilt bits on the internal hardware instruction sub-units, and once more than one is tripped, it re-executes the instruction).
Should reduce the effect of power (not Power) glitches and even cosmic ray corruption to make this type of attach meaningless.
So DSA is safe?
WWSD (What Would Stalin Do?)
Spy! Much easier.
Yes, it's a hardware problem
We've been fixing certain hardware problems in software for ages. The proposed fix hardens the key, so it would be a good idea anyway.
And, yes, after the hardware engineers should re-examine their product and work to implement a solution to that part of the problem as well.
Not the first time...
Interesting , except for the fact that it's not the first time this happens : Attacks to both RSA encryption and decryption using low voltage inducted faults are presented here : http://www.computer.org/portal/web/csdl/doi/10.1109/FDTC.2009.30
And these guys did not use a cluster, but a single PC to elaborate the results in a few minutes, nor they did time the glitches in the supply voltage, they just underfed the CPU a little bit.
81 cluster P4s
They applied the technique to an embedded hardware device consisting of a Sparc processor running a Linux operating system and were able to extract its 1024-bit private key in 104 hours.
Does that 104 hours include the 100 hours it took to glitch the power supply in the first place, or is that merely 100 computing hours used to rebuild they private key from the 8800 malformed messages?
Even if that is 100+ hours CPU time, it's only on 81 old P4s - if you could feed it to a botnet of a million or more machines you've brought that time down to seconds.
Glitching the power supply takes the time but the processing power is out there if you're prepared to (ab)use it for the rest.
Interesting approach they've taken and I can deny it's clever but I think "Serious Vulnerability" is taking it a bit far - In very specific controlled circumstances, it's possible to leak enough data that a huge cluster of machines can determine a key.
That said, full marks for a novel approach.
except it's not novel...
This technique is not novel, it has already been applied, successfully , to a real ARM9 running Linux and not to a generic SPARC reproduction on an FPGA. The required time to generate the faulty signature is much less and the scheme can be broken in minutes by a single pc. The paper has been published a _year_ ago , and it's available here : http://home.dei.polimi.it/barenghi/files/FDTC2009.pdf
Its science FFS
Ok, I can't really see why so many people are complaining that this is a publicity hunting exercise by scientists. It probably is ... they need to do those to survive these days due to the stupidity of the modern world that science should be relevant. Thank god we didn't believe that before, otherwise we'd have no modern technology at all - electricity was just an interesting phenomenon once, people.
Science is there for its OWN sake ... like philosophy, music, drama and literature ... its PRIMARY purpose is to enrich the human condition by understanding our universe. Lots of nice technology is a great SECONDARY by-product - but the moment we make it the principal purpose is the moment we stop really doing science.
This is a very interesting attack. It shows you could introduce processing glitches - in this case by PSU tweaking, but maybe in future by a remote microwave beam etc - which cause a supposedly non-key revealing algorithm to reveal its key. It demonstrates use a network of ancient, virtually obselete machines as a sufficient cheap grid, showing a small botnet would suffice for a calculation (brute forcing a 1024bit key) that should require millions of CPUs. Did the poster who mentioned it only taking 20 mins on Amazons EC2 remember how networks such as EC2 ever came to be developed? It is researchers like this who - eventually - make stuff like that possible.
They have even shown there is a fix to this. Ok, maybe they are looking too hard for a moment of fame by calling it 'severe', although I agree with some of the posters who have pointed out once a consumer hardware device's private key is out there, that actually IS a serious thing.
But FFS, lets give these people some respect. When I was one I was paid less than half as much, worked more than twice as hard and had about the same job security (albeit year-on-year rather than month-on-month) as a contractor. I'm sure it's not much different now. And even if only 1% of these people will make 'useful' contributions during their research, the ratio wont get any higher if you make scientists focus on 'useful' stuff, as the whole thing about science is we don't know what will turn out to be useful.
This is great stuff, proper science, and kudos to the folks involved - even if they have slightly exaggerated the severity, which I'm not sure they have.
Jeez, does anyone RTFA?
Repeat after me: "Media players and smartphones with anti-copying mechanisms."
Repeat after me: "Servers, by contrast, would be much harder to attack because they are generally located in places that prevent people from manipulating their power supply."
It seems like every monkey in the place hears the word "software" and automatically starts shouting "OS"! "Windows"! "Linux"! "Server"! Word up, kiddies - the majority of software systems in the world wouldn't know a web server from a wildebeest. They're living in cars, DVD drives, microwaves, digital watches, and stuff like that. Most of these won't use OpenSSL, but a few will, if they need to implement security algorithms. OpenSSL's license is BSD-like, in that the idea is to provide a generic toolkit which anyone can use provided they acknowledge they're using it, and a good software engineer will always re-use tested code instead of writing their own from scratch.
Suppose you could multi-region any DVD drive, any time - a few people in Hollywood would be interested. Or suppose you could hack a car's engine controller to let you remap it. That's got safety implications, especially if the car is something like a Prius with electric motors permanently connected to the drive-wheels - if the software says go then it goes *now*, no hanging around waiting for throttles to open. Or suppose you could hack your X-Box to find what secret key MS have used - at that point you have the same rights as MS, and they physically can't shut you out. Worse, any trusted algorithms used by X-Box coders to identify a user could be circumvented, so now you've got carte blanche to write your own numbers into the amount of gold pieces your wizard character has, what upgrades are on your car, etc.. I've no idea whether Toyota or MS use OpenSSL, but those are the kind of exploits we're talking.
Dear God! My blog!
Fuck me but what a cool job these people have - I have worked in IT for over twenty years and its all I can do to stay awake (I am tired of clowns telling me that getting their Windows desktop to show the latest picture of their spawn tarquin is mission critical)
Best news of the Decade
If this mean that we will be able to remove the illegal DRM that infect: blueRay Disk, MediaPlayer, PVR, Video Game Console Etc...then this might show once and for all that DRM are not only ilegal,. but 100% useless.