US20110111863A1

US20110111863A1 - Method and apparatus for securing networked gaming devices

Info

Publication number: US20110111863A1
Application number: US12/944,582
Authority: US
Inventors: Daniel Kaminsky
Original assignee: Individual
Current assignee: Individual
Priority date: 2009-11-12
Filing date: 2010-11-11
Publication date: 2011-05-12
Also published as: US20110113231A1; US20110113230A1; WO2011060190A1

Abstract

Embodiments are described for a system operating a plurality of gaming devices. A central gaming computer having a trusted node daughterboard having operational software is configured to be loaded on a gaming computer, a network coupled to the central gaming computer, and a plurality of gaming computers coupled to the network with each of the plurality of gaming computers including an operational node motherboard operable to load operational software sent from the central gaming computer to affect a change in gameplay in the gaming computer. Upon completion of desired computer processing on the operational node, the trusted node causes the operational node to reboot to remove the pre-boot data and the operating system software from the operational node such that no rewrite functions are performed on the operational node.

Description

CROSS REFERENCE TO RELATED APPLICATIONS

This application claims the benefit of U.S. Provisional Patent Application 61/281,114 entitled SYSTEM AND METHOD FOR PROVIDING SECURE VIEWING OF TRANSMITTED DATA, by Daniel Kaminsky, filed Nov. 12, 2009, the entire contents of which are incorporated herein by reference.
This application is related to the following commonly owned, co-pending United States patents and patent applications, each of which are incorporated by reference herein in their entirety:
U.S. patent application Ser. No. ______ entitled APPARATUS AND METHOD FOR SECURING AND ISOLATING OPERATIONAL NODES IN A COMPUTER NETWORK, by Daniel Kaminsky, filed Nov. 11, 2010 (Attorney Docket No. 1300.05).
U.S. patent application Ser. No. ______ entitled SYSTEM AND METHOD FOR PROVIDING SECURE RECEPTION AND VIEWING OF TRANSMITTED DATA OVER A NETWORK, by Daniel Kaminsky, filed Nov. 11, 2010 (Attorney Docket No. 1300.02).

FIELD OF THE INVENTION

The invention relates generally to network security, and more specifically, to a method and apparatus for electronic gaming devices and similar terminal machines interconnected by a secure computer network.

BACKGROUND

Computational platforms that directly process money, such as networked casino (or waging) gaming devices, automatic teller (ATM or cash) machines are becoming increasingly deployed in many areas. Such machines are vulnerable to not only physical attack, but network attack due to the nature of their use and their placement in relatively isolated and potentially dangerous locations.
The gaming industry has increased the use of electronic gaming machines to supplement the usual mechanical machines traditionally found in casinos and other similar locations. Interconnecting a plurality of gaming devices such as slot machines through a computer network to a central computer provides many advantages. One advantage of networked gaming devices is the ability to extract accounting data from the individual gaming devices as well as providing player tracking. This allows a central host computer to monitor the usage and payout, collectively known as audit data, of the individual gaming devices. This audit data includes data related to the number of coins or tokens inserted into the device, the number of times the device has been played, the amount of money paid in raises, the number and the type of jackpots paid by the machine, the number of door openings, and so on. The host computer can then compile an accounting report based on the audit data from each of the individual gaming devices. This report can then be used by management, for example, to assess the profitability of the individual gaming devices.
Player tracking, as the name indicates, involves tracking individual player usage of gaming devices. In prior art player tracking systems, the player is issued a player identification card which has encoded thereon a player identification number that uniquely identifies the player. The individual gaming devices are fitted with a card reader, into which the player inserts a player tracking card prior to playing the associated gaming device. The card reader reads the player identification number off the card and informs a central computer of the player's subsequent gaming activity. Individual player usage can then be monitored by associating certain of the audit data with the player identification numbers. This allows gaming establishments to target individual players with direct marketing techniques according to the individual's usage.
It is to be appreciated that the full power of networked gaming devices has not been completely realized. This is because as technology in the gaming industry progresses, the traditional mechanically driven reel slot machines have largely been replaced with electronic counterparts having CRT, LCD video displays or the like and gaming machines such as video slot machines and video poker machines have become the norm in casino environments. Part of the reason for this is the nearly endless variety of games that can be implemented on gaming machines utilizing advanced electronic technology. In some cases, newer gaming machines are utilizing computing architectures developed for personal computers. These video/electronic gaming advancements enable the operation of more complex games, which would not otherwise be possible on mechanical-driven gaming machines and allow the capabilities of the gaming machine to evolve with advances in the personal computing industry.
When implementing the gaming features described above on a gaming machine using architectures utilized in the personal computer industry, a number of requirements unique to the gaming industry must be considered. One such requirement is the regulation of gaming software. Typically, within a geographic area allowing gaming, i.e., a gaming jurisdiction, a regulatory body is charged with regulating the games played in the gaming jurisdiction to ensure fairness and prevent cheating. In most gaming jurisdictions there are stringent regulatory restrictions for gaming machines requiring a time consuming approval process of new gaming software and any software modifications to gaming software used on a gaming machine. A regulatory scheme also typically includes field verification of deployed gaming applications to ensure that a deployed game corresponds to the certified version of the game.
To implement the play of a game on a gaming machine, a monolithic software architecture has traditionally been used. In a monolithic software architecture, a single gaming software executable is developed. The single executable is typically burnt into an EPROM (erasable programmable read only memory) and then submitted to various gaming jurisdictions for approval. After the gaming application is approved, typically a unique checksum is determined for the gaming application stored in the EPROM for the purpose of uniquely identifying the approved version of the gaming application. A disadvantage of a monolithic programming architecture is that a single executable that works for many different applications can be quite large. For instance, gaming rules may vary from jurisdiction to jurisdiction. Thus, either a single custom executable can be developed for each jurisdiction or one large executable with additional logic can be developed that is valid in many jurisdictions. The customization process may be time consuming and inefficient. For instance, upgrading the gaming software may require developing new executables for each jurisdiction, submitting the executables for re-approval, and then replacing or reprogramming EPROMs in each gaming machine.
In contrast to the monolithic approach of software development and distribution, software architectures for use by personal computers (PCs) have moved toward an object oriented approach where different software objects may be dynamically linked together prior to or during execution to create many different combinations of executables that perform different functions. Thus, for example, to account for differences in gaming rules between different gaming jurisdictions, gaming software objects appropriate to a particular gaming jurisdiction may be linked at run-time. This is obviously simpler and more efficient than creating a single different executable for each jurisdiction. Also, object oriented software architectures simplify the process of upgrading software since a software object, which usually represents only a small portion of the software, may be upgraded rather than the entire software.
Another disadvantage of the monolithic architecture approach relates to the logistics of distributing gaming applications. In present systems, because each gaming application for each gaming machine typically is embodied in a separate memory device, i.e., an EPROM, these EPROMs must be transported from the gaming application provider, to the gaming venues, e.g., casinos, and manually installed in each of the hundreds of gaming machines at each venue. The amount of resources consumed by this process is exacerbated by the fact that many new games are introduced each year.
Unfortunately, single venue gaming networks still do not adequately address the logistical issues associated with the distribution of gaming applications from the gaming application provider to the gaming venues, or the complications associated with complying with a multiplicity of regulatory schemes. Further, due to the vulnerability presented by a network linking gaming machines which could compromise the networked gaming machines, there is a need for techniques by which the distribution of gaming applications and the networking of gaming machines may be made more efficient and secure.
The disadvantages described above with respect to gaming machines are also present in many other similar networked terminal-type computing platforms, such as ATMs, point-of-sale terminals, ticket dispensing machines, and the like.

SUMMARY OF THE INVENTION

A system for operating a plurality of gaming devices comprises a central gaming computer having a trusted node daughterboard having operational software configured to be loaded on a gaming computer, a network coupled to the central gaming computer, and a plurality of gaming computers coupled to the network with each of the plurality of gaming computers including an operational node motherboard operable to load operational software sent from the central gaming computer to affect a change in gameplay in the gaming computer. The trusted node of the central gaming computer includes pre-boot data configured to be loaded on an operational node of a gaming computer. A method for remotely controlling one of a plurality of gaming computers from a central gaming computer with each gaming computer having an operational node and the central gaming computer having a trusted node connected via a network to an operational node of each gaming computer comprises: sending a power up signal from the trusted node in the central gaming computer to a operational node in one of the plurality of gaming computers when it is desired to affect a change in a parameter of game play in the gaming computer; requesting from the central gaming computer trusted node pre-boot data from an operational node in an gaming computer; and sending pre-boot data from the central computer trusted node to a gaming device operational node.
After an operational program or other attachment (e.g., e-mail message) has been accessed, opened or executed by the operational node motherboard and made accessible to an intended recipient, a power-off signal is sent from the trusted node daughterboard to the operational node motherboard to wipe clean any malware that may have comprised it from opening the previous data file. The operational node motherboard is then in an off and clean state awaiting another execution command from a trusted node daughterboard.

BRIEF DESCRIPTION OF THE DRAWINGS

In the following drawings like reference numbers are used to refer to like elements. Although the following figures depict various examples, the one or more implementations are not limited to the examples depicted in the figures.

FIG. 1 illustrates an example general-purpose computing system in which embodiments of the present invention may be implemented.

FIG. 2 illustrates an embodiment of a split brain design of the present invention in which a trusted daughterboard is connected to a management network operative to manage an operational motherboard.

FIG. 3 illustrates a network implementation of the split brain computer system of FIG. 2 under an embodiment.

FIG. 4 represents an example cloud computing system that implements embodiments of the split brain system of FIG. 3.

FIG. 5 illustrates a system that implements embodiments of the trusted node/operational node architecture in a network of game machines.

FIG. 6 illustrates an example of a game device coupled to a central computer for the network of FIG. 5, under an embodiment.

FIG. 7 is a flow diagram that illustrates the power cycle and bootstrap processing acts performed to remove potential malware infections, under an embodiment.

FIG. 8 is a timeline illustrating the elimination of a malware infection by the process of FIG. 7, under an embodiment.

INCORPORATION BY REFERENCE

All patents and patent applications that are referenced herein are hereby incorporated by reference in their entirety.

DETAILED DESCRIPTION

Embodiments of the present invention broadly relate to problems associated with persistent data storage in computing nodes. For instance, such storage can take place in: on-board hard drives, solid state discs (SSD), motherboard BIOS, network card firmware and microcontroller firmware. Such persistent storage provides opportunities for malware to reside in one or more of these components, and, once stored in any one of these components, the operability of the entire associated system is significantly compromised due to the presence of such malware.
For purposes of the present description, the term “malware” is to be understood to represent malicious software, which is software designed to infiltrate or damage a computer system without owner permission. The expression is a general term used by computer professionals to mean a variety of forms of hostile, intrusive, or annoying software or program code. The term “computer virus” is sometimes used as a catch-all phrase to include all types of malware, including viruses. In general, software is considered malware based on the perceived intent of the creator rather than any particular features, and may include computer viruses, worms, trojan horses, most rootkits (a software system that consists of a program or combination of several programs designed to hide or obscure the fact that a system has been compromised), spyware, dishonest adware, crimeware and other malicious and unwanted software. Malware does not necessarily include defective software, which is software that has a legitimate purpose but contains harmful bugs.
It is to be appreciated that while the illustrated embodiments of the present invention may be discussed in reference to “cloud computing”, the present invention system and method is not to be understood to be limited thereto as it is to be understood to encompass all computer networks and environments that may be exposed to malware.
FIG. 1 depicts an example general-purpose computing system in which embodiments of the present invention may be implemented. As shown in FIG. 1, computer system 100 generally comprises at least one processor 102, or processing unit or plurality of processors, memory 104, at least one input device 106 and at least one output device 108, coupled together via a bus or group of buses 110. In certain embodiments, input device 106 and output device 108 could be the same device. An interface 112 can also be provided for coupling the processing system 100 to one or more peripheral devices, for example interface 112 could be a PCI (peripheral component interconnect) card or PC card. At least one storage device 114 which houses at least one database 116 can also be provided. The memory 104 can be any form of memory device, for example, volatile or non-volatile memory, solid state storage devices, magnetic devices, etc. The processor 102 could comprise more than one distinct processing device, for example to handle different functions within the processing system 100. Input device 106 receives input data 118 and can comprise, for example, a keyboard, a pointer device such as a pen-like device or a mouse, audio receiving device for voice controlled activation such as a microphone, data receiver or antenna such as a modem or wireless data adaptor, data acquisition card, and so on. Input data 118 could come from different sources, for example keyboard instructions in conjunction with data received via a network. Output device 108 produces or generates output data 120 and can comprise, for example, a display device or monitor in which case output data 120 is visual, a printer in which case output data 120 is printed, a port for example a USB port, a peripheral component adaptor, a data transmitter or antenna such as a modem or wireless network adaptor, and so on. Output data 120 could be distinct and derived from different output devices, for example a visual display on a monitor in conjunction with data transmitted to a network. A user could view data output, or an interpretation of the data output, on an external device, such as a display monitor or a printer. The storage device 114 can be any form of data or information storage means, for example, volatile or non-volatile memory, solid state storage devices, magnetic devices, and the like.
In use, the processing system 100 is adapted to allow data or information to be stored in and/or retrieved from, via wired or wireless communication means, at least one database 116. The interface 112 may allow wired and/or wireless communication between the processing unit 102 and peripheral components that may serve a specialized purpose. Preferably, the processor 102 receives instructions as input data 118 via input device 106 and can display processed results or other output to a user by utilizing output device 108. More than one input device 106 and/or output device 108 can be provided. It should be appreciated that the processing system 100 may be any form of terminal, server, specialized hardware, or the like.
It is to be appreciated that the processing system 100 may be a part of a networked communications system. Processing system 100 could connect to a network, for example the Internet or a WAN. Input data 118 and output data 120 could be communicated to other devices via the network. The transfer of information and/or data over the network can be achieved using wired communications means or wireless communications means. A server can facilitate the transfer of data between the network and one or more databases. A server and one or more databases provide an example of an information source.
Thus, the processing computing system environment 100 illustrated in FIG. 1 may operate in a networked environment using logical connections to one or more remote computers. The remote computer may be a personal computer, a server, a router, a network PC (personal computer), a peer device, or other common network node, and typically includes many or all of the elements described above. The remote computer may also be embodied in a mobile processing or communication device, such as a laptop/notebook computer, PDA (personal digital assistant), smartphone, or other similar processing device.
It is to be further appreciated that the logical connections depicted in FIG. 1 include a local area network (LAN) and a wide area network (WAN), but may also include other networks such as a personal area network (PAN). Such networking environments are commonplace in offices, enterprise-wide computer networks, intranets, and the Internet. For instance, when used in a LAN networking environment, the computing system environment 100 is connected to the LAN through a network interface or adapter. When used in a WAN networking environment, the computing system environment typically includes a modem or other means for establishing communications over the WAN, such as the Internet. The modem, which may be internal or external, may be connected to a system bus via a user input interface, or via another appropriate mechanism. In a networked environment, program modules depicted relative to the computing system environment 100, or portions thereof, may be stored in a remote memory storage device. It is to be appreciated that the illustrated network connections of FIG. 1 are exemplary and other means of establishing a communications link between multiple computers may be used.
FIG. 1 is intended to provide a brief, general description of an illustrative and/or suitable exemplary environment in which embodiments of the below described present invention may be implemented. FIG. 1 is an example of a suitable environment and is not intended to suggest any limitation as to the structure, scope of use, or functionality of an embodiment of the present invention. A particular environment should not be interpreted as having any dependency or requirement relating to any one or combination of components illustrated in an exemplary operating environment. For example, in certain instances, one or more elements of an environment may be deemed not necessary and omitted. In other instances, one or more other elements may be deemed necessary and added.
In the description that follows, certain embodiments may be described with reference to acts and symbolic representations of operations that are performed by one or more computing devices, such as the computing system environment 100 of FIG. 1. As such, it will be understood that such acts and operations, which are at times referred to as being computer-implemented or computer-executed, include the manipulation by the processor of the computer of electrical signals representing data in a structured form. This manipulation transforms the data or maintains them at locations in the memory system of the computer, which reconfigures or otherwise alters the operation of the computer in a manner understood by those skilled in the art. The data structures in which data is maintained are physical locations of the memory that have particular properties defined by the format of the data. However, while an embodiment is being described in the foregoing context, it is not meant to be limiting as those of skill in the art will appreciate that the acts and operations described hereinafter may also be implemented in hardware.
Embodiments may be implemented with numerous other general-purpose or special-purpose computing devices and computing system environments or configurations. Examples of well-known computing systems, environments, and configurations that may be suitable for use with an embodiment include, but are not limited to, personal computers, handheld or laptop devices, personal digital assistants, smartphones, multiprocessor systems, microprocessor-based systems, set top boxes, programmable consumer electronics, network, minicomputers, server computers, game server computers, web server computers, mainframe computers, and distributed computing environments that include any of the above systems or devices.
Embodiments may be described in a general context of computer-executable instructions, such as program modules, being executed by a computer. Generally, program modules include routines, programs, objects, components, data structures, etc., that perform particular tasks or implement particular abstract data types. An embodiment may also be practiced in a distributed computing environment where tasks are performed by remote processing devices that are linked through a communications network. In a distributed computing environment, program modules may be located in both local and remote computer storage media including memory storage devices.
Embodiments of the computing system environment 100 of FIG. 1 are used to implement aspects of a computer architecture, sometimes referred to as a “split brain” design in which a daughterboard is used to manage and isolate an operational motherboard on a networked computer during the transfer of data over the network. FIG. 2 illustrates an embodiment of a split brain design of the present invention in which a trusted daughterboard 200 (trusted node) is connected to a management network operative to manage an operational motherboard 204 (operational node), which is preferably connected to an operational network 206.
To reduce vulnerability to malware attacks it is advantageous to minimize as much as possible, the amount of persistent storage on an operational node. However, eliminating persistent storage from an operational node to obviate malware infection requires novel solutions not found or taught in the prior art. It is generally understood that a purpose of having numerous components on an operational node retain data across reboot is to enable basic functioning of the operational node. For instance, typically microcontrollers do not function properly, or at all, without any firmware. Embodiments of the present invention eliminate persistent storage from an operational node by deploying, preferably in ROM (Read Only Memory), “stub firmware” that either retrieves or receives its normal boot state from a centralized buffer on the operational node. As shown in FIG. 2, a dedicated Gigabit Ethernet interface 210 is employed to provide such a centralized buffer with its state information, from which the system may retrieve fresh copies of its motherboard BIOS, network card firmware, and microcontroller firmware from the trusted node during a pre-boot sequence. It is noted that a Gigabit Ethernet interface (GigE) is generally preferred for enabling connectivity between a trusted node and operational nodes because a GigE interface does not discriminate between the data packets sent to it as it has no inherent connectivity. In general, GigE refers to a transmission standard as defined by IEEE 802.3-2008. It should be noted, however, that other similar transmission standards and corresponding interfaces can also be used.
To ensure further security for the computing system environment, the power on/off commands are preferably implemented through dedicated, maximally-isolated hardware, as opposed to a conventional IPMI (Intelligent Platform Management Interface) BMC (baseboard management controller) mechanism. Such an arrangement prevents the canonical attack of a reboot/refresh cycle being suppressed within compromised hardware, which could pretend to have loaded clean firmware on an operational node.
For the system of FIG. 2, when properly configured it is virtually impossible to permanently write any data to any persistent storage source or component on the operational node 204 without administrator consent. This includes all BIOS 205, which represents boot firmware that is designed to be the first code run by a computer when powered on. The initial function of the BIOS 205 is to identify, test, and initialize system devices such as the video display card, hard disk, other disk sources and hardware. Typically, this process places the computer into a known state, so that any software stored on compatible media can be loaded, executed, and given control of the computer. This process is commonly known as booting or booting up, and otherwise known as bootstrapping. BIOS programs are typically stored on a chip and are built to work with various devices that make up the complementary chipset of the overall system. They provide a small library of basic input/output functions that can be called to operate and control the peripherals such as the keyboard, text display functions and so forth.
For the system of FIG. 2, it may still be possible to permanently write storage data on the SSD 208 of the operational node 204, since the SSD 208 may be considered temporary storage. The operational node 204 may also include a standard VGA output (wherein the VESA-DDC pins are preferably blocked), USB ports, a GigE interfacing network 210 and hardware virtualization support.
The illustrated embodiment of FIG. 2 of the present invention is operative such that the trusted node 200, via GigE 210, manages the content of all persistent data stores (including the SSD 208) present on the operational node 204. Additionally, the trusted node 200 is configured and operative to power on and off the operational node 204, preferably via the GigE interfacing connection 210, whereby it is virtually impossible to cause unintended power issues for the trusted node 200 from the operational node 204. With regard to the power management of operational nodes, the system architecture illustrated in FIG. 2 renders it virtually impossible for an operational node to adversely impact power flow to trusted nodes.
As shown in FIG. 2, the trusted node 200 is coupled to the operational node 204 through a monitor component 202. The monitor 202 is a multiport switch that may include some degree of processing capability or circuit logic to perform tasks such as packet analysis. The monitor can be configured to detect power messages and other out-of-band critical messages from the trusted node 200 and deliver them to appropriate points on the operational node 204. It can also be configured to see frames transmitted from the operational node 204 to the trusted node 200 and perform any appropriate MAC (media access control) 209 filtering. For the embodiment of FIG. 2, the monitor component 202 is also functionally coupled to the power circuit (on/off switch) 211 and boot store 213 of the operational node 204. The boot store 213 is used to control the net firmware component 215 and any micro-controller units 217 that may be present on the operational node 204.
In an embodiment, the trusted node 200 is configured and operational to disable or fully wipe (delete all storage) on the SSD 208 of the operational node 204. The trusted node 200 is preferably operational to reset the operational node 204 in a relatively brief time period (e.g., approximately 15 seconds or less) when the purpose of use for the operational node 204 has been completed.
The illustrated embodiment of FIG. 2, may be further configured such that the trusted node 200 is provided support for a conventional x86 processor, PS/2 keyboard and mouse peripheral components. It is noted that in accordance with the present invention, there is preferably no actual persistent storage on the operational node 204 aside from the SSD 208. Thus, to accomplish this, rather than blocking writes, a “pre-boot” load of firmware may be implemented. Also, in accordance with embodiments, the maximum performance-per-watt on the central processing unit (CPU) for the operational node 204 is accomplished along with the provision of sufficient RAM storage parameters. Further, support is provided for a hardware “freeze/resume” command, from the trusted node 200 to the operational node 204 and for resetting the operational node 204 to a known good state in preferably less than one second when desired. Additionally, with respect to actual implementation details, a USB (Universal Serial Bus) boot structure is preferably provided on the trusted node 200, and instead of one node per 1U space, the illustrated embodiment of FIG. 2 of the present invention preferably utilizes a blade architecture with a locked down backplane.
In general, the daughterboard and motherboard of the split brain architecture can be embodied in separate component boards that are coupled to one another through physical connectors, cables, ribbon cables, bus wiring, or other connection means as is known in the electrical manufacturing art. For example, the daughterboard may be embodied in a physical circuit board that is inserted in the motherboard by means of a physical interface connector that physically and electrically couples the two boards. The boards may also instead be coupled to one another through a ribbon cable or bus wiring connection that provides an electrical connection, but not a rigid physical connection. In alternative embodiment, the daughterboard in logic circuitry that is implemented in a device or component that is mounted on a motherboard, such as through a chip carrier or similar mechanism. In yet a further alternative embodiment, the daughterboard and motherboard functions may be provided in different circuits on the same board, or on a hybrid component board.
In an embodiment, the system of FIG. 2 may utilize an IP KVM structure on the trusted node 200, whereby video, keyboard, and mouse commands are routed back to the trusted node 200 as opposed to being routed back to a traditional IP KVM hardware component. The IP KVM (Internet Protocol, Keyboard/Video/Mouse) component or switch is generally a hardware device that enables a user to control from a single keyboard, video monitor and/or mouse, the keyboards, video monitors and mouse components associated with multiple computers.
The illustrated embodiment of FIG. 2 of the present invention may be yet further configured to include a hardware key cycler for SSD 208, which irrevocably destroys encryption keys for SSD content between boots. An IP firewall may also be provided in front of the operational motherboard GigE interfacing port 210. Also, the functionality of having the ability to monitor IP traffic on the operational nodes GigE interfacing port 210 from the trusted node 200 may be provided as well as the ability to Remote Direct Memory Access (RDMA) from the trusted node 200 to the operational node 204 via a private GigE interfacing link. In general, RDMA is a direct memory access from the memory of one computer into that of another without involving either computer's operating systems. This permits high-throughput, low-latency networking, which is especially useful in massively parallel computer clusters. Typically, RDMA supports zero-copy networking by enabling the network adapter to transfer data directly to or from application memory, eliminating the need to copy data between application memory and the data buffers in the operating system. Such transfers require no work to be done by CPUs, caches, or context switches, and transfers continue in parallel with other system operations. When an application performs an RDMA Read or Write request, the application data is delivered directly to the network, reducing latency and enabling fast message transfer. Thus, by providing the ability to RDMA from the trusted node 200 to the operational node 204 via a private GigE interface, it is virtually impossible to permanently damage (corrupt) the operational node 204 with any external electrical manipulation/illegal read or write commands.
FIG. 3 illustrates a network implementation of the split brain computer system of FIG. 2 under an embodiment. As shown in FIG. 3, a trusted node daughterboard 300 is coupled to a trusted switch 302, which in turn is coupled to an operational node motherboard 304. Trusted node 302 is also shown coupled to a trusted network 301. Preferably, trusted switch 302 is a Gigabit Ethernet switch having Gigabit Ethernet connections to the trusted node 300 and operational node 304. It is to be appreciated that trusted switch 302 may be coupled to a plurality of operational node motherboards, such as nodes 306 and 308. Trusted switch 302 is also preferably coupled to an IP KVM component 310, which in turn is coupled to the operational node 304. Operational node 304 may also be coupled to an operational switch 312.
The IP KVM 310 is preferably operational to provide input commands (e.g., keyboard and mouse) from trusted node 300 to operational node 304, through trusted switch 302. Additionally, IP KVM 310 is operational to provide video output information from operational node 304 to trusted node 300 also through trusted switch 302.
As mentioned above with reference to FIG. 2, trusted node 300 controls the on/off functionality of operational node 304 as well as provides the preboot data and operating system software to the data storage components found on operational node 300. Additionally, firewalling of the IP packets sent from the operational node 302 may be provided for further security if so desired.
The embodiment of FIG. 3 provides the fundamental advantages of preventing unauthorized hardware writes while providing a fully manageable cloud node (i.e., operational motherboard/node) while at all times preventing the cloud management layer from being corrupted with malware or other malicious actions. This advantage is accomplished by providing the illustrated split brain architecture in which a primary operational motherboard/node is operatively coupled to a secondary trusted daughterboard/node, in which the purpose of the primary operational motherboard is to provide the maximum performance per watt, while always being able to be reset into a known-good state. The purpose of the secondary trusted daughterboard/node is to store and manage that state of the operational motherboard/node, preferably using information bootstrapped from the internet cloud.
Using present described embodiments, a computing cloud may be set up with both trusted and operational networks/nodes, exposing two GigE interfacing ports to each node. Preferably one GigE port is connected to the trusted node 300, containing: an x86 operating environment, a BIOS capable of netbooting, persistent storage for trusted state and bootstrapping data and a connection to the operational motherboard/node 304. Each operational motherboard/node in the split brain architecture is a relatively standard x86 motherboard, tuned to offer maximum performance-per-watt having a connection to the trusted daughterboard/node with an on-board video out (having preferably the VESA-DDC disabled). Preferably also provided are a PS/2 keyboard and mouse and IP KVM access preferably implemented with either a standard rackmount IP KVM configured to operate over a PS/2 or an IP KVM integration with the trusted daughterboard/node. Also preferably additionally provided is a temporary SSD, which either 1) has a hardware key cycler, that renders content from a previous boot unreadable to future ones (thus obviating the need to clear the drive between boots), or 2) requires software to implement the this key cycler functionality. Further provided is a GigE connection to the operational network, hardware virtualization support in the CPU, sufficient RAM and control over unauthorized hardware writes.
It is to be appreciated that while some components on an operational node do not have persistent storage capabilities, many do thus causing the PC components on the operational node to be susceptible to malware attacks. For instance, many components have internal firmware in flash, especially when microcontrollers are taken into account. Thus, an unauthorized write to this flash memory can create a permanent, persistent infection that is difficult, or impossible, to clean. Therefore, in accordance with certain embodiments, there are four strategies that can manage these flash memory components. The first is to replace the flash ROM on the operational node with centralized RAM that is populated by the secure daughterboard in a pre-boot sequence. The second is to replace the flash ROM on the operational node with fixed ROM. This may sacrifice some degree of updatability on components, however such components may actually only be rarely patched, if at all. The third strategy is to manage the flash ROM from the daughterboard, using hardware control pins to lock access to the flash ROM unless the trusted daughterboard explicitly enables writeability. The fourth strategy is to manage the flash ROM with code in the firmware that only allows updates that match specific cryptographic assertions.
Embodiments of the present invention also include mechanisms to prevent corruption or attack on the trusted node. There are two methods to establish connectivity between the trusted node (the daughterboard) and the operational node (the motherboard) to prevent the backflow of information from the operational node to the trusted node to prevent an operational motherboard/node under the control of the attacker from corrupting the trusted network. A first method is the implementation of a relay approach whereby relays are set up to make certain components (e.g., RAM, SSD) appear in one environment or the other, but not both. With the relay method, pre-boot data is copied onto various persistent stores that are then swapped into the operational core. This does not require any specialized software or firmware, nor any parsing on the trusted node of content from the operational node.
The second method is a networking approach whereby a private GigE connection is established between the motherboard and the daughterboard in which the motherboard loads content via the daughterboard. In this networking approach, the backflow of information is prevented from the operational node to the trusted node in which the trusted node can read and write arbitrary memory of the guest, which can be advantageous. For instance, provided is the ability to enable a rapidly cycled filter for untrusted content preferably providing the functionality to snapshot and return to a known good state the operational motherboard rapidly (such as at least as fast as a VMware restore operation). Therefore, regardless how the bulk state is managed between the trusted and operational nodes, preferably at least one set of control pins will be required; for example, the trusted daughterboard/node will be configured and operative to power on and power off the operational motherboard.
It is to be appreciated that further hardware may be provided to limit the amount of firewalling on the IP packets originating from operational node. In particular, hardware may be provided to enable a trusted node to declare an IP, a set of IPs, or an IP range, for the operational nodes that the GigE interface is to use.
Embodiments of the trusted node/operational node split brain system can be implemented in wide variety of operational environments that implement or control LAN or WAN communications. A typical operational implementation may be the deployment of multiple split brain operational nodes in a rack mount system that includes several other network and controller boards. Such a system might comprise a Trusted Manager board, an IP KVM board, an L3 switch board, and a number of operational node boards each implementing a split brain architecture as described above. The L3 (Layer 3) switch operates as a network router and can be configured to inspect incoming packets and make dynamic routing decisions based on the source and destination addresses.
FIG. 4 represents an example cloud computing system that implements embodiments of the split brain system of FIG. 3. As shown in FIG. 4, a trusted net 402 is coupled to a trusted manager 404, which in turn is coupled to a trusted switch 406. Trusted switch 406 is coupled to an IP KVM controller 408. Both trusted switch 406 and IP KVM 408 are each coupled to operational nodes 410, 412 and 414. An operational switch 416 is also coupled to operational nodes 410-414, and to trusted net 402.
A normal method of operation of system 400 is as follows: each operational node 410-414 is in an off state but is listening for Wake-On LAN packets from a trusted switch 406. When the Internet cloud 402 desires to activate an operational node 410-414, it sends a packet to the node's management interface (trusted manager 402) instructing it to enter pre-boot mode. A small computational environment is activated on the selected operational node 410-414, which retrieves a full copy of the boot store from the trusted manager 404 via the trusted switch 406 so as to prevent operational nodes 410-414 from spoofing the IP/MAC of the trusted manager 404. Preferably, all components in the activated operational node 410-414 receive or retrieve their packets of the boot store from the trusted manager 404 wherein RAM is preferably wiped clean to avoid malware attacks. Next, the activated operational node boots up normally, and immediately netboots off via a coupled management interface. The management interface boots a stub operating system, which populates the SSD of the activated operational node with the required software and data. Afterwards, the stub operating system of the activated operational node declares itself loaded, and sends the lock code to the SSD so the stub operating system can now boot from the write-locked SSD of the activated operational node. After a predetermined passage of time, an administrator administers the cloud node by connecting the activated operational node to the IP KVM 408, which preferably has unidirectional video coming into it and a unidirectional PS/2 keyboard and mouse (as described above). Once the internet cloud 402 wishes to repurpose the activated operational node 410-414, preferably any soft shutdown tasks are executed via normal software layers, and then a hard power off packet is sent. Once the hard power off message is received, the operational node is powered down at the hardware level. Since there is no persistent data that an attacker could have changed, anything malware on the operational node is erased.
Embodiments of the present invention are applicable to a number of different network based applications involving transmission of data among networked computers. One of the most popular network applications, and one of the most dangerous with respect to malware transmission and propagation, is the transmission of electronic mail through LAN and WAN systems.

Gaming Machine Application

FIG. 5 illustrates a system that implements embodiments of the trusted node/operational node architecture in a network of game machines or gaming devices. As shown in FIG. 5, system 10 includes one or more central computer systems 18. Each central gaming computer system 18 supports up to a defined maximum number of gaming devices. As described further below, each central computer system 18 includes a trusted node motherboard 505 connected via network 20 to each operational node motherboard 510-514 provided in each gaming device 12-16.
It is to be appreciated the system 10 supports a multiplicity of various gaming devices. For illustrative purposes, the gaming devices 12-16 depicted in FIG. 5 may be the type having a pull handle for initiating a game, e.g., slot machines. However, the invention is not limited to such gaming devices. For instance, the gaming devices shown in FIG. 1. can also be gaming tables or push button operated machines as well, e.g., video poker. As will be described hereinafter, the system supports any gaming device providing traditional discrete connections, e.g., coins-in, coins-out, etc., as well as those having serial interfaces, as described below.
Each central computer 18 is responsible for monitoring the activity level of the corresponding gaming devices connected thereto and issuing commands to the associated gaming devices to reconfigure their game play and payout schedules during certain bonusing events. Preferably, the central computer 18 issues status requests to each of the individual gaming devices to determine the activity level of each.
The system of FIG. 5 implements computing devices, such as those illustrated in FIG. 1 and split brain trusted node/operational node systems, such as those illustrated in FIGS. 2 and 3. System 10 is configured to monitor, control, and reconfigure a plurality of gaming devices or machines 12-16 each including an operational node motherboard 510-514. The system includes at least the following capabilities: remote game play reconfiguration, accounting data extraction, integrated player tracking, cashless play and the like. Remote game play reconfiguration includes sending a reconfiguration command from a central host computer to one or more of the gaming devices 12-16. The gaming devices, on receiving a reconfiguration command, will reconfigure its game play in accordance with the reconfiguration command.
System 10, according to the invention, also implements a variety of bonusing events through a reconfiguration process. These bonusing events include: a multiple jackpot wherein the gaming device reconfigures its payout to be a multiple of its default payout schedule; a bonus jackpot wherein the gaming device reconfigures its payout schedule to payout an additional bonus amount when certain conditions are met; and a progressive jackpot wherein two or more gaming devices are combined in a progressive jackpot having a progressive jackpot payout schedule.
System 10 further provides for integrated player tracking and accounting data extraction. Unlike prior art systems that use disparate systems for player tracking and accounting data extraction, the system 10 provides for player tracking and accounting data extraction over the same network. The player tracking, according to the invention, allows the casino to run certain promotional events. The integrated player tracking and accounting data extraction also allows the system to support cashless play wherein a credit is given to a player over the network.
FIG. 6 illustrates an example of a game device coupled to a central computer for the network of FIG. 5, under an embodiment. As shown in system 600, a gaming device 602 includes a game engine 614 comprising logic board, software and other components required to execute game software. The game engine 614 is protected by a physical security layer 616 and access certain devices associated with the gaming device, such as output devices 618 including monitors, lights, buzzers, speakers, and the like. The game engine 614 can receive user input through one or more input devices 620 including physical buttons, levers, cameras, on-screen or touchscreen input, and other similar input means.
In an embodiment, the gaming device 602 is coupled over a network link 610 to a central computer. In a typical network implementation, the network link 610 may be an untrusted link. A communication port 612 on the gaming device 602 may include an encryption engine to facilitate the communication of encrypted data over link 610 to overcome the vulnerabilities inherent in an untrusted link. Likewise, the communication port 608 in central computer that maintains central store 606 includes a compatible encryption engine to communicate with the gaming device 602.
The central computer of system 600 includes a central store 606 that provides the source of firmware for the gaming device operational node. The central store 606 is protected by a physical security layer 604. In a typical implementation, the central store is kept in a physically secure location, such as a safe or other similar facility.
In an embodiment, each gaming device 12-16 of FIG. 5 implements a trusted node and operational node system illustrated in FIG. 3. With respect to the gaming device application, the illustrated embodiment of FIG. 3 is operative such that the trusted node 505, via GigE 210, manages the content of all persistent data stores (including the SSD 208) present on an operational node motherboard 510-514 respectively provided in each gaming device 12-16. Additionally, the trusted node 505 of the central gaming computer system 18 is configured and operative to power on and off an operational node 510-514, preferably via the GigE interfacing connection 210, whereby it is virtually impossible to cause unintended power issues for the trusted node 505 from each operational node 510-514. It is to be appreciated that with regards to power management of operational nodes, the present invention renders it virtually impossible for an operational node to adversely impact power flow to the trusted nodes.
Additionally, the trusted node 505 may be configured and operational to disable or fully wipe (delete all storage) on the SSD 208 of each operational node motherboard 510-514 in each gaming device 12-16. The trusted node 505 is preferably operational to reset each operational node 510-514 (as will be further discussed below) in a time frame of approximately 15 seconds or less when the purpose of use for such an operational node 510-514 has been exhausted. It is noted that with gaming machines, it is particularly important that the operational node motherboard 510-514 provided in each gaming device 12-16 quickly resets as it is highly undesirable to have a gaming machine inoperable by a gambler while it is resetting.
The illustrated embodiment of FIG. 3, may be further configured such that the trusted node 505 in central gaming system computer system 18 is provided support for a conventional x86 processor, PS/2 keyboard and mouse peripheral components. It is noted that in accordance with the present invention, there is preferably no actual persistent storage on an operational node 510-514 motherboard provided in each gaming device 12-16 aside from the SSD 208. Thus, to accomplish this, rather than blocking writes, the present invention implements a pre-boot load of firmware. Also, in accordance of the present invention, maximum performance-per-watt on the CPU for an operational node 510-514 is accomplished along with the provision of sufficient RAM storage parameters. Further, support is provided for a hardware freeze/resume command, from the trusted node 505 in the central gaming computer system 18 to an operational node 510-514 and for resetting an operational node 510-514 provided in a gaming device 12-16 to a known good state in preferably less than one second when desired.
In an embodiment, each gaming device 12-16 implements a trusted node and operational node system illustrated in FIG. 4. With reference to FIG. 4 and FIG. 5, illustrated is a trusted node daughterboard 505 provided in gaming central computer system 18 coupled to a trusted switch 302, which in turn is coupled to an operational node motherboard 510-514 provided in each gaming device 12-16. Trusted node 505 is also shown coupled to a trusted network 20. Preferably, trusted switch 302 is a Gigabit Ethernet switch having Gigabit Ethernet connections to the trusted node 505 in the gaming central computer system 18 and each operational node 510-514 provided in each gaming device 12-16. It is to be appreciated that trusted switch 302 may be coupled to a plurality of operational node motherboards each respectively provided in a gaming device, such as nodes 512 and 514. Trusted switch 302 is also preferably coupled to an IP KVM component 310, which in turn is coupled to an operational node 510. Each operational node 510-514 may also be coupled to an operational switch 312.
IP KVM 310 is preferably operational to provide input commands (e.g., keyboard and mouse) from the trusted node 505 in the gaming central computer system 18 to an operational node 510-514 provided in a gaming device 12-16, via trusted switch 302. Additionally, IP KVM 310 is operational to provide video output information from an operational node 510-514 provided in a gaming device 12-16 to the trusted node 505 in the gaming central computer system 18, again preferably via trusted switch 302.
As mentioned above with reference to FIG. 3, the trusted node 505 in the gaming central computer system 18 controls the on/off functionality of each operational node 510-514 provided in each gaming device 12-16 as well as provides the preboot data and operating system software to the data storage components found on an operational node 510-514 in each gaming device 12-16. Additionally, firewalling of the IP packets sent from each operational node 510-514 may be provided for further security if so desired.
It is to be appreciated that with the embodiments, two fundamental advantages include preventing unauthorized hardware writes in each gaming device while providing a fully manageable network node (i.e., operational motherboard/node) while at all times preventing the management offered by the gaming central computer system 18 from being corrupted with malware or other malicious actions.
As discussed above, one way to accomplish this is by providing the split brain architecture in which a primary operational motherboard/node 510-514 is provided in each gaming device 12-16 which is operatively coupled to a secondary trusted daughterboard/node provided in the central gaming computer system 18 wherein the purpose of the primary operational motherboard in each gaming device is to provide the maximum performance per watt, while always being able to be reset into a known-good state. The purpose of the secondary trusted daughterboard/node 505 in the gaming central computer system 18 is to store and manage that state of the operational motherboard/node in each gaming device, using bootstrapped information.
With respect to the embodiments illustrated and described above, description will now turn to its operational use with reference to an example casino gaming computing system illustrated in FIGS. 2-6. With returning reference to the example embodiment of FIG. 3, illustrated is a trusted node 505 of the central computer gaming system 18 coupled to a trusted manager, which in turn is coupled to a trusted switch. Trusted switch (e.g., switch 302 of FIG. 3) is preferably coupled to each operational node 510-514 of each gaming device 12-16. It is noted in an alternative arrangement of the present illustrated embodiment, trusted switch 302 is connected to an IP KVM controller wherein both trusted switch 302 and the IP KVM controller are each coupled to operational nodes 510, 512 and 514 each associated with a respective gaming device 12, 14 and 16.
Preferably, the method of operation performed is as follows: each operational node 510-514 of a respective gaming device 12-16 is in an off state listening for Wake-On LAN packets from a trusted switch. When interaction between the central gaming system 18 a gaming device 12-16 is desired for a purpose such as adjusting a parameter of its gameplay (payouts, actual game being played or other like interactive services), the trusted node 505 of the central gaming computer system 18 preferably sends a packet to the node's management interface of the selected gaming device 12-16 instructing it to enter pre-boot mode. A small computational environment is activated on the selected operational node 510-514, which preferably retrieves a full copy of the boot store from the trusted manager via the trusted switch so as to prevent operational nodes 510-514 from spoofing the IP/MAC of the trusted manager. Preferably, all components in the activated operational node 510-514 of a respective gaming device 12-16 receive or retrieve their packets of the boot store from the trusted manager wherein RAM is preferably wiped clean to avoid malware attacks.
Next, the activated operational node boots up normally, and preferably netboots off via a coupled management interface. The management interface boots a stub operating system, which populates the SSD of the activated operational node with the required software and data. Afterwards, the stub operating system of the activated operational node declares itself loaded, and sends the lock code to the SSD so the stub operating system can now boot from the write-locked SSD of the activated operational node. After a predetermined passage of time, an administrator administers the network by connecting the activated operational node to the trusted switch 506.
Once the central gaming computer system 18 (via trusted node 505) wishes to repurpose an activated operational node 510-514 of an associated gaming device 12-16, preferably any soft shutdown tasks are executed through normal software layers, and then a hard power off packet is sent. Once the hard power off message is received, the operational node is powered down at the hardware level. Since there is no persistent data that an attacker could have changed, anything bad (malware) on the operational node must have been erased therefrom.
FIG. 7 is a flow diagram that illustrates the power cycle and bootstrap processing acts performed to remove potential malware infections in a game machine application or other similar application, under an embodiment. FIG. 8 is a timeline illustrating the elimination of a malware infection by the process of FIG. 7, under an embodiment. As shown in FIG. 7, the operational node is initially in an off state 702, a firmware bootstrap process 704 turns the operational node on 708 and starts a bulk storage bootstrap process 706. After the bulk storage bootstrap process is complete, the operational node resets and goes into the power off state 702. During the flow process of FIG. 7, the operational node according to embodiments can be used to receive updates or attachments from a server or other networked computer. The process involves loading pre-boot data and operating system software onto the operational node from a data store on the trusted node onto the operational node, and then rebooting the operational node to reboot to remove the pre-boot data and the operating system software from the operational node such that no rewrite functions are performed on the operational node.
As shown in FIG. 8, the time line for this process on the operational node goes from the off state to the firmware bootstrap step 802 and the bulk storage bootstrap state. This period is a safe update period 803 and continues until the bulk storage bootstrap stops and the application period starts 806. During the application execution period, the operational node is in a possible infection period 805. The illustration of FIG. 8 shows an example in which the operational node is actually infected 808 during the possible infection period. The reset step 810 that powers off the operational node, however, initiates an infection destruction period 807 in which the malware attack is eliminated.
Although embodiments and example implementations have been described in relation to game devices, such as in a casino environment, it should be noted that embodiments also include implementations in other network applications, such as ATM or cash machines, point-of-sale terminals, vending machines, ticket machines, and other similar applications involving networked computing devices that execute application programs that require monitoring, control and maintenance.
Optional embodiments of the present invention may broadly consist in the parts, elements and features referred to or indicated herein, individually or collectively, in any or all combinations of two or more of the parts, elements or features, and wherein specific integers are mentioned herein which have known equivalents in the art to which the invention relates, such known equivalents are deemed to be incorporated herein as if individually set forth.
It should also be noted that the various functions disclosed herein may be described using any number of combinations of hardware, firmware, and/or as data and/or instructions embodied in various machine-readable or computer-readable media, in terms of their behavioral, register transfer, logic component, and/or other characteristics. Computer-readable media in which such formatted data and/or instructions may be embodied include, but are not limited to, non-volatile storage media in various forms (e.g., optical, magnetic or semiconductor storage media) and carrier waves that may be used to transfer such formatted data and/or instructions through wireless, optical, or wired signaling media or any combination thereof. Examples of transfers of such formatted data and/or instructions by carrier waves include, but are not limited to, transfers (uploads, downloads, e-mail, etc.) over the Internet and/or other computer networks via one or more data transfer protocols (e.g., HTTP, FTP, SMTP, and so on).
Unless the context clearly requires otherwise, throughout the description and the claims, the words “comprise,” “comprising,” and the like are to be construed in an inclusive sense as opposed to an exclusive or exhaustive sense; that is to say, in a sense of “including, but not limited to.” Words using the singular or plural number also include the plural or singular number respectively. Additionally, the words “herein,” “hereunder,” “above,” “below,” and words of similar import refer to this application as a whole and not to any particular portions of this application. When the word “or” is used in reference to a list of two or more items, that word covers all of the following interpretations of the word: any of the items in the list, all of the items in the list and any combination of the items in the list.
The above description of illustrated embodiments is not intended to be exhaustive or to limit the embodiments to the precise form or instructions disclosed. While specific embodiments of, and examples are described herein for illustrative purposes, various equivalent modifications are possible within the scope of the disclosed methods and structures, as those skilled in the relevant art will recognize. The elements and acts of the various embodiments described above can be combined to provide further embodiments.
In general, in the following claims, the terms used should not be construed to limit the disclosed method to the specific embodiments disclosed in the specification and the claims, but should be construed to include all operations or processes that operate under the claims. Accordingly, the disclosed structures and methods are not limited by the disclosure, but instead the scope of the recited method is to be determined entirely by the claims. While certain aspects of the disclosed system and method are presented below in certain claim forms, the inventors contemplate the various aspects of the methodology in any number of claim forms. For example, while only one aspect may be recited as embodied in machine-readable medium, other aspects may likewise be embodied in machine-readable medium. Accordingly, the inventors reserve the right to add additional claims after filing the application to pursue such additional claim forms for other aspects.

Claims

1. A system for operating a plurality of gaming devices comprising:

a central gaming computer having a trusted node daughterboard having operational software configured to be loaded on a gaming computer;

a network coupled to the central gaming computer; and

a plurality of gaming computers coupled to the network with each of the plurality of gaming computers including an operational node motherboard operable to load operational software sent from the central gaming computer to affect a change in gameplay in the gaming computer.

2. The system of claim 1 wherein the trusted node of the central gaming computer includes pre-boot data configured to be loaded on an operational node of a gaming computer.

3. A method for remotely controlling one of a plurality of gaming computers from a central gaming computer with each gaming computer having an operational node and the central gaming computer having a trusted node connected via a network to an operational node of each gaming computer, the method comprising the steps of:

sending a power up signal from the trusted node in the central gaming computer to a operational node in one of the plurality of gaming computers when it is desired to affect a change in a parameter of game play in the gaming computer;

requesting from the central gaming computer trusted node pre-boot data from an operational node in an gaming computer; and

sending pre-boot data from the central computer trusted node to a gaming device operational node.

4. The method of claim 2, further including the steps of:

sending operating system software from the central gaming computer trusted node to a selected operational node of a gaming computer; and

loading the sent operating system software sent from the central gaming computer trusted node on a selected operational node of a gaming device.

5. The method of claim 2, further including the step of upon completion of the desired computer processing on the operational node, the trusted node causes the operational node to reboot to remove the pre-boot data and the operating system software from the operational node such that no rewrite functions are performed on the operational node.

6. A system for securing a networked gaming computer environment, the system comprising a trusted daughterboard provided in a central gaming computer coupled to a respective operational motherboard provided in each of a plurality of gaming devices coupled to the central gaming computer via the network wherein the trusted daughterboard is operative to reset each operational motherboard into a trusted state.

7. The system of claim 6 wherein the trusted daughterboard of the central gaming computer is operative to manage the state of each operational motherboard in each of the plurality of gaming computers.

8. The system of claim 7 wherein the trusted daughterboard of the central gaming computer is operative to manage the state of the operational motherboard using bootstrapped information.

9. The system of claim 8 wherein the operational motherboard of each of the plurality of gaming computers and the trusted daughterboard of the central gaming computer are coupled via a gigabit Ethernet interface.

10. The system of claim 6 wherein the operational motherboard of each of the plurality of gaming computers includes an x86 processor system.

11. The system of claim 6 wherein the operational motherboard of each of the plurality of gaming computers is coupled to an IP KVM component for receiving input commands and sending output signals.

12. The system of claim 6 wherein the operational motherboard of each of the plurality of gaming computers further includes a BIOS capable of netbooting and bootstrapping data.

13. The system of claim 12 wherein the operational motherboard of each of the plurality of gaming computers further includes net firmware and a boot store wherein the BIOS and the net firmware are coupled to the boot store.

14. The system of claim 13 wherein the boot store is in operative communication with the trusted daughterboard of the central gaming computer.

15. The system of claim 14 wherein a gigabit Ethernet connects the boot store to the trusted daughterboard of the central gaming computer.

16. The system of claim 15 further including a Gigabit Ethernet switch coupled intermediate the trusted daughterboard of the central gaming computer, the operational motherboard of each gaming computer and an IP KVM component coupled to the operational motherboard of each of the plurality of gaming computers.