Recent Features
| |||||||||||||
Buffer keys at 100 ms intevalsBuffer keys at 100 ms intevalsPosted Sep 18, 2008 15:23 UTC (Thu) by felixfix (subscriber, #242)Parent article: OpenSSH and keystroke timings
Only send keystroke packets every 100 ms (of course this interval would have to be configurable). If that is no keys, no packet. If that is 1 key, one packet. If it is 10 keys, one packet.
It would introduce some weird latency. But I think it would be fairly easy to try, and some experimenting would show whether an interval small enough to be bother-free would send multiple keys.
You could even make it a lower and upper bound, and it would choose a random interval between them for each packet.
I wonder how much difference this would make in the entropy.
I personally don't think a 100 ms interval would be very obnoxious. The weird part would be its burstiness, which might make 100ms too hard to get used to. But if you pick an interval that sometimes sends two or even three keys, that should be enough. Well, but then you might have packets every interval for several intervals, then skip one or two, then a few more, and that might be a clue that the skipped packets were due to quickly typed keys having been combined in the previous or next packets :-)
(Log in to post comments)
Buffer keys at 100 ms intevals Posted Sep 18, 2008 15:55 UTC (Thu) by docwhat (subscriber, #40373) [Link]
Adding chaff might be easier and less disruptive. Have SSH randomly send non-keystroke keystroke-like packets every so often. Latency wouldn't be effected much.
You could also randomly time shift keys characters by a 1ms or two every so often. I don't think a user would notice that.
Ciao!
Buffer keys at 100 ms intevals Posted Sep 18, 2008 18:17 UTC (Thu) by felixfix (subscriber, #242) [Link]
Those are both better ideas :-) The chaff one is fun, but the time shifting sender is the best, since it produces no chaff for the receiver to have to discard. My batching idea might also require a receiver change, if keystroke packets can only have single keys now. The time shifter can be done entirely on the sender side and the receiver will never know the difference.
Buffer keys at 100 ms intevals Posted Sep 18, 2008 19:29 UTC (Thu) by docwhat (subscriber, #40373) [Link]
Sure. Implement the key jitter-time-shift idea now. Then later you can add stuff that requires the receiver to understand it's chaff.
Ideally, the packets should be the same size, so keys and chaff should both be the same structure except that the chaff has an extra bit saying it's chaff.
An alternative that may be implementable now (I don't know much about the SSHv2 protocol) is to use a bogus encryption key so that it is rejected on the receiving side. That'll add additional confusion to anyone trying to break the stream as they'll have to separate the differently encrypted packets from one another.
Ciao!
Buffer keys at 100 ms intevals Posted Sep 18, 2008 18:22 UTC (Thu) by djm (subscriber, #11651) [Link]
Yes, this is essentially the idea I had: quantise the packet sending time to some interval, and send chaff for some interval after the last keystroke. Unfortunately this is quite difficult to implement in OpenSSH's crufty mainloop :(
Buffer keys at 100 ms intevals Posted Sep 19, 2008 0:20 UTC (Fri) by gmaxwell (subscriber, #30048) [Link]
Tricks like this sound nice but try proving that they actually stop the information leak. As far as I'm aware nothing short of padding to a full constant information rate has ever been proven to stop information leaks from timing in systems where they have been considered (anonymous remailers, onion networks).
Since we're already talking about a somewhat obscure (though, no doubt, real) vulnerability it's probably not worth adding complexity for a half solution which can not be proven to completely close the hole.
To me the obvious solution to this would be to extend ssh agent to supporting more types of authentication, and allowing programs other than SSH to make use of that functionality. Timing attack immunity would fall out as a nice side-effect but greater robustness against compromised jump hosts would also be a benefit, as well as the ability to provide things like smart-card authentication across multi-hop ssh connections.
Beyond the basic SSH-via-SSH or SUDO-(PAM)-via-SSH) cases it would take some time for applications to be updated to take advantage of this functionality, so it wouldn't be an overnight fix, but we've lived with this vulnerability this long so a bit longer waiting for the right fix shouldn't kill anyone.
Buffer keys at 100 ms intevals Posted Sep 19, 2008 6:00 UTC (Fri) by djm (subscriber, #11651) [Link]
SSH isn't like an Onion network or a remailer - those seek to hide the identities of disparate users, whereas SSH just needs to mask inter-keystroke timings and run lengths. It's quite a different (and much simpler, thankfully) problem.
|
|||||||||||||