Trust no oneDeep Throat, The X-Files

“Security” for network communication can basically (at least for our purposes here) be split into two distinct paradigms: Secrecy and verification. Secrecy entails encoding a message for transmission such that if the message were to be intercepted by a third party it would appear to be unreadable; The canonical example is the ROT13 “substitution” cipher. Verification is the process by which the contents of a message can be reliably determined to have not been modified in transmission (for example via a Man-in-the-Middle attack); The most common form of cryptographic verification is the Digital Signature. Digital Signatures are also an example of one type of “Asymmetric Cryptography” in which one of the primary benefits (usually at the expense of speed) is the ability to freely publish one-half of the complete cipher (hence the term “Public Key” cryptography).

While the issue of information security and cryptography is interesting in its own right, my primary concern is general multi-player gaming of one type or another (okay, to be fair, all types). While there hasn’t been much press regarding the security of on-line gaming, either mainstream or technical (outside of the perpetual dead-horse of griefing in SecondLife), it’s one that I’m fairly certain will cross over from “technical curiosity” to “absolutely required” in a short period of time. That’s not to say that no games have ever attempted secure communication between either client-server or client-client, however these have generally been focused on very specific issues; Usually either attempts to either prevent duplication of the game media itself (CD checks, for example), or stop common forms of on-line cheating (item duplication being the most notable). MMOs generally do require encrypted log-in credentials, and more often than not use some sort of custom, blanket encryption on their network protocols (see: World of Warcraft), but these types of security strategies are used to protect the Intellectual Property of the developer and stability of public servers, not as a means to ensure user privacy or security for the user.

The issue of user security in on-line game-play is one that appears simple at the outset: Encrypt communications, encourage the use of strong passwords, and verify user credentials. However, these solutions assume that there is one ultimate arbiter of legitimate game-play, or more practically several that are functionally identical in that they are as trustworthy as one another. This is functionally represented as the common “client-server” architecture used by most multi-player on-line games in which one or more clients exchange information with one server. The server acts a both the final arbiter regarding the rules of play, and the means by which clients communicate with one another (rather than directly in a peer-to-peer fashion). Because the server both referees the gameplay and manages communication between clients, the server may easily eject players in violation of the rules and prevent players from knowing too much about one other in situations that may create an unfair advantage for those willing to exploit the game (locations of other players who would otherwise be not visible, etc).

This presents a clear problem when attempting to develop systems of play that to not rely on a single arbiter of legitimate play. Without a server how can we be sure all players are both playing with the same rule-set and abiding by that rule-set? If players are directly exchanging information with one another regarding their particular game-states relative to one another, how can we prevent individual players from taking advantage of information that may give them an unfair advantage? Who becomes the de facto administrator responsible for maintaining fair-play? Some of these issues are more easily solved than others, obviously, but not all of them can be addressed technologically.

One answer to the questions of trust and fair-play is to leave those determinations up to individual players. The original implementation of the public-key cryptography suite, PGP, did the same thing regarding the issue of the validity of other users’ public keys; Trust networks could be formed between groups of people who would then have the ability vouch for new users. In practice it is the application of the power of a FOAF-like system. If you trust someone, you can reasonably reliably trust the people they trust, etc. Problems with the FOAF principal arise when you grow your network outside of what you can reasonably use as a tool for verification. While your friends-of-friends may be reliable, the friends-of-friends-of-friends may not be (at least not reliably). This solution suffers from the ability of massive numbers of malicious participants to overwhelm an individual’s ability to reasonably verify sources of trusted information.

Democratizing suffers from a similar problem: If you can vote a suspected cheater out of a game, it’s just as likely that a cheater can flood the game with illegitimate players that will stifle the process and probably vote out legitimate players who pose a threat. Unlike a client-server system it would be very difficult to verify that a group of players is not, for instance, one single player directing a group of “phantom avatars”. Most commercial MMOs prevent this simply by charging a fee and using credit card details as verification. Obviously it’s not fool-proof but the barrier is raised above what many potential dishonest players may deem reasonable.