Overview of requirements

The library is targetted to offer a central organized authentification system. Through using  digital signatures we can asure that a new user just need once contact to the central organization and then can use this key on any server without further contact of the client or the server to the masterserver. Phase 2 of the project will be adding a same concept for approving stats between server and client, so that compromissed servers can be found much easier and so offer a concept to secure the integrity of stats and give a "ranked server" concept for any public servers TODO: More detailed Phase 2.

The players of the game

• Client - The client of the user that actually displays the data of the game via awesome cool 3D engines which always kicks ass ;). The client can be a cheater with modified source

• Server - The server where the client of the game connects to gather with the other clients. The server can be compromised with modified source

• Masterserver - The only clean guy in the play. It is a central server (or a distributed trusted server concept) where the player "registers" his nick so that he can asure that his nickname is bound to this key. Actually its not required that there has to be a nickname saved with the key. It depends on the game, but because the player somewhere must see in game who they talk to, its highly recommended for easy approve.

The problem

The problem that has to be solved is farly easy in explaining, we want to secure the player as who he is. You could think of a concept like Steam, which assures that a specific Steam_ID is exactly this player. But the problem about Steam is that it 100% works with a central server for all exchange. Also the servers who support this are not open source, this all together makes it secure, but only as long as Steam runs, it fails if Steam is down. Implementing such a loosy solution is farly easy for open source games, even with source, noone can block against a fully client <=> masterserver <=> server <=> client communication. But open source games, dont have the resources to handle a 100% available masterserver mostly. Even an outage of an hour could block out several players from doing what they normally do: Playing with their identity. Some still can play if they dont care about their identity, but the gameplay is hardly broken if "it doesnt care what you do".

The solution

As easy as the problem is explained as easy can be the solution. We use  digital signatures to guarantee any data from any point. We can put the way of working in the following simplified workflow:

First Time

• Client generate key
• Client gives public key request to Masterserver
• Masterserver puts approved player infos and his public key into a signed package that identifies him and gives it back to Client

Per Connection

• Client sends signed package to the Server
• Server checks if package is really signed by Masterserver and if so, checks if the public key of the connection matches the one in the package. This way the server approves this way the informations for himself.

More exactly: Usage Example for discussion

Using libs

Of course, we use any lib that can help our way, which is multiplatform so that it can be integrated very easy into the game engines. So far we plan to use  libgcrypt for the encryption and signing concepts we need.