Become a fan of Slashdot on Facebook

 


Forgot your password?
Close
typodupeerror
×

The Keyboard That Could Phone Home 287

Posted by ScuttleMonkey from the blueprints-coming-to-a-torrent-near-you dept.
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."
This discussion has been archived. No new comments can be posted.

The Keyboard That Could Phone Home More

The Keyboard That Could Phone Home

Comments Filter:

  • Could you get around this... (Score:5, Insightful)

    by Saint Aardvark ( 159009 ) * on Tuesday August 08, 2006 @07:22PM (#15870529) Homepage Journal
    ...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.

    • Re:Could you get around this... (Score:5, Interesting)

      by interiot ( 50685 ) on Tuesday August 08, 2006 @07:32PM (#15870584) Homepage
      There was a talk at the university I was at about the security measures on US government firewalls, for particularly secure computers. Covert timing channels [wikipedia.org] are one clear class of things that a very security firewall needs to protect against (not just for JitterBugs... trojans/viruses could try to communicate this way as well), and they did just that... changed the timing of the packets at the firewall to try to prevent covert timing channels from being possible.

    • Re:Could you get around this... (Score:4, Interesting)

      by russ1337 ( 938915 ) on Tuesday August 08, 2006 @07:34PM (#15870603)
      If the information is contained in the 'gaps' between the traffic, buffer the traffic in hardware as it leaves the system. (Buffering and clocking the keypresses in hardware to remove the jitter may cause a percieveble lag). If the keyboard is the suspected source of the hidden jitter, then an inline clocked buffer could remove this, releasing the keypresses to the system at a uniform interval. If the system is suspected, buffering and clocking can be added at the system router.

      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)

      by wall0159 ( 881759 ) on Tuesday August 08, 2006 @07:34PM (#15870608)
      Well, probably. But what you're doing is just adding noise to the system - this can be circumvented by just taking longer to send the time-based data (ie send the data with greater redundancy, so that it's more noise tolerant). Also, adding jitter would slow the network connection because you can't make transmission faster, you can only slow it by the mean delay of your introduced noise.

      A more effective method would be to use a method of transmission that wasn't time-dependent on what the user typed. For example, ssh could be designed so that it sent a packet every 100ms (whatever - I don't know the specific time) regardless of what the user had typed. I think this would render this attack useless, but would still introduce some latency...

      The article says 'In applications such as telnet and remote desktop, a packet is sent every time a user presses a key' - is this the case with ssh too? I mean - surely *nobody* uses telnet for secure communications!
      • is this the case with ssh too?
        In the login/password, no, that is buffered and sent all at once after you hit enter. Within the session, it's possible, individual characters are transmitted as you type. But I think the encryption and other overhead makes this more difficult than the researchers presume. See my post below for more details.

      • 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?

        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)

      by LincolnQ ( 648660 ) on Tuesday August 08, 2006 @07:42PM (#15870660)
      The thing I don't get is how you distinguish the miniscule delay introduced with this system from the much larger delay between subsequent keypresses the user makes. I don't think most people type at such a consistent rate that you could plug this in and immediately start observing traffic. (I wouldn't be too surprised if you could do it after observing the person's typing habits for a long time... but that would be different for every person, so most likely impractical.)
      • Mod parent up. This was my immediate question as well, and I still haven't heard it answered.

        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 ... I just can't think of it right now.

        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.
        • That's not nessecarily true, it depends on the preciseness of your timing, and the aditionally introduced jitter that you cannot control.

          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

    • Naggle would like to speak with you.

      Tom

    • Re:Could you get around this... (Score:5, Insightful)

      by FhnuZoag ( 875558 ) on Tuesday August 08, 2006 @08:00PM (#15870750)
      No, you can't get around this, because if it's built into the keyboard, then it's a hardware thing, and any software based solution will be insufficient.

      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.
      • Most home users aren't interesting enough to be targetted by keyloggers. :)

        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.
      • The US government was going to buy PCs for use on a secure network from a Chinese company until they scrapped the deal over security issues. Many people accused the US of being alarmist over that, but here we see exactly how keyloggers etc could be shipped with PCs undetectable.

      • Yes, you can get around this (Score:5, Informative)

        by sacrilicious ( 316896 ) <qbgfynfu.opt@recursor.net> on Tuesday August 08, 2006 @08:53PM (#15870952) Homepage
        No, you can't get around this, because if it's built into the keyboard, then it's a hardware thing, and any software based solution will be insufficient.

        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.

      • No, you can't get around this, because if it's built into the keyboard, then it's a hardware thing, and any software based solution will be insufficient.

        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)

      by frovingslosh ( 582462 ) on Tuesday August 08, 2006 @08:24PM (#15870852)
      Sure, you could add your own jitter, but it's not really needed. My bullshit detector went off right as I hit the text reading "adding imperceptible delays to keypresses as people". Come on! People add their own imperceptable delays to keypresses, particularly when typing passwords. Other system and network activity adds timing discrepencies to packets that would mask this "jitter". And in most cases when a password is sent, it is sent in a packet, not as individual packets for each character, meaning that the keyboard can't really influence the between letter spacing at all. Plus the keyboard has no comprehension of what is going on upon the screen, it has no way to know if what is being typed is a password or not, so there is no way it can detect and specially encode passwords, it would have to somehow influence the system in a way that allowed it to encode every single keypress as this magic keypress jitter. Because of other packet "jitter" already affecting traffic, I don't believe it could even work if robots were doing all the typing, but certainly not for humanas.

      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.

      • You're mistaking the data that is being clandestinely communicated (the password) and the data stream that it's being hidden in (an ssh/telnet session). The fact that the password is transmitted in one packet is independent of the packets of the ssh session in which that data is secretely transmitted.

        [TMB]
    • Could you get around this 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. [ Reply to This

      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

    • Random jitter? What, like an Internet connection?

      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.

  • Hmm... (Score:5, Funny)

    by bcat24 ( 914105 ) on Tuesday August 08, 2006 @07:23PM (#15870534) Homepage Journal
    This threat, however far-fetched, seems particularly relevant in light of the U.S. government's decision in May to use computers built by Lenovo only for processing unclassified data. The Chinese government owns 28% of Lenovo, information that has sparked fears of espionage. As it turns out, numerous keyboards are also manufactured in China.
    With Communist computer, keyboard spy on YOU!

    • Re:Hmm... (Score:2, Funny)

      by madcow_bg ( 969477 )
      In Russia, YOU spy on the keyboard!

    • I think it's just as likely... (Score:2, Interesting)

      by Anonymous Coward
      ...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.

    • Re:Hmm... (Score:3, Insightful)

      by coaxial ( 28297 )
      With Communist computer, keyboard spy on YOU!

      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)

      by megaditto ( 982598 )
      Hey, I wonder if NSA/AT&T used Chinese boxes to wiretap citizens?

      Warrants or no warrants [eff.org], but as a patriot, I sure hope they use 100% American?

  • manufactured (Score:5, Insightful)

    by Anonymous Coward on Tuesday August 08, 2006 @07:24PM (#15870542)
    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...
    • Yeah, but if you're dealing with classified information, you have to be paranoid.

    • Re:manufactured (Score:3, Interesting)

      by bunions ( 970377 )
      meh, maybe sorta.

      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
    • Couldn't any kind of virus or malicious "software" be manufactured in to many different hardware.
      I think the real trick here is in *covertly* transmitting the captured information. A virus that simply establishes a TCP connection to some server in russia WILL be detected; this thing may not. Of course, to do this packet timing analysis you have to "own" a router that's carrying the encrypted information, which is somewhat limiting.

    • Re:manufactured (Score:5, Informative)

      by steve_l ( 109732 ) on Tuesday August 08, 2006 @07:50PM (#15870701) Homepage
      yeah, laptops could implement this in the keyboard controller. Or even the USB hub could do it.

      you have to trust the pc vendors, as they have nothing to gain, and everything to lose, in lawsuits and lost sales. But what if their government comes along and says 'add this back door'. They'd comply.

      Case in point: Lotus notes put a back door in export versions of notes:
      http://catless.ncl.ac.uk/Risks/19.52.html#subj1 [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.
      • It wasn't so much a backdoor but as a way to comply with the export regulations at that time. You couldn't export 128bit encryption at that time but they could if NSA where given half the key.

        But this isn't just US doing this. France for example around that time only allowed 40bit keys to be used and Lotus had to comply with that too.

        Btw, Lotus have long since stopped doing this once it was legal to do so. (hence you post relates to 1997).

  • Manufactured into a keyboard (Score:5, Funny)

    by Anonymous Coward on Tuesday August 08, 2006 @07:24PM (#15870546)
    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

  • My question is... (Score:2, Interesting)

    by jarg0n ( 882275 )
    My question is why are University of Pennsylvania researchers developing keyloggers!!??
    • Maybe Senator Spector got them an NSA contract.
    • To catch students logging into termpapersfor10dollars.com

    • Re:My question is... (Score:2, Informative)

      by Firefly1 ( 251590 )
      If it's a choice between UP researchers developing this and educating relevant entities to the potential threat (and, of course, said entities taking prompt and appropriate action), and blackhats fielding it unbenownst to the world at large...
      Now what was your question again?

    • Re:My question is... (Score:3, Informative)

      by EvanED ( 569694 )
      For the same reason that security researchers do any of their destructive research; the same reason that I'm just starting to study how to build a rootkit. People need to know what risk factors are present in decisions they make with regards to hardware, software, and configuration choices, and how to protect against those risk factors. If there were no white hat hackers, the black hats would ALWAYS be a step ahead because the white hats wouldn't be able to anticipate possible other attacks.

  • Huh? (Score:5, Insightful)

    by tgd ( 2822 ) on Tuesday August 08, 2006 @07:34PM (#15870609)
    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.
    • 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.

      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)

    by stienman ( 51024 ) <adavis&ubasics,com> on Tuesday August 08, 2006 @07:43PM (#15870665) Homepage Journal
    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

    • 1) It can, at best, transmit 1 bit per keypress

      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

    • 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.

      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)

    by Lord Ender ( 156273 ) on Tuesday August 08, 2006 @07:44PM (#15870669) Homepage
    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!).

  • Yeah... (Score:3, Interesting)

    by Kawahee ( 901497 ) on Tuesday August 08, 2006 @07:58PM (#15870745) Homepage Journal
    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?
    • > 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.

      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
    • 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...").

      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.
    • It's not like these people are going to bust into internet cafe's, pick the lock and change the keyboard without anybody noticing.

      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)

    by tji ( 74570 ) on Tuesday August 08, 2006 @08:01PM (#15870754)
    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.

  • Trusted Input Device (Score:5, Funny)

    by NotQuiteReal ( 608241 ) on Tuesday August 08, 2006 @08:01PM (#15870756) Journal
    I don't trust anything that I didn't key into the front panel switches [depaul.edu] myself.

    This Trusted Input Device method, I call TID BITS, for short.

    • Ah, 40+ years ago I used to work on Honeywell computers. To start one up you would first clear memory by setting 15 00 00 00 01 into the switches on the front pannel and pushing the go button. Those funny numbers translated into LCA 0000 0001, that is copy memory address 0001 to 0000, and continue copying. This would run around and around all 2k of memory and when you got tired of that you would press the stop button. Now why can I remember that sequence and not the grammar for an http link? (Oh yes, w

  • Interesting theory, but how likely in practice (Score:5, Insightful)

    by bhmit1 ( 2270 ) on Tuesday August 08, 2006 @08:03PM (#15870771) Homepage
    SSH already went through the debate of timing style attacks and came out fine: http://www.ssh.org/company/newsroom/article/204/ [ssh.org]. 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.
    • How about clocking the keys out of the keyboard in a regular manner (even if they are typed irregularly) and then adding the delay for the information?
      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.

      • How about clocking the keys out of the keyboard in a regular manner (even if they are typed irregularly) and then adding the delay for the information?

        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

  • password exposed via timing. (Score:5, Interesting)

    by Kaenneth ( 82978 ) on Tuesday August 08, 2006 @08:07PM (#15870778) Journal
    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
  • 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?

  • Nagle's algorhitm (Score:5, Informative)

    by vadim_t ( 324782 ) on Tuesday August 08, 2006 @08:21PM (#15870844) Homepage
    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.
    • Just enable (as it's usually disabled for things like SSH) Nagle's algorhitm, and it should destroy most of the timing information.


      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.
      • If your server is right nearby, sure. The best ping times I get for anything on the Internet is 100ms, and 200-300ms is a lot more usual. I can easily type fast enough so that it comes into play.
  • 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...

  • Here's what scares me about this... (Score:3, Insightful)

    by spagetti_code ( 773137 ) on Tuesday August 08, 2006 @08:48PM (#15870928)
    The government of the USA has already shown a proclivity [usatoday.com] towards [wired.com] watching [infowars.net] its [zmag.org] citizens [eff.org]. To be fair, this phenomenon isn't [geek.com] limited [silicon.com] to [spy.org.uk] 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 [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!

  • Should I worry about my HP Jitterbug Keyboard (Score:3, Funny)

    by rodion_schlatzski ( 994069 ) on Tuesday August 08, 2006 @08:57PM (#15870964)
    A power supply problem zapped my HP Keyboard and the replacement arrived about 10 minutes ago. A lable on the outside reads:

    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)

    by darnok ( 650458 ) on Tuesday August 08, 2006 @09:09PM (#15871028)
    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

  • Pah! (Score:3, Funny)

    by stunt_penguin ( 906223 ) on Tuesday August 08, 2006 @09:11PM (#15871036)
    A keyboard that phones home? I want a phone that lets me type at 120wpm. Now that would be impressive ^^

  • Finally... (Score:4, Funny)

    by chicago_scott ( 458445 ) on Tuesday August 08, 2006 @09:12PM (#15871041) Journal
    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.

  • Lag from the JitterBug or from network latency? (Score:4, Interesting)

    by frdmfghtr ( 603968 ) on Tuesday August 08, 2006 @10:43PM (#15871327)
    FTA:

    In applications such as telnet and remote desktop, a packet is sent every time a user presses a key. By causing calculated "jitters" in keyboard input while such a program is running, a JitterBug could slightly delay data sent over the network. Certain amounts of delay could represent a one or a zero in each packet that is linked to keyboard use, allowing an attacker to send secret information in otherwise innocuous data without modifying software or initiating any new connections.


    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)

Slashdot Top Deals

"Here's something to think about: How come you never see a headline like `Psychic Wins Lottery.'" -- Comedian Jay Leno

Close