Introduction

For those not familiar with compromising emanations (usually referred as TEMPEST emanations, although TEMPEST is the name of a (classified) US standard for protecting against these), here is a brief explanation, which I hope is understandable by people who did not have lessons in physics. I also hope that I don't make any false statements, since I'm not studying physics. Those familiar with the subject can skip to the next part .

A great deal of information is available on the net. Search for keywords such as "TEMPEST","EMSEC" or "van Eck". There is a very good page having much more complete information and pointers to lots of resources including serious research papers.

Basics of Electromagnetism

• An electric current can be understood as a flux of electrically charged particles, for example electrons.

• Electric tension can be defined as spatial concentration of electric charges.

• Electric charges create electric fields around them, whose intensity increases with increased tension.

• Moving charges create magnetic fields. When a charge is accelerated (when its velocity changes) the magnetic field changes. The greater the velocity, the greater the magnetic field.

• Magnetic and electric fields propagate in space, at precisely the speed of light.

• Their combination is called an electromagnetic field. When either component of the electromagnetic field changes, this change also propagates in space, forming an electromagnetic (EM) wave. Various characteristics of EM waves are their shape (planar, spherical), frequency, phase relationships between their magnetic and electric parts and direction/shape of polarization.

• EM waves might be reflected, absorbed, transmitted, conducted and otherwise affected by matter. The more conductive the matter, the more it is likely to affect EM waves.

• Magnetic and electric fields are tied together. Maxwell's equations describe their relationship. The reciprocal of 4. is also true: varying magnetic fields induce forces on electrical charges.

• Therefore, if we have a changing electric current, by 1.it consists of electrons having changing velocity which by 3 and 4 create a changing electromagnetic field. By 5. these propagate in space. By 8. they might induce forces on free electrons sitting in an antenna. As a result they might move, thus creating an electric current closely tied to the first one.

Basics of Compromising Emanations

TEMPEST and van Eck: Cathod Ray Tube Monitors as Sources of Compromising Emanations

Take any electronic information processing device. Data is internally represented as presence or absence of electrical charges. Processing of data is manipulation of these charges. Thus in any electronic information processing device, there are electrical currents whose variations reflect closely the data being processed. But varying currents create electromagnetic waves which propagate in space and which can then be detected. When no special precautions are taken, the data being processed can be at least partially recovered from the received EM waves. If this data is sensitive, these waves are called compromising emanations. These waves can also escape to and travel in power and phone lines or metallic elements such as pipes.

Thus computer monitors emit EM waves dependent on the picture they are displaying. It has been publicly known for about 20 years that relatively simple apparatus can be used to recover the picture displayed on a computer monitor or TV screen at some distance (maybe a hundred meters). Compromising EM waves produced by CRT (Cathod Ray Tube) displays are known as van Eck radiation. Wim van Eck is (or was) a researcher at PTT laboratories in Holland. He wrote a public report called "Electromagnetic Radiation From Video Display Units: An Eavesdropping Risk ?" in 1985 where he gives indications for constructing an interception device.

Markus G. Kuhn and Ross J. Anderson presented in 1998 an excellent paper where they principally discuss ways of controlling the displayed picture so as to make it harder to intercept or to secretly transmit data.

CRT emanations are very important because video signals need to be greatly amplified to be able to drive the electron guns firing the electron beams that build up the display. It is reported that with professional equipment they can be recovered at distances exceeding one kilometer.

Also the monitor is the most important, if not the only output device of a computer. Thus gaining access to the contents of the screen of someone means completely monitoring that users activities. For these reasons, TEMPEST monitoring is often confused with van Eck monitoring.

Digital Data Buses as Sources of Compromising Emanations

However the CRT is far from being the only source of compromising emanations. There has been a paper by Peter Smulders, again from The Netherlands, called "The Threat of Information Theft by Reception of Electromagnetic Radiation from RS-232 Cables": data transmitted over an unshielded RS-232 (i.e. common serial cable) cable at 9600 baud can be recovered with nothing more than a standard FM radio.

Digital data signals consist of series of rectangular electrical pulses. These pulses have ususally very short rise and fall times. Furthermore level changes occur at multiples of the base clock period. The frequency spectrum of such signals can thus contain components at all the dividers and multiples of the base clock frequency. This is why EM noise generated by computers can be received on a radio on nearly all frequencies with both amplitude and frequency modulation.

Buses in a computer are digital data paths connecting several components. Buses might be internal to a chip, but they might also connect fairly distant components. On my computer the video card, the EIDE hard disk controller and the CPU are all connected via the PCI bus, which has long, unterminated wires which act as antennas. And since PCI buses operate at high frequencies they generate signals which can be picked up well into the VHF band (hundreds of MHz).

For an overview of the PCI bus see Structured Computer Organization , fourth edition, by A.S.Tanenbaum, chapter 3, The Digital Logic Level, Example Buses, The PCI Bus.

Basically the PCI bus is a 32-bit or 64-bit wide synchronous bus operating at either 33.3 or 66.6 MHz. Address and data signals are multiplexed on the same wires. For single-word transfers, the address is transmitted first, then the data. There is also a block mode for transmitting blocks of data at contiguous addresses. Ideally block mode would be used for transferring data blocks from the hard disk or network controller to physical memory without CPU intervention. If a block consisting of 32-bit words whose bits are either all zeroes or all ones gets transferred via a PCI bus, all the data lines would simultaneously go up and down as the block is transferred. The overall electrical signal would be strong. By adjusting the pattern of all-zeroes and all-ones words, it is possible to modulate a carrier frequency at half the PCI clock frequency. This signal can then either be picked up directly or thru its odd harmonics (since a square wave at frequency f has strong spectral components at frequencies 3f, 5f, ...). Other carrier frequencies dividing half the clock frequency can also be generated.

The data intended for the hard disk travels from main memory to the hard disk controller, which then transmits it to the hard disk, via an SCSI or IDE bus. These are also synchronous buses and come in various widths and frequencies. Someone wrote me:

The thing that creates MOST RF activity, often is the SCSI controller on the server. Frequency is high, wires are long (and their length often near to wave length). Once I had an old SCSI card at home and I was able to hear e-mail incoming and regular disk syncs made periodically (on the UNIX machine).

And continued:

Because I had many cheap SCSI disks, I bought an Adaptec 15?? (don't remember) card and connected these disks (NEC 40 MB) via unshileded cable (1 m or so).

It was impossible to work because I heard so much noise on 2 m (145MHz) band. What I did was: to separate the machine from the (cheap Alan CT-100 handheld) tranceiver via a shielded RS-232 cable. I also made a new grounding as well as I could.

Later I had the possibility to change the SCSI cards and cables and motherboards and so on. My impression was that the card and SCSI cable together are the most important elements. Even old XT's are not making such a noise as SCSI cards.

(Nothing to say, even some very drastic measures like ferrite rings on wires were used with almost no improvement).

In addition to it, some specific operations (Linux locate working nightly over the whole disk) were distinguishable over the FM receiver ( 20 km from the sender , concrete block house, antenna as a simple wire).

(emphasis is mine).

Experiments

Hardware

I realized the following experiments. Since everything is very hardware-sensitive, I will detail my equipment:

Computer

Pentium 120 clocked at 120MHz with Intel Triton PCI chipset (not UDMA capable). Phoenix S3 Trio32/64 video card with 2Mb RAM (maximum dot clock 80MHz). ADI Microscan 17" monitor. Fujitsu MPA3035ATU ATA DISK drive (UDMA capable). Maxtor 71626 AP ATA DISK drive. ESS1868 16-bit sound card. Both disks were put in 32-bit DMA mode before initiating transfers in experiment 3. The system runs under Debian/GNU Linux 2.0 with Kernel 2.2.10.

Receiving equipment

Sony CFS-1130S radio cassette player, FM 88-108 MHz, AM 530-1600 KHz and 2.3-22 MHz having a simple, tubular telescopic antenna; this is a totally analog device. Aiwa TX456 walkman with PLL synthesized digital tuner, FM 87.5-108 MHz, AM 531-1602KHz reception range, where the earphones cable seems to act as an external antenna.

Most people owning a computer will own the other equipment as well.

Experiment 1: Teasing the Cathod Ray Tube

M. G. Kuhn and R. J. Anderson, in their paper discussed a way of synthesizing medium- and short-wave amplitude-modulated signals by displaying appropriate patterns on a computer display. They discussed video synchronization and timing issues. I have implemented their idea in the program "tempest", contained in the archive tempest-crt.tar.gz Here are the contents of the README file describing the program:

Short description

Quick hack for transmitting a data stream by sythesizing a radio wave using the video display card. Modulation used is 4-level frequency shift keying over an amplitude modulated carrier. Since this program was just quickly made to check the possibility of such emissions, it has neither been optimized nor there is an accurate data clocking.

Requirements

this quick hack was written for Linux. It requires the XF86DGA (Direct Graphics Architecture) and XF86VM (video mode) extensions. It must have read/write access to the /dev/mem device, for directly accessing the frame buffer. Run it as root. Furthermore, as this is a quick hack, it REQUIRES an 16 bits per pixel RGB display, and is probably endianness-dependent.

Usage

select an integer carrier frequency in KHz, for example 999, then a data file (I use /dev/urandom), set your display to 16 bits and type ./tempest 999 </dev/urandom where 999 stands for your frequency and /dev/urandom for the data file to be modulated. The modulation is straight double side band AM. Make sure your monitor is powered-up :) After the program has precalculated the four symbols (which takes a while since it's REALLY not optimized in any way). Listen to the tones with a handheld radio.

You can press ESC to exit.

In fact the program uses only the lower 2 bits of its input octets to modulate its carrier. Knowing this, I created an ASCII file containing the following pattern:

DEFGDEFGDEFGDEFGDDDDEEEEFFFFGGGGDFEGFDGEFGDFEFDGFDGFDEGFDGDFDFDGEFEGDFEGFD

I then selected an appropriately quiet frequency in the AM band and launched modulation on my monitor, set to a 1024 by 768 pixels resolution at a vertical refresh rate of 70.07 Hz and horizontal scanning frequency of 56.48 KHz, the pixel clock being 75 MHz.

I was able to clearly hear the broadcasted pattern with the Aiwa receiver up to 4 meters away from the monitor, even behind a concrete wall. I must stress that this receiver has no appropriate AM antenna and performs very poorly on AM anyway. I then recorded the received tones on cassette and digitized it with my sound card. The resulting WAV file is available here (it takes around 72Kb of space). Here is its sonogram:

Time runs from left to right, spanning 5 seconds. The frequency scale is linear, the top of the sonogram corresponding to 22100 Hz. There is a logarithmic relationship between the spectral power and the displayed pseudocolor value, that is, the spectrum is displayed in dB. Minimal power maps to blue color, maximal power maps to red color.

The small, red staircases at the bottom of the sonogram correspond to the DEFGDEFGDEFG... parts of the pattern, the large staircases to the DDDDEEEEFFFFGGGG... parts and the remaining bars to the "random" part. Note that the sample begins at the end of a burst and ends at the middle of the next one.

Writing software for automatically decoding such transmissions is left as an exercise for the DSP/digicomm amateur. Besides, it can be eye-decoded.

Experiment 2: Broadcasting a Test Beep with Varying Pitch Using CPU Loops

The program "cpu" in the archive tempest-cpu.tar.gz has been run under null system load, with a command line of:

./cpu 1000 1000 20000 20000 60 60

It was possible to hear a sweeping tone in the full receivable spectrum, using both radios. The strongest reception was in the FM band at 87.5 MHz. There, I was able to hear the tune at up to 20 meters away with the Sony radio; however it should be noted that the radio was plugged to the electrical network in the same house. Nevertheless at a distance of 20 meters, several rooms apart, I have found that reception was quite sensitive to the orientation of the antenna, completely vanishing for some orientations. This suggests that the main transmission path was not the power line. The small Aiwa receiver (which is battery-operated) displayed a reception range of 5 meters.

I have recorded the received tune on cassette and digitized it using my sound card. The sample being voluminous, the version available here has been have reduced it from 44100 Hz 16 bit to 8000 Hz 8 bit. Note that there is strong interference from a nearby radio station. The WAV file is here (about 39 Kb).

Here is its spectrum analysis:

(If you feel lost please see the description of the previous sonogram).

At the bottom of the sonogram, i.e. at the lower frequencies, you can see a log-shaped repeating curve in red, as well as its first few harmonics, corresponding to the tone broadcasted by the CPU and demodulated by the radio's FM circuitry.

Someone wrote me:

We used to do this (radio broadcasting using the CPU) many, many years ago on the IBM 1401 computer with a small AM radio - using the then core memory cycles...

And continued in another letter with:

In actual fact, that old 1401 program had more use than just playing a tune. It was used by our operators on the midnight shift (working 12 midnight till 07.30 hrs) to determine which program was running and what state it was in ! That way they could easily get ready for the next batch run, and so on....

Dave Emery N1PRE said in a post to the Cypherpunks mailing list:

And as for playing tunes with cpu radiation, back in the PDP-8 days in the early 70's someone spent some time programming a PDP-8 to play complex polyphonic music by executing multiple IOT instructions on the external IO bus in suitable little loops. I remember hearing it play Bach... it was amazingly good and very musical. Someone else where I worked back then disassembled the program and figured out to enter arbitrary music and compile it into playable programs. The whole thing was such a novelty back then that it made the national news... Radiation of the very slow logic and cpu clocks back then was mostly only in the low end of the AM broadcast band... not much above 20 mhz or so...

It's quite easy to broadcast a sliding tune, but broadcasting enjoyable music under a modern operating system seems tricky.

Experiment 3: Abusing the Disk Controller

The third program, tempest-pci , contained in this archive, exploits block mode PCI transfers (and possibly EIDE transfers) by synchronously writing appropriate data to an on-disk file. The user supplies two pattern descriptions on the command line, one for transmitting 0-valued bits, one for transmitting 1-valued bits. A pattern description is a string of '0' and '1' characters. A zero represents a null 32-bit word ( 0x00000000 ), a one represents an all-ones 32-bit word ( 0xffffffff ). Two buffers are filled with these patterns. The program then opens the specified file in synchronous mode ( O_SYNC option to the open() system call) and writes these buffers depending on the data bits it sees on its standard input (the program seeks to the beginning of the file before each write). Various command-line options are provided; look at the source code.

Bursts of noise can be heard in the full receivable radio spectrum. Reception is a lot better in the FM range at near-multiples of the PCI clock frequency but since the FM band is crowded the range is very limited: about a few meters. However it is usually hard to distinguish between noise bursts corresponding to "1" and ones corresponding to "0". Trying different patterns gives little improvement. To make sure that the noise bursts are actually pattern-dependent I conducted a "blind" experiment. I called the program tempest-pci with random input (redirecting /dev/urandom to its input); the bits sent are displayed them on standard output. So I made it transmit a 16-bit word while hiding results. After reception, recording and sampling as in the previous experiments, I found that it was possible to distinguish two kinds of bursts on the sonogram. One of the two kinds was more rich in high-frequency components, as you can see for yourself. Here is the WAV file (about 117Kb) and here is the sonogram:

Looking at the sonogram I guessed the possible bit values. I then looked at the output of the program. My guess was right. I repeated the experiment two or three times with different patterns, all with success, possibly misguessing the correspondance between the burst types and their bit values, but never confusing the two kinds of bursts. Therefore this system can be used to transmit data, although detection and demodulation are likely to be quite tricky. It does not require access to special resources as other techniques do (either pixel-based access to the display or access to a PCI address). However it is very sensitive to disk activity and should better be run when the system is quiet.

Here are close-up views of the two kinds of bursts:

Experiment 4: Accessing Memory over the PCI Bus Directly with the CPU

Warning! Running tempest-mem with an incorrect address can severely damage your system ! I strongly advise you to not run it unless you know what you're doing.

The final program, tempest-mem is the most sophisticated one I have written (available here for this purpose. It is also the one that makes the most noise ! Its aim is, like the tempest-pci program, to generate signals on the PCI bus. However it attains its aim by writing to a user-supplied address supposed to be in the PCI address space. It does so by mmap() 'ing the /dev/mem device. It thus requires appropriate privileges. In order to have fast and predictible timing, the command, when invoked, generates two pieces of i386 code according to the user-supplied patterns and address. It then executes them according to the data to be transmitted (actually it just transmits pseudorandom bits). I wrote this program after someone suggested me to do writes to the video card's display buffer at an off-screen address (my video card is connected to the PCI bus); this both drives the bus and bypasses the caches, while being invisible.

When data is written to a PCI address with a mov instruction on the CPU, the destination address is first generated on the multiplexed address/data lines, and then the data word is presented at the next clock tick. So, it is not possible to have complete control over the address/data lines this way, since writing to arbitrary adrresses would result in havoc. But two addresses having sufficiently different hamming weights can be selected. Suppose for example that address a is 0xe0000000 while address b is 0xe001ffffc (which corresponds on my system to the lowest and highest 4-byte aligned addresses of the video RAM).

I have not yet implemented this subtility. But it is possible to transmit and recover data by using a single address.

I have conducted a "blind experiment" as in Experiment 3, this time with a 32-bit random word. The first 29 bits appear with extreme clarity on the sonogram, and I guessed them right. My guess for the 32-bit word was 0010 0001 1110 0111 1001 1111 0001 1*110* . The actual data transmitted (or intended to be transmitted) was 0010 0001 1110 0111 1001 1111 0001 1001 . The remaining 3 bits are difficult to decipher, presumably because some other bus activity (such as the operating system flushing caches) occurred. The WAV file is available here (about 284 Kb).

Conclusions

Empirical evidence, comments from various people and litterature shows that it is possible to broadcast data with extremely simple software using radio frequency emissions by appropriately controlling the CPU and system buses, and that this data can be received and recovered using low quality equipment.

Experiments done with very limited equipment show that it is possible to obtain reception ranges varying from a few meters to over twenty meters, reception seeming to be little affected by concrete walls.

Consequences

There are important consequences for computer security. User programs or maybe even Java applets can broadcast data that can be undetectably received. CPU broadcasting techniques mean that privileged access or pixel-level access to screen contents and displaying of suspect patterns on a user's screen are not necessary. It might be even possible to apply spread-spectrum like modulation techniques to reduce the likelihood of suspect RF signals being noticed. It can be possible to steal information from isolated computers not even having network connectivity nor a CRT display, by using virus or other techniques to get the program in the target.

These techniques are available to entry-level attackers having no special equipment . Therefore it is conceivable that attackers having minimal equipment and good knowledge can obtain much higher reception ranges. Funded or government/corporation-backed attackers can probably extract useful information even without having to install broadcasting software, by using appropriate equipment. Access to power and telephone lines could be very useful.

However data broadcasting can also be used as a communications or monitoring tool. It has been suggested that video cards could, by connecting an appropriate antenna (with maybe a homebuilt RF amplifier), be used for transmitting data with a good range. With appropriate software, a PC having nothing more than two video cards (one for normal display), and a sound card together with an external radio or a radio tuner card with digitizing capabilities could be used for wireless communications. Such a setup can be useful if a natural catastrophe rendering usual communications means unusable occurs. Such a situation has occurred in Izmit, Turkey with the earthquake that occurred a week before this document was first released.

Things to Investigate

The open civilian community must investigate these issues by itself. I suggest the following research topics:

• In-depth analysis of RF signals emitted by typical computers and their peripherals, including keyboards.

• Determination of likely interception ranges for various classes of attackers.

• Development of new protective counter-measures, both hardware and software.

• Testing of existing counter-measures together with development of offensive tools (unfortunately you need a gun to test bullet-proof glazing).

• Development of free, open-source software, protocols and modulation schemes for using plain computer equipment for wireless communications.

• Propagation of compromising emanations in power and telephone lines.

• The possibility that various electronic devices might pickup and retransmit (possibly modulating) compromising emanations. Emanation techniques could even contaminate digital transmissions and be digitally relayed.

• Vulnerability and protection of equipment against active electromagnetic attacks.

Some protective measures have been suggested in a post to the Cypherpunks mailing list titled "Spread-spectrum Computer Clock ?".

I hope that this page will give inspiration to other people for investigating these matters.

Resources and references

Here are resources and references about TEMPEST.

• Link Joel McNamara, The Complete, Unofficial TEMPEST Information Page .

• Link Markus G.Kuhn and Ross J. Anderson, Soft Tempest: Hidden Data Transmissions Using Electromagnetic Emanations , in David Aucsmith (Ed.): Information Hiding, Lecture Notes in Computer Science 1525, Springer-Verlag, ISBN 3-540-65386-4, pp. 124-142., 1998.

• Link Berke Durak, Controlled CPU Tempest Emanations , post to Cypherpunks mailing list, 1999.

• Link Berke Durak, Sources for Controlled CPU TEMPEST Emanations , post to Cypherpunks mailing list, 1999.

• Link Jim Bell, Spread-Spectrum Computer Clock ? , post to Cypherpunks mailing list, 1995.

The original URL of this document is http://lambda-diode.com/electronics/tempest/

Redistribution is unlimited, provided that you don't alter contents and give me credit where it is due. It would also be gentle to inform me by mail whenever you use this material as part of a publication or web site.