David Honig wrote on 1999-01-20 22:42 UTC:
> At 08:56 PM 1/20/99 +0000, Ben Laurie wrote:
> >Steve Bellovin wrote:
> >> Intel has announced a number of interesting things at the RSA conference.
> >> The most important, to me, is the inclusion of a hardware random number
> >> generator (based on thermal noise) in the Pentium III instruction set.
> >> They also announced hardware support for IPSEC.
> >
> >An interesting question (for me, at least) is: how will I know that the
> >hardware RNG is really producing stuff based on thermal noise, and not,
> >say, on the serial number, some secret known to Intel, and a PRNG?
>
> You would have to reverse engineer random samples of the chip to gain
> *some* confidence. Intel could make this easier by providing
> their "source" and tool flow, from specs to a HDL to synthesis to layout.
>
> There are, I am told, commercial firms who will give you a netlist given
> *only* a sample chip and lots of money.
Oh, I can also tell you names: Semiconductor Insights Inc. and Chipworks
Inc., both Canada, are two of these companies for instance who make
their living by reverse engineering netlists from VLSI products,
primarily for patent infringement lawsuits. Chipsworks has a nice
micrograph collection of greetings from chip designers to reverse
engineers left on the chip layout on their web site. These labs will
however ask for a dozen sample chips usually (etching is an irreversible
process after all, so you often need several samples to get the
parameters right). The commercial prices range from 10000 USD for
reading out a smartcard to 100000 USD for reverse engineering a
cryptographic ASIC (see the court evidence presented in the BSkyB v.
Christopher-Carey case).
Obviously, knowing the netlist of one type sample tells you nothing
about the functionality of other processors that you buy from the same
source. I would not be worried about chips purchased directly from
Intel, but knowing that NSA and their international competitors own
similar production fabs as Intel, and smaller firms can easily hire
these as well, it is to be expected that there are already loads of
Trojan processors in circulation. Tampering with the RNG by replacing it
with a PRNG is one potential manipulation. Other much more interesting
manipulations are hidden ways to get you from user into supervisor mode,
thus allowing attackers to completely circumvent a B3 multi-level
security OS trivially. Installing a root kit on dockmaster.ncsc.mil this
way would be fun. Who needs covert channels if you have a backdoor
instruction?
I have even better ideas, what a Trojan CPU manufacturer might want to
put into his hardware: Pentium and friends have all string copy machine
instructions. Add a tiny (LFSR) substring detection hardware to this,
and trigger an "interesting" effect once a specific rare substring is
processed. This could be the slow death of the processor within the next
30 minutes, or the immediate switch to supervisor mode and execution of
bytes following the magic string. No OS could protect you from a CPU
trap door like that. To shutdown the Iraqi defense system, you would
just send them email (or radar pulses?) with the right strings in it, and
no matter how secure the OS is, the CPU would bypass it all at a
hardware level. In a full-paranoia application, I might seriously
consider to remove from the compiler's code generator certain
string-handling instructions that make implementation of substring
triggered Trojans particularly easy.
> And there's of course Ross Anderson and Marcus Kuhn and their
> chip-stripping labs..
There is indeed an interest from government agencies in reverse
engineering capabilities to make sure hardware bought for the processing
of critical information has no trap-door. At the moment - if at all -
the only implemented protection is a controlled transport of components
between trusted (vetted) manufacturers.
At the moment, we ourselves can only look reasonably at chips with up to
two or three metal layers, because we use hydrofluoric acid wet etching
to strip off metal layers. Once we get access to a small reactive ion
etcher, we might also start looking at processors with more metal layers
such as the Pentium. I am told that workstation CPUs are actually easier
to understand than many of the 8-bit microcontrollers that smartcard
hackers normally work with. The latter have a layout that has been hand
optimized over more than a decade, while modern processor have much more
regular and much less optimized routing that was dumped directly out of
some VHDL netlist generator without the loving hand of a 1980s
microcontroller designer. Chip decompiling might not be as difficult as
it seems at first. We believe that much of it can be done cheaply
semi-automatically even using optical microscopy. I can now read 0.8 µm
CMOS designs with a single metal layer on micrographs of the metal and
the poly layer almost as easily as circuit diagrams. (Actually, if
someone here wants to do a PhD project in VLSI security, now would be a
pretty good time to talk to us.)
> If you can account for all the hardware in someone's chip in terms of a
> specified
> function, with no parts left over, you have some confidence that they're not
> occasionally leaking something they shouldn't, or faking a true RNG.
I do not think, the RNG or new covert channels are the main risk. The
dangers of bad CPU RNGs are easily compensated by post-processing the
random-bit string with a good software PRNG. For instance I would use
the Pentium III RNG mainly by stirring large chunks of it periodically
into the entropy pool of the Linux /dev/random driver, without
discarding the entire history of interrupt timestamps as an additional
source of entropy. Hardware RNGs often to not provide the bitrate of
high-quality randomness that the applications need, so you use them
primarily as one of several sources to generate the seed of a PRBG. I
also would test it at boot-time with at least the FIPS 140-1 tests, to
detect simple defect modes.
I believe that hidden substring matchers in CPUs are the most dangerous
form of Trojan circuitry.
Markus
--
Markus G. Kuhn, Computer Laboratory, University of Cambridge, UK
Email: mkuhn at acm.org, WWW: <http://www.cl.cam.ac.uk/~mgk25/>
