[116704] in Cypherpunks
Re: Controlled CPU TEMPEST emanations
daemon@ATHENA.MIT.EDU (Jean-Francois Avon)
Wed Aug 18 18:32:32 1999
Message-Id: <199908182127.RAA01722@cti06.citenet.net>
From: "Jean-Francois Avon" <jf_avon@citenet.net>
To: "Cypherpunks" <cypherpunks@toad.com>,
"Berke Durak" <durakb@crit2.univ-montp2.fr>
Cc: "Noel.Boutin@gel.usherb.ca" <Noel.Boutin@gel.usherb.ca>
Date: Wed, 18 Aug 1999 17:22:39 -0400
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
Reply-To: "Jean-Francois Avon" <jf_avon@citenet.net>
Greetings Mr. Durak.
You might want to talk to Pr. Noel Boutin, at U. of Sherbrooke (Quebec
Province), Canada. I think he was reserching for a while (late eighties) on a
system that would transmit digital data from utility electrical power meter
directly via the power grid itself. His work was probably done in cooperation
with Hydro-Quebec, one of the largest electrical network in North America.
The page for the Electrical Engineering professors at U. of S. is
http://www.gel.usherb.ca/general/personnel/prof/index.html
and Noel Boutin's address is Noel.Boutin@gel.usherb.ca
He is a Top Gun in his field and one of the best (if not THE best) teacher I
ever had (1989) during all my years at U. of Sherbrooke. I have no ideas if
this topic covered his specific research topics (actually unlikely) but he is
this kind of mind that likes to inquire into things...
Ciao
Jean-Francois Avon.
On Wed, 18 Aug 1999 19:15:09 +0300 (EEST), Berke Durak wrote:
>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.
>--
>Berke Durak durakb@crit2.univ-montp2.fr
>PGP 262i F203A409 44780515D0DC5FF1:BBE6C2EE0D1F56A1
>GnuPG 1024D/15FAB6E4 2048g/64021883 E38EE35DCED067CEB949:FC77DAFA083A15FAB6E4
>Kripto-TR http://gsu.linux.org.tr/kripto-tr/
>
Jean-Francois Avon, B.Sc. Physics, Montreal, Canada
JFA Technologies, R&D physicists & engineers
Instrumentation & control, LabView programming
PGP keys: http://bs.mit.edu:8001/pks-toplev.html
PGP 2.6.x RSA (preferred key: 0xC58ADD0D)
0xC58ADD0D: 5296 45E8 205A 8A5E F87C C86F AEFE F891
0x5B51964D: 152A CCBC D4A4 81B0 2540 1119 3237 822C
PGP 5.x DH ID: 0x6CBA71F7 (use only in last resort)
4858 88E9 FD68 415A 2945 ACCB 366D 3848 6CBA 71F7
