'Severe' OpenSSL vuln busts public key crypto Computer scientists say they've discovered a "severe vulnerability" in the world's most widely used software encryption package that allows them to retrieve a machine's secret cryptographic key. The bug in the OpenSSL cryptographic library is significant because the open-source package is used to protect sensitive data in …
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.
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!
/sarcasm
Paris, who of course handles frickin beams of another sort altogether...
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!
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.
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.
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.
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.
rant over...!!
> 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.
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.
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!
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.
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.
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.
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)
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!
"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.
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.
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...
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'.
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?
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.
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.
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.
--------------------------------------------------
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.
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
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.
</soapbox>
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.
It is a software problem. The implementation of the algorithm leaks information about it's internal state if you inject a bit error, or stop the processing at a particular point.
It's a well known attack, it was done 10years ago against IBM crypto chips using radiation induced errors.
There are a bunch of well known security programming tricks to stop this, and the similar power load analysis attacks.
After reading this, I tried to induce my Sky box to divulge it's porn channels for free by modulating the power supply with my Arc welder. It seems Sky, in their wisdom, anticipated this attack and have built in a protection mechanism where the box shuts down permanently after emitting a modest amount of smoke.
It would probably be better if the Reg resisted publishing these types of stories until the 1st April.
SSL is no longer fit for purpose and needs to be replaced. Modern application aware firewalls perform an SSL Decrypt (a man-in-middle attack) in order to identify the traffic and then can block the connection. Unless you check the SSL certificate, or the CA signed SSL certificate on the firewall expires (causing your browser to issue a warning) you are not going to notice.
Check your site's SSL certificate just in case.
You are sadly misinformed, I witnessed a PA-500 (Palo Alto) firewall do this in virtual wire mode. This firewall is two generations ahead of Checkpoint and probably one generation ahead of Fortinet.
It is very success at SSL decrypt and in fact can identify banking sites and not decrypt the traffic (as part of the security policy).
ROTFLMAO
I love it... a dire warning to those who seek to lock content (HD Video and Audio) to prevent it from being copied... not a warning to the world at large...(those of us doing our banking and buying things on eBay).
"Although the attack technique is difficult to carry out, it could eventually be applied to a wide variety of devices, particularly media players and smartphones with anti-copying mechanisms."
Difficult to carry out? Could eventually be applied? Thanks but no-thanks for the heads up on how to crack blue-ray.
How precisely to you have to produce 'transient' events in a power supply to finally squeeze out a few crumbs ? Can this be done consistently for 100 hours without destroying the device?
And then you still need to use an HPC cluster to tease the encryption key together?
Seriously?
I would think that this would just encourage hardware vendors to ship devices with more robust power supplies, that shouldn't be too difficult .. problem solved.
I thought the strength of FOSS was the "many eyes" looking at these issues, therefore when one of those "many eyes" finds something, what does the FOSS community do ?
They complain and argue against it, and attack the messenger. I thought the "model" of FOSS was supposed to promote and support testing and experimenting with the code?
Assume you have a large group of people working on breaking into a system, mabey something like the chinese government. With huge resources, people "on the inside" and massive support and technical resources.
Now also consider, the further development of this type of exploit, (bug).
You know programmically control you're CPU and RAM voltages, you can also remotely control the CPU load, and progababy even the internal cooling system including CPU fan.
So it's quite possible for future development and work on this bug would make it exploit REMOTELY exploitable.
Also with "inside" workers, (say a chinese IT worker working in google chine, on a night watch).
Would be able to access the machine, and with the availability of super computers get the key's he wants. Mabey without detection.
a Cluster of 81 P4's, what would a couple of fully configured quit CPU, quad Core i7's and 4 TESLA cards do it in. Probably not that long. with a desktop supercomputer or two.
So this exploit/bug is critical, and it's not that big a step to refine it as a remote exploit, it might be as easy as watching the CPU load, and taking advantage of the expected known CPU temp.
Or varying the CPU and RAM voltages (as overclockers do all the time), making it a remote exploit. (not to mention the 'insider job' possibility).
It's is a fault (bug) in OpenSSL, there should be NO WAY for fragments of the Key to be released in clear text due to hardware operational issues.
It's about time FOSS start to take security more seriously, and cease beign so cavalear with the assumption that 'all it just dandy in FOSS'. It's not........
The Register 
Biting the hand that feeds IT
Copyright. All rights reserved © 1998–2024
