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
Would love to see how exactly they implemented this ;)
/me heads off to go watch some MacGuyver/Stargate for ideas
On a more serious note though..
I always thought it was easier to just torture somebody for the password?
Okay, seriously.. is there any way that we could protect against this in hardware or software? This could be a little bit tricky. I'll let you know as soon as I come up with a solution!
Censorship is obscene. Patriotism is bigotry. Faith is a vice. Slashdot 2.0 sucks.
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*
"...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."
Translation: Can I foil the process of obtaining a signal by adding random noise? I don't know. Why don't you ask a HAM?
Assume 50 million keyboards are sold. There needs to be Many Many Hackers to decode so much stealth information. It is good though that the research had pointed valid security related points.
Chris ,
Php Programmers.
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.
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.
...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.
Why do people invent shit like this? So far as I'm concerned, this is just about as "useful" to society as the average trojan, worm or virus.
The higher the technology, the sharper that two-edged sword.
There's a way around that. Ah, damn! Now I have to shoot myself.
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.
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
For a lot of years, we ensured that we could decrypt traffic of a lot of 3rd world nations, no problems.
I sort of doubt those Swiss encryption equipment companies are still in business, but probably they took enough NSA/CIA money they don't much care.
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?
And when I'm on slashdot and I get headache pain, I take Sanhedrin, the headache medicine (those of you old enough will get the joke).
Similar to the upcoming US election results
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.
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!
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!
Here is a link to the project website (the paper is linked from there):
l
http://fuji.cis.upenn.edu/~gauravsh/jitterbug.htm
BTW, the channel output doesn't depend on the user typing pattern. The average delay added for each keystroke is of the order of 10 ms. The paper has more details. It will work with any application where there is causal relationship between keyboard and network activity (incl. SSH).
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.
http://video.google.com/videoplay?docid=-112322121 7782777472&q=Vista+Voice/
Error 2101: all your sig are belong to us
c'mon, snark this out a little. They can ignore whatever randomness by users timing of keystrokes, because the individual keys are mapped with their choice of random (not really random, just all the keys needs to be different so the whole deal just looks random, it's really not a good word for this) timing sequence. They can throw out everything BUT their own keys, ignore your random speed or slowness, but it's a *conjunction*, and because they hold the key they can read it. (this tagged keyboard is a mechanical form of a one time pad, which you can use in conjunction with gibberish on top of it, they ignore the speed difference gibberish that doesn't fit their expected patterns) They can still read the traffic no matter who is using the keyboard or how weirdly they type. Even adding delays wouldn't help, because they would see those and chunk them out too as irrelevant to the real traffic, and they'd HAVE to do that anyway.
Cute trick really. I guess you could sniff it, find their patterns, script something that mimics their patterns and transmits bullshit (pre determined by you, pages from a book or whatever), instead of the real stuff, by doing a substitution ciper using their data speed chunk signatures. If it was timely enough and not too stupid sounding (whatever your substitution was), they might even fall for it for quite a long time. You just have to make sure they see some of their expected patterns to keep them amused.
I can think of a few other ways to play with them on this (one of them is hysterically funny), but that's enough for now.
Many people don't seem to think this would work. However, it definitely will in the future if it doesn't now.
Most terminal connections transmit one character per typed letter. This would be true of an ssh connection.
The main objection seems to be that the attacker doesn't know the user's typing cadence. The keyboard itself can correct for typing cadence, delaying characters slightly to create slop that can be used to make cadence irrelevant. Human typists don't get much faster than 0.2 seconds per character. A few are slightly faster, but not much. So, the keyboard just needs to hold every keypress and release it on an even tenth of a second, modified by the key specific hundredths or thousandths of a second. So, 'a' = 0.n01 seconds, 'b' = 0.n02 seconds, 'c' = 0.n03 seconds, and so on. So, each packet will be emitted at 0.n?? seconds, where the ?? provides the key that the user pressed. If the time-to-packet is consistent to the thousandths of a second then the actual message can be hacked out of the character stream by solving a simple rot-n cipher.
This just takes a high precision timer in the keyboard. It's not tough to get something working that's accurate to ten-thousandths of a second.
A normal ping of my local gateway is consistent to ten-thousandths of a second right now.
It's just a matter of time before the packet transmission delay between hitting a key and sending the key out of the network card makes this type of attack possible, if it isn't already. The article's "1 bit" of information is just a proof of concept. It would certainly be possible to tack on 8 bits of information through packet delay, as machine speeds improve.
SSH claims that they are not vulnerable to the attack largely because of the cadence issue.
http://www.ssh.org/company/newsroom/article/204/
Their analysis is unimaginative. If SSH is not vulnerable now, it will be in the future. And it's not just vulnerable to password attacks. All information typed through the terminal would be hackable.
Fortunately, there are solutions, like re-randomizing the network traffic release time at the network card. Or, randomizing single-character packet release times in the ssh code.
Ah, and yes, I could walk into my local internet cafe or library and perform a quick keyboard switch without a problem. No one's watching. No one cares.
"So far as I'm concerned, this is just about as "useful" to society as the average trojan, worm or virus."
Sounds like someone lost too many times at corewars.
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.
Wake me up before you go-go
Don't leave me hanging on like a yo-yo
Wake me up before you go-go
I don't want to miss it when you hit that high
Wake me up before you go-go
'Cause I'm not plannin'' on going solo
Wake me up before you go-go
Take me dancing tonight
I wanna hit that high (yeah, yeah, baby)
(Jitterbug)
(Jitterbug)
Cuddle up, baby, move in tight
We'll go dancing tomorrow night
It's cold out there, but it's warm in bed
They can dance, we'll stay home instead
(Jitterbug)
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?
Thinking my keyboards are not cheep but verry well worn in.
The ones on the servers are like Das Keyboards. http://www.daskeyboard.com/ It keep most people off them. No letters to work with are left on them. I don't have a problem using it.
I find I type faster on Mechanical keyboards than membrane. My keyboards pay for self in a year. Normally if I see a new keyboard at my workstation first question who nicked my Mechanical keyboard they better return it now.
Ok I have not needed a new keyboard in over 10 years. One day I will have to upgrade and get one with windows keys.
I have been timed I lost over 30 words per min on a membrane keyboard compared to a new Mechanical and that is still 5 word per min slower than the ones I have broken in. They get a little softer with use. Not much but it does make a difference.
A good keyboard to me is like a good pair of boots. Feel and work the best just before it fails.
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.
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!
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
Dude? Time for your medication. Seriously.
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."
does each key have a unique jitter? Sounds like pulse code modulation.
"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
3i 1blame 4the 2user 4for 2not 4being 4more 7vigilant 1if 5this 2ever 5happened 2to 5me (2and 2it 5wouldn't) 3i 2wouldn't 5be 2blaming 4some 1"hacker" 4for 2my 4own 2lax 7security
31424 24471 52525 22532 52414 2427
Probably just pseudorandom. Ossifrage!
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?
This doesn't make you immune because the delays which would normally decode to QWERTY patterns could easily be shifted to any other standard layout. The keyboard would merely assigns a delay per key, not per letter, and it would be easy enough to program the decode software to try all layouts until readable text appears. Face it, you can't type jibberish forever.
If you want to be immune, use an IBM Model-M keyboard. Mine is already 20 years old and it still works like the day it was purchased.
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...
this was at USENIX Security '06, a week ago. Slashdot is slowwww.
Also, this only really works if you're using SSH or VNC or some interactive network application, and they have a lot of bugs to work out before it's feasible.
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.