I wish to setup a room-based multiplayer game model where players may host matches and serve as host (IE the server with authoritative power). I wish to host a master server which tracks player's items, rank, cash, exp, etc.
In such a model, how can I prevent someone who is hosting a game (with a modified server) from spoofing the master server with invalid match results, thus gaining exp, money or rankings.
It's been pointed out that my previous answer may have been based on a misunderstanding of what you meant by "spoofing". (If so, please let me know and I'll delete it.)
If what you want to prevent is the game servers sending bogus data to the master server, then — as Jari Komppa notes — that's generally impossible to prevent completely. In fact, it's simply a variant of the classic multiplayer cheating prevention problem, except with the intermediate servers rather than the clients being the ones suspected of cheating. Many of the same techniques used for traditional cheating prevention could work here too, but as usual, none of them are completely foolproof.
That said, there are some things you could do that would specifically help against cheating servers. One of them would be to have each player in a match separately contact the master server and confirm that they're participating in that match. (You'll probably want to do that before the match begins, so that you can make sure everyone agrees who the participants are and so that nobody's tempted to claim they didn't participate in a match they lost. You could use digital signatures to defer that, though; essentially, you could have every player in a match sign a message saying "I'm player X and I'm participating in match M on server S at time T with players Y, Z and W." and send it to the game server, which can later relay it to the master server.) That way, you can at least ensure that a cheating server can't affect the rankings of any player who doesn't actually play on that server.
This is particularly useful if you're using something like Elo ratings where player ranking mostly depends on their relative performance. Sure, someone running a bogus server might still create a bunch of fake accounts and submit results saying that their own account beat the fake ones, but with a relative ranking system, all that will do is make the cheater's account rank slightly above the fakes (which in turn will have rock bottom ratings).
Another obvious thing to do to discourage cheating is to let players verify their match results directly from the master server. If a player wins a match on a new server, but the results sent to the master server say that they lost (or if the results are never sent at all), that will let them know that something fishy is going on. Hopefully, at that point they'll either report the server for cheating, or at least vote with their feet and never play on that server again.
In fact, you could make this automatic: after each game, once the results have been sent to the master server, have the clients fetch them back from the master server and compare them to how the client thinks the game ended. If there's a mismatch, report it both to the player (so that they'll know something's wrong) and to the master server (so that you can detect cheating servers). Of course, as the operator of the master server, you'll then need to decide who's lying — the server or the player — but hopefully in most cases that will be fairly obvious from the pattern of reports.
Note: This answer may be based on a misunderstanding of the question — see comments below.
Short generic answer: use digital signatures.
Specifically, the master server should have a private key for a suitable digital signature scheme (RSA, DSA, ECDSA, etc.) and should somehow securely relay its public key to all the clients. Then the server can sign any data it sends to clients with the private key (or possibly use it to negotiate a shared secret usable for symmetrically encrypting and/or authenticating communications between it and that particular client) and the client can use the public key to verify that the signature has been generated by the server.
Of course, your next problem is distributing the public key so that a rogue server can't spoof that and substitute its own public key. That might not be so hard if you can do it in advance (e.g. distributing the key along with the game executable), but it gets tricky if you have to do it later, for example because the identity of the master server is not known in advance. One standard solution is to distribute some other public key (whose corresponding private key is known only to you) in advance to all the clients, and then sign the message containing the master server's public key with that other key before broadcasting it.
In fact, you could even extend such signature chains further — say, have one super-secret master private key, which is kept locked in a safe somewhere and whose public key is known to all clients, and another "daily use" private key which is used to actually sign the server keys, and whose public key is itself signed with the super-secret master key before it's locked up in the safe. This is not that useful by itself, but it becomes potentially very useful if you also include some mechanism to revoke compromised keys, so that e.g. if your daily use key is leaked, you can just revoke it and generate another one.
What I describe above is a rudimentary kind of public key infrastructure. Actually implementing one securely can get quite complicated, but fortunately it's been done before. In fact, whenever you connect to a website (like Wikipedia) using HTTPS, this is pretty much exactly what you browser does: it receives a public key certificate from the server, verifies that the certificate matches the server name in the URL, is not listed as revoked and has been signed by a known and trusted certificate authority, and then uses it to negotiate a temporary symmetric encryption key known only to itself and to the owner of the private key corresponding to the certificate. This symmetric key is then used to encrypt and authenticate all data sent between the client and the server.
In particular, you really should take a look at existing SSL/TLS libraries (which typically come with an X.509 PKI implementation), or possibly at SPKI. These are still somewhat complicated, but probably easier (and more secure) than trying to roll your own.
This depends on the nature of the game and on the reason you're offloading the server role.
In certain circumstances you might be able to mostly achieve this with cryptographic audit logs. E.g. if it's a two-player turn-based game and you can arrange for each client to have a private asymmetric key for signature purposes, you can have a protocol along the lines of
At the end both clients submit the result to the central server, and if they disagree then they submit the audit trails: (S1, C1, m1), (S2, C2, m2), etc. Since each player has signed their moves, they are committed to them.
It's still vulnerable to one player DDOSing the other to prevent them submitting their result, but there really isn't much you can do about that.
NB This is just a quick sketch - I'm sure that if you post it to crypto.stackexchange.com someone will poke massive holes in it - but I think the principle is sound. Get whatever scheme you design reviewed by someone who knows their stuff before you start relying on it.
