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!
So I better go out tomorrow and buy myself another 100 Keyboards before its too late...they can see what you do!
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
My question is why are University of Pennsylvania researchers developing keyloggers!!??
Error 2101: all your sig are belong to us
I RTFA'd and I don't see how this would work with regular, semi-random typing -ie. I may 'sit on a character' while I space out or think about what to type next -or try to find the next key....
It seems that this could only work if there were a regularly timed stream of data -such as that of a TTY playing back a paper tape or someone who was Mavis Beacon Prime typing at a completely regular rate to which the 'jitter' could be added to. I don't *think* that most remote apps use any kind of buffer dumps or anything that would add the type of regularity that would allow this to be exploited.
That would leave out all of us one fingered-wonders. Feel free to correct me as I may have missed some subtle point of the article.
-What's the speed of Dark?
OK, so they can make a device that adds jitter to the time it takes from when I hit a key to when the computer knows I hit it. Great. Kudos to them for there nice bit of hackery. But, how exactly does that transmit any information to the outside world? 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. Sorry folks, but my typing rate just isn't that consistent. No, no, that's just an example, you say. The real trick is to embed this in the TCP/IP stack and add jitter to the outgoing packets. Again, nice try, but it's not going to work in the real world. All sorts of things both inside the computer (e.g., page swaps and single-threaded paths in the kernel) and outside of it (e.g. TCP congestion control and Ethernet exponential backoff for collision control) are going to have an effect on the timing of when packets leave the computer. Interesting in an academice lab, perhaps, but for the real world, schmeh.
i think my $10 walmart keyboard will do just fine for now..
*plays the Apogee theme song music*
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.
I don't know about the source, but you can get the paper right here. It has a little more details than the article.
If someone magically places a new keyboard on your desk, and you don't think something is amiss, you deserve what's coming to you.
Often times it might be nice to get the password without the victim's knowledge that the password is compromised.
...that US corporations would install these. The American government/corporations (same thing really) has clearly demonstrated their belief that people exist for them to prey upon.
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
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.
Seriously, wouldn't it need drivers to hook into the OS to access the network stack, at least for anything beyond Telnet and Remote Desktop (which, according to the article, sends "a packet ... every time a user presses a key"). Using the keyboard with webbrowsing or downloading seems safe, as far as I can understand (which, admittedly, may not be all that far :-) And if don't use Telnet or RD and use a bog-standard keyboard driver on Linux and you should be safe, right?
(Or just use a telnet or remote client that is progmatically de-jittered)
but, all of you thinking that your typing speed would influence the devices' output... couldn't the device just buffer up your keystrokes a little bit and then send them out timed the way they wanted. I don't know about you, but my hands have memorized many of my passwords and usually just send them out in a burst. If the device was buffering, say, 8-12 bytes at a time and then sending them out timed to perfection, I'd probably just chalk-up any delay that I noticed to normal network lag.
A keyboard keylogger? "Scary". I think not. It's not like these people are going to bust into internet cafe's, pick the lock and change the keyboard without anybody noticing. Nor are they going to do it to somebody's personal PC ("Hey, my keyboard's different. Oh well..."). The only market I see for this is for corporations, and they can either use a hardware dongle, or have a software keylogger. They can also run the user in a sandbox that prevents them from detecting the software one, and the software one probably has more power in it anyway.
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?
I'll subscribe to Slashdot when I see a month without a dupe, a typo, or an article the "editors" didn't read.
OK, thanks to someone else for digging up the real paper. It's actually quite interesting how they do it, and it makes sense. I encourage anyone who is interested to just avoid the article that was posted and read the paper instead. Much more intellectually satisfying...
I just get worked up by how much the press tries to fear monger these days and, given the increbile lack of detail there, assumed it was overblown. After reading the real paper, I have to admit that I was wrong.
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
"I always thought it was easier to just torture somebody for the password? "
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.
About the only way I can see this working is if the keyboard had a buffer. Not only to capture your keystrokes, but to also pass them to the application.
/.), then should be easy for the keyboard to set the timing.
... in very limited circumstances ... for very restricted input options.
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, this is a potential threat
Not to mention that the attacker has to have a sniffer between you and the first router on your network. Otherwise that router will be introducing its own delays and further scramble the timing.
Making a keyboard without any parts that were manufactured or assembled outside of the USA, is this even possible? What about a whole computer? How much do you think it would cost?
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.
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
DARPA and the NSA are devoutly, religiously paranoid about computers, and they dominate the funding of computer science research. I'm sure they think they stuff like this is important, regardless of whether it is or not.
On a more serious note though..
;)
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
Me failed English...
FreeBSD over Linux. If my comments seem odd, this may explain...
Score one for dvorak, my traffic is as secure from the keyboard as the ROT13 I use on the nework... Also for massive amounts of bittorrent traffic in my upstream queue effectively destroying any timing information between my keyboard and the outside world. QoS probably actually works to keep it more intact, but still...
If you were masochistic, have password prompts randomly shift your keymap back and forth while entering your password...
XML is like violence. If it doesn't solve the problem, use more.
The government of the USA has already shown a proclivity towards watching its citizens. To be fair, this phenomenon isn't limited to the USA, but Bush has taken it to new levels.
We now know that the government secretly had printer manufacturers embed hidden ID codes on printer's output, 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!
HeadOn - apply directly to the forehead
HeadOn - apply directly to the forehead
HeadOn - apply directly to the forehead
etc
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!
Real easy to detect. Just play DDR/StepMania in keyboard mode. If you fail all songs, either you suck, or your keyboard has been bugged.
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
A keyboard that phones home? I want a phone that lets me type at 120wpm. Now that would be impressive ^^
When the posters fear their moderators, there is tyranny; when the moderators fears the posters, there is liberty.
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.
Any sandboxed enviroment would have access to both the keyboard with short delays and at least the originating host. With a hidden channel between the keyboard and the running program, keypressed from outside of the sandbox could be sent. Activex, java, flash and possiably other web apps could be used to dump the keyboard contents with much closer timing tollarances, then encrypt and dump to remote host without any indication the user could detect.
I think I just cashed out all my cool points.
Adding noise doesn't prevent timing channels, it only reduces their bandwidth. With error-correcting encoding and multiple sends, timing channels can defeat most "noise" based solutions. Actually, they might even add noise themselves to hide within.
Even if the bandwidth is reduced to only 8 bits a day, useful information can still leak out
Also: don't assume a timing channel in a keyboard would send the current keypress. It would send the relevant one (over time)
How hard would it be for a manufacturer to install something like this Key Katcher! into a keyboard?
Today's show is brought to you by the number 09 F9 11 02 9D 74 E3 5B D8 41 56 C5 63 56 88 C0: 25
. . .not to buy a new keyboard.Ever.
Klingon Software is not released, it escapes, inflicting terrible damage onto the enemy as it does
let's assume microsseconds delays in packets to transfer data. riiiiiiiiight...
they should market it as a replacement for tcp/ip for real time applications rather then a scriptkiddie wet dream's keyloger.
It's the trust and accountability we have in companies that keeps this from happening in general.
Yeah, I know someone who swears that there is a camera in the remote sensor on cable TV boxes.
While I figure it would take all of a day before someone figures out that the boxes have a camera in them, my main argument to him rested in the fact of what would happen to a company if it turned out every cable box they made had a camera in it.
You know what, I think it goes beyond just having a bankrupt company and stock worth less than the price of some SCO stock (if that's mathmatically possible)...I think people would hunt down the upper management of the company and kill them.
Of course, AT&T execs are still alive...
Transporter_ii
Doctors destroy health, lawyers destroy justice, universities destroy knowledge, religion destroys spirituality
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?
*beep*
SARCASM ALERT
You could always just transmit data secretly by controlling electromagnetic emanations of computers. Lets see a firewall stop that.
Yes, I do remember "mainframes" - I was in charge of about $3M worth of computing equipment, back in "the day", but I would guess my household computers surpass all that now. (Of course a VAX cost about $200K back then... Not a VAX III, mind you.)
Just because I once had a job that involved loading many cases of punched cards into a computer doesn't mean I didn't know it was antiquated then! :-)
(I was in the last class at a University of California school that required punch-card input. Of course, working in the computer center, I was able to use an interactive CRT workstation, then simply send my debugged program to the cardpunch... I had time to spare, and harass the poor souls who had to punch their cards manually, submit the deck, check for results, rinse lather and repeat, as it were. Heh.)
But still - I am over 40, but less than 50. Not that old. (I haven't had my slide rule out in ages!)
This issue is a bit more complicated than you think.
I always thought it was easier to just torture somebody for the password?
...but in the United States, we call it The Waterboard Attack. Not so funny.
I love cryptologists. This is technically known as the rubber hose attack, I believe. Seriously, how awesome is that? Don't you immediately envision someone being thwacked with a rubber hose? Excellent.
DDR/StepMania isn't sensitive enough to catch this, I think. Yes, it's friggin' accurate, but probably not to less than a 10th of a second.
Don't thank God, thank a doctor!
The noise level does not matter if you collect enough samples. I mean, that was freaking high-school physics' material in my day.
But you probably got better PE and sex-ed instead...
Obama likes poor people so much, he wants to make more of them.
frovingslosh proclaimed, "People add their own imperceptable delays to keypresses, ... ." Yes, but the keyboard (or whatever) does not have to send the characters at the same instant they are typed. It can wait for the next multiple of some fraction of a second - e.g. .25sec - and then add its delays to those now-regularized instants in time. As long as the 'encoding' occasionally induces no delay, the listener can get synched up with the sender. It's not a problem if some instants are skipped. It is not a problem if the typist manages a burst that exceeds the maximum rate, as characters sent between the regularized instants would not have to carry information. (Actually, the 'regularization' does not even have to be uniform as long as it is predictable.)
Why would the US Government need to worry about this? It's not like most departments and branches buy all of their PC components manufacturered in China or anything...
Oh, wait....
Mooniacs for iOS and Android
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."
I think that may be -exactly- why to continue research into security academically. There are people out there with a very real and practical (to them) urge to research this stuff: in order to use it against their perceived enemies. Pick a religious, ethnic, political, or racial minority OR majority, poor people, rich people, business people, you, me, everyone who buys a computer in a certain region, bugged hardware for export, foreign nationals and diplomats... The list goes on.
It's better to have the flaws in our major systems exposed on a public level so that we can develop countermeasures, then it is to let the _real_ "bad guys" use it against us, the public.
I don't know about you, but I cannot and will not stand for it. Nobody has the right to spy on me, or you, or anybody else. NOBODY. I don't care if it's for "legal" purposes or not.
Laws are written to make criminals, not good citizens.
"network-intensive apps like telnet"
eh? Since when is telnet network-intensive?
Here's a simple way to do it:
- let N be the number of characters in the alphabet you care about (say, 75: letters, numbers, and common punctuation)
- let M be the smallest resolution at which you can reliably time the packet differences (eg, 1ms)
- let P be the period represented by the time M*N
- when you want to transmit a key, map it into your alphabet as X where 1<X<=N
- no matter how much time has elapsed since the last packet, delay the next packet to (next multiple of P) + X.
To decode: take the time difference between packets, modulo P, and you get X.
You can enhance this system by using escape codes. Ordinary network traffic could proceed unmolested when you're not typing, but once you start typing a recognizable escape sequence is issued (coded into packet delays, of course) which kicks you over into keyboard mode, and another kicks you back out once typing has stopped.
The attacker gets extra bonus points if s/he includes an error-correcting checksum in the data stream (again, coded into packet delays) to make it more robust.
And that's why my keyboard has an ethernet connector!
Damn!
Donde Ser Geek No Duele
Given the delays you specify, I can easily imbed the message 1011 in your traffic. I do this by ensuring that every 1-bit in my message corresponds to an interval that ends in 5 and every 0-bit corresponds to an interval that ends in 0. So, given your input sequence (100,110,90,40), I delay the keystrokes to produce the sequence (105,110,95,45). This only requires that the network variance be less than 5ms.
I only skimmed the research paper, but this appears to be exactly what they propose as well. In particular, I think it's telling that they transmitted a secret message across the planet using their mechanism (using a 20ms window instead of the 5ms I used in my example).
If they would want to listen to reliable packet intervals it should be at the first hop. If they could compromise the first hop would they still bother to use this timing interval technique?
Lost your device? Just answer what your dog's name is (Cujo) or what you wanted to be when you grew up (Convenience store attendant, just like Apu).
...and that's what projects like LinuxBIOS and The Open Graphics Project are for!
"[Regarding the 'cloud,'] ownership was what made America different than Russia." -- Woz
I remembered that some researchers had done this before (http://www.freedom-to-tinker.com/?p=893) and it was a lot easier than replacing the keyboard. The basic idea is that all keybaords have unique sounds, and if you can interpret those sounds, then something like 90% of the keypresses can be determined by just simply listening (and if you use lasers, you don't even need to enter the room, as long as it has a window, and you have line of sight.
Okay, there appears to be alot of confusion on how this works. It does NOT work on a packet per keypress basis. Essentially the whole idea is to mask the fact that there IS a keylogger on your system (whether software or built into your keyboard) by not creating additional network traffic. So the keylogger records keystrokes individually, but then during normal network traffic created by whatever is running on your system, web browsing, servers, etc. the network driver, which must also be compromised, will modulate keystroke information onto your standard traffic. The fact that your ssh session, or computer login is long over has no bearing on the matter... they keylogger recorded the information and transmits it over a period of time. What makes this more devious is that it doesn't have to be sent to any predetermined IP. The receiver simply needs to be able to listen to your outgoing traffic. So of course this isn't going to be transmitting your passwords over the internet in general... but it will let somebody in say your local network or ISP record your keystrokes. Protection? Use network drivers you can trust. I'm ignorant on how safe signed drivers are. Open source drivers may be safer simply because someone would notice weird code in there.
Comment removed based on user account deletion
Because probably 99.99% of the internet traffic goes though various kinds of traffic shapers, meaning that outgoing packets are rescheduled and all timing info is lost.
Cool idea, though...
Well, that's the real problem. Using the older technology requires a lot of time and effort and some activity by a human being trying to detect what is being typed. The evil phone home nature, along with the automated nature, of the device makes it trivial for someone to obtain a bunch of data on tons of people. This would not be possible in an earlier time since so much more human time and human effort would be required.
Similar to the upcoming US election results
The latte' bribe survey was done by somebody who was working for the company who's passwords were compromised, and most of the passwords were found to be valid. If somebody would offer me something to divulge a password, I would refused the offer; also, the triviality of this bribe would have raised serious alarm bells with me. Some people have enough integrity and are not desperate enough to lie.
In practice, I would imagine that the bribe for a useful Login/Password would be a bit more substantial, and that if the Login/Password were not valid, that the person who took the bribe would be made to realize that welshing on a bribe is not a good choice to make.
I don't get the threat. If your premise is that the user's hardware is compromised, then the fact that it's the keyboard, doesn't seem to make things much worse.
Scenario: FBI agents or the mafia breaks into your home and replaces your IBM model M keyboard with a new keyboard that includes this misfeature. You just happen to not notice. ;-) The keyboard logs and transmits your KDE wallet password. They later break into your home again, use the wallet password that they have discovered to look up your bank password, and drain your account. Ok, that's not good. What the new keyboard contributes above and beyond a conventional bug, is that the password was transmitted covertly, instead of over a radio to the van outside. I guess that's a "cool" misfeature, but if you have people breaking into your home all the time, you probably don't detect non-covert channels either.
Scenario: "internet cafe" or library installs these. This scenario is a joke, because they can install whatever the hell they want on the machines at the software level, and the users will never know. The users don't have any way to detect non-covert channels anyway. This new keyboard makes no difference at all, in any scenario where a user is not using his own trusted computer.
Scenario: laws are passed requiring all keyboards to have this misfeature. After a few decades, almost everyone has one, so anyone can snoop on anyone without the initial installation break-in. They just have to break into your house one time, to use the intercepted KDE wallet password to unlock all your other passwords. Yeah, ok, I see a problem here. But if the premise is that attackers get to pass laws requiring everyone's computer be compromised, then things are pretty hopeless anyway, and this keyboard is just one of dozens of bugs lurking in your machine.
I'm not saying there aren't some new threats here, but they're pretty minor compared to the premises that enable them.
As copyright owner of this comment, I authorize everyone to defeat any technological measure which limits access to it.
(Dons tinfoil hat & earplugs and strides away into the sunset...)
There's this company which makes little only-physically-detectable (the computer has no idea, and no means of detection) PS/2 connectors with keylogging capabilities and built-in RAM for storage: http://www.keelog.com/
They even sell kits to make your own if you're too much of a tightwad to pay for a pre-built one!
--A
[BEGIN PGP PUBLIC KEY]: X5O!P%@AP[4\PZX54(P^)7CC)7}$EICAR-STANDARD-ANTIVI
Get your free Microsoft keyboards right here ladies and gents. Guaranteed to have no strings attached. They even have special security chips installed to... um... make the internet go faster. Yeah thats it. They make the internet go faster.
Having to work for a living is the root of all evil.
Grandparent hasn't thought things through thoroughly enough - anti-drew gives a clear way to do what the GP says can't be done.