Patent Application
20100120526
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.
Embodiments disclosed herein relate generally to a system and method for using a co-processor to authenticate software, and more particularly, to using a co-processor to authenticate software in gaming machines.
The gaming industry has often utilized computer-based gaming devices that apply encryption and authentication techniques for security. Electronic gaming devices are machines that provide for wagering games such as poker, blackjack, and other games of chance, skill, or combinations thereof. Currently, gaming devices are produced in many forms including stand-ups, tabletop machines, handheld units, gaming integrated with mobile phones, software plug-ins such as a java applet, and many other types of gaming devices. In such electronic gaming machines, such electronic components include a processor, storage media, and gaming software (e.g., game code) that is stored on the storage media and executed by the processor. To provide necessary security, the gaming software is authenticated at start-up and at other times throughout the gaming process.
One security measure that may employ encryption is software authentication in a gaming machine. Gaming regulations require that game software in electronic gaming machines be authenticated. Various events may trigger an authentication process, which typically takes place in the central processing unit (CPU) of the gaming machine. Typically, gaming software uses one processor to both authenticate and execute the gaming software. This increases the time needed to execute instructions. Authentication takes longer with more complex programs and programs that require a lot of memory.
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.
Typically there is a secure memory, or read only sealed memory, such as an EPROM which contains an authentication algorithm. Additionally, there is non-secure media that contains the content to be authenticated. The secure memory can be removed and independently verified and authenticated with external devices; however, data in non-secure devices cannot be easily removed, making verification and authentication 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.
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 the data is stored on a hard drive, CD-ROM, or DVD-ROM. This results in considerably longer boot times for gaming machines and other devices that require verification and authentication. 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 are growing, resulting in even longer durations for boot time authentication.
Moreover, in many gaming jurisdictions, there are regulatory requirements that mandate that authentication of a system be performed by a program running from the non-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.
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 contents of the non-secure media are authenticated by the operating system at boot time.
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.
An added concern is creating an authentication methodology that can be used on one or more memory devices, where the methodology used accommodates memory devices that were created without “native” support of the authentication algorithms. This allows use, for example, of legacy game memory devices that were previously developed, tested, and approved by gaming regulators. This methodology would allow legacy memory devices that had already been approved by regulatory gaming jurisdictions to be authenticated using any algorithm supported by the gaming device. The legacy game memory devices can be either secure media (non-alterable) or non-secure media (alterable). The alternative would be to re-sign the legacy memory device and submit for regulatory testing and approval, which can be costly in terms of time and money.
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.
One security measure that may employ encryption is software authentication in a gaming machine. Gaming regulations require that game software in electronic gaming machines be authenticated. Various events may trigger an authentication process, which typically takes place in the central processing unit (CPU) of the gaming machine. Typically, gaming software uses one processor to both authenticate and execute the gaming software. This increases the time needed to execute instructions. Authentication takes longer with more complex programs and programs that require a lot of memory.
Accordingly, those skilled in the art have long recognized the need for a system and method that can reduce the time necessary to authenticate software. This invention clearly addresses these and other needs.
Briefly and in general terms, a system and method of using a main processor and a co-processor to authenticate software and execute software to reduce processing loads is disclosed. Such a system includes: a media storage device for storing gaming software, a first processor for executing the gaming software, and a second processor for authenticating the gaming software. Preferably, the first processor is connected to the storage device via a first interface bus. Preferably, the second processor is connected to the storage device via a second interface bus. In response to a command, game software information is transferred to the second processor via the second interface bus to authenticate the game software. The authentication results are then reported to the first processor to establish access rights to the gaming software by the first processor.
In another embodiment, a method for authenticating software in a gaming machine having a main processor and a second processor is disclosed. The method includes: storing software associated with a game on a storage device in the gaming machine; receiving a command to execute gaming software; transferring gaming software information to the second processor; authenticating the software in the gaming machine using the second processor and without using the main processor; reporting authentication results to the main processor to establish access rights to the gaming software by the first processor; and enabling access rights to the gaming software by the main processor, in response to receiving positive authentication results.
Other features and advantages will become apparent from the following detailed description, taken in conjunction with the accompanying drawings, which illustrate by way of example, the features of the various embodiments.
Referring again to the drawings, wherein like reference numerals denote like or corresponding parts throughout the drawings, and more particularly to
Specifically,
The gaming machine 10 includes one or more input mechanisms. In one embodiment, the gaming machine 10 may include a plurality of player-activated buttons 18, which may be used for numerous functions such as, but not limited to, selecting a wager denomination, selecting a number of games to be played, selecting a wager amount per game, initiating a game, or cashing out money from the gaming machine 10. The buttons 18 function as input mechanisms and may include mechanical buttons, electromechanical buttons or touch screen buttons. Optionally, handle 19 may also serve as an input mechanism. More particularly, the handle 19 may be “pulled” by a player to initiate a game.
The gaming machine 10 may also include one or more speakers 24. Various types of audio may be output to the speakers 24. In various embodiments, the gaming machine 10 shown may also include a ticket reader/ticket printer system 16 that is associated with a cashless gaming system. In one embodiment, the ticket reader/ticket printer system may print out and/or issue tickets. In another embodiment, the ticket reader/ticket printer system 16 is capable of accepting previously printed vouchers, paper currency, promotional coupons, or the like. The ticket reader/ticket printer system 16 of the cashless gaming system may generate vouchers having printed information that includes, but is not limited to, the value of the voucher (i.e., cash-out amount) and a barcode that identifies the voucher.
Optionally, in an alternate embodiment, the ticket reader/ticket printer system 16 includes a bill acceptor, which is an assembly that examines currency or coupons and communicates the value to the machine. Accepted items register as credits, and rejected items are returned to the player. In one optional embodiment, the slot 24 works in conjunction with a bill acceptor assembly. Alternately, in an optional embodiment, the gaming machine 10 includes a separate bill acceptor (not shown). In one embodiment, the bill acceptor device may include an embedded web server that delivers a management user interface to a web browser. The management user interface may be used to control and configure various functions and operations of the bill acceptor.
The gaming machine 10 may further include a player tracking system (not shown). The player tracking system allows a casino to monitor the gaming activities of various players. Additionally, the player tracking system is able to store data relating to a player's gaming habits. That is, a player can accrue player points that depend upon the amount and frequency of their wagers. Casinos can use these player points to compensate the loyal patronage of players. For example, casinos may award or “comp” a player free meals, room accommodations, tickets to shows, and invitations to casino events and promotional affairs.
Typically, the player tracking system is operatively connected to one or more input components on the gaming machine 10. These input components include, but are not limited to, a card reader 26 for receiving a player tracking card, a keypad or equivalent, an electronic button receptor, a touch screen, and the like. The player tracking system may also include a database of all qualified players (i.e., those players who have enrolled in a player rating or point accruing program). Generally, the database for the player tracking system is separate from the gaming devices. The gaming machine 10 includes a card reader 26 that may be used to read player tracking cards. Additionally, the card reader 26 may also read casino employee cards. Each time a card is inserted into the reader, it monitors and tracks player and employee activity.
As shown in
The stepper motors 30 of the gaming machine 10 are controlled and monitored by the RCU 28. More specifically, the RCU 28 is responsible for determining the spin profile for each reel 20. In order to determine the appropriate spin profile, the RCU 28 calculates the distance between the current and final position of each reel. Based upon the spin distance and the desired spin duration of each reel, the RCU 28 then determines a spin profile for each reel 20.
As shown in
In one embodiment, the game controller 32 includes a random number generator 34 that determines a game outcome, wherein the game outcome is a combination of indicia. In alternate embodiments, the game controller 32 may use a pseudo-random number generator or a weighted random number generator to determine the game outcome. In yet another embodiment, the random number generator 34 (or pseudo-random number generator or weighted random number generator) is a separate component in communication with the game controller 32.
As shown in
Typically, the player tracking system is operatively connected to one or more input components on the gaming machine 10. These input components include, but are not limited to, a card reader for receiving a player tracking card, a keypad or equivalent, an electronic button receptor, a touch screen and the like. The player tracking system may also include a database of all qualified players (i.e., those players who have enrolled in a player rating or point accruing program). Generally, the database for the player tracking system is separate from the gaming devices.
Referring now to the gaming network, an additional security feature of the gaming network requires a secure boot sequence within each gaming machine and server such that an initial boot is accomplished using code residing in unalterable media. The initial boot code verifies the operating system and all network services it includes. Consequently, network services will not be enabled until the full operating system has been verified as legitimate.
In one embodiment, the game machine provides a secure boot and initial O/S verification as follows. EPROM verification software resides within an input/output processor (IOP). The verification software verifies all EPROMs on the IOP board (i.e., mains and personalities) upon application of power to the game machine. Next, after the application of power to the machine, the BIOS+ performs a self-verification on all of its code. Once satisfactorily completed, the board (e.g. a Pentium class board) begins executing code from the BIOS+ contained in the conventional ROM device. This process verifies the conventional ROM device and detects any substitution of the BIOS+.
Upon boot-up of the processor, the BIOS+ executes a SHA-1 verification of the entire O/S that is presented. At least with respect to the components that comprise data files or firmware, a well-known hash function, the Secure Hash Function-1, also known as SHA-1, may be used to compute a 160-bit hash value from the data file or firmware contents. This 160-bit hash value, also called an abbreviated bit string, is then processed to create a signature of the game data using an equally well-known, one-way, private signature key technique, the Digital Signature Algorithm (DSA). The DSA uses a private key of a private key/public key pair, and randomly or pseudo-randomly generated integers, to produce a 320-bit signature of the 160-bit hash value of the data file or firmware contents. This signature is stored in the database in addition to the identification number.
The digital signature is calculated and compared with an encrypted signature stored in a secure location on the game machine using, for example, the RSA private/public key methodology. If the signatures compare, the BIOS+ allows the operating system to boot, followed by the game presentation software. Next, display programs and content are verified, before being loaded into the IOP RAM to be executed for normal game operation.
During communication, each message is protected using the security of the gaming network. However, certain messages incorporate additional security checks even if the package is considered trustworthy. For example, code downloads may require that they be cryptographically signed and verified before executing. For messages such as these, the digital signature for the code is independent of and in addition to the authentication provided by VPN and the other network security features. In addition to the digital signature check and verification, the gaming network implements increasing number versioning of network downloaded updates so that rollback attempts may be mitigated or eliminated.
Once two devices have identified themselves to each other, a verification procedure can take place. The verification procedure is intended to establish that the device with which another device is communicating is a valid gaming device. In one embodiment of the disclosed embodiments, verification may be accomplished by using the protocol described herein in connection with
In one embodiment, a verification method such as is described in pending U.S. patent application Ser. No. 10/243,912, filed on Sep. 13, 2002, and entitled “Device Verification System and Method,” assigned to the assignee of the disclosed embodiments, and incorporated by reference herein in its entirety. The disclosed embodiments provide a system and method for verifying a device by verifying the components of that device. The components may comprise, for example, software components, firmware components, hardware components, or structural components of an electronic device. These components include, without limitation, processors, persistent storage media, volatile storage media, random access memories, read-only memories (ROMs), erasable programmable ROMs, data files (which are any collections of data, including executable programs in binary or script form, and the information those programs operate upon), device cabinets (housings) or cathode ray tubes (CRTs). Identification numbers or strings of the components are read and then verified. The process of verifying may comprise matching each identification number in a database to determine whether each identification number is valid. In the case where a data file comprises one of a plurality of operating system files, verification of that file, in effect, comprises verifying part of an operating system. For data files, the file names may comprise the identification numbers.
The database may comprise a relational database, object database, or may be stored in XML format, or in a number of other formats that are commonly known. The database may also comprise an independent system stack of bindings, which comprise numbers, identification strings or signatures in the database for matching or authenticating the components, from manufacturers of the components, each identification number being verified using the binding from the manufacturer of the respective component to verify the component. Especially in the context of smaller devices such as personal digital assistants (PDAs), such a system stack may comprise a subset of one or more global component databases containing bindings from manufacturers of the components, each binding of the subset being associated with at least one of the identification numbers of one of the components in the device.
Structural components, such as cabinets, may contain an electronic identification chip embedded within them, such as a so-called Dallas chip or an IBUTTON device manufactured by Dallas Semiconductor of Dallas, Tex. These devices allow a unique identifier, placed within a semiconductor or chip, to be placed on a component that may or may not be electronic, such as a computer or gaming machine cabinet. The IBUTTON device is a computer chip enclosed in a 16 mm stainless steel can. The steel button can be mounted, preferably permanently or semi-permanently, on or in the structural component. Two wires may be affixed to the IBUTTON device, one on the top, and one on the bottom, to exchange data between the IBUTTON device and a processor, serial port, universal serial bus (USB) port, or parallel port.
The matching process may comprise matching each identification number based on the type of component that the identification number identifies. The identification number and the type of component are matched in the database in order to verify that the identification number is valid. Operation of the device may be stopped if any one of the identification numbers is not matched in the database. In the case of a game or gaming machine type of device, a tilt condition message is generated if any one of the identification numbers is not matched in the database.
Either contained in the device, or in communication with the device, is a processor and a memory containing executable instructions or a software program file for verification of the components (verification software), which may itself be one of the components to verify. The verification software may be stored on a persistent storage media such as a hard disk device, read only memory (ROM), electrically erasable programmable read-only memory (EEPROM), in the aforementioned CMOS memory, battery-backed random access memory, flash memory or other type of persistent memory. Preferably, the verification software is stored in a basic input/output system (BIOS) on a solid-state persistent memory device or chip. BIOS chips have been used for storing verification software, such as the BIOS+ chip used by Bally Gaming Systems, Inc. of Las Vegas, Nev. in their EVO gaming system. Placing the verification software in the BIOS is advantageous because the code in the BIOS is usually the first code executed upon boot or start-up of the device, making it hard to bypass the verification process.
Alternatively, the verification software may be stored in a firmware hub, which may comprise the part of an electronic device or computer that stores BIOS information. In personal computer hub technology, such as that manufactured by the Intel Corporation of Santa Clara, Calif., a hub is used in place of a peripheral component interconnect (PCI) bus to connect elements of chipsets.
The persistent storage media may be a removable storage unit such as a CD-ROM reader, a WORM device, a CD-RW device, a floppy disk device, a removable hard disk device, a ZIP disk device, a JAZZ disk device, a DVD device, a removable flash memory device, or a hard card device. However, the database is preferably stored in a non-removable, secure device either within the device being verified, or remotely on a server, in order to enhance security.
The verification software executes a DSA verification of the data files and firmware components. Also stored in the database is the public key of the private key/public key pair. For each data file and firmware component, as part of the DSA verification, the processor and verification software first computes the hash value of the digital contents of the component using the SHA-1 algorithm. The verification software then processes or authenticates this computed hash value, using the DSA signature verification algorithm, which also takes, as input, the aforementioned public key stored in the database. The verification part of the DSA produces a boolean result (yes or no) as to whether the inputs solve the algorithm. If the algorithm is not solved by the inputs, then an unexpected result is produced, thereby failing to verify the particular component. This may cause a fault tilt to occur to prohibit the loading operation of the device. Otherwise, use of the device is permitted. A detailed description of the DSA can be found in the U.S. government's Federal Information Processing Standards Publication (FIPS) 186-2. That publication describes each step of the DSA signature generation and verification.
Alternatively, the set of executable instructions may use the Rivest-Shamir-Adleman (RSA) algorithm to verify the components. Using the RSA algorithm, a first abbreviated bit string or hash value is computed from each component's digital contents and encrypted into a digital signature. The digital signature is stored in the database along with the identification number for the component. When the device is verified, the component is verified by computing a second abbreviated bit string computed from the component's digital contents. The signature is retrieved from the database by searching the database for the identification number. The signature is decrypted to recover the first abbreviated bit string. The component is then verified by comparing the second abbreviated bit string with the first abbreviated bit string. If the first and second abbreviated bit strings do not match, then the component is not verified. As discussed below, this may cause a fault tilt to occur to prohibit the loading operation of the device. Otherwise, use of the device is permitted.
Instead of creating a digital signature for (i.e., signing) each data file individually, collections of data files may be signed together in order speed up processing. The abbreviated bit strings, hash values, or signatures, also called digests, of the collection of data files are collected into a catalog file, and the catalog is signed as described above.
Referring now to
The main processor 120 is used to execute gaming software. The gaming software may be stored in a storage device 130 such as a hard disk or flash-based memory. The main processor 120 communicates with the storage device 130 via bus 140. Other components (not shown) may also be connected to the main processor 120 via the bus 140.
A co-processor 150 interfaces with the storage device 130 via a dedicated bus, such as a direct memory access bus 160. The co-processor 150 may also be directly connected to the main processor 120. The co-processor 150 may consist of separate units of hardware, such as field-programmable gate arrays or complex programmable logic devices.
Additionally, this co-processor assisted hardware-based system for software authentication uses the central processing unit 110 to control the operations of the gaming machine 100, including the software authentication, which is performed at various points in time. The storage device 130 may also store the authentication program, which may include hash functions, digital signatures, and a public key.
In practice, the central processing unit 110 receives wagers or commands to initiate a game. During game-play, the main processor 120 communicates with the co-processor 150 at every software authorization request. The microprocessor 120 transfers information to the co-processor 150 to allow the co-processor to perform authentication while the microprocessor 120 executes the gaming program. For example, the microprocessor 120 may transfer a software component's length and start address, as well as the public key to the co-processor 150 during initial transfer.
The result of this transfer is that the co-processor 150, interconnected via its own interface bus 160 and the storage devices 130, performs the hardware based authentication of all of the software process, rather than process being performed by the microprocessor 120. The storage device 130 may be any type of electronic storage device including but not limited to a hard drive, CD-ROM, DVD, and Flash memory.
The co-processor 150 may use the software public key, start address, length, and digital signature, or any other information provided by the microprocessor 120 to perform authentication. The co-processor 150 performs the authentication before allowing the microprocessor 120 access rights to the data. Upon completion of the authentication process, the co-processor 150 reports the results back to the microprocessor 120 of the main CPU 110.
The utilization of the co-processor 150 significantly enhances performance of the software authentication process within the gaming 100. Specifically, the co-processor 150 performs the software validation at a processing speed greater than that capably provided by the main processor 120. Additionally, use of the co-processor 150 off-loads the software processing functionality from the main processor 120, thereby reducing the amount of code needed to perform software validation. Correspondingly, this provides added processing capability for additional game play on the gaming machine 100. In this manner, the main processor 120 may perform one process while the co-processor 150 authenticates software to be used in the same process or another process.
Normally, authentication of gaming software is performed by software-based techniques in a gaming machine. Software-based authentication techniques, although more granular, lack speed, and if required to authenticate large groupings of stored data, can hinder performance. A hardware-based authentication process, using a co-processor in place of a main processor, overcomes the lack of performance issues that are typically associated with software-based authentication. The above-described hardware-based authentication process improves the speed for processing authentication of gaming and other software associated with a gaming machine.
The co-processor uses the game software data to access the game software on a storage media. The co-processor may then authenticate 230 the game software. Preferably, the co-processor has a dedicated bus for accessing the game software from the storage device.
If the authentication is successful, the co-processor communicates with the main processor 240, and the main processor accesses the storage media and executes the software program 250. If the authentication is unsuccessful, the co-processor communicates 240 the authentication failure to the main processor. The main processor 240 would then be unable to access the game software.
Using a co-processor to authenticate software reduces the speed necessary to run game software, compared to when a single processor handles both authentication and software execution. Also, less code is needed to perform software authentication, because software designers do not need to write programs to have the main processor both authenticate and execute the software. This frees up processing capability on the main processor, which can result in improved game play.
Referring again to the gaming network, the gaming network may use a number of network services for administration and operation. Dynamic Host Configuration Protocol (DHCP) allows central management and assignment of IP addresses within the gaming network. The dynamic assignment of IP addresses is used in one embodiment instead of statically assigned IP addresses for each network component. A DNS (domain name service) is used to translate between the domain names and the IP addresses of network components and services. DNS servers are well known in the art and are used to resolve the domain names to IP addresses on the Internet.
Similarly, Network Time Protocol (NTP) is used to synchronize time references within the network components for security and audit activities. It is important to have a consistent and synchronized clock so that the order and the timing of transactions within the gaming network can be known with reliability and certainty. Network information can be gathered centrally at a single workstation by using the Remote Monitoring (RMON) protocol. SNMP (Simple Network Management Protocol) allows network management components to remotely manage hosts on the network, thus providing scalability. In one embodiment of the gaming network, SNMPv3 is used to take advantage of embedded security mechanisms to mitigate malicious attacks made against the configuration management function. Still further, TFTP (Trivial File Transfer Protocol) is used by servers to boot or download code to network components.
In one embodiment, the network may be implemented using the IPv6 protocol designed by the IETF (Internet Engineering Task Force). When using IPv6, the network may take advantage of the Quality of Service (QoS) features available with IPv6. QoS refers to the ability of a network to provide a guaranteed level of service (i.e. transmission rate, loss rate, minimum bandwidth, packet delay, etc). QoS may be used as an additional security feature in that certain transactions may request a certain QoS as a rule or pursuant to some schedule. Any fraudulent traffic of that nature that does not request the appropriate QoS is considered an attack and appropriate quarantine and counter measures are taken.
Similarly, the Type of Service (ToS) capabilities of IPv4 may also be used in a similar manner to provide additional security cues for validation of transactions. Again, certain types of transactions may be associated with a particular specific ToS or a rotating schedule of ToS that is known by network monitors.
Accordingly, the gaming network provides for traffic confidentiality. All nodes within the network exchange information that is confidentially protected. One method for providing confidentially protected data is by using encryption. A number of encryption schemes may be used, such as an FIPS approved encryption algorithm and an NIST specified encryption mode, such as the Advanced Encryption Standard (AES).
In addition, all nodes within the gaming network apply source authentication and integrity of all traffic. A suitable message authentication mechanism may be, for example, an FIPS approved algorithm such as the Keyed-Hash Message Authentication Code (HMAC) and SHA-1. All nodes automatically drop messages that have been replayed. As noted above, replayed messages are a means of attack on network security.
Key management mechanisms should be sufficient to resist attack. In one embodiment, a 1024 bit Diffie-Hellman key exchange with a 1024 bit DSA/RSA digital signature is used to render key attacks computationally infeasible. It should be noted that the key sizes are given as examples only. Smaller or greater key size can be used in the gaming network as security recommends. The gaming network should be robust, maintaining the availability of critical services. The network should include protection against misrouting and also discard any traffic that has a source or destination outside of the network. The gaming network should also require a minimum level of authentication and assurance before permitting an additional device on the network and prevent such connection when the assurance is not provided.
Host protection and security includes secure host initialization where the host performs a self-integrity check upon power-up initialization. All operating system components that are not needed are disabled. When software patches are downloaded to the gaming network, the host verifies them. The host checks for unused IP ports and disables them prior to connecting to the gaming establishment network. When processing network traffic, any traffic not addressed to the host is dropped from the processing stack as soon as possible. In the gaming network, all service, guest, and default administrator accounts that may be part of the operating system are disabled. In one embodiment, one-time passwords and/or multi-part passwords are used for remote login, if remote login is enabled. The one-time password may itself be a multi-part password. When using a multi-part password, different trusted individuals each hold a part of the multi-part password. The entire password is required for enablement of the system. This prevents any single individual from compromising security. Moreover, all host software components are operated with the lowest privilege necessary for sufficient operation. For example, software that can operate with “user” privilege will do so, to limit its usefulness to an attacker.
Audit requirements include integrity protection of audit logs from date of creation and throughout their use. Events that are audited in an embodiment of the gaming network include account logon events (both success and failure), account management (both success and failure), directory service events (failure), logon events (success and failure), object access (failure), policy changes (success and failure), privilege use (failure), system events (success and failure), access to a host or networking device logged by user name and the time of access, and all other internal user actions. Anomalous behavior is audited and logged for purposes of evidence for law enforcement and/or attack recognition. Audit information is collected and stored in a secure manner to preserve the chain of evidence. If there is a failure of the audit system, automatic shutdown is initiated.
The gaming network is designed so that there is no single point of failure that would prevent remaining security features from operating when one is compromised. The gaming network also will continue to operate in the event of bridging to another network, such as the Internet.
Although the disclosed embodiments have been described in connection with in-cabinet devices identifying themselves to each other, it is not limited to such an application. The disclosed embodiments may be used to provide identification of any network devices by organically updating identification information periodically in Ethernet frames. In addition, the disclosed embodiments are not limited to the specific network configuration described herein. Rather, the system can work with any number of network configurations without departing from the scope and spirit of the disclosed embodiments.
It will be apparent from the foregoing that, while particular forms of the disclosed embodiments have been illustrated and described, various modifications can be made without departing from the spirit and scope of the disclosed embodiments. Accordingly, it is not intended that the disclosed embodiments be limited, except as by the appended claims.
