Method of randomly and dynamically checking configuration integrity of a gaming system

• US 20080076547A1
• Filed: 09/13/2006
• Published: 03/27/2008
• Est. Priority Date: 09/13/2006
• Status: Active Grant

• Current Assignee: IGT (International Game Technology)
• Original Assignee: IGT (International Game Technology)
• Inventors: Rader, Kirk, Bigelow, Robert, Davis, Dwayne A.
• Granted Patent: US 8,117,461 B2
• Time in Patent Office: Days
• US Class Current: 463/29
• CPC Class Codes: G06F 21/57 Certifying or maintaining trusted computer platforms, e.g. secure boots or power-downs, version controls, system software checks, secure updates or assessing vulnerabilities
• CPC Class Codes: G07F 17/3241 Security aspects of a gaming system, e.g. detecting cheating, device integrity, surveillance computer security G06F21/00

Abstract

In a gaming environment, a method of periodically downloading dynamically generated executable modules at random intervals that perform system configuration integrity checks in a secure and verifiable manner is disclosed. The dynamically generated executable modules are created on a server machine and are themselves signed using industry standard PKI techniques, and contain randomly chosen subset from a repertoire of proven hashing and encryption algorithms that are executed on the system to be checked to create a unique signature of the state of that system. The dynamically generated executable module returns the signature to the server machine from which it was downloaded and deletes itself from the system being checked. The next time such an executable module is downloaded, it will contain a different randomly chosen subset of hashing and encryption algorithms. The server that is performing the system configuration integrity check maintains a database of expected system configurations and performs the same subset of hashing and encryption algorithms as contained in the dynamically generated executable module. The result returned by the downloaded executable module is compared to that computed locally, and an error condition is raised if they do not match.

Claims

1. A method of ensuring the validity of a data set for use in a casino-type gaming system, said method comprising the steps of:

(a) installing a game data set at a gaming module;

(b) providing an exact copy of at least a portion of the game data set at an oversight module;

(c) randomly and dynamically generating an integrity executable at the oversight module

(d) sending the integrity executable to the gaming module;

(e) using the integrity executable, computing a first outcome from the game data set at the gaming module;

(f) after computing the first outcome, sending the first outcome to the oversight module and removing the integrity executable from the gaming module;

(g) using the integrity executable, computing a second outcome from the game data set at the oversight module;

(g) comparing the first and second outcomes to determine whether the first and second outcomes match;

(h) if the first and second outcomes match, indicating that the game data set is authentic; and

(i) if the first and second outcomes do not match, indicating that the game data set is not authentic.

2. The method as recited in claim 1 further comprising:

if the first outcome is not received within a predetermined amount of time starting from when the integrity executable was sent, indicating that the game data set is not authentic.

3. The method as recited in claims 1 wherein the oversight module is stored on a server machine and the gaming module is stored on a client machine.

4. The method as recited in claims 3 wherein the server machine is a central gaming server and the client machine is a remote gaming terminal.

5. The method as recited in claims 3 wherein the server machine is a remote gaming terminal and the client machine is a portable gaming device.

6. The method as recited in claims 1 wherein the integrity executable is based on system configuration of the gaming module and includes one or more security algorithms.

7. The method as recited in claims 1 wherein the integrity executable is sent at randomly varying intervals.

8. A method of performing a system configuration integrity check, comprising:

in a host, maintaining a database of expected system configurations of one or more remote systems;

in the host, randomly and dynamically generating an executable module containing an algorithm that is configured to generate a unique signature of the state of a particular remote system;

sending the executable module to the particular remote system

in the particular remote system, executing the executable module so as to generate a unique signature of the state of the actual system configuration of the particular remote system;

returning the unique signature to the host and deleting the executable module from the particular remote system;

in the host, generating a unique signature of the state of the expected system configuration associated with the particular remote system maintained on the database using the same algorithm contained in the executable module; and

in the host, comparing the unique signature returned from the particular remote system with the unique signature generated locally at the host, and generating an error condition if the unique signatures do not match.

9. A server side method of checking the integrity of a client device, comprising:

randomly and dynamically generating an executable for checking the integrity of a client device, the executable containing one or more algorithms to be performed on at least a portion of a particular system configuration of a particular client device;

communicating with a client device;

sending the executable to one or more particular client devices having the particular system configuration;

looking for a reply from the one or more client devices in response to performing the executable, the reply including the outcome of the executable;

if a reply is received, determining whether the client device is a trusted device based on the outcome;

if a reply not received within a preset amount of time, indicating that the device is no longer trusted; and

sending a trust response to the client, the trust response indicating whether the client is trusted or not trusted.

10. The method as recited in claim 9 further comprising:

storing at least the portion of expected system configuration of the particular client device, the portion including at least uncompromisable data.

11. The method as recited in claim 10 wherein the uncompromisable data is gaming data.

12. The method as recited in claim 9 further comprising:

encrypting the executable to prevent anyone but the client device from reading the executable.

13. The method as recited in claim 12 wherein the executable is encrypted with a public key stored at the server and decrypted with a private key stored at the client device.

14. The method as recited in claim 9 wherein determining whether the client device is a trusted device includes:

generating a second outcome of the executable at the server;

comparing the outcome generated at the client device with the second outcome generated at the server, indicating that the client device is trusted if there is a match, indicating that the client device is not trusted if there is no match.

15. The method as recited in claim 9 further comprising:

sending a command to the client device when the client device is no longer trusted, the command instructing the client to stop operations, erase data or initiate an alarm.

16. A client side method of checking the integrity of a client, comprising:

providing a system configuration;

randomly receiving a dynamic executable from a server;

verifying the authenticity of the dynamic executable;

temporarily storing the dynamic executable; and

running the dynamic executable on at least a portion of the system configuration to obtain an outcome, the outcome being used to determine if the client is a trusted device.

17. The method as recited in claim 16 further comprising:

sending the outcome to the server that sent the dynamic executable; and

deleting the dynamic executable and outcome.

18. The method as recited in claim 17 further comprising:

receive trust response from the server, the trust response indicating whether the client is trusted or not trusted, the trust response being based on the outcome;

if trusted, proceeding with standard client operations; and

if not trusted, implementing security measures.

19. The method as recited in claim 17 wherein the executable is deleted immediately after the outcome is obtained.

20. The method as recited in claim 16 further comprising:

implementing security measures if the dynamic executable is not received within a predetermined amount of time.

21. The method as recited in claim 16 wherein verifying the authenticity of the dynamic executable includes decrypting the dynamic executable using a private key.

22. The method as recited in claim 16 further comprising

implementing security measures if the dynamic executable is not authenticated.

23. A method for randomly and dynamically generating an executable associated with testing the integrity of a remote client device associated with gaming, said method comprising:

randomly generating a request to check a particular remote client device;

consulting a system configuration database containing an expected system configuration for the particular remote client device;

randomly selecting data to be checked from the expected system configuration of the particular remote client device;

consulting an algorithm database containing a plurality of hashing and verification algorithms to be performed on the select data;

randomly selecting one or more algorithms to be performed on the select data; and

compiling algorithms into an executable.

24. A gaming system, comprising:

an oversight module configured to randomly monitor the integrity of one or more gaming modules operatively coupled to the oversight module to ensure that the gaming modules have not been compromised, the oversight module randomly performing audits of at least the gaming code stored on the gaming modules, the audits indicating whether the gaming code has been changed or altered from a known configuration.

25. The gaming system as recited in claim 24 wherein the audits are dynamically generated.

26. The gaming system as recited in claim 24 wherein the oversight module includes:

a gaming module configuration database having a copy of the gaming data for each gaming module;

an algorithm database that includes a plurality of security algorithms;

an integrity check generator configured to randomly and dynamically generate integrity executables to be run on both the oversight module and the gaming module, the integrity executable containing one or more security algorithms;

a comparator that compares the results of the executable run on the oversight module and the gaming module, a match indicating that the gaming module is trusted, a non match indicating that the gaming module is not trusted.

27. The gaming system as recited in claims 26 wherein the integrity check generator consults the gaming module configuration database to find a gaming module configuration for a particular gaming module to be audited, and uses the gaming module configuration for the particular gaming module to determine what type of data to base the integrity executable on.

28. The gaming system as recited in claims 26 wherein the integrity check generator consults the algorithm database and includes one or more security algorithms in the integrity executable.

29. The gaming system as recited in claims 24 further comprising:

an interface for sending the integrity executable to the gaming module; and

a security mechanism for encrypting the integrity executable before sending the integrity executable over the interface.

30. The gaming system as recited in claims 29 wherein the integrity executable includes instructions to erase itself after running on the gaming module.

31. The gaming system as recited in claims 24 further comprising:

one or more security elements for implementing security measures when the gaming module is not trusted, the security measures being selected from at least terminating gaming operations at the gaming module, performing a self destruct at the gaming module, initiating audio alarms at the oversight module or gaming module, initiating visual alarms at the oversight module or gaming module, or erasing data at the gaming module.

32. The gaming system as recited in claims 24 wherein the gaming system is embodied as a single gaming machine that includes both the oversight module and gaming module.

33. The gaming system as recited in claims 24 wherein the gaming system is embodied as a gaming network with one or more server machines and one or more client machines that communicate over a wired or wireless connection.

34. The gaming system as recited in claims 33 wherein the client machine is a remote gaming terminal.

35. The gaming system as recited in claims 33 wherein the server machine includes the oversight module and the client machine includes the gaming module.

36. The gaming system as recited in claims 33 wherein server machine includes the oversight module and a gaming module and the client machine includes a gaming module.