I am writing a score server for client/server games such that various games can talk to one server. Each game would thus register for a name/password and use that in their code to send data to the server.
Now, putting aside all the problems with cheat detection found in closed source software, it seems my problem is exacerbated by the need to distribute full code to make the client (this will be the AGPL so server code is also included).
Does anybody have some good references, or good ideas, on how this can be accomplished, such that each game client can uniquely identify itself with the server? That is, how can I adequately protect some "keys" in a completely AGPL project?
NOTE: I already understand the problem with detecting cheaters, and I realize this is a part of the same problem. I'm just hoping that somebody has an idea that the most basic identity of a game client can be protected.
edA-qa mort-ora-y wrote:
Each game would thus register for a name/password and use that in their code to send data to the server.
Seems simple enough.
it seems my problem is exacerbated by the need to distribute full code to make the client (this will be the AGPL so server code is also included).
The general consensus is "The attacker already knows the algorithm" thus revealing the source should not be a problem. Compilation is NOT a secure way of hiding something anyway.
Does anybody have some good references, or good ideas, on how this can be accomplished, such that each game client can uniquely identify itself with the server?
HTTPS? You might want to look at OpenSSL. Some programming languages may have in built libraries for doing the kind of Asymmetric Cryptography you need.
That is, how can I adequately protect some "keys" in a completely AGPL project?
Protect from whom? This is in fact one of the most important questions. If your just trying to protect a users login details then it's unlikely they are going to try to breach their own security (and it's their own fault if they do).
I would doubt you would need to reveal the Decryption key for the AGPL server. Just make sure the key isn't actually *in* the software. Make it a separately key file. For instance Apache doesn't have a users SSL key compiled into it, it is provided separately. (IANAL)
If of course you are putting keys in the client and trying to hide these keys from the person running the game then that isn't technically possible (even with proprietary code).
You should try to answer the following questions: What data needs to be secured? Where is that data is stored? Where is that data is being transferred from/to? Who is that data is being secured from?
Andy
Andy wrote:
The general consensus is "The attacker already knows the algorithm" thus revealing the source should not be a problem. Compilation is NOT a secure way of hiding something anyway.
I agree, but at least it prevents casual abuse of the server. That is, a bit of obfuscation is likely enough to rid the game of the majority of cheaters or abusers. I agree it does nothing to deter the hardcore attacker.
Protect from whom? This is in fact one of the most important questions. If your just trying to protect a users login details then it's unlikely they are going to try to breach their own security (and it's their own fault if they do).
I can make this clearer, there are three "entities" involved: 1. The Server 2. The Client 3. The Player
The server has no problem with identity, it knows who it is. The Player will authenticate with a known safe protocol (HTTPS and MD5 password possibly), and will be prompted for his password when he connects.
The question comes to the identity of the "Client". Basically I want to server an official client, let's call it "WhatNots". Now, the source if completely open, and I wish to encourage everybody to make their own version of "WhatNots", but I don't want those copies to be able to identify as the official client with the score server.
I know this problem in the commercial game world, basically the one of preventing cheaters. But that world has the advantage of using obfuscation in their authentication algorithms.
You should try to answer the following questions: What data needs to be secured?
The integrity of the scoring data on the server. It wishes only to accept scoring data from authorized clients (that is, the official game clients).
Where is that data is stored?
On the server.
Where is that data is being transferred from/to?
Produced by the client, transferred to the server.
Who is that data is being secured from?
People with unathorized clients attempting to give themselves inflated scores.
edA-qa mort-ora-y eda-qa@disemia.com writes:
Andy wrote:
The general consensus is "The attacker already knows the algorithm" thus revealing the source should not be a problem. Compilation is NOT a secure way of hiding something anyway.
I agree, but at least it prevents casual abuse of the server. That is, a bit of obfuscation is likely enough to rid the game of the majority of cheaters or abusers. I agree it does nothing to deter the hardcore attacker.
In designing your protocol, you need to assume that once a single "hardcore attacker" crafts an exploit, they can quickly redistribute it to "the majority of cheats or abusers".
On Sun, 2008-04-20 at 11:12 +0200, edA-qa mort-ora-y wrote:
The question comes to the identity of the "Client". Basically I want to server an official client, let's call it "WhatNots". Now, the source if completely open, and I wish to encourage everybody to make their own version of "WhatNots", but I don't want those copies to be able to identify as the official client with the score server.
I know this problem in the commercial game world, basically the one of preventing cheaters. But that world has the advantage of using obfuscation in their authentication algorithms.
You should try to answer the following questions: What data needs to be secured?
The integrity of the scoring data on the server. It wishes only to accept scoring data from authorized clients (that is, the official game clients).
Where is that data is stored?
On the server.
Where is that data is being transferred from/to?
Produced by the client, transferred to the server.
Who is that data is being secured from?
People with unathorized clients attempting to give themselves inflated scores.
You have a trust problem, and there is no other way to solve it than to eliminate the problem of trust or to fully trust.
An easy solution (in term of trust) is to remove the problem. Never trust the client, always compute whatever you need to trust only server side.
If you need to trust the client for other reasons (performance for example), then the only way to fully trust it is by using a trust computing platform against the users, something free software does not really like to do unless there is agreement from the user.
edA-qa mort-ora-y eda-qa@disemia.com writes:
I am writing a score server for client/server games such that various games can talk to one server. Each game would thus register for a name/password and use that in their code to send data to the server.
Now, putting aside all the problems with cheat detection found in closed source software, it seems my problem is exacerbated by the need to distribute full code to make the client (this will be the AGPL so server code is also included).
Does anybody have some good references, or good ideas, on how this can be accomplished, such that each game client can uniquely identify itself with the server? That is, how can I adequately protect some "keys" in a completely AGPL project?
The first thought that occurs is that the keys should not be part of the source, i.e. that the programs should be fully functional without the *specific* keys you will be using for your service.
This is analogous to a client and server that use TLS to communicate: the client and server both have secret keys, and exchange the corresponding public keys at the start of the connection. The server can be configured so that it will refuse connections from clients that fail to present an already-known (i.e. registered) public key for the session.
In fact, what is stopping you from simply using public key cryptography to authenticate both ends of the connection?