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."

Comments

Could you get around this...

[Saint Aardvark]

...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.

Re:Could you get around this...

[interiot]

There was a talk at the university I was at about the security measures on US government firewalls, for particularly secure computers. Covert timing channels are one clear class of things that a very security firewall needs to protect against (not just for JitterBugs... trojans/viruses could try to communicate this way as well), and they did just that... changed the timing of the packets at the firewall to try to prevent covert timing channels from being possible.

Re:Could you get around this...

[NemosomeN]

The more likely workaround would be devices you put between your keyboard and the computer. Easier? No. Cheaper? No. Marketable? Maybe.

Hmm...

[bcat24]

This threat, however far-fetched, seems particularly relevant in light of the U.S. government's decision in May to use computers built by Lenovo only for processing unclassified data. The Chinese government owns 28% of Lenovo, information that has sparked fears of espionage. As it turns out, numerous keyboards are also manufactured in China.

With Communist computer, keyboard spy on YOU!

manufactured

[Anonymous Coward]

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...

Manufactured into a keyboard

[Anonymous Coward]

The "Made in Nigeria" had me worried, but with a quality name like Sony on the keyboard, I decided not to worry.

password exposed via timing.

[Kaenneth]

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

Nagle's algorhitm

[vadim_t]

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.

It's 1AM, do you know where your keyboard is?

[Kadin2048]

Mod parent up. This was my immediate question as well, and I still haven't heard it answered.

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 ... I just can't think of it right now.

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.