[prev in list] [next in list] [prev in thread] [next in thread] 

List:       kde-games-devel
Subject:    [Kde-games-devel] Solution for highscores
From:       George Staikos <staikos () kde ! org>
Date:       2001-05-02 22:35:58
[Download RAW message or body]


Ok I am posting this info now but I don't plan to do anything about it for at 
least another week (if then). 

I have been considering the concept of a system-wide KDE highscores system 
for months now.  It took me a little while to work out the details but I 
think I have come to a working solution.  This solution requires a suid 
binary _or_ a daemon listening on a port/socket.  I think a suid binary is 
better.  This is not a KDE binary.  It's simply a binary that takes a score 
for a game and updates the highscore file if necessary.

So here's how it works:

/usr/share/apps/khighscores/gamename.his
(for example...   a highscores file for a game)
They will be stored in order and will be similar to this format:
"Name"     <delimiter>    "score"     <delimeter>     "Game specific info"

This way additional info can be stored for each score.  (sometimes a level 
achieved is included along with points, for instance)

Now these files are world readable but only uid "games" or uid "root" (or 
something similar) writeable.

When a game concludes, it will call a class in libkdegames which will open a 
socket or popen() or execv() or system() the binary and transmit the score to 
the suid app which can then determine if it is a new high score and insert it 
in place.   The app can then read the new highscores file and display it to 
the user.

So what's to stop any user from saying "add this new highscore"?

Encryption
--------

Each game will have an encryption key (or even asymmetric keys) generated at 
install time.  The decryption key is stored in (example) 
/usr/share/apps/khighscore/gamekeys and this file is mode 600.  That way the 
suid binary can read it but no-one else can.  Now how does the game encrypt a 
message?  Simple.  We put a sentinel on the stack in the binary, and at 
install time when the keys are generated, we edit the binary directly and 
replace the sentinel with the encryption key.  Then install the binary.  What 
is to stop a user from debugging the app and finding the key?  Well, as far 
as I can tell, as long as a binary is installed "executable" but not 
"readable", then it is not ptrace()able and thus not debuggable (and 
certainly not readable or copyable).  The only thing that can be done is an 
strace, and this will never give the encryption key.

So, what we do is encrypt the "message" for the suid binary with the cipher, 
and append a cryptographic hash of the message for use as an authentication 
code.  (try to detect if the message has been tampered with - probably 
excessive, but it's easy and the code is already done for doing this).  The 
suid binary decrypts this, checks the hash, then does it's work and returns 
an error code.


Weakness
--------

I can only think of one weakness.  That is, obtaining random data will be 
traceable with strace.  This basically prevents us from making plaintext 
attacks harder.  Thus a good algorithm must be chosen for the encryption 
algorithm.  Yes anyone with root can do things..  You can't stop this.  You 
shouldn't try to because you're wasting your time if you do try.


Editting the binary is only necessary when you don't compile from source.  
However, since most users don't compile from source, there's no point in 
supporting both compile time and install-time key embedding.

This can be configurable on a per-game basis also.  A game could have 
multiple highscore catalogs, varying highscore sizes (top 10, top 100, etc), 
just as an example.  The games that are allowed to register will be listed in 
the gamekeys file along with their key.

We can even ship the binary for generating key-pairs so the admin can 
regenerate new keys if he wishes.  This shouldn't be difficult at all.




So there you have it.  I don't see how this is cheatable, but perhaps I've 
missed something.  I'm tired and I'm still not done exams (I just finished 
writing one within the last hour or so).  The details might need minor work, 
but the overall process is the key here.  Hopefully I haven't left anything 
out.  As for implementation, I'm not sure that I can commit to helping you 
guys do this before 2.2, but I can provide the crypto algorithms.  I'm 
already doing that now in KOffice and am hoping to move the whole framework 
to kdelibs with a customizable, dynamically loading system.


No opening 1000's of homedirs on a school system everytime you finish a game. 
No suid/sgid KDE apps.
No hope of cheating.
No problem!

-- 

George Staikos

_______________________________________________
Kde-games-devel mailing list
Kde-games-devel@master.kde.org
http://master.kde.org/mailman/listinfo/kde-games-devel

[prev in list] [next in list] [prev in thread] [next in thread]