United States Patent £19]
`Schwartz et al.
`
`(54] METHOD AND APPARATUS FOR SECURING
`EXECUTABLE PROGRAMS AGAINST
`COPYING
`
`(75]
`
`Inventors: Edward L. Schwartz, Sunnyvale;
`Michael J. Gonnish. Los Altos, both
`of Calif.
`
`[73] Assignees: Ricoh Company, Ltd •. Tokyo. Japan;
`Ricoh Corporation. Menlo Park, Calif.
`
`(21] Appl. No.: 423,402
`
`Apr. 18, 1995
`
`(22] Filed:
`Int. Cl.6
`........................................................ H04L 9/00
`(51]
`[52] U.S. Cl. ................................................... 380/4; 380/49
`(58] Field of Search ........................... 380/4, 49; 375/240
`
`(56]
`
`References Cited
`
`U.S. PIJENT DOCUMENfS
`
`9/1979 Best ............................................ 380/4
`4,168,396
`2/1984 Best ............................................ 380/4
`4,433,207
`8/1984 Best ............................................ 380/4
`4,465,901
`4,558,176 12/1985 Arnold et al ............................... 380/4
`4,562,305 12/1985 Gaffney, Jr .................................. 380/4
`4,905,277
`211990 Nakamura ................................... 380/4
`1/1995 Arnold et al ............................... 380/4
`5,379,342
`4/1996 Hamilton et al .......................... 380/49
`5,504,816
`5,533,051
`7/1996 James ...................................... 375/240
`5,544,244
`8/1996 Ogura .......................................... 380/4
`
`FOREIGN PIJENT DOCUMENTS
`
`0 536 943 A2.
`
`4/1993 European Pat. Off ..
`
`111111111111111111111111 lllll lllll lllll 1111111111111111111111111111111
`US005675645A
`[11] Patent Number:
`(45] Date of Patent:
`
`5,675,645
`Oct. 7, 1997
`
`OTHER PUBLICATIONS
`
`Donald E. Knuth. 'The Art of Computer Programming,"
`Addison-Wesley Publishing Company, Second Edition, p.
`28.
`David Sheff. "Game Over: How Nintendo Zapped an Ameri(cid:173)
`can Industry. Captured Your Dollars, and Enslaved Your
`Chldren," Random House, Inc. (1993). pp. 160-161.
`
`Primary Examiner-Salvatore Cangialosi
`Attome}\ Agent, or Finn-Philip H. Albert; Townsend and
`Townsend and Crew LLP
`
`(57]
`
`ABSTRACT
`
`A secure system for executing program code in an insecure
`environment while making it impossible, or at least
`impractical, to determine how to copy the program code and
`associated data is provided. A program memory contains
`encrypted program data and security circuitry contained
`within an integrated circuit is provided for decrypting the
`program data as it is needed by a processor. A portion of the
`processing steps which would be done by the processor in an
`insecure system is performed in this secure system within
`the secure circuitry using portions of the decrypted program
`data which are not provided to the processor. Program data
`is parsed it out based on a proper request to the security chip
`from the processor. A key value stored in volatile memory is
`used in the decrypting process and the volatile memory is
`positioned on the integrated circuit such that its contents are
`lost before a chip peel provides access to the volatile
`memory.
`
`33 Claims, 8 Drawing Sheets
`
`,100
`
`BRANCH SE PARA TOR
`
`102
`
`108
`
`110
`KEY
`
`ENCRYPT OR
`
`Encrypted
`ROM
`
`1
`
`KINGSTON 1004
`
`

`

`Ut
`~
`~
`Ut
`.....)
`Q\.
`,...
`Ut
`
`~
`
`1--1
`t"'t-
`~
`~
`
`00
`s,
`
`.....:i
`'-=
`'-=
`lo-I
`
`_......:.
`~
`0
`
`~ = ~
`~ = ~
`
`•
`7J'J.
`•
`Cj
`
`I
`•
`
`II
`
`18
`
`Input Devices
`
`Video Display
`
`16
`
`Figure 1
`
`CPU
`
`~
`
`BUS TAP
`
`security
`
`ADDR
`
`2
`
`Control Tools
`
`I 431 Analysis and
`
`22
`
`14
`
`42
`
`12
`
`I
`
`24 I ,..., _ ., I I
`
`10
`
`

`

`01 "' ~
`
`01
`
`....:J
`Q'\
`.,..
`01
`
`~ a
`
`QC
`~
`N
`
`~
`
`~
`
`,....:t
`fl
`0
`
`~ ;-= """"'
`
`00. •
`~ •
`
`~ 30
`
`TOEX TERNAL
`
`14
`
`BU: ...
`
`UNIT -
`BUS ...
`
`__.. 50
`
`Figure 2
`
`74
`
`i,...;
`
`-
`
`--
`
`---.
`
`...
`'"
`
`PRIVATE TABLES
`
`"'-----
`
`76 -
`
`i,...;
`
`CLOCK
`TIME
`REAL-
`
`l
`
`-
`
`BUS TAPS
`
`BRANCH RESPONSE ~ .
`BRANCH REQUEST
`
`RESPONSE
`
`DATA REQUEST/
`
`~
`
`-
`
`-
`
`-
`
`I
`
`~
`I ROM DATA
`
`ROUTER I
`
`CLEAR
`
`_..70
`
`DE COM-H
`
`HIDDEN DATA
`
`PRESSOR
`
`68
`
`~
`
`REQUEST
`
`ROM ACCESS
`
`... -
`
`TRANSLATE/CACHE CONTROL
`
`_,52
`
`+
`
`72
`
`__..
`
`;. DECRYPTOR f-+
`
`62
`
`-
`
`64
`
`,,
`
`KEY
`
`(
`60
`
`_.J
`
`~56 ,,
`'"
`
`CACHE
`
`54
`
`-
`
`D JATA
`
`... -
`A DOR
`
`ROM
`TO
`
`COMPUTATIONAL UNIT (CU)
`
`3
`
`

`

`U.S. Patent
`
`Oct. 7, 1997
`
`Sheet 3 of 8
`
`...__ _____ _..-
`-
`
`~
`
`112
`GAME PROGRAM~
`
`5,675,645
`
`'100
`
`.,
`
`BRANCH SEPARATOR
`
`J02
`
`~-__.·,----... 114 r-------... 116 ~-----...... J18 ,,_--'--...... J20
`
`...._
`
`~
`
`TIMING
`DATA
`
`32
`
`~
`
`Encrypted
`ROM
`
`......_----~~
`
`SECURE
`PROGRAM
`
`~ ...._
`........_
`CHECKSUM
`BRANCH
`DATA
`TABLE
`
`~
`
`' '
`
`1 '
`
`,,
`
`''
`
`COMPRESSOR
`
`104
`~
`
`,,
`
`JOB
`
`110 -C KEY
`
`____ 1
`-
`'1----•~
`
`ENCRYPTOR
`
`Figure 3
`
`4
`
`

`

`U.S. Patent
`
`Oct. 7, 1997
`
`Sheet 4 of 8
`
`5,675,645
`
`Security Chip
`
`Processor
`
`Start
`
`N
`
`Extract Page from ROM
`
`I
`I
`I
`S4 I
`I
`$51
`I
`I
`Place Hidden Data in Private Tables I
`I
`I
`I
`I
`
`56
`
`Return Page in Clear
`
`Request Page of
`Instructions/Data
`
`81
`
`Halt Processor
`
`83
`
`Get Next Instruction
`
`87
`
`S11
`
`N
`
`Pass Branch
`Request to
`Security Chip
`
`Figure 4A
`
`5
`
`

`

`U.S. Patent
`
`Oct. 7, 1997
`
`Sheet 5 of 8
`
`5,675,645
`
`Security Chip
`
`Processor
`
`S9
`
`Execute Instruction
`
`S13
`
`Go to New Address
`
`Calculate Branch Address
`
`S14
`
`N
`>------£-----.c Halt Processor
`I
`I
`I
`I
`I
`I
`$151
`------~----...::;; I
`Pass Next Address to Processor--------
`I
`I
`I
`I
`I
`I
`I
`I
`I
`I
`I
`+
`Figure 48
`
`6
`
`

`

`U.S. Patent
`
`Oct. 7, 1997
`
`Sheet 6 of 8
`
`5,675,645
`
`524
`~
`
`__ TIME INPUT FROM
`REAL-TIME CLOCK 76
`
`BUS TAP CHECKSUM
`ScM
`-
`LOGIC
`_ 514
`
`_,512
`
`CONTROL
`
`----. REG
`
`DATA IN REG
`r
`
`506
`
`,_.
`502 510
`
`-
`
`H
`
`_sos
`
`r
`
`VALUE
`
`TYPE
`
`CHECKSUM
`PASSWORD -
`TIMING
`
`516
`
`-
`
`500
`
`)
`
`i---+ERROR
`SIGNAL
`
`MUXCONTROL
`-
`
`STACK
`CONTROL
`
`BRANCH
`TABLE
`
`.....-----. 518
`ADDRESS 1
`MUX ~
`BRANCH
`1-------------+--------+~-
`r--+ ADDRESS
`ADDRESS 2
`OUTPUT
`
`520
`o~
`NEXT 1
`1-------------+----ti---+---+1 MUX _
`NEXT2
`
`INITIAL VALUE
`
`PENDING (NEXT BRANCH INDEX)
`
`STACK
`
`522 -
`
`Figure 5
`
`7
`
`

`

`U.S. Patent
`
`Oct. 7, 1997
`
`Sheet 7 of 8
`
`5,675,645
`
`SCRAMBLED
`OUTPUT
`
`Mux
`
`106
`
`608A
`
`Buffer
`
`6088
`
`Buffer
`
`608C
`
`Buffer
`
`Compressed
`Data Stream
`
`Demux
`
`606
`
`Pseudo-
`Random
`Number
`Generator
`(PRNG}
`
`Key Value
`
`Figure 6
`
`8
`
`

`

`U.S. Patent
`
`Oct. 7, 1997
`
`Sheet 8 of 8
`
`5,675,645
`
`712
`
`716
`
`KEY
`CLOCK
`
`POWER
`SOURCE
`
`r100
`
`Key Load
`
`Key In
`
`Key Shift Register
`
`In it/Run
`
`714
`
`MLS
`CLOCK
`
`702
`
`704
`
`MAXIMAL LENGTH SEQUENCE (MLS)
`SHIFT REGISTER
`
`710
`
`Figure 7
`
`9
`
`

`

`5,675,645
`
`1
`METHOD AND APPARATUS FOR SECURING
`EXECUTABLE PROGRAMS AGAINST
`COPYING
`
`BACKGROUND OF THE INVENTION
`
`The present invention relates to the field of securing
`executable programs against copying. More specifically, in
`one embodiment the invention provides security against
`copying in an open hardware system where access to the
`processor executing the program and the memory holding
`the program is assumed.
`Securing computer programs (software) against unautho(cid:173)
`rized copying has been a concern of software developers
`since software was sold as a separate product. The difficulty
`lies in the fact that software is easily copied and any copy
`protection or prevention scheme must allow for the eventual
`copying of portions of the software if it is to be executed.
`Unless the software is secured in a chip (integrated circuit)
`which also contains the microprocessor which will execute
`the software, the executed portions of the software must pass
`from the distribution media to the processor along circuit
`lines which are monitorable. Thus, for a program to be
`secure and still be useful to its intended user, the program
`cannot be readily copyable in its generally available form or
`in the form in which it is executed by the intended user.
`Recently. with the increasing need for technical support
`from a program's developer, the desire for complete
`documentation, and the fear of viruses, unauthorized copy(cid:173)
`ing of some software, especially critical business software,
`has diminished. However, where software needs no support
`or documentation and is used on systems where viruses
`cannot be transmitted, such as video game systems using
`video game cartridges with game software stored in read(cid:173)
`only memory (ROM). unauthorized copying is still preva(cid:173)
`lent. All that is needed is an understanding of the circuitry
`used in the game cartridge and a copy of the game program.
`An additional concern of the makers of video games, who
`typically make video game consoles and wish to limit their
`use to games produced by licensed software producers, is
`not software copying, but video game console copying to
`produce consoles which will execute authorized game car(cid:173)
`tridges or unauthorized, but compatible, game cartridges.
`In an unprotected system, a copyist (i.e., a "software
`pirate" or other unauthorized analyzer or copier of the
`software) can easily copy program code if it is accessible.
`Program data, as used herein refers to the data necessary to
`run the program. which includes instructions (program
`code). tables of values and image data used to generate
`screen images. Even if the program data is not easily
`accessible in its distributed form, a copyist might obtain it by
`observing a bus between the storage media which holds the
`program data and the processor to determine the program
`code. Thus. encryption of the program data alone does not
`provide real protection, since it must be decoded eventually
`to be used. Where the program data is stored on video game
`cartridges and the processor is on a video game console,
`analyzing the program data is simplified. since the interface
`between the storage media and the processor is readily
`available without any hidden communication. In many video
`game consoles. the entire bus of the CPU is readily available
`for analysis. This particular problem, of course, extends to
`all forms of program storage media which are detachable,
`not just video game cartridges.
`Many copy protection systems are a deterrent to casual
`copyists. but not to determined copyists, who might be
`willing to spend large sums of money and time to break a
`copy protection scheme in order to be able to manufacture 65
`large numbers of unauthorized copies of a program. For
`some casual copyists. it is enough to include software-only
`
`2
`copy protection, such as the use of secret files or codes not
`normally accessed or observed by a casual copyist. Many
`casual copyists will also forgo copying when copying
`involves construction of cartridges, since this requires the
`ability to make plastic cases and circuit boards. However,
`the most determined copyists of cartridges are those who
`plan to make large numbers of cartridges for sale and thus
`have the ability to make cartridges once the program data is
`copied.
`Software-only copy protection systems, which might use
`10 an undocumented portion of the program data media to store
`hidden codes. generally rely on "security through obscurity"
`to prevent only those who are not aware of the copy methods
`from making workable copies. Therefore. when the goal is
`to stop large-scale and educated copyists. software-only
`protection is not viable. Fortunately, where the program data
`15 is distributed on media containing hardware elements, as is
`the case with video game cartridges, hardware copy protec(cid:173)
`tion can be included on the cartridge.
`Many hardware protection systems rely on the presence of
`a hardware circuit or device which signals the existence of
`20 an authorized copy of the program. The program, when
`executed. runs a routine to check for the existence of the
`authorization device. If the authorization device is not
`present, the program refuses to continue or performs some
`other undesirable action. These protection systems are open
`25 to two methods of attack. both of which could render the
`protection ineffective.
`In a first type of attack. a copyist would analyze the
`circuitry of the hardware authorization device to determine
`its essential elements and from that information make
`30 duplicate, unauthorized authorization devices. Even if the
`details of the authorization device are buried in a custom
`integrated circuit, the integrated circuit could be examined
`under a microscope layer-by-layer using a chemical peeling
`process to resolve the circuit features. The operation of the
`35 authorization device might also be observed by slowing
`down or speeding up both the authorization device circuitry
`and the processor to aid in the detailed analysis of one
`operation or the high-speed analysis of many passes over the
`program.
`In a second type of attack. the copyist attempts to modify
`40 the software routines which check for the exists of the
`authorization device so that the routines always report back
`that the authorization device is in place, whether or not it
`actually is. With a readily-available logic analyzer attached
`to a microprocessor running a program. a copyist can run the
`45 processor at a slow speed and have the logic analyzer record
`all instructions executed by the microprocessor and all the
`data traffic to and from the microprocessor, then use this
`information to determine the flow of the program. If the flow
`of the program is recorded both with the authorization
`50 device in place (simulating an authorized use) and without
`the authorization device in place (simulating an unautho(cid:173)
`rized use), the copyist can compare the flows and determine
`where in the program the decision is made as to whether the
`authorization device is in place. Once that location is
`55 determined. the software at that location could be modified
`so that the routine which tests for the presence of the
`authorization device never fails. This can often be done by
`replacing one conditional jump instruction with an uncon(cid:173)
`ditional jump or a NOP (null operation).
`Therefore, what is needed is an apparatus which allows a
`60 processor to execute program code, over a possibly insecure
`bus. while requiring an impractical amount of work on the
`part of a copyist to reproduce the program data for use apart
`from the apparatus or to reproduce the apparatus.
`SUMMARY OF THE INVENTION
`The present invention provides a secure system for
`executing program code in an insecure environment while
`
`10
`
`

`

`5,675,645
`
`4
`To make a chosen text attack on the encrypted program
`data more difficult. the program data could be compressed
`first to remove patterns in the data.
`The encryption and decryption could be done as conven(cid:173)
`tional encryption/decryption. However. where low hardware
`cost is a priority. the encryptor could be just a data scrambler
`which rearranges the order of the bits or bytes of the
`program data according to the output of a PRNG. The data
`decryptor is then just a series of buffers. a multiplexer and
`10 a demultiplexer. Where the security chip includes
`decompression. the buffers might already exist in the decom(cid:173)
`pressor. If the scrambler is used in addition to other
`encryption. a chosen text attack is made more difficult, since
`the position of any word or bit in the data cannot be inferred.
`The PRNG is seeded by the key value or some agreed upon
`15 value dependent on the key. Because the file is compressed.
`less robust encryption can be used. To further defend against
`analyses in which many different sections of the encrypted
`program data are compared with the corresponding
`decrypted data to determine the key value, a secondary key
`20 value which varies from section to section could be used.
`The secondary key value could be a value generated from
`data stored with the program data and the main key value.
`Alternatively. a table of secondary keys could be stored with
`the program data or in the security chip. with the main key
`25 value used to select keys from the table.
`In some applications. it is also desirable to prevent the
`operation of an authorized game cartridge on an unautho(cid:173)
`rized game console. For these applications, the game con(cid:173)
`sole is provided with a difficult to copy element and the
`30 security chip on the game cartridge requires this element to
`be present before operating.
`A further understanding of the nature and advantages of
`the inventions herein may be realized by reference to the
`remaining portions of the specification and the attached
`35 drawings.
`
`3
`making it impractical to determine how to copy the program
`code or associated data. In one embodiment of a secure
`system according to the present invention, a program
`memory contains encrypted program data (program
`instructions. data tables. digitized images, etc.) and security
`circuitry contained within an integrated circuit is provided
`for extracting the program data as it is needed by a processor.
`In various embodiments. the processor is a central process(cid:173)
`ing unit (CPU). a video pixel processor or other low-level
`CPU requiring program data. A portion of the processing
`steps which would be done by the processor in an insecure
`system is performed in this secure system within the secure
`circuitry using portions of the decrypted program data which
`are not provided to the processor. Program data is parsed
`based on a proper request to the security chip from the
`processor. The security chip tracks which sections of the
`program memory are proper for the processor to be request(cid:173)
`ing based which program code in being executed. The
`security circuitry includes a key register in which a key
`value, needed to decrypt the program code, is stored. For
`security. a different key value can be used for each different
`program.
`Where a risk of chip peeling exists. the key might be
`stored in volatile memory powered by a battery or stored as
`charge on capacitor. positioned and/or distributed on the
`security chip surface such that a chip peel breaks the source
`of power to the volatile memory well before the volatile
`memory can be reached.
`In a specific embodiment. the security chip extracts the
`branch statements from the program instructions and stores
`them in an internal branch table after decryption and before
`providing the instructions to the processor. In a preferred
`embodiment. the branch statements are separated before
`being encrypted and stored in the program memory. Because
`the possible fiows of the program are known from the branch
`table. the branch table only need contain a listing of the
`branches which are imminent. thereby saving memory.
`In various embodiments. the encryption is complex con(cid:173)
`ventional encryption while in others, to save hardware. is
`simpler encryption such as XOR'ing with the output of a
`pseudorandom number generator (PRNG). A number of
`additional security measures can be applied where needed. 40
`For example. if the security chip is positioned to read the
`processor bus. a tap of the processor bus can be provided so
`that the security chip can monitor all instruction fetches and
`data fetches from memory. For example. since the security
`chip provides all the branch information, the program fiow 45
`between branches is linear and deterministic. Thus, the
`security module could perform a checksum on all the bus
`activity between branches, compare it to a precompiled
`checksum and refuse to provide more branch information if
`the checksums do not match. as would be the case if the 50
`instructions provided to the processor had been modified in
`some way.
`The security chip could also include a real-time clock. RC
`(resistor-capacitor) time constant circuit. or other dynamic
`logic circuit to confirm that the processor is executing
`instructions at an expected rate. This prevents a processor
`from being accelerated to speed up the process of running
`the program through all the possibilities needed to build an
`unauthorized branch table or from being slowed to perform
`hardware analysis.
`Furthermore. because the security chip maintains the 60
`branch table. it can calculate what the next branch is. so that
`the processor only need provide the values neetled to
`evaluate whether to take a conditional branch. In order to
`handle return instructions. the security chip also maintains
`the program stack for the processor. This security feature 65
`prevents the processor from requesting unexpected branch
`information.
`
`55
`
`BRIEF DESCRIPTION OF THE DRAWINGS
`FIG. 1 is a block diagram of a computer system according
`to the present invention wherein program data resides on a
`cartridge connected to a processor over a plug-in bus includ(cid:173)
`ing a security chip on the cartridge;
`FIG. 2 is a more derailed block diagram of the security
`chip;
`FIG. 3 is a block diagram of a system used to encrypt
`programs onto encrypted memories which are used in the
`cartridges;
`FIGS. 4A and 4B together show a fiow chart of an
`execution of a program by the processor;
`FIG. 5 is a block diagram of a branch unit;
`FIG. 6 is a block diagram of a dam stream scrambler; and
`FIG. 7 is a block diagram of a pseudorandom number
`generator.
`
`DESCRIPTION OF THE PREFERRED
`EMBODIMENTS
`FIG. 1 shows a common application for the present
`invention. namely video games. It should be apparent after
`reading this disclosure that the invention is not limited to
`video games or programs stored on cartridges. In FIG. 1. a
`game console 10 is shown with a game cartridge 12 about to
`be mated to game console 10 via a bus 14. We assume herein
`that a copyist is able to read the game program and game
`data as it is stored in game cartridge 12 and is also knows
`everything that goes on in game console 10. According to
`the preferred practice in the design of security devices, we
`also assume that the copyist knows all the derails of any
`security circuits and algorithms except for any keys or
`
`11
`
`

`

`5,675,645
`
`10
`
`5
`passwords. Because the primary goal of the system is to
`allow a legitimate user to run the program. it is impossible
`to prevent the copyist from determining the outcome and
`flow of the program by running it with a given set of input
`data. Thus, the goal of the security of this system is to
`require that the program actually be run, at normal speed.
`and limit the amount of information about the program
`which can be inferred from one execution of the program
`with one input data set. The impracticality of determining
`the actual program code and data is based on the fact that the
`number of input data sets which would have to be run
`against the system is so high that the time needed to perform
`such an analysis is greater than, or comparable to. the time
`span in which the bulk of the legitimate sales of the program
`are made.
`Game console 10 is shown with a processor 20, local 15
`memory 22. an output interface to a video display 16. an
`input interface from input devices 18, and a circuit clock 24.
`Game console 10 might include other elements not shown.
`The input devices 18 are shown generically, since they are
`not the subject of the present invention, but might include 20
`keyboards. joysticks. touch pads or sensor arrays. Video
`display 16 is typically a pixelated display (e.g .• a raster
`monitor) which displays a two-dimensional array of pixels
`colored as indicated by processor 20 or an intermediate
`video memory (not shown). Local memory 22 stores vari- 25
`ables used in the execution of the program as well as a
`current page of instructions of the program. Local memory
`22 need not store the entire program at once. since the
`program can be paged into local memory 22 as needed. As
`should be apparent from this description, the security system 30
`is described with reference to processor 20, the CPU of
`game system, however the present invention might also be
`used with a video processor. image processor or other
`processor present in the system.
`Game cartridge 12 is shown with a security chip 30 and
`a ROM 32. Other forms of storage can be substituted for
`ROM 32. such as CD-ROM (compact disk ROM). diskette,
`flash memory, or even remote programs accessed via a
`network. ROM 32 contains the game program in an
`encrypted form. The game program so stored comprises
`program executable cede, data tables. graphic images and 40
`other related objects which are necessary or related to the
`operation of the game embodied by the cartridge. In a
`preferred embodiment. security chip 30 is a single integrated
`circuit with no secure data streams flowing on externally
`accessible pins.
`The present invention cannot protect against all attacks.
`For example. if a copyist obtains the game program in its
`unencrypted form from an unscrupulous employee of the
`game maker. the present invention will not prevent the
`copyist from distributing the game in that form. It is 50
`assumed here that the unauthorized copyist only has access
`to a game console and a number of game cartridges. With
`this limited access, the copyist will attempt to analyze the
`operation of the console and cartridges using various analy-
`sis and control tools shown as tools 40 in FIG. 1. An analysis
`tool records signals. while a control tool changes the signals,
`often while an analysis tool is recording signals. Such tools
`include microprocessor trace analyzers, waveform
`generators. oscilloscopes. etc. FIG. 1 shows various places
`within the game console 10 and game cartridge 12 the
`copyist could tap to analyze and control signals. 60
`Significantly. the copyist cannot tap onto internal lines of
`security chip 30 without chemically peeling the security chip
`and working on a microscopic level.
`A tap 41 to circuit clock 24 might be used to slow down
`the processing speed of game console 10 to more easily 65
`analyze its operation. or used to speed up circuit clock 24 to
`more quickly execute many instructions to test different
`
`6
`variations of the program. To render this tap ineffective,
`security chip 30 might also maintain a clock whose speed is
`determined internal to security chip 30 and refuse to decrypt
`program data from ROM 32 if circuit clock 24 does not run
`at the correct speed.
`A tap 42 to ROM 32 provides the copyist with the
`contents of ROM 32. but these contents are not useful
`without the decryption provided by security chip 30. A tap
`44 on the data traffic on bus 14 or a tap 43 on the data traffic
`between processor 20 and local memory 22 might provide
`decrypted program information, but would only provide the
`instance of the program sequence which applies to one
`execution of the game instead of a sequence which is usable
`for different sets of input. Furthermore. that information
`does not include branching instructions. as those are not sent
`to the processor. but are executed in security chip 30.
`The same is true for a tap 45 on the video display. While
`tap 45 might be able to record all the video signals, they
`would only correspond to one particular playing of the
`game. For example, if a game level containing unique
`graphics is never reached. the graphics at that game level
`will never be sent to video display 16 and therefore cannot
`be obtained by tap 45.
`A determined copyist might use a tap 46 on the signals
`between input devices 18 and processor 20 to insert signals
`simulating different outcomes and events in the game. With
`enough different paths. a copyist might be able to determine
`all the possibilities and work backwards to reconstruct the
`game program. but because the speed of the processor
`cannot be increased and due to the sheer number of
`possibilities. the copyist is not likely to be able to do this
`between the time a game is released to the public and the
`game sells enough copies to diffuse the copyist's potential
`market
`Thus, even with all these taps. a copyist having access to
`only game console 10 and game cartridge 12 cannot make a
`full, usable copy of the game program. A determined copyist
`might tap into the internals of security chip 30 itself. which
`would require careful removal of the casing of the security
`chip and a layer-by-layer analysis of security chip 30.
`However, even knowing the entire internal circuitry of
`security chip 30, the copyist will not obtain the volatile
`settings of the key needed for decryption of ROM 32. since
`the memory holding the key is designed to lose power as
`layers are removed. If the memory is many layers below the
`layers required for power, the memory will be erased before
`45 its layer is available for analysis. In order to defeat security
`chip 30. the copyist must be able to analyze the contents of
`ROM 32 and the output of the security chip to derive the key.
`In addition to the key being different for each different game
`(not necessarily each game cartridge containing that game),
`security chip 30 contains other features which make the
`cracking of the encryption without access to the internals of
`security chip 30 more difficult.
`FIG. 2 shows security chip 30 in more detail. including a
`bus unit 50 which couples security chip 30 to bus 14 and
`passes requests for program data to a translator 52. Trans(cid:173)
`lator 52 converts the address of the access request into an
`address location, or range of locations. in ROM 32. This
`address is sent over an address bus 54 to ROM 32. which
`returns the data on data bus 56. Alternatively. some locations
`of ROM 32 might be cached in cache 60. in which case
`translator 52 routes address information to cache 60. which
`in turn supplies the cached data.
`Both sources of data are coupled to an input of a decryptor
`62. which decrypts the data from ROM 32 using a key value
`supplied from a key register 64. As explained below. dif(cid:173)
`ferent configurations for decryptor 62 are possible depend(cid:173)
`ing on the degree of security needed. Since the decryptor 62
`is constrained to be. more or less. the inverse of the an
`
`35
`
`55
`
`12
`
`

`

`5,675,645
`
`8
`
`}
`
`If the program of Table 1 were supplied to branch
`separator 102. the secure program shown in Table 2 and the
`branch table shown in Table 3 would result.
`
`TABLE 2
`
`Secure Program
`
`Address
`
`Line#
`
`Instruction
`
`0
`1
`2
`3
`4
`5
`6
`7
`8
`
`0
`
`5
`6
`2
`7
`3
`4
`
`i=O
`mov i, br__req_arg[l]
`br_req 0
`mov a[i], b[i]
`br_req 1
`br_req 2
`br_rcq 3
`i= i+ 1
`br_req 4
`
`TABLE3
`
`Branch Table (Hidden Data)
`
`BR#
`
`Type
`
`Arg=nt(s)
`
`'Ihle
`Address
`
`False
`Address
`
`arg[l] > 10
`
`6
`
`0
`1
`2
`3
`4
`
`Cond'l
`Return
`Call
`Return
`Goto
`
`7
`encryptor used to encrypt the program data, the different
`configurations are discussed below in connection with the
`encrypt or.
`The output of decryptor 62 feeds to the input of a
`decompressor 68. which is optional. Decompressor 68 in 5
`turn passes the data to a router 70. Router 70 includes an
`output for clear ROM data and an output for hidden data.
`The clear ROM data is unencrypted program code and data
`objects. but without branch information. The hidden data
`contains the branch information as well as other variables. 10
`such as checksums and expected execution times.
`The hidden data output is coupled to an input of a
`computational unit 72. which handles the overall control of
`security chip 30. Computational unit 72 also includes a port
`for reading from. and writing to, private tables 74. an input 15
`for reading from a real-time clock 76, an input for receiving
`branch requests from bus unit SO, an output for branch
`responses coupled to bus unit SO. an input from bus unit SO
`for bus taps which provide information about activity occur(cid:173)
`ring over a processor bus or bus 14. and a port for receiving
`and responding to queries from bus unit SO about the 20
`propriety of requests for program data. The detailed opera(cid:173)
`tion of security chip 30 is described below in connection
`with FIG. 4.
`FIG. 3 is a block diagram of a system 100 used to encrypt
`a game program 112 onto an encrypted ROM 32 to be used 25
`in game cartridge 12. System 100 includes storage for game
`program 112 coupled to a branch separator 102 which
`outputs a secure program 114. a branch table 116. a file of
`checksum data 118 and a file of timing data 120. Storage is
`provided for these output data sets and that storage is 30
`coupled to a compressor 104. which is optional but pre(cid:173)
`ferred. The output of compressor 104 is coupled to an input
`of an encryptor 108. which also has an input for receiving a
`key value from a key register 110. The output of encryptor
`108 forms the contents of ROM 32.
`As explained above. game program 112 comprises pro(cid:173)
`gram executable code. data tables, graphic images and other
`related objects. A short example of program executable
`code. useful for expl