Hi,

Some secure protocols like SSH send encrypted keystrokes
as they're typed.  By doing timing analysis you can figure
out which keys the user probably typed (keys that are
physically close together on a keyboard can be typed
faster).  A careful analysis can reveal the length of
passwords and probably some of password itself.

The paper:

  http://portal.acm.org/citation.cfm?
  id=1267612.1267637&coll=Portal&dl=GUIDE&CFID=1943417&C
  FTOKEN=28290455

I'm seriously considering implementing a fix for this
weakness.  Is there any interest in incorporating this
sort of thing into openBSD?

Cheers  --Kevin

[ message continues ]

Be warned: implementing any sort of time-based events in the current
SSH mainloop is annoyingly difficult.

If you can do it cleanly, then we are interested.

-d

[ message continues ]

The paper itself is not accessible. Prima facie, this looked like a
technology-in-search-of-a-problem kinda thing to me. For now, it
sounds like bull.
However, there are atleast 10 references to keystoke
timing/characteristics. That this 'weakness' holds water is a
judgement call. Of course, one can make any kind of conclusion only
after studying the paper/references.

Hari

[ message continues ]

Just wait until you see me type!


[ message continues ]

I remember reading that or a similar paper a while back. The idea has
been around for longer. Is it a weakness? Yes, I'd say so. I can't
comment on how serious it is, but at first blush not too serious. Making
OpenSSH immune would be nice, as a proactive step.

The reason why I think it's a weakness is that you can gather statistics
on typing and use those to infer things. I.e., you can extract
meaningful information from the encrypted session. If you're snooping on
ssh and see a short burst of typing followed by another ssh session from
the remote machine you can guess they typed 'ssh host.example.com' by
the length of typing and the host connected to. Nice crib. Oh, after
than connect was there another short burst? Probably the password. How
many keystrokes can probably be inferred. Perhaps stats on interkey
timing can be used to make some intelligent guesses, such as the 4th
char is NOT punctuation because is followed char 3 too closely. Or
whatever.

Just because this takes real work and isn't in a popular script kiddie
tool doesn't mean you should discount it. Traffic analysis of one kind
or another has a long history of paying off well.

--
Darrin Chandler            |  Phoenix BSD User Group  |  MetaBUG
dwchandler@stilyagin.com   |  http://phxbug.org/      |  http://metabug.org/
http://www.stilyagin.com/  |  Daemons in the Desert   |  Global BUG
Federation

[demime 1.01d removed an attachment of type application/pgp-signature]

[ message continues ]

On Thu, Sep 11, 2008 at 10:06:27AM +0900, Hari wrote:
| On Thu, Sep 11, 2008 at 4:58 AM, Kevin Neff <kevin.l.neff@gmail.com> wrote:
| > Hi,
| >
| > Some secure protocols like SSH send encrypted keystrokes
| > as they're typed.  By doing timing analysis you can figure
| > out which keys the user probably typed (keys that are
| > physically close together on a keyboard can be typed
| > faster).  A careful analysis can reveal the length of
| > passwords and probably some of password itself.
| >
| > The paper:
| >
| >  http://portal.acm.org/citation.cfm?
| >  id=1267612.1267637&coll=Portal&dl=GUIDE&CFID=1943417&C
| >  FTOKEN=28290455
| 
| The paper itself is not accessible. Prima facie, this looked like a
| technology-in-search-of-a-problem kinda thing to me. For now, it
| sounds like bull.

Sure the paper is accessible. Just google for "Timing Analysis of
Keystrokes and Timing Attacks on SSH". First hit is the PDF of the
article which is well written and explains the problem in great
detail.

Cheers,

Paul 'WEiRD' de Weerd

+++++++++++>-]<.>++[<------------>-]<+.--------------.[-]
                 http://www.weirdnet.nl/                 

[ message continues ]

This is nearly complete bullshit.  For any individual, learning
their characteristics could give rise to being able to know a
great deal about what they are doing, but hardly for the 
general case.

I know people who type blindingly fast.  I'm a mutant hunt
'n pecker, but I can go 50wpm+ when on a good keyboard and
awake, and far slower then conditions aren't good.  I also have
a problem with my right hand which makes for typing problems
at times.

How about people with severe physical problems?  I know a C4
quadrapledgic who types slowly, very slowly.  Depending on how
he feels, his speed varies by probably a factor of 4 or so.

Such a system could learn for an individual if you know things
about them.  But what about a Chord keyboard?  Dvorak?(sp)

If you want to worry, think about the sounds a keyboard makes.
Get an old IBM "buckling spring" keyboard (original PC and AT)
and listen to the sounds it makes.  That is something you
could probably decode with decent accuracy.

--STeve Andre'

[ message continues ]

if I was trying to gank a quadriplegic's password I'd probably not use
keystroke analysis.
and damn, who would steal a quadriplegic's password? that's like
punching a dude with glasses, only slightly worse.

[ message continues ]

Hell you say. I wear glasses and have been punched. Hard. In the face.

Good to know I'll be immune from you.


[ message continues ]

These two sentences contradict one another.

[ message continues ]

As a general method of attack, this won't work well.  As a specific
attack on someone whose characteristics are known, timing data
will be more useful.

--STeve Andre'

[ message continues ]

http://www.eecs.berkeley.edu/Pubs/TechRpts/2008/EECS-2008-32.html

No need to say more. I'm not using keyboards anymore. I think we have
much worse things to worry.

-- 
Giancarlo Razzolini
http://lock.razzolini.adm.br
Linux User 172199
Red Hat Certified Engineer no:804006389722501
Verify:https://www.redhat.com/certification/rhce/current/
Moleque Sem Conteudo Numero #002
OpenBSD Stable
Ubuntu 8.04 Hardy Heron
4386 2A6F FFD4 4D5F 5842  6EA0 7ABE BBAB 9C0E 6B85

[ message continues ]

On 9/10/2008 at 2:58 PM Kevin Neff wrote:

|Hi,
|
|Some secure protocols like SSH send encrypted keystrokes
|as they're typed.  By doing timing analysis you can figure
|out which keys the user probably typed (keys that are
|physically close together on a keyboard can be typed
|faster).  A careful analysis can reveal the length of
|passwords and probably some of password itself.


I do not agree with that statement.   Using two fingers I can hit the "A" and
"L" keys nearly simultaneously (probably could even hit them simultaneously if
I tried enough).

The statement seems to rely upon the typist being a one-finger typer.

[ message continues ]

Thanks for all the comments.  I think we're all pretty much on the same
page.

First order of business is to look at how much of a weakness this may be.
Then, implement several potential solutions.  Finally, test to see if the
"fixes" improved the situation.

I like the idea of mainly patching the username and passwd transfer.  But
there may be some utility to having interactive sessions as bullet proof as
possible.

I will pitch the idea to my group.  If they agree to work on it, we will
have something by the end of the quarter (bar F).

--Kevin





[ message continues ]

Sorry, I'm finally at my real mail client. It's not a "real"  
vulnerability, imho. Merely a way to time and attack the individual  
keystrokes. I suspect you could ID individual users, if not figure out  
passwords, etc.

If you're that concerned about your ssh session, multiplex the tunnel  
and have an expect script randomly execute remote commands through it.  
Your interactive shell will be the "real" session, with expect  
throwing interactive "noise." No real additional setup required, just  
using multiplexed tunneling in ssh(1)

[ message continues ]