Information Security with Colin Percivalby Michael W. Lucas
Michael W. Lucas: Who is Colin Percival, and why should we listen to him?
Colin Percival: To the first question: I'm a visiting researcher at Simon Fraser University in Canada, as well as being a deputy security officer with the FreeBSD project. I started my B.S. in mathematics at age 13 (concurrent with high school) and graduated with a first-class honors degree in 2001; to the extent possible within the confines of an undergraduate degree program, I had an emphasis on number theory and computer algorithms. I then went to Oxford University, where I recently defended my doctoral thesis in computer science.
To the second question: you should listen to me because I have written a 12-page academic paper presenting and discussing a serious security vulnerability, and nobody has been able to refute my results. I believe that my work stands on its own; it doesn't need my name attached to give it credibility.
MWL: I saw your hyperthreading presentation at BSDCan, where you demonstrated weaknesses with the combination of cryptographic software and hyperthreading. Can you explain your work in a way that those folks who aren't cryptographers, and who find that 12-page paper intimidating, can understand it?
CP: Well, this is a bit of a strained analogy, but here goes. Imagine that you work in computer technical support. You're really good at your job, but you can never answer any questions on your own--instead, you have a collection of really good computer manuals spread out on your desk, and every time someone asks you a question, you have to refer to the appropriate manual to work out what the answer is.
Now, because you're so good at your job, you don't just help one customer at once; instead, you have two phones, and you try to help two customers at once, alternating back and forth between them. If the two people you are helping are asking about completely different problems, then you can have both manuals open to the right pages, and this works very well; but if you've got two people who need answers from the same manual, then you have to spend time flipping the pages back and forth, which means that it takes far longer for you to answer each question.
Since the two people you are helping can measure how long it takes you to answer their questions, they can determine if you have to flip pages--in other words, they can determine if the other customer is asking you questions for which you need to refer to the same manual in order to answer.
In my paper, "you" are the CPU, the two people you are helping are two computer programs, and the reference manuals you are using is the main memory of the computer. By measuring how long it takes for the CPU to perform some calculations, a program can work out which parts of the computer's main memory are being used by the other program. Once it knows this ... well, it's hard to explain further without explaining technical details about how encryption works, so let it suffice to say that knowing which memory locations are being accessed while some data is being encrypted or decrypted can very often tell you what the data, or the secret key being used, is.
MWL: A real system has a lot of things going on at the same time, though. To stretch your analogy even further, you don't have two callers on the line--you have dozens, or even hundreds. You were able to recover hundreds of bits from a key in your environment, but it appears, to me at least, to be a bit different from recovering an actual key on an actual system in the real world; even the lowest-use system has a lot of processes scheduled. Isn't this vulnerability largely theoretical?
CP: You're stretching the analogy in the wrong direction. You're right that there may be dozens or even hundreds of programs running on a busy system--or, in our analogy, that many customers phoning for technical support--but what matters is how many programs are running at once. On a hyperthreaded CPU, there are only ever two programs being run at any given time; all the rest are waiting for their turn (again, much like technical support lines!).
All an attacker needs to do is get his code running on the CPU at the same time as the program he is trying to spy on--and he only needs to do this once. If he doesn't succeed on his first attempt--that is, if some other program is selected to run at the same time as his target--then he can just try again. A computer that is running at 90 percent of capacity is a very heavily loaded system, but even there the attacker would only need to make ten attempts on average before he succeeded; and each attempt takes a fraction of a second and is for all practical purposes undetectable.
In short, the vulnerability is entirely practical. In my paper I make some assumptions for the purposes of making it easier to explain and demonstrate the attack, but the difficulties an attacker would encounter in the real world are far from insurmountable.