NetNews Usenet Archive 1992 #18/NN_1992_18.iso/spool/sci/crypt/2910

Text File | 1992-08-15 | 5.9 KB | 113 lines

Newsgroups: sci.crypt
Path: sparky!uunet!elroy.jpl.nasa.gov!decwrl!csus.edu!netcom.com!netcom!mjohnson
From: [e-mail] (Mark Johnson)
Subject: Re: The Next Pearl Harbor: We don't audit our chips
Message-ID: <[e-mail]>
Date: Sat, 15 Aug 92 22:55:47 GMT
Organization: Netcom Online Communications Service
In-Reply-To: [e-mail]'s message of Sat, 15 Aug 92 10:11:28 PDT
References: <[e-mail]>
Distribution: usa
Lines: 100

In article <[e-mail]> [e-mail] writes:

  >  I was at a cocktail party with a number of computer types who work
  >  clandestinely for foreign governments.  We got on the topic of silicon
  >  compilers, and how one of these computer types invented a virus that would
  >  infect silicon compilers, and add extra circuitry to each IC developed with
  >  them.  The circuitry was a AM transistor radio that when it received a
  >  signal of the proper duraton would cause the chip to fail.  It seems to
  >  me a "Pearl Harbor" in the making, what with the number of Unix based
  >  silicon compilers on the market, and all of them hooked up to networks.
  >  I'd hate to see all that expensive military hardware fail because we
  >  don't audit our chips and chipmaking software for this sort of thing.
  >  Any comments?
  >  Chris

I am one of those people.  But Chris got it wrong on several counts:

   (1) The virus doesn't infect silicon compilers, it infects hardware
       synthesis CAD programs ... the ones that take a high-level "RTL"
       description (like Verilog or VHDL) and munge it into gate
       primitives.  This software is used in ASIC design (gate arrays,
       standard cell semicustom chips).  Fortunately, all you have to
       do is figure out how to infect the program(s) of the major vendor
       in the field, because they have >75% of the market.

   (2) It isn't AM radio, it's FM.  The problem with AM is, there's
       too much interference and it doesn't propagate very well at
       >60,000 feet (where the missiles and/or the airplanes will be
       when we want them to veer off course).  Antennae for AM are
       also a lot more cumbersome than they are for FM.  This is
       especially true for our reception environment (on the die of
       a silicon chip): the chips are within packages which are
       on cards within cardcages, which are within replaceable
       modules, which are within electronics bays, which are within
       the exterior skin of the aircraft/missile/ship.

   (3) The triggering event isn't related to "a signal of the proper
       duration" at all!  Think about it: the synthesis program attaches
       this little hardware dongle to J Random Chip.  We have no idea
       what clock frequency this chip (that may not even get specified
       till next year) will operate at .... so we have no idea how many
       bits to put in a timing-counter.  Making a precision timer
       from on-chip elements (R's and C's) is no good either; how do
       we know what the resistance per unit length or the capacitance
       per unit area will be of J Random Chip Fab?  And even if we did,
       the values fluctuate from lot to lot, die to die, AND they are
       horribly temperature-dependent.

       No, the trigger mechanism is the receipt of a certain bitstring
       (using convolutional embedded-framing encoding), followed by
       its complement (using a different encoding).  We calculate the
       probability that exactly our bitstring will occur on our
       frequency "at random" or "by accident", is less than 2 to
       the minus 100 power.


   (4) The virus to generate the extra (secret) logic is the EASY
       part.  Remember that this stuff is MIL-STD-883, which means
       they have to run budjillions of design verification tests
       before they can ship a single chip for government use.  No,
       the hard part is the *other* viruses {yes, plural}, the ones
       that infect the design verification suite.

       Design verification for MIL STD parts starts with the completed
       chip, the one that pops out of synthesis.  This contains our
       secretly-added logic.  We need to find a way to prevent this
       logic from calling attention to its presence during design
       verification.  To make a long story short, the very hardest
       verification is the "stuck at fault coverage measurement".
       In this little beauty, the software systematically shorts
       every signal in the chip (one by one) to logic-1 and to logic-0,
       then applies the chip's manufacturing go/nogo tests.  If an
       internal signal is "Stuck At" a logic value, but all the
       tests pass anyway, that is BAD.  (It means you have a hole
       in your test coverage).  To defeat this, we were forced to make
       another virus that infects the stuck-at-coverage program too.


   (5) Our extra, secret logic is of some finite size; it takes
       transistors and gates to do what Chris said.  We didn't dare to
       emit this logic for small chips; the excess would be easily
       noticed by the engineers.  A second problem is, we can't
       significantly increase the power consumption (that would
       attract the engineer's attention too).  So there are some
       manufacturing technologies (e.g. the rad-hard MOS ones) that
       we simply don't dare to emit our logic upon.  And sadly, these
       chips often perform the coolest and thus most hackable
       functions in military gear (e.g. detonaters).

   (6) Pearl Harbor is not what we have in mind.  My esteemed
       colleagues, Ernst Blofeld and Dr. No, have a more sophisticated
       and elevated purpose than simple and crude surprise attack.


ACKNOWLEDGEMENT: the generous financial backing of Oswald Cobblepott
and of Sceptre Corporation has been instrumental in achieving these
objectives.  We express our sincere gratitude for their kind
assistance.

  -- M. Johnson