Return to Revisions

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.