Slashdot Mirror
The Keyboard That Could Phone Home
An anonymous reader writes "University of Pennsylvania researchers have developed a keylogger they call the JitterBug that can modulate passwords or other information into normal traffic by adding imperceptible delays to keypresses as people use keyboard and network-intensive apps like telnet and remote desktop. The idea is that the delays in keypresses cause delays in packets, and data can be encoded in those delays. There's no software or extra network activity that the victim can see, but anyone who can see the traffic (even if it's encrypted) could grab the data. Here's the scary part: the researchers say that it could be manufactured into a keyboard, making these keyloggers widespread and virtually undetectable."
...by adding your own random jitter to outgoing packets? I'm thinking of something like an option in OpenBSD to do this for all TCP connections, say.
Carousel is a lie!
Couldn't any kind of virus or malicious "software" be manufactured in to many different hardware. It's the trust and accountability we have in companies that keeps this from happening in general. It's kind of crazy we would have to worry about something like that...
The "Made in Nigeria" had me worried, but with a quality name like Sony on the keyboard, I decided not to worry.
...i .blame ....the ..user ....for ..not ....being ....more .......vigilant .if .....this ..ever .....happened ..to .....me (..and ..it .....wouldn't) ...i ..wouldn't .....be ..blaming ....some ."hacker" ....for ..my ....own ..lax .......security
intellectual property law is philosophically incoherent. it is your moral duty to ignore it or sabotage it
Who uses telnet? And if they are, sniff the damn packets directly.
And RDP is not a keystroke-per-packet, 100% of the time. Neither is SSH. Without that, you couldn't make any assumptions about the data you may have missed.
Encryption latency, packet retransmissions upon collisions at routing equipement... there are 1000 reasons outside the lab this wouldn't be even remotely useful for tracking activity off the desktop, and there's way easier ways of doing it on the desktop.
It would only work when the pressing of a single key causes the generation and transmission of a packet. Telnet is what they talk about, but most terminal programs would be vulnerable. Connecting to a mainframe is obvious, but you'd have the same problem with windows remote desktop, any remote client programs, etc. The SSL telnet program send passwords as a single packet, so that would prevent transmission of information during the password phase, but would not prevent it during interactive use.
Normal websurfing, email, and desktop applications run on the computer itself (instead of remotely) would not pass any usable jitter information.
Ajax web based applications could be vulnerable if they generate packets each time a key is pressed. Not many do this, but more will as time goes on.
The key problems are:
1) It can, at best, transmit 1 bit per keypress
2) All of the intelligence would have to be in the keyboard for deciding *what* to send.
Further, I haven't read the paper, but I don't see how this would work unless the user's typing patterns are very well known to the program, or the jitter introduced is significantly greater than 1/2 the average keypress to keypress time. This would be noticable to most people, though they would get used to it. This could be adaptive though, if you know that a particular keyboard is used by one user, and the keyboard spends a significant amount of its bandwidth on known patterns.
Also, the keyboard cannot query the computer - the only information it could gain is what is typed in it. And since it could only get 1/7 of the possible information that's typed in (or perhaps 1/3 if good compression is used) then it wouldn't be able to get very much at all.
All in all, it seems like a cool trick, but like tempest it requires some fairly specific conditions. For most things there are other ways that are likely easier, less detectable by the end user, and more informative than this one. But under appropiate conditions, it could be just the ticket.
-Adam
This Trusted Input Device method, I call TID BITS, for short.
This issue is a bit more complicated than you think.
SSH already went through the debate of timing style attacks and came out fine: http://www.ssh.org/company/newsroom/article/204/. Additionally, web forms aren't transmitted until you hit submit. So you need some interractive session to monitor to detect something like this. The article mentions telnet, which, if you're going to sniff to detect packet timing, you might as well watch the packets themselves. When you get into something that is encrypted and interractive, wouldn't there be enough random jitter from the encrypting and other data, like mouse position updates when you have remote GUI's, to make this very difficult without creating so much jitter to be obvious to the user that the keyboard is screwed up?
Implementation wise, the article lacked detail, so it's time to guess what's involved. You can't simply add a fixed number of ms to each key. What you need to do is have a timer that you are always offsetting from. Otherwise, the time that the user takes to type a key would be added on to the keystroke jitter, making it useless. Say you only watch 90 keys, giving you up to 90X, where X is some measurable time. The timer would also need to be 90X, meaning that you really have a maximum possible delay of 180X. With a CPU context switch (this is an interactive user), encryption processing, and physical network delays, I'm guessing that X would have to be several ms to be detectable. That would make the maximum time, even with only a 3ms X, over a half second in the worst case, which a user will certainly notice. Of course you can reduce the number of keys that you monitor, I picked 90 because it made the math easy and eliminated the F1-F12 keys. But anything over a couple 1/10s of a second will be noticable.
I recall a story of someone who determined a co-workers password by listening to the timing of her keypresses.
"mickeymouse" m i c k e y mou s e
That's why I keep a liberal supply of dandruff and chicken grease on my keyboard at all times. Even if the boffins manage to make an identical keyboard (with the windows keys ripped out, no less), they could never recreate the back-alley ambiance.
Cool! Amazing Toys.
Just enable (as it's usually disabled for things like SSH) Nagle's algorhitm, and it should destroy most of the timing information.
For those who don't know, it's a TCP optimization that buffers data until there's a packet worth of data, or an ACK is received for the last packet sent, so that writing 1 byte of data into a socket doesn't immediately result in sending a packet with 40 bytes of overhead, and 1 byte of data.
Sure, there is valid reason to be concerned about spying hardware and software being built into computers.But unfortunatey bullshit hype like this just clouds the issue, when it is finally discredited it will just make it that much harder for people who are warning of valid concerns.
I'm an American. I love this country and the freedoms that we used to have.
Incorrect. It's true that there'd be no way to prevent the keyboard from collecting data, but one could certainly prevent the successful transmission of the collected data. The way the data would be encoded would be via the timing of the packets sent in response to keystrokes; that logic path most definitely involves software levels, specifically (in the example given of a remote terminal session) the choice of the software to send a packet once per keystroke. The proposed solution of introducing jitter to the packets is indeed a solution, and a simple straightforward one at that.
- First they ignore you, then they laugh at you, then ???, then profit.
This sounds like a good way for citizens to track politicians' activity. As citizens we need better ways to serruptitiously monitor our public servants.
Smaller cameras would be better too.
So if you had 40 USB keyboards plugged into one machine, and used a different one to type each character of the password, you wouldn't have a problem, correct?
Fellowship 9/11
Mod parent up. This was my immediate question as well, and I still haven't heard it answered.
... I just can't think of it right now.
If you want to encode information into the delay between key-press packets, then you need to make the delay significantly longer (at least a few standard deviations) than the average difference between two keypress packets.
People don't type at exactly the same rate, so if the delay in between keypresses varies (I'm making up numbers here) between 100 and 150 ms, then you need to make the introduced delay greater than 50ms.
Alternately, you could buffer all of the incoming keystrokes in the computer, and send them out at a constant rate (say exactly 100ms apart); then you'd only have to add a small delay to them in order to encode information. But unless the packets are being buffered and sent out in such an orderly fashion by the host system already, it seems like this kind of behavior could be easily picked up on, because it would cause a delay of at least a few keystrokes in an interactive system (if there's one packet per keystroke and you're queueing and buffering a few packets at a time). I'm sure there's probably some nice mathematical formula for the amount of transit time you'd add (from the time the key goes down to the time it's received by the host system) as a result of buffering out all the variation in the timing between packets
Ultimately though, I don't see any defense against an attack like this. If someone can compromise your hardware, particularly your input devices, you're quite screwed. I've always seen it as an extension of the 'local console root' rule: if someone can get to the CPU, then they have root. I guess we've got to extend this to keyboards, mice, and monitors as well: if you don't know where everything that you pass unencrypted information through was last night, maybe you shouldn't be using it.
Messing with the delay is only one of many ways that someone could sneak information out of an area -- it's neat, technically, but there are a lot of low-tech ways that would work just as well (including the audio recorder trick from a while back, where you can determine a typed password by listening to a recording of the keypresses).
If you only wanted a system that would work once, you could build a more powerful keystroke-recorder into a keyboard. Instead of having it mess with the delay, make it wake up the computer in the middle of the night (logging on -- it's not hard to grab your password on a Windows box, since it's nicely defined as the first thing you type after pressing Ctrl-Alt-Del and before return), and then executing a macro that emailed a recording of everything that had been typed recently to a dead-drop.
"Ladies and gentlemen, my killbot features Lotus Notes and a machine gun. It is the finest available."