Hi all, Over the past 10 years, there has been some discussion and several patches concerning keystroke timing being revealed by the timing of openssh packet network transmission. The issue is that keystroke timing is correlated with the plaintext, and openssh users expect their communications to be kept entirely secret. Despite some excellent ideas and patches, such as Jason Coit's http://marc.info/?l=openssh-unix-dev&m=100326089315915&w=2 there has been little done to address this problem. As far as I can tell, the only countermeasure implemented in OpenSSH is that the server will echo back dummy messages (rather than nothing) when users enter passwords. But users expect all of their communication to be secret... not just their passwords! (There is no project called "SecurePasswordShell"!) I think Jason's approach is spot on: * keystrokes should be only sent at predetermined intervals (eg: every 50ms, or 20 times a second) * cover traffic at these fixed transmission times should be sent even if no keystroke is pressed. This can be turned off whenever a user is idle for 3 seconds. The security of Jason's proposal is clear: no information is leaked, except the timing of when the user starts and stops a typing spurt. This is because the same traffic pattern is created, regardless of the timing of the keystrokes. Why is this feature not available in OpenSSH? Jason's patch is almost 10 years old and doesn't apply to modern OpenSSH. If I cleaned it up, would it be seriously considered for inclusion in a future release? Cheers, Andrew
Isn't it difficult to predict the size of a legitimate response to a keystroke? Just because you send a dummy response doesn't mean you got the size right. If you don't get the size right it's easy to differentiate wheat from chaff. Sent from my iPhone On Dec 27, 2010, at 8:11 PM, Andrew Clausen <clausen at econ.upenn.edu> wrote:> Hi all, > > Over the past 10 years, there has been some discussion and several > patches concerning keystroke timing being revealed by the timing of > openssh packet network transmission. The issue is that keystroke > timing is correlated with the plaintext, and openssh users expect > their communications to be kept entirely secret. > > Despite some excellent ideas and patches, such as Jason Coit's > > http://marc.info/?l=openssh-unix-dev&m=100326089315915&w=2 > > there has been little done to address this problem. As far as I can > tell, the only countermeasure implemented in OpenSSH is that the > server will echo back dummy messages (rather than nothing) when users > enter passwords. But users expect all of their communication to be > secret... not just their passwords! (There is no project called > "SecurePasswordShell"!) > > I think Jason's approach is spot on: > * keystrokes should be only sent at predetermined intervals (eg: > every 50ms, or 20 times a second) > * cover traffic at these fixed transmission times should be sent even > if no keystroke is pressed. This can be turned off whenever a user is > idle for 3 seconds. > > The security of Jason's proposal is clear: no information is leaked, > except the timing of when the user starts and stops a typing spurt. > This is because the same traffic pattern is created, regardless of the > timing of the keystrokes. > > Why is this feature not available in OpenSSH? Jason's patch is almost > 10 years old and doesn't apply to modern OpenSSH. If I cleaned it up, > would it be seriously considered for inclusion in a future release? > > Cheers, > Andrew > _______________________________________________ > openssh-unix-dev mailing list > openssh-unix-dev at mindrot.org > https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev
I'd like to have better keystroke timing countermeasures in OpenSSH, but they are just too intrusive under the current mainloop design. I'd like to renovate the mainloop some time and this would make implementing things like this quite a bit more easy. -d On Mon, 27 Dec 2010, Andrew Clausen wrote:> Hi all, > > Over the past 10 years, there has been some discussion and several > patches concerning keystroke timing being revealed by the timing of > openssh packet network transmission. The issue is that keystroke > timing is correlated with the plaintext, and openssh users expect > their communications to be kept entirely secret. > > Despite some excellent ideas and patches, such as Jason Coit's > > http://marc.info/?l=openssh-unix-dev&m=100326089315915&w=2 > > there has been little done to address this problem. As far as I can > tell, the only countermeasure implemented in OpenSSH is that the > server will echo back dummy messages (rather than nothing) when users > enter passwords. But users expect all of their communication to be > secret... not just their passwords! (There is no project called > "SecurePasswordShell"!) > > I think Jason's approach is spot on: > * keystrokes should be only sent at predetermined intervals (eg: > every 50ms, or 20 times a second) > * cover traffic at these fixed transmission times should be sent even > if no keystroke is pressed. This can be turned off whenever a user is > idle for 3 seconds. > > The security of Jason's proposal is clear: no information is leaked, > except the timing of when the user starts and stops a typing spurt. > This is because the same traffic pattern is created, regardless of the > timing of the keystrokes. > > Why is this feature not available in OpenSSH? Jason's patch is almost > 10 years old and doesn't apply to modern OpenSSH. If I cleaned it up, > would it be seriously considered for inclusion in a future release? > > Cheers, > Andrew > _______________________________________________ > openssh-unix-dev mailing list > openssh-unix-dev at mindrot.org > https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev >
On Mon, 27 Dec 2010, Andrew Clausen wrote:> I think Jason's approach is spot on: > * keystrokes should be only sent at predetermined intervals (eg: > every 50ms, or 20 times a second) > * cover traffic at these fixed transmission times should be sent even > if no keystroke is pressed. This can be turned off whenever a user is > idle for 3 seconds.This idea has merit, but please make it adapt to low bandwidth and high delay networks. For example, avoid sending dummy traffic if the transmit queue is not empty (which probably signifies a low bandwidth or high loss connection); or move the predetermined intervals further apart if the connection has high round trip time. --apb (Alan Barrett)