Exposing Computer Monitor Side-Channel Vulnerabilities With TempestSDR

Having been endlessly regaled with tales of side-channel attacks and remote exploits, most of us by now realize that almost every piece of gear leaks data like a sieve. Everything from routers to TVs to the power supplies and cooling fans of computers can be made to give up their secrets. It’s scary stuff, but it also sounds like a heck of a lot of fun, and with an SDR and a little software, you too can get in on the side-channel action.

Coming to us via software-defined radio buff [Tech Minds], the video below gives a quick tour of how to snoop in on what’s being displayed on a monitor for almost no effort or expense. The software that makes it possible is TempestSDR, which was designed specifically for the job. With nothing but an AirSpy Mini and a rubber duck antenna, [Tech Minds] was able to reconstruct a readable black and white image of his screen at a range of a few inches; a better antenna and some fiddling might improve that range to several meters. He also shares a trick for getting TempestSDR set up for all the popular SDRs, including SPRplay, HackRF, and RTL-SDR.

Learning what’s possible with side-channel attacks is the key to avoiding them, so hats off to [Tech Minds] for putting together this simple, easy-to-replicate demo. To learn even more, listen to what [Samy Kamkar] has to say about the subject, or check out where power supplies, cryptocurrency wallets, and mixed-signal microcontrollers are all vulnerable.

[via RTL-SDR.com]

12 thoughts on “Exposing Computer Monitor Side-Channel Vulnerabilities With TempestSDR

  1. This has actually been a thing for a long time. (and exploited out in the wild too…)

    Now, just like keyboards, a monitor can do a few things to combat this issue.

    Keyboards for an example can randomly scan their columns instead of scanning them one after another, and also scan them at a reduced voltage. Reducing voltage means lower amplitude in the emitted signals, and the random pattern means that we can’t as easily discern what column were pressed.

    Though, since each column isn’t “identical” to each other, not to mention the rows as well… Then we can still largely discern where the key were, but since keyboards can have different trace layouts, the task becomes a bit harder. (Not to mention that we need to look at finer differences within the emitted signal.)

    Another way to though leak data is via the cable going from the keyboard to the computer. Here a large change were simply to go from single ended to differential signaling, this dramatically reduced EMI. (though also dramatically increased signal integrity and thereby bitrate.)

    A monitor could do something “similar”.
    We already have encryption on HDMI (as a form of DRM, and it’s not strong encryption btw). We could instead do a key exchange between monitor and the computer, if we do the key exchange at reduced bitrate, then our cables will be a far worse antenna. So it should be reasonably secure to send over a symmetric key, and we only need to do it during startup.

    Not to mention that we could also bake in an EEPROM into the monitor, so that it can remember the computer for a while. (if it’s list of remembered computers gets too long, it can just overwrite the computer it hasn’t talked to in forever.) This means that we don’t even need to send over the key during startup, except the first time we use the monitor.

    From there on we also need to fix our data leaking screen itself, if our monitor were to randomly scan it’s rows, then that would make it harder to reverse engineer what order things should be in. (Though, this would obviously just cut the image into long single pixel wide strips, putting them back in the correct order isn’t too big of a challenge, but since its a new order for each picture, the challenge becomes harder, unless you know where to search.)

    Another method to mitigate data leakage is to also put on a transparent conductive coating on the display, effectively shielding it a bit and preventing the RF from leak out as much.

    Though, as with anything else in the world of encryption, we can simply just make things harder, not actually make it impossible. (Even one time pad can be broken, since you need a perfectly random source, and you still leak other data surrounding the encrypted package, since it has a certain size, transmission date, source, among other things.)

        1. Not to mention that it also is rather inefficient as well.

          And that with a good antenna array, one can discern a specific monitor in a landscape full of other monitors. (same can be done with keyboards too…)

          Its easier to shield stuff to bury it in the noise, but with a sufficient antenna array, one can amplify it back out from the noise…. (Though, the word “sufficient” can eventually imply something highly impractical/obvious, making it infeasible for an attacker to use it in practice.)

    1. If we’re talking custom display protocol how about an ECDH key agreement handshake to create a shared symmetric key, and one of the counter modes for AES encryption to snow-out the visible patterns in the ciphertext without adding blocking requirements?

  2. In the CRT era, there was a font with soft transitions and no sharp straight lines that supposedly made it more difficult to lock on to a signal in Tempest testing; don’t know if that would make a difference on an LCD.

  3. My first introduction to this was actually in the book Cryptonomicon by Neal Stephenson though i think it’s alot easier to pull off with todays hardware 21 years latter

  4. As with the majority of fledgling technologies, wireless HDMI has to address multiple, incompatible standards that compete with one another. Wireless HDMI is only an immediate replacement for HDMI cables.

Leave a Reply to Alexander WikströmCancel reply

Please be kind and respectful to help make the comments section excellent. (Comment Policy)

This site uses Akismet to reduce spam. Learn how your comment data is processed.