Fighting game cheating with cryptography

Design by:Steven B. Davis

steve@free2secure.com+1.650.278.7416

Original presentation Copyright 2004 by IT GlobalSecure Inc.

Problem• Cheating in online games continues to be a serious problem.

• Casino games• First-person shooters• Casual games• … and others

• Most approaches depend on a trusted third party. SecurePlay was designed so that no one needs to be trusted

• If there are N participants in a game, the game will be “fair” if at least one is honest or “differently dishonest”.

• This does not solve every cheating problem.• For example, it cannot stop financial collusion in Poker (where players agree to share their

winnings), but it can stop knowledge collusion where players share knowledge of their hands with some slight tweaks to the game rules.

Working with SecurePlay

Overview• SecurePlay Game Reference Model• How Used for Different Types of Games

• Chess – Turn-based Gaming• 3-Card Monte - Games of Hidden Information• Backgammon – Basic Games with Random Events• Poker – Basic Games with Private Random Events and Dealer• Hearts – Like Poker, but with Private Moves• Rock-Paper-Scissors – Simultaneous Games• Fighting Game – Simple Real-Time and Event-based Games• Rally Cars – Secured Real-Time and Event-based Games

• SecurePlay Network Model

SecurePlay Game Reference Model

• Basic Model for all Network Games

• Presentation• Control• State• Rules• Assets• Administration• Network(s)

Game StatePresentation

Control

Non-Deterministic Rules

Deterministic Rules

Choices/ActionsEvent Generation

Game AdministrationLobbies, Administration, Infrastructure

Assets (art, data)

Game Play

Network

Game Reference Model – Transaction Overview

• Transactions are used to coordinate game play over a network

• Depending on how the transactions are used, the integration can occur later in the development process with more or less difficulty

Game StatePresentation

Control

Non-Deterministic Rules

Deterministic Rules

Choices/ActionsEvent Generation

Game AdministrationLobbies, Administration, Infrastructure

Assets (art, data)

Game Play

Ship

Ship

Strobe

Strobe

Blast

Blast

Random

Simultaneous

Simultaneous

Secret

Multi-Part

Multi-Part

Random

Integration Effort

SecurePlay Protocols

Chess – Turn-based Gaming• Network Chess Overview

• Turn-based Game• Well-known Rules

• SecurePlay Integration• Understanding SecurePlay, Games, and

Communications• Use Blast or Multi-part Turn Protocols to send

turns• Add Security Services: Encryption, Integrity, and

Non-repudiation

SecurePlay & Game Integration• SecurePlay Links Players,

Games, and Communications• Allows multiple games,

players, and communications to use a common SecurePlay library

• Game API is basically a container for Transactions

• Add and remove players• Change communications• Add and remove

transactions

• Transaction APIs are the main SecurePlay services used by Games

Game API Other SecurePlayTransaction APIs

Communications Service(s)

SecurePlay API

Game

SecurePlay Transactionsand Games

• Game Rules Code Create and Wrap SecurePlay Transactions

• For Chess, the Rules Code is the moves for the various pieces

• Either Blast or Multi-Part Transactions can be used to send Chess moves

Game

Game Rules

Game Transactions

Transaction API

Game Transaction

Event Notification

Messages

SecurePlay Messages• SecurePlay is a message-

based system• Message Elements

• Header• Body• Signature

• Security Features• Encryption• Integrity/Non-Repudiation• Privacy• Anti-Piracy

• Plug-able Security Manager

Header Message Signature

Signed

Encrypted

Blast Transaction

• Simple Message• Sent to All

Participants in the Game

• For Chess, could be used to send Player Actions/Turns

WKP to D4

Multi-Part Turn Transaction 1

• Simple, Multi-Part Transaction

• Includes full transaction setup

• Creation, Configuration, Start

• And eventually, End.

• For Chess, a Single Multi-Part Transaction would be used for the entire game.

• It could also be used for “Chat”.

WKP to D4

Net Play “Synchronization” – Action vs. State

• Different Types of Ways to Exchange New Game Information over a network:

• Action (by human or machine player)

• Differential Action (* not applicable for Chess)

• Rules Action (* not applicable for Chess, but common in computer games)

• Action Result (Player Final Position)

• Updated State (new chess board positions)

• Differential State (Player Final Position, (optional) removed pieces)

State 1 State 2 State 3Action 1 Action 2

Result 1 Result 2

Differential State

Differential Action

State 1 – State 2

Action 1 – Action 2

Game & Rules Verification• SecurePlay supports

independent verification• Needed because games are

inherently adversarial• Every participant needs to be

able to validate actions and state by themselves

• Historically, State Change Validation can be difficult

• SecurePlay Simplifies Verification

• Rules Action Attempt Validation

• Affirmation of state• Rules Action Resolution

Validation

• SecurePlay’s “Go Forward” technique is more robust than checking rules “differentially”

State 1 State 2 State 3Action 1 Action 2

Result 1 Result 2

Validate State Change

Validate Action Attempt

Can State 2 Result from State 1?

Can Player 1 Perform Action 1?

Validate Action ResultIs Result 2 possible from State 2?

Guessing Games - 3-Card Monte

• Guessing Game (Find the Queen)• Games using similar principles

include Stratego™ and Battleship™ and card games like “Go Fish”

• Typically Turn-based games• Guessing location or value of hidden

assets

• SecurePlay Integration• Secret Transaction for Hidden, Non-

Repudiable* Actions or Choices• Other Transactions may be used to

complete the game

* Cannot be later refuted by the transaction participants

Alleged Alleged

Secret Transaction 1• At its core, this is a two-step

transaction.

• A Secret is identified

• The “Hidden Secret” is sent to the other participants using Irreversible Transforms

• Random data is appended to prevent Dictionary Attacks

• At the appropriate time, the Hidden Secret and appended Random data is revealed and Verified

• For 3-Card Monte:• (Secret) Set Queen Location• (Secret) Send Transform of Secret• (Multi-Part) Bet on Queen Location• (Secret) Reveal Secret• (Multi-Part) Resolve Bet

Secret

Secret

Secret

Random

Random

Hash Function

Hash Function

Transform

StoreTransform

Send

Send

Transform

ValidateReceivers

Sender

Alleged

Verification – Instant vs. Deferred• Verification can be inherent in the completion of transaction or

deferred until a later time. • Verification can also be deferred from a game rules perspective.• As long as every transaction and rule can eventually be verified, the

game is fair.• Certain transactions and rules can allow intermediate verification in

case of player complaint, though not always – again this depends on the nature of the specific game.

Backgammon• Game of Actions and Random Events

• The most common game structure for traditional board games

• The underlying structure of many computer games (Random Event, Move, Attack, Resolve, Repeat) or (Move, Attack, Random Event, Resolve, Repeat)

• The underlying structure of most casino games (Make Bet, Random Event, Resolve, Repeat)

• Use of Random Events to Move or to Resolve Actions

• SecurePlay Integration• Random or Simultaneous Transaction to

Generate Fair Random Events• Blast, Multi-step, or other transactions may

be used to complete the game.

Player 1<Random> Roll Dice<Multi-Part> Move PiecesPlayer 2<Random> Roll Dice<Multi-Part> Move Pieces…Where <> denotes the SecurePlay protocol

Simultaneous Transaction 1• The Simultaneous Transaction

essentially is the Secret Transaction with multiple parties involved.

• Each party sends the Transform of their contribution, just as with the Secret Transaction.

• After each party receives all of the other participants contributions, they reveal their contribution

• Random Numbers are created by the contribution consisting of an arbitrary random number chosen by each Participant (for Backgammon, 2 random numbers between 1 and 6)

• The Results are then added together and reduced to a value between 1 and 6

Secret 2 Random 2

Hash Function

Transform 2

Secret 1 Random 1

Hash Function

Transform 1

Transform 2 Transform 1

Secret 2 Random 2 Secret 1 Random 1

Secret 1 Secret 2

1. Exchange

2. Reveal

Player 1 Player 2

Result Result

3. Combine3. Combine

Random Transaction 1• Build Collaborative Game Key by

Dealer• Dealer sends Transform of his

contribution to other players (uses Secret Transaction)

• Each other Player posts a random contribution

• Dealer combines all to build Game Key

• Game Key used to generate random events

• At end of Game, Dealer reveals his contribution

• Everyone verifies contribution, rebuilds game key, and reconstructs random events to Verify transaction

Key 1 Random 1

Hash Function

Transform 1

Dealer Players

Key 2

Key 3

Key 4

Transform 1

Key 2

Key 3

Key 4

Game Key

Event Generator

Event 1Event 2

Event 3Event 4

Event 5

Key 1

Verify

Rebuild Events

Reveal

Send

Post

BuildPlay

Poker• Game of Random Deal

(or deals) and Betting (or rounds of Betting)

• SecurePlay Integration• Introduction to

“Privacy” in SecurePlay• Requirement for

“Dealer”• Combination of Random

Transactions (for deals) and Multi-part Transactions (for bets)

Players<Multi-Part> Ante upDealer<Random> Deal to Player 1<Random> Deal to Player 2…Player 1<Multi-Part> BetsPlayer 2<Multi-Part> Bets… Where <> denotes the SecurePlay protocol to use

Message Privacy• The Privacy function allows

different messages to be sent to different participants in a Game Transaction

• Allowed values are:• Participant(P) - Distinguished

recipient of transaction message• Non-participant(Q) – Recipient of

alternate transaction message• All (A) – sent to all transaction

members

• Used directly within SecurePlay by the Secret Transaction, for revealing secrets to selected transaction members, and by the Random Transaction for random events such as dealing cards face down to individuals.

Header Message Signature

P or Q

A

OR

Header Message Signature

Header Alternate Message Signature

Header Message Signature

Privacy Flag

Random Transaction 2• The set up of the Random

Transaction is identical to that for Backgammon.

• Random events are created without replacement to work like a deck of cards

• The Transaction Master (Dealer) creates different random events to be revealed to each participant (just like dealing cards face down).

• Alternate messages are sent to the other players to maintain synchronization with the “deck”.

• Verification will ensure consistency, unless cards are revealed.

Key 1 Random 1

Hash Function

Transform 1

Dealer Players

Key 2

Key 3

Key 4

Transform 1

Key 2

Key 3

Key 4

Game Key

Event Generator

Event 1Event 2

Event 3Event 4

Event 5

Key 1

Verify

Rebuild Events

Reveal

Send

Post

Build Player 1 Only

Player 2 Only

Net Play “Synchronization” – Asymmetric Information

• Computer games often use symmetric network communications and information

• Easy• Net play added late in process• Many security weaknesses

• Asymmetric information (i.e., “I know something you don’t”) is a powerful game play tool

• Provides uncertainty and opportunity for strategic choice• Increases re-playability and extends the life of games• Needs to be built into the game design• Needs security system for verification• Supported by SecurePlay protocols

Hearts• Game of Random Deal,

Secret Exchange of Cards, and Play

• SecurePlay Integration• Use of Random Transaction

for Initial Deal• Use of Secret Transactions

for Passing Cards• Use of Multi-Part

Transaction for Play

Dealer<Random> Deal to Player 1<Random> Deal to Player 2<Random> Deal to Player 3<Random> Deal to Player 4Player 1<Secret> Pass Cards to LeftPlayer 2<Secret> Pass Cards to Left …<Multi-Plat> Play…End game<Random> Verify Deal<Secret> each player, verify Secret

Where <> denotes the SecurePlay protocol to use

Secret Transaction 2• The Secret Transaction

supports revealing Secrets using the Privacy feature of SecurePlay messages

• Passing Player uses Secret Transaction to send Transform to All Players

• Passing Player reveals the Secret to the selected Player prior to play.

• Passing Player reveals the Secret to the remaining Players at the end of the game.

Alleged Alleged

Secret

Secret

Secret

Random

Random

Hash Function

Hash Function

Transform

StoreTransform

Send

Send

Transform

ValidateReceivers

Sender

Alleged

Rock-Paper-Scissors

• Simplest example of a simultaneous game

• Cheating is a “timing” attack by waiting to see what the other player will do

• SecurePlay Integration• Direct use of Simultaneous

Transaction

Simultaneous Transaction 2

• Transaction process is the same as previously described

• Resolution is handled purely in Game Rules code

Secret 2 Random 2

Hash Function

Transform 2

Secret 1 Random 1

Hash Function

Transform 1

Transform 2 Transform 1

Secret 2 Random 2 Secret 1 Random 1

1. Exchange

2. Reveal

Player 1 Player 2

3. ResolvePlayers<Simultaneous> make choices<Simultaneous> send choice transforms<Simultaneous> reveal choices<Simultaneous> verify choices

Rules – resolve ChoicesWhere <> denotes the SecurePlay protocol to use

Strobe Transaction 1

• Strobe is a sequence of Simultaneous Transactions

• Strobe automatically moves from one Simultaneous Transaction to the next

• Reading data out of the previous transaction

• Writing data to the current transaction

ExchangeReveal

ExchangeReveal

ExchangeReveal

ExchangeReveal

Read

Read

Read

Read

Time

Fighting Game

• Basic “Real-Time” Game• Attack/Defend/React• Most games with

“Tactics” use this basic model

• SecurePlay Integration• Use of Strobe Transaction

for Interaction• Use of Rules to Provide

“Real-Time”ness• Randomization

Embedded in Strobe• Like Dice in Backgammon

Player 1<Simultaneous> Tactic 1<Simultaneous> send transform<Simultaneous> reveal Tactic<Simultaneous> verify Tactic 2

Player 2<Simultaneous> Tactic 2<Simultaneous> send transform<Simultaneous> reveal Tactic<Simultaneous> verify Tactic 1

Resolve

Where <> denotes the SecurePlay protocol to use

Strobe Transaction 2

• Strobe can be used to chain together a sequence of actions over time.

• Time does not have to be uniform and can be Event-Driven or Interval Driven

• Payloads of Strobe Transactions can contain any sort of information, Actions, Results, and State updates as well as ancillary data such as random event generators

ExchangeReveal

ExchangeReveal

ExchangeReveal

ExchangeReveal

Read

Read

Read

Read

Time

Event-based Time vs. Interval Time

• Strobe simply sequences events in time,it does not force events to be uniform

• A key concept, whether Strobe is used or not, is some notion of minimal time and non-interference

• The minimal time interval between actions by a Player

• Choices that occur during a minimal time interval should not “break” each other.

• These intervals are driven by game rules and network lag

ExchangeReveal

ExchangeReveal

ExchangeReveal

ExchangeReveal

Time ExchangeReveal

Exchange

Reveal

ExchangeReveal

Exchange

Reveal

ExchangeReveal

ExchangeReveal

ExchangeReveal

Rally Cars• Racing Games use simplified

interfaces to simulate car racing.

• Similar mechanisms are used for Sports games and Action Games where continuous time and action are perceived

• SecurePlay Integration• Use Strobe Transaction to Post

Actions or State Updates• Use Multi-Step or Blast

Transactions as an alternative• Physics Engine Provides

Continuity

Physics is just another Set of Rules

• Physics Engines can be event driven or interval driven for game play

• Engine “runs” between Player Actions• No different than the table lookup done for fighting game or Rock-Paper-

Scissors• Always have synchronization issue over a network• Always have a display issue over a network

Steer Left 20o Steer Right 5o Steer Right 8o

Accelerate 48% Brakes 5% Brakes 55%Accelerate 88%

Time = 18

Time = 23

Time = 41

Time = 30 Time = 48

Time = 43

Time = 65

Abstraction of Game Play vs. Presentation

• Game Presentation State for continuous state can “float” above actual game play state

• Interpolation and Projection of State can occur at the presentation level, not at game play level.

• Challenge is in smart control and recognizing reality of network environment

• Need tools to convey anomalous network environment

• Need game design to be robust under wide range of network conditions

Actual GamePresentation 1 Presentation 2

Ship Transaction

The Ship Transaction provides for the distribution of game data and other assets

• Supports Verified Shipment

• Supports Buffered Shipment for very large items

• Supports Slow/Manual Shipment to minimize interference with ongoing game play

Asset Shipment PackagesFor sending assets incrementally

DATA ASSET:Name: EinsteinClass: ScientistIntelligence: 98Sense of Humor: 75

SecurePlay Network Model• Communications model

• Independent of Transactions

• Can support client-server, peer-to-peer

• Can support multiple communications systems concurrently

• SecurePlay messages provide a logical network above the actual communications network

• Transaction model• Internal transaction master• Transaction participants

are a subset of game participants

Game Instance

Transactions

SecurePlay Messages

Communications Networks

SecurePlay and Anti-Piracy• Network games that are delivered as a

service have a high degree of anti-piracy built in

• Excluding the threat, mainly seen in Asia of “Doppelganger Servers”

• SecurePlay’s upcoming extension, Keeper, will provide a high degree of anti-piracy for generalized network games

• With capability to help stop Doppelgangers• Complementary to Other DRM/license security

solutions• Customized extensions can provide additional

strength in different platform, network, and game environments

SecurePlay and Tournament & High Score Games

• Tournament Games• Player vs. Player games can operate in true peer-to-peer fashion• Players can agree on results or disagree

• Only if disagreement occurs, SecurePlay game logs can be posted to Tournament Director for evaluation

• High-Score Solitaire/Patience Games• Player is effectively playing against Game Operator• SecurePlay can be used for full interaction over network

• SecurePlay can also be scaled back to seed random data, review results, or otherwise “compress” its involvement depending on security risks and suspicions.

• SecurePlay can also choose to allow a review games if they are anomalous.

• SecurePlay builds a Secure Game Contract

Next steps• Does this make sense (any questions)?• Does this address an interesting problem?• Are there other applications?• Are there system constraints that may invalidate or limit the

effectiveness of this approach?

Who am I?• Steven Davis• Worked in high-end security design and analysis since 1987

• Current focus on “business security” – linking business and security together beyond IT• History:

• Design and analyze custom cryptography and security architectures• … and lots of other security work

• Several security patents:• Anti-cheating cryptography for games• “Manual” digital signature to improve credit card security

• Book “Protecting Games”• Numerous papers and conferences• Blog: free2secure.com• Defunct blog: playnoevil.com – 2006 to 2012

• https://www.linkedin.com/in/free2secure• steve@free2secure.com• +1.650.278.7416