Schneier on Security
A blog covering security and security technology.
« Why Management Doesn't Get IT Security |
| "Deconstructing Information Warfare" »
November 8, 2006
Keyboards and Covert Channels
This paper introduces JitterBugs, a class of inline interception mechanisms that covertly transmit data by perturbing the timing of input events likely to affect externally observable network traffic. JitterBugs positioned at input devices deep within the trusted environment (e.g., hidden in cables or connectors) can leak sensitive data without compromising the host or its software. In particular, we show a practical Keyboard JitterBug that solves the data exfiltration problem for keystroke loggers by leaking captured passwords through small variations in the precise times at which keyboard events are delivered to the host. Whenever an interactive communication application (such as SSH, Telnet, instant messaging, etc) is running, a receiver monitoring the host's network traffic can recover the leaked data, even when the session or link is encrypted. Our experiments suggest that simple Keyboard JitterBugs can be a practical technique for capturing and exfiltrating typed secrets under conventional OSes and interactive network applications, even when the receiver is many hops away on the Internet.
Posted on November 8, 2006 at 1:26 PM
• 26 Comments
To receive these entries once a month by e-mail, sign up for the Crypto-Gram Newsletter.
Why I'm not interested in trying to research anti-data-exfiltration techniques:
There is so much legitimate noise, and any covert channel can thus be created using steganography. This is a good example, but not the only one.
I recall reading an attack against anonymizing networks which ran along similar lines. I'll have to see if I can dig it up again.
Another military tempest application?
I don't see anything new with this.
A little more detail to your comment would have been nice.
This reminds me a bit of "Silence on the Wire" by Michal Zalewski. Zalewski did not examine this particular idea but did look at lots of related concepts about the physical and network mechanisms that computers rely upon, from a security perspective.
I noted the statement "Mitigation of timing channels involves either neutralizing the channel completely or reducing its bandwidth to acceptable levels." As I understand it, this means blocking traffic which can be tied to keystroke activity such as telnet or making it run so slowly that the jitters are lost in the background noise.
Just a thought here but might it be possible to defend against this, in some scenarios, by adding a function to the firewall that adds pseudo-random delays to traffic associated with keyboard logins? This would almost certainly degrade the quality of Microsoft RDP, VNC and similar systems and it only applies in the case where there is a firewall between the trusted and untrusted networks.
Are there encrypted systems out there that add random noise? e.g. a ssh connection sending dummy packets at random points in time so there is little or no information about the usage of the secure channel?
@Rainbow: Yes. SSH2, in particular, does send random packets in order to confuse timing analysis. However, this doesn't really solve the problem -- it's always possible to distinguish signal from noise given a large enough sample size. Random noise packets might protect you from timing analysis when you're typing your password, but probably not when you're sending gigabytes of data.
If this is the same paper that was at Usenix (best paper?) a couple of months ago, the basic idea was that its a keylogger that you don't have to go back and get later or directly connect to a network. They also talk about a "supply attack" where a many keyboards have this software installed, either by breaking into the keyboard makers code or with a virus. That is actually kind of scary.
It amuses me that these studies always claim that key logging is trivial to hide in hardware, yet still every implementation uses the archaic PS/2 interface! I've yet to see a USB key logger, let alone one that can log a paired and encrypted Bluetooth keyboard. Good luck with that!
``It amuses me that these studies always claim that key logging is trivial to hide in hardware, yet still every implementation uses the archaic PS/2 interface! I've yet to see a USB key logger, let alone one that can log a paired and encrypted Bluetooth keyboard. Good luck with that!''
Oh, so it has different scan codes than a PS/2 keyboard? The jitterbug can be placed in the keyboard itself, prior to transmission, or in the computer itself. USB isn't terribly complex. Bluetooth keyboards, if anything, have an additional vulnerability, and that's the RF part of the signal path. But the keyboard hasn't changed prior to RF, and the computer hasn't changed post RF, so it is vulnerable to all the normal attacks.
You can buy glue chips that implement USB. It's not hard, they're just not common enough yet for people to start targeting them.
You know, the timings are already quantized by the scan process.
Isn't that how the SSH1 attack worked? -- by watching packet timings and doing statistical analysis of the keystrokes. That is, you can determine what keys were pressed based on the pauses between keys.
I've always been a fan, ever since buying your books. But I have a question.
Why have you not spoken out about the computer-electoral system? Surely, some infrastructure based on PKI, signing, certing, and/or hashing could provide a system where a voter would not need to worry about the quality of the machines. Where the voter machine, and the tally machines, are neither able to see nor edit a person's selections. Where your vote is safe from the moment it leaves your fingers until it hits its destination, a publicly reviewable and auditable database of votes.
What do you think?
@ Daniel Feldman:
"Random noise packets might protect you from timing analysis when you're typing your password, but probably not when you're sending gigabytes of data."
Remember that this particular bug is physically located between the keyboard and the network, and modifies keypress timings to create its covert channel.
I have never *typed* gigabytes of data, and I never expect to unless I grow a lot more fingers some time. So even if it's true that the covert channel can be recovered "eventually", if I can add enough noise to ensure that "eventually" means "more data than I will type in the lifetime of my keyboard", then that's fine.
A JitterBug operating "outside" my network card, rather than at my keyboard, would present a much higher bar. All of my traffic would be available for it to jitter, not just keypresses. But if an attacker has compromised my network card, I suspect he can solve the covert exfiltration problem without going to this much trouble. A mouse offers higher bandwidth than a keyboard, but doesn't have much affect on the timing of network packets unless I'm using VNC or similar. Which, as it happens, I'm not, but YMMV :-)
Apart from the fact that PS/2 is easy to do in a PIC etc.
One other reason for not seeing USB etc from the academic community is the USB Device numbers.
These need to be registered and a device driver written or borrowed from somebody elses device.
The first is costly the second is technicaly illegal as you would be using the driver without permision.
The upshot is the idea is proved with minimum cost/risk to the paper writer.
I know Daniel J. Bernstein published a very readable paper on breaking AES by examining network packet times, based on CPU cache hits/misses
@Clive Robinson: "...the second is technicaly illegal as you would be using the driver without permision."
Well, I guess that bugging someone's keyboard is not just 'technically' illegal, so that would be the least of your worries.
Apart from this I assume that you could probably forward the query for the USB device number to the keyboard actually behind your bug, pretty much like a USb extender cable would do. The only thing the bug would add are some timing variations when transfering bits through that cable.
If the bad guys get access to your hardware there are hundreds of other attack vectors they can use, most of which don't involve extra hardware.
Interesting article, but, not something you would spend time or money defending youself against.
I believe the point of the article is that you have to secure and trust your keyboard & input devices, even if your computer itself is locked down. The supply attack stuff has scary implications.
@Paeniteo: I think Clive's point is that the writer of a paper wouldn't want to risk doing something illegal. Bugging your *own* keyboard is legal as far as I understand.
Thanks for pointing that out Walt. The supply chain for computer peripheral hardware includes a major country on the "list of the 13 Internet enemies in 2006" (http://www.rsg.org/print.php?id=article=19603) Call me paranoid but they are a major supplier...
It seems to me that even if you've captured all keystrokes, you have to do a little digging to find the passwords among all of the other things that are typed. Good thing that many applications require you to use passwords that are easily recognizable as such, containing non-dictionary words, special characters, and digits. Any spell checker should be able to spit them out in no time!
Consider if Alice's keyboard broke (they sometimes do), and Eve was able to intercept the keyboard shipment from, say, Dell, and bug it. Now any of Alice's secrets she types in to particular channels (Vnc, Rdp, telnet, ssh, IM, all of the above over VPNs, etc.) are no longer secret, and don't require you to install software on that computer.
That's a pretty good attack vector to consider if your data is that valuable.
Schneier.com is a personal website. Opinions expressed are not necessarily those of BT.