CA2473287C - Gaming machine having targeted run-time software authentication - Google Patents
Gaming machine having targeted run-time software authentication Download PDFInfo
- Publication number
- CA2473287C CA2473287C CA002473287A CA2473287A CA2473287C CA 2473287 C CA2473287 C CA 2473287C CA 002473287 A CA002473287 A CA 002473287A CA 2473287 A CA2473287 A CA 2473287A CA 2473287 C CA2473287 C CA 2473287C
- Authority
- CA
- Canada
- Prior art keywords
- data
- gaming machine
- memory
- executable code
- predetermined amount
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Expired - Fee Related
Links
Classifications
-
- G—PHYSICS
- G07—CHECKING-DEVICES
- G07F—COIN-FREED OR LIKE APPARATUS
- G07F17/00—Coin-freed apparatus for hiring articles; Coin-freed facilities or services
- G07F17/32—Coin-freed apparatus for hiring articles; Coin-freed facilities or services for games, toys, sports, or amusements
- G07F17/3225—Data transfer within a gaming system, e.g. data sent between gaming machines and users
- G07F17/3232—Data transfer within a gaming system, e.g. data sent between gaming machines and users wherein the operator is informed
- G07F17/3234—Data transfer within a gaming system, e.g. data sent between gaming machines and users wherein the operator is informed about the performance of a gaming system, e.g. revenue, diagnosis of the gaming system
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F21/00—Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
- G06F21/50—Monitoring users, programs or devices to maintain the integrity of platforms, e.g. of processors, firmware or operating systems
- G06F21/57—Certifying or maintaining trusted computer platforms, e.g. secure boots or power-downs, version controls, system software checks, secure updates or assessing vulnerabilities
-
- G—PHYSICS
- G07—CHECKING-DEVICES
- G07F—COIN-FREED OR LIKE APPARATUS
- G07F17/00—Coin-freed apparatus for hiring articles; Coin-freed facilities or services
- G07F17/32—Coin-freed apparatus for hiring articles; Coin-freed facilities or services for games, toys, sports, or amusements
-
- G—PHYSICS
- G07—CHECKING-DEVICES
- G07F—COIN-FREED OR LIKE APPARATUS
- G07F17/00—Coin-freed apparatus for hiring articles; Coin-freed facilities or services
- G07F17/32—Coin-freed apparatus for hiring articles; Coin-freed facilities or services for games, toys, sports, or amusements
- G07F17/3241—Security aspects of a gaming system, e.g. detecting cheating, device integrity, surveillance
Abstract
A naming machine that authenticates its gaining software substantially continuously and repetitiously while the gaming machine is powered on. A processor, while running the gaming machine's gaming program, determines whether the data in each of a plurality of memories is authentic. The processor may read multiple memories in a parallel fashion while making memory contents authenticity determinations. The processor may also read multiple memories in a serial fashion while making memory contents authenticity determinations. The processor may also read same memories in a parallel fashion and read other memories in a serial fashion while determining the authenticity of each memory's contents. Furthermore, the contents of a memory may be analyzed to decipher between executable data and graphics data such that the executable data's authenticity is determined more often than the graphics data's authenticity
Description
GAMING MACHINE HAVING TARGETED RUN-TIME
SOFTWARE AUTHENTICikTION
FIELD OF THE INVE,NTION
The present invention relates generally to gaining machines, and more particularly, to software authentication of programs running in a gaming machine.
BACKGROUND OF THE INVENTION
As a regulatory requirement in virtually all jurisdictions that allow gaming, it is necessary to have a technique to authenticate that the software installed in a gaming inachine is tested and approved. In the past, gaming manufacturers have generally used EPROM-based hardware platforms to store program code. As a result, a number io of software authentication techniques have been accepted as standards throughout the gaming industry. Depending upon the preferences of the local regulatorv agency, these techniques generally include either a Kobetron signature or a hash function based on the data stored in the EPROM device.
Authentication of software programs basically occurs using two different is methods in the field, again. determined by the local regulatory agency. In one method, each EPROM is authenticated by a galning agezlt prior to being installed in a gazning machine that is to be brought up for play. The EPROMs mav be shipped directly to the gamincy agency for authen.tication 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.
20 In another method, authentication is conducted on a spot-check basis wherein a gaming agent periodically visits a casino and picks machines for the removal of software components for authentication.
Jurisdictional requirements require that storage media containing code or data be authenticated at power-up, continuously or at a periodic rate, or upon occurrence of 25 predetennined events, such as the opening any doors or panels of the gaming device that allows access to internal circuitry. The storage media may be colnprised of erasable programmable read-only memory devices (EPROMs), electrically erasable programmable read-only memory devices (.EEPROMs), PROMs, CompactFlash storage cards, hard disk drives, CD drives, or substantially any non-volatile memory and in some cases volatile memory (e.g., NVRAM, specialty mask semiconductors, battery backed RAM, SRAM, DRAM, etc.). Storage a.nedia comprises a memory device and the data stored th.ereon. Authentication of storage media is controlled by the ffaming device's central processing unit (CPU). However, authentication by the CPU may take more than several minutes due to increasing complexity of the gaming device's software and thus the stora~e size of the media.
For example, the authenticity of numerous storage devices associated with the CPU may need to be determined every so often while a gaming machine is running.
In some cases, gaming authorities require that a gaming program be authenticated io about every ten minutes while the gaming machine is running. To determine the authenticity of a memory device's contents the CPU must read the memory device and perform various calculations and comparisons to determine if the memory device's contents are authentic. Reading many inemorv devices or large meinory devices can use significant CPU time and therefore may negatively affect the is responsiveness of the gaming program that a user interacts with. What is needed is a tecl-inique for authenticating memory devices associated with a gaming machine that does not affect the gaming program that the user interacts with.
20 SUMMARY OF THE INVENTIOI'+l Embodiments of the present izwention authenticate a gaining machine program, software, firmware, or data (data) stored in memory devices within the ganiing machine while the gaming machine is rtuining and interacting with a user.
The authentication process does not slow or interfere with the gaming program that 25 interacts with the user. The authentication processes are ongoina and are substantially continuously repetitive. The authentication processes niay substantially repeat every 2 minutes to 24 hours. Furthermore, in order to increase the speed of authenticating some of the data, graphics data niay be differentiated from executable data so that the authenticity of the executable data can be determined more often than the graphics 30 data.
It should be understood that for the purposes of this description of exemplary embodiments of the present invention that the gaming machine program nlay be either compiled or uncompiled. Furthermore the gaming machine progratn comprises code, ,J
files, instructions or programs that are executable in that they direct the aaining machine to do something (hereinafter "executable code"). The gaming machine program further comprises graphics code, files, data, instructions or programs (herein after "graphics data") that have to do with graphics or multimedia applications. Such graphics or multimedia may include, but are not limited to, data or information used to control graphics, animation, or other special effects that move air, move fluids, create smells, create bubbles, create flasliing lights, control laser lights, control air pressure, control temperature, control mechanical devices, or control sound devices.
In an embodiment of the present invention a gaming machine comprises a user interface and a central processing unit (CPU) coupled to the user interface.
The CPU
comprises a processor. A first meinory is coupled to t:he processor. The first memory is adapted to contain executable program code. The executable program code has both executable instructions and graphics data. A second memory is also coupled to the processor. The second memory stores data. The executable instructions found in the is first memory include a plurality of instructions configured to cause the processor to determine the authenticity of the executable program code and the data. The processor, with the aid of the executable instructions, determines the authenticity of the executable prograin and the data on a substantially continuous, repetitious basis.
Furthermore, the authenticity determination of the exectitable program code might be performed substantially iri a parallel process with the authenticity determination of the data_ Other executable instructions cause the processor to determine, Nvhen reading said executable program c.ode, ,AThether executable code or graphics data are bein.g read. If the processor is reading graphics data, then the plurality of executable code z1; cause said processor to nct determine the authenticity of the graphics data unless more than a predetermined ntnuber of events have passed since the last time the graphics data was authenticated. The events may be seconds, clock count-ups, countdowns, a number of repetitions through a prograrn loop, etc. I.f the processor reads executable instructions, then the plural:ity of instructions cause the processor to determine the authenticity of said executable instructions.
In anotl2er embodiznent of the present invention, a gaming machine comprises a CPU and a plurality of inemory devices. The CPU is adapted to determine the authenticity of data in at least two of the plurality of memory devices in a parallel, repeating manner. The CPU is also adapted to read the data stored in at least one of the plurality of memory devices and detennine whether the data is executable data or graphics data. If the data stored in a memory is determined to be graphics data, then the CPU is adapted to determine the authentidity of -the graphics, data if -a predetermined number of events have passed. The events may be clock cycles, seconds, count-ups, count-downs, passes through a program ioutine or loop, uses by a user, number of games played, etc. If the data stored in a memory is determined to be' executable data, then said CPU is adapted to determine the authenticity '-of said executable data.
In another embodiment of the present invention a method is provided for authenticating various memory devices' data within a gaming machine while the gaming-machine is operating. The authentication process- of the memory devices"
data can be perfonned in substantially a parallel fashion; such that two or more memory device's data is being authenticated at about the same time. The metliod of authenticating also comprises reading data from a first memory device and ' detennining or using other techniques to determine whether the data is graphics data or executable code. If the data is determined to be graphics data, then more data is read froin the first memory device. If the data is detennined to be executable data, then it is determined whether the executable code is -autlientic after which more data is read from the first memory device. -According to an aspect of the present invention there is provided a method of authenticating memory devices' data within a gaming machine while said gaming machine is operating, said memory devices' data being authenticated substantially in parallel, said method of authenticating comprising: .
reading a next predetermined amount of data from a first memory device storing executable code for operating a wagering game on said gaming machine and graphics data accessed by said executable code to display graphics of said wagering game on a display of said gaming machine;
detennining if the next predetermined amount of data is executable code or graphics data;
if said next predetermined amount of data is graphics data, then reading a next predetermined amount of data, without authenticating the graphics data;
4a if said next predetermined amount of data is executable code, then authenticating said executable code; and wherein the above steps are repeated substantially continuously while said gaming machine is operating.
According to another aspect of the present invention there is provided in a gaming machine that is turned on, a method of repeatedly authenticating at least a first and a second memory substantially in parallel, said method comprising:
reading first data from said first memory storing executable code and graphics data and authenticating said first data, wherein reading first data from said first memory and authenticating said first data comprises:
reading a next file of said first data;
determining if the next predetermined amount of data is executable code or graphics data;
if said next file is a graphics data, then returning to said reading step, without authenticating the graphics data;
if said next file is an executable code, then determining whether said executable file is authentic, then returning to said reading step until all of said first data in said first memory device has been read; and reading second data from said second memory and authenticating said second data;
repeating said reading steps substantially continuously and substantially in parallel.
According to a further aspect of the invention there is provided a gaming machine comprising:
a user interface; and a central processing unit (CPU) coupled to said user interface, said CPU
comprising:
a processor;
a first memory coupled to said processor, said first memory adapted to contain gaming machine program code, said gaming machine program code comprising executable code and graphics data;
a second memory coupled to said processor, said second memory comprising data;
said gaming machine program code further comprises:
4b a plurality of instructions configured to cause said processor to determine the authenticity of said gaming machine program code and said data on a substantially continuous, repetitious basis such that the authenticity determination of said gaming machine program code is performed substantially in parallel with the authenticity determination of said data;
said plurality of instructions are further configured to cause said processor to determine, when reading said gaming machine program code, whether said processor is reading executable code or graphics data, if said processor reads graphics data, then said plurality of instructions cause said processor to not determine the authenticity of said graphics data unless more than a predetermined number of events have passed since the last time said graphics data was authenticated;
if said processor reads said executable code, then said plurality of instructions cause said processor to determine the authenticity of said executable code.
According to a further aspect of the present invention there is provided a gaming machine comprising a CPU, and a plurality of memory devices;
said CPU adapted to determine the authenticity of data in at least two of said plurality of memory devices in a parallel, repeating fashion;
said CPU further adapted to read said data stored in at least one of said plurality of memory devices and determine whether said data is executable code or graphics data;
if said data stored in said at least one of said plurality of memories is graphics data, then said CPU is adapted to determine the authenticity of said graphics data if a predetermined number of events have passed and read said next data stored in at least one of said plurality of memory devices without authenticating the graphics data if a predetermined number of events have not passed;
if said data stored in said at least one of said plurality of memories is executable code, then said CPU is adapted to determine the authenticity of said executable code.
4c According to a further aspect of the present invention there is provided a method of authenticating data within at least one memory of a gaming machine while the gaming machine is executing a wagering game, said at least one memory storing executable code for operating said wagering game and graphics data accessed by said executable code to display graphics of said wagering game on a display of said gaming machine, said method comprising:
(a) determining if a next predetermined amound of data fromo said memory is executable code or graphics data;
(b) if said next predetermined amount of data is executable code, then authenticating said executable code and returning to step (a); and (c) if said next predetermined amount of data is graphics data and a predetermined condition has been met, then authenticating said graphics data and returning to step (a);
and if said next predetermined amount of data is graphics data and said predetermined condition has not been met, then returning to step (a) without authenticating said graphics data.
According to a further aspect of the present invention there is provided a method of authenticating data within at least one memory of a gaming machine, said at least one memory storing executable code for operating a wagering game on said gaming machine and graphics data accessed by said executable code to display graphics of said wagering game on a display of said gaming machine, said method comprising:
(a) while said gaming machine is booting up, authenticating both the executable code and the graphics data; and (b) while said gaming machine is executing said wagering game after booting up:
(i) determining if a next predetermined amount of data from said memory is executable code or graphics data;
(ii) if said next predetermined amount of data is executable code, then authenticating said executable code and returning to step (i); and (iii) if said next predetermined amount of data is graphics data and a predetermined condition has been met, then authenticating said graphics data and returning to step (i); and if said next predetermined amount of data is graphics data and said predetermined condition has not been met, then returning to step (i) without authenticating said graphics data.
4d According to a further aspect of the present invention there is provided a method of authenticating data within at least one memory of a gaming machine, said at least one memory storing executable code for operating a wagering game on said gaming machine and graphics data accessed by said executable code to display graphics of said wagering game on a display of said gaming machine, said method comprising:
(a) while said gaming machine is booting up, authenticating both the executable code and the graphics data; and (b) while said gaming machine is executing said wagering game after booting up, authenticating said executable code at a first frequency and authenticating said graphics data at a second frequency, said first frequency being greater than said second frequency.
The above summary of the present invention is not intended to represent each embodiment, or every aspect, of the present invention. This is the purpose of the figures and the detailed description which follow.
BRIEF DESCRIPTION OF THE DRAWINGS
The foregoing and other advantages of the invention will become apparent upon reading the following detailed description and upon reference to the drawings.
Figure 1 is an isometric view of a gaming machirie operable to conduct a wagering game;
Figure 2. is an exemplary block diagram of a CPU in a gaming machine according to the present invention; and Figure 3 is a flow.chart for an exemplary run-time authentication process for a gaming machine.
While the invention is susceptible to various modifications and alternative forms, specific embodiments have been shown by way of example in tlie drawings and will be described in detail herein. It should be understood, however, tliat the invention is not intended to be limited to the particular forins disclosed.
Rather, the s invention is to cover all modifications, equivalents, and al'ternatives falling within the spirit and scope of the invention as defined by the appended claims.
Description of Illustrative Embodiments Turning now to the drawings and referring initially to Figure 1, a gaming lo 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 includes a video display 12 such as a cathode ray tube (CRT), liquid crystal display (LCD), plasma, or other type of visual display known in the art. A touch screen preferably overlies the display 12. In the illustrated embodiment, the gaming machine is 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-top" version in which the display 12 is slanted at about a thirty-degree angle tovvard the player.
The gaming machine 10 includes a plurality of possible credif receiving mechanisms 14 for receiving credits to be used for placing wagers in the game.
The 20 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 exa.mple, accept magnetic cards and smart (cl~ips) cards coded with .r.noi~ey or designatin4 an account containing money.
25 The gaming niachin 10 includes a user interface comprising a plurality of push-buttons 16, the above-noted touch screen, and otl7er possible devices.
The plurality of push-buttons 16 may, for exainple, include one or more "bet"
buttons for wagering, a "play" button for coirzmencing play, a"collect", button for cashing out, a "help" button for viewing a help screen, a "pay table" button for viewing the pay 30 table(s), and a "call attendant" button for calling an attendant.
Additional game-specific buttons may be provided to facilitate play of the specific game executed on the machine. The touch screen may define touch keys for implementing many of the same fun.ctions as the push-buttons. Other possible user interface devices include a keyboard and a pointing device such as a rriouse or trackball.
Referring now to F:igure. 2, a central processing unit (CPU) 30 controls operation of the gaming machine 10. In response to receiving a wager and a command to initiate play, the CPU 30 randomly selects a game outcome from a plurality of possible outcomes and causes the display 12, via the video circuitry 39 and video out 40, to depict indicia representative of the selected game outcome.
Alternatively, the game outcome may be centrally detennined at a remote computer using either a random number generator (RNG) or pooling schema. 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 defzned by a pay table, the CPU 30 awards the player with a number of credits associated writh the winning outcome.
The CPU 30 includes a nlicroprocessor 32 and various memory devices (media devices). The microprocessor 32 interfaces with many other components of the gaming machine 10 via an interface bus 34. A inain memory 36 stores the compiled gaming machine program for operating the gaming machine 10.
The main meinor>> 36 i.nay be DRAM or SRAM or substantially any other volatile memory device or .reprogrammable non-volatile ineinory device. The battery backed memory 38 stores machine critical data that cannot be lost when power is removed from machine 10. The battery backed memory 38 may be battery backed volatile memory or a reprograrnmable or rewritable non-volatile memory device.
The video circuitry 39 supplies display information to a, video display 12 that may comprise a CRT, LCD, plasma, or other displav device. Audio circuitry 42 generates sounds for game play on the gaming rnachine 10. The I/O control 44 controls input/output interfaces with the user interfaces such as game buttons 16, coin validators 14, touch screen bill validators, multimedia devices, etc.
In an exemplary embodiment, the various memory devices may also include a boot memory 46, a high capacity storage memory 48, an.d a serial read-write memory 50. The boot memory 46 is preferably a read-only memory such as a one megabit EPROM, EEPROM, PROM or other type or appropriately sized programmable read-only memory. The boot memory 46 may also be substantiallv any type of non-volatile memory. The high capacity storage memor-v 48 is preferably a CompactFlash `]
card, but may also be a hard disk drive, CD drive, DVD drive, magnetic RAM, battery backed RAM or other type of non-volatile memory. The serial memory 50 is preferably an EEPROM such as a 51.2 byte SPI EEPROM, but could be any type of programmable read-only or read/write non-volatile memory. Depending upon the preferences of the local aaming regulatory agency, all three memories may be adapted to be authenticated outside of the CPU as well as when installed in the CPU at power up or prior to being utilized in the gaming machine.
The boot memorv 46 stores, at least some of the following, boot code 52, an authentication program 54, a RAM loader, a decompression utility 56, and a digital io signature 58. The authentication program includes a hash function 60, a digital signature verification algorithm 62, and a public key 64. The hash function 60 may, for example, be an SH.A-1 hash algorithm that reduces a data set to a unique 160 bit message digest. A hash algorithm or function is used to calculate a message digest corresponding to the files in, for example, a memory device. The message digest does Is not have to be unique, i.e., the function -?nay return the same hash value for two or more items (althouffh this is very unlikely). The non-uni.queness of the hash value for each item in the message digest is acceptable because each hash value is used to evaluate a different file or data set within a memory device. The message digest is a small representation of a large amount of data. A message digest is a relatively 20 unique representation of data, from a cryptographic standpoint, and is an irreversible representation of the data. In other words, one cannot recreate t11e original data from the message digest.
The digital sianature 58 is generated, in effect, from the boot memory's contents as a whole. ln an exemplary embodiment, after hashing is performed to produce a message digest, then a digital signature is created to enable the origin and autlienticity of the digest to be determined. When there is data that requires a means for determining the origin of the data, one generally uses a digital signature mechanism. There exists a federal standard called FIPS 186-2 that defines a digital signature generation and verification mechanism called the Digital Signature 30 Algorithm (DSA). In an exemplary embodiment a digital sianature is created from the message digest. In essence the DSA uses a private key, a public key, and the message digest. A private key and the message digest are used to create an original signature associated with the original message digest. The public key, the original signattiue, and a ca.lculated message digest are used to check a signature associated with a message digest in order to determine the origin and authenticity of the data set.
It is understood that neither the message digest nor the data or files used to create the message digest can be recreated using the DSA. The digital signature 58 is used to sign the message digest of the boot memory contents. Again, the signature may be used to determine the source or manufacturer of the inessage digest, via a public key, but caiuzot be used to recreate the message digest or the original data.
Furthermore, the DSA is not being used here as an encryption process under FIPS 186-2, but rather a technique for validating the signature associated with the data set, and the public io key.
The high capacitv storage memorv 48 stores gaine and operating system executable program files 66, sound operating system files 68, sound bank files 70, araphics files 72, a file list of file types 74, and digital signatures 76, 78. The files in the high capacity storage memory 48, taken toaether,, constitute a"gaming program"
5 as that term is used herein, and the various files constitute "data files"
as that term is used herein. Thus, the gamina program includes a plurality of data files. For each data file on the high capacity storage memory 48, the manifest file contains a file nan7e, a file type, a load address, and a file digital signature 76. The whole device digital signature 78 is generated from the gaming program as a whole, while each 20 digital signature 76 is generated from the associated data file listed in the manifest file.
The serial read-write memory D-0 stores inform.ation/data specific to the jurisdiction where the CPt? is to be installed. This information may, for example, include a lottery terminai identification (ID) 80, a part number 82, a jurisdiction ID
255 84, a jurisdiction name 86, jurisdietion bit code options 88, jurisdiction max bet 90, jurisdiction max win 92, and a digital signature 94. The digital signature 94 is gener=ated from the sei-aal memory's contents as a whole.
The boot memory 46, serial read-write memory 50 and high capacity storage memory 48 may each be removable devices and/or contain alterable software.
Each 30 of these memory devices may, be able to be reprogrammed or be able to receive downloaded updates from an outside source via a programming device, a network such as the Internet, an intranet, an Ethemet, a fibre loop, or other type of networking system. The boot meniory 46, serial read-write memory 50, and high capacity memory 48 each may be required to be authenticated by the gaminQ machine 10 at various points during operation of the gaining machine.
In order to bett:er understand the advantages of an exemplary run-time authentication algorithm, it is important to realize that as gaining machines evolved they began to use alterable media, such as flash memories, EEPROMs, EPROMs, CD
drives, disk drives, etc. in their electronics and programming structure to store all or portions of the programs and files. Newer gaming machines are designed to allow the gaming software to be updated, to grow in size, and to grow in coinplexity.
Because of these advances and changes in gaming machine design, electronics, software and io memory storage size the time necessary to authenticate the software in the storage media during run-time operations has increased because the methods required to authenticate the software content became more complex. An increase in the time required to authenticate the software during machine run-time operations may affect the responsiveness and speed of the run-time software as well as the smoothness of ls operation to the extent that it is noticeable to the user. A CPU may become unable to effectively operate the gaminQ machine main prograin while inultiplexing authentication processes are taking place due to the sheer size of the main program that must be authenticated within a predefined period of time. Thus, it is iiecessary to provide a teclmique to authenticate the gaming programs and media within various 20 media devices without s]owing or disturbing the operation of the gaming machine.
An exemplary run-time authentication comprises tw,o main cycles of events during the operation of a gaming machirie. The first cycle of events checks whether the high capacity storage memory 48 is connected to the bus 34. This check is perforined at predetermined intervals tha,: may range from about every 5 ms to about 25 everv minute. The first cycle also checks whether the high capacity storaae memory's 48 SIIA-1 message di-est calculation is continuously being recalculated.
The second cycle of events performs a constant or continuous authentication of the boot fnemory 46, the serial read-write meinory 50, the files that are being executed froin the main i:lemory 36, and the integrity of the data stored in the battery 30 backed memory 38. Ltilizing a SHA-1 hash message digest of a media device's contents the authentication of each inedia device is performd. The authentication of the media device during a run-time authentication may be limited to the data in the whole media device rather than the individual files stored in the media device. The authentication of a media device may also be performed file by file when the CPU has stored the memory locations and the type of data in the memory locations prior to an authentication process.
During a boot-up process of the CPU 30 the media devices and software s thereon are normally authenticated. The boot-up authentication process includes performing a SHA-1 hash over the media software that is loaded into the main memory 36, authenticating the diffital signature 58, 78, 94, and storing the calculated hash message digest in battery backed memory. Thus, during run-time authentication there is no requirement to perform signature verification since the files and io components were proven to be authentic during the boot process. One main purpose of run-time authentication is so the CPU 30 can check to make sure that the files and data loaded into the main memon, 36 during the boot process have not been altered.
Another purpose of the run-time authentication is to verify that certain software or hardware components, such as the boot memory 46, the high capacity storage memory 1.5 48, or the serial read-w-rite memory 50 have not been changed or undergone a change in any of tlzeir software/firmware. In order to check tlie executable code in main memory 36, the boot memory 46, the hiQh capacity storage memory 48, or the serial read-wTite memory 50 for authenticity, only a SHA-1 hash, or its equivalent is necessary since all had been verified at boot-up to riave come from a trusted source via a digital sianature verification process. It is understood that there are various other techniques otlier than. a SHA-i hash function that could be used to verify the authenticity of the various media devices during run time. Such other techniques may include, but are not limited to, CRC-16, CRC-32, MD5 and checksum techniques.
As an additional run-tim.e authentication and verification check, a digital sianature verify operation is performed on the media devices (e.g., main meinory 36, boot memory 46, high capacity storage memory 48, ag:~d serial read-write memory 50) when the gaming software returns from certain gaz.nina events. These events are inainly security events wherein people have had access to the inside of the gaming machine or the Qamingr machine has made a large payout. The security events that may require an additional run-time verification and authenti.cation check along with a digital signature verify operation include, but are not limited to:
1. Any "door closure event". On a gaming m.achine there may be various doors or hatches for providing access to the interior of the gaming machine.
i~
Anytime one of the doors or hatches is closed, the gaming program and otlier various media devices are checked -ior authenticity because someone may have had access to the interior of the gaming machine.
2. Any return to game play when exiting the "administration screen". Various gaming machines have an administration mode. There may be one or more levels for the administration anode. For example, one mode may include critical configuration settings affecting the payouts made by the gaming device and may require machine doors or hatches to be accessed to gain entry, Another nlode may allow an administrator to view and verify meters, event logs, game playtime, machine statistics and other items benign to tlie functionality of the gaming device without unlocking any machine access doors or hatches.
SOFTWARE AUTHENTICikTION
FIELD OF THE INVE,NTION
The present invention relates generally to gaining machines, and more particularly, to software authentication of programs running in a gaming machine.
BACKGROUND OF THE INVENTION
As a regulatory requirement in virtually all jurisdictions that allow gaming, it is necessary to have a technique to authenticate that the software installed in a gaming inachine is tested and approved. In the past, gaming manufacturers have generally used EPROM-based hardware platforms to store program code. As a result, a number io of software authentication techniques have been accepted as standards throughout the gaming industry. Depending upon the preferences of the local regulatorv agency, these techniques generally include either a Kobetron signature or a hash function based on the data stored in the EPROM device.
Authentication of software programs basically occurs using two different is methods in the field, again. determined by the local regulatory agency. In one method, each EPROM is authenticated by a galning agezlt prior to being installed in a gazning machine that is to be brought up for play. The EPROMs mav be shipped directly to the gamincy agency for authen.tication 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.
20 In another method, authentication is conducted on a spot-check basis wherein a gaming agent periodically visits a casino and picks machines for the removal of software components for authentication.
Jurisdictional requirements require that storage media containing code or data be authenticated at power-up, continuously or at a periodic rate, or upon occurrence of 25 predetennined events, such as the opening any doors or panels of the gaming device that allows access to internal circuitry. The storage media may be colnprised of erasable programmable read-only memory devices (EPROMs), electrically erasable programmable read-only memory devices (.EEPROMs), PROMs, CompactFlash storage cards, hard disk drives, CD drives, or substantially any non-volatile memory and in some cases volatile memory (e.g., NVRAM, specialty mask semiconductors, battery backed RAM, SRAM, DRAM, etc.). Storage a.nedia comprises a memory device and the data stored th.ereon. Authentication of storage media is controlled by the ffaming device's central processing unit (CPU). However, authentication by the CPU may take more than several minutes due to increasing complexity of the gaming device's software and thus the stora~e size of the media.
For example, the authenticity of numerous storage devices associated with the CPU may need to be determined every so often while a gaming machine is running.
In some cases, gaming authorities require that a gaming program be authenticated io about every ten minutes while the gaming machine is running. To determine the authenticity of a memory device's contents the CPU must read the memory device and perform various calculations and comparisons to determine if the memory device's contents are authentic. Reading many inemorv devices or large meinory devices can use significant CPU time and therefore may negatively affect the is responsiveness of the gaming program that a user interacts with. What is needed is a tecl-inique for authenticating memory devices associated with a gaming machine that does not affect the gaming program that the user interacts with.
20 SUMMARY OF THE INVENTIOI'+l Embodiments of the present izwention authenticate a gaining machine program, software, firmware, or data (data) stored in memory devices within the ganiing machine while the gaming machine is rtuining and interacting with a user.
The authentication process does not slow or interfere with the gaming program that 25 interacts with the user. The authentication processes are ongoina and are substantially continuously repetitive. The authentication processes niay substantially repeat every 2 minutes to 24 hours. Furthermore, in order to increase the speed of authenticating some of the data, graphics data niay be differentiated from executable data so that the authenticity of the executable data can be determined more often than the graphics 30 data.
It should be understood that for the purposes of this description of exemplary embodiments of the present invention that the gaming machine program nlay be either compiled or uncompiled. Furthermore the gaming machine progratn comprises code, ,J
files, instructions or programs that are executable in that they direct the aaining machine to do something (hereinafter "executable code"). The gaming machine program further comprises graphics code, files, data, instructions or programs (herein after "graphics data") that have to do with graphics or multimedia applications. Such graphics or multimedia may include, but are not limited to, data or information used to control graphics, animation, or other special effects that move air, move fluids, create smells, create bubbles, create flasliing lights, control laser lights, control air pressure, control temperature, control mechanical devices, or control sound devices.
In an embodiment of the present invention a gaming machine comprises a user interface and a central processing unit (CPU) coupled to the user interface.
The CPU
comprises a processor. A first meinory is coupled to t:he processor. The first memory is adapted to contain executable program code. The executable program code has both executable instructions and graphics data. A second memory is also coupled to the processor. The second memory stores data. The executable instructions found in the is first memory include a plurality of instructions configured to cause the processor to determine the authenticity of the executable program code and the data. The processor, with the aid of the executable instructions, determines the authenticity of the executable prograin and the data on a substantially continuous, repetitious basis.
Furthermore, the authenticity determination of the exectitable program code might be performed substantially iri a parallel process with the authenticity determination of the data_ Other executable instructions cause the processor to determine, Nvhen reading said executable program c.ode, ,AThether executable code or graphics data are bein.g read. If the processor is reading graphics data, then the plurality of executable code z1; cause said processor to nct determine the authenticity of the graphics data unless more than a predetermined ntnuber of events have passed since the last time the graphics data was authenticated. The events may be seconds, clock count-ups, countdowns, a number of repetitions through a prograrn loop, etc. I.f the processor reads executable instructions, then the plural:ity of instructions cause the processor to determine the authenticity of said executable instructions.
In anotl2er embodiznent of the present invention, a gaming machine comprises a CPU and a plurality of inemory devices. The CPU is adapted to determine the authenticity of data in at least two of the plurality of memory devices in a parallel, repeating manner. The CPU is also adapted to read the data stored in at least one of the plurality of memory devices and detennine whether the data is executable data or graphics data. If the data stored in a memory is determined to be graphics data, then the CPU is adapted to determine the authentidity of -the graphics, data if -a predetermined number of events have passed. The events may be clock cycles, seconds, count-ups, count-downs, passes through a program ioutine or loop, uses by a user, number of games played, etc. If the data stored in a memory is determined to be' executable data, then said CPU is adapted to determine the authenticity '-of said executable data.
In another embodiment of the present invention a method is provided for authenticating various memory devices' data within a gaming machine while the gaming-machine is operating. The authentication process- of the memory devices"
data can be perfonned in substantially a parallel fashion; such that two or more memory device's data is being authenticated at about the same time. The metliod of authenticating also comprises reading data from a first memory device and ' detennining or using other techniques to determine whether the data is graphics data or executable code. If the data is determined to be graphics data, then more data is read froin the first memory device. If the data is detennined to be executable data, then it is determined whether the executable code is -autlientic after which more data is read from the first memory device. -According to an aspect of the present invention there is provided a method of authenticating memory devices' data within a gaming machine while said gaming machine is operating, said memory devices' data being authenticated substantially in parallel, said method of authenticating comprising: .
reading a next predetermined amount of data from a first memory device storing executable code for operating a wagering game on said gaming machine and graphics data accessed by said executable code to display graphics of said wagering game on a display of said gaming machine;
detennining if the next predetermined amount of data is executable code or graphics data;
if said next predetermined amount of data is graphics data, then reading a next predetermined amount of data, without authenticating the graphics data;
4a if said next predetermined amount of data is executable code, then authenticating said executable code; and wherein the above steps are repeated substantially continuously while said gaming machine is operating.
According to another aspect of the present invention there is provided in a gaming machine that is turned on, a method of repeatedly authenticating at least a first and a second memory substantially in parallel, said method comprising:
reading first data from said first memory storing executable code and graphics data and authenticating said first data, wherein reading first data from said first memory and authenticating said first data comprises:
reading a next file of said first data;
determining if the next predetermined amount of data is executable code or graphics data;
if said next file is a graphics data, then returning to said reading step, without authenticating the graphics data;
if said next file is an executable code, then determining whether said executable file is authentic, then returning to said reading step until all of said first data in said first memory device has been read; and reading second data from said second memory and authenticating said second data;
repeating said reading steps substantially continuously and substantially in parallel.
According to a further aspect of the invention there is provided a gaming machine comprising:
a user interface; and a central processing unit (CPU) coupled to said user interface, said CPU
comprising:
a processor;
a first memory coupled to said processor, said first memory adapted to contain gaming machine program code, said gaming machine program code comprising executable code and graphics data;
a second memory coupled to said processor, said second memory comprising data;
said gaming machine program code further comprises:
4b a plurality of instructions configured to cause said processor to determine the authenticity of said gaming machine program code and said data on a substantially continuous, repetitious basis such that the authenticity determination of said gaming machine program code is performed substantially in parallel with the authenticity determination of said data;
said plurality of instructions are further configured to cause said processor to determine, when reading said gaming machine program code, whether said processor is reading executable code or graphics data, if said processor reads graphics data, then said plurality of instructions cause said processor to not determine the authenticity of said graphics data unless more than a predetermined number of events have passed since the last time said graphics data was authenticated;
if said processor reads said executable code, then said plurality of instructions cause said processor to determine the authenticity of said executable code.
According to a further aspect of the present invention there is provided a gaming machine comprising a CPU, and a plurality of memory devices;
said CPU adapted to determine the authenticity of data in at least two of said plurality of memory devices in a parallel, repeating fashion;
said CPU further adapted to read said data stored in at least one of said plurality of memory devices and determine whether said data is executable code or graphics data;
if said data stored in said at least one of said plurality of memories is graphics data, then said CPU is adapted to determine the authenticity of said graphics data if a predetermined number of events have passed and read said next data stored in at least one of said plurality of memory devices without authenticating the graphics data if a predetermined number of events have not passed;
if said data stored in said at least one of said plurality of memories is executable code, then said CPU is adapted to determine the authenticity of said executable code.
4c According to a further aspect of the present invention there is provided a method of authenticating data within at least one memory of a gaming machine while the gaming machine is executing a wagering game, said at least one memory storing executable code for operating said wagering game and graphics data accessed by said executable code to display graphics of said wagering game on a display of said gaming machine, said method comprising:
(a) determining if a next predetermined amound of data fromo said memory is executable code or graphics data;
(b) if said next predetermined amount of data is executable code, then authenticating said executable code and returning to step (a); and (c) if said next predetermined amount of data is graphics data and a predetermined condition has been met, then authenticating said graphics data and returning to step (a);
and if said next predetermined amount of data is graphics data and said predetermined condition has not been met, then returning to step (a) without authenticating said graphics data.
According to a further aspect of the present invention there is provided a method of authenticating data within at least one memory of a gaming machine, said at least one memory storing executable code for operating a wagering game on said gaming machine and graphics data accessed by said executable code to display graphics of said wagering game on a display of said gaming machine, said method comprising:
(a) while said gaming machine is booting up, authenticating both the executable code and the graphics data; and (b) while said gaming machine is executing said wagering game after booting up:
(i) determining if a next predetermined amount of data from said memory is executable code or graphics data;
(ii) if said next predetermined amount of data is executable code, then authenticating said executable code and returning to step (i); and (iii) if said next predetermined amount of data is graphics data and a predetermined condition has been met, then authenticating said graphics data and returning to step (i); and if said next predetermined amount of data is graphics data and said predetermined condition has not been met, then returning to step (i) without authenticating said graphics data.
4d According to a further aspect of the present invention there is provided a method of authenticating data within at least one memory of a gaming machine, said at least one memory storing executable code for operating a wagering game on said gaming machine and graphics data accessed by said executable code to display graphics of said wagering game on a display of said gaming machine, said method comprising:
(a) while said gaming machine is booting up, authenticating both the executable code and the graphics data; and (b) while said gaming machine is executing said wagering game after booting up, authenticating said executable code at a first frequency and authenticating said graphics data at a second frequency, said first frequency being greater than said second frequency.
The above summary of the present invention is not intended to represent each embodiment, or every aspect, of the present invention. This is the purpose of the figures and the detailed description which follow.
BRIEF DESCRIPTION OF THE DRAWINGS
The foregoing and other advantages of the invention will become apparent upon reading the following detailed description and upon reference to the drawings.
Figure 1 is an isometric view of a gaming machirie operable to conduct a wagering game;
Figure 2. is an exemplary block diagram of a CPU in a gaming machine according to the present invention; and Figure 3 is a flow.chart for an exemplary run-time authentication process for a gaming machine.
While the invention is susceptible to various modifications and alternative forms, specific embodiments have been shown by way of example in tlie drawings and will be described in detail herein. It should be understood, however, tliat the invention is not intended to be limited to the particular forins disclosed.
Rather, the s invention is to cover all modifications, equivalents, and al'ternatives falling within the spirit and scope of the invention as defined by the appended claims.
Description of Illustrative Embodiments Turning now to the drawings and referring initially to Figure 1, a gaming lo 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 includes a video display 12 such as a cathode ray tube (CRT), liquid crystal display (LCD), plasma, or other type of visual display known in the art. A touch screen preferably overlies the display 12. In the illustrated embodiment, the gaming machine is 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-top" version in which the display 12 is slanted at about a thirty-degree angle tovvard the player.
The gaming machine 10 includes a plurality of possible credif receiving mechanisms 14 for receiving credits to be used for placing wagers in the game.
The 20 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 exa.mple, accept magnetic cards and smart (cl~ips) cards coded with .r.noi~ey or designatin4 an account containing money.
25 The gaming niachin 10 includes a user interface comprising a plurality of push-buttons 16, the above-noted touch screen, and otl7er possible devices.
The plurality of push-buttons 16 may, for exainple, include one or more "bet"
buttons for wagering, a "play" button for coirzmencing play, a"collect", button for cashing out, a "help" button for viewing a help screen, a "pay table" button for viewing the pay 30 table(s), and a "call attendant" button for calling an attendant.
Additional game-specific buttons may be provided to facilitate play of the specific game executed on the machine. The touch screen may define touch keys for implementing many of the same fun.ctions as the push-buttons. Other possible user interface devices include a keyboard and a pointing device such as a rriouse or trackball.
Referring now to F:igure. 2, a central processing unit (CPU) 30 controls operation of the gaming machine 10. In response to receiving a wager and a command to initiate play, the CPU 30 randomly selects a game outcome from a plurality of possible outcomes and causes the display 12, via the video circuitry 39 and video out 40, to depict indicia representative of the selected game outcome.
Alternatively, the game outcome may be centrally detennined at a remote computer using either a random number generator (RNG) or pooling schema. 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 defzned by a pay table, the CPU 30 awards the player with a number of credits associated writh the winning outcome.
The CPU 30 includes a nlicroprocessor 32 and various memory devices (media devices). The microprocessor 32 interfaces with many other components of the gaming machine 10 via an interface bus 34. A inain memory 36 stores the compiled gaming machine program for operating the gaming machine 10.
The main meinor>> 36 i.nay be DRAM or SRAM or substantially any other volatile memory device or .reprogrammable non-volatile ineinory device. The battery backed memory 38 stores machine critical data that cannot be lost when power is removed from machine 10. The battery backed memory 38 may be battery backed volatile memory or a reprograrnmable or rewritable non-volatile memory device.
The video circuitry 39 supplies display information to a, video display 12 that may comprise a CRT, LCD, plasma, or other displav device. Audio circuitry 42 generates sounds for game play on the gaming rnachine 10. The I/O control 44 controls input/output interfaces with the user interfaces such as game buttons 16, coin validators 14, touch screen bill validators, multimedia devices, etc.
In an exemplary embodiment, the various memory devices may also include a boot memory 46, a high capacity storage memory 48, an.d a serial read-write memory 50. The boot memory 46 is preferably a read-only memory such as a one megabit EPROM, EEPROM, PROM or other type or appropriately sized programmable read-only memory. The boot memory 46 may also be substantiallv any type of non-volatile memory. The high capacity storage memor-v 48 is preferably a CompactFlash `]
card, but may also be a hard disk drive, CD drive, DVD drive, magnetic RAM, battery backed RAM or other type of non-volatile memory. The serial memory 50 is preferably an EEPROM such as a 51.2 byte SPI EEPROM, but could be any type of programmable read-only or read/write non-volatile memory. Depending upon the preferences of the local aaming regulatory agency, all three memories may be adapted to be authenticated outside of the CPU as well as when installed in the CPU at power up or prior to being utilized in the gaming machine.
The boot memorv 46 stores, at least some of the following, boot code 52, an authentication program 54, a RAM loader, a decompression utility 56, and a digital io signature 58. The authentication program includes a hash function 60, a digital signature verification algorithm 62, and a public key 64. The hash function 60 may, for example, be an SH.A-1 hash algorithm that reduces a data set to a unique 160 bit message digest. A hash algorithm or function is used to calculate a message digest corresponding to the files in, for example, a memory device. The message digest does Is not have to be unique, i.e., the function -?nay return the same hash value for two or more items (althouffh this is very unlikely). The non-uni.queness of the hash value for each item in the message digest is acceptable because each hash value is used to evaluate a different file or data set within a memory device. The message digest is a small representation of a large amount of data. A message digest is a relatively 20 unique representation of data, from a cryptographic standpoint, and is an irreversible representation of the data. In other words, one cannot recreate t11e original data from the message digest.
The digital sianature 58 is generated, in effect, from the boot memory's contents as a whole. ln an exemplary embodiment, after hashing is performed to produce a message digest, then a digital signature is created to enable the origin and autlienticity of the digest to be determined. When there is data that requires a means for determining the origin of the data, one generally uses a digital signature mechanism. There exists a federal standard called FIPS 186-2 that defines a digital signature generation and verification mechanism called the Digital Signature 30 Algorithm (DSA). In an exemplary embodiment a digital sianature is created from the message digest. In essence the DSA uses a private key, a public key, and the message digest. A private key and the message digest are used to create an original signature associated with the original message digest. The public key, the original signattiue, and a ca.lculated message digest are used to check a signature associated with a message digest in order to determine the origin and authenticity of the data set.
It is understood that neither the message digest nor the data or files used to create the message digest can be recreated using the DSA. The digital signature 58 is used to sign the message digest of the boot memory contents. Again, the signature may be used to determine the source or manufacturer of the inessage digest, via a public key, but caiuzot be used to recreate the message digest or the original data.
Furthermore, the DSA is not being used here as an encryption process under FIPS 186-2, but rather a technique for validating the signature associated with the data set, and the public io key.
The high capacitv storage memorv 48 stores gaine and operating system executable program files 66, sound operating system files 68, sound bank files 70, araphics files 72, a file list of file types 74, and digital signatures 76, 78. The files in the high capacity storage memory 48, taken toaether,, constitute a"gaming program"
5 as that term is used herein, and the various files constitute "data files"
as that term is used herein. Thus, the gamina program includes a plurality of data files. For each data file on the high capacity storage memory 48, the manifest file contains a file nan7e, a file type, a load address, and a file digital signature 76. The whole device digital signature 78 is generated from the gaming program as a whole, while each 20 digital signature 76 is generated from the associated data file listed in the manifest file.
The serial read-write memory D-0 stores inform.ation/data specific to the jurisdiction where the CPt? is to be installed. This information may, for example, include a lottery terminai identification (ID) 80, a part number 82, a jurisdiction ID
255 84, a jurisdiction name 86, jurisdietion bit code options 88, jurisdiction max bet 90, jurisdiction max win 92, and a digital signature 94. The digital signature 94 is gener=ated from the sei-aal memory's contents as a whole.
The boot memory 46, serial read-write memory 50 and high capacity storage memory 48 may each be removable devices and/or contain alterable software.
Each 30 of these memory devices may, be able to be reprogrammed or be able to receive downloaded updates from an outside source via a programming device, a network such as the Internet, an intranet, an Ethemet, a fibre loop, or other type of networking system. The boot meniory 46, serial read-write memory 50, and high capacity memory 48 each may be required to be authenticated by the gaminQ machine 10 at various points during operation of the gaining machine.
In order to bett:er understand the advantages of an exemplary run-time authentication algorithm, it is important to realize that as gaining machines evolved they began to use alterable media, such as flash memories, EEPROMs, EPROMs, CD
drives, disk drives, etc. in their electronics and programming structure to store all or portions of the programs and files. Newer gaming machines are designed to allow the gaming software to be updated, to grow in size, and to grow in coinplexity.
Because of these advances and changes in gaming machine design, electronics, software and io memory storage size the time necessary to authenticate the software in the storage media during run-time operations has increased because the methods required to authenticate the software content became more complex. An increase in the time required to authenticate the software during machine run-time operations may affect the responsiveness and speed of the run-time software as well as the smoothness of ls operation to the extent that it is noticeable to the user. A CPU may become unable to effectively operate the gaminQ machine main prograin while inultiplexing authentication processes are taking place due to the sheer size of the main program that must be authenticated within a predefined period of time. Thus, it is iiecessary to provide a teclmique to authenticate the gaming programs and media within various 20 media devices without s]owing or disturbing the operation of the gaming machine.
An exemplary run-time authentication comprises tw,o main cycles of events during the operation of a gaming machirie. The first cycle of events checks whether the high capacity storage memory 48 is connected to the bus 34. This check is perforined at predetermined intervals tha,: may range from about every 5 ms to about 25 everv minute. The first cycle also checks whether the high capacity storaae memory's 48 SIIA-1 message di-est calculation is continuously being recalculated.
The second cycle of events performs a constant or continuous authentication of the boot fnemory 46, the serial read-write meinory 50, the files that are being executed froin the main i:lemory 36, and the integrity of the data stored in the battery 30 backed memory 38. Ltilizing a SHA-1 hash message digest of a media device's contents the authentication of each inedia device is performd. The authentication of the media device during a run-time authentication may be limited to the data in the whole media device rather than the individual files stored in the media device. The authentication of a media device may also be performed file by file when the CPU has stored the memory locations and the type of data in the memory locations prior to an authentication process.
During a boot-up process of the CPU 30 the media devices and software s thereon are normally authenticated. The boot-up authentication process includes performing a SHA-1 hash over the media software that is loaded into the main memory 36, authenticating the diffital signature 58, 78, 94, and storing the calculated hash message digest in battery backed memory. Thus, during run-time authentication there is no requirement to perform signature verification since the files and io components were proven to be authentic during the boot process. One main purpose of run-time authentication is so the CPU 30 can check to make sure that the files and data loaded into the main memon, 36 during the boot process have not been altered.
Another purpose of the run-time authentication is to verify that certain software or hardware components, such as the boot memory 46, the high capacity storage memory 1.5 48, or the serial read-w-rite memory 50 have not been changed or undergone a change in any of tlzeir software/firmware. In order to check tlie executable code in main memory 36, the boot memory 46, the hiQh capacity storage memory 48, or the serial read-wTite memory 50 for authenticity, only a SHA-1 hash, or its equivalent is necessary since all had been verified at boot-up to riave come from a trusted source via a digital sianature verification process. It is understood that there are various other techniques otlier than. a SHA-i hash function that could be used to verify the authenticity of the various media devices during run time. Such other techniques may include, but are not limited to, CRC-16, CRC-32, MD5 and checksum techniques.
As an additional run-tim.e authentication and verification check, a digital sianature verify operation is performed on the media devices (e.g., main meinory 36, boot memory 46, high capacity storage memory 48, ag:~d serial read-write memory 50) when the gaming software returns from certain gaz.nina events. These events are inainly security events wherein people have had access to the inside of the gaming machine or the Qamingr machine has made a large payout. The security events that may require an additional run-time verification and authenti.cation check along with a digital signature verify operation include, but are not limited to:
1. Any "door closure event". On a gaming m.achine there may be various doors or hatches for providing access to the interior of the gaming machine.
i~
Anytime one of the doors or hatches is closed, the gaming program and otlier various media devices are checked -ior authenticity because someone may have had access to the interior of the gaming machine.
2. Any return to game play when exiting the "administration screen". Various gaming machines have an administration mode. There may be one or more levels for the administration anode. For example, one mode may include critical configuration settings affecting the payouts made by the gaming device and may require machine doors or hatches to be accessed to gain entry, Another nlode may allow an administrator to view and verify meters, event logs, game playtime, machine statistics and other items benign to tlie functionality of the gaming device without unlocking any machine access doors or hatches.
3. Any return to game play from a "game disable" state. An attendant, a command from a host system, or other internal mechanisms can place the ls gaming machine in a game disable state in. order to reserve the gaming machine for a certain player or for numerous other reasons. Essentially the gaming machine is on, but will not operate iuitil it is taken out of the disabled state.
4_ Any cashout handpay state. A caslzout handpay is typical when a player ?o would like to cash out of Qaming machine and the amount of credit or winnings on the gazning machine is higher than the amount of coins or payout u.nits in the gaming machine's hopper or higher tlian an operator confiffured machine payout limit. If tl-iis occurs, the garnina machine may go into a cashout handpay state wherein an attendant will have to come to the gaming 2-S machine and assist the pla_yer so that the player ca.n get manually paid or handpaid. Once the cashotit handpay is completed the attendant will use a key, card or other code or device to access the gaming machine and exit from the cashout handpay state.
5. Any Jackpot handpa;- state. A Jackpot handpEry state is shriilar to the cashout 30 handpay state, except tlae gaming machine is set to go into a Jackpot handpay state when a jackpot hit by the player is above a predetermined amount such as a monetary amount that must be reported to Internal Revenue Service (IRS).
When a jackpot of the predetermined ainount or greater is hit then the machine locks up and an attendant is called to hand pay the player and further to have the player fill out the appropriate IRS (W-2G) form(s). The attendant can then use a kev, card, pass code, or other appropriate means to reset tlie cyaming machine into a play mode again.
After a successful verification of all files in main znemory 36, the battery backed memory 38 is verified using, for example, a CRC check. The battery backed memory 38 can be set to store two copies of critical data -- a first copy that is stored as a master copy and a second copy that is stored as an auxiliary copy. The master lo copyprogram and auxiliary copy of the critical data can. also be compared to each other to help ensure the integrity of the critical data being stored in the battery backed memory 38.
Figure 3 depicts a flow chart of an exemplary authentication process for continuous run-time authentication in accordance with an embodiment of the present 15 invention. After boot-up of the gaming machine, w;'ierein gaming machine program software or firznware was autllenticated in at least one of a variety of accepted ways, and vvhile the Qamin~ machine is operational, the CPU 30 will, in conjunction with executin- the E!aming machine pro-ram, continuously authenticate the main memory 36, battery backed memory 38, boot memory 46, high capacity storage memory 48, 20 the serial read-write memory 50 and any other memories that may require authentication. The CPU can be set to authenticate substantially any media device in the gaming machine or closely associated with tlie gaming machine through a network. The main application is launched at step 100 from the main memory 36.
The gaming machine is operational and the authentication of predetermined media 25 devices begins. Froi-ri. step 100, two authentication ftuzctionalities operate substantially in parallel as depicted by path A and path B. Path A
authenticates the high capacity storage memory 48, and path B authenticates, in a serial fashion, the main memory 36, the battery backed memory 38, boot memory 46, and. the serial read-write memory 50. The dotted line for pat11 C indicates that otller authentication 30 processes may also take place in parallel with path A and B.
Discussing path A first, a predeterinined a7nount of data is read from the high capacity storage memory 48 at step 102. Path A is separated from path B
because the high capacity storage memory 48 may include a much larger amount of data then that which is found on patli B. By sepaT-ating the paths, all con2ponents on path B
can be authenticated one or more times in the same time as one cycle through path A.
The predetermined amount of data may be a bit, a byte, aword or, for example, 1 bit to 1 Kb;rtes of data, or any amount of data that the architecture can handle in the time allotted for the function. The CPU processes the gamina machine program and performs the authentication functionalities in a time sharing manner. The percentage of sharing depends on how the sharing affects the gaming machine program's main application that interacts with a user while coinpleting the authentication within a predetermined amount of time.
At step 102 the data that is read is used to calculate a hash message digest representative of the data. At step 103, the CPUdetermines whetlier all the data in the liigh capacity memory 48 lias been read in order to determine if the hash calculation is complete. If all the data from the higii capacity memory 48 has not been read then the algorithm retums to step 102 to read more data and continue calculating the hash ~ message digest. If at step 103 the hash calculation for all the data has been completed then, at step 104, the calculated hash ii-iessage digest is compared with a previously stored hash message digest result for the data contents of the high capacity storage memory. The stored hash result may have been stored in one of the various non-volatile memories in the c,aminL, machine. For exaz:npleõ the stored hash result may have been stored in a battery backed NVRAM 38 during boot-up. If the verification comparison indicates tha'_ the calculated hash message digest and the stored hash message digest are the same, then the high capacity memory is considered authenticated and the algorithm returns to step 102 and begins reading data from the high capacit_y storage memory 48 from the beginning (or any predetermined data location) atrain. This loop continues for as long as the ganzing machine is powered on. If the verification comparison fails, at step 104, due to the stored hash not being equal to the calculated hash, then a critical error is displayed, at step 105, on the Qaming machine. The garning machine then becomes non-funetional or out-of-order until an attendant comes over the machine and determines what needs to be done to correct the error.
Ideally, the high capacity storage memory has the predetermined arnount of data read from it about every 15 ms, but the data reading loop of path A may be substantially any amount of time, for example, fi-om between 2 gns to once a day so 1ona as the read takes place within the limitations of CPU. It is tuzderstood that in an exemplary embodiment of the present invention, the high capacity storage memory 48 is not the device from which code is executed. F'or example, the high capacity memory 48 may be a compact flash card, a hard drive or other type of non-volatile memory device that cannot be used to execute the gamina program. In many circumstances, the high capacity memory 48 may be hot-plugable or hot-swappable with the gaming machine. As such, the run-time validation of the high capacity memory 48 also functions in various ways, as a check or means for making sure the high capacity memory has not been removed, unplugged or partially disconnected zo from the gaming machine after boot-up.
Furthennore, the high capacity memory 48 :inay be a non-volatile memory, capable of providing an executable program to the microprocessor 32. If this is so, an exemplary embodiment of the invention may not be required to have both a main memory 36 and a high capacity memory 48.
It should be noted aoain with respect to path A, that there might be more than one hiQh capacity memory that must be authenticated. Path O(dotted line) represents an algoritlun wherein one or more additional high capacity memories (or otlier media devices) are part of the CPU 30 in an exemplary gamintr machine. The data in the additional memories may be authenticated via similar means and in parallel with paths A and B.
With respect to path B coming out of step 100, at step 106 data is read from the serial read-write memory 50 and a hash message digest is calculated from all the bits. In the exemplary embodiment the serial read-write memory 50 contains significantly less data than the high capacity memory 48. Since there is significantly less data in the serial read-write memory 50 than the high capacity memory 48, the data in the entire memory can be read as a binary iinage su.ch that a hash calculation can be performed. The hash calculation result is then compared with a stored serial read-write memory hash rr_essage digest that was calculated at boot-up. If the two hash message digests do not match, then the algoritlun indicates that the authentication failed and a critical error is displayed on the gazning machine at step 5.
On the other hand, if the stored and calculated hash. message digests match, then the serial read-write memory contents are considered validated and authentic.
At step 107, the boot memory's data is read and a hash message digest is calculated. The calculated boot memory hash is compared with a boot memory hash message digest that was stored at boot-up. If the hash message digests do not match, the fail path is taken to step 105 and a critical error is displaved on the gaming machine. If the hash message digests match then the boot iuemory data is validated.
Another step could be placed here to validate a7y other memory associated with the CPU 30. These additional steps may be substantially the same as steps 106 and 107.
Once steps 106 and 107 (and any other similar steps) are completed the algorithm goes to step 108. Either path A or B may have one or more authentication processes io performed in a serial fashion.
In an exemplary embodiment of the present invention the main memory 36, or other memories (such as the battery backed memory 28 or possibly the high capacity memory 48) may contain both executable code along uith graphics data.
Executable code and graphics data may be compiled code or uncompiled code. When the gaming is machine program (the game executable, operating system executable, and all graphics data) is compiled as a sit.lgle compiled gaming machine program and stored in the main memory 36 (or other memories) the sin6le compiled gaining machine program can be quite large and take a significant amount of time to authenticate -,vhen compared to the time required to authenticate, for example, the boot memory 46.
20 Table 1 illustrates approximate authentication times of coinpiled or executable proarams or files an embodiment of the present inventioll.
Executable Program Size Average Verification Time 1.5 MB 1.9 minutes 3.0 MB 3.8 minutes 4.5 MB 5.7 minutes - -;
6.0 MB 7.6 minutes 7.5 MB 9.5 minutes 9.0 MB 11.4 minutes Table 1 If a first gaming machine has a gaming machine program in its main memory that is about 1.5 MB, then the authentication time is within a reasonable time frame of less than about 10 minutes. 'if a secon.d gaming inachine has a gaming machine program in its main memory that is greater than about 6.0 MB, then the time required to authenticate begins to become unacceptable due to gaming agencies requesting that the traming software be authenticated about every 10 minutes while the gaming machine is powered on.
io Assume that the main difference between the first and the second gaming machine is that there is more graphics data in the second ga.ming machine's gaming machine program. Then, it is Luldersta.ndable that if the compiled executable code in both gaming machines are about the same size (give or take a few megabytes), then a.
separation of executable code portions of the gaming machine program from the is crraphics data portions would decrease the time required to authenticate the second machine's compiled gaming machine program to about the same amount of time as the first maehine's compiled gaining machine program. Furthermore, tampering with the executable data inay be more harmful to a user of the gaming machine than tampering with the graphics data. This is because adjusting or tampering with the 20 executable part of the program mav affect the proper odds and payouts of the gaming machine. VJherein tamperi.ng with the graphics data may have the lesser effect of disturbing the gaming grapliics or other multimedia expe.rience. As such, in one embodiment of the present invention the graphics data is separated and left out of the authentication cycle. This may be acceptable because all the graphics data is called 25 by the executable code, which is constantly authenticated. In another embodiment of the present invention, the graphics data is authenticated on a less frequent basis in order to offload the processor so that more time can be dedicated to authenticating the executable code files. For example, the g-raphics data in tlie main memory may only be authenticated from every other time the executable code is authenticated to once s every hour, day, at predetermined intervals, or after a predeterinined number of events. A timer or counter may be utilized to measure a predetermined number of events such as clock counts, cycles, up-counts, down courits, seconds, number of games played, number of users, etc.
Still looking at step 108 of Figure 3. an exernplary authentication algorithm begins to read data from the main memory (SDRAM:) 36 and determined if the data being read is executable code or some axiother type of code such as graphics data.
The determination of whether data is graphics data or executable code can be inade prior to reading the data. Reading data and the deterrnining whether the data is graphics data or executable code can take more time than already having loaded static is memory addresses of indicating whether data in such static memory addresses is araphics data or executable code. As such, in embodiments of the present invention, static memory addresses are loaded into one of the volatile or non-volatile memories indicating where all the data is, for example, in the main memory 36 or the high capacity memory 28 and Zn,That type of data it is. In other exemplary embodiments of the present invention wherein data is dynamically loaded into a memory device, various exemplary methods can be utilired to identify the data locations and the data type. For exaznple, a list indicating which memory locations are storing (Yraphics data and which memory locations are storinQ executable code can be created and stored at the time the data is loaded into a meinory device at boot-up during programming of z, the device, or any other time. Such a list allows the C:PIJ to forego reading the data before making a type-of-data determination.
If the data read is executable code (e.Q.., belongs to an executable fiie), then at step 110 a hash calculation is performed on the content of that executable file. The hash messaLe digest is compared ayainst the hash message digest that was stored in a non-volatile RAM at, for example, boot-up for the particular executable file.
If the hash message digests do not inatch, then authentication fails and a critical error is displayed at step 105. If the si.gnatures ,:zlatch and are verified, then the executable file is authenticated. At step 112 it is determined A~hether all the executable files in the main memory have been read. If all the files have not been read then the algorithm aoes back to step 108 to read the next file or predetermined amount of data.
If the next file or predetermined amount of data that is read at step 108 is not executable code, then at step 109 a timer or counter is checked. If this is the first tiine through the algorithm loop; then the algorithm will automatically go from step 109 to step 111 wherein non-executable data or files (e.g., graphics data or files) are authenticated. If this is not the first time through the algorithm loop, then the timer, counter or countdown (hereinafter "tim.er'") is checked to detei-snine whether a predetermined amount of time (counts or number of events) have passed. If the predetermined amount of time had not passed, then the non-executable file is not authenticated at step 111 and the algorithm returns to step 108 to read the next file. If the timer has reached the p.redetermined amount of time (counts), then the graphics file is checked for authenticity via, for example, by comparing a calculated hash message diaest with a previously stored hash message digest as discussed previously.
is If the non-executable file cannot be authenticated by the calculate-and-compare hashes method, then a critical error is displayed at step 105. If the non-executable file is authenticated by calculating a hasli message digest arid then cornparing the calculated message digest with a stored message digest for the file, then the algoritlun checks whether the last file in the main memory has been read at step 112. If the last file has not been read, then the algorithm returns to step 108 and reads the next file or predetermined amount of data. If the last file has been read from the main memory 36 at step 112, then the battery backed memory 38 is checked at step 113.
With respect to step 109, another exemplary embodiment may have a timer for each of the 6raphics data files so that the more critical graphics data files can be set to be checked more often than, for example, a non-critical graphics data file.
Another exemplary reason for giving each graphics data file its own timer would be to stagger the authentication of the aion-executablie files in order to limit loading on the microprocessor 32.
The battery backed meznorv 38 is checked at step 113. In an exemplary embodiment a cyclic redundancy check (CRC) is performed on the nonvolatile RAM, battery backed memory 38. A CRC is a technique for detecting data changes or errors. A checksum or perhaps a hash calculation could also be used to authenticate the battery backed memorv 38.
lf the battery backed memory 38 is not determined to be authentic, then a critical error is displayed at step 105. If the battery backed memory 38 is authenticated, then the exemplary algorithm checks to make sure the inachine is running at step 114. If the machine continues to be operational then the loop returns to step 106 wherein the authentication of data within the selected memory devices is repeated in a serial manner and substantially in parallel With the authentication of the high capacity memory 48.
While the present invention has been described with reference to one or more particular embodiments, those skilied in the art will recognize that many changes may be made thereto without departing from the spirit and scope of the present invention.
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.
4_ Any cashout handpay state. A caslzout handpay is typical when a player ?o would like to cash out of Qaming machine and the amount of credit or winnings on the gazning machine is higher than the amount of coins or payout u.nits in the gaming machine's hopper or higher tlian an operator confiffured machine payout limit. If tl-iis occurs, the garnina machine may go into a cashout handpay state wherein an attendant will have to come to the gaming 2-S machine and assist the pla_yer so that the player ca.n get manually paid or handpaid. Once the cashotit handpay is completed the attendant will use a key, card or other code or device to access the gaming machine and exit from the cashout handpay state.
5. Any Jackpot handpa;- state. A Jackpot handpEry state is shriilar to the cashout 30 handpay state, except tlae gaming machine is set to go into a Jackpot handpay state when a jackpot hit by the player is above a predetermined amount such as a monetary amount that must be reported to Internal Revenue Service (IRS).
When a jackpot of the predetermined ainount or greater is hit then the machine locks up and an attendant is called to hand pay the player and further to have the player fill out the appropriate IRS (W-2G) form(s). The attendant can then use a kev, card, pass code, or other appropriate means to reset tlie cyaming machine into a play mode again.
After a successful verification of all files in main znemory 36, the battery backed memory 38 is verified using, for example, a CRC check. The battery backed memory 38 can be set to store two copies of critical data -- a first copy that is stored as a master copy and a second copy that is stored as an auxiliary copy. The master lo copyprogram and auxiliary copy of the critical data can. also be compared to each other to help ensure the integrity of the critical data being stored in the battery backed memory 38.
Figure 3 depicts a flow chart of an exemplary authentication process for continuous run-time authentication in accordance with an embodiment of the present 15 invention. After boot-up of the gaming machine, w;'ierein gaming machine program software or firznware was autllenticated in at least one of a variety of accepted ways, and vvhile the Qamin~ machine is operational, the CPU 30 will, in conjunction with executin- the E!aming machine pro-ram, continuously authenticate the main memory 36, battery backed memory 38, boot memory 46, high capacity storage memory 48, 20 the serial read-write memory 50 and any other memories that may require authentication. The CPU can be set to authenticate substantially any media device in the gaming machine or closely associated with tlie gaming machine through a network. The main application is launched at step 100 from the main memory 36.
The gaming machine is operational and the authentication of predetermined media 25 devices begins. Froi-ri. step 100, two authentication ftuzctionalities operate substantially in parallel as depicted by path A and path B. Path A
authenticates the high capacity storage memory 48, and path B authenticates, in a serial fashion, the main memory 36, the battery backed memory 38, boot memory 46, and. the serial read-write memory 50. The dotted line for pat11 C indicates that otller authentication 30 processes may also take place in parallel with path A and B.
Discussing path A first, a predeterinined a7nount of data is read from the high capacity storage memory 48 at step 102. Path A is separated from path B
because the high capacity storage memory 48 may include a much larger amount of data then that which is found on patli B. By sepaT-ating the paths, all con2ponents on path B
can be authenticated one or more times in the same time as one cycle through path A.
The predetermined amount of data may be a bit, a byte, aword or, for example, 1 bit to 1 Kb;rtes of data, or any amount of data that the architecture can handle in the time allotted for the function. The CPU processes the gamina machine program and performs the authentication functionalities in a time sharing manner. The percentage of sharing depends on how the sharing affects the gaming machine program's main application that interacts with a user while coinpleting the authentication within a predetermined amount of time.
At step 102 the data that is read is used to calculate a hash message digest representative of the data. At step 103, the CPUdetermines whetlier all the data in the liigh capacity memory 48 lias been read in order to determine if the hash calculation is complete. If all the data from the higii capacity memory 48 has not been read then the algorithm retums to step 102 to read more data and continue calculating the hash ~ message digest. If at step 103 the hash calculation for all the data has been completed then, at step 104, the calculated hash ii-iessage digest is compared with a previously stored hash message digest result for the data contents of the high capacity storage memory. The stored hash result may have been stored in one of the various non-volatile memories in the c,aminL, machine. For exaz:npleõ the stored hash result may have been stored in a battery backed NVRAM 38 during boot-up. If the verification comparison indicates tha'_ the calculated hash message digest and the stored hash message digest are the same, then the high capacity memory is considered authenticated and the algorithm returns to step 102 and begins reading data from the high capacit_y storage memory 48 from the beginning (or any predetermined data location) atrain. This loop continues for as long as the ganzing machine is powered on. If the verification comparison fails, at step 104, due to the stored hash not being equal to the calculated hash, then a critical error is displayed, at step 105, on the Qaming machine. The garning machine then becomes non-funetional or out-of-order until an attendant comes over the machine and determines what needs to be done to correct the error.
Ideally, the high capacity storage memory has the predetermined arnount of data read from it about every 15 ms, but the data reading loop of path A may be substantially any amount of time, for example, fi-om between 2 gns to once a day so 1ona as the read takes place within the limitations of CPU. It is tuzderstood that in an exemplary embodiment of the present invention, the high capacity storage memory 48 is not the device from which code is executed. F'or example, the high capacity memory 48 may be a compact flash card, a hard drive or other type of non-volatile memory device that cannot be used to execute the gamina program. In many circumstances, the high capacity memory 48 may be hot-plugable or hot-swappable with the gaming machine. As such, the run-time validation of the high capacity memory 48 also functions in various ways, as a check or means for making sure the high capacity memory has not been removed, unplugged or partially disconnected zo from the gaming machine after boot-up.
Furthennore, the high capacity memory 48 :inay be a non-volatile memory, capable of providing an executable program to the microprocessor 32. If this is so, an exemplary embodiment of the invention may not be required to have both a main memory 36 and a high capacity memory 48.
It should be noted aoain with respect to path A, that there might be more than one hiQh capacity memory that must be authenticated. Path O(dotted line) represents an algoritlun wherein one or more additional high capacity memories (or otlier media devices) are part of the CPU 30 in an exemplary gamintr machine. The data in the additional memories may be authenticated via similar means and in parallel with paths A and B.
With respect to path B coming out of step 100, at step 106 data is read from the serial read-write memory 50 and a hash message digest is calculated from all the bits. In the exemplary embodiment the serial read-write memory 50 contains significantly less data than the high capacity memory 48. Since there is significantly less data in the serial read-write memory 50 than the high capacity memory 48, the data in the entire memory can be read as a binary iinage su.ch that a hash calculation can be performed. The hash calculation result is then compared with a stored serial read-write memory hash rr_essage digest that was calculated at boot-up. If the two hash message digests do not match, then the algoritlun indicates that the authentication failed and a critical error is displayed on the gazning machine at step 5.
On the other hand, if the stored and calculated hash. message digests match, then the serial read-write memory contents are considered validated and authentic.
At step 107, the boot memory's data is read and a hash message digest is calculated. The calculated boot memory hash is compared with a boot memory hash message digest that was stored at boot-up. If the hash message digests do not match, the fail path is taken to step 105 and a critical error is displaved on the gaming machine. If the hash message digests match then the boot iuemory data is validated.
Another step could be placed here to validate a7y other memory associated with the CPU 30. These additional steps may be substantially the same as steps 106 and 107.
Once steps 106 and 107 (and any other similar steps) are completed the algorithm goes to step 108. Either path A or B may have one or more authentication processes io performed in a serial fashion.
In an exemplary embodiment of the present invention the main memory 36, or other memories (such as the battery backed memory 28 or possibly the high capacity memory 48) may contain both executable code along uith graphics data.
Executable code and graphics data may be compiled code or uncompiled code. When the gaming is machine program (the game executable, operating system executable, and all graphics data) is compiled as a sit.lgle compiled gaming machine program and stored in the main memory 36 (or other memories) the sin6le compiled gaining machine program can be quite large and take a significant amount of time to authenticate -,vhen compared to the time required to authenticate, for example, the boot memory 46.
20 Table 1 illustrates approximate authentication times of coinpiled or executable proarams or files an embodiment of the present inventioll.
Executable Program Size Average Verification Time 1.5 MB 1.9 minutes 3.0 MB 3.8 minutes 4.5 MB 5.7 minutes - -;
6.0 MB 7.6 minutes 7.5 MB 9.5 minutes 9.0 MB 11.4 minutes Table 1 If a first gaming machine has a gaming machine program in its main memory that is about 1.5 MB, then the authentication time is within a reasonable time frame of less than about 10 minutes. 'if a secon.d gaming inachine has a gaming machine program in its main memory that is greater than about 6.0 MB, then the time required to authenticate begins to become unacceptable due to gaming agencies requesting that the traming software be authenticated about every 10 minutes while the gaming machine is powered on.
io Assume that the main difference between the first and the second gaming machine is that there is more graphics data in the second ga.ming machine's gaming machine program. Then, it is Luldersta.ndable that if the compiled executable code in both gaming machines are about the same size (give or take a few megabytes), then a.
separation of executable code portions of the gaming machine program from the is crraphics data portions would decrease the time required to authenticate the second machine's compiled gaming machine program to about the same amount of time as the first maehine's compiled gaining machine program. Furthermore, tampering with the executable data inay be more harmful to a user of the gaming machine than tampering with the graphics data. This is because adjusting or tampering with the 20 executable part of the program mav affect the proper odds and payouts of the gaming machine. VJherein tamperi.ng with the graphics data may have the lesser effect of disturbing the gaming grapliics or other multimedia expe.rience. As such, in one embodiment of the present invention the graphics data is separated and left out of the authentication cycle. This may be acceptable because all the graphics data is called 25 by the executable code, which is constantly authenticated. In another embodiment of the present invention, the graphics data is authenticated on a less frequent basis in order to offload the processor so that more time can be dedicated to authenticating the executable code files. For example, the g-raphics data in tlie main memory may only be authenticated from every other time the executable code is authenticated to once s every hour, day, at predetermined intervals, or after a predeterinined number of events. A timer or counter may be utilized to measure a predetermined number of events such as clock counts, cycles, up-counts, down courits, seconds, number of games played, number of users, etc.
Still looking at step 108 of Figure 3. an exernplary authentication algorithm begins to read data from the main memory (SDRAM:) 36 and determined if the data being read is executable code or some axiother type of code such as graphics data.
The determination of whether data is graphics data or executable code can be inade prior to reading the data. Reading data and the deterrnining whether the data is graphics data or executable code can take more time than already having loaded static is memory addresses of indicating whether data in such static memory addresses is araphics data or executable code. As such, in embodiments of the present invention, static memory addresses are loaded into one of the volatile or non-volatile memories indicating where all the data is, for example, in the main memory 36 or the high capacity memory 28 and Zn,That type of data it is. In other exemplary embodiments of the present invention wherein data is dynamically loaded into a memory device, various exemplary methods can be utilired to identify the data locations and the data type. For exaznple, a list indicating which memory locations are storing (Yraphics data and which memory locations are storinQ executable code can be created and stored at the time the data is loaded into a meinory device at boot-up during programming of z, the device, or any other time. Such a list allows the C:PIJ to forego reading the data before making a type-of-data determination.
If the data read is executable code (e.Q.., belongs to an executable fiie), then at step 110 a hash calculation is performed on the content of that executable file. The hash messaLe digest is compared ayainst the hash message digest that was stored in a non-volatile RAM at, for example, boot-up for the particular executable file.
If the hash message digests do not inatch, then authentication fails and a critical error is displayed at step 105. If the si.gnatures ,:zlatch and are verified, then the executable file is authenticated. At step 112 it is determined A~hether all the executable files in the main memory have been read. If all the files have not been read then the algorithm aoes back to step 108 to read the next file or predetermined amount of data.
If the next file or predetermined amount of data that is read at step 108 is not executable code, then at step 109 a timer or counter is checked. If this is the first tiine through the algorithm loop; then the algorithm will automatically go from step 109 to step 111 wherein non-executable data or files (e.g., graphics data or files) are authenticated. If this is not the first time through the algorithm loop, then the timer, counter or countdown (hereinafter "tim.er'") is checked to detei-snine whether a predetermined amount of time (counts or number of events) have passed. If the predetermined amount of time had not passed, then the non-executable file is not authenticated at step 111 and the algorithm returns to step 108 to read the next file. If the timer has reached the p.redetermined amount of time (counts), then the graphics file is checked for authenticity via, for example, by comparing a calculated hash message diaest with a previously stored hash message digest as discussed previously.
is If the non-executable file cannot be authenticated by the calculate-and-compare hashes method, then a critical error is displayed at step 105. If the non-executable file is authenticated by calculating a hasli message digest arid then cornparing the calculated message digest with a stored message digest for the file, then the algoritlun checks whether the last file in the main memory has been read at step 112. If the last file has not been read, then the algorithm returns to step 108 and reads the next file or predetermined amount of data. If the last file has been read from the main memory 36 at step 112, then the battery backed memory 38 is checked at step 113.
With respect to step 109, another exemplary embodiment may have a timer for each of the 6raphics data files so that the more critical graphics data files can be set to be checked more often than, for example, a non-critical graphics data file.
Another exemplary reason for giving each graphics data file its own timer would be to stagger the authentication of the aion-executablie files in order to limit loading on the microprocessor 32.
The battery backed meznorv 38 is checked at step 113. In an exemplary embodiment a cyclic redundancy check (CRC) is performed on the nonvolatile RAM, battery backed memory 38. A CRC is a technique for detecting data changes or errors. A checksum or perhaps a hash calculation could also be used to authenticate the battery backed memorv 38.
lf the battery backed memory 38 is not determined to be authentic, then a critical error is displayed at step 105. If the battery backed memory 38 is authenticated, then the exemplary algorithm checks to make sure the inachine is running at step 114. If the machine continues to be operational then the loop returns to step 106 wherein the authentication of data within the selected memory devices is repeated in a serial manner and substantially in parallel With the authentication of the high capacity memory 48.
While the present invention has been described with reference to one or more particular embodiments, those skilied in the art will recognize that many changes may be made thereto without departing from the spirit and scope of the present invention.
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.
Claims (40)
1. A method of authenticating memory devices' data within a gaming machine while said gaming machine is operating, said memory devices' data being authenticated substantially in parallel, said method of authenticating comprising:
reading a next predetermined amount of data from a first memory device storing executable code for operating a wagering game on said gaming machine and graphics data accessed by said executable code to display graphics of said wagering game on a display of said gaming machine;
determining if the next predetermined amount of data is executable code or graphics data;
if said next predetermined amount of data is graphics data, then reading a next predetermined amount of data, without authenticating the graphics data;
if said next predetermined amount of data is executable code, then authenticating said executable code; and wherein the above steps are repeated substantially continuously while said gaming machine is operating.
reading a next predetermined amount of data from a first memory device storing executable code for operating a wagering game on said gaming machine and graphics data accessed by said executable code to display graphics of said wagering game on a display of said gaming machine;
determining if the next predetermined amount of data is executable code or graphics data;
if said next predetermined amount of data is graphics data, then reading a next predetermined amount of data, without authenticating the graphics data;
if said next predetermined amount of data is executable code, then authenticating said executable code; and wherein the above steps are repeated substantially continuously while said gaming machine is operating.
2. The method of claim 1, wherein the method of claim 1 is repeated until said executable code cannot be authenticated.
3. The method of claim 1 or 2, wherein said next predetermined amount of data is a file.
4. The method of any one of claims 1 to 3, wherein said first memory device is a volatile memory device containing a gaming machine program.
5. The method of any one of claims 1 to 4, wherein if said next predetermined amount of data is said graphics data then determining whether a predetermined amount of events have passed, and wherein if said predetermined amount of events have passed then overriding reading the next predetermined amount of data without authenticating the graphics data and authenticating said graphics data.
6. The method of any one of claims 1 to 5, further comprising:
reading a next second-predetermined amount of data from a second memory device; and determining whether said next second-predetermined amount of data is authentic;
repeating said step of reading said next second-predetermined amount of data from the second memory device and said step of determining whether said next second-predetermined amount of data continuously while said gaming machine is operating, wherein said reading said next predetermined amount of data step and said reading said next second-predetermined amount of data step are performed substantially in parallel.
reading a next second-predetermined amount of data from a second memory device; and determining whether said next second-predetermined amount of data is authentic;
repeating said step of reading said next second-predetermined amount of data from the second memory device and said step of determining whether said next second-predetermined amount of data continuously while said gaming machine is operating, wherein said reading said next predetermined amount of data step and said reading said next second-predetermined amount of data step are performed substantially in parallel.
7. The method of any one of claims 1 to 5, further comprising reading a next second-predetermined amount of data from a second memory device;
calculating a hash message digest with said next second-predetermined amount of data;
and determining whether all data from said second memory device has been read;
if all data from said second memory device has not been read, then repeating said reading a next second-predetermined step, calculating step and determining whether steps again;
if all data from said second memory device has been read, then using said calculated hash message digest to authenticate the data in said second memory;
wherein said reading said next predetermined amount of data and said reading said next second-predetermined amount of data is performed substantially in parallel.
calculating a hash message digest with said next second-predetermined amount of data;
and determining whether all data from said second memory device has been read;
if all data from said second memory device has not been read, then repeating said reading a next second-predetermined step, calculating step and determining whether steps again;
if all data from said second memory device has been read, then using said calculated hash message digest to authenticate the data in said second memory;
wherein said reading said next predetermined amount of data and said reading said next second-predetermined amount of data is performed substantially in parallel.
8. The method of any one of claims 1 to 7, wherein authentication of said memory devices' data is performed repetitiously within a predetermined amount of time.
9. The method of claim 8 wherein said predetermined amount of time is an amount of time that is less than 24 hours.
10. A gaming machine comprising:
a user interface; and a central processing unit (CPU) coupled to said user interface, said CPU
comprising:
a processor;
a first memory coupled to said processor, said first memory adapted to contain gaming machine program code, said gaming machine program code comprising executable code and graphics data;
a second memory coupled to said processor, said second memory comprising data;
said gaming machine program code further comprises:
a plurality of instructions configured to cause said processor to determine the authenticity of said gaming machine program code and said data on a substantially continuous, repetitious basis such that the authenticity determination of said gaming machine program code is performed substantially in parallel with the authenticity determination of said data;
said plurality of instructions are further configured to cause said processor to determine, when reading said gaming machine program code, whether said processor is reading executable code or graphics data, if said processor reads graphics data, then said plurality of instructions cause said processor to not determine the authenticity of said graphics data unless more than a predetermined number of events have passed since the last time said graphics data was authenticated;
if said processor reads said executable code, then said plurality of instructions cause said processor to determine the authenticity of said executable code.
a user interface; and a central processing unit (CPU) coupled to said user interface, said CPU
comprising:
a processor;
a first memory coupled to said processor, said first memory adapted to contain gaming machine program code, said gaming machine program code comprising executable code and graphics data;
a second memory coupled to said processor, said second memory comprising data;
said gaming machine program code further comprises:
a plurality of instructions configured to cause said processor to determine the authenticity of said gaming machine program code and said data on a substantially continuous, repetitious basis such that the authenticity determination of said gaming machine program code is performed substantially in parallel with the authenticity determination of said data;
said plurality of instructions are further configured to cause said processor to determine, when reading said gaming machine program code, whether said processor is reading executable code or graphics data, if said processor reads graphics data, then said plurality of instructions cause said processor to not determine the authenticity of said graphics data unless more than a predetermined number of events have passed since the last time said graphics data was authenticated;
if said processor reads said executable code, then said plurality of instructions cause said processor to determine the authenticity of said executable code.
11. The gaming machine of claim 10, wherein said first memory is a volatile memory.
12. The gaming machine of claim 10 or 11, wherein said second memory is a non-volatile memory.
13. A gaming machine comprising a CPU, and a plurality of memory devices;
said CPU adapted to determine the authenticity of data in at least two of said plurality of memory devices in a parallel, repeating fashion;
said CPU further adapted to read said data stored in at least one of said plurality of memory devices and determine whether said data is executable code or graphics data;
if said data stored in said at least one of said plurality of memories is graphics data, then said CPU is adapted to determine the authenticity of said graphics data if a predetermined number of events have passed and read said next data stored in at least one of said plurality of memory devices without authenticating the graphics data if a predetermined number of events have not passed;
if said data stored in said at least one of said plurality of memories is executable code, then said CPU is adapted to determine the authenticity of said executable code.
said CPU adapted to determine the authenticity of data in at least two of said plurality of memory devices in a parallel, repeating fashion;
said CPU further adapted to read said data stored in at least one of said plurality of memory devices and determine whether said data is executable code or graphics data;
if said data stored in said at least one of said plurality of memories is graphics data, then said CPU is adapted to determine the authenticity of said graphics data if a predetermined number of events have passed and read said next data stored in at least one of said plurality of memory devices without authenticating the graphics data if a predetermined number of events have not passed;
if said data stored in said at least one of said plurality of memories is executable code, then said CPU is adapted to determine the authenticity of said executable code.
14. The gaming machine of claim 13, wherein said predetermined number of events are measured in at least one of seconds, up counts, and down counts.
15. The gaming machine of claim 13 or 14, wherein said at least one of said plurality of memory devices that contains graphics data or executable code is a main memory.
16. The gaming machine of claim 15, wherein said graphics data and said executable code are both compiled data.
17. The gaming machine of any one of claims 13 to 16, wherein said CPU is further adapted to determine the authenticity of other ones of said plurality of memory devices in a serial, repetitious fashion.
18. The gaming machine of any one of claims 13 to 16, wherein said CPU is adapted to determine the authenticity of one, of said at least two of said plurality of memory devices, in a serial, repetitions manner with a plurality of other memory devices.
19. The gaming machine of any one of claims 13 to 16, wherein said CPU is adapted to determine the authenticity of at least one of said plurality of memory devices using a hash calculation.
20. The gaming machine of any one of claims 13 to 16, wherein said CPU is adapted to determine the authenticity of at least one of said plurality of memory devices using a CRC.
21. The gaming machine of any one of claims 13 to 16, wherein said CPU is adapted to determine the authenticity of at least one of said plurality of memory devices by comparing a calculated signature with a stored signature.
22. A method of authenticating data within at least one memory of a gaming machine while the gaming machine is executing a wagering game, said at least one memory storing executable code for operating said wagering game and graphics data accessed by said executable code to display graphics of said wagering game on a display of said gaming machine, said method comprising;
(a) determining if a next predetermined amount of data from said memory is executable code or graphics data;
(b) if said next predetermined amount of data is executable code, then authenticating said executable code and returning to step (a); and (c) if said next predetermined amount of data is graphics data and a predetermined condition has been met, then authenticating said graphics data and returning to step (a); and if said next predetermined amount of data is graphics data and said predetermined condition has not been met, then returning to step (a) without authenticating said graphics data.
(a) determining if a next predetermined amount of data from said memory is executable code or graphics data;
(b) if said next predetermined amount of data is executable code, then authenticating said executable code and returning to step (a); and (c) if said next predetermined amount of data is graphics data and a predetermined condition has been met, then authenticating said graphics data and returning to step (a); and if said next predetermined amount of data is graphics data and said predetermined condition has not been met, then returning to step (a) without authenticating said graphics data.
23. The method of claim 22, wherein said predetermined condition occurs at predetermined intervals, after a predetermined number of events, or after a predetermined number of times for authenticating said executable code.
24. The method of claim 22 or 23, wherein said next predetermined amount of data is a file.
25. The method of claim 24, wherein said file has an associated verification code.
26. The method of claim 25, wherein the associated verification code is a digital signature.
27. The method of any one of claims 22 to 26, wherein said at least one memory device is a volatile memory device.
28. The method if any one of claims 22 to 27, further including reading said next predetermined amount of data prior to said determining step.
29. The method of claim 28, wherein the authenticating of said executable code includes performing a hash calculation on said read data, said hash calculation providing a result that is used in authenticating said executable code.
30. A method of authenticating data within at least one memory of a gaming machine, said at least one memory storing executable code for operating a wagering game on said gaming machine and graphics data accessed by said executable code to display graphics of said wagering game on a display of said gaming machine, said method comprising:
(a) while said gaming machine is booting up, authenticating both the executable code and the graphics data; and (b) while said gaming machine is executing said wagering game after booting up:
(i) determining if a next predetermined amount of data from said memory is executable code or graphics data;
(ii) if said next predetermined amount of data is executable code, then authenticating said executable code and returning to step (i); and (iii) if said next predetermined amount of data is graphics data and a predetermined condition has been met, then authenticating said graphics data and returning to step (i); and if said next predetermined amount of data is graphics data and said predetermined condition has not been met, then returning to step (i) without authenticating said graphics data.
(a) while said gaming machine is booting up, authenticating both the executable code and the graphics data; and (b) while said gaming machine is executing said wagering game after booting up:
(i) determining if a next predetermined amount of data from said memory is executable code or graphics data;
(ii) if said next predetermined amount of data is executable code, then authenticating said executable code and returning to step (i); and (iii) if said next predetermined amount of data is graphics data and a predetermined condition has been met, then authenticating said graphics data and returning to step (i); and if said next predetermined amount of data is graphics data and said predetermined condition has not been met, then returning to step (i) without authenticating said graphics data.
31. The method of claim 30, wherein said predetermined condition occurs at predetermined intervals, after a predetermined number of events, or after a predetermined number of times for authenticating said executable code.
32. The method of claim 30 or 31, wherein said at least one memory device is a volatile memory device.
33. The method of claim 30, 31 or 32, further including reading said next predetermined amount of data prior to said determining step.
34. The method of claim 33, wherein the authenticating of said executable code includes performing a hash calculation on said read data, said hash calculation providing a result that is used in the authenticating of said executable code.
35. The method of claim 34, wherein the next predetermined amount of data is a file having an associated verification code.
36. The method of claim 35, wherein the associated verification code is a digital signature.
37. A method if authenticating data within at least one memory of a gaming machine, said at least one memory storing executable code for operating a wagering game on said gaming machine and graphics data accessed by said executable code to display graphics of said wagering game on a display of said gaming machine, said method comprising:
(a) while said gaming machine is booting up, authenticating both the executable code and the graphics data; and (b) while said gaming machine is executing said wagering game after booting up, authenticating said executable code at a first frequency and authenticating said graphics data at a second frequency, said first frequency being greater than said second frequency.
(a) while said gaming machine is booting up, authenticating both the executable code and the graphics data; and (b) while said gaming machine is executing said wagering game after booting up, authenticating said executable code at a first frequency and authenticating said graphics data at a second frequency, said first frequency being greater than said second frequency.
38. The method of claim 37, wherein said second frequency is based on a predetermined condition, said predetermined condition occurring at predetermined intervals, after a predetermined number of events, or after a predetermined number of times for authenticating said executable code.
39. The method of claim 3, wherein the file has an associated verification code.
40. The method of claim 39, wherein the associated verification code is a digital signature.
Applications Claiming Priority (2)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| US10/616,459 | 2003-07-09 | ||
| US10/616,459 US7491122B2 (en) | 2003-07-09 | 2003-07-09 | Gaming machine having targeted run-time software authentication |
Publications (2)
| Publication Number | Publication Date |
|---|---|
| CA2473287A1 CA2473287A1 (en) | 2005-01-09 |
| CA2473287C true CA2473287C (en) | 2009-09-08 |
Family
ID=33452679
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| CA002473287A Expired - Fee Related CA2473287C (en) | 2003-07-09 | 2004-07-08 | Gaming machine having targeted run-time software authentication |
Country Status (5)
| Country | Link |
|---|---|
| US (1) | US7491122B2 (en) |
| EP (2) | EP1832952A3 (en) |
| AU (1) | AU2004203019B2 (en) |
| CA (1) | CA2473287C (en) |
| ZA (1) | ZA200405485B (en) |
Families Citing this family (89)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US6731313B1 (en) * | 2000-06-23 | 2004-05-04 | Igt | Gaming device having touch activated alternating or changing symbol |
| US7695363B2 (en) * | 2000-06-23 | 2010-04-13 | Igt | Gaming device having multiple display interfaces |
| US7699699B2 (en) | 2000-06-23 | 2010-04-20 | Igt | Gaming device having multiple selectable display interfaces based on player's wagers |
| US7162036B2 (en) | 2001-08-06 | 2007-01-09 | Igt | Digital identification of unique game characteristics |
| US6685567B2 (en) | 2001-08-08 | 2004-02-03 | Igt | Process verification |
| US20060036874A1 (en) * | 2001-08-08 | 2006-02-16 | Igt | Data pattern verification in a gaming machine environment |
| US6902481B2 (en) * | 2001-09-28 | 2005-06-07 | Igt | Decoupling of the graphical presentation of a game from the presentation logic |
| US8708828B2 (en) * | 2001-09-28 | 2014-04-29 | Igt | Pluggable modular gaming modifiers and configuration templates for gaming environments |
| US7931533B2 (en) | 2001-09-28 | 2011-04-26 | Igt | Game development architecture that decouples the game logic from the graphics logics |
| WO2003045519A1 (en) * | 2001-11-26 | 2003-06-05 | Igt | Pass-through live validation device and method |
| US8992326B2 (en) * | 2006-09-06 | 2015-03-31 | Bally Gaming, Inc. | Networked gaming system communication protocols and methods |
| US8529349B2 (en) * | 2004-09-16 | 2013-09-10 | Bally Gaming, Inc. | Networked gaming system communication protocols and methods |
| US9117342B2 (en) | 2004-09-16 | 2015-08-25 | Bally Gaming, Inc. | Networked gaming system communication protocols and methods |
| US9082260B2 (en) | 2004-09-16 | 2015-07-14 | Bally Gaming, Inc. | Networked gaming system communication protocols and methods |
| US8568237B2 (en) | 2004-09-16 | 2013-10-29 | Bally Gaming, Inc. | Networked gaming system communication protocols and methods |
| US8535158B2 (en) * | 2004-09-16 | 2013-09-17 | Bally Gaming, Inc. | Networked gaming system communication protocols and methods |
| US8986122B2 (en) | 2002-09-13 | 2015-03-24 | Bally Gaming, Inc. | Networked gaming system communication protocols and methods |
| US7491122B2 (en) | 2003-07-09 | 2009-02-17 | Wms Gaming Inc. | Gaming machine having targeted run-time software authentication |
| US7103779B2 (en) | 2003-09-18 | 2006-09-05 | Apple Computer, Inc. | Method and apparatus for incremental code signing |
| US8251791B2 (en) | 2004-08-19 | 2012-08-28 | Igt | Gaming system having multiple gaming machines which provide bonus awards |
| US8021230B2 (en) * | 2004-08-19 | 2011-09-20 | Igt | Gaming system having multiple gaming machines which provide bonus awards |
| US7963847B2 (en) * | 2004-08-19 | 2011-06-21 | Igt | Gaming system having multiple gaming machines which provide bonus awards |
| US8108691B2 (en) | 2005-02-07 | 2012-01-31 | Sandisk Technologies Inc. | Methods used in a secure memory card with life cycle phases |
| US8423788B2 (en) | 2005-02-07 | 2013-04-16 | Sandisk Technologies Inc. | Secure memory card with life cycle phases |
| US8321686B2 (en) | 2005-02-07 | 2012-11-27 | Sandisk Technologies Inc. | Secure memory card with life cycle phases |
| US8038530B2 (en) | 2005-02-28 | 2011-10-18 | Wms Gaming Inc. | Method and apparatus for filtering wagering game content |
| US20060205513A1 (en) * | 2005-03-09 | 2006-09-14 | Igt | MRAM as nonvolatile safe storage for power hit and ESD tolerance in gaming machines |
| US7722468B2 (en) * | 2005-03-09 | 2010-05-25 | Igt | Magnetoresistive memory units as read only memory devices in gaming machines |
| US7736234B2 (en) * | 2005-03-09 | 2010-06-15 | Igt | MRAM as critical event storage for powered down gaming machines |
| US20070021195A1 (en) * | 2005-06-24 | 2007-01-25 | Campbell Steven M | Gaming system file authentication |
| US7743409B2 (en) | 2005-07-08 | 2010-06-22 | Sandisk Corporation | Methods used in a mass storage device with automated credentials loading |
| US20070021196A1 (en) * | 2005-07-19 | 2007-01-25 | Campbell Steven M | Watermarking downloadable game content in a gaming system |
| US8705739B2 (en) * | 2005-08-29 | 2014-04-22 | Wms Gaming Inc. | On-the-fly encryption on a gaming machine |
| US7841939B2 (en) | 2005-09-09 | 2010-11-30 | Igt | Server based gaming system having multiple progressive awards |
| US8128491B2 (en) | 2005-09-09 | 2012-03-06 | Igt | Server based gaming system having multiple progressive awards |
| US8137188B2 (en) * | 2005-09-09 | 2012-03-20 | Igt | Server based gaming system having multiple progressive awards |
| US7568973B2 (en) * | 2005-09-09 | 2009-08-04 | Igt | Server based gaming system having multiple progressive awards |
| US8966284B2 (en) | 2005-09-14 | 2015-02-24 | Sandisk Technologies Inc. | Hardware driver integrity check of memory card controller firmware |
| WO2007033322A2 (en) * | 2005-09-14 | 2007-03-22 | Sandisk Corporation | Hardware driver integrity check of memory card controller firmware |
| US7934049B2 (en) | 2005-09-14 | 2011-04-26 | Sandisk Corporation | Methods used in a secure yet flexible system architecture for secure devices with flash mass storage memory |
| US8468361B2 (en) * | 2005-09-21 | 2013-06-18 | Broadcom Corporation | System and method for securely provisioning and generating one-time-passwords in a remote device |
| WO2007058890A2 (en) | 2005-11-10 | 2007-05-24 | Wms Gaming Inc. | Authenticating files in wagering game machines |
| US8364965B2 (en) * | 2006-03-15 | 2013-01-29 | Apple Inc. | Optimized integrity verification procedures |
| US8920231B2 (en) | 2006-03-31 | 2014-12-30 | Michael R. Pace | System and method for securely controlling operation and configuration of an electronic game having virtual refills |
| US7526530B2 (en) | 2006-05-05 | 2009-04-28 | Adobe Systems Incorporated | System and method for cacheing web files |
| WO2007145954A2 (en) | 2006-06-07 | 2007-12-21 | Wms Gaming Inc. | Processing metadata in wagering game systems |
| US8512130B2 (en) | 2006-07-27 | 2013-08-20 | Igt | Gaming system with linked gaming machines that are configurable to have a same probability of winning a designated award |
| US8616959B2 (en) | 2006-09-27 | 2013-12-31 | Igt | Server based gaming system having system triggered loyalty award sequences |
| US7674180B2 (en) * | 2006-09-27 | 2010-03-09 | Igt | Server based gaming system having system triggered loyalty award sequences |
| US7862430B2 (en) * | 2006-09-27 | 2011-01-04 | Igt | Server based gaming system having system triggered loyalty award sequences |
| US7896741B2 (en) * | 2006-10-16 | 2011-03-01 | Igt | Progressive controller |
| US8423794B2 (en) | 2006-12-28 | 2013-04-16 | Sandisk Technologies Inc. | Method and apparatus for upgrading a memory card that has security mechanisms for preventing copying of secure content and applications |
| WO2008108916A1 (en) * | 2007-03-01 | 2008-09-12 | Wms Gaming Inc. | Electronic gaming machine security for software stored in nonvolatile media |
| AU2008200752B2 (en) | 2007-03-29 | 2010-10-28 | Aristocrat Technologies Australia Pty Limited | A storage method for a gaming machine |
| AU2008253650B2 (en) * | 2007-05-15 | 2013-01-17 | Wms Gaming Inc. | Validation scheduling in a wagering game machine |
| WO2008147742A2 (en) * | 2007-05-21 | 2008-12-04 | Wms Gaming, Inc. | Trusted initialization for wagering game machines |
| US7985133B2 (en) | 2007-07-30 | 2011-07-26 | Igt | Gaming system and method for providing an additional gaming currency |
| JP5411414B2 (en) * | 2007-07-31 | 2014-02-12 | 株式会社ユニバーサルエンターテインメント | Game machine |
| US8900053B2 (en) | 2007-08-10 | 2014-12-02 | Igt | Gaming system and method for providing different bonus awards based on different types of triggered events |
| US9142097B2 (en) | 2007-10-26 | 2015-09-22 | Igt | Gaming system and method for providing play of local first game and remote second game |
| US20090124354A1 (en) | 2007-11-12 | 2009-05-14 | Acres-Fiore, Inc. | Method for attributing gameplay credit to a player |
| AU2009222006B2 (en) | 2008-03-04 | 2013-01-24 | Apple Inc. | System and method of authorizing execution of software code based on at least one installed profile |
| US20090239648A1 (en) | 2008-03-21 | 2009-09-24 | Acres-Fiore Patents | Method and apparatus for altering gaming device configuration responsive to information related to a player of the gaming device |
| US20090264171A1 (en) | 2008-04-16 | 2009-10-22 | Acres-Fiore, Inc. | Generating a score related to play on gaming devices |
| US9424712B2 (en) | 2008-06-27 | 2016-08-23 | Bally Gaming, Inc. | Authenticating components in wagering game systems |
| US8657662B2 (en) | 2008-09-04 | 2014-02-25 | Patent Investment & Licensing Company | Gaming device having variable speed of play |
| US20100124980A1 (en) | 2008-11-17 | 2010-05-20 | Acres-Fiore Patents | method for configuring casino operations |
| US8702490B2 (en) | 2009-07-24 | 2014-04-22 | Patent Investment & Licensing Company | Gaming device having multiple game play option |
| US9039516B2 (en) | 2009-07-30 | 2015-05-26 | Igt | Concurrent play on multiple gaming machines |
| US9997007B2 (en) | 2009-10-01 | 2018-06-12 | Patent Investment & Licensing Company | Method and system for implementing mystery bonus in place of base game results on gaming machine |
| US8313369B2 (en) | 2009-10-14 | 2012-11-20 | Patent Investments & Licensing Company | Outcome determination method for gaming device |
| US9659442B2 (en) | 2009-11-10 | 2017-05-23 | Patent Investment & Licensing Company | System and method for measuring gaming player behavior |
| US8696436B2 (en) | 2009-11-16 | 2014-04-15 | Patent Investment & Licensing Company | Method for displaying gaming result |
| US8684811B2 (en) | 2009-12-03 | 2014-04-01 | Patent Investment & Licensing Company | Gaming device having advance game information analyzer |
| US9240094B2 (en) | 2009-12-03 | 2016-01-19 | Patent Investment & Licensing Company | Rapid play poker gaming device |
| US8753194B2 (en) * | 2010-11-11 | 2014-06-17 | Igt | Escrow accounts for use in distributing payouts with minimal interruption to game play |
| US9704331B2 (en) | 2010-12-29 | 2017-07-11 | Patent Investment & Licensing Company | Means for controlling payback percentage of gaming device |
| US9721423B2 (en) | 2010-12-29 | 2017-08-01 | Patent Investment & Licensing Company | Event-based gaming operation for gaming device |
| US9728043B2 (en) | 2010-12-29 | 2017-08-08 | Patent Investment & Licensing Company | Means for enhancing game play of gaming device |
| US8627097B2 (en) | 2012-03-27 | 2014-01-07 | Igt | System and method enabling parallel processing of hash functions using authentication checkpoint hashes |
| US8915783B2 (en) * | 2012-04-27 | 2014-12-23 | Tipping Point Group, Llc | Gaming machines with player reservation feature |
| US10490022B2 (en) | 2013-12-31 | 2019-11-26 | Video Gaming Technologies, Inc. | System and method for authenticating storage media within an electronic gaming system |
| US9811972B2 (en) * | 2013-12-31 | 2017-11-07 | Video Gaming Technologies, Inc. | System and method for authenticating storage media within an electronic gaming system |
| US9875618B2 (en) | 2014-07-24 | 2018-01-23 | Igt | Gaming system and method employing multi-directional interaction between multiple concurrently played games |
| JP6392054B2 (en) * | 2014-09-25 | 2018-09-19 | 株式会社ユニバーサルエンターテインメント | Game machine |
| US9972171B2 (en) | 2015-09-24 | 2018-05-15 | Igt | Gaming system and method for providing a triggering event based on a collection of units from different games |
| US10491401B2 (en) * | 2017-02-21 | 2019-11-26 | Google Llc | Verification of code signature with flexible constraints |
| US11450172B2 (en) | 2019-03-19 | 2022-09-20 | Keen Dog, Llc | Amusement system for skill-based games and methods directed to the same |
| US20220343730A1 (en) * | 2021-04-22 | 2022-10-27 | Everi Payments Inc. | System and method for suspending casino jackpot processing |
Family Cites Families (75)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| GB1098578A (en) * | 1965-12-08 | 1968-01-10 | Grieve & Company Ltd T | Improvements in and relating to latch needles |
| GB1512857A (en) * | 1974-09-13 | 1978-06-01 | Bally Mfg Corp | Monitoring system for use with amusement game devices |
| US4405829A (en) * | 1977-12-14 | 1983-09-20 | Massachusetts Institute Of Technology | Cryptographic communications system and method |
| DE3316414A1 (en) | 1982-05-12 | 1983-12-22 | Bally Manufacturing Corp., 60618 Chicago, Ill. | DEVICE AND METHOD FOR ENSURE THE INTEGRITY OF A PLAYING DEVICE |
| AU571119B2 (en) * | 1984-12-13 | 1988-03-31 | Ainsworth Nominees Pty Ltd | A poker machine with improved security after power failure |
| US4727544A (en) * | 1986-06-05 | 1988-02-23 | Bally Manufacturing Corporation | Memory integrity checking system for a gaming device |
| JP2560124B2 (en) * | 1990-03-16 | 1996-12-04 | 株式会社セガ・エンタープライゼス | Video game system and information processing device |
| US5231668A (en) * | 1991-07-26 | 1993-07-27 | The United States Of America, As Represented By The Secretary Of Commerce | Digital signature algorithm |
| US5326104A (en) | 1992-02-07 | 1994-07-05 | Igt | Secure automated electronic casino gaming system |
| US5668878A (en) | 1994-02-28 | 1997-09-16 | Brands; Stefanus Alfonsus | Secure cryptographic methods for electronic transfer of information |
| JP3653709B2 (en) * | 1994-02-28 | 2005-06-02 | 株式会社セガ | Data security device |
| RU95103479A (en) * | 1994-03-11 | 1996-12-27 | Уолкер Эссет Мэнеджмент Лимитед Партнершип (US) | Game system, game computer, method for playing or drawing lottery when player participates in it |
| JPH08141196A (en) | 1994-11-15 | 1996-06-04 | Daikoku Denki Co Ltd | System of verifying content of setting of game machine, and system of controlling operation of game machine, and game machine |
| US5644704A (en) * | 1994-11-30 | 1997-07-01 | International Game Technology | Method and apparatus for verifying the contents of a storage device |
| US5707286A (en) * | 1994-12-19 | 1998-01-13 | Mikohn Gaming Corporation | Universal gaming engine |
| US5737418A (en) * | 1995-05-30 | 1998-04-07 | International Game Technology | Encryption of bill validation data |
| USRE39369E1 (en) * | 1995-06-29 | 2006-10-31 | Igt | Electronic casino gaming system with improved play capacity, authentication and security |
| US6620047B1 (en) * | 1995-06-29 | 2003-09-16 | Igt | Electronic gaming apparatus having authentication data sets |
| US7063615B2 (en) * | 1995-06-29 | 2006-06-20 | Igt | Electronic gaming apparatus with authentication |
| ATE496444T1 (en) * | 1995-06-29 | 2011-02-15 | Igt Reno Nev | ELECTRONIC CASINO GAMING SYSTEM WITH IMPROVED GAMING, AUTHENTICATION AND SECURITY |
| US5643086A (en) * | 1995-06-29 | 1997-07-01 | Silicon Gaming, Inc. | Electronic casino gaming apparatus with improved play capacity, authentication and security |
| US5871398A (en) * | 1995-06-30 | 1999-02-16 | Walker Asset Management Limited Partnership | Off-line remote system for lotteries and games of skill |
| US6402614B1 (en) * | 1995-06-30 | 2002-06-11 | Walker Digital, Llc | Off-line remote system for lotteries and games of skill |
| US5970143A (en) * | 1995-11-22 | 1999-10-19 | Walker Asset Management Lp | Remote-auditing of computer generated outcomes, authenticated billing and access control, and software metering system using cryptographic and other protocols |
| US5768382A (en) * | 1995-11-22 | 1998-06-16 | Walker Asset Management Limited Partnership | Remote-auditing of computer generated outcomes and authenticated biling and access control system using cryptographic and other protocols |
| US5971851A (en) * | 1996-12-27 | 1999-10-26 | Silicon Gaming, Inc. | Method and apparatus for managing faults and exceptions |
| US6964611B2 (en) * | 1996-12-30 | 2005-11-15 | Walker Digital, Llc | System and method for automated play of lottery games |
| US6099408A (en) * | 1996-12-31 | 2000-08-08 | Walker Digital, Llc | Method and apparatus for securing electronic games |
| JPH10192533A (en) | 1997-01-13 | 1998-07-28 | Sophia Co Ltd | Arithmetic processor for game machine |
| US6071190A (en) * | 1997-05-21 | 2000-06-06 | Casino Data Systems | Gaming device security system: apparatus and method |
| US6203427B1 (en) * | 1997-07-03 | 2001-03-20 | Walker Digital, Llc | Method and apparatus for securing a computer-based game of chance |
| AUPP149998A0 (en) * | 1998-01-27 | 1998-02-19 | Aristocrat Leisure Industries Pty Ltd | Multi-platform gaming architecture |
| US6487301B1 (en) * | 1998-04-30 | 2002-11-26 | Mediasec Technologies Llc | Digital authentication with digital and analog documents |
| NZ509018A (en) | 1998-06-17 | 2002-06-28 | Aristocrat Technologies Au | Software verification and authentication |
| NZ509019A (en) | 1998-06-18 | 2002-08-28 | Aristocrat Technologies Au | Method of linking devices to gaming machines |
| US6409602B1 (en) * | 1998-11-06 | 2002-06-25 | New Millenium Gaming Limited | Slim terminal gaming system |
| AUPP734298A0 (en) * | 1998-11-26 | 1998-12-24 | Aristocrat Leisure Industries Pty Ltd | Electronic casino gaming with authentication and improved security |
| US6488581B1 (en) * | 1999-06-22 | 2002-12-03 | Igt | Mass storage data protection device for a gaming machine |
| US6565443B1 (en) * | 1999-09-14 | 2003-05-20 | Innovative Gaming Corporation | System and method for verifying the contents of a mass storage device before granting access to computer readable data stored on the device |
| AUPQ321699A0 (en) | 1999-09-30 | 1999-10-28 | Aristocrat Leisure Industries Pty Ltd | Gaming security system |
| US6595856B1 (en) * | 2000-01-04 | 2003-07-22 | Sigma Game, Inc. | Electronic security technique for gaming software |
| US7043641B1 (en) | 2000-03-08 | 2006-05-09 | Igt | Encryption in a secure computerized gaming system |
| US6629184B1 (en) * | 2000-05-18 | 2003-09-30 | Igt | Method and apparatus for inhibiting a selected IDE command |
| AU2001285125B2 (en) | 2000-08-21 | 2004-08-26 | Igt | Method and apparatus for software authentication |
| US6675152B1 (en) * | 2000-09-13 | 2004-01-06 | Igt | Transaction signature |
| CA2320665C (en) * | 2000-09-26 | 2010-08-17 | Spielo Manufacturing Incorporated | System and method for downloading electronic information to a video lottery terminal |
| US6645077B2 (en) * | 2000-10-19 | 2003-11-11 | Igt | Gaming terminal data repository and information distribution system |
| US6918831B2 (en) * | 2002-09-13 | 2005-07-19 | Igt | Method and apparatus for independently verifying game outcome |
| US7137893B2 (en) * | 2001-05-09 | 2006-11-21 | Wms Gaming Inc. | Method and apparatus for write protecting a gaming storage medium |
| US20020187828A1 (en) | 2001-06-12 | 2002-12-12 | Jamal Benbrahim | Method and apparatus for securing gaming machine operating data |
| DE10210173B4 (en) * | 2001-07-05 | 2012-12-06 | Adp Gauselmann Gmbh | A method of encrypting data sent from a peripheral module to a coin operated machine control unit |
| US7162036B2 (en) * | 2001-08-06 | 2007-01-09 | Igt | Digital identification of unique game characteristics |
| US6685567B2 (en) * | 2001-08-08 | 2004-02-03 | Igt | Process verification |
| US20030064811A1 (en) * | 2001-09-28 | 2003-04-03 | Greg Schlottmann | Gaming device with write only mass storage |
| WO2003045519A1 (en) | 2001-11-26 | 2003-06-05 | Igt | Pass-through live validation device and method |
| US6880149B2 (en) * | 2002-04-01 | 2005-04-12 | Pace Anti-Piracy | Method for runtime code integrity validation using code block checksums |
| US8226473B2 (en) * | 2002-04-10 | 2012-07-24 | Wms Gaming Inc. | Gaming software authentication |
| US6962530B2 (en) * | 2002-04-25 | 2005-11-08 | Igt | Authentication in a secure computerized gaming system |
| US6926605B2 (en) * | 2002-09-13 | 2005-08-09 | Igt | Method and apparatus for independently verifying game outcome |
| US20040243848A1 (en) * | 2003-03-06 | 2004-12-02 | Blackburn Christopher W. | Authentication service in a service-oriented gaming network environment |
| US20040259633A1 (en) * | 2003-04-16 | 2004-12-23 | Gentles Thomas A. | Remote authentication of gaming software in a gaming system environment |
| US7125017B2 (en) * | 2003-05-20 | 2006-10-24 | Oberthur Gaming Technologies Inc. | Dual play area lottery game with enhanced authentication system |
| US7367889B2 (en) * | 2003-06-09 | 2008-05-06 | Wms Gaming Inc. | Gaming machine having hardware-accelerated software authentication |
| US7600108B2 (en) * | 2003-06-17 | 2009-10-06 | Wms Gaming Inc. | Gaming machine having reduced-read software authentication |
| US7491122B2 (en) | 2003-07-09 | 2009-02-17 | Wms Gaming Inc. | Gaming machine having targeted run-time software authentication |
| US7794323B2 (en) * | 2003-07-25 | 2010-09-14 | Igt | Gaming apparatus with encryption and method |
| WO2005029272A2 (en) | 2003-09-15 | 2005-03-31 | Acres Gaming Incorporated | Method and device for data protection and security in a gaming machine |
| US20050143171A1 (en) * | 2003-12-30 | 2005-06-30 | Loose Timothy C. | Gaming machine having sampled software verification |
| JP2006227930A (en) * | 2005-02-17 | 2006-08-31 | Aruze Corp | Game machine operation authentication system and game machine |
| JP4885473B2 (en) * | 2005-04-19 | 2012-02-29 | 株式会社ユニバーサルエンターテインメント | GAME MACHINE, GAME INFORMATION AUTHENTICATION CAPTURE DEVICE, AND GAME INFORMATION CAPTURE DEVICE |
| JP2006296671A (en) * | 2005-04-19 | 2006-11-02 | Aruze Corp | Game machine, authentication and fetch device for game information and fetch device for game information |
| US8095990B2 (en) * | 2005-04-25 | 2012-01-10 | Universal Entertainment Corporation | Gaming machine, gaming information authentication loading device and gaming information loading device |
| US20070021195A1 (en) * | 2005-06-24 | 2007-01-25 | Campbell Steven M | Gaming system file authentication |
| JP2007011420A (en) * | 2005-06-28 | 2007-01-18 | Konami Co Ltd | Authentication device and game device provided therewith |
| US8152628B2 (en) * | 2005-08-01 | 2012-04-10 | Igt | Methods and devices for authentication and licensing in a gaming network |
-
2003
- 2003-07-09 US US10/616,459 patent/US7491122B2/en not_active Expired - Fee Related
-
2004
- 2004-07-02 EP EP07009040A patent/EP1832952A3/en not_active Withdrawn
- 2004-07-02 EP EP04015615A patent/EP1496419B1/en not_active Expired - Fee Related
- 2004-07-05 AU AU2004203019A patent/AU2004203019B2/en not_active Ceased
- 2004-07-08 CA CA002473287A patent/CA2473287C/en not_active Expired - Fee Related
- 2004-07-09 ZA ZA200405485A patent/ZA200405485B/en unknown
Also Published As
| Publication number | Publication date |
|---|---|
| ZA200405485B (en) | 2006-02-22 |
| EP1832952A3 (en) | 2007-09-19 |
| EP1496419A1 (en) | 2005-01-12 |
| EP1832952A2 (en) | 2007-09-12 |
| US7491122B2 (en) | 2009-02-17 |
| CA2473287A1 (en) | 2005-01-09 |
| EP1496419B1 (en) | 2013-03-20 |
| US20050009599A1 (en) | 2005-01-13 |
| AU2004203019A1 (en) | 2005-01-27 |
| AU2004203019B2 (en) | 2010-03-18 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| CA2473287C (en) | Gaming machine having targeted run-time software authentication | |
| AU2004237915B2 (en) | Gaming machine having sampled software verification | |
| CA2471167C (en) | Gaming machine having reduced-read software authentication | |
| CA2470326C (en) | Gaming machine having hardware-accelerated software authentication | |
| AU2003203759B2 (en) | Gaming software authentication | |
| US20060036874A1 (en) | Data pattern verification in a gaming machine environment | |
| US11651078B2 (en) | Secure bootloader for electronic gaming machines and other computing devices | |
| CA3092564C (en) | Gaming system having boot locked validation of program installs, data installs and program launches | |
| US11113401B2 (en) | Secure bootloader for electronic gaming machines and other computing devices |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| EEER | Examination request | ||
| MKLA | Lapsed |
Effective date: 20170710 |