How do you fight cheating in online games (everything from poker and other casino games to casual and first person shooters)? Instead of trying to monitor the game and detect cheaters after the fact, you can actually prevent AND detect many forms of game cheating with cryptography. This paper describes a suite of cryptographic algorithms you can use to stop many forms of cheating. The downside (and there always is a downside, isn't there) is that you have to build it into your games. It is a secure foundation on top of which your games are built. NOTE: Full notes are available with the slide package. Contact me at: steve@free2secure.com for more information.

1. 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.

2. 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.

3. Working with SecurePlay

4. 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

5. 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/Actions
Event Generation
Game Administration
Lobbies, Administration, Infrastructure
Assets (art, data)
Game
Play
Network

6. 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/Actions
Event Generation
Game Administration
Lobbies, 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

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

8. 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 SecurePlay
Transaction APIs
Communications Service(s)
SecurePlay API
Game

9. SecurePlay Transactions
and 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

10. 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

11. Blast Transaction
• Simple Message
• Sent to All
Participants in the
Game
• For Chess, could be
used to send Player
Actions/Turns
WKP to D4

12. 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

13. 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

14. 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 Result
Is Result 2 possible from State 2?

15. 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

16. 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
Store
Transform
Send
Send
Transform
Validate
Receivers
Sender
Alleged

17. 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.

18. 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 Pieces
Player 2
<Random> Roll Dice
<Multi-Part> Move Pieces
…
Where <> denotes the
SecurePlay protocol

19. 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. Combine
3. Combine

20. 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 1
Event 2
Event 3
Event 4
Event 5
Key 1
Verify
Rebuild Events
Reveal
Send
Post
Build
Play

21. 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 up
Dealer
<Random> Deal to Player 1
<Random> Deal to Player 2
…
Player 1
<Multi-Part> Bets
Player 2
<Multi-Part> Bets
… Where <> denotes the SecurePlay protocol to use

22. 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

23. 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 1
Event 2
Event 3
Event 4
Event 5
Key 1
Verify
Rebuild Events
Reveal
Send
Post
Build
Player 1 Only
Player 2 Only

24. 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

25. 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 4
Player 1
<Secret> Pass Cards to Left
Player 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

26. 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
Store
Transform
Send
Send
Transform
Validate
Receivers
Sender
Alleged

27. 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

28. 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. Resolve
Players
<Simultaneous> make choices
<Simultaneous> send choice transforms
<Simultaneous> reveal choices
<Simultaneous> verify choices
Rules – resolve Choices
Where <> denotes the SecurePlay protocol to use

29. 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
Exchange
Reveal
Exchange
Reveal
Exchange
Reveal
Exchange
Reveal
Read
Read
Read
Read
Time

30. 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

31. 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
Exchange
Reveal
Exchange
Reveal
Exchange
Reveal
Exchange
Reveal
Read
Read
Read
Read
Time

32. 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
Exchange
Reveal
Exchange
Reveal
Exchange
Reveal
Exchange
Reveal
Time Exchange
Reveal
Exchange
Reveal
Exchange
Reveal
Exchange
Reveal
Exchange
Reveal
Exchange
Reveal
Exchange
Reveal

33. 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

34. 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

35. 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

36. 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 Packages
For sending assets
incrementally
DATAASSET:
Name: Einstein
Class: Scientist
Intelligence: 98
Sense of Humor: 75

37. 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

38. 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

39. 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

40. 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?

41. 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