Masterserver <-> dedicated server security

Hello everyone,

I’m currently thinking of some aspects of one of my projects. Actually, I’ve solved some problems I had a couple of months ago (i.e. user authentication through web services to verify if a user may or may not play a game, etc).

In my initial game idea I was thinking of hosting my own servers on which the gamers may play. Unfortunately this would mean a lot of maintenance and management from my side. To offload that burden from my shoulders, I’m more targeting to create dedicated servers that can be hosted by anyone.

Looking at other dedicated servers of other games, I can see that some use special keys to identify the dedicated server. This helps to secure any data transmission which has an influence on the player statistics and to make sure that the information is actually coming from a server authenticated to send critical information.

Has anyone implemented such a system? Is this the right way to go?

My goal is to have in-game usage of items that have been bought through micro-transactions. Would I need additional security to handle this in-game purchasing?

Normally, I’d say that the game verifies via the master server if a player still has access to an item. I’d do this whenever the game client sends a message to the game server about the usage of the item.

Dependent on the number of players (i.e. 5000 players in 160 games (160 dedicated game servers)), wouldn’t that flood the master server? Has anyone an idea how games such as Battlefield: BC2 handle this? They are actually storing the player information online and update it throughout online gaming to reflect the current rank, unlocked items, etc).

Thanks for sharing your ideas and your experience.

Metron

Hi Metron,

I am sorry that I didn’t see this post earlier. I might be able to help. Three years ago, Dice approached my team, asking us to replace their lobby system for their BF games. We got a detailed view of how they had solved it but also what they were unhappy with and how they wanted it changed. Since we sadly declined their generous offer, because we were busy with other stuff, we do not know what they finally ended up with. But I can ask them.

However, the problem you describe is very general. We have, as you know, been developing our own master server in uLink that would not have any problems tackling what you describe. I could walk you though our design of it and you’d know what we think is a great solution. In our upcoming uLink 1.1, it will even be improved with some very unique features (and battle tested in a popular game very much like the one that you described). The uLink master server can very easily handle the number of players and game severs that you are visioning. And so would any well implemented solution. You do not need to worry about that. But in general terms, you could use a Unity server as a central server that handles all the player data / stats and that talks to all the other game servers via P2P. Security could be handled the way that we have done it and that you can read about here. But I will ask Aidin to flesh out how anyone would be able to start their own dedicated servers - but you could easily do that too.

All in all, no matter if you use uLink or implement it yourself, we would gladly help you. I hope this short overview made you more comfortable with your design and please empty your head with any questions that it might have caused.

(I could have also mentioned uLobby but since it is still in development, it feels a bit premature.)

Hi Christian,

thanks for your insights.

My initial idea wasn’t to have a Unity server as the master server, holding player stats. That would be overkill in terms of allocated resources. The master server itself would not hold any game logics but “only” validation code for the incoming statistics and player purchased item usage. The master server would connect to a DB where player information is stored.

Thinking of it, a different RSA key for each dedicated server would do the job. This means that the master server itself would have to handle a different RSA key for each registered dedicated server. This way the communication between this single dedicated server and the master server would be secure and back-ended by the validation code. Combined with version and crc check on the executable the risk of encountering a manipulated dedicated server could be low.

I really start to get a better picture of the master server ↔ dedicated server communication and security, which is a good thing. Things are shaping up… now I have to find the time to implement some of the stuff :slight_smile:

Hi Metron!

I understand your choice of design, it is the reflex choice. It also the reflex choice to disregard unity (-batchmode) as a central server. Unity has a bad reputation as a server, which is simply not true. We have done tests in extreme conditions with low resources and I would gladly share our results with you.

Your designing a very specialized master server which will likely be hard to reuse for other applications and also inflexible to future game changes. As I’m sure you know it is also really easy to get stuck in building building-blocks and it’s very hard to predict future needs. Also, version and CRC checks are unfortunately too easy to hack to secure micro-transactions. I would recommend something like this:

Take advantage of ready to use building blocks, so you can focus on making the game, and let micro-transactions be encrypted by the client with a public key which only the central server knows the private key pair to. The communication between central server ↔ dedicated server then doesn’t need to be secure since the dedicated server can not read it, although encryption between them wouldn’t hurt and would still be needed for player stats. We would till have the problem that a dedicated server could cheat, with stats, but that’s the price for letting others host.

Pretty harsh words, I’d think. At his own account, it was his second thought after thinking it through. But I agree with your main points:

  • A general approach is better to start with. It can later be replaced by an optimized one if needed.
  • The Unity server is much better than people say (but we really need to put the number out and find a way that allow people to test it themselves).
    (Your third point: of course security is always important but in this specific case I do not have the knowledge to say either way)

Hi Aidin,

I understand. But the master server enhancements are not that big. In fact, this can be done via quite simple plug-ins. But then, I think your uLobby will need some of the features (ie. DB connection for user login, storage of generic user information, etc). Architecture wise, the master server is contains a subset of the lobby server.

I’m getting my head around the user authentication. I was planning to do the authentication via web services. After successful authentication, the user would be able to retrieve a list of running games. I might realize this indirectly by authenticating the user against a web service which delivers a password for a master server (handling this internally in the code, the player never would see the password, although it will be visible if anyone does some packet sniffing). If the master server would provide some kind of user authentication (via i.e. a plugin system), I could drop my web service stuff and would only have one point of access…

Following your idea of Unity as a central server, I would set up a P2P connection between the central server and the dedicated server, and authorative server connections between the dedicated server and the game clients, right? If I have 160 dedicated servers running, do I need only 1 uLinkNetworkP2P in the central server or would I need to do something else?

Thanks for answering my (stupid) questions :slight_smile:

Metron,

No question is stupid. =) But you would not need anything else than uLink.

We talked a little bit about your problem with the other guys in the team. Since it is so general, we thought it would be best to actually make an example project out of it and have it up on our dev site. It might take a couple of months time before we get it up, but the idea is to make a full blown example of the kind of game you are planning. It is so much easier to show than tell =)

Ah, you are fishing for information about uLobby! Well, uLobby is still in beta but when it is ready, it will have a complete and mean feature list. It will be of the same high standard that we measure all our technology by. We will put more information up on the homepage soon.