RLCTF/Protokolle

Diese Seite behandelt Kommunikationsprotokolle (oder besser gesagt Protokollideen) zum RLCTF, bzw. Scannergame Projekt.

Ein paar Worte zur Krytographie

Asymmetrische Kryptographie ist insbesondere für offline Transfers von Vorteil, da man die Identität eines Spielers oder die Authenzität eines Ereignisses unmittelbar durch seine Signatur verifizieren kann. Leider ist asymmetrische Kryptographie auch immer sehr rechenintensiv und kann auf einem Microcontroller nicht ohne weiteres durchgeführt werden.

Selbst wenn ein ECC Verfahren zum Einsatz kommt, benötigt man eine Library, die es laubt mit großen Zahlen zu rechnen.

Im folgenden werden Protokolle diskutiert, die in akzeptabler Zeit auf einem Microcontroller ausgeführt werden können. Es ist zusätzlich auch möglich, diese Protokolle (in Teilen) offline auszuführen

Token Austausch

Tokens sind bestimmte (Punktbringende) Ereignisse, Virtuelle Objekte oder Eigenschaften die sich ein Spieler während des Spiels aneignen kann. Bei tokens ist es wichtig, das sie verifizierbar sind - auch ohne Kontakt zum Server zu haben.

Offline Token Protokoll

Zu Spielbeginn erhält das Gerät jedes Spielers eine Liste mit Hashsummen:

hashsum_1
hashsum_2
  .
  .
hashsum_n

Diese Hashtabellen sind Hashsummen der eigentlichen Tokens, die jeweils mit den Identitäten einer für jeden Token un Untergruppe von Spielern Kokateniert werden:

hashsum_k = hash ( token_k || ID_a || ID_b || ... || ID_m )

Wenn ein Spieler einen Token vom Server oder einem Gerät im Spiel erhält, so wird ihm vom Server eine Nachricht gesandt, die die Liste der Identitäten für den Token, sowie den token selber enthält. Mit diesem Wissen kann er nun anderen Spielern der Geräten gegenüber beweisen, das er diesen Token besitzt... (indem er genau diese Nachricht auf Anfrage raussendet).

"Wie jetzt? Dann kann doch jeder Spieler einfach die Nachricht einfach wiederholen und so tun, als besäße er den Token?!". Ja, natürlich kann er das! Dazu muss er einfach die Nachricht selbst aussenden... Aber halt: Nicht umsonst werden (für jeden Token unterschiedliche) Untergruppen von Spielern vom Server generiert. Diese beschränken zum einen schonmal für einen Betrügerischen Mitspieler die möglichen Tokens auf eine bestimmte Anzahl. Nicht jeder Spieler kann jeden beliebigen Token aussenden. Ferner ist es möglich, betrügerische Spieler eindeutig zu identifizieren: Sendet ein Spieler verschiedene falsche Tokens aus, so lässt sich der Betrüger in der Schnittmenge der Identitäten in den Tokens finden.

Die Bildung von Untergruppen ist nötig, um die Tabelle der Hashsummen und damit den Speicherverbrauch auf den Geräten gering zu halten. Andererseits ist es aus Speiltechnischer Sicht zum Schutz vor betrügerischen Spielern auch nötig, die Anzahl der Spieler in einer Untergruppe möglichst gering zu halten (idealerweise ist diese = 1). Die Größe der Untergruppen kann selbstverständlich auch pro Token variieren - es wäre z.B. möglich, besonders "wertvolle" Tokens mit nur kleinen Benutzergruppen zu erstellen.

Bei einem gleichgewichteten Kompromiß aus Speicherbedarf und Cheatschutz ist die Größe der Tabelle das zweifache der Anzahl der möglichen Token wenn man beabsichtigt, das jeder Spieler eine gleiche Anzahl möglicher Token haben kann.