On Sep 12, 2008, at 4:08 PM, Damien Miller wrote:
There is no reason to believe that keystroke timing attacks will be
impossible against protocol 2 where they work against protocol 1.
They might just be a little more tricky.
I don't think I discounted an updated version of this attack against
SSH2, as much tried to say it's "impractical to the point of
unlikely." Even more so given the changes in SSH2 from SSH1.
Pointing at the paper and discounting it because it is ssh1 only is
sticking your head in the sand. It is usually easier to research
attacks
on simpler protocols and work up to more complicated ones later.
I do admit Eve could figure out the differences between Adam, Bob,
Celeste, and Dora by typing timing patterns and timing in packet
payload between the boxes, even if they shift locations.
Given enough time and enough response packets you might be able to
figure out which two letter commands were given at any given time.
Section 6 of RFC4253[1] should provide some level of masking to which
character is typed outbound to the remote system and more than bit on
the return, and Eve could - possibly - correlate which two packets
represented which characters through inference based on the number and
frequency of return packets and other events (fresh outbound ssh, etc).
It's just a improbable attack. One that's easily defended against by
maintaining the interactive shell/echoback and simply push additional
random ssh interactive packets through simulated keystrokes via a
multiplexed ssh(1) tunnel[2]. Injecting noise should work better than
sending blocks of text+commands which will likely release some of the
same information for little to no gain in privacy or security.
In the end, there are far easier (and therefor more likely) methods to
retrieve a password than fingerprint Bobs typing patterns through
letter frequency and presumed key placement. Typing patterns change
between context (mine do, I type far faster and longer with IRC than I
do when deciding flags or using short burst two or three letter
commands)[3]. Of course, that's a different problem entirely than the
one the thread originator came up with.
[1] http://tools.ietf.org/html/rfc4253#section-6
[2] Seriously, if you're worried about Eve, read ControlMaster and
ControlPath in ssh_config(5) and multiplex your ssh session. Have a
script that will intermittently fire off random commands in a shell on
the remote machine and do nothing with the returned output. It'll be
interactive (vs bulk), and difficult to differentiate from your "real"
traffic. Hell, have it randomly execute ssh(1) from the remote system
to arbitrary remote systems you'd normally visit and hang up at the
Password: prompt (or even log in by chaining auth back..).
[3] granted, if you can account ssh input with IRC output, you have a
basic black box. Length of typing, number of letters, etc. So, there
may be a form of analysis that would work, but not quite in the same
block-cypher SSH1 vuln as the item described in 2001. This would have
the additional effect of masking who's the person typing from the
keystroke timing fingerprint, but again Eve needs a large amount of
packet information that's somewhat reliable to correlate the output to
the input.
