1111111111111111 IIIIII IIIII 11111 1111111111 111111111111111 IIIII 1111111111111111 IIII 11111111
`
`
`
`
`
`US 20030195033Al
`
`(19) United States
`(12) Patent Application Publication
`Gazdic et al.
`
`(10) Pub. No.: US 2003/0195033 Al
`Oct. 16, 2003
`(43) Pub. Date:
`
`(54) GAMING SOFTWARE AUTHENTICATION
`
`(57)
`
`ABSTRACT
`
`(76)
`
`Inventors: Daniel J. Gazdic, Chicago, IL (US);
`Chad A. Ryan, Lisle, IL (US); Craig J.
`Sylla, Round Lake, IL (US)
`
`Correspondence Address:
`Michael J. Blankstein
`WMS Gaming Inc.
`800 South Northpoint Boulevard
`Waukegan, IL 60085 (US)
`
`(21) Appl. No.:
`
`10/119,663
`
`(22) Filed:
`
`Apr. 10, 2002
`
`Publication Classification
`
`Int. Cl.7 ..................................................... A63F 13/00
`(51)
`(52) U.S. Cl.
`................................................................ 463/20
`
`A method of preparing memory contents of a gaming
`machine for subsequent authentication and a method of
`authenticating the prepared memory contents are disclosed.
`A first memory stores a game data set and a first authenti(cid:173)
`cation code generated from the game data set. The game data
`set includes game data files and second authentication codes
`generated from the respective data files. A second memory
`stores an authentication program for authenticating the first
`memory's contents, as well as a third authentication code
`generated from the second memory's contents. To authen(cid:173)
`ticate the memory contents, the second memory's contents
`are first authenticated and, if deemed authentic, the game
`data set as a whole and each data file in the first memory are
`authenticated. The authentication process involves generat(cid:173)
`ing fresh authentication codes using the authentication pro(cid:173)
`gram and comparing the fresh codes with appropriate ones
`of the stored authentication codes.
`
`10
`
`~
`
`11
`
`1
`1
`
`II,
`
`II
`
`l1
`
`~
`
`~
`
`-
`
`11
`
`1
`1
`
`IPR2020-01218
`Sony EX1008 Page 1
`
`

`

`Patent Application Publication Oct. 16, 2003 Sheet 1 of 7
`
`US 2003/0195033 Al
`
`10
`
`~
`
`FIG. 1
`
`14
`
`IPR2020-01218
`Sony EX1008 Page 2
`
`

`

`'"""
`~ >
`
`~
`0
`Ul
`'"""
`\0
`
`0
`N
`'JJ.
`d
`
`-..J
`....,
`0
`N
`~ ....
`'JJ. =-
`
`~
`
`~
`0
`0
`N
`'"""
`O'I
`:-""
`I")
`0
`=
`....
`~ ....
`...
`""C =
`O'
`0 =
`....
`....
`"Cl -....
`>
`~ = ....
`~ ....
`""C
`
`0
`
`-.
`
`I")
`
`~
`I")
`
`"Cl
`
`~
`
`I
`
`I
`
`JURISDICTION MAX WIN I
`
`I JURISDICTION MAX BET I
`
`341
`
`JURISDICTION BIT CODE I I
`
`OPTIONS
`
`I
`
`JURISDICTION NAME I
`
`I I
`
`JURISDICTION ID
`
`I
`
`I
`
`I
`
`PART NUMBER
`
`LOTTERY TERMINAL ID I
`
`DIGITAL SIGNATURE
`!DIGITAL SIGNATURESI- l--'
`
`(WHOLE DEVICE)
`
`!FILE LIST.IITYPES.I
`MAN I FEST Fl LE
`ZERO FILLED
`UNUSED SPACE-
`
`DIGITAL SIGNATURE
`
`(WHOLE DEVICE)
`
`ZERO FILLED
`UNUSED SPACE-
`
`DECOMPRESSION
`
`UTILITY
`
`120 v----
`
`GRAPHICS DATA
`
`PUBLIC KEY
`
`46a
`
`SOUND BANKS
`
`44a -i--... DSA VERIFY OPERATION
`
`SOUND OPERATING
`
`SYSTEM
`
`SYSTEM EXECUTABLE
`GAME AND OPERATING
`
`HASH FUNCTION
`
`42 -:--
`
`BOOT CODE
`
`~ -0
`DIGITAL SIGNATURE K36 0
`
`(WHOLE DEVICE)
`
`I
`
`I
`
`ZERO FILLED
`UNUSED SPACE-
`
`24
`
`)
`
`,,,
`
`22
`
`32
`
`\
`
`'
`
`\
`
`)
`
`20
`
`FIG. 2
`
`\
`
`:--
`
`30
`
`SERIAL READ-WRITE MEMORY\
`
`/ HIGH CAPACITY STORAGE MEMOR~
`
`,
`
`'
`
`BOOT MEMORY
`
`I
`
`IPR2020-01218
`Sony EX1008 Page 3
`
`

`

`Patent Application Publication Oct. 16, 2003 Sheet 3 of 7
`
`US 2003/0195033 Al
`
`MEMORY
`CONTENTS
`
`L,.,------.
`
`40
`
`'~
`
`HASH
`FUNCTION
`
`L.,---...
`
`42
`
`•
`
`MESSAGE L.,---...
`DIGEST
`
`48
`
`46b
`
`(
`
`•
`
`PRIVATE
`KEY
`
`- DSA GENERATION
`i..---
`OPERATION
`
`44b
`
`30, 32, 34, OR 36·
`
`-
`
`DIGITAL
`SIGNATURE
`
`FIG. 3
`
`IPR2020-01218
`Sony EX1008 Page 4
`
`

`

`Patent Application Publication Oct. 16, 2003 Sheet 4 of 7
`
`US 2003/0195033 Al
`
`20
`
`40
`
`BOOT MEMORY
`
`48
`
`MEMORY
`CONTENTS
`
`HASH
`FUNCTION
`
`COMPUTED
`MESSAGE DIGEST
`
`DSA SIGNATURE
`
`42
`
`30, 32, 34,
`OR 36
`
`44a
`
`DSA VERIFY
`OPERATION
`
`DIGITAL
`SIGNATURE
`
`50
`
`46a
`
`PUBLIC KEY
`
`52
`MATH OPERATION
`(COMPLEMENT)
`
`54
`
`COMPLEMENT OF
`SIGNATURE
`
`58
`
`SUM =0 AUTHENTICATION
`SUCCESSFUL
`
`SUM NOT=O
`
`AUTHENTICATION
`FAILED
`
`60
`
`FIG. 4
`
`IPR2020-01218
`Sony EX1008 Page 5
`
`

`

`Patent Application Publication Oct. 16, 2003 Sheet 5 of 7
`
`US 2003/0195033 Al
`
`FIG. 5a
`
`70 -
`
`AUTHENTICATE
`BOOT
`MEMORY
`I
`
`72/
`
`AUTHENTICATE HIGH
`CAPACITY STORAGE
`MEMORY
`
`-
`
`-
`
`AUTHENTICATE
`EXTERNAL
`SERIAL
`COMPONENT
`}
`MEMORY
`AUTHENTICATION
`I ~
`74
`'
`
`POWER UP (BOOT)
`MACHINE
`+
`POWER ON SELF TEST
`(POST)
`{
`AUTHENTICATE
`BOOT MEMORY
`!
`AUTHENTICATE
`SERIAL MEMORY
`+
`INITIALIZE HIGH CAPACITY STORAGE
`MEMORY DRIVERS AND FILE SYSTEM
`i
`AUTHENTICATE HIGH
`CAPACITY STORAGE MEMORY
`
`I"\
`76
`
`I"\
`78
`
`I'\
`80
`
`\
`82
`
`' 84
`
`I"\
`86
`
`INTERNAL
`....
`BOOT
`.,,,
`COMPONENT
`AUTHENTICATION
`
`J
`
`-
`
`-
`
`-
`
`FAIL
`
`FAIL
`
`FAIL
`
`FAIL
`
`-
`
`'
`
`A
`TO
`FIG. 5b
`
`© TO
`
`FIG. 5b
`
`IPR2020-01218
`Sony EX1008 Page 6
`
`

`

`Patent Application Publication Oct. 16, 2003 Sheet 6 of 7
`
`US 2003/0195033 Al
`
`FAIL
`
`AUTHENTICATE DATA FILE FROM
`HIGH CAPACITY STORAGE MEMORY
`88
`
`PASS
`
`91
`
`90
`
`DECOMPRESS DATA FILE
`
`LOAD DATA FILE TO
`ASSOCIATED
`CPU COMPONENT
`
`93
`
`~-----1
`
`FAIL AUTHENTICATE THE DECOMPRESSED
`FILE(S) AND LOAD TO ASSOCIATED
`CPU COMPONENT
`PASS
`
`DISPLAY CRITICAL
`ERROR
`
`NO
`
`92
`
`YES
`
`96
`
`LAUNCH MAIN APPLICATION
`FROM SYSTEM RAM
`
`94
`
`FIG. 5b
`
`SYSTEM BOOT
`COMPLETE
`
`IPR2020-01218
`Sony EX1008 Page 7
`
`

`

`Patent Application Publication Oct. 16, 2003 Sheet 7 of 7
`
`US 2003/0195033 Al
`
`MAIN APPLICATION 94
`LAUNCHED FROM
`SYSTEM RAM
`
`READ
`READ HIGH CAPACITY
`FAILS
`STORAGE MEMORY
`AND CALCULATE
`MESSAGE DIGEST
`
`FAIL
`
`AUTHENTICATE
`SERIAL
`MEMORY
`
`PASS
`
`106
`
`108
`
`FAIL
`
`AUTHENTICATE
`BOOT
`MEMORY
`
`PASS
`
`110
`
`FAIL
`
`AUTHENTICATE
`FILE IN SYSTEM
`RAM
`
`FAIL
`•--
`
`VERIFY NVRAM
`CRC'S AREAS AND
`MAIN /AUX COPIES
`
`96
`
`DISPLAY CRITICAL
`ERROR
`
`END
`
`FIG. 6
`
`IPR2020-01218
`Sony EX1008 Page 8
`
`

`

`US 2003/0195033 Al
`
`Oct. 16, 2003
`
`1
`
`GAMING SOFTWARE AUTHENTICATION
`
`FIELD OF THE INVENTION
`
`[0001] The present invention relates generally to gaming
`machines and, more particularly, to software authentication
`in a gaming machine.
`
`BACKGROUND OF THE INVENTION
`
`[0002] As a regulatory requirement in virtually all juris(cid:173)
`dictions that allow gaming, it is necessary to have a tech(cid:173)
`nique to authenticate that the software installed in a gaming
`machine is tested and approved. In the past, gaming manu(cid:173)
`facturers have generally used EPROM-based hardware plat(cid:173)
`forms to store program code. As a result, a number of
`software authentication techniques have been accepted as
`standards throughout the gaming industry. Depending upon
`the preferences of the local regulatory agency, these tech(cid:173)
`niques generally include either a Kobetron signature or a
`hash function based on the data stored in the EPROM
`device.
`
`[0003] Authentication of software programs basically
`occurs using two different methods
`in the field, again
`determined by the local regulatory agency. In one method,
`each EPROM is authenticated by a gaming agent prior to
`being installed in a gaming machine that is to be brought up
`for play. The EPROMs may be shipped directly to the
`gaming agency for authentication prior to the install date of
`the machine, or may be authenticated on the casino floor as
`the software is being installed in the machine. In another
`method, authentication is conducted on a spot-check basis.
`A gaming agent periodically visits a casino and picks
`machines selectively or at random to remove the software
`components for authentication.
`
`[0004] Due to advances in technology
`that have been
`made in recent years, EPROM-based hardware platforms are
`becoming obsolete and newer technologies are being intro(cid:173)
`duced into the gaming industry. These advanced technolo(cid:173)
`gies utilize storage devices that have been classified as "high
`capacity storage devices." High capacity storage devices
`may, for example, include CD-ROMs, hard disk drives, and
`flash devices. Thus far, there is no industry standard method
`for authenticating these types of devices.
`
`SUMMARY OF THE INVENTION
`
`[0005] The present invention provides a method of pre(cid:173)
`paring memory contents of a gaming machine for subse(cid:173)
`quent authentication and a method of authenticating
`the
`prepared memory contents. A first memory stores a game
`data set and a first authentication code generated from the
`game data set. The game data set includes game data files
`and second authentication codes generated from the respec(cid:173)
`tive data files. A second memory stores an authentication
`program for authenticating the first memory's contents, as
`well as a third authentication code generated from the
`second memory's contents. The first memory is preferably a
`high capacity storage device, while the second memory is
`preferably a boot read-only memory. To authenticate
`the
`memory contents, the second memory's contents are first
`authenticated and, if deemed authentic, the game data set as
`a whole and each data file in the first memory are authen(cid:173)
`ticated. The authentication process involves generating fresh
`
`authentication codes using the authentication program and
`comparing
`the fresh codes with appropriate ones of the
`stored authentication codes.
`
`BRIEF DESCRIPTION OF THE DRAWINGS
`
`[0006] The foregoing and other advantages of the inven(cid:173)
`tion will become apparent upon reading
`the following
`detailed description and upon reference to the drawings.
`[0007] FIG. 1 is an isometric view of a gaming machine
`operable to conduct a wagering game.
`[0008] FIG. 2 is a block diagram of computer-readable
`storage contained in the gaming machine.
`[0009] FIG. 3 is a flow diagram of a method of generating
`digital signatures from contents of the computer-readable
`storage for subsequent authentication.
`[0010] FIG. 4 is a flow diagram of a method of authen(cid:173)
`ticating the digital signatures.
`[0011] FIGS. Sa and Sb are a flow diagram of a multi(cid:173)
`stage authentication procedure executed external
`to the
`gaming machine and then internal to the gaming machine
`during a system boot process.
`[0012] FIG. 6 is a flow diagram of a continuous run-time
`authentication procedure executed by the gaming machine
`after a main software application is launched from system
`RAM.
`
`[0013] While the invention is susceptible to various modi(cid:173)
`fications and alternative forms, specific embodiments have
`been shown by way of example in the drawings and will be
`described in detail herein. It should be understood, however,
`that the invention
`is not intended
`to be limited to the
`particular forms disclosed. Rather, the invention is to cover
`all modifications, equivalents, and alternatives falling within
`the spirit and scope of the invention as defined by the
`appended claims.
`
`DESCRIPTION OF ILLUSTRATIVE
`EMBODIMENTS
`
`[0014] Turning now to the drawings and referring initially
`to FIG. 1, a gaming machine 10 is operable to conduct a
`wagering game such as mechanical or video slots, poker,
`keno, bingo, or blackjack. If based in video, the gaming
`machine 10 includes a video display 12 such as a cathode ray
`tube (CRT), liquid crystal display (LCD), plasma, or other
`type of video display known in the art. A touch screen
`preferably overlies the display 12. In the illustrated embodi(cid:173)
`ment, the gaming machine 10 is an "upright" version in
`which the display 12 is oriented vertically relative to a
`player. Alternatively, the gaming machine may be a "slant(cid:173)
`top" version in which the display 12 is slanted at about a
`thirty-degree angle toward the player.
`[0015] The gaming machine 10 includes a plurality of
`possible credit receiving mechanisms 14 for receiving cred(cid:173)
`its to be used for placing wagers in the game. The credit
`receiving mechanisms 14 may, for example, include a coin
`acceptor, a bill acceptor, a ticket reader, and a card reader.
`The bill acceptor and the ticket reader may be combined into
`a single unit. The card reader may, for example, accept
`magnetic cards and smart (chip) cards coded with money or
`designating an account containing money.
`
`IPR2020-01218
`Sony EX1008 Page 9
`
`

`

`US 2003/0195033 Al
`
`Oct. 16, 2003
`
`2
`
`[0016] The gaming machine 10 includes a user interface
`comprising a plurality of push-buttons 16, the above-noted
`touch screen, and other possible devices. The plurality of
`push-buttons 16 may, for example, include one or more
`"bet" buttons for wagering, a "play" button for commencing
`play, a "collect" button for cashing out, a "help" button for
`viewing a help screen, a "pay table" button for viewing the
`pay table(s), and a "call attendant" button for calling an
`attendant. Additional game-specific buttons may be pro(cid:173)
`vided to facilitate play of the specific game executed on the
`machine. The touch screen may define touch keys for
`implementing many of the same functions as the push(cid:173)
`buttons. Other possible user interface devices include a
`keyboard and a pointing device such as a mouse or trackball.
`
`[0017] A central processing unit (CPU) controls operation
`of the gaming machine 10. In response to receiving a wager
`and a command to initiate play, the CPU randomly selects a
`game outcome from a plurality of possible outcomes and
`causes the display 12 to depict indicia representative of the
`selected game outcome. In the case of slots, for example,
`mechanical or simulated slot reels are rotated and stopped to
`place symbols on the reels in visual association with one or
`more pay lines. If the selected outcome is one of the winning
`outcomes defined by a pay table, the CPU awards the player
`with a number of credits associated with the winning out(cid:173)
`come.
`
`[0018] The CPU includes a microprocessor and computer(cid:173)
`readable storage. Referring to FIG. 2, in a preferred embodi(cid:173)
`ment,
`the computer-readable
`storage
`includes a boot
`memory 20, a high capacity storage memory 22, and a serial
`read-write memory 24. The boot memory 20 is preferably a
`read-only memory such as a one megabit EPROM. The high
`capacity storage memory 22 is preferably a compact flash
`card. The serial memory 24 is preferably an EEPROM such
`as a 512 byte SPI EEPROM. Depending upon the prefer(cid:173)
`ences of the local regulatory agency, all three memories may
`be authenticated both outside of the CPU and then when
`installed in the CPU at power up. The diagram in FIG. 2
`displays the contents stored in each of the memories and
`authenticated prior to use in the gaming machine.
`
`[0019] The boot memory 20 stores boot code, an authen(cid:173)
`tication program, a RAM loader, a decompression utility
`120, and a digital signature 30. The authentication program
`includes a hash function 42, a digital signature algorithm
`(DSA) verify operation 44a, and a public key 46a. The hash
`function 42 may, for example, be an SHA-1 hash algorithm
`that reduces a data set to a unique 160 bit message digest.
`The digital signature 30 is generated from the boot memo(cid:173)
`ry's contents as a whole.
`
`[0020] The high capacity storage memory 22 stores game
`and operating system executable program files, sound oper(cid:173)
`ating system files, sound bank files, graphics files, a manifest
`file, and a digital signature 32. The above files, taken
`together, constitute a "game data sef' as that term is used
`herein, and the various files constitute "data files" as that
`term is used herein. Thus, the game data set includes a
`plurality of data files. For each data file on the high capacity
`storage memory 22, the manifest file contains a file name, a
`file type, a load address, and a digital signature 34. The
`digital signature 32 is generated from the game data set as
`a whole, while each digital signature 34 is generated from
`the associated data file listed in the manifest file.
`
`[0021] The serial memory 24 stores information specific to
`the jurisdiction where the CPU is to be installed. This
`information may, for example, include a lottery terminal
`identification (ID), a part number, a jurisdiction
`ID, a
`jurisdiction name, jurisdiction bit code options, jurisdiction
`max bet, jurisdiction max win, and a digital signature 36.
`The digital signature 36 is generated from the serial memo(cid:173)
`ry's contents as a whole.
`
`[0022] The digital signatures 30, 32, 34, and 36 in the
`various memories are preferably generated and authenti(cid:173)
`cated using the Digital Signature Standard as adopted by the
`U.S. Department of Commerce/National Institute of Stan(cid:173)
`dards and Technology and published in FIPS PUB 186-2 on
`Jan. 27, 2000.
`
`[0023] FIG. 3 illustrates a method of generating the digital
`signatures 30, 32, 34, and 36 for subsequent authentication.
`The method is performed outside of the gaming machine
`during an engineering release process. Specifically, each
`digital signature is generated from associated memory con(cid:173)
`tents 40 by reducing the contents 40 to a message digest 48
`using the hash function 42 and then inputting the message
`digest 48 and a private key 46b into a DSA generation
`operation 44b.
`
`[0024] The associated contents 40 from which each digital
`signature is generated varies as described above in connec(cid:173)
`tion with FIG. 2. Specifically, the digital signature 30 is
`generated from the contents of the boot memory 20 as a
`whole. The digital signature 32 is generated from the game
`data set in the high capacity storage memory 22 as a whole,
`while the digital signatures 34 are generated from the
`respective data files ( except the manifest file) making up the
`game data set. Some of the data files, such as the sound and
`graphics files, may be compressed. A compressed data file(s)
`may itself include a plurality of uncompressed data files. A
`digital signature 34 may be generated from the compressed
`data file, and either a digital signature 34 or a message digest
`48 may be generated from the data file prior to compression
`(i.e., the uncompressed data file). The digital signature 34 or
`message digest 48 generated from an uncompressed data file
`may be appended to the compressed data file. The digital
`signature 36 is generated from the contents of the serial
`memory 24 as a whole. The hash function 42 used in the
`signature generation method is the same as the hash function
`42 stored in the boot memory 20. The aforementioned public
`key 46a stored in the boot memory 20 and the private key
`46b form an associated pair in accordance with the Digital
`Signature Standard. The same public key/private key pair
`46a-b is preferably used to generate and authenticate all
`digital signatures. Alternatively, different public key/private
`key pairs may be used to generate and authenticate one or
`more of the digital signatures.
`
`[0025] FIG. 4 illustrates a method of authenticating the
`digital signatures 30, 32, 34, and 36 already stored in the
`memories. The timing of this method is described below in
`connection with FIG. 5 and depends upon the digital sig(cid:173)
`nature being authenticated. The method employs the boot
`memory's authentication program, which includes the hash
`function 42, the DSA verify operation 44a, and the public
`key 46a. In the authentication method, a fresh digital sig(cid:173)
`nature 50 is generated from previously signed memory
`contents 40 by reducing the contents 40 to a message digest
`48 using the hash function 42 and then inputting the message
`
`IPR2020-01218
`Sony EX1008 Page 10
`
`

`

`US 2003/0195033 Al
`
`Oct. 16, 2003
`
`3
`
`digest 48 and the public key 46a into the DSA verify
`operation 44a. The message digest 48 is also stored in a
`nonvolatile random access memory (RAM) for later use
`during continuous run-time authentication. The fresh digital
`signature 50 is then mathematically complemented at step
`52 to yield a complement 54 of the fresh signature 50. The
`signature complement 54 is summed with the stored digital
`signature (i.e., digital signature 30, 32, 34, or 36) generated
`from the same memory contents 40. If the mathematic sum
`56 is zero (i.e., the fresh signature 50 matches the stored
`signature), authentication is deemed a success at step 58. If,
`however, the mathematic sum 56 is not zero, authentication
`is deemed a failure at step 60.
`[0026] Referring to FIGS. Sa and Sb, the procedure for
`authenticating the contents of the memories 20, 22, and 24
`is implemented in the following distinct stages: external
`component authentication, internal boot component authen(cid:173)
`tication, file authentication and loading, and continuous
`run-time authentication (see FIG. 6). This authentication
`procedure guarantees the integrity and security of the CPU
`software. A failure detected in any one of the stages is
`considered a critical failure that must be corrected prior to
`any further play of the gaming machine. The machine
`displays the critical failure, if detected, at step 96.
`
`[0027] External component authentication verifies
`the
`contents of the memories prior to placement in the gaming
`machine. Alternatively, if permitted by the local gaming
`agency, the memory contents may be verified using a
`dedicated serial port after the memories have been installed
`in the CPU. External component authentication of the boot
`memory 20 may be accomplished using industry standard
`techniques, such as a Kobetron MT-2000 signature or a hash
`algorithm for generating a unique signature (step 70). Exter(cid:173)
`nal component authentication of the high capacity storage
`memory 22 may be accomplished using tools commercially
`available from such companies as Kobetron Inc. of Navarre,
`Fla., Gaming Laboratories International Inc. (GLI) of Toms
`River, N.J., and Dataman Programmer Ltd. of Orange City,
`Fla. (step 72). External component authentication of the
`serial memory 24, which requires a serial communications
`interface to read from and write to the memory, may be
`accomplished using tools commercially available from one
`or more of the aforementioned companies (step 74).
`
`[0028]
`Internal boot component authentication occurs
`immediately following power up of the machine and entails
`authentication of the contents of each installed memory as a
`whole and does not look at individual files stored in the
`memory. Authentication of individual files occurs during a
`later stage. After powering up (booting) the machine at step
`76, a Power On Self Test (POST) is immediately initiated at
`step 78 to initialize the CPU hardware and run a few basic
`tests to verify that the hardware is functioning correctly.
`After the POST, the three memories are authenticated as a
`whole using the method in FIG. 4 and in the following
`sequence: (1) authenticate digital signature 30 of boot
`memory 20 at step 80, (2) authenticate digital signature 36
`of serial memory 24 at step 82, and (3) authenticate digital
`signature 32 of high capacity storage memory 22 at step 86.
`The boot memory 20 is authenticated first because the other
`two memories rely upon the contents of the boot memory 20
`to complete their own authentication processes. Prior to
`authenticating the high capacity storage memory 22 at step
`86, that memory's drivers and file system are initialized at
`
`step 84. If all three memories have been determined to be
`both present and authentic, the authentication procedure
`proceeds to the next stage-file
`authentication and loading.
`
`[0029] File authentication
`sequentially
`loading
`and
`authenticates the executable data files ( except for the mani(cid:173)
`fest file) stored in the high capacity storage memory 22 and
`loads each authenticated data file into the CPU component
`(e.g., system RAM) where the data file will reside and
`execute from during normal machine operation. The data
`files are loaded and processed in the order listed in the
`manifest file stored in the high capacity storage device 22.
`The manifest file itself is not loaded into the system, but
`rather is used during the system boot process to guide the file
`loading process. The order in which the data files are loaded
`does not have an effect on system operation.
`
`[0030] The digital signature 34 of a data file in the high
`capacity storage memory 22 is authenticated at step 88 using
`the method in FIG. 4. If the data file is compressed, the
`digital signature 34 generated from the compressed data file
`is authenticated at step 88. If the digital signature 34 is
`authenticated, a check is made at step 89 as to whether or not
`the data file is compressed. If the data file is not compressed,
`the data file is loaded to an associated CPU component at
`step 90. The associated CPU component is identified in the
`manifest file. If, however, the data file is compressed, the
`compressed data file is decompressed using the decompres(cid:173)
`sion utility 120 stored in the boot memory 20 at step 91. The
`decompressed data file may be authenticated prior to being
`loaded to the associated CPU component at step 93. The
`message digest 48 calculated during such authentication is
`stored in the non-volatile random access memory (RAM) for
`later use during continuous run-time authentication. A check
`is then made at step 92 as to whether or not the loaded data
`file was the last file listed in the manifest file. If not, the file
`authentication and loading steps are repeated for the next
`data file listed in the manifest file. After authenticating and
`loading the last file and performing a RAM clear check (not
`shown), the main software application is launched from
`system RAM at step 94 to complete the system boot process.
`The authentication procedure
`then proceeds to the final
`stage----continuous run-time authentication.
`
`[0031] FIG. 6 illustrates a basic method of continuous
`run-time authentication as it will take place following the
`completion of the system boot process. There are two main
`cycles of events that occur during continuous run-time
`authentication. The first cycle repeatedly verifies the pres(cid:173)
`ence of the high capacity storage memory 22 in the CPU
`board, and calculates and verifies the message digest 48 (see
`FIG. 4) for the memory 22 as a whole at steps 100, 102, and
`104. The high capacity storage memory 22 is accessed at
`short time intervals such as every 15 milliseconds. Any
`unsuccessful read of the high capacity storage memory 22 at
`step 100 or any unsuccessful authentication at step 104 halts
`the machine and causes it to display a critical error at step
`96. The continuous run-time authentication of the high
`capacity storage memory 22 is limited to the memory as a
`whole and does not look at individual files stored on the
`memory.
`
`[0032] The second cycle involves repetitive authentication
`of the serial memory 24 at step 106, the boot memory 20 at
`step 108, and the files that are executing from system RAM
`at steps 110 and 112. All authentications are preferably
`
`IPR2020-01218
`Sony EX1008 Page 11
`
`

`

`US 2003/0195033 Al
`
`Oct. 16, 2003
`
`4
`
`accomplished using the message digest 48 of the corre(cid:173)
`sponding memory or file, instead of the DSA verify opera(cid:173)
`tion in FIG. 4. Message digests 48 of the various memories
`and files (including the decompressed data files) were pre(cid:173)
`viously stored in non-volatile RAM, and it is against these
`stored message digests 48 that newly calculated message
`digests are compared. The DSA verify operation is not
`necessary at this point because the memories and files were
`proven to be authentic during the system boot process. The
`purpose of continuous run-time authentication is to ensure
`that the information that was loaded to system RAM during
`the boot process has not been altered and that the memories
`have not been changed. A message digest 48 is sufficient for
`this purpose. It should be understood, however, that the DSA
`verify operation may instead be performed during this
`second cycle of continuous run-time authentication.
`[0033] Following the successful authentication of all files
`in system RAM, the nonvolatile RAM is verified using a
`standard "CRC" or other similar check at step 114. Main and
`auxiliary copies of the non-volatile RAM are also compared
`to each other at step 114 to ensure the integrity of the
`non-volatile RAM. In accordance with step 116, all of the
`above functions of the second cycle continue for as long as
`the machine is powered on. If the machine is powered off,
`the authentication procedure will start again at the boot
`component authentication stage in FIG. 5 when the machine
`is powered up.
`[0034] While the present invention has been described
`with reference to one or more particular embodiments, those
`skilled in the art will recognize that many changes may be
`made thereto without departing from the spirit and scope of
`the present invention.
`[0035] For example, as noted above, numerous techniques
`may be used to prepare and authenticate a compressed data
`set. The compressed data set may include one or more files
`in the high capacity storage memory 22. In the illustrated
`embodiment, to prepare a compressed data set for subse(cid:173)
`quent authentication, the performed steps include compress(cid:173)
`ing an uncompressed game data set; generating a first
`authentication code from the compressed data set; and
`storing the compressed data set and the first authentication
`code in the high capacity storage memory 22. The com(cid:173)
`pressed data set may include sound files, graphics files, and
`even executable game code. The first authentication code
`may be a message digest 48 or a digital signature 34 (see
`FIG. 3). The manifest file in the high capacity storage
`memory 22 lists the compressed data set and its associated
`first authentication code.
`
`[0036] Prior to compressing an uncompressed data set, a
`second authentication code may be generated from the
`uncompressed data set and appended to the compressed data
`set. The second authentication code may be a message digest
`48 or a digital signature 34 (see FIG. 3). The manifest file
`in the high capacity storage memory 22 lists the compressed
`data set and the first and second authentication codes gen(cid:173)
`erated from the respective compressed and uncompressed
`data sets.
`
`[0037] To authenticate a data set that has been prepared in
`the above manner, the performed steps include authenticat(cid:173)
`ing the compressed data set; decompressing the compressed
`data set using a decompression utility stored in the boot
`memory; and authenticating the decompressed data set. Both
`
`the compressed data set and the decompressed data set may
`be authenticated during the file authentication and loading
`stage shown in FIG. Sb by generating fresh authentication
`codes that are compared to the respective stored first and
`second authentication codes. If a stored authentication code
`is a message digest 48 (see FIG. 3), then the fresh authen(cid:173)
`tication code against which it is compared is also a message
`digest (see FIG. 4). If, however, the stored authentication
`code is a digital signature 34 (see FIG. 3), then the fresh
`authentication code against which it is compared is a digital
`signature 50 (see FIG. 4). After the decompressed data set
`is loaded into its associated CPU component (e.g., system
`RAM), the decompressed data set may again be authenti(cid:173)
`cated during continuous runtime authentication shown in
`FIG. 6 by generating a fresh authentication code that is
`compared to the stored second authentication code of the
`same type (i.e., message digest or digital signature).
`[0038] The compressed data set may include a plurality of
`uncompressed data files. When preparing the compressed
`data set for subsequent authentication, a respective authen(cid:173)
`tication code may be generated for each of these uncom(cid:173)
`pressed files and stored in the manifest file. These authen(cid:173)
`tication
`codes
`are
`then
`later
`authenticated
`after
`decompressing the compressed data set.
`[0039] Depending upon the level of authentication needed
`to comply with a regulatory gaming body, the authentication
`method may be modified to authenticate the compressed
`data set only prior to decompression or only after decom(cid:173)
`pression.
`[0040] Each of these embodiments and obvious variations
`thereof is contemplated as falling within the spirit and scope
`of the claimed invention, which is set forth in the following
`claims:
`
`What is claimed is:
`1. A method of preparing memory contents of a gaming
`machine for subsequent authentication, comprising:
`
`first authentication codes from respective
`generating
`game data files;
`
`storing the first authentication codes and the respective
`data files in one or