Fighting online game cheating with cryptography
Download as PPTX, PDF0 likes467 views
The document discusses secureplay, a cryptographic system designed to combat cheating in online games by eliminating the need for a trusted third party. It outlines the system's application across various game types, detailing how transactions, game state validation, and secret sharing can mitigate cheating risks. While not a comprehensive solution for all cheating scenarios, secureplay enhances fairness in games through message-based protocols and independent verification of actions and states.
Fighting online game cheating with cryptography
- 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.
- 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