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
Maybe it's a proof of concept, or thought exercise, but I think there would be many hurdles against actually using this. Such as:
- 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.
This Trusted Input Device method, I call TID BITS, for short.
This issue is a bit more complicated than you think.
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?
All the techniques ever used to make men moral have been themselves thoroughly immoral... (Nietzsche)
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.
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.)
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.
5069-7601 TASC
-barcode-
ASSY-KBD JITTERBUG PS/2 US/PAPE
--- I guess it is time for HP to rename this sucker!
Great...so...now...everything...I...type...will... look...like...William...Shatner...speaking...
Each...word...gets...it's...own...sentence
At least stuff I type will appear more dramatic
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
How much jitter has to be introduced into the packet stream to be detected as inserted delay and not network latency?
Pinging my own wireless router:
10 packets transmitted, 10 packets received, 0% packet loss
round-trip min/avg/max/stddev = 2.611/2.823/3.343/0.233 ms
--- google.com ping statistics ---
11 packets transmitted, 11 packets received, 0% packet loss
round-trip min/avg/max/stddev = 10.530/10.839/11.361/0.251 ms
--- yahoo.com ping statistics ---
10 packets transmitted, 10 packets received, 0% packet loss
round-trip min/avg/max/stddev = 61.703/65.211/68.176/2.781 ms
Maybe the sample size isn't big enough, but how does one differentiate inserted delays from network latency? If the difference between the keystroke and the packet is the modulated data, how do you get this information to a recipient with to reference to when the keystroke was pressed? Maybe there's some fancy signal processing involved similar to spread spectrum, but that's never been a strong suit.
(Asked by a network simpleton)
Government's idea of a balanced budget: take money from the right pocket to balance...oh who am I kidding?
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."