Spread-Spectrum computer clock?

[jimbell@pacifier.com (jimbell)]

Recently there has been a substantial amount of discussion concerning the use of
accurate timing in an attempt to uncover encryption keys, by carefully noting
the length of time that a decryption takes in a computer of a known cpu speed.
I have noticed that most of the discussion focussed on the delay time of the
overall operation done over a network, for example a LAN or perhaps the
Internet, but it has been recognized that imprecision due to indeterminate
network timings make such a tactic problematic at least.

However, being a ham and occasionally listening to the various odd noises
produced by a computer when you tune a VHF or UHF ham radio to a harmonic of the
clock speed, it ccurred to me that the delay times WITHIN a particular
encryption/decryption would  be far more easily measured with local RF snooping.
I would imagine that if you can determine even a fraction of a bit of key from a
network "ping,"  you could do a lot better "listening" to the execution of a
program within a few hundred feet with an ordinary radio receiver and a
sophisiticated analysis program.

Okay, I admit, this is certainly not a new idea.  The military's TEMPEST program
is to build electronic equipment which is so "quiet" that it is impossible (or,
at least, arbitrarily difficult) to capture useful information by inadvertent
radio transmission.

Obviously, that is out of the league (not to mention the budget) of the vast
majority of the users of personal computers.  Nevertheless, it seems to me that
if we as a community of computer users are interested in security, we should not
merely focus on the mathematics and algorithms used and their reliability, but
also secondary methods to break the systems involved.

True, most of us are not sufficiently interesting "targets" to justify this kind
of attack, but machines such as encrypted remailers are sufficiently "high
value" that protecting them would be worth a little extra effort  I'm not under
any illusion that we can hope to make them "snoop-proof", but a little effort
should substantial raise the difficulty level..

More than a year ago, it occurred to me that it might be worth it to build a CPU
clock replacement module that took the place of the main CPU crystal oscillator,
and replaced it with a oscillator module whose frequency was (very long period!)
pseudorandomly varied, possibly with a resolution of 16-bit and over a range of
perhaps 1%., with the frequency varying every few tens or hundreds of
microseconds.  The result, I presume, is that every operation synchronized to
the microprocessor clock  would vary in time and would be hard to "tune" with a
normal radio receiver.  It seems to me that this would make the resulting
computer harder to "bug" using standard equipment.

If this were do-able and were in fact done, it would probably be worth it to
"tailor" the spectrum of variation in clock speed so that these variations do
not tend to average out over "long" times, for example a few hundred
milliseconds or even tens of seconds.   This would at least help to disguise the
decryption-time information that is commonly discussed.   

A complicating factor is the fact that modern motherboards often generate their
microprocessor clocks using PLL synthesis from a master clock, probably the
14.318 MHz clock.  On the one hand, that might make the process easier; only one
clock to vary.  On the other, it is at least conceivable that there are some
devices in any given computer which depend on a precisely constant clock speed,
and would not tolerate such variation.  This was probably more true in the early
days of the IBM PC; today you usually see separate crystals on any cards that
need truly specific frequencies.



(Hey, I didn't say this was a perfect solution, merely one that would raise the
barrier a bit...)


Other potential tactics.  (Some of which are already happening; if anybody out
there is more informed about such techniques, please tell me)

0.   Copper-screen cages.  Okay, maybe this appears to be a bit too obvious, but
it really isn't too involved:  A few years ago, I happened onto a roll of
honest-to-goodness copper screen; sort of line window screen but made of pure
copper.  Sewn/soldered into a bag, it would make an excellent cover.  (openings
required for floppies and CDROMS, as well as cables are obviously a
complication, but...

1.  Use CPUs with Internal caches as well as external caches, both to reduce the
amount of electronic noise transmitted  to antenna-length wires outside the
microprocessors, as well as make external memory accesses less predictable and
less frequent.  Fortunately, I suppose, the natural transition to 486's, DX2's
and DX4/4s) and Pentiums has make this happen without any anti-snooping
motivaition.

2.  Eventually, CRT's will be replaced with some sort of matrix-type displays
that emit far less useable information and will be easier to shield.

3.  Filtering of every wire that comes out of the computer's case, primarily
using a combination of ferrite beads and decoupling capacitors.   This would be
especially true of the telephone line, which would be accessible from outside a
house or office.   Also, use of multiple powerline filters/surge protectors in
series.

4.  I'd pay particular attention to the keyboard interface and its associated
microcontroller:  Years ago, I speculated that if a VFO (voltage to frequency
converter) was placed on the data line between the  keyboard and the computer,
it would transmit the identity of every key pressed.  (This would obviously
include passwords, too)  

(Does the keyboard hardware of the typical PC allow echobacks, whcih would allow
the CPU to fill the CPU/Keyboard channel with apparently meaningless random
garbage, thwarting RF overhearing of this data?!?)


And I wouldn't be surprised if the NSA has built replacement keyboard
controllers to be used to surreptiously replace on garden-variety keyboards,
controllers which deliberately "broadcast" such information in an even
easier-to-discern pattern. Even a short access to such a keyboard and it might
be telling your  secrets.  

Even if a  black-bag job wasn't possible,  If it were possible to tune to its
normal keyboard microprocessor operation rate, and given a known keyboard scan
pattern a particular pressed key could be identified.  Given how cheap keyboards
are these days, a slightly paranoid person might buy one from a trustworthy
source and glue the case  shut to prevent tampering, and replace it monthly with
cast-offs.

5.    While this isn't my area of expertise, it occurs to me that softrware
should be written to complete operations in an identical time frame, no matter
the input data.  While this has already been hashed over on the nets, the
"solution" that is typically discussed involves adding a null loop at the end of
the real operation, and contining only after the "wall clock" shows enough time
has passed.  This isn't an adequate solution, I think, if local RFmonitoring of
the computer can be done.  (It will know when the actual result ended)    A
better (and, sadly, more inefficient) method would involve executing BOTH
branches of  conditional jump, and only using the data generated from the
desired half at the very end..    

Another possibility might be (for certain large mathematical algorithms) is to
split up the functions and to execute them in a "random" order, with enough
"dummy" operations inserted to further disguise the  facts.  For example, if
you're multiplying two 1024-bit values to get a 2048-bit result, program this to
be  done in a pseudrandom order and intersperse any operations with pseudorandom
operations  to disguise it.  (A pseudorandom interrupt generator might help,
here.)

6.   Think like an NSA hack.  If I were such a sneaky bastard, I'd try to figure
out a way to module a visible LED on the computer's case with data, or modulate
the video display's brightness to signal slow-speed data..  



Well, that's just a few thoughts.  There's a lot more material out there that
ought to be discussed.  Admittedly, these subjects can appear to be a bit more
than a little paranoid, but without such discussion we're almost certain to be
at risk.