Re: Defeating HyperThreading attacks

I strongly agree with you but what's up with my last argument.
To collect enough information you need to see several encryptions.
If I use 2 keys and made an alternate use of the 2 keys. How could a
program know that I have change the key ?

I have a last idea to expose. Nobody has made a comment on my first post.
Maybe my english is too sloppy, or everythings I said was evident...

But I have proposed prefetch has solution against collision attacks on the
aes. The model of attack is different but when I read the paper of colin I
see that he is really afraid of prefetching and if now we add like in my
version of the aes some prefetching instruction and a dummy array (there
is no dummy array in my version of the aes). I believe it to be the killer
idea against those attacks (I should have read more carefully colin's
paper). Our encryption process can also play with cache to disturb the
opponent. What do you think about it ? I will make test tomorrow.

I really want to think you David for your helpfull and usefull comments.

In the end:
"To ensure that the two processes
run simultaneously, we start running the Spy process before we start
OpenSSL, and stop it after OpenSSL has nished, while minimizing the
number of other processes running; without these steps, an attacker
might need to make several attempts before he successfully spies
upon OpenSSL."Colin's paper

On Tue, 31 May 2005, David Wagner wrote:

> >Can I control the number of process running on the platform ?
>
> No, of course not, not unless you have superuser privileges.
> (I am assuming you are referring to Linux, since that is what you
> mentioned in your original post.)
>
> >I think that we could deal with Hyperthrading
> >in this way. But I am not sure actually since I have done nothing here.
>
> Ok, let us know what you find when you do the experiments.
> I don't see how it could work, but if you are able to make this
> idea succeed, please let us know.
>
> >One of my real question can a malicious HyperThreaded program take
> >advantage of cache misses on a real server with high load.
>
> Who knows? I don't see any fundamental reason that would prevent
> such an attack. (Most likely the S/N ratio will go down, but maybe
> that just means the attacker needs to have more observations.) It
> seems prudent to assume such attacks are possible, lacking an airtight
> argument that such attacks are impossible.
>
> I think you are taking much too optimistic a view here. Are you
> assuming the adversary is lazy and will not adjust his attack to
> defeat the defenses you put in place? If so, that is a bad assumption.
>
> Rule #1 of security analysis: In case of doubt, better assume the worst.
>
Received on Thu Sep 29 21:39:25 2005