Mitigating Information Exposure to Cheaters in Real-Time Strategy Games

1. Mitigating Information Exposure to Cheaters in Real-Time Strategy Games Chris Chambers Wu-chang Feng Wu-chi Feng Portland State University Debanjan Saha IBM Research

2. Outline • Background • Detecting cheating in Battleship • Cheat detection for RTS • Evaluation • Information hidden • Bandwidth cost

3. Background: On-line games • Are popular • Are cheat-filled • Cheating is detrimental to popularity and fun • RTS games • Players command virtual armies • Peer-to-peer architecture • Most common cheat: maphacks

4. Warcraft 3 RTS interface

5. Warcraft 3 RTS interface

6. Related work • Baghman, Levine, “Cheat-proof playout for centralized and decentralized online games” • INFOCOM 2001 • University of Massachusetts • Cool zero-knowledge proof for if two entities share the same location • Scales exponentially with # of units • Buro, “ORTS: A Hack-free RTS Game Environment” • International Computers and Games Conference, 2002 • University of Alberta • Proposes client/server RTS architecture

7. Detecting Battleship cheats • Familiar turn-based game • When played peer-to-peer, exhibits similar problems to RTS games • Fix battleship, then fix RTS games

8. miss miss miss miss miss miss miss miss miss miss miss miss Shoot() Shoot() Shoot() Shoot() Shoot() Battleship Conundrum 1 2. A fires and hits 3. A cheats, A wins A knows B’s location Shoot(1,2) hit Shoot(2,2) hit Shoot(3,2) hit “Just lucky I guess” 1 2. A fires, B lies 3. B cheats, A loses A doesn’t know B’s loc miss miss “Just unlucky I guess”

9. Securing Battleship • Pre-game • Exchange hashes of ship location, secret • Commits players to a specific location without revealing it (bit commitment) • In-game • Each move, send (and receive) shot coordinates, and whether opponent’s last shot hit or missed • Opponents can lie about hits/misses here • Post-game • Exchange secrets and initial ship location • Verify opponent’s integrity by checking all the evidence of shots vs. replies

10. Battleship  RTS games • Battleship only has one secret per player per ship • RTS games use the fog of war rule • RTS games have hundreds of secrets, and they change moment to moment • Unit type • Unit placement • RTS games are balanced like rock, paper, scissors… knowing opponent’s secrets, it’s easy to win

11. RTS Secrets Yellow unit, and its vision radius Yellow shouldn’t see these enemies Yellow should see these enemies

12. RTS Secrets • Current RTS network protocol is to exchange mouse clicks and each simulate the other’s game • PRO: no one can lie about what units they have • CON: each player knows the other player’s mouse clicks! • Just like Battleship

13. Hiding RTS Secrets • Key idea: You know opponent’s view • If (<click>) is in oppView, send <click> • Else send Hash(<click>,secret) 1. myUnitsViewable 2. <click> or h(<click>,s) 3. myView 1. myUnitsViewable 2. <click> or h(<click>,s) 3. myView

14. Cheat Detection Protocol • Pre-game • Create your secret s • Generate initial game state igs, send h(s,igs) • In-game • Each time slice, send (and receive) • Your viewable area • Either your move m, or, if it’s invisible to him, h(s,m) • If one of your units just entered his area, send that unit • Post-game • Exchange your secret, initial conditions, and all hidden moves throughout the game • Verify opponent’s integrity by simulating the game rapidly with the (now known) hidden moves

15. Issues • Not all information is concealed • Old way: nothing concealed • New way: know viewable areas • How much information is concealed? • Increased network requirements • Old way: bandwidth = number of clicks • New way: bandwidth = ???

16. Quantifying Information Concealment • One general measure of information: Shannon’s uncertainty where x is a random variable with n possible valuesand p(x) is the probability distribution of x • Peak uncertainty (1): values are equally likely • Minimum uncertainty (0): values are predicted perfectly

17. Quantifying Information Concealment • Experiment method: • Scatter points randomly on a grid • Calculate uncertainty (small) • Create viewable areas from points • Calculate uncertainty • Graph difference • Experiment 1: vary number of units (radius fixed proportional to RTS) • Experiment 2: vary radius of units (units fixed proportional to RTS)

18. Uncertainty Gain

19. Bandwidth • RTS games are really turn-based at a ms level, but often the turns are empty • Need a bandwidth model that scales down to ms but allows for empty moves • Terms: vr = viewable region n = new units s = signature r = time interval to update vr sm = secured moves

20. Estimating Bandwidth • Viewable area • Game state: 11,000 x 11,000 positions • Mini-map in Warcraft: 175 x 175 pixels  gives reasonable representation of viewable area • Assume 200ms for r • Warcraft allows max 100 units/player • Assume half of units sent each timeslice • Number of moves • Depends on click-speed • Fast players peak at 5 moves / second • Maximum bandwidth: ~2-3 kilobytes/second • How does this compare to real games?

21. Units in a real game over time Replay from a single Warcraft 3 game

22. Size of mini-map Replay from a single Warcraft 3 game

23. Summary • Scheme addresses a key RTS cheat • Decreases information exposed • Bandwidth seems reasonable • Future work • Evaluate scheme vs. game traces • Make a library of game traces, viewable areas

24. End of talk • Questions?

25. Non-repudiation • How to prove cheating to a 3rd party? • Need more cryptography: message signatures • Digest each message and encrypt the digest with private key • 3rd parties digest each message and compare with decrypted digest • Ideally public keys for this stored at game’s authentication server

26. Bit Commitment Example: Fair coin flip • Each party… • Comes up with a secret key • Encrypts “heads” or “tails” • Exchanges encrypted messages • Exchange secret keys • Whoever was the “flipper” wins if answers differ, loses if they’re the same • Needs fixing if you want to show the result to someone else: non-repudiation

27. Background: non-repudiation • Properties • N-r messages cannot be forged • Everyone can verify the author of an n-r message • The trick: signatures • Requires player I to have public key pubi and private key privi • Given message X, compute h(X), a cryptographic hash of X • The signed version of X is (X,privi(h(X))): X appended with an encrypted version of h(X). • Everyone can verify the author of the message • Decrypt the signature using the public key • Perform the hash on X. Out pops h(X) • Why can’t they be forged?

28. Another metric: Information loss • Uncertainty very generic • We can quantify information loss: percentage of data deleted • Example • Quantizing a large map into a 2x2 grid • Any more units than 4 are lost • Scheme has two sources of information loss: • Quantization • Overlapping viewable areas

29. Information loss • Quantization • Scatter p points • Downsample • Count number of points p’, compute the ratio p’/p • Overlap • Scatter points • Expand viewable areas • Calculate overlapped area as “lost”

30. Information loss

31. Information loss conclusions • Information loss modest: 12% for 6 units • Expect trace-driven data to show more loss: units are clustered often in game play

32. Applicability outside of RTS • Apps that are… • Peer-to-peer (ie, too resource consumptive to host client-server) • Tolerant of extra bandwidth requirements • Example: • Board games • Card games

33. Don’t have to send all units Blue doesn’t send these units (they’re already known about by yellow) Blue doesn’t send these units (they’re not visible) Blue only has to send these units