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."
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!
I don't know about the source, but you can get the paper right here. It has a little more details than the article.
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:
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.
"You're right," Fisheye says. "I should have set it on 'whip' or 'chop.'"
Here is the paper. ;) so if someone want to read and report his conclusion that I can read next morning...
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
I have discovered a truly marvelous proof of killer sig, which this margin is too narrow to contain.
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!).
A slashdotter who didn't build his own computer is like a Jedi who didn't build his own lightsaber.
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.
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
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.
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?
- White Knight of the Order of Mihoshi Enthusiasts
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.
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
Bzzt Whir Click
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.
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.
Far be it from me to question the article, but I had been under the impression that Nagle's Algorithm 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, 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.
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).
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 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.