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)
Re:Could you get around this... (Score:5, Interesting)
Re:Could you get around this... (Score:5, Funny)
Re:Could you get around this... (Score:2)
Usable by the god-fearing tech-illiterate masses? Yes. And that's what matters. What good is privacy if only geeks who have crosshairs on them sixty ways from Sunday when the Revolution comes (you can SMELL them in a crowd. Yech.) have it?
[OT]By the way, I hate grammar Nazi's periods, too. LOL.[/OT]
Re:Could you get around this... (Score:2)
The god-fearing, tech-illiterate masses seems to be quickly shrinking into a single group: corporate execs.
Guess who the revolution is being planned against.
Re:Could you get around this... (Score:2)
Re:Could you get around this... (Score:2)
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:3, Insightful)
Re:Could you get around this... (Score:3, Funny)
Why of course. Just let me jump in my flying car and go to the hypermarket on the moon, I hear robots are on sale there.
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.
Don't be silly ... (Score:3, Funny)
Oh, wait....
Re:Could you get around this... (Score:4, Interesting)
There is a similar concept in advanced TEMPEST [wikipedia.org], analysis but we cant talk about that here....
Re:Could you get around this... (Score:5, Informative)
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:Could you get around this... (Score:2)
Re:Could you get around this... (Score:3, Informative)
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 congest
Re:Could you get around this... (Score:5, Interesting)
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: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
Re:Could you get around this... (Score:2)
Tom
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.
Re:Could you get around this... (Score:2)
The keyboard would have to send its information by delaying packet transfer, so it'd have to have either software or add a connected intermediate to the ethernet cable. That's what's fishy about it.
Re:Could you get around this... (Score:2)
Yes, you can get around this (Score:5, Informative)
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:Yes, you can get around this (Score:3, Insightful)
Re:Could you get around this... (Score:2)
Yes, software is sufficient because it has to go through lots of software before it goes out on the Internet (of whereever it's going). If (e.g.) you add jitter in the OS interrupt handler, then the only part that would know about the original message is the CPU hardware and it can't really tell anyone by itself (unless asked to by software).
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:bullshit detector says hardly needed (Score:2)
[TMB]
Re:bullshit detector says hardly needed (Score:5, Insightful)
Re:Could you get around this... (Score:2)
Yes, that'd work.
As an alternative or supplemental approach, it'd also be useful to intersperse "chaffe" packets, i.e. garbage packets. Such chaffe packets could be inserted by a low level option in OpenBSD like you describe, or even by any link in the transmission chain, without application software even knowing abo
Re:Could you get around this... (Score:2)
Besides that, how are they sending the keypresses back to the server? Is there some unknown exploit in the PS/2 port we haven't found for ~15 years? If they've got the means on the victim's PC to send this information back in the first place they don't need special hardware at all.
Re:Could you get around this...Tech Fight. (Score:2, Informative)
Ever heard of a SNR?
Ender
Hmm... (Score:5, Funny)
Re:Hmm... (Score:2, Funny)
I think it's just as likely... (Score:2, Interesting)
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?
manufactured (Score:5, Insightful)
Re:manufactured (Score:2)
Re:manufactured (Score:3, Interesting)
On reflection, I don't see how it'd be so out of the question for some engineer somewhere to add in a delay in the firmware unbeknownst to the employer. All he'd have to do then is install some free shell and/or IRC machines somewhere, maybe some altered game servers, something like that, and wait for someone with his compromised keyboards to walk in.
Seems pretty straightforward, if you buy the initial premise that someone would do this. I don't see it working for a company. A person is
Re:manufactured (Score:2)
Re:manufactured (Score:5, Informative)
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:manufactured (Score:3, Informative)
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).
Manufactured into a keyboard (Score:5, Funny)
Re:Manufactured into a keyboard (Score:2)
it's your own damn fault (Score:5, Funny)
Re:it's your own damn fault (Score:2)
My question is... (Score:2, Interesting)
Re:My question is... (Score:2)
Re:My question is... (Score:3, Funny)
Re:My question is... (Score:2, Informative)
Now what was your question again?
Re:My question is... (Score:3, Informative)
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:Huh? (Score:2)
That's why you send the data multiple times. Even if you miss 10% of the data each time, if you send it 100 times, its likely you will receive it all. You could even add some sort of checksum so you would know when you receive it all.
Encryption latency, packet retransmissions upon collisions at routing equipement... there are 1000 reasons outside the
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:Very limited (Score:2)
I would not be so quick to say this. A sophisticated parasitic channel would be not constrained to only a single bit delay (no delay/unit delay). Finer-grained timing information could be used.
A thorough analysis of the SnR of such a time channel in a typical-internet-usage setting would be interesting.
And, if the controller in the kbd is only slightly intelligent (which should be no problem to mass-produce cheaply nowadays), it could repeat the transmission of
Re:Very limited (Score:2)
They do it but having a regular timer on the keylogger. From the usenix article, they pick a window, say 30ms, and you want to put in three values per stroke, 0, 1, "no transmission", with each value being at a 10ms point within the 30ms window. So when you type a key,
problems (Score:3, Informative)
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!).
Yeah... (Score:3, Interesting)
Undetectable data transfer is at least worrying, not the fact you can embed it in the keyboard. Also, external hardware devices can't be plugged in and execute arbitrary code, which means you require software installed, which can be detected. Not such an undetectable spy device now, is it?
Re:Yeah... (Score:2)
And what makes you think the internet cafe owner wouldn't just do this themselves?
I know a friend who used an internet cafe to do net banking, and the next day, they had $3000 transferred from their credit card to a mysterious account
Re:Yeah... (Score:2)
How about a stack of them at your next local computer show. "Free keyboard with any purchase over $40!" You'd take one. And so would I. And not think twice about it.
Well..maybe not now.
Re:Yeah... (Score:2)
A few years back a bank in some Israeli town was broken into.
The police were called but nothing seemed to have been stolen and they though nothing of it.
A few months later large amounts of cash started vanishing from accounts there.
It turned out that someone had broken in and installed a wireless access point.
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.
Trusted Input Device (Score:5, Funny)
This Trusted Input Device method, I call TID BITS, for short.
Re:Trusted Input Device (Score:2)
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.
Re:Interesting theory, but how likely in practice (Score:2)
There are some ways one can think of which would allow data transmission.
And AFAIK the keyboard controller in a typical PC keyboard only scans the keyboard 15 times per second which means that there is a natural regularity in the data already.
Re:Interesting theory, but how likely in practice (Score:2)
That's what I described, up to 90X for the over all keyboard clock, and another 90X for the additional delay. Of course you could type the character encoded as 1X right at the start of the cycle and hardly see any delay. Actually, thinking through it a bit harder, your overall max is really just 90X since if someone typed the key encoded as 89X right aft
Re:Interesting theory, but how likely in practice (Score:2)
Pre-programming the logger with the username would also be a good method. Of course you could always
password exposed via timing. (Score:5, Interesting)
"mickeymouse" m i c k e y mou s e
So thats why government keyboards cost $1000 (Score:2)
Nagle's algorhitm (Score:5, Informative)
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:Nagle's algorhitm (Score:2)
You'd be correct except that nagle doesn't really come into play these days except in unusal congestion situations or very long distance communication.
It used to be really important when you'd have busy servers that can barely keep csh responsive, or a hundred users sharing a 56K frame relay line. Nowadays the echo/ack comes back on each keystroke.
Re:Nagle's algorhitm (Score:2)
Woo! I'm immune (Score:2)
If you were masochistic, have password prompts randomly shift your keymap back and forth while entering your password...
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:Here's what scares me about this... (Score:2)
Should I worry about my HP Jitterbug Keyboard (Score:3, Funny)
5069-7601 TASC
-barcode-
ASSY-KBD JITTERBUG PS/2 US/PAPE
--- I guess it is time for HP to rename this sucker!
The...William...Shatner...Keyboard. (Score:4, Funny)
Each...word...gets...it's...own...sentence
At least stuff I type will appear more dramatic
Pah! (Score:3, Funny)
Finally... (Score:4, Funny)
Smaller cameras would be better too.
Lag from the JitterBug or from network latency? (Score:4, Interesting)
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)
Re:Cool, where can I get the source? (Score:2, Informative)
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:Cool, where can I get the source? (Score:3, Interesting)
I thought that it was easier and more reliable to just bribe somebody who has hte password. There was an article a while back that indicated that some people will divulge passwords for something as trivial as a latte' or chocolate -- the cost goes up from there.
Re:Cool, where can I get the source? (Score:2, Interesting)
I always thought it was easier to just torture somebody for the password?
Who needs torture when there is vodka? Also, if they're like me you have two passwords, one overwrites the hard disk
Re:Just spreading FUD (Score:3, Informative)
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:
I'm skeptical, too. (Score:3, Informative)
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
Re:Just spreading FUD (Score:3, Informative)
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:Just spreading FUD (Score:2)
I don't see how you can get around the other delays though, OS, memory, buffer, and CPU delays should all be neglible, but the TCP delays are going to blow your packet delayin
Re:Just spreading FUD (Score:2)
--- elided.example.com ping statistics ---
100 packets transmitted, 100 packets received, 0% packet loss
round-trip min/avg/max/stddev = 59.322/62.689/79.781/3.203 ms
These are ping times between me and a host that's about 175
Re:What about user -induced lag? (Score:3, Interesting)
I don't see that with varying the delay. (Score:2)
The keyboard would have to establish a standard delay for each packet and then lengthen/shorten that delay to indicate 0 or 1.
If you're doing a lot of typing (like I am right now on
If I start uploading a file or something else, then the system won't be able to transmit data during that process.
So,
Re:What about user -induced lag? (Score:2)
This wasn't described in the article, but I think it's the most feasible option described yet. We are no longer talking about a hacked keyboard, but rather some trojan software running on the computer that doesn't want to be detected. Considering the amount of network traffic compared to the number of keys a user types, I think there is more than enough space to hide a good bit of binary data. The user
Re:What about user -induced lag? (Score:2)
The article is talking about a keyboard that incorporates a keylogger. This keyloggers output is encoded somehow in specifically timed artificial delays between the actual physical keydown and kbd driver reporting a keydown. This delay is then apparent in every connection in which individual keystrokes are sent as soon as they're generated. I don't know how common these connections are, however. How they extract useful data from that I don't k
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.)
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?
Re:Look! Someone gave me a new keyboard! (Score:5, Funny)
Re:Scary! (Score:5, Funny)
Re:Scary! (Score:2, Funny)