[comp.lsi] A Truly Secure

mark@mips.COM (Mark G. Johnson) (05/30/90)

There was an EPROM built which was indeed secure.  It was the Intel
27916 device, organized as 16K by 8 (128Kbits).  Intended for
applications such as storage of software [game cartridges are mentioned
in the paper], it prevents accesses unless the user proves s/he is
authorized.

A 64-bit key is programmed into the part.  However there is no way
to read the key out; the key only participates in the "authentication
handshake" protocol.

The chip enters the Locked mode upon power-up.  To unlock it, you
must authenticate yourself by proving that you know the 64-bit key.
The chip produces a 32-bit pseudorandom number, and encrypts it with
the key.  It presents this encrypted result on its pins.  The external
system must take this encrypted value and decrypt it, then return the
decrypted result to the 27916 EPROM.  If the decryption is correct
then the EPROM is convinced that you do indeed know the key, and it
unlocks.  Then the external system generates a random number, encrypts
it with the key, and presents this to the EPROM.  The EPROM decrypts
it and hands back the result.  If the decryption is correct, then the
system knows the EPROM contains the right key, and the handshake protocol
is completed.

For simplicity, and also to increase sales volume, Intel built the entire
pseudorandom number generator and encryption/decryption hardwire right
onto the 27916 EPROM chip.  Thus the software contains an EPROM, and the
system contains another EPROM (used to unlock the software).

Much of the technical paper is devoted to a discussion of the encryption
function and the psuedorandom number generator.  I will however note here
that the random number outputs were subjected to several statistical tests,
and that the generator is carefully arranged so as not to produce the same
random number upon each power-up.

It's a good read; I recommend having a look at

   L. Letham, D. Hoff, and A. Folmsbee, "A 128K EPROM Using Encryption of
   Pseudorandom Numbers to Enable Read Access," IEEE Journal of Solid
   State Circuits, Vol. SC-21, No. 5, October 1986, pp. 881-888.


Also, I recommend talking to your favorite IC engineer and asking
the question "Suppose I want to use microprobes to discern the logic
states on 64 different signals of a chip, and suppose those signals
don't connect to the metal layer.  How easy and/or costly would this be,
and how many samples (chips) would be required?"
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^--- this is the yucky
                                                   part; even the best
                                                   probe operators mangle a
                                                   die after N<<64 probings.
                                                   For spazzes like me, it's
                                                   a lucky day if N=10 and
                                                   that's if they're metal!!
                                                   (metal is easiest to probe)
-- 
 -- Mark Johnson	
 	MIPS Computer Systems, 930 E. Arques M/S 2-02, Sunnyvale, CA 94086
	(408) 524-8308    mark@mips.com  {or ...!decwrl!mips!mark}

mpe@shamash.cdc.com (2375) (05/30/90)

The simplest method to by-pass security shells on any computer (or in
this case an EPROM) would be to allow the target computer to present
itself to the EPROM at power-up and receive the necessary validation and 
later access the EPROM from the run-time evironment.  Some OS kernels will
even assist the process by copying the slower EPROM into faster SRAMS.

Another fact which an attaching user can use to gain access to the EPROM
would be the non-protected startup code which must contain the algorithm
to authorize the users.  The password and transformation functions must
be contained in a machine (and unfortunately user) readable area of the
machine (usually a ROM/PROM/PLA/EPROM etc).

All the new Intel chip family has done to protect the ROM code is to 
break the job of duplicating the code a two part task.  First hack the
password signature and transform function, than apply it to the protected
EPROM and read the contents into a temp buffer.

mark@mips.COM (Mark G. Johnson) (05/30/90)

In article <21908@shamash.cdc.com> mpe@shamash.cdc.com writes:
  >The simplest method to by-pass security shells on any computer (or in
  >this case an EPROM) would be to allow the target computer to present
  >itself to the EPROM at power-up and receive the necessary validation and 
  >later access the EPROM from the run-time evironment.  Some OS kernels will
  >even assist the process by copying the slower EPROM into faster SRAMS.

But remember that the EPROM is designed for use in a game cartridge,
whose host machine will apply both ends of the authentication
handshake: (1) EPROM verifies that host contains secret key; (2)
host verifies that EPROM contains secret key.  The goal is to prevent
folks from copying game cartridges.

A game cartridge must contain one of these Intel EPROM chips so that
it can perform the hardware handshake.  If you know what bits to
program into the data-store area of the ROM, that's most of the battle,
but you still need to know how to program the KEY bits so your duplicate
EPROM can perform both halves of the hardware handshake.  Otherwise the
host will refuse to talk to you.

If all you want to do is read out the contents of the datastore of
the ROM and you don't give a hoot about the key, just purchase a
legimitate cartrige, remove the plastic housing, clip a logic analyzer
onto the pins of the ROM and record the address/data pairs as they whizz by.

Aside: Pull down your Intel catalog and look for 27916.  It isn't there.
       I guess the game cartridge market might have evaporated before
       Intel was ready to deliver the part.  Or, mebbe customers decided
       they didn't like Intel's scheme (or, dare I say, Intel's price?).

Rumor has it that Nintendo game cartridges contain ROMS that are somehow
abnormal (encrypted?  wacko custom chip design that doesn't correspond
to any commercial part, e.g. 48K by 11bits?), and that this is how
they guarantee they are the only source of [highly lucrative] cartridges.
-- 
 -- Mark Johnson	
 	MIPS Computer Systems, 930 E. Arques M/S 2-02, Sunnyvale, CA 94086
	(408) 524-8308    mark@mips.com  {or ...!decwrl!mips!mark}

hedley@iitinc (Hedley Rainnie) (06/01/90)

> 
>  Mark Johnson	mark@mips.com  writes
>
> Rumor has it that Nintendo game cartridges contain ROMS that are somehow
> abnormal (encrypted?  wacko custom chip design that doesn't correspond
> to any commercial part, e.g. 48K by 11bits?), and that this is how
> they guarantee they are the only source of [highly lucrative] cartridges.
> -- 

The Nintendo is actually protected by a patented micro controller an 
identical one on both the cartridge and base unit. The two chips operate
at ~4Mhz and use a serial link to communicate with each other. The mother
board chip is master and the cartridge chip is wired with the master/slave
pin as slave, on power up a random 4 bit code is transmitted to the slave.
This chooses a permutation of an algorithm that will begin some clock cycles
later. Data does is passed back and forth at a slower rate than the 4Mhz clock
and each chip monitors the data coming in to it. If for some reason there is
an error in the data, the mother board chip detects this and will after some
cycles yank down on reset to the 6502. The net result of this can be seen on
a Nintendo with no cartridge, it repeatedly resets. The algorithm is chosen
so no two sequences are the same over time (at least a long time). The IC
itself is a 4bit microcontroller with its ROM protected by P-implant in P-Well.

Happy probing!

Hedley

{decwrl|sun}!imagen!iitinc!hedley  | Integrated Information Tech.
hedley@imagen.com		   | Santa Clara, CA. (408)-727-1885 x49
-- 
{decwrl|sun}!imagen!iitinc!hedley  | Integrated Information Tech.
hedley@imagen.com		   | Santa Clara, CA. (408)-727-1885 x49

davidc@vlsisj.VLSI.COM (David Chapman) (06/01/90)

In article <39144@mips.mips.COM> mark@mips.COM (Mark G. Johnson) writes:
>There was an EPROM built which was indeed secure.  It was the Intel
>...
>Also, I recommend talking to your favorite IC engineer and asking

You rang?  :-)

>the question "Suppose I want to use microprobes to discern the logic
>states on 64 different signals of a chip, and suppose those signals
>don't connect to the metal layer.  How easy and/or costly would this be,
>and how many samples (chips) would be required?"

I'd say 1 chip and not that expensive.  All you need is the Schlumberger
E-beam prober.  Assuming that the E-beam won't erase your EPROM (and I
don't know the answer to that one), you can read the signals directly
off the chip.  Chip designers love them; they can compare the signals
on the chip with their simulations (we have one, and I'm told it works
like a charm)!

No physical probing is necessary.

P.S.  "Not that expensive" is marginal cost; the prober itself is $500K,
      I think.
-- 
		David Chapman

{known world}!decwrl!vlsisj!fndry!davidc
vlsisj!fndry!davidc@decwrl.dec.com

stripes@eng.umd.edu (Joshua Osborne) (06/01/90)

In article <39146@mips.mips.COM> mark@mips.COM (Mark G. Johnson) writes:
>Rumor has it that Nintendo game cartridges contain ROMS that are somehow
>abnormal (encrypted?  wacko custom chip design that doesn't correspond
>to any commercial part, e.g. 48K by 11bits?), and that this is how
>they guarantee they are the only source of [highly lucrative] cartridges.

They have some sort of conversation - 4 or 60 times a sec (I forget which)
the NES asks the cartrage whats up, the cartrage replys.  If the cartrage
replys wrong the reset line (on the 6502-like thing, or the VDU I forget
which) is asserted.  This trace could be (and has been) cut, but then you
lose the ability to hit RESET from the front panel.  The "lockout" chip can
be moved from one cartrage to another (it is distinct from the ROM/RAM on
the cartrage).  They are not impossable to duplicate, but they are hard,
from 2 to 4 componys have done it.
-- 
           stripes@eng.umd.edu          "Security for Unix is like
      Josh_Osborne@Real_World,The          Mutitasking for MS-DOS"
      "The dyslexic porgramer"                  - Kevin Lockwood
"Don't try to change C into some nice, safe, portable programming language
 with all sharp edges removed, pick another language."  - John Limpert

rgupta@portia.Stanford.EDU (Rajesh Gupta) (06/02/90)

In article <39144@mips.mips.COM> mark@mips.COM (Mark G. Johnson) writes:
>There was an EPROM built which was indeed secure.  It was the Intel
>27916 device, organized as 16K by 8 (128Kbits).  Intended for
>applications such as storage of software [game cartridges are mentioned
>in the paper], it prevents accesses unless the user proves s/he is
>authorized.
>
...
>Also, I recommend talking to your favorite IC engineer and asking
>the question "Suppose I want to use microprobes to discern the logic
>states on 64 different signals of a chip, and suppose those signals
>don't connect to the metal layer.  How easy and/or costly would this be,
>and how many samples (chips) would be required?"
>^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^--- this is the yucky
>                                                   part; even the best
>                                                   probe operators mangle a
>                                                   die after N<<64 probings.
>                                                   For spazzes like me, it's
>                                                   a lucky day if N=10 and
>                                                   that's if they're metal!!
>                                                   (metal is easiest to probe)


well, you don't really need to (pico)probe it. if you have enough $$,
you can use ebeam probing with some kind of voltage contrast enhancement
techniques.

happy SEMing...

Rajesh

rgupta@sirius.stanford.edu

dirk@dksoft.incom.de (Dirk Koeppen) (06/08/90)

I am looking for a PROM which includes some security for the burned-in
software. There is no need for full security or encryption. All I need
is a device which can not be copied with usual PROMers. Is anybody
aware of a 27128 compatible pinout devices which prevents or difficult
coping ?

Thanks,
dirk