Boy, do I hate it when a
FLOSS
project is given a hard time unfairly. I was this morning greeted
with news
from many
places that OpenSSL, one of the
most common FLOSS software libraries used for cryptography, was
somehow severely vulnerable
.
I had a hunch what was going on. I quickly downloaded a copy of the academic paper that was cited as the sole source for the story and read it. As I feared, OpenSSL was getting some bad press unfairly. One must really read this academic computer science article in the context it was written; most commenting about this paper probably did not.
First of all, I don't claim to be an expert on cryptography, and I
think my knowledge level to opine on this subject remains limited to a
little blog post like this and nothing more. Between college and
graduate school, I worked as a system administrator focusing on network
security. While a computer science graduate student, I did take two
cryptography courses, two theory of computation courses, and one class
on complexity theory0. So, when
compared to the general population I probably am an expert, but compared to
people who actually work in cryptography regularly, I'm clearly a
novice. However, I suspect many who have hitherto opined about this
academic article to declare this severe vulnerability
have even
less knowledge than I do on the subject.
This article, of course, wasn't written for novices like me, and certainly not for the general public nor the technology press. It was written by and for professional researchers who spend much time each week reading dozens of these academic papers, a task I haven't done since graduate school. Indeed, the paper is written in a style I know well; my “welcome to CS graduate school” seminar in 1997 covered the format well.
The first thing you have to note about such papers is that informed readers generally ignore the parts that a newbie is most likely focus on: the Abstract, Introduction and Conclusion sections. These sections are promotional materials; they are equivalent to a sales brochure selling you on how important and groundbreaking the research is. Some research is groundbreaking, of course, but most is an incremental step forward toward understanding some theoretical concept, or some report about an isolated but interesting experimental finding.
Unfortunately, these promotional parts of the paper are the sections that focus on the negative implications for OpenSSL. In the rest of the paper, OpenSSL is merely the software component of the experiment equipment. They likely could have used GNU TLS or any other implementation of RSA taken from a book on cryptography1. But this fact is not even the primary reason that this article isn't really that big of a deal for daily use of cryptography.
The experiment described in the paper is very difficult to reproduce. You have to cause very subtle faults in computation at specific times. As I understand it, they had to assemble a specialized hardware copy of a SPARC-based GNU/Linux environment to accomplish the experiment.
Next, the data generated during the run of the software on the specially-constructed faulty hardware must be collected and operated upon by a parallel processing computing environment over the course of many hours. If it turns out all the needed data was gathered, the output of this whole process is the private RSA key.
The details of the fault generation process deserve special mention. Very specific faults have to occur, and they can't occur such that any other parts of the computation (such as, say, the normal running of the operating system) are interrupted or corrupted. This is somewhat straightforward to get done in a lab environment, but accomplishing it in a production situation would be impractical and improbable. It would also usually require physical access to the hardware holding the private key. Such physical access would, of course, probably give you the private key anyway by simply copying it off the hard drive or out of RAM!
This is interesting research, and it does suggest some changes that might be useful. For example, if it doesn't slow a system down too much, the integrity of RSA signatures should be verified, on a closely controlled proxy unit with a separate CPU, before sending out to a wider audience. But even that would be a process only for the most paranoid. If faults are occurring on production hardware enough to generate the bad computations this cracking process relies on, likely something else will go wrong on the hardware too and it will be declared generally unusable for production before an interloper could gather enough data to crack the key. Thus, another useful change to make based on this finding is to disable and discard RSA keys that were in use on production hardware that went faulty.
Finally, I think this article does completely convince me that I would never want to run any RSA computations on a system where the CPU was emulated. Causing faults in an emulated CPU would only require changes to the emulation software, and could be done with careful precision to detect when an RSA-related computation was happening, and only give the faulty result on those occasions. I've never heard of anyone running production cryptography on an emulated CPU, since it would be too slow, and virtualization technologies like Xen, KVM, and QEMU all pass-through CPU instructions directly to hardware (for speed reasons) when the virtualized guest matches the hardware architecture of the host.
The point, however, is that proper description of the dangers of a “security vulnerability” requires more than a single bit field. Some security vulnerabilities are much worse than others. This one is substantially closer to the “oh, that's cute” end of the spectrum, not the “ZOMG, everyone's going to experience identity theft tomorrow” side.
0Many casual users don't realize that cryptography — the stuff that secures your networked data from unwanted viewers — isn't about math problems that are unsolvable. In fact, it's often based on math problems that are trivially solvable, but take a very long time to solve. This is why algorithmic complexity questions are central to the question of cryptographic security.
1 I'm oversimplifying a bit here. A key factor in the paper appears to be the linear time algorithm used to compute cryptographic digital signatures, and the fact that the signatures aren't verified for integrity before being deployed. I suspect, though, that just about any RSA system is going to do this. (Although I do usually test the integrity of my GnuPG signatures before sending them out, I do this as a user by hand).