keystroke timing attack

Andersson, Mats mats.andersson at appgate.com
Mon Nov 12 20:08:21 EST 2001


Hi,

On Mon, 12 Nov 2001, Solar Designer wrote:
> > client's ignore message, it's now possible to figure out the
> > SU-signature again!
>
> Why, it would also not send "echo" ignore messages when a shell
> command (and not a password) is being entered.  So the server-side
> countermeasure continues to work to the same extent it normally did.
>
> It's just the described client-side countermesure which turns out to
> be totally ineffective (as opposed to quite ineffective which it
> normally is) when there's also a server-side countermeasure as
> recommended by our advisory and as implemented in recent OpenSSH. Such
> an interesting interaction. ;-(

I wasn't aware of the server-side counter-measure (or what it did) which
was allready in the openssh-server when I did this in our code, I should
of course have checked :-(.

Ok, sending all keystrokes in a stream with evenspaced packets was the
countermeasure originally propsed by MaF here at AppGate. I thought that
it might add perceived latency to keyboard input and it is also somewhat
harder to implement given how my code works right now so I simplified it
with just adding the noise (as it was both solutions turned out to undo
the server-side countermeasure of course :-). I didn't think this through
very much, I just thought that adding noise is better than nothing.

However this is an optional feature and disabled by default so it might be
used with servers which doesn't have the server-side counter-measure.

> In case anyone cares, I agree with Markus entirely.  In fact, this
> issue has been discussed before our advisory and the Berkeley paper
> went public.

I'll go read that paper now, actually it was on my TODO-list but that list
has a strange tendency to flood continually... :-).

> can be done without a protocol extension which would let clients and
> servers agree on the dummy traffic.  Whatever we thought was practical
> to implement right now is described in the advisory.  For the clients
> this means protecting the initial login username and password only.

Fair enough (for now one could enable the client side counter-measeure
when it sees a server which it knows doesn't have the server-side one,
which is what I'll do actually since it is still better than nothing :-).

Thanks for the input.

Cheers,

/Mats




More information about the openssh-unix-dev mailing list