FITUG e.V.

Förderverein Informationstechnik und Gesellschaft

Controlled CPU TEMPEST emanations

18 August 1999

Date: Wed, 18 Aug 1999 19:15:09 +0300 (EEST) From: Berke Durak <durakb@crit2.univ-montp2.fr> To: cypherpunks@toad.com Subject: Controlled CPU TEMPEST emanations

Hello,

After having implemented and successfully tested Ross Anderson's idea to use the video output to synthesize a mediumwave AM signal, I wondered if a similar effect could be obtained by using only the CPU, since it was easy to correlate CPU activity with radio noise. I've just written a quick C program that tries to force activity on the memory bus in a repetitive pattern, with adjustable frequency. After having fiddled with the timings for about one hour, I managed to broadcast a test tune using my Pentium 120 running Linux, giving extremely clear reception on FM band at about 87.5 Mhz (I have in no way calculated or predicted this frequency).

Be warned that my understanding of radio waves is bad and incomplete, and that I have no particular radio equipment, save a walkman and a radio cassette player.

I found that it is possible to hear the test tune over the whole "consumer" medium- and short-wave spectrum (530-1600 KHz, 2.3-22 MHz) using the walkman, which has a digital synthesized PLL radio (which is generally very sensitive to electrical noise), provided the radio is held at a distance of less than two meters around the CPU, which suggests that there are spectral components of CPU activity at many frequencies dividing the clock frequency and at their harmonics (which gives a very rich spectrum). The reception in the FM band is much more clean, and it is possible to hear the test tune in the next room (three to four meters).

I've found that accesses to the main memory create much more noise that other CPU activity, which is readily understandable. As it is not possible to disable CPU caches in user mode, the program allocates a buffer of 1 megabyte, larger than the CPU caches, and fills it with an arbitrary pattern for a number of cycles, then pauses for a number of cycles. These numbers are supplied on the command line. There is an evident correlation between the pitch of the tones generated and the length of the cycles. However, the amplitude of the received signal, although constant for one run, can vary significantly between different runs. My guess is that this has to do with the physical addresses of the memory pages allocated by the process.

I guess that with higher frequency processors and careful assembly coding, it should be possible to do good broadcasting upto and including the FM band. Unlike broadcasting done using an attached CRT display, this broadcasting would be totally invisible and undetectable to the user unless he is suspecting such an activity, and either starts to investigate it or is a radio amateur having lots of equipment (like a spectrum analyzer) which could give him hints about weird CPU activity patterns (but it should be possible to use spread-spectrum transmissions to hide them completely, altough decoding SS is hard). However broadcasting done using the CPU and/or system buses is much less powerful than broadcasting done using the CRT display. But, since it is invisible, if one can get reasonably close to the target computer, it might be possible to discretely record the signals using a dissimulated received, for later processing. Thus, I think that this threat is at least as serious as hidden data transmissions via the CRT.

If you are too lazy to write your own and want my quicly hacked, slow, dirty source code for CRT or CPU broadcasting (X11/Linux, DGA), e-mail me and I'll make them available on the net.

Berke. Zurück