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

Re:Could you get around this...

[wall0159]

Well, probably. But what you're doing is just adding noise to the system - this can be circumvented by just taking longer to send the time-based data (ie send the data with greater redundancy, so that it's more noise tolerant). Also, adding jitter would slow the network connection because you can't make transmission faster, you can only slow it by the mean delay of your introduced noise.

A more effective method would be to use a method of transmission that wasn't time-dependent on what the user typed. For example, ssh could be designed so that it sent a packet every 100ms (whatever - I don't know the specific time) regardless of what the user had typed. I think this would render this attack useless, but would still introduce some latency...

The article says 'In applications such as telnet and remote desktop, a packet is sent every time a user presses a key' - is this the case with ssh too? I mean - surely *nobody* uses telnet for secure communications!

Re:Cool, where can I get the source?

[dyamkovoy]

I don't know about the source, but you can get the paper right here [usenix.org]. It has a little more details than the article.

Re:Just spreading FUD

[drinkypoo]

Again, nice try, but it's not going to work in the real world.

On the other hand, they performed a test, and it seems to have worked. No details on the test but you would really have to go through a lot of effort to be sure that in fact you had a good network connection and a steady typing cadence, and the test was between countries. FTFA:

Researchers say that in tests, the JitterBug was able to transmit data from the University of Pennsylvania to the National University of Singapore fairly reliably.

Provided there is sufficient traffic, who cares if you have a high error rate? Use error correction.

Ordinarily I would raise the same objections, but I read the fine article, and am willing to accept that some people may be a lot smarter than I am, while it is patently obvious that some people are a lot better-educated.

I'm skeptical, too.

[alexhs]

Here [usenix.org] is the paper.
A "Keyboards and Covert Channels" search on Google will give you the PDF, too.
I don't have time to read it right now (time to sleep here in France ;) so if someone want to read and report his conclusion that I can read next morning...

problems

[Lord Ender]

If you're going through a router with any kind of load, it will add unpredictable delays of its own.

Any crypto that relies on the timing of packets is going to have this problem, because IP makes no promises about packet timing (or even order!).

Re:Just spreading FUD

[AHumbleOpinion]

In order to read information out of my delayed key strokes, you'd have to know the cadence that I'd normally be typing at and then measure the deltas to get the bits.

No, I don't think so. I am just making a guess, I have not read the article, but I think a simple "rounding" of your cadence would be enough. Pick a small time interval, round your actual timing to the nearest interval, done. For discussion purposes let's say the interval is 0.1s, encode a 0 bit as x.x3s and a 1 bit as x.x6s.

Re:manufactured

[steve_l]

yeah, laptops could implement this in the keyboard controller. Or even the USB hub could do it.

you have to trust the pc vendors, as they have nothing to gain, and everything to lose, in lawsuits and lost sales. But what if their government comes along and says 'add this back door'. They'd comply.

Case in point: Lotus notes put a back door in export versions of notes:
http://catless.ncl.ac.uk/Risks/19.52.html#subj1 [ncl.ac.uk]

they sent messages with 64 bit encryption (!), but 24 bits of the key was hidden in the message, where the NSA knew to look, or otherwise given to them. You only had 40 bit keys, which upset the swedish government.

Moral: You cant trust closed source apps any more than closed source hardware.

Re:My question is...

[Firefly1]

If it's a choice between UP researchers developing this and educating relevant entities to the potential threat (and, of course, said entities taking prompt and appropriate action), and blackhats fielding it unbenownst to the world at large...
Now what was your question again?

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.

Re:Could you get around this...Tech Fight.

[ender_]

If the noise is of the same or greater order of magnitude then the signal. Yes, you can foil the process.

Ever heard of a SNR?

Ender

Yes, you can get around this

[sacrilicious]

No, you can't get around this, because if it's built into the keyboard, then it's a hardware thing, and any software based solution will be insufficient.

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.

Re:My question is...

[EvanED]

For the same reason that security researchers do any of their destructive research; the same reason that I'm just starting to study how to build a rootkit. People need to know what risk factors are present in decisions they make with regards to hardware, software, and configuration choices, and how to protect against those risk factors. If there were no white hat hackers, the black hats would ALWAYS be a step ahead because the white hats wouldn't be able to anticipate possible other attacks.

Re:Could you get around this...

[charleschuck]

The article says 'In applications such as telnet and remote desktop, a packet is sent every time a user presses a key' - is this the case with ssh too?

Far be it from me to question the article, but I had been under the impression that Nagle's Algorithm [wikipedia.org] had been designed to concatenate small buffers—such as telnet—to prevent them from necessarily sending a packet with each keypress.

I am not a TCP stack guru (IANATCPSG?!), but it seems like, though this algorithm was designed to reduce congestion, it would upset a timing attack by having to wait for the ACK of the last packet—at least on high latency links.

SSH, at least as of 2002, according to this e-mail [netbsd.org], turns on TCP_NODELAY, which disables the algorithm to reduce latency of keypresses in a connection when it believes an interactive session has been started. Thus, SSH does indeed send a packet with each keypress.

Re:manufactured

[forgotten_my_nick]

It wasn't so much a backdoor but as a way to comply with the export regulations at that time. You couldn't export 128bit encryption at that time but they could if NSA where given half the key.

But this isn't just US doing this. France for example around that time only allowed 40bit keys to be used and Lotus had to comply with that too.

Btw, Lotus have long since stopped doing this once it was legal to do so. (hence you post relates to 1997).

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

[Anonymous Coward]

Hard to see how this is possible? Then just read the paper here http://www.usenix.org/events/sec06/tech/shah/shah_ html/jbug-Usenix06.html [usenix.org] and stop dismissing the idea on the basis of a secondhand report.

The delay between the user's key presses is irrelevant, the JitterBug will adjust the delay since the last key press so that, for example, the delay is a multiple of 20ms, or a multiple of 10ms but not 20ms. This gives you the "1" or "0" bits with 10ms separation for noise reduction and it doesn't depend on the user's typing speed, only on the value of delay modulo 20ms.