U.S. patent application number 12/619639 was filed with the patent office on 2010-03-11 for authentication and validation systems for gaming devices.
This patent application is currently assigned to BALLY GAMING, INC.. Invention is credited to Thomas E. Buckeyne, Ronald A. Cadima, Robert W. Crowder, JR., Anthony E. Green, Pravinkumar Patel, Anand Singh.
Application Number | 20100062844 12/619639 |
Document ID | / |
Family ID | 43991971 |
Filed Date | 2010-03-11 |
United States Patent
Application |
20100062844 |
Kind Code |
A1 |
Crowder, JR.; Robert W. ; et
al. |
March 11, 2010 |
AUTHENTICATION AND VALIDATION SYSTEMS FOR GAMING DEVICES
Abstract
Systems and methods for authenticating and validating a device
are disclosed herein. In one method, a manifest file is created for
a gaming component, wherein the manifest file includes contents of
each file from the gaming component. A digital signature is
generated for each file from the gaming component, wherein the
digital signature is created by using the contents of each file.
Each digital signature is saved with each file in the manifest
file. A digital signature calculation is performed on a file
accessed during a bootup process. The contents of the accessed file
are validated by comparing the calculated digital signature to the
saved digital signature, and an error message is presented on a
video display when the contents of the accessed file is not
validated.
Inventors: |
Crowder, JR.; Robert W.;
(Las Vegas, NV) ; Singh; Anand; (Henderson,
NV) ; Green; Anthony E.; (Henderson, NV) ;
Buckeyne; Thomas E.; (Las Vegas, NV) ; Patel;
Pravinkumar; (Las Vegas, NV) ; Cadima; Ronald A.;
(Las Vegas, NV) |
Correspondence
Address: |
STEPTOE & JOHNSON, LLP
2121 AVENUE OF THE STARS, SUITE 2800
LOS ANGELES
CA
90067
US
|
Assignee: |
BALLY GAMING, INC.
Las Vegas
NV
|
Family ID: |
43991971 |
Appl. No.: |
12/619639 |
Filed: |
November 16, 2009 |
Related U.S. Patent Documents
|
|
|
|
|
|
Application
Number |
Filing Date |
Patent Number |
|
|
11423370 |
Jun 9, 2006 |
|
|
|
12619639 |
|
|
|
|
10794760 |
Mar 5, 2004 |
|
|
|
11423370 |
|
|
|
|
60452407 |
Mar 5, 2003 |
|
|
|
Current U.S.
Class: |
463/29 |
Current CPC
Class: |
G07F 17/32 20130101;
G06F 21/64 20130101; G06F 2221/2109 20130101; G06F 21/57 20130101;
G06F 21/575 20130101; G07F 17/3241 20130101 |
Class at
Publication: |
463/29 |
International
Class: |
A63F 9/24 20060101
A63F009/24 |
Claims
1. A method for verifying a gaming component, the method
comprising: creating a manifest file for a gaming component,
wherein the manifest file includes contents of each file from the
gaming component; generating a digital signature for each file from
the gaming component, wherein the digital signature is created by
using the contents of each file; saving each digital signature with
each file in the manifest file; performing a digital signature
calculation on a file accessed during a bootup process; validating
the contents of the accessed file by comparing the calculated
digital signature to the saved digital signature; and presenting an
error message on a video display when the contents of the accessed
file is not validated.
2. The method of claim 1, further comprising: generating a digital
signature of the completed manifest file; and saving the digital
signature of the completed manifest file in a header of the
manifest file.
3. The method of claim 2, further comprising: performing a digital
signature calculation on the completed manifest file; validation
the manifest file by comparing the calculated digital signature for
the completed manifest file to the saved digital signature.
4. The method of claim 1, wherein the digital signature is a
Pintsov-Vanstone Signature Scheme with Partial Message Recovery
(PVSSR) signature.
5. A method of verifying a gaming component, the method comprising:
determining if the manifest is authentic, the manifest including
component information and a stored digital signature for the gaming
component; performing a digital signature calculation using the
contents of the component to produce a calculated digital signature
if the manifest is authentic; verifying the gaming component by
comparing the calculated digital signature to the stored digital
signature; and loading the gaming component if the calculated
digital signature and the stored digital signature are equal.
6. The method of claim 5, wherein authenticating the manifest
includes performing a digital signature algorithm on the
manifest.
7. The method of claim 5, wherein the component is verified when
the component is retrieved for operation of a device.
8. The method of claim 5, wherein the component is verified on a
continuing basis during operation of a device.
9. The method of claim 5, wherein the digital signature is a
Pintsov-Vanstone Signature Scheme with Partial Message Recovery
(PVSSR) signature.
10. A method for verifying a gaming component, the method
comprising: identifying a validation protocol used to create a
digital signature for a gaming component; determining if the
manifest is authentic, the manifest including component information
and a stored digital signature for the gaming component; performing
a digital signature calculation using the contents of the component
to produce a calculated digital signature; verifying the gaming
component by comparing the calculated digital signature to the
stored digital signature; and presenting an error message on a
video display when the contents of the accessed file is not
validated.
11. The method of claim 10, wherein authenticating the manifest
includes performing a digital signature algorithm on the
manifest.
12. The method of claim 10, wherein the component is verified when
the component is retrieved for operation of a device.
13. The method of claim 10, wherein the component is verified on a
continuing basis during operation of a device.
14. The method of claim 10, wherein the digital signature is a
Pintsov-Vanstone Signature Scheme with Partial Message Recovery
(PVSSR) signature or a SHA-1 Hash.
Description
CROSS-REFERENCE TO RELATED APPLICATIONS
[0001] This application is a continuation-in-part of U.S.
application Ser. No. 11/423,370, entitled AUTHENTICATION AND
VALIDATION SYSTEMS FOR GAMING MACHINES, filed Jun. 9, 2006, which
is a continuation-in-part of U.S. application Ser. No. 10/794,760,
entitled GAMING SYSTEM ARCHITECTURE WITH MULTIPLE PROCESSES AND
MEDIA STORAGE, filed Mar. 5, 2004, which claims the benefit of U.S.
Provisional Application Ser. No. 60/452,407, entitled GAMING BOARD
SET AND GAMING KERNEL FOR GAME CABINETS, filed Mar. 5, 2003, all of
which are hereby incorporated by reference in their entirety.
COPYRIGHT NOTICE
[0002] A portion of the disclosure of this patent document contains
material that is subject to copyright protection. The copyright
owner has no objection to the facsimile reproduction by anyone of
the patent document or the patent disclosure, as it appears in the
Patent and Trademark Office patent files or records, but otherwise
reserves all copyright rights whatsoever.
FIELD
[0003] Systems and methods for authenticating and validating
components of a computerized device, such as a gaming machine or
other electronic device, are disclosed herein.
BACKGROUND
[0004] In previous systems, authentication of content on read/write
media or non-secured media storage involves calculating a hash
value over the data contents and then using the hash value in
conjunction with a digital signature and public key to verify that
the data contents are authentic.
[0005] Typically there is a secure memory, or read only sealed
memory, such as an EPROM which contains the authentication
algorithm. Additionally there is non-secure media that contains the
content to be authenticated. The secure memory can be removed and
independently verified with external devices; however data in
non-secure device cannot be easily removed and verification is more
difficult. Therefore, it is desirable to have a program that is
running from the secure memory authenticate the contents of the
non-secure device.
[0006] The authentication methods usually involve calculating a
hash value over the entire contents of non-secure media, or major
portions thereof, at boot time. The problem with this method is
that it takes a considerable amount of processing time to calculate
a hash value over the entire contents of the non-secure media,
especially if it is a hard drive, CD-ROM, or DVD-ROM that contains
a large amount of data. This results in considerably longer boot
times for gaming machines and other devices that require
verification. For example, some boot times are as long as ten
minutes or more. As gaming machines and other devices become more
sophisticated, the storage requirements for the non-secure media is
growing, resulting in even longer durations for boot time
authentication.
[0007] Moreover, in many gaming jurisdictions, there are regulatory
requirements that mandate that authentication of a system be
performed by a program running from the secure media. For gaming
machines based on personal computer (PC) architecture, this
typically means that the BIOS must reside on the EPROM and the
authentication code executed from the BIOS EPROM. This puts a
further limitation on gaming machines because authentication code
executing from the BIOS EPROM may not run as quickly as code
executing from the faster PC-based RAM.
[0008] An alternative to the above method is to have the BIOS
authenticate the operating system only, load the operating system,
and then have the operating system authenticate the remainder of
the non-secure media. However, this method still increases the boot
time because the entire content of the non-secure media is
authenticated by the operating system at boot time.
[0009] Additionally, regulatory gaming jurisdictions require that
the contents of the non-secure media, and contents of programs
executing from volatile memory, be checked on a periodic basis, or
whenever significant events occur. For example, when a main door
closes, the gaming machine must make sure that all code executing
from RAM is authentic and that such code has not been modified.
Some gaming machines have handled this requirement by
re-authenticating the programs on the non-secure media and
reloading them into RAM for execution. These requirements further
contribute to significant delays that occur due to complying with
authentication regulations.
[0010] Furthermore, it is possible to download data from a central
host on the network to the non-secure media. It is desirable to
have the ability to download individual files or groups of files to
change the capabilities of the gaming machine. This may involve
downloading a new game for use by the player or downloading some
enhancement to the operating system files. Nevertheless, if there
is just one digital signature for the entire contents of the
non-secure media device, then updating small portions of the
contents through downloading becomes more difficult because the
host must also download the new digital signature. This means the
host needs to re-sign the contents prior to download. Such a
process has its drawbacks because the host may not be secure if it
is in a casino location and not controlled by the gaming
manufacturer that produced the code.
[0011] Accordingly, there is a need for systems and methods to
authenticate and validate files on gaming devices.
SUMMARY
[0012] According to one embodiment, a means of quickly
authenticating the contents of one or more manifests located on a
writeable media device is disclosed. Once the contents of one or
more manifests are authenticated, the boot process of the operating
system is begun. The operating system then calculates a hash value
over each component on the writeable media, as it is needed, and
then compares it to a corresponding hash value located within the
manifest to insure that the component has not changed. One benefit
of this embodiment is that the digital signatures that are used for
authentication are only calculated for the data located within the
manifests, which are relatively small in size when compared to the
entire data set of the writable media. Another benefit is that, for
verification, a hash is performed on the components and compared to
an associated manifest value, whereby the calculation of the hash
is computationally less intensive than performing a digital
signature check, as is preformed on the manifest.
[0013] According to another embodiment, the components are verified
on an as-needed basis, allowing for quicker boot times because only
the components that are loaded are verified. This results in
quicker system loading times, and through definition of the
manifest components, better control over what components are
verified and when they such components are verified.
[0014] Several methods of organizing the components are available.
In one embodiment, a component is verified as or within partitions
on the hard disk device. For example, in one embodiment, the hard
disk device contains multiple partitions containing, for example,
the Linux operating system, gaming libraries and executables, and
multiple games with each game being placed within a separate
partition. During boot up, the manifest for the partitions is
authenticated using DSA signature validation, and then each
partition is verified when it is mounted or loaded by the operating
system. Such verification is performed by calculating the hash
value over the partition as it is mounted, and comparing it to the
hash located within the manifest file. This allows the operating
system to boot quickly because just the operating system is
verified prior to loading the operating system. Then the libraries
are verified and loaded. Only the games that are active need to
have their respective partitions verified and loaded, although,
optionally, several game files can be loaded at once for
anticipated play. For example, and not by way of limitation, if a
hard drive has 100 game partitions, but only 10 games are active,
then only the 10 game partitions of the active games need to be
verified at boot time.
[0015] In another embodiment, components are broken down into
files, where the manifest contains an entry for each file in the
partition. During boot time, the BIOS verified the Linux kernel
boot image, and loads it. The Linux kernel verifies each file as it
is opened. The added benefit is that an entire partition does not
need to be verified when it is mounted. Instead, the files in the
partition are verified as they are opened. If the operating system
only needs to load 20% of the files during boot time, then the
remaining 80% of the files can be verified on an "as-needed" basis
when they are loaded at a later time. This dramatically decreases
the boot time for the gaming machine. Likewise, games are able to
load just a portion of their graphic files during boot time. The
remaining graphic files used for animated bonus screens, movies,
and sounds can be loaded later as those resources are required
throughout the game play cycle. In this regard, if a game contains
512 MB of graphics (by way of example only), 80% of which are
sounds and movies, then the load time for the game is dramatically
improved by delaying the loading of large files to support those
sounds and movies.
[0016] Still, further methods of separation of the components to be
verified are possible. For example, and not by way of limitation,
games that play a 100 MB movie typically open the file and stream
the content of the file to the display as the movie is being
played. Therefore, it is not desirable to verify the entire file
when it is opened, as there would be a significant delay when the
movie file is opened for streaming. Therefore, another embodiment
allows files to be broken down into blocks of data where each block
is verified as it is read from the media. For example, the manifest
file may contain a file entry for a 100 MB file, where the file is
broken down (by way of example, and not by way of limitation) into
4K block sizes where each block includes a corresponding hash value
within the manifest file entry. As each block of the file is read,
only that particular block needs to be verified before loading.
This allows games to stream large sound and graphic files directly
from the hard drive while simultaneously verifying the contents.
The benefit is file verification without delays perceived by the
player.
[0017] In another embodiment, the breakdown of components is by
sectors on the hard disk device. In this embodiment, each sector on
the hard drive has a corresponding entry within the manifest. Since
sectors are organized around the geometry of the hard drive, and
not the file system, this embodiment results in a more efficient
and simpler method of verifying information as it is loaded. For
example, the Linux operating system has a block driver for a hard
drive. When a block driver is instructed to load blocks of data for
use by the file system, the block driver can read the sectors of
the disk for the blocks of data and verify each sector as it is
loaded. The benefit to this process is that sectors comprise
continuous data on the hard drive organized around cylinders.
Sectors are loaded very efficiently by the hard drive and thus can
be efficiently verified using this mechanism. If an entire image is
downloaded from a host server for a partition, each partition
contains the files in a predefined organization. In one embodiment,
a manifest for sectors is pre-calculated for the partition and
downloaded along with the partition image.
[0018] In another embodiment, when files are downloaded and
installed by the gaming machine, the manifest is calculated
dynamically by the gaming machine and stored in a writable area.
Once the manifest is created based on any of the component
breakdown methods described above, they are digitally signed by the
gaming machine itself, or by a remote server. This allows for
greater flexibility in how the component breakdowns are selected to
achieve the greatest verification efficiency. For example, in one
embodiment, downloaded files found in a partition allow the gaming
machine to dynamically create a manifest based on hard drive sector
verification that is digitally signed by the gaming machine, or by
a remote host during manifest file creation. This embodiment
provides individual file download capabilities, while maintaining
the sector-based verification aspect, which may be the most
efficient for the hard disk device in some embodiments.
[0019] In one embodiment, a hard disk device contains a manifest
partition, where the manifest files can be quickly located and
authenticated. Alternatively, in another embodiment, the manifest
files are contained in a predefined section of the hard drive
reserved for quick loading and verification. In another embodiment,
the entries of the manifest are spread out over the entire file
system. For example, in one embodiment, the hash value for a file
is appended to each file, or in each file's directory entry. The
digital signature is calculated over all, or logical groups, of the
manifest entries spread out over the file system.
[0020] In one embodiment, manifests are broken down to include
entries for logical groupings of files. It is preferable in some
gaming jurisdictions to have regulatory agencies approve groups of
files as a package. For example, but not by way of limitation, in
one embodiment, game files are broken down into several groups of
files relating to: 1) paytable and win evaluation, 2) game
executable code, 3) basic game graphics and sounds, and 4) paytable
graphics and sounds. Each group of files is configured to be
updated or replaced with a corresponding group of files. For
example, to change the paytable, groups 1) and 4) are downloaded.
Likewise, groups 2) and 3) are updated to change the look and feel
of the game. Subsequently, as a particular group is downloaded, a
corresponding manifest for the file group is also downloaded. This
is referred to as a package. In one embodiment, a package can
contain one or more manifests.
[0021] According to another embodiment, a method verifies a gaming
component. The method includes determining if a manifest is
authentic, the manifest including component information and a
stored hash for the gaming component; performing a hash calculation
on the component to produce a calculated hash if the manifest is
authenticated; verifying the gaming component by comparing the
calculated hash to the stored hash; and loading the gaming
component if the calculated hash and the stored hash are equal.
[0022] In one embodiment, the component comprises a data file. In
another embodiment, the component comprises a data component stored
in a partition of a digital storage medium. In this embodiment, the
stored hash is a hash of the entire partition, and performing the
hash calculation includes performing the hash calculation on the
entire partition if the partition has not yet been verified during
operation of the device.
[0023] In yet another embodiment, the component comprises a data
component stored in a library located on a digital storage medium.
In this embodiment, the stored hash is a hash of the entire
library. The performing of the hash calculation comprises
performing the hash calculation on the entire library if the
library has not yet been verified during operation of the
device.
[0024] Yet another embodiment includes a method of verifying one or
more components in a device. The method includes determining if a
manifest is authentic, the manifest including component information
and a stored hash for each component; performing a hash calculation
on each component as each component is needed for operation of the
device to produce a calculated hash for each component if the
manifest is authenticated; comparing the calculated hash to the
stored hash for each component; for each component needed for
operation of the device, loading the component if the calculated
hash and the stored hash are equal.
[0025] In another embodiment, a method verifies a component,
wherein the component has a plurality of sub-components. The method
includes determining if a manifest is authentic, the manifest
including sub-component information and a stored hash for each
sub-component; performing a hash calculation on at least one
sub-component to produce a calculated hash if the manifest is
authenticated; verifying the at least one sub-component by
comparing the calculated hash to the stored hash for the
sub-component; and loading the sub-component if the calculated hash
and the stored hash for the sub-component are equal.
[0026] In yet another embodiment, a system is used to verify a
component. The system includes a processor, and a set of
instructions that are executable on the processor for
authenticating a manifest, wherein the manifest includes component
information and a stored hash for the component. Included is a set
of instructions that are executable on the processor for
determining if the manifest is authenticated. Further included is a
set of instructions executable on the processor for performing a
hash calculation on the component to produce a calculated hash if
the manifest is authenticated. A further set of instructions is
executable on the processor for verifying the component by
comparing the calculated hash to the stored hash. A further set of
instructions that is executable on the processor is included for
loading the component if the calculated hash and the stored hash
are equal.
[0027] In another embodiment, a system for verifying a component
includes a computer usable medium having computer readable program
code embodied therein configured for verifying a component.
Computer readable code configured to determine if a manifest is
authentic is included. The manifest includes component information
and a stored hash for the component. Further computer readable code
is configured to perform a hash calculation on the component to
produce a calculated hash if the manifest is authenticated. Further
computer readable code is configured to verify the component by
comparing the calculated hash to the stored hash. Further computer
readable code is configured to load the component if the calculated
hash and the stored hash are equal.
[0028] In another embodiment, a method verifies one or more files
stored on a network associated storage device connected to a
network. The method includes determining if a manifest is
authentic, the manifest including component information and a
stored hash for a file; reading the file from the network
associated storage device over a network connection if the manifest
is authentic; performing a hash calculation on the file to produce
a calculated hash; verifying the file by comparing the calculated
hash to the stored hash; and loading the file if the calculated
hash and the stored hash are equal. In one aspect of this
embodiment, the gaming machine uses a plurality of files stored on
the network associated storage device, reading the file, performing
the hash calculation, verifying the file, and loading the file are
performed for each file, as needed. In another aspect of this
embodiment, verifying the file includes performing a SHA-1
verification. In another aspect of this embodiment, the network
associated storage device comprises a network attached storage
device.
[0029] In another embodiment, a method verifies one or more files
stored on a diskless storage device. The method includes
determining if a manifest is authentic, the manifest including
component information and a stored hash for a file; reading the
file from the diskless storage device if the manifest is authentic;
performing a hash calculation on the file to produce a calculated
hash; verifying the file by comparing the calculated hash to the
stored hash; and loading the file if the calculated hash and the
stored hash are equal. In one embodiment, the diskless storage
device comprises a solid-state storage device. In another
embodiment, the solid-state storage device comprises an erasable
programmable read-only memory. In another embodiment, the
solid-state storage device comprises a safe random access
memory.
[0030] In yet another embodiment, a method verifies one or more
files stored on a gaming component. The method includes creating a
manifest file for a gaming component, wherein the manifest file
includes contents of each file from the gaming component;
generating a digital signature for each file from the gaming
component, wherein the digital signature is created by using the
contents of each file; saving each digital signature with each file
in the manifest file; performing a digital signature calculation on
a file accessed during a bootup process; validating the contents of
the accessed file by comparing the calculated digital signature to
the saved digital signature; and presenting an error message on a
video display when the contents of the accessed file is not
validated.
[0031] In yet another embodiment, a method verifies a gaming
component. The method includes determining if the manifest is
authentic, the manifest including component information and a
stored digital signature for the gaming component; performing a
digital signature calculation using the contents of the component
to produce a calculated digital signature if the manifest is
authentic; verifying the gaming component by comparing the
calculated digital signature to the stored digital signature; and
loading the gaming component if the calculated digital signature
and the stored digital signature are equal.
[0032] In another embodiment, a method verifies a gaming component.
The method includes identifying a validation protocol used to
create a digital signature for a gaming component; determining if
the manifest is authentic, the manifest including component
information and a stored digital signature for the gaming
component; performing a digital signature calculation using the
contents of the component to produce a calculated digital
signature; verifying the gaming component by comparing the
calculated digital signature to the stored digital signature; and
presenting an error message on a video display when the contents of
the accessed file is not validated.
[0033] Other features and advantages of the claimed invention will
become apparent from the following detailed description when taken
in conjunction with the accompanying drawings, which illustrate, by
way of example, the features of the claimed invention.
BRIEF DESCRIPTION OF THE DRAWINGS
[0034] FIG. 1 is a block diagram that illustrates a device that
comprises a gaming machine having components capable of
verification according to one embodiment.
[0035] FIG. 2 is a block diagram that illustrates components of the
gaming machine of FIG. 1.
[0036] FIG. 3 is a block diagram that illustrates directory and
file organization of a partition for manifests on the hard disk
device of FIG. 2.
[0037] FIG. 4 is a block diagram illustrating a structural
organization of a manifest file according to one embodiment.
[0038] FIG. 5 shows a flow chart illustrating the steps for booting
a BIOS and Linux operating system according to one embodiment.
[0039] FIG. 6 shows a flow diagram that illustrates the steps
performed in a file verification method when a file is opened,
according to one embodiment.
[0040] FIG. 7 is a block diagram of one embodiment of a processing
environment in a gaming machine.
[0041] FIG. 8 is a flow diagram illustrating a method for creating
a PVSSR manifest.
[0042] FIG. 9 is a block diagram of one embodiment of a BIOS
EEPROM.
[0043] FIG. 10 illustrates block diagrams of hard disks and compact
flashes used in the gaming device.
[0044] FIG. 11 illustrates one embodiment of a manifest
partition.
[0045] FIG. 12 is a flow diagram illustrating a startup process for
a gaming device.
[0046] FIG. 13 illustrates one embodiment of an In-Memory File
Validation Table.
[0047] FIG. 14 is a flow diagram of a method for creating an
In-Memory File Validation Table.
[0048] FIG. 15 illustrates another embodiment of an In-Memory File
Validation Table.
[0049] FIG. 16 is a flow diagram of one method for validating a
file on a gaming device.
[0050] FIG. 17 is a flow diagram of a start-up process for a gaming
device.
[0051] FIG. 18 is a flow diagram of one method for running a
background validation process.
DETAILED DESCRIPTION
[0052] In one embodiment, a system and method that uses digital
signature technology to authenticate the contents of one or more
manifests on a digital storage device is provided. Each manifest
includes a list of file records, wherein each record contains the
name of a file stored on the hard disk device, and a hash value
derived from the contents of the file of a device. At boot time,
the gaming machine first authenticates the contents of the manifest
and then verifies the contents of the files using the hash value
stored in the manifest. By way of example, but not by way of
limitation, files are verified using a SHA-1 as they are needed
during the boot up of the operating system and throughout normal
operation. This method reduces the boot time of, for example, of a
gaming machine and eliminates the need to check digital signatures
for each individual file or over the entire contents of a
non-secure media.
[0053] Referring now to the drawings, wherein like references
numerals denote like or corresponding parts throughout the drawings
and, more particularly, to FIGS. 1-6, there is shown one embodiment
of an improved authentication system in accordance with the
invention. With reference to FIG. 1, a block diagram illustrates a
device 10 that comprises a gaming machine 10. A cabinet 130 houses
the gaming machine 10 that has one or more CRT-type displays 134
for displaying game play. Electronic components 50 that operate the
games on the gaming machine 10 are located within the cabinet
130.
[0054] With reference to FIG. 2, a block diagram illustrates
components 50 of the gaming machine 10 capable of verification
before and during use of the gaming machine 10. The components 50
comprise, for example, and not by way of limitation, software or
data file components, firmware components, hardware components, or
structural components of the gaming machine 10. These components
include, without limitation, one or more processors 60, a hard disk
device 100, volatile storage media such as random access memories
(RAMs) 76, read-only memories (ROMs) 77 or electrically erasable
programmable ROMs (EEPROMS) such as basic input/output systems
(BIOS) 64.
[0055] In one embodiment, components 50 also include data files
(which are any collections of data, including executable programs
in binary or script form, and the information those programs
operate upon), gaming machine cabinets (housings) 130, cathode ray
tubes (CRTs) 134, or compact disk read only memory (CDROM) or CD
read-write (CR-RW) storage. In one embodiment, the data files may
include data storage files, software program files, operating
system files, and file allocation tables or structures. Ports 139
are be included with the gaming machine 10 for connection to
diagnostic systems 140 and other input/output devices 142. In one
embodiment, the ports 139 each comprise a serial port, universal
serial bus (USB) port, parallel port or any other type of known
port, including a wireless port. Preferably, each of the components
50 have embedded or loaded in them identification numbers or
strings that can be accessed by the processor 60, including the
processor 60 itself, which are utilized for verification as
explained below. In embodiment, the components that are data files
each use their file path and name as their identification number or
string.
[0056] Either within the gaming machine 10, or in the diagnostic
system 140 attachable to the gaming machine 10, are executable
instructions or a software program 70 for verification of the
components (verification software 70), which may itself be one of
the components 50 to verify if it is internal to the gaming machine
10. In one embodiment, verification software 70 is stored on a
persistent storage media such as the hard disk device 90, ROM 77,
EEPROM 64, in a complementary metal oxide semiconductor memory
(CMOS) 72, in safe ram comprising a battery-backed static random
access memory (BBRAM) 62, in flash memory components 150, 160, or
other type of persistent memory. In one embodiment, the
verification software 70 is stored in a basic input/output system
(BIOS) 64 device or chip. BIOS chips 64 have been used for storing
prior verification software, such as previous versions of the
BIOS+chip used by Bally Gaming Systems, Inc. of Las Vegas, Nev. in
their EVO gaming system. Placing the verification software 70 in
the BIOS 64 is advantages because the code in the BIOS 64 is
usually the first code executed upon boot or start-up of the gaming
machine 10, making it hard to bypass the verification process.
Alternatively, in one embodiment, the verification software 70 is
stored in a firmware hub (FWH), such as Intel's 82802 FWH.
[0057] The organization of the hard disk device 100, and compact
flash 150 and 160 for the operating system and game according to
one embodiment are shown. The hard disk device 100 is broken down
into partitions 110 to reserve a fixed amount of space for major
components of the gaming system. When a hard disk device 100 is
used as the mass storage media, all content is downloaded to the
hard disk device 100 and there is typically no need for compact
flash components 150, 160. However, in one embodiment, a hard disk
drive 100 is used in combination with a game compact flash 160
containing game files, such files being previously approved by a
regulatory agency. Preferably, in a completely downloadable system,
the hard disk device 100 contains all files for the system and the
game compact flash storage media 160 is not required. For
jurisdictions that don't allow for hard disk devices, the operating
system's compact flash 150 is used to hold the Linux operating
system and gaming operating system related files, and the game
compact flash 160 holds the game files.
[0058] Each storage media, including the hard disk device 100, and
flash memories 150 and 160, is formatted into a typical disk drive
geometry of sectors, cylinders and heads. Sector 0 of the storage
media contains the master boot record, which also contains a
partition table. In one embodiment, a /manifests partition 110a is
an EXT2 Linux file system that is designed to hold the manifest
files that are associated with other files stored on the remaining
media partitions.
[0059] An /os1 partition 110b holds the root file system for the
operating system that is mounted by a Linux kernel. The root file
system contains the Linux operating system files as well as other
utility files of the gaming machine that are needed for proper
operation. It also contains the files that pertain to the operation
of the gaming OS. These are programs specifically developed to
manage the resources that are common to gaming machines, such as
input/output (I/O), peripherals, random number generator(s), host
communications drivers, and the like.
[0060] An /os2 partition 110c holds the same type of files as the
/os1 partition 110b, but the /os2 partition 110c includes an
alternative operating system that can be executed. If for some
reason the operating system contained in the /os1 partition 110b
fails to load and properly execute, then the system can revert to
the operating system in the /os2 partition 110c as a backup
operating system. In one embodiment, the /os2 partition 110c holds
an operating system that was previously known to operate without
failure. The operating systems contained in the /os1 and /os2
partitions 110b, 110c can be used interchangeably in an alternating
fashion so that it can be guaranteed that the last known,
acceptable operating system can be executed if the other operating
system fails to load. Another advantage of these dual operating
system partitions is to allow for robust updates of the operating
system, even if a power-fail should occur during package
installation. This is particularly important for various remote
system locations, where it may be inconvenient to send technicians
to fix failed downloaded updates.
[0061] In another embodiment, a /download partition 110d holds a
writable partition where newly downloaded packages are stored and
download log files are kept. When a package is installed, the
package contents are used to update files on the hard-drive
partitions as dictated by the package contents.
[0062] In a still further embodiment, a /games partition 110e holds
the files related to a game application. This includes the game
executable, graphics, sounds, paytables, configuration and other
files required for the game application to operate properly. In one
embodiment, this partition holds files for a plurality of games and
their associated files. This allows the system to support multigame
applications.
[0063] The operating system's compact flash 150 layout is similar
to the hard disk device 100 layout, except, in some embodiments, it
does not contain a /games partition. The game compact flash 160
contains a /manifest partition and /game partition. The operating
system compact flash 150 is used along with the game flash 160 to
form a complete bootable system. The /manifests partition located
on each media 160 contains the manifest files associated with their
respective media partitions.
[0064] As alternative, instead of, or in conjunction with, the hard
disk device 100, another mass storage device is used, such as a
CD-ROM, CD-RW device, a WORM device, a floppy disk device, a
removable type of hard disk device, a ZIP disk device, a JAZZ disk
device, a DVD device, a removable flash memory device, or a hard
card type of hard disk device.
[0065] FIG. 3 is a block diagram that illustrates directory and
file organization of the /manifest 110a partition for a hard disk
device 100. As shown in FIGS. 2 and 3, a /config directory 302
contains configuration files that the BIOS can use during the boot
process, including known operating system boot tracking files
boot.id and active.id. In one embodiment, a public-key.id file
stores a public key for verifying the /config directory itself, or
the whole manifest partition as a component. The /os1 directory 304
contains the manifest files pertaining to the operating system in
/os1 partition 110b. The /os2 directory 306 contains manifest files
for the operating system in the /os2 partition 110c. The /games
directory 308 contains all manifest files for the /games partition
110e. In one embodiment, manifest files end in ".mfst" which allows
the BIOS to uniquely identify them as it parses through the file
system.
[0066] Still further, a "/os1/kernel.mfst" manifest file contains
an entry associated with the Linux kernel image that is stored on
the /os1 partition 110b at the location "/boot/kernel.image".
Likewise the "/os1/initrd.mfst" manifest file contains an entry
associated with the /os1 partition file at the location
"/boot/initrd.image" The "/os1/os.mfst" file contains entries for
all other files on the /os1 partition 110b.
[0067] FIG. 4 is a block diagram that illustrates the layout of a
manifest file according to one embodiment. The manifest file
contains header information followed by an entry for each file. The
first component is the Manifest Digital Signature (MDS). The
digital signature is created at a later time after the manifest is
created. During manifest creation, the MDS is initially filled with
zeros as a placeholder. The next field is the SHA-1 hash value.
This hash value is calculated over the remainder of the manifest
file data. The next field holds the version string of the manifest.
Each manifest is uniquely identified by its file name. However,
additional version information is also placed within the file. The
Build Time Stamp field (BTS) contains the date and time when the
manifest was created. In one embodiment, the date and time field is
in Unix format. The Manifest File Entry Count (MFEC) field contains
the number of file entries that directly follow this field.
[0068] Each file entry contains information to allow the Linux
kernel to verify the contents of a file that exists on one of the
partitions. The first field of the file entry is the name of the
file. The file name is a variable length string that is terminated
by a null character. The name of the file matches the path of the
file to which it refers, as it exists on the Linux file system. For
example, and not by way of limitation, a file in a game partition
with the relative path, "/blazing7s/paytable," relates to an entry
of "/games/blazing7s/paytable" in the manifest because the game
partition is mounted under the "/games" directory of the Linux file
system.
[0069] Following the file name field is the type field, which
stores the type of the referred file. The type can be "file" to
indicate the SHA-1 is over the entire file contents. In another
embodiment, the type field can be set to "block" to indicate that
the file data is broken down into blocks of hashed data. Following
the type field is a summary SHA-1 hash value that is computed over
the remainder of the record's data. The block size field that
follows indicates the size of each block of file data. The number
of blocks in the file is the next field and it denotes how many
SHA-1 hash values will follow. The remaining SHA-1 hash values in
the file entry are the SHA-1 values for each sequential block of
data of the file. The last SHA-1 in the list includes the hash
value over the last block of file data. This last block could be
less than the full block size in the event the file size is not an
exact multiple of the block size.
[0070] The benefit of block type verification is that it allows
each block of data to be verified as the content of the file is
being read. For example, a media file may consist of a file size of
310,000,000 bytes, which is approximately 302 Mbytes in size.
Loading this entire file into memory may be difficult or
impractical for embedded systems having limited memory. Therefore,
it is desirable to stream the media file to the video display and
sound system by loading one piece of data at a time. Additionally,
verifying the entire 302 Mbyte file before playing it, may cause
the system to present a significant delay to the player. By using a
block size of 4 Kbytes, for example, each block is read and the
contents are verified one block at a time. This results in the 302
Mbyte file having 75684 blocks and 75684 SHA-1 values stored in the
manifest file. The last block of data in the file contains the
remaining 2432 bytes of data of the file and the last SHA-1 in the
SHA-1 list is calculated for this last block of 2432 bytes of
data.
[0071] FIG. 5, there is shown a flow chart illustrating the steps
for booting a BIOS and Linux operating system according to one
embodiment. The BIOS is the first program to start when the gaming
machine is powered on. The BIOS is located in a 1 MByte EPROM. Of
course, it will be appreciated that EPROMs of other capacities may
also be used. The last 512 Kbytes of the EPROM includes the BIOS
code. The first 512 Kbytes is used as startup code.
[0072] The BIOS first executes on power-up, step 400. In one
embodiment, the BIOS initializes PC-based hardware and then
executes a BIOS extension prior to booting from media. The BIOS
extension generally resides in the lower half of the EPROM. In step
402, the BIOS extension first validates itself by calculating a
Standard Hashing Algorithm 1 (SHA-1) over the entire 1 MByte BIOS
EPROM. In step 404, if the calculated SHA-1 does not match the
stored SHA-1 in the BIOS, then the EPROM is deem corrupt and
execution stops at the validation error state, step 490. The
validation error state displays a meaningful error message to an
operator and prevents further booting of the gaming machine system.
The gaming machine remains in this unplayable, faulted state until
power is recycled or the device is turned off and on. Again, a
SHA-1 is, but other techniques may also be used as are well know in
the art.
[0073] The BIOS validation step 402 may also include the check of a
digital signature. The digital signature and public key may be
stored in the BIOS next to where the SHA-1 is stored. After the
SHA-1 passes, the digital signature, public key, and SHA-1 value
can be used by a digital signature algorithm to test the
authenticity of the BIOS.
[0074] After the BIOS has authenticated the BIOS EPROM, in step
406, the BIOS authenticates the manifests on the media storage
devices attached to the gaming system electronics. During initial
boot-up, the BIOS searches for IDE drives connected to the
electronics. One configuration includes one large capacity hard
drive, although other configurations are used with other
embodiments. For example, with reference back to FIG. 2, in one
embodiment, the media storage device storing the files to be
verified and used by the gaming machine 10 is a remote media
storage device 101, that is accessed over a port 139 configured as
a network connection (e.g., RJ 45 for TCP/IP network, USB, switched
fabric connection, or the like) to a download server 122. The files
are read from the remote storage device over the network connection
port 139 from the download server 122.
[0075] In another embodiment, the remote media storage device 101
is combined with the download server 122 in a specialized file
server called a network file storage device. A network file storage
device contains a slimmed-down operating system and a file system.
The operating system processes I/O requests by supporting common
file sharing protocols. In one embodiment, this allows the gaming
machine 10 to operate as a diskless workstation, and boot directly
from the remote media storage device 101.
[0076] In yet another embodiment, the media storage device storing
the files to be verified and used by the gaming machine is a solid
state, or diskless, storage device, such as an erasable
programmable ROM (EEPROM), safe random access memory (safe-RAM),
another flash memory device, or the like.
[0077] Whether remote or local, hard disk or solid state, for each
media storage device, the BIOS reads the manifests. In one
embodiment, the manifests are read from a first partition 110
located on a hard disk device 100. In this embodiment, since the
manifests are stored in a EXT2 Linux file system on the partition
110, the BIOS is programmed to read this file system so that it can
open the root directory, subdirectories, and files within the
subdirectories. The BIOS starts at the root directory for the
manifest partition 110a and performs a depth first recursive search
for all manifest files that have the ".mfst" suffix. Every manifest
file found is then authenticated by the BIOS.
[0078] In one embodiment, for each manifest file, the system first
reads the size of the file from the directory entry. Then, in step
406, the BIOS opens the file to read the file contents in binary
format. The first 20 bytes of data are read as the digital
signature for the manifest. The next 20 bytes are read as the
pre-calculated SHA-1 representing the entire remaining file
contents. The BIOS then reads the remaining contents of the file
and calculates a SHA-1 over those remaining contents. The
pre-calculated SHA-1 and the calculated SHA-1 then are compared. If
they are not equal values, then the BIOS provides a validation
error and stops. Next, in step 406, the BIOS uses the SHA-1 value,
the digital signature for the manifest, and the public key stored
in the BIOS to authenticate the manifest file using a digital
signature algorithm (DSA). In step 408, if the DSA passes, then the
manifest is considered authentic; otherwise the BIOS provides a
validation error and stops, step 490. The manifest being
authenticated need not be loaded into memory. In one embodiment, it
is read in a piecemeal manner so that the SHA-1 can be calculated
over the file contents. Once a manifest is authenticated, then its
contents are cleared from memory. The BIOS then proceeds to
authenticate the next manifest.
[0079] Additionally, when authenticating manifest files, the BIOS
keeps a running SHA-1 hash value over all manifest file data it
processes in a global variable 410. Initially, this global
variable, BIOS SHA-1, is set to zero. As each manifest is
authenticated, the BIOS uses the BIOS SHA-1 result to perform a
running calculation over the entire manifest file contents. The
BIOS then stores the new BIOS SHA-1 result back in the global
variable, step 409. This process is similar to a process of
calculating a SHA-1 over all manifest files as if they were all
concatenated into a stream of file data. Therefore, the order of
processed manifests is kept consistent between the BIOS and the
kernel.
[0080] The BIOS SHA-1 value is then passed to the Linux kernel when
it boots, step 418. The Linux kernel can use it to guarantee that
the manifest file contents are identical when the Linux kernel
loads the manifests into memory. This allows the BIOS to perform
all of the authentication from EPROM based code, but allows the
Linux kernel to verify that every file loaded thereafter has not
changed from its originally processed contents. This step
guarantees that the manifest files have not been changed between
the time the BIOS authenticates them and the time the Linux kernel
loads them. In an alternative embodiment, the BIOS system
continually accesses the hard disk device 100 for the manifests.
With constant accesses and a quick boot time, the system can reduce
the chance that the manifest file has changed.
[0081] Once all manifests are authenticated, step 412, then the
BIOS verifies the Linux kernel image and the initial ram disk
image, step 414. The Linux kernel image contains the compressed
binary image for the Linux kernel. This is the first part of the
Linux operating system that runs. The initial ram disk image
contains a ram based file system that holds the startup drivers and
startup scripts used by the Linux kernel image. In one embodiment,
the manifest partition contains two special manifest files that can
be identified by their file name. The /manifests/os1/kernel.mfst
file contains the SHA-1 for the kernel image and the
/manifests/initrd.mfst contains the SHA-1 for the initial ram disk
image. When authenticating these two manifest files, the BIOS saves
their embedded SHA-1 values to use when loading the Linux kernel
image and the initial ram disk image. In step 414, the Linux kernel
image is loaded into memory by the BIOS. As it is loaded, the BIOS
calculates a SHA-1 over the contents. Once loaded, in step 416, the
BIOS compares the calculated SHA-1 to the SHA-1 kept from the
manifest file, kernel.mfst. If they are the same, then the Linux
kernel image is verified. The BIOS performs the same type of
operation on the Linux initial ram disk image. If either of the
SHA-1 comparisons fail, the BIOS produces a validation error and
halts further booting, step 490. Once both images are loaded, the
BIOS jumps to the start of the Linux kernel image In-Memory, step
418, passing the BIOS SHA-1 manifest calculation it computed over
all manifest files found on all media devices, step 410. This value
is passed in as a startup value allowing Linux to use it later in
the boot process.
[0082] When the Linux kernel executes, it performs some
initialization, eventually mounts the initial ram disk image, and
runs the startup scripts found on the initial ram disk, step 420.
These startup scripts load certain drivers from the ram disk and
install them into the Linux kernel. One of these drivers is the
file verification module. This module intercepts file open calls
made to the Linux kernel so that a file can be verified immediately
upon opening and before use. The module is also responsible for
storing the manifest entries of file names and SHA-1 values to use
in file verification. After installing the file verification
module, the startup scripts run the manifest loader that loads the
manifests into the kernel file verification module, step 422.
[0083] The manifest loader begins searching for manifest files on
the media devices. In one embodiment, the search for manifests is
performed using the same method and order as did the BIOS. Similar
to the BIOS, the manifest loader contains a global variable, Linux
SHA-1, that it initializes to zero, step 422. As each manifest file
is loaded, step 424, the SHA-1 is calculated over the entire
manifest file contents. In step 426, each manifest is parsed based
on the manifest file version, type information, and file type
version information. The manifest loader parses out each file entry
record. For each file entry it calls, the Linux kernel file
verification module passes the file name, file type, file SHA-1,
and any extra data associated with the file types, such a block
list of SHA-1's. As each call is made to load a manifest entry, the
file verification module adds each entry into an internal memory
table protected by the kernel and that is inaccessible to other
processes, step 424, until the last manifest is processed, step
428. This table is preferably a hash table keyed on file names to
allow for quick lookups when a file is opened. It is possible for
two manifests to reference the same file, but they both preferably
contain the same SHA-1 value. In other words, duplicate entries are
accepted and filtered out by the file verification module. In one
embodiment, if the same file name is loaded into the kernel file
verification module and the file has two different SHA-1 values,
then such is considered a validation error and the boot process is
terminated.
[0084] Once the manifest loader has loaded all manifests from all
media devices, it then passes into the file verification module the
Linux SHA-1 value it computed over all manifest file data. In step
430, the Linux kernel compares the BIOS SHA-1 passed to it when
starting the Linux kernel to the Linux SHA-1 passed in by the
manifest loader. If they are identical, then all manifests that
have been authenticated by the BIOS have been loaded by the
manifest loader and all manifest data was identical in both
operations. In this case, the file verification module records that
it has been properly initialized and the kernel call returns to the
manifest loader to continue the boot process. If a mismatch between
the BIOS SHA-1 and Linux SHA-1 is found in step 430, then the
kernel goes into a file validation error mode and prevents further
execution of the boot process in step 490.
[0085] During the boot process, startup scripts for the system
continue to run, step 470. Each of these files is loaded and
verified by the Linux kernel verification module by comparing its
calculated SHA-1 value to the SHA-1 value loaded in step 424.
Eventually the root file system for the operating system is mounted
from the hard disk device. In one embodiment, it is mounted as a
read-only file system. This file system contains more startup
scripts to continue the initialization of the operating system and
the eventual loading of the gaming operating system libraries,
servers, and game applications that comprise the gaming system,
step 480.
[0086] FIG. 6 is a flow diagram that illustrates the steps
performed in file verification method when a file is opened,
according to one embodiment. As each file is opened for processing,
step 500, a standard file-open call is made to the Linux kernel,
step 502. This can be caused by a script opening a file, a program
opening a file, or a Linux library opening a file. Every file-open
call is intercepted. In one embodiment, the Linux kernel is
customized to check if the file is on a read-only partition, step
504, and if not, a function call is made through an indirect
pointer to the file verification kernel module. Otherwise, the file
does not need verification and the Linux kernel can open, step 506,
and process, step 508, the file as it normally does.
[0087] More particularly, the kernel file verification module
receives the call to verify a file, step 510. The system first
looks up the file's complete path name in the hash lookup table
loaded previously during the Linux boot process. In one embodiment,
if the file entry is not found, then this unknown file cannot be
verified and the Linux kernel goes into a file validation error
mode, and prevents further execution of any applications. If the
file is found, then it retrieves the SHA-1 value loaded for that
file entry. The file data is then read by the kernel file
verification module and a SHA-1 is calculated over the file
contents, step 512. The SHA-1 calculated over the file contents is
then compared to the manifest SHA-1 value retrieved from the hash
table, step 514. If they match, then the file verification module
returns to the Linux kernel allowing it to complete the normal file
open process, step 506. If there is a mismatch, then the Linux
kernel goes into the file validation error mode preventing further
execution of any application processes, step 516.
[0088] In another embodiment, referring to the previous example of
a 302 Mbyte file with "block" type validation, in an additional
effort to save memory in the embedded system, the entire SHA-1 list
for file-by-file type verification of files is not loaded at boot
time. To save time, the Linux kernel retains In-Memory where the
SHA-1 list of the 75684 SHA-1 values starts in the manifest file
and uses it at a later time when the file is opened for streaming.
When the file is opened, the Linux kernel reads the SHA-1 list from
the manifest. In order to insure that the list has not changed or
been corrupted, the first SHA-1 in the file entry is the SHA-1 hash
value for the list. The Linux kernel can then load the list and
check its SHA-1 against the SHA-1 originally loaded at boot time.
Once this test is passed, then the file is ready for streaming and
each block of file data can be checked as it is loaded.
[0089] In one embodiment, a more hierarchical organization of SHA-1
values is used. This organization allows the Linux kernel to load
one piece of the SHA-1 value list at a time to further reduce any
load or time delays. If the Linux kernel loads 1000 SHA-1 list
values at a time, then a second tier level of 75 SHA-1 values are
present. The first SHA-1 is computed over the 75 SHA-1 values. The
first SHA-1 value in the second tier list is then computed over the
first 1000 SHA-1 values of the 3rd tier.
[0090] By using different types of file entries as denoted by the
type field, the manifest can support many different authentication
methods. The BIOS does not need to retain information about the
format for these types of manifests. The BIOS searches for manifest
files ending in the ".mfst" extension, reads the contents,
calculates the SHA-1 over the manifest file contents, excluding the
first 40 bytes of the DSS and the SHA-1 values, and then compares
the SHA-1 to what is stored in the manifest file. If there is a
mismatch, then the manifest file is corrupt. If the SHA-1 values
match, then the digital signature is checked with the SHA-1 value.
If the digital signature passes, then the manifest is deemed
authentic. If not, then there is a file validation error.
[0091] In other embodiments, the manifest is signed with other
public/private key algorithms, such as RSA, without affecting the
benefit that the digitally signed manifests provide. In one
embodiment, the manifests are encrypted instead of being digitally
signed. In yet another embodiment, the Linux Kernel Image and
initial ram disk image are encrypted. The decryption key is stored
in the BIOS. The BIOS decrypts the Linux kernel image and the
initial ram disk image, and allows the Linux kernel to boot. By
decrypting the kernel, the BIOS can run the kernel as a trusted
program. The Linux kernel boots and the startup scripts run the
manifest loader. The manifest loader decrypts the manifest files
and loads the file entries into the Linux kernel file verification
module, as described above. Once all manifests are loaded, the
Linux operating system continues booting and dynamically checks the
validity of each file as it is opened.
[0092] In another embodiment, manifests may be broken down to hold
SHA-1's for files according to how software components are packaged
and distributed. A package may consist of a set of files and the
package manifest that controls or pertains to one aspect of the
gaming machine's operation. By breaking the operating system or
game files into smaller packages, a gaming system that supports
download can have better control over which packages get updated
when such update occurs.
[0093] In some embodiments, one manifest holds verification data
for every file on the hard drive, while in other embodiments, the
manifest is limited to only one file, wherein every file has its
own associated manifest. Neither of these methods diminish the
benefit of improving the boot speed, since the operating system
verifies files that are loaded on an "as-needed" basis.
[0094] In another embodiment, one manifest with one digital
signature is used for all data files on a gaming platform, or for a
particular media storage device. In this embodiment, the manifest
partition contains one manifest file and one digital signature. In
another similar embodiment, the manifest partition is a list of
files and their associated SHA-1 values, with a digital signature
at the end of the partition, so that the entire partition is
authenticated before loading.
[0095] The benefit to having one manifest is the simplicity of
managing only one file entry list or one manifest, and the speed at
which the manifest is processed. In some embodiments, the manifest
is created at the time software is built for release. However,
downloading one entire package to the hard drive along with its one
associated manifest is not quite as beneficial as downloading
individual packages, in some gaming jurisdictions. In these gaming
jurisdictions, individual packages are created and approved by
regulatory agencies in an independent manner. In gaming machines
located within these jurisdictions, the packages are downloaded to
gaming machines individually by a download server to form various
configurations. This is much easier to manage instead of creating
every configuration at the time the software is built and getting
every combination of configuration approved by regulatory agencies.
For these gaming machines, it is advantageous to include a manifest
in or for each package downloaded.
[0096] In one embodiment, a method allows a single manifest to
exist while still providing the ability to download individual
packages. In this embodiment, the manifest is dynamically signed
each time a new download occurs that affects the contents of the
manifest. If a new package is downloaded that contains four new
files and one changed file, then four manifest file entries are
added and one entry updated with the new SHA-1 corresponding to the
files. The gaming machine digitally signs the manifest after the
download installation is completed. In this embodiment, the private
key for digitally signing the manifest is located somewhere within
the gaming machine.
[0097] In an alternative embodiment, the gaming machine, through a
secure connection with a download host, sends the manifest
information to the download host and the download host dynamically
digitally signs the manifest and responds to the gaming machine
with the manifest digital signature. In another embodiment, the
host already has the manifest contents of the gaming machine and is
able to digitally sign the new manifest and download it with the
original download package. Either of these methods allows the
download server to digitally sign the manifest so that the private
key is not stored within the gaming machine. This added protection
of the private key can be more easily performed on the download
server and is more economical than placing the same protection on
every gaming machine. Such protection can involve, for example, a
secure computing system, chip, or plug-in board that provides
digital signatures without compromising the private key.
[0098] As described above, the manifest contains file entries and
their associated SHA-1 values. In an alternative embodiment, the
manifest contains a list of partition entries that are on the
storage media. Each partition entry indicates a partition on the
hard drive and its corresponding SHA-1 value. The Linux kernel and
the initial ram disk image are stored in a separate partition. The
BIOS authenticates the manifest via its digital signature. It then
verifies the Linux kernel partition by calculating a SHA-1 over the
partition data, and then compares it to the manifest partition
entry. Once verified, the BIOS loads the Linux kernel and the Linux
kernel boot process begins. The manifest loader loads the manifest
in the Linux kernel partition verification module. The partition
verification module is responsible for verifying each partition as
it is mounted by the Linux operating system. Partitions are larger
than files, and verifying a partition prior to using some of the
files in the partition may take a little longer than file based
verification; however, it is still faster than verifying the entire
media content prior to booting.
[0099] Another embodiment uses block-based verifying. Every fast
access storage media in Linux is broken down into block-based
accesses. Each block may be 512 bytes in size. Of course, any size
block can be used. File systems are organizations that are built on
top of the block based data access methods. In one embodiment,
verification is built into the storage media by having a SHA-1 for
every block of data on the hard drive. The manifest then becomes a
list of SHA-1's for every block of data that is to be verified.
Since many of the blocks of data on a hard drive may be identical,
perhaps because they are unused, in one embodiment, the list is
compressed to save space. In such a scenario, the manifest
comprises approximately 20/512, or 4% of the disk space. If
sequential blocks area used to form a larger block of 4096, or 4
Kbytes, of data, then the disk space required for the manifest
reduces to approximately 0.5% of the disk space. With a 10 Gbyte
hard drive, the manifest is approximately 50 Mbytes in size.
[0100] In another embodiment, using a method similar to that
discussed above regarding file-based verification, hierarchical
sections of SHA-1 values allow portions of the manifest list to be
dynamically loaded on demand. For example, and not by way of
limitation, the 50 Mbtytes list is comprised of 2,500,000 SHA-1
values. The list of SHA-1's is broken down into 25,000 sections,
each section comprises 100 SHA-1 values. A higher level SHA-1 list
of 25,000 SHA-1 values is used as the top level SHA-1 values, where
each SHA-1 in this top level list is the SHA-1 over one of the
25,000 sections of SHA-1 values. This list is, therefore, about 500
Kbytes in size, which can easily be loaded into memory at boot
time. When the operating system tries to read a block of data on
the hard drive, the kernel determines which of the lower level
25,000 sections the block is associated. If this lower level
section of 100 SHA-1 values is not In-Memory, then it is loaded.
When the level is loaded, all 100 SHA-1 values for the section are
read into memory and the SHA-1 over them is calculated. This SHA-1
must match its corresponding SHA-1 in the higher level list of
25,000 SHA-1 values. If they do match, then the loaded section of
100 SHA-1 values is verified, and the correct SHA-1 value for the
block can then be used to verify the contents of the 4096 byte
block that is then loaded.
[0101] In still another embodiment, sections of the SHA-1 lists and
loaded are managed by a memory manager to determine when to release
a section list to make room to load another section list on demand.
Least recently used algorithms are used to determine which sections
to discard. In one embodiment, by de-fragmenting a hard drive, even
more efficiency is attained when using the block verification
method across the entire hard drive.
[0102] When using manifests with file-based verification, it is
possible to avoid loading all of the manifests. In one embodiment,
the Linux system keeps In-Memory only the SHA-1 value for the
manifest on initial loading, and then loads the remainder of the
manifest on demand. For example, in one embodiment, when a
particular partition is mounted by the Linux OS, then the Linux
kernel loads the manifest that pertains to that partition. When the
manifest is loaded, its contents are checked against the SHA-1
value that was loaded and stored in RAM during the boot process.
This allows the manifest to be loaded after boot time to assure
that it is authentic.
[0103] In another validation method, a manifest file approach using
Pintsov-Vanstone Signature Scheme with Partial Message Recovery
(PVSSR) is used for file validation. Instead of creating a SHA-1 on
the contents of each file and then signing the SHA-1, a PVSSR
signature is created using the contents of each file. As files are
accessed, the PVSSR signature is used to authenticate the contents
of the file before allowing it to be used. The PVSSR authentication
system insures that modifiable and programmed components in the
gaming device are authenticated during BIOS processing and before
the Linux system starts. Additionally, the Linux OS code and the
validation support code are contained on read-only EEPROM, thereby
insuring code integrity once the EEPROM is burned.
[0104] As used herein, the initial RAM disk is an In-Memory logical
disk used by the Linux kernel to load the support code when it is
initializing the system and creating the environment under which
the Linux system will run. The initial RAM disk is created using a
compressed file that contains all the modules and programs needed
to support initial system bootup. In the new file validation
environment, the RAM Disk will contain the file validation module,
the memory validation and the Faultdog module, as well as some
hardware support modules needed to start the Linux support. The RAM
disk will be stored as a compressed file on the BIOS ROM chip.
Additionally, the terms disk, CompactFlash.RTM. and flash are used
interchangeably within the document. These teens all refer to the
media where files are stored on a gaming machine.
[0105] It should also be noted that reference is made to the Alpha
Support Compact Flash (ASCF) and the Game Compact Flash (GCF). The
Alpha Support Compact Flash contains all the files and executables
needed to support the running of the Linux system and Alpha Game
support Platform. This includes the Linux libraries and programs as
well as the files and libraries used to support the running of a
game. The Game Compact Flash contains all the files required to
support and run a particular game.
[0106] FIG. 7 illustrates one embodiment of a processing
environment in a gaming machine 10. The components above the dashed
line 600 is stored on the socketted BIOS EPROM 602 in the gaming
device 10.
[0107] Other components within the gaming device 10 include the
Jurisdiction EPROM 604, the compact flashes 606, 608 containing the
Alpha Game Environment support code and the game code,
respectively, as well as the processing memory 610.
[0108] When the gaming device 10 is powered up, the BIOS 602 gains
control and validates its contents using a CRC16 hash.
[0109] The Linux Kernel as well as the Validation and Fault manager
modules are loaded from the BIOS into the EGM processing memory.
The File Validation module 612 then reads and authenticates the
contents of the Jurisdiction EPROM 604 as well as the contents of
all the File Manifest files stored on the Alpha Support compact
flash 606. If the Game compact flash 608 contains manifest files,
these files are authenticated. Otherwise, the contents of the
entire game flash 608 will be authenticated using a combination of
a SHA-1 Hash and DSS signature.
[0110] Once this is completed, control is passed back to the Linux
kernel to initialize the system operating environment and start the
game. As each file on a read-only compact flash partition is
accessed, the file's contents are authenticated using the
appropriate authentication method (e.g., PVSSR or DSS). If the file
being opened is covered by a DSS signed manifest file, then the
SHA-1 value of the contents of the file is validated. A
continuously running background process periodically authenticates
the manifest files, the files they point to, and the contents of
the Game compact flash.
[0111] Older game compact flashes that do not have a PVSSR or DSS
manifest file associated with them are authenticated using the DSS
signature for the SHA-1 value of the compact flash contents. This
DSS signature is stored in the game flash's pre-partition area.
[0112] No access is allowed to the game flash until it has been
authenticated.
[0113] After the initial authentication of the game flash's
contents, its contents are continuously validated on a periodic
basis.
[0114] If it is found that the contents are not valid, the machine
is immediately halted.
[0115] Jurisdiction chips signed using older DSS technology have
their contents authenticated using DSS signature of the
Jurisdictions contents SHA-1 hash value stored in the Jurisdiction
chip.
[0116] Generally, the PVSSR file validation methodology, disclosed
herein, uses a manifest file approach and a PVSSR signature is
created using the contents of each file. As files are accessed, the
PVSSR signature is used to authenticate the contents of the file
before allowing it to be used. The code to authenticate PVSSR
signatures resides in a file validation loadable module contained
within the initial RAM disk image that is stored on the BIOS
EEPROM. The File Validation module also uses the Public Keys stored
in the BIOS and a digital signature to verify: the contents of the
file manifest files; the contents of the jurisdiction EPROM; and
the contents of older game flashes that do not have PVSSR manifest
files associated with them. The File Validation module also creates
an In-Memory table of PVSSR signatures for all files on the
read-only partitions of the Alpha Support and for the Game compact
flash files if they exist.
[0117] If the Game compact Flash is covered by a DSS File
Validation Manifest, then the SHA-1 hash values for the files
contained on the game compact flash are read from the game DSS file
validation manifest files and stored in a memory table for later
access.
[0118] As shown in FIG. 7, the BIOS EEPROM also contains the Linux
kernel module. Both file validation loadable module and the Linux
kernel modules are loaded from the BIOS into the EGM main memory
before the Alpha system is loaded and receives control. A CRC16
checksum is performed over the entire contents of the BIOS to
insure that its contents are consistent and unchanged. When
initialization is complete, control is passed to the Linux system
initialization code to allow the system to start. As each file
residing on a read only partition of the compact flash is opened,
the file contents are authenticated using either the PVSSR
signature or the SHA-1 hash value stored during the File Validation
module initialization.
[0119] If the signature authentication fails or SHA-1 hash
validation fails, the EGM will be halted with an error message and
no further processing will be allowed.
[0120] Generally, one or more Validation Manifest Files (VMF) are
created for file validation. In one embodiment, four VMF's are
created for the Alpha Support Compact Flash: (1) Linux_base.ggmnfst
which is a manifest file that contains all the files associated
with the Alpha operating support; (2) Links_linux_base.ggmnfst
which is a manifest that contains the information needed to
validate that all logically-linked files point to the correct real
file; (3) glass.ggmnfst which is a manifest of all the images that
may be displayed on the gaming machine's top box video display; and
(4) Links_glass.ggmnfst which is a manifest used to validate any
logically linked files pointing to the correct real file.
[0121] For games using the PVSSR support, a minimum of two manifest
files are used.
[0122] A first manifest is used for the actual game files, and a
second manifest is used to validate that the logically-linked files
point to the correct real file.
[0123] In one embodiment, each VMF header includes the information
in the following table.
TABLE-US-00001 Field Description Signature Length of PVSSR
Signature Length PVSSR Digital signature of the contents of the
Manifest Header Signature File Count No. of files referenced in the
manifest Time Stamp Time stamp of when manifest was generated
Manifest ID Unique identifier for the manifest release id Unique
identifier for the release this manifest is associated with Control
Flags Control flags on how manifest and its contents are processed
Signature File For future use Name Reserved 2 KB of reserved space
for use by download support.
[0124] After the VMF header, the VMF includes file entries for all
the files to which the Validation Manifest File is applicable. Each
file entry contains the following information:
TABLE-US-00002 Field Description PVSSR Signature PVSSR Signature of
the file contents PVSSR Signature Size Actual size of the PVSSR
signature Signature Block Offset Reserved for future use Signature
Block Index Reserved for future use Check flag Control flag of when
and how to check PVSSR signature Size of file's name Size of the
name of the file File Name Fully qualified file name for the
signature
[0125] Generally, PVSSR signatures are created using
Certicom-supplied hardware in a secured location with a public and
private key pair only known to authorized individuals. Data to be
signed is loaded into the signing system from a secure location,
signed, and then stored back in the secure location.
[0126] FIG. 8 illustrates one method of creating manifest files
having a PVSSR signature from an unsigned binary image of the Alpha
Support or Game Compact Flash. At step 700, a list of all the files
is extracted from the unsigned, compact flash image.
[0127] At step 702, the list is divided into a list containing all
real files and associated data and a list containing the logical
link file names that point to real file names. At step 704, the
contents of each file from the real file list is read and passed to
the Certicom signing hardware. A signature for the contents of each
file is returned and saved in the manifest file at step 706. When
all the files are signed, the entire contents of the real file
manifest is signed at step 708. The returned signature is then
stored in the manifest file header. For the logically-linked file
list, the logical link name and the real file name are stored in
the manifest file at step 710. The contents of the manifest file
are then passed into the signing hardware and the resulting
signature is saved in the manifest header at step 712.
[0128] FIG. 9 illustrates a layout of one embodiment of a BIOS
EPROM 800 that supports PVSSR authentication. In this embodiment,
the BIOS 800 includes the following: BIOS Initialization and
Checksum 802; CRC16 of BIOS Contents 804; Linux Kernel Offset 806;
Linux Kernel Size 808; Initial Ram Disk Offset 810; Initial Ram
Disk Size 812; BIOS Flags 814; PVSSR Public Key 816; DSS Public Key
818; BALLY BIOS Extension code and loader 820; Linux Kernel
Loadable Image 822; Initial RAM Disk Loadable Image 824; and
Kontron.RTM. vendor BIOS Code 826. As those skilled in the art will
appreciate, other embodiments of the BIOS EPROM may include fewer
or more components.
[0129] The CRC16 hash is used to validate the contents of the BIOS.
The BIOS initialization calculates a CRC16 hash of the BIOS
contents and compares it to the stored CRC16 hash value. If the
CRC16 has values that do not match, the system is prevented from
starting. In one embodiment, an error message is presented on a
display of the gaming device. The PVSSR Public Key is used by the
file validation module to authenticate the PVSSR signatures for the
files, jurisdiction EPROM, and compact flash.
[0130] The DSS Public key is used to authentic older versions of
games and jurisdiction chips that were signed using the DSA/DSS
signing process. The BALLY BIOS Extension code and loader provide
the logic for copying the Linux Kernel and initial RAM disk from
the BIOS into the system's main memory and then passing control to
the Linux initialization code. The Kontron.RTM. vendor BIOS code
performs initial hardware identification and setup.
[0131] FIG. 10 illustrates one embodiment of the partitioning of a
hard disk 900, the OS compact flash 902, and the game compact flash
904. The reserved partitions 906 in the hard disk and OS compact
flash 902 are dedicated to host download support. If the gaming
device supports host download, the reserved partitions are
formatted and initialized. Otherwise, these partitions 906 are not
initialized and cannot be accessed. The os1 partition 908 of the OS
compact flash 902 contains all files used to run the game and
support the Linux System run environment. The glass partition 910
of the OS compact flash 902 contains the image files used for older
style games running on a dual screen gaming device. The image file
is used to display an image on the upper screen related to the game
that is running on the gaming device. In a download environment,
the reserved partition 3 (912) is designated as os2 and is used to
save a copy of the last working version of the system support
code.
[0132] FIG. 11 illustrates one embodiment of a manifest partition
1000 for an Alpha Support Compact Flash. The configuration
directory 1010 includes a file called boot.id that is used to
indicate which partition on the disk or compact flash boots the
Linux system support. This is important in a download environment
in which there is a primary and a backup OS (Alpha Support)
partitions. The games directory 1012 is used to mount and link the
manifest partition on the game compact flash. The os1 directory
1014 contains all of the manifest files associated with files
stored on the Alpha Support Compact Flash. In a download supported
environment, the os2 directory is available and contains the file
validation manifest file for the backup Alpha OS support. The
information contained within the os1 directory partition 1014 is
only accessible by the File Validation Module's initialization
process. The data extracted from the os1 partition 1014 is stored
in a private reserved storage belonging to the File Validation
Module.
[0133] FIG. 12 illustrates a start-up procedure for a gaming
device. When power is applied to the gaming machine, the BIOS is
initialized and the initialization code calculates a CRC16 hash
value for the contents of the BIOS EPROM at step 1050. At step
1052, the BIOS EPROM is validated by comparing the calculated CRC16
hash value to the CRC16 hash stored in the BIOS. If the values do
not match, an error message is displayed and all processing is
stopped. Otherwise, if the hash values match, the Kontron.RTM.
vendor BIOS support gains control and performs hardware
identification and initialization processing at step 1054. After
the Kontron.RTM. vendor BIOS support completes its initialization,
control is passed to the BALLY BIOS Extension.
[0134] At step 1056, the BIOS Extension code copies the Linux
Kernel Loadable image and the Initial RAM disk image from the BIOS
into the gaming device's RAM memory. The BALLY BIOS Extension also
copies the DSS and PVSSR Public Key bits from the BIOS into the
gaming device's RAM memory at offset 0x900.
[0135] Control is then passed from the BALLY BIOS Extension to the
Linux start-up code logic at step 1058. The Linux start-up code
initializes the Linux kernel control blocks, memory and CPU
hardware features. The Linux start-up code also calls a small
command file, linuxrc, located in the Initial RAM disk. At step
1060, the linuxrc command file loads various modules such as the
Bally AGK, Fault Manager, File Validation and Memory Validation
Modules into the gaming device's memory from the Initial RAM
disk.
[0136] The File Validation Module authenticates the Jurisdiction
EPROM and the contents of all file manifests. If present, the File
Validation Module will also authenticate the contents of older
and/or legacy game compact flash. The Bally AGK module creates and
initializes the upper level entries in the proc file system used by
Bally programming support. In particular, the Bally AGK module also
creates and initializes the proc file system entry/proc/agk. If
activated support functions are present, Bally AGK supports read
requests for reporting activated support functions.
[0137] If the modules, as shown in FIG. 11, load and initialize
successfully, control is passed back to the Linux start-up code.
The Linux start-up code continues the start-up process for the
Linux system and loads the game and the game support. If the
modules do not successfully complete initialization, a machine
fault is raised and the system is halted.
[0138] After the File Validation Module is loaded from the Initial
RAM disk and stored on the EGM's BIOS, the File Validation Module
is initialized according to the following process. First, the PVSSR
and DSS public keys that are passed by the BIOS BALLY extension
loader code are stored. The BALLY BIOS extension code will save the
PVSSR public key value at address x0900 In-Memory for use by the
File Validation Module.
[0139] Second, the File Validation Module uses either the stored
PVSSR or DSS public keys to authenticate the contents of the
Jurisdiction EPROM. If the Jurisdiction contents contain the string
"GG_SIGN", the Jurisdiction contents were signed using the PVSSR
public and private keys. Accordingly, the Jurisdiction contents
will be authenticated with the stored PVSSR. If this string is
absent, the contents of the Jurisdiction chip were signed using the
DSS public and private key pair, and the stored DSS public key is
used to authenticate the Jurisdiction contents.
[0140] Third, if the string "FST" appears at a predefined offset in
the pre-partition area of the Game compact flash, a flag is set to
identify the game compact flash as a pre-manifest type game. The
flag signals that the game needs to be authenticated by using the
SHA-1 hash of the entire game flash contents and the DSS signature
for the hash value. Additionally, an entry is created in the proc
file system, /proc/agk/game_auth, to indicate when the contents of
the game compact flash was validated. Access to the game compact
flash is not permitted until the contents of the game have been
authenticated and the word "Done" written into the
"/proc/agk/game_auth" file.
[0141] Fourth, the boot ID file is read to determine the proper
partition location for the Linux kernel on the compact flash or
hard disk. The boot ID file also identifies the proper partition
for starting the Linux operating system environment. The Linux
kernel is then initialized with the proper partition ID.
[0142] Fifth, the manifests associated with the Alpha Support
compact flash and game flash are read. The PVSSR signatures of the
manifest's contents are validated. Also, the memory file validation
table is built. If the game flash contains manifest files signed
with DSS support, a separate table containing the SHA-1 hash values
of all the files within the game manifest files is created. A flag
is set to indicate that the contents of the files on the game flash
are validated using the SHA-1 Hash values.
[0143] Sixth, the vendor ID and release information for the Alpha
Support and the Game are initialized. Next, the file validation
module saves the address of where to call the file validation
routine in the Linux kernel's open file code. Lastly, the file
validation module is registered with the system and control is
returned to the Linux start-up process.
[0144] In the event that an error is detected during initialization
of the File Validation Module, a system fault is raised and an
error message is presented on the display screen on the gaming
device. Additionally, all further processing is halted.
[0145] FIG. 13 illustrates one embodiment of an In-Memory File
Validation Table. As shown in FIG. 13, the table shows how the file
validation information is stored in the gaming device's memory.
[0146] As each file is extracted from the File Validation Manifest
File, its PVSSR signature is saved in the next free entry in the
Signature Table. The name of the file is then hashed to create an
index into the Signature Pointer Table. If an entry in the
Signature Pointer table already contains a pointer to a Signature
Table entry, the new Signature Table entry is chained to the one
pointed to by the Signature Index Table entry. The file name of the
new Signature Table entry is then stored in the file name table and
the address of where it is stored is saved in the Signature Table
entry. The first entry in a chain of Signature Table entries will
not have a file name associated with it. File names are only saved
for duplicates.
[0147] FIG. 14 illustrates one method for creating an In-Memory
File Validation Table. As shown in FIG. 14, a File Validation
Manifest is created for each file at step 1100. For each file in
the manifest, a PVSSR signature is saved in a Signature Table Entry
at step 1110. The file name is then hashed to create an index into
the Signature Pointer Table at step 1112. At step 1114, a
determination is made as to whether the index points to a used
table entry. If the index does not point to a used table entry, the
index points to the next Signature Table Entry at step 1116. The
process then repeats itself for the next file at step 1110.
[0148] If the index points to a used table entry, the entry is
retrieved at step 1118. At step 1120, a determination is made as to
whether the next PVSSR Sig Entry is zero. If the next PVSSR value
is zero, the process proceeds to step 1124. If the next PVSSR value
is not zero, the process chains through the PVSSR Signature entries
until a zero entry is found at step 1122. Once a zero entry is
found, the address of the new Signature Table entry is saved in the
next PVSSR Signature Entry at step 1124. At step 1126, the file
name is copied to the File Name Table, and the address is saved in
the Signature Table Entry. The pointer is updated to the next free
Signature Table Entry at step 1128. The process then repeats itself
for the next file at step 1110.
[0149] For a game flash that contains DSS File Validation Manifest
files, a duplicate memory validation table, as shown in FIG. 15, is
created that saves the SHA-1 hash values for the game file contents
instead of a PVSSR signature. The processing to create the
In-Memory File Validation Table using SHA-1 hash values is the same
as the processing for storing a PVSSR in a memory signature table,
except that the SHA-1 hash is used instead of PVSSR.
[0150] FIG. 16 illustrates one method for file validation
processing in a gaming device. When a request is made to open a
file that resides in a read-only partition at step 1200, the
system's open code calls the file validation driver with the fully
qualified name of the file to be opened.
[0151] The file validation driver performs the following operations
before allowing the file open to proceed. At step 1210, the driver
determines whether the file validation pointer is zero. If the file
validation pointer is zero, the Linux file open process continues
at step 1212, and the program continues processing at step
1214.
[0152] If the file validation pointer is not zero, the file
validation driver determines whether the file has PVSSR Signature
authentication at step 1216. If there is no PVSSR signature
authentication, the process proceeds to step 1212. If there is a
PVSSR signature authentication, a PVSSR value is calculated based
on the Index value from the file name at step 1218. At step 1220, a
determination is made as to whether the PVSSR Table Pointer Entry
is zero. If the value is zero, a system fault is raised and
processing stops at step 1222. If the PVSSR Table Pointer Entry is
not zero, the Signature Table Entry is retried at step 1224.
[0153] At step 1226, a determination is made as to whether the next
PVSSR Sig Entry is zero. If the next PVSSR Sig Entry is zero, then
the PVSSR Signature is extracted and the file contents are
authenticated at step 1228. If the file contents are deemed to be
authentic at step 1230, then the Linux file opening process
continues at step 1212. If the file contents are not authentic, the
system faults and processing stops by calling kernel panic at step
1222. The Linux kernel panic is intercepted by the Bally fault
manager code to display an error message on a display screen on the
gaming device. All further processing on the gaming device is
halted and no new processing can be started without manual
intervention by authorized personnel to correct the problem and/or
restart the gaming machine.
[0154] If at step 1226, the next PVSSR Sig Entry is not zero, then
the process loops through the chain of Signature Table Entries at
step 1232. If there is a file name match at step 1234, then the
PVSSR Signature is extracted and the file contents are
authenticated according to step 1228. If there is no file name
match or the process has reached the last entry, the first
Signature Table Entry is selected for authentication purposes at
step 1236. If the file contents are deemed to be authentic at step
1230, then the Linux file opening process continues at step 1212.
Otherwise, at the system faults and processing stops at step
1222.
[0155] Once the Linux kernel has completed all of its
initializations and the Linux run environment is established, the
Linux kernel passes control to the Linux command file, rc.sysinit.
FIG. 17 generally illustrates the logic flow through the system to
reach the rc.sysinit command file. Generally, the rc.sysinit file
loads support for any hardware not contained within the Linux
kernel and not started from the linuxrc command file, initializes
the game processing environment, and starts the game. Some basic
functions performed by the rc.sysinit command file include (but is
not limited to): mounting the compact flash device on the system as
read-only; setting hardware access to compact flash as R/O with no
file system caching; starting background file validation support;
authenticating that logically-linked files point to the correct
real files; loading common and activate hardware support not
included in Linux kernel; initializing video support and splash
screen support after the contents of the game compact flash have
been authenticated; loading any remaining hardware drivers;
starting memory background memory validation support; initializing
game global run-time environment variables; starting Game Manager
processing; and processing background authentication.
[0156] Background authentication processes are started from the
rc.sysinit processing. The background authentication process
authenticates and validates the following: any partitions formatted
with ext2 file system existing on the compact flash are not
modified; contents of the PVSSR File Manifests and the contents of
all files defined within those Manifests are authentic; contents of
a DSS manifest file associated with the game flash and the file
contents defined within the manifest are valid; or the SHA-1 hash
value over the entire contents of the game flash (not associated
with manifest file) matches the SHA-1 hash generated by the File
Validation Loadable Module initialization code. If any checks fail,
the system immediately halts with a message displayed on a video
screen of the gaming machine. These checks insure that the media
associated with the Linux Alpha Support and the Game code are not
modified in any manner and that the hardware is not producing any
errors or inaccurate data read results. The background process
checks also insure that files from the File Validation Manifest are
not modified or corrupted.
[0157] At the start of rc.sysinit processing, a program called
validate-links is run. The processing associated with the
validate-links program is performed before the Game Manager
environment and the game is started. The validate-links program
accesses File Validation Manifest files that contain all of the
logical links on the Alpha support and Game compact flashes. The
validate-links program extracts the logical link name and the real
file name from the manifest, accesses the logical link, and then
validates that the logical link points to the same real file as
specified in the manifest. If the logical link does not point to
the appropriate file, a system fault is raised and an error message
is displayed on a gaming machine's video screen, and all processing
on the EGM is halted.
[0158] In addition to running the validate-links program, a
validate-files process is started at the beginning of rc.sysinit
processing. Generally, on a periodic basis, the validate-files
process authenticates and validates that the game code and Alpha
support code on the compact flash have not been modified. The
validate-files process also validates that the hardware does not
give invalid information as a result of a read operation.
[0159] FIG. 18 illustrates one method for performing a background
validating process. At step 1300, the validate-files is started.
The boot partition ID is obtained from the boot.id file at step
1302, and the public keys are obtained from the proc file system at
step 1304. At step 1306, a list of Alpha Support File Validation
Files is obtained.
[0160] At step 1308, the validate-files program first reads control
blocks maintained by the EXT2 file system. The EXT2 file system is
used to format the partitions on the Alpha Support and gaming
device's storage media. The partitions are divided into physical
blocks of storage having the same size. The EXT2 file system
maintains a table that indicates whether a physical block is used
and unused. When data is written to one of the file system's unused
blocks, the file system's table is modified to indicate that the
block is no longer free. Additionally, the file system updates a
block that keeps track of all the used blocks within the
partition.
[0161] At step 1308, after the validate-files program reads the
control blocks, the program verifies that the control information
relating to the free and unused blocks has not changed since the
last time the control blocks were read. If a change is detected,
the machine is halted and a message displayed on the EGM's video
screen at step 1310.
[0162] Next, the program determines whether a "FST" string appears
in the pre-partition area of the Game compact flash at step 1312.
If present, a flag is set to identify the game compact flash as a
pre-manifest type game at step 1314. The flag signals that the game
needs to be authenticated by using the SHA-1 hash of the entire
game flash contents and the DSS signature for the hash value. At
step 1316, the validate-files program determines whether the Game
compact flash includes a DSS manifest. If present, a DSS Game Flag
is set at step 1318.
[0163] After the partition control data is authenticated, all of
the PVSSR manifests are processed at step 1322. The PVSSR manifest
processing includes reading and authenticating the manifest
contents for each Alpha support manifest at step 1330. If the
manifest contents are determined to be authentic at step 1332, the
contents of each file in the manifest is read and authenticated at
step 1334. If the contents of the manifest or the file's contents
are not authenticated at steps 1332 and 1336, an error message is
displayed on the gaming device's video screen at step 1310 and
processing is stopped.
[0164] If DSS Manifest flag is determined to be present at step
1324, a request is issued to File Validation Module to activate a
Linux Kernel thread (Game Validation) that authenticates the DSS
signature of the SHA-1 hash of Game compact flash's contents. At
step 1326, a SHA-1 hash value of the Game Flash contents is
calculated and saved into memory. The calculated SHA-1 hash value
is then compared to the hash value stored in the system RAM at step
1328. For DSS manifest processing, the manifest contents for each
Alpha support manifest is read and authenticated at step 1330. If
the manifest contents are determined to be authentic at step 1340,
the contents of each file in the manifest is read and authenticated
at step 1342. If the SHA-1 values do not match or the contents of
the manifest or the file's contents are not authenticated at steps
1340 and 1342, an error message is displayed on the gaming device's
video screen at step 1310 and processing is stopped.
[0165] Once the Game flash contents are authenticated, the
/proc/agk/game_auth file is updated to indicate Game flash
authentication is done. This allows the rc.sysinit command file to
initialize the Game Manager environment and access the game flash.
It also signals the validate-files process so it can continue to
periodically re-calculate the SHA-1 hash value of the compact
flash's contents. The file is validated if the calculated hash
matches the original hash value.
[0166] In one embodiment, the gaming device may be configured to
support host downloaded information. However, any modification made
to the gaming device's storage media requires that an existing File
Validation Manifest File be replaced with a new File Validation
Manifest File to reflect the changes to the files stored on the
gaming device's storage media. Since the File Validation Manifest
is being changed, the gaming device must be stopped and restarted.
This is required to allow the secure BIOS to authenticate and
validate the new operating environment and File Validation
Manifests, and to allow the validation driver to rebuild the
In-Memory File Validation Table.
[0167] Accordingly, one modification procedure is carried out
according to the following method. First, the gaming machine is
disabled, and no player activity is allowed on the gaming machine.
File validation is suspended. Files to be deleted from the storage
media are first rewritten with all zeroes prior to deletion. All
updates are made to the existing files, and any new files are
added. The File Validation Manifest file is then replaced. All
unused blocks on the storage media's partition are filled with
zeros. The File Validation Tables are re-created with the new
manifest. This insures that any previously validated files will be
validated again. The logical-links are also validated. Once
completed, the gaming machine is re-enabled to a run state.
[0168] In another embodiment, the gaming device includes a System
Fault Manager and hardware Watchdog support. Generally, the
hardware watchdog register is used by the Fault Management Support
to insure that all required processes and threads in the gaming
software are active and functioning. In one embodiment, the
Faultdog support interfaces with the Watchdog support in order to
detect whether a required thread no longer exists and to restart
the EGM after a fault has been detected, reported and acknowledged.
The Faultdog Manager is the only process in the system that
interacts with the Watchdog support, thereby insuring its
integrity.
[0169] In one embodiment, the hardware Watchdog support includes a
Watchdog circuit having a timeout counter and an input/output (I/O)
Halt from the Protection Circuit. If the watchdog circuit is
enabled, the timeout counter needs to be regularly cleared before a
timeout period. If a timeout occurs, the Watchdog circuit indicates
that the CPU must be locked-up and the CPU's hardware reset.
[0170] The following tables illustrate one embodiment of the
watchdog support.
TABLE-US-00003 BIT Signal Function D0 TO_0 Watchdog Timeout value
bit 0 D1 TO_1 Watchdog Timeout value bit 1 D2 TO_2 Watchdog Timeout
value bit 2 D3 TO_3 Watchdog Timeout value bit 3 D4 TO_4 Watchdog
Timeout value bit 4 D5 TO_5 Watchdog Timeout value bit 5 D6 TO_6
Watchdog Timeout value bit 6 D7 /WCHDOG_EN Watchdog & I/O Halt
Enable (Protection circuit), active low
TABLE-US-00004 FUNCTION Clear Manual Watchdog Watchdog State CPU
& I/O Halt Timer after BIT Reset Disable (Enabled) Reset D0 0
Any Timeout 1 D1 0 Non-Zero Value 1 D2 0 Value 1 D3 0 1 D4 0 1 D5 0
1 D6 0 1 D7 0 1 0 1
[0171] The Watchdog enable bit enables both the Watchdog and the
I/O Halt from the Protection Circuit. Bits TO[6:0] set the timeout
period ranging from 0.1 to 12.8 seconds with a resolution of 0.1
seconds. Because the timer and the timeout register are not
synchronized the timeout period is provided with 0.1 seconds of
tolerance. As shown above, Bit 7 high disables the Watchdog's CPU
reset and the Protection Circuit's I/O halt signals.
[0172] When enabling the Watchdog, care must be taken because the
Watchdog counter is free-running. As a result, it is possible that
the timeout value may match the counter when the Watchdog is
enabled, thereby resulting in a CPU reset that initiates an endless
cycle of resets. To prevent this problem, the Watchdog is enabled
on power-up with the timeout initially set to the maximum of 12.8
seconds. Additionally, once the Protection Circuit times out, the
Protection Circuit may only be reset with a hardware reset. If the
Protection Circuit is being used, servicing starts before its first
15 minute timeout. These two limitations prevent enabling and
disabling the Watchdog with different applications. As a result,
the Watchdog should only be initialized at power-up.
[0173] The Watchdog counter is automatically reset when a timeout
value is written and bit-7 (/WCHDOG_EN) is low. The manual CPU
reset is established by writing all zeros to the `HW Watchdog
Register`. In order to prevent glitches or inadvertent resets of
the system when enabling the Watchdog, the timeout value should be
a non-zero value prior to clearing bit 7.
[0174] The Software Faultdog support includes the following
functions: monitor all registered processes to detect errors or
unauthorized removal of registered processes; manage the hardware
Watchdog Register to avoid system hangs; display generic user
message and turn on top box lights when a fatal error occurs; log
detailed fault description message when fatal error occurs; display
detail fault description message when attendant key is turned;
display a message when the door is opened after a fault has
occurred; display a message when a Game or OS flash has been
removed; automatically detect cabinet-type and port configuration;
automatically reboot the gaming device when the attendant key is
turned for the second time after a fatal error; provide
independence from any specific video or I/O requirements; and catch
kernel panic errors, show detailed information about kernel panic,
and prevent the gaming device from automatically rebooting after
the panic occurs.
[0175] All files, partition, and memory validation threads register
with the Faultdog Manager when they are first started. The Faultdog
Monitoring Support continuously runs in the background checking to
see if registered threads are still active in the system. If a
registered thread is no longer active on the system, a fatal fault
is raised. This fault is written to the fault log, and the
appropriate message is displayed on the video screen of the gaming
device. Typically, attendant intervention is required to clear this
fault and restart the gaming device via a power-up cycle.
[0176] The Faultdog Manager also resets the hardware Watchdog Timer
to signal that the system is still alive. If the Faultdog Manager
does not reset the hardware Watchdog Timer, the timer will expire;
thereby causing a system failure. The Faultdog Driver and process
insure that all of the required processes are still active and that
the hardware Watchdog Timer is used to verify that the Faultdog
Code is still active.
[0177] Any errors detected by the Faultdog Management Code will
generate an error message for display on the video screen of the
gaming device. Optionally, the candle lights, on the gaming device,
may be turned on in response to errors detected by the Faultdog
Management Code. Optionally, the errors are written to a Faultdog
Error Log.
[0178] Generally, Faultdog Error logging support is only available
after the BIOS code has finished processing, and the Faultdog
Support installed. The Faultdog Support is installed as the first
support during Linux kernel initialization and setup process and
prior to any other authentication and validation code in
system.
[0179] The error message and the error log includes the following
information: date and time stamp for the error occurrence; task ID
of the task that was running at the time of the error; description
of the type of error that was encountered; and the name of the file
being processed if the error was caused by a file validation.
[0180] When the G2S Download support is introduced into the system,
any authorized regulatory monitoring authority will be able to
request a copy of the error logs to be transmitted to them along
with any relevant validation data.
[0181] It should be noted that, while some embodiments have been
described in the context of a gaming machine, the components of any
device can be verified using the embodiments described herein. By
way of example, and not by way of limitation, other exemplary
devices that can be verified include: a kiosk, a cashier device, a
plasma signage controller, a DNS server, a DHCP server, a database
server, a web server, a cryptographic device, a firewall, a load
balancer, a network monitoring unit, a network router, a download
server, a certificate authority server, a cashless server, a
progressive controller, a tournament controller, a display
controller, a networking device, an Ethernet switch, a network hub,
a cash transaction server, a third party payment server, a prize
redemption machine, in room gaming device, a bingo game controller,
a lottery game controller, a class II gaming device, a class III
gaming device, a lottery gaming device, an amusement gaming device,
an arcade gaming machine, a regulator monitoring device, a VPN
device; a player tracking device; a player marketing device, a slot
management system, a home game console, an ATM banking machine, a
debit card reader, a point of sale system, a cash register, a
retail scanner, a RFID reader, a location security
monitoring/security input device, a military device, a vending
machine, a stock transaction server, a banking server, a cell
phone, a personal digital assistant, a laptop computing device, an
electronic wallet device, a smart card, a set-top box, a monetary
input/output device, a biometric device, a user authentication
device, a personal media player, a software network updatable
device, a handheld scanner, a currency handler/counter, a lottery
ticket purchase/redemption device, a player bingo device, a
monitor, a television, a fax device, an electronic money transfer
device, a USB device, a Bluetooth device, a fire wire capable
device, a wi-fi enabled device, a robotic device, or a handheld
gaming device or any other device that requires files to be
verified in a timely manner.
[0182] The various embodiments described above are provided by way
of illustration only and should not be construed to limit the
invention. Those skilled in the art will readily recognize various
modifications and changes that may be made to the claimed invention
without following the example embodiments and applications
illustrated and described herein, and without departing from the
true spirit and scope of the claimed invention, which is set forth
in the following claims.
* * * * *