keystroke timing attack

[C. Jason Coit]

All,

Roel Jonkman and I release two patches that countered this attack a
while back.  I submitted a patch for OpenSSH 2.9p2 on Oct 5 and 2.9.9p2
on Oct 16.  These patches are located at
http://www.silicondefense.com/software/ssh/index.htm.  
Our method was to send packets every 50 ms (using IGNORE messages if no
keystroke was made) and then shutting down after about a second after
the last genuine keystroke.  Is it possible to get our code into
openssh?  



regards,

Jason Coit

Solar Designer wrote:
> 
> On Sun, Nov 11, 2001 at 02:12:44PM +0100, Markus Friedl wrote:
> > On Sun, Nov 11, 2001 at 01:26:25AM +0100, Andersson, Mats wrote:
> > > The next release of MindTerm (an ssh1/ssh2 implementation in java found at
> > > www.appgate.com/mindterm) contains a client-side "countermeasure" against
> > > this timing attack aswell. It starts sending IGNORE messages, at
> > > pseudo-random short intervals, of same size as a channel-data packet
> > > containing a keystroke when one start typing and then keeps on sending
> > > these packets up to 2 seconds after last keypress, completely hiding the
> > > inter-keystroke timings.
> >
> > but since the server won't send an 'echo' ignore message to the
> > 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. ;-(
> 
> > moreover i don't think random intervalls help, i think you need 'fixed'
> > intervalls.
> >
> > if you have random intervals, you can probably strip the random noise
> > if you have enough samples.
> 
> 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.
> 
> It's nice to see client authors try to design and implement additional
> countermeasures.  Unfortunately, I don't believe there's much which
> 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.
> 
> --
> /sd

-- 

+--                                  --+
|   C. Jason Coit Programmer/Analyst   |
|    Silicon Defense: IDS Solutions    |
|    http://www.silicondefense.com/    |
+--                                   -+