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

• US 8,543,837 B2
• Filed: 12/20/2011
• Issued: 09/24/2013
• Est. Priority Date: 09/13/2006
• Status: Active Grant

• Current Assignee: IGT (International Game Technology)
• Original Assignee: IGT (International Game Technology)
• Inventors: Bigelow, Robert Jr., Rader, Kirk, Davis, Dwayne A
• Primary Examiner(s): Orgad, Edan
• Assistant Examiner(s): JACKSON, JENISE E
• Application Number:
  US13/330,827
• Publication Number:
  US 20120110347A1
• Time in Patent Office: 644 Days
• Field of Search: 713/168, 713/187, 713/189, 726/26, 463/29
• US Class Current: 713/189
• 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 module returns the signature to a server 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 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 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 one or more algorithms that are configured to generate a unique signature of a state of a system configuration of a particular remote system, wherein the one or more algorithms are randomly selected from an algorithm database containing a plurality of hashing and verification functions;

sending the executable module to the particular remote system;

in the particular remote system, executing the executable module so as to generate the unique signature of the state of the 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 one or more algorithms 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.

2. 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, wherein the one or more algorithms are randomly selected from an algorithm database containing a plurality of hashing and verification functions;

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 client device is no longer trusted; and

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

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

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

4. The method as recited in claim 3 wherein the uncompromisable data is gaming data.

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

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

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

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

generating a second outcome of the executable at a 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.

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

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

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

providing a system configuration;

randomly receiving a dynamic executable containing one or more security algorithms from a server, wherein the dynamic executable specifies random data from an expected system configuration that the one or more security algorithms run on to check the integrity of the client, wherein the one or more security algorithms include hashing or verification algorithms;

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 corresponding to the specified random data to obtain a unique signature of a state of the system configuration of the client, the unique signature of the state of the system configuration of the client being used by the server to determine if the client is a trusted device.

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

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

deleting the dynamic executable and outcome.

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

receiving a 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.

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

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

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

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

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

implementing security measures if the dynamic executable is not authenticated.

16. 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 selected data;

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

compiling algorithms into an executable.