The Keyboard That Could Phone Home 287
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."
Could you get around this... (Score:5, Insightful)
manufactured (Score:5, Insightful)
Huh? (Score:5, Insightful)
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.
Re:Cool, where can I get the source? (Score:3, Insightful)
Often times it might be nice to get the password without the victim's knowledge that the password is compromised.
Re:What about user -induced lag? (Score:1, Insightful)
Very limited (Score:5, Insightful)
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
Re:Could you get around this... (Score:5, Insightful)
This is also another reason for 100% open source code for any important part (which you use to transfer confidential information) of your computer.
Especially for low-level parts like device drivers. Stallman wanted to have a free printer driver. Remember the yellow dots??
I hope this is something which makes the closed source WLAN (it's working, it's ok) fans
a bit quieter.
Re:Could you get around this... (Score:5, Insightful)
But really, this whole issue is stupid. Built into the keyboard? WTF? If you allow a hostile agent to install hardware in your computer, then having a keylogger is the least of your worries. Where's the alarmist article about the possibility of keyboards with built in hand grenades?
The system is also overcomplicated by far - for one, you are relying on people using telnet and remote desktop, which most home users do not. What advantages, if at all, does this tech hold over just modulating in delays with conventional traffic (e.g. HTTP requests)? Or other known systems of steganography? And don't forget that telnet is unencrypted in any case.
Seems like an unlikely scenario (Score:4, Insightful)
- Discerning keyboard delays vs. user typing delays.
- Discerning keyboard delays vs. network latency variability.
- Getting the user to connect to a remote host using a direct keyboard interface like telnet. The much more common WWW connections do not expose keyboard input speed, the input is sent as one big request (unless you run some java app, or possibly other active code in the browser).
- Compromising the network connection or destination host to expose the keyboard traffic.
I'd say there are a whole lot of more likely exploits that are higher on my list of things to look out for.
Re:{sigh} (Score:4, Insightful)
I was thinking about that myself. I'm no Luddite, but it seems to me the inexhorable march of advancement is fast outstripping any hope of catching up with social and cultural adaptation. Stuff like this makes me think "Why would anyone (legitimate) do this? Just to see if they could?" It seems like a stupid justification.
But then, isn't it stupendously better for this type of danger to show up in an academic paper, for all to see and think about how to counter, rather than spooks, foreign spooks, or some black hat with an attitude being able to use it surreptitiously for a long, long time because nobody else thought about it or publicized it?
Interesting theory, but how likely in practice (Score:5, Insightful)
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.
bullshit detector says hardly needed (Score:5, Insightful)
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.
Re:What about user -induced lag? (Score:4, Insightful)
There may be several schemes that would work, but here's the simplest one I can think of off the top of my head. Basically, you figure out what the maximum delay that can go unnoticed is, and you buffer keystrokes for that length of time. For example, if you determine that nobody ever notices when a keystroke is delayed 100 ms, you buffer keystrokes for that long.
Now, if during that period of time you get multiple keystrokes, then you spit the keystrokes out of your queue with a predefined timing. If you want to send a 0, you might send the first keystroke out, then wait 50 ms, then send the second. If you want to send out a 1, then you might wait 75 ms between the keystrokes. So basically, you get opportunistic about it. Only if you have two keystrokes in a short period of time do you try to encode data in the timing.
But of course there will be times when the user is typing slowly, and you don't get 2 or more keystrokes in a short interval, but you still have to send them out. The solution to that problem is easy: if you aren't trying to send a 0 or 1, just make sure you never send out any keystroke sooner than 100 ms after you sent the last one. Now you have a system where (at the remote end), if you see two packets arrive about 50 ms apart, that's a 0, and if you have two arrive about 75 ms apart, that's a 1, and if you have two arrive about 100 ms or more apart, that's no data (a no-op).
And of course you want all kinds of redundancy built in because the network and the TCP/IP stack and the operating system will add lots of noise and corruption to your covert data stream, so you'll have to piece it back together. But that's an easy enough problem provided you don't mind reducing the bandwidth even further than what it is already is.
Oh, speaking of bandwidth, you can probably encode more than one bit per keystroke pretty easily. Coincidentally enough, today I was observing network latency between two sites about 1000 miles apart, and I noticed that even though the latency was usually around 70 ms, the standard deviation seemed to be much lower, down around 2 or 3 ms. So in this case, depending on how much you want to delay things (you can't delay things so much that an average typist can outpace you!), you could use one of a set of several different delays between keystrokes. You might encode 3 bits by doing intervals spaced 5 ms apart. So, 50 ms for 000, 55 ms for 001, 60 ms for 010, 65 ms for 011, ..., 85 ms for 111,
and 110 ms for no-op. (Things get complicated, but I'm assuming
you'd want a bigger gap between no-op and the others since no-op
will occur very frequently.)
Here's what scares me about this... (Score:3, Insightful)
We now know that the government secretly had printer manufacturers embed hidden ID codes on printer's output [eff.org], thereby removing any possibility of anonymous document creation.
I wouldn't be surprised if some enterprising Bush-ite didn't see the possibility here of having *every* keyboard manufactured with some form of this technology embedded. Imagine if the government could tell what you were typing just by listening to your traffic.
Think of the terrorists we could stop! Think of the children!
Re:Could you get around this... (Score:3, Insightful)
Re:Yes, you can get around this (Score:3, Insightful)
bullshit (Score:2, Insightful)
they should market it as a replacement for tcp/ip for real time applications rather then a scriptkiddie wet dream's keyloger.
Re:Hmm... (Score:3, Insightful)
In freedom loving countries, keyboard KEEPS YOU SAFE!
Be afraid! Or the terrorists' goal to make us change our lives and live in terror will succeed!
Re:Hmm... (Score:3, Insightful)
Warrants or no warrants [eff.org], but as a patriot, I sure hope they use 100% American?
It's 1AM, do you know where your keyboard is? (Score:5, Insightful)
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.
Re:bullshit detector says hardly needed (Score:2, Insightful)
B) Some programs send packets interatively, on keypresses. As the article says, programs like SSH, and remote deskop.
So, if you design your transmission protocol to be resilient enough to handle the noise introduced by all the processing between the keypresses hitting the computer and the computer transmitting a packet, as long as the packet transmission is still tied to the keypresses, you could eventually transmit information along this 'channel'.
Now, the issue is just deciding which information to transmit.
You could easily just dump its entire buffer over and over.
Since this channel will probably be pretty slow, however, you might want to code "password detection" heuristics into your algorithm, so it can try to only send passwords, or at least send them first. A simple heuristic I thought of off the top of my head just now: A sequence of characters that does not form an actual word, but is repeated several times per day/week is probably either a password or a recurring typo. Send these sequences first.
Re:bullshit detector says hardly needed (Score:5, Insightful)
Re:Could you get around this... (Score:3, Insightful)
Yes. They're in the firmware of the printer, not the driver, so a free printer driver wouldn't make much difference in this case.
Re:It's 1AM, do you know where your keyboard is? (Score:3, Insightful)
An example.
Assume a user types a character on the average every 100ms.
If you could time to the ms then you could encode 2 secret bits on each packet by delaying the packet by 0,1,2 or 3 ms
Decoding the stream would be a simple matter of taking the sequence of delays and run mod4 on them.
If noise made this impractical (i.e. single-ms timing is impossible) then you could do the same thing by adding 0, 10, 20 or 30 ms delay to every packet, using delay mod 10 for decoding.
The delay you need to add is completely unrelated to the typing-speed of the user. It is related only to the accuracy with which you can cause and measure delay.
If the user pressed a single key once an hour, you could *still* delay that packet by 0, 10, 20 or 30ms and thus transport 2 "hidden" bits. The only assumption being that you can cause and measure delay accurately enough that you can detect which of the 4 happened.
The demise of the password on the horizon (Score:2, Insightful)
Lost your device? Just answer what your dog's name is (Cujo) or what you wanted to be when you grew up (Convenience store attendant, just like Apu).