Verifying server software integrity?

Question

I'm trying to brainstorm a security scheme for the problem of verifying server software integrity. The domain of this problem is Game Servers built on Valve's Source Dedicated Servers. These servers are used in competitive gaming, and the integrity of these servers can be incredibly important in running tournaments and whatnot.

Game clients are already verified quite well in a number of ways by Valve's Steam system. Because of various content-verifying and anti-cheat systems (VAC), we can be fairly sure that no client-side content is modified.

However, on the server side, there are little to no protection schemes in place to ensure that clients are playing on unmodified versions of the software. The software itself is inherently configurable (through config variables and commands), and it allows extensions on functionality through Server Plugins. In addition, there are no checks on the server code on filesystem or in memory. SRCDS servers are inherently modifiable on many levels.

This poses a problem in competitive gaming on the Source engine. It is possible for any number of ConVar modifications, plugins, or server binary modifications could be used to "cheat"--to give an advantage in gameplay mechanics to one team over another, or one player over another. There is currently no way for a client or third party to verify that the SRCDS server is unmodified.

The basic solution to this issue seems to be open-ness. We can make changes to ConVar values be announced to clients, make lists of plugins running on the servers available to clients, and even do CRC checks on files on disk and in memory and provide clients with resulting values. However, none of this can be differentiated from a server which falsifies the announced/provided information. Anything down this path essentially feels like obscurity rather than security.

How can I design a system to verify server software's integrity using only challenge/responses to that server?

P.S. Feel free to ask questions or ask for more specifications.

Answer 1

What a great question. I think this is one of the things that divides the games industry- do you centralise your servers to keep control over them, but then suffer from lack of flexibility to gamer needs and be accused of ruling with an iron fist or do you give control over to the gamer population and run the risk of malicious or tainted servers.

Three thoughts occur to me- none are ideal, but might be of use.

1. Announce configs to clients- this won't put off major compromise of the server but will increase the effort required from the malicious party.

2. Go down the route of trust and reputation, and have gamer rate servers whether they think they are honest or not. This also has issues, and rep can be gamed too but it is another option.

3. Provide the server software as a module you can query (a la punkbuster and valve's own checks) and disable on inconsistencies. Again, it has been proven again and again that this type of thing will be broken at some point as someone analyses the code to understand what response to send back, and it will annoy server owners, but it will also increase the effort required from the malicious party.

Answer 2

It seems highly unlikely that you'll be able to be confident of answers that you get directly from the server you don't trust. Seems like you need a third party to vouch for it. E.g. find a way to get a cloud service provider to attest to the fact that the operator has loaded a given iso image on some standard hardware and has subsequently only communicated with it thru a certain port which is tied to a well-constrained configuration interface. I've wondered before if any of the cloud providers do that....

Answer 3

In principle, there are technical solutions. You could make sure your servers all contain a TPM, and use remote attestation to have the server attest to each client that it is running the legitimate server-side software.

However, in practice there are significant engineering challenges, which may make this approach not terribly realistic, or more expensive than it's worth in your setting. For instance, clients now need to have a way of obtaining the master list of what versions of software are authorized; servers need to be programmed to use the TPM hardware (which is a bit of a specialty operation); schemes need to be devised to ensure that the integrity of the server software cannot be compromised after attestation; and other challenges. This all sounds like an engineering and management hassle of major proportions.

Unfortunately, TPMs' remote attestation capabilities are not widely used today, so you can't build on the efforts and experience of others. So, if you wanted to take this approach, you'd be on the bleeding edge. Sounds like the kind of thing that would make a program manager run screaming.

Therefore, I probably wouldn't recommend this approach to a small independent software vendor, even though in principle I suspect it could probably be made to provide reasonably decent security against the kind of threat you mention (if you had unlimited resources).