[Author Prev][Author Next][Thread Prev][Thread Next][Author Index][Thread Index]

Re: Bit on cheating: was: Re: Introductions



Hi,

> > > - encrypt/obfuscate network traffic.
> >
> > Wont work with open source though :-)
>
> Ah, this hits the weak spot of open source games: Once you get hold of the
> source code, you can do anything with it, especially adding cheat code
> within the actual game logic. So the bottom line is that you can trust
> neither server nor client by default, which is a very unpleasant situation.

I don't think so, because having the sourcecode is only marginally easier than 
having the binaries. Reverse-Engineering is too easy.

What it really needs here is a Trustworthy Computing Plattform, something like 
Palladium, that has the feature of remote attestation. With remote 
attestation a player can remotely attestate against the server and against 
all other players that he is playing fair.
And this would only really make sense when the Games are OpenSourced, because 
only then every player can inspect, whether the game itself is fair, and what 
the attestetated fairness really means.

> I think that the easiest countermeasure is to provide players with the
> means to rate - and maybe even ban - players that are obviously cheating.
> However, this must be done in a democratic process, or the cheaters
> themselves might use it in revenge on honest players. Such a model does not
> need a very sophisticated design, but will need some kind of moderation to
> actually work.

Well, I am not really sure how you can counterfeit vote-cheating.
Secure voting is still an extremely hard problem in the crypto-branche.

> This is an interesting approach. However, I do not understand how they are
> able to hide the key in their binaries. Given the statistic characteristics
> of a cryptographic key (quite a lot of keys look like they are an almost
> perfect stream of random numbers, mostly because how they are generated),
> you should be able to make it out within the file within minutes. Using
> strace or gdb on a nethack session might give you quite some extra hints on
> the location of the key.

Come on. Never heard of Steganography? 
There are enough easy and standard expansion methods. Base64, Hexadecimal, ...
Hexadecimal storage divides the Entropy by 2, but you can have any individual 
expansion method you want.
And you can easily design a key-storage system, if you need that.


> To the key to this approach is to effectively hide the key from prying
> eyes, within a region, on which the user has the ultimate control. How can
> you possibly do that?
>
> Additionally, this is not possible with true free software licenses like
> the GPL, as the binaries and sources that you distribute must actually
> correspond exactly. So you would be force to publish the unobfuscated key
> along with the code. The only alternative I see now is to use the BSD
> license. IIRC, nethack is under a BSD-style license, right?

Why? The Key is data, not sourcecode. I don't think that it violates the GPL.

But you should notice, that simple Knowledge-based-Proofs are fundamentally 
flawed for remote attestation!
With a Knowledge-based proof (like storing a secret key in a binary, and 
having a zero-knowledge protocol to attestate the knowledge of the key 
against the other players and the server), you only attestate knowledge, but 
not behaviour.

It is the difference between knowing how to play fair and actually doing it!
With Knowledge-based Proofs you only attesttate that you know how to play 
fair, but nobody knows whether you are really playing fair, and you can 
easily attestate you knowledge while cheating at the same time.

So what you need is a trusted third-party (you have to trust it, and all other 
players have to trust it) that controlls whether you are really playing fair, 
and that attestates those controlling-results to the other players (and the 
server).

This trusted third-party can be other players on LAN-parties for example, who 
are watching the game, or it can be a Palladium like platform for 
Internet-game scenarios.

Many greetings,
Philipp Gühring
Futureware 2001