Yet Another Computer Side Channel

Researchers have managed to get two computers to communicate using heat and thermal sensors. It's not really viable communication -- the bit rate is eight per hour over fifteen inches -- but it's neat.

EDITED TO ADD (4/13): The paper. Similar research.

Posted on March 27, 2015 at 7:01 AM • 22 Comments

Comments

Russel T. JamesMarch 27, 2015 9:05 AM

I think the previous poster is receiving side-channel information in a similar fashion through his tin foil helmet.

Clive RobinsonMarch 27, 2015 9:19 AM

@ Moderator,

I suspect that MIX has returned yet again... perhaps a little analysis is required. If it is the same person/organisation then it might be a little more serious than previous oddities.

MartinMarch 27, 2015 9:58 AM

@Tao-PI

This is probably a good time to start thinking about coming back to reality.

Clive RobinsonMarch 27, 2015 10:06 AM

Technically this side channel is an example of a simple EmSec channel in the class of thermal emissions.

What it does demonstrate is the issue of very low bandwidth that can be used with any system...

In practice each time you turn a piece of equipment on or off you are sending out a change of state which can represent one or more bits of information (think which second in a minute to see how you get just under 6bits for each transition).

Likewise using the load on a CPU to create heat can be used in a number of ways either in time/frequency or amplitude. That is you could use one of a number of conventional modulation techniques where the traditional "amplitude" component is replaced by a measure of temprature.

But we also know that heat is pervasive and gets into all parts of a system, where it can cause other effects by well known physical processes. One area in particular is the XTAL used by the CPU artifacts of which appear in all the computers activities.

A number of years ago I mentioned this on this blog and later a student researcher at Cambridge Computer Labs used the same idea to fingerprint computers across the Internet by examining TCP/IP time stamps (he later upgraded the idea to use the timestamp transition edges to get an improved signal to noise).

However as I pointed out, this alows for other interesting possibilities, one of which is detecting "virtual systems" used in hosting environments and honey nets. The leaking of this information is fairly important from a security point of view as it makes advanced attackers lives considerably easier and more secure. For example, what looks like a very simple "script kiddy" attack can be used to enumerate a network in terms of what is and is not a virtual machine and which VMs and how many are running on individual hardware systems. The ratio of VMs to actuall hardware would quite easily reveal most honey nets, thus an experianced attacker would not risk their hard won zero day etc and thus shorten it's useful life.

But not only is heat all pervasive, it is a side effect of "work" thus no system can avoid producing it in some measure because nothing is 100% efficient. Which means in turn it's a side channel you can not stop. All you can do is lower it's usefull bandwidth.

And even at only 1 bit an hour it does not take long for sufficient key bits etc to be leaked out...

Whilst there are other things you can do to reduce the effect of "work related side channels" you have to be very very carefull you don't make an attackers job easier inadvertantly...

ZenzeroMarch 27, 2015 10:33 AM

@Bruce

It is indeed a fascinating means of communication between systems. As both systems would require to be compromised it's value as a secret avenue of comms (detectable as @Clive alludes to) is pretty minimal. Though rather cleaver none the less.

The paper will be published on the Ben-Gurion University site at some stage:
http://cyber.bgu.ac.il/blog/bitwhisper-heat-air-gap

GweihirMarch 27, 2015 12:09 PM

A nice student project, to be sure. Not surprising that it works, and the stated bit-rate is under next-to-ideal conditions and will be much worse in many environments.

Marcos El MaloMarch 27, 2015 1:12 PM

Am I missing something, or could this attack be easily defeated with a desk fan and a bucket of ice? Perhaps a heating pad on some sort of variable timer?

CoolerMarch 27, 2015 2:54 PM

I think this attack is for the really desperate TLA out there. Maybe some third world entity who can't afford a better attack.

DBMarch 27, 2015 3:15 PM

You guys just aren't thinking of the applications of this kind of side channel to realize how serious this can be: think about a compromised air-gapped machine communicating with a nearby also-compromised non-airgapped machine... this is where it starts to get hinky and potentially "useful," no matter how low the bandwidth.

Terry ClothMarch 27, 2015 4:24 PM

Finally, an application for the elusive millibit per second
I've always wondered about sites that use mbps, as in ``The FCC redefined broadband to be no less than 25mbps.'' (I'm looking at you, Register.) Finally, a comm channel that runs at 2.2 mbps.

Clive RobinsonMarch 27, 2015 6:26 PM

@ DB,

You guys just aren't thinking of the applications of this kind of side channel to realize how serious this can be...

It's one of the normal human responses, due I suspect too to many "chicken little" type statments from talking heads about the world going to end if people don't XXXX immediately.

The important take away from this is it's a side channel you can not stop due to the fact that all systems are inefficient, and the result of this inefficiency is heat...

All you can do is try to limit the channel bandwidth, but care needs to be excercised, because it could make the issue worse. Further as Bruce has been known to point out "attackes only get better with time".

@ Marcos El Malo,

Am I missing something, or could this attack be easily defeated with a desk fan and a bucket of ice? Perhaps a heating pad on some sort of variable timer?

Yes thermal energy only moves from hot to cold and to move the heat requires that work be done to make a thermal gradient. And this work generates it's own heat, so you are not cancelling the heat generated from the CPU or it's signal, you are just replacing it with another stronger signal else where...

And that means the signal is more detectable at a longer range.

Even adding what appears as a random masking signal will make detection of the real signal easier.

All you can realy do is lower the bandwidth of the signal via insulated thermal masses that act as storage elements with long time constants, but they will eventually need to be cooled in some way which requires work...

Marcos El MaloMarch 27, 2015 7:17 PM

@Clive

OK, how about this, then? Devote one or more cores of the CPU to run programs designed to create thermal noise. Would that do it? Thanks for your previous response and thank you if you respond to this.

DBMarch 27, 2015 7:49 PM

@ Clive

My intent wasn't to say "the world going to end if people don't XXXX immediately" but "let's not say 'welp, nothing can be done' and stick our head back in the sand and pretend this doesn't exist at all"

For example, things can be done, like: if your computer is heating up and cooling off and you don't know why, figure out why! As an example, the computer I'm typing this on has a fan that senses the hotness of the CPU, and if it gets warmer, it starts spinning faster... and making more noise. It becomes really obvious if it's doing something CPU intensive, even if only for a few seconds at a time. I always investigate unexplained CPU activity because I don't want to waste power, regardless of any potential security related side channels. Also unexplained unusual CPU activity is often a result of a problem that needs fixing in my experience so far (bug, runaway task, etc).

Such monitoring could be made easier... and we could consider it important to use such monitoring on, say, an air gapped secure system, or a system near one. Elsewhere, maybe not as important often.

Of course making things more visible to the user could make them more visible to the other computer too, so care has to be taken how one monitors things. For example, in my case, a mic could be used to detect the heat increase (i.e. detecting fan noise), thus increasing the bandwidth of the side channel by making it a heat-audio combo channel. But maybe there are other ways like something on the screen, which, technically could be read too, but if you can read the screen you got a much bigger side channel right there on the rest of the screen! You could think about hiding your screen from any sort of light sensors too not just curious human eyes... the list goes on, and probably isn't important for many use cases where there are simpler side channels available, but can be important in some (like air gapped machine).

And just being aware of the issues helps. It starts the brain thinking down new paths it didn't before...

ZenzeroMarch 27, 2015 8:20 PM

This particular attack requires both the air gaped computer and the internet accessible computer to be both compromised and within a certain distance of each other. In reality that's game over in the first place.

@Bruce wasnt highlighting this as the next big thing, side channel methods are very well know. I believe it was just a "that's pretty cool"

Clive RobinsonMarch 28, 2015 7:17 AM

@ DB,

My intent wasn't to say "the world going to end if people don't XXXX immediately"...

No and I was not implying you were.

The problem is we get many vested interests talking up any security vulnerability they can for various reasons. Often the vulnerabilities don't warrant the attention the vested interests think they should have.

The result is as with the "boy who cried wolf" people develop "warning fatigue" where they just assume that all new warnings are being handed out by the vested interests and thus show little or no interest, which is the point your posting was raising.

@ ALL,

Personaly I know that "thermal side channels" are a real problem, as they exist due to "work" being carried out, and just as with One Time Pads where solving one problem justs creats another harder problem, trying to solve thermal side channel issues just moves the problem else where, often at a greater distance and easier detectorability.

For instance the example of active cooling by fan, the noise it creates not only goes around corners, the vibrations it sets up in objects happens at many times the distance radiant heat would no longer effect the same object in a normal environment like a hotel room. It would be upto the dimensions of the room which is getting on for thirty to fifty times the thermal range. Unfortunatly the vibrations have a charecteristic that enables them to be filtered out from other noises, and worse a laser mic could pick the vibrations up at over 150meters so in effect in the hotel or office building on the other side of the block...

But... the original idea of the fan is to reduce the thermal mass of the CPU heat sink as pasives tend to be large and thus expensive. The problem is the smaller the thermal mass of the heatsink the greater the bandwidth of the thermal side channel.

So double whammy, your fan can be detected upto around 150 meters through windows and bright sunshine etc, and due to the reduction of heat sink thermal mass it probably has ten to a hundred times the usable information bandwidth...

But further consider the fan is an electrical item and some are quite electricaly noisy. This noise will get back through the average computer PSU onto the utility/mains wiring... Modern "smart meters" have information bandwidths of more than 300Hz, and can --in theory-- be programed to send this information back out via the signaling protocol to where ever those with control of the signaling want it to go, so around the world would not realy be of an issue...

So the small financial savings made by switching from a passive heat sink to an activly cooled heat sink via a fan could have a major security implication...

And untill people start thinking this way the issues of poor information security will just get worse and worse with time. And as Bruce has remarked attacks only get better with time...

So thermal side channels are a major issue to think about in secure systems design. And even though I was sounding warnings last century people were just not interested. Thankfully now it is in the open it can be talked about in academic journals, not hidden away in TEMPEST and EmSec design and instalation manuals as it has been for a good thirty to seventy years... So time to play "Catch up quick".

WaelMarch 28, 2015 2:42 PM

I don't believe thermal side channel information leakage emanating from a general purpose platform as described in this article is a viable attack.

Dirk PraetMarch 29, 2015 8:00 PM

@ Marcos El Malo, @Clive

OK, how about this, then? Devote one or more cores of the CPU to run programs designed to create thermal noise. Would that do it?

It's probably easier to set up some dummy cron jobs that intermittently cause extra CPU load and thus heat. It may interfere with or throw off the malware processes that for their communications depend on temperature increases ('1') and decreases ('0') within certain intervals.

The desktop fan is a good idea when you put it between sender and receiver as the latter needs to pickup the temperature changes in the former, thus disturbing the heat emissions from the sending device. For plain cooling purposes you're probably better of with an external USB-powered laptop/notebook cooling pad or adjustable fan.

However interesting as a PoC, I doubt this attack is very practical at a transmission rate of 8 bits/hour and with a maximum distance of 40 cm. between both devices.

Clive RobinsonMarch 30, 2015 6:40 AM

@ Dirk Praet, @ Marcos El Malo,

How about this, then? Devote one or more cores of the CPU to run programs designed to create thermal noise. Would that do it?

It's a subject I've given some thought to over the years.

There are two main aspects to consider,

The first is aranging a constant work load on the chip such that an external monitoring process can not gain usefull information from observing the thermal signiture.

The second is hiding the work load process from observation by a secondary monitoring process such as EM signiture, CPU external bus signitures, cache usage signitures etc etc.

Obviously the second process is recursive, because trying to hide the first process it's self generates tell tales that need another process to hide from a different monitoring process and so on.

However the first process is also problematic, no mater what you do it will leak some information, the only question is what the observer can do with it. At the very least a constant load will alert the observer you are upto something you are apparently trying to hide.

But the first process also has a problem, to be effective it must be able to dominate the effects of other cores at all times, even when they idle...

It's why I prefer to go down other routes. A large passive heat sink not only reduces the observable heat differential thus limiting the side channel range, it also reduces the side channel bandwidth as well. An external fan that is fixed in behaviour reduces the thermal diferential further, but generaly does not effect the bandwidth.

The real solution is carefull system design such that whilst work is done, it's not done in ways that make side channels usefull either to passively observer, or to actively control. One way is to shorten task time by upping the process swaping rate and increasing the number of processes. Providing any given task has only a very small fraction of the CPU time compared to the side channel time constant it's overall effect is minimised.

Further the compiler or interpreter used to make the code available to run on the computer can be designed to provide a minimal or constant load signiture.

It's these areas little or no attention has been given by the open community even as purely academic excercises. The opposite is true for the closed signals intelligence community, where designing minimum EmSec visability equipment has been going on since WWI a century ago.

Leave a comment

Allowed HTML: <a href="URL"> • <em> <cite> <i> • <strong> <b> • <sub> <sup> • <ul> <ol> <li> • <blockquote> <pre>

Photo of Bruce Schneier by Per Ervland.

Schneier on Security is a personal website. Opinions expressed are not necessarily those of IBM Resilient.