Slashdot Mirror
Remote RSA Timing Attacks Practical
David Brumley and Dan Boneh writes "Timing attacks are usually used to attack weak computing devices such as smartcards. We show that timing attacks apply to general software systems. Specifically, we devise a timing attack against OpenSSL. Our experiments show that we can extract private keys from a OpenSSL-based server such as Apache with mod_SSL and stunnel running on a machine in the local network. Our results demonstrate that timing attacks against widely deployed network servers are practical. Subsequently, software should implement defenses against timing attacks. Our paper can be found at Stanford's
Applied Crypto Group."
The article says that they "can extract private keys from an OpenSSL-based web server". That doesn't sound like a compromise to the RSA algorithm. They just got the private key.
-phish
Since it came out in 2000, have modern browsers fixed the cache cookie problem? (Besides refusing cookies?)
If we were ants living on a Rubik's cube, differential geometry would be a little more confusing.
I'm pretty sure you're trolling, but I'll bite...
:)
Your elitism has been commented on thoroughly, so I'll skip to the meat.
It takes 1.5 million queries to break an SSL key using this technique if you have an account on the same machine. That's for a local attack.
They go on to give evidence that a remote attack is possible, but don't actually give parameters that would indicate the complexity of the attack. 1.5 million queries is already kind of pushing it though, and I would imagine taking the attack to the remote setting, even with a small round trip, will explode the complexity significantly. So the attack may not be feasible at all.
Furthermore, adding random variance to latency data doesn't theoretically help much. Get enough samples, and that noise drops out. It raises the number of queries, yes, but doesn't stop the latency from forming a statistically usable distribution.
-Lux
Everybody's suggestion seems to be to add a random delay to responses.
Why ?
Why not make the response time fixed ? Like in the biggest possible response time. If every query was responded in x ms, NO info would be leaking to the attacker. Or am I missing something ?
fixed or random delays work find - as long as you don't leak info about the key. this is mentioned in the paper.
the attack is a nice proof-of-concept, but almost totally impractical. notice that their "lan" was a completely private switch, with just the attack and target machines on it. if your lan is anything like mine, there's huge variance that will defeat the attack. not to mention that any other activity on the target machine will make the attack harder, or any kind of traffic shaping (they were doing 140 probes per second). not to mention simply turning on blinding.
it's great to see this vuln demonstrated in the lab, but really no need to worry about it.
All the OpenSSL developers need to do is check between each calculation, and wait until a slashdot article is moderated at "insightful"....NOT :-D
("funny", now, would operate like a geiger counter somewhere in the western region of the former U.S.S.R...and would probably overload the servers of the world; there would quite simply be no delays in any SSL engine on the planet.)
Not that I'm trying to add to the noise, mind you...
Redundancy is good; triple redundancy is twice as good! - Me.
Hmmmm... Not as unlikely as that - lots of people host on virtual-machines (e.g. Verio) or with managed hosting companies (e.g. Rackspace, which is why I'm nervous ;) ). That means that latency is very low, and fairly consistent.
Just a thought.
Think about what you're saying for a second. If it is possible, using any sort of method whatsoever, to extract an RSA private key from a device that has only a public key, RSA is completely broken in general. In this particular example, I just build an X-box, substituting my adversary's public key for Microsoft's public key, perform whatever hocus pocus you're suggesting, and get my adversary's private key.
The fact is that the timing attack given in the article involves timing decryption, an activity where the private key is used. For the reasons I outlined above, it would make no sense to have a timing attack where what you're timing only involves the public key.
In general, since X-boxes do not have the private key, the private key cannot be found given unrestricted access to X-boxes unless RSA is broken.
Again, this shows how important it is to use separate key pairs for different jobs.
Imagine you use the same private key for both vulnerable SSL servers, and for offline protocols, such as PGP or S/MIME. Whoever successfully attacks your interactive SSL server would be capable of reading encrypted mail sent to you in the past.
Then you could (somewhat) compensate for latency with each iteration.
Not necessarily elegant or foolproof, but I think possible... I wonder how much varience/latency (noise) you can reasonably account for before the exploit breaks down (or becomes too time-consuming to be worthwhile...)?