Shawn T. Rutledge quotes Jonathan Shapiro:
> > That's because you haven't applied error correction to the signal. Think
> > about it a little more from the attacker's perspective...
>
> I don't think I understand.
If you have a noisy channel, you can communicate data over it; it's just that all the data has random noise added to it.
The fundamental theorem of information theory says that the noisy channel has some fundamental capacity, in bits per second, and that you can communicate over that channel at any rate less than that fundamental capacity with arbitrarily low probabilities of error by being clever. Error-correction codes are one method of being clever; the longer your error-correction words, the lower the probability of error, while leaving your bit-rate constant. (Also, your latency goes up. This seems to be a constant with many methods of being clever --- the better your reliability on the noisy channel, the worse your latency. I don't know if there's a mathematical proof of that.)
(Unfortunately, I don't really understand information theory, so I can't really explain the theorem, I'm afraid.)
So suppose you have two applications with windows A and B open on the screen, and the security policy supposedly forbids them from communicating with one another. But the window system tells each window whenever it needs to redraw its contents because another window has just moved away from being atop it.
So here are some possible covert channels specific to windowing systems:
- window A can move itself around the screen at varying rates. As it
moves over the window B, window B gets refresh requests (Expose
events in X terminology). The channel is "noisy" because B may get
refresh requests for other reasons as well. Even if window B doesn't
have access to a clock, it can use the overall event stream as a
noisy clock; if it gets 100 refresh requests in between
mouse-movement events, it's an indication of refreshes happening more
frequently than when it gets 100 mouse-movement events between
refresh requests.
- window A can use up varying quantities of hardware resources (texture
maps and so forth), causing window B's drawing operations to speed up
and slow down --- or possibly even fail more or less often.
- if window B asks the user to calibrate on-screen colors to
printed-out colors, and the colors displayed in window B are slightly
affected by the colors displayed horizontally adjacent to window B,
window A can display colors that encode information on the off-chance
that it's sitting next to window B on the display, causing window B's
colors to get calibrated by the user slightly differently.
- if window A is doing something that occasionally attracts the user's
attention, and window A has some latitude in how it can time this
"something" --- either in frequency or in phase --- it can encode
information it wants to transmit in this timing. This will distract
the user from window B, possibly causing them to temporarily stop
typing, for example.
- as I think Norm alluded to, window A can encode radio waveforms in
dithering patterns. The monitor cable and monitor will transmit
them; any nearby radio receiver capable of picking up the appropriate
band will be able to receive them. The interesting case here is when
there is a radio receiver inside the same computer --- perhaps the
sound card has some circuits that resonate at radio frequencies?
(This is actually a problem even with things like memory access
patterns. Try turning your sound-card output to the max, turning
your amplified speakers to the max, and running various Linux
processes. (Playing a recorded sound will likely blow out your
speakers at this point, so don't do that.) You should be able to
hear mouse interrupts, keyboard interrupts, sorting algorithms, and
identify different processes by sound.)
I tend to think that most of these are fairly low in bandwidth.
-- <kragen@pobox.com> Kragen Sitaker <http://www.pobox.com/~kragen/> The Internet stock bubble didn't burst on 1999-11-08. Hurrah! <URL:http://www.pobox.com/~kragen/bubble.html> The power didn't go out on 2000-01-01 either. :)