spieleprogrammierer.de - Forum und Wiki zur Spieleprogrammierung und Spieleentwicklung

public/private Key? Ich denke, du meinst eher Klartext und Schlüsseltext? Gerade wenn man Fachbegriffe verwendet, sollte man sich ihrer Bedeutung sicher sein, sonst ist es besser und oft korrekter, es in Umgangssprache zu umschreiben. Musste ich nur mal bemerken.

Was du mit deiner Rechnung meinst, weiß ich gerade nicht, aber hier mal meine Gedanken:

AES zu benutzen ist eine gute Idee. Es ist das naheliegende und das was man immer tun sollte, wenn man keine sehr guten Gründe dagegen hat. Gut, du möchtest also verifizieren, ob ein Key korrekt ist und du möchtest in der Lage sein, beliebig viele, korrekte Keys zu generieren.

Wie wäre es hiermit: AES hat 128 Bit große Blöcke. In Hexdezimaler Schreibweise sind das 32 Ziffern, mit 32 verschieden Zeichen (Buchstaben + ein paar Zahlen, ohne 0 und O um Verwechslungen zu vermeiden) hättest du noch 26 Ziffern, mit 64 Zeichen (Alphabet groß/klein, Zahlen n paar Sonderzeichen) noch 22. In der Hexdarstellung kann man einen Block wunderbar kodieren, der CD Key ist dann zwar nervig lang, aber ok.

Jetzt ist die Frage, wie du den Key überprüfen kannst. Nun, wichtig ist, dass es nur wenige Keys gibt, die richtig sind, denn sonst könnte man einfach raten. Sehr einfach wäre folgendes Verfahren: Du sagst einfach, dass jede Zahl, die durch 2^64 teilbar ist, ein gültiger Key ist. Die letzten 64 Bit in deinem AES Block sind also alle 0, die davor beliebig. Diesen Block verschlüsselst du jetzt, und der verschlüsselte Block ist dann der CD-Key. Zur Überprüfung wird der Key wieder entschlüsselt und die letzten 64 Bit betrachtet.

Somit kannst du sehr einfach beliebig viele (bis zu 2^64, also unsinnig viele) CD-Keys generieren, und genauso einfach überprüfen. Ein Angreifer kann aber von beliebig vielen gesammelten Keys nicht auf weitere schließen. Und durch ausprobieren hat er nur eine Erfolgschance von 2^-64.

Da wir den CD-Key entschlüsseln können müssen, brauchen wir leider die vollen 128 Bit als CD Key. Dafür ist das Verfahren aber auch extrem sicher, da gegen AES noch keine brauchbaren Angriffe bekannt sind. Durch den EInsatz eines anderen Verfahrens könnte man aber auch mit kleineren Blockgrößen und somit kürzeren Keys auskommen.

Zitat von »Jonathan_Klein«

public/private Key? Ich denke, du meinst eher Klartext und Schlüsseltext?

Ich denke eher nicht, nein. Ich denke er meint wirklich public und private Key

Ich glaube aber auch, dass das größere Problem an der gesamten Idee ist, dass er den CD-Key nicht so verstecken kann, dass man ihn beim Kopieren der Software nicht gleich mitkopiert. Typisches Problem auch bei sehr gut gesicherten CD-Keys.

Also ich mach das so:

Zufallszahlen generieren und die zur Basis 36 konvertieren (36 = Großbuchstaben + Ziffern), dabei aber eine Lookup-Table benutzen, welche in anderer Reihenfolge ist, also nicht A-Z0-9 sondern kreuz und quer durcheinander (A65GOEWVN3Q...). Dann packe ich an eine bestimmte Stelle die Information um welche Art von Key es sich handelt (Demo, Vollversion, etc) und such noch ein paar Stellen raus, an denen ich eine Prüfsumme für den Key mit reinspeicher.
Zum validieren gucke ich dann, ob das Zeichen, dass an der Stelle für den Typ steht gültig ist (mann muss ja nicht alle Zeichen dafür benutzbar machen) und gucke ob die Prüfsummen stimmen.
Dabei kommt dann sowas wie "OE5GH-1H5D6-51AIH-1HHGT-EYHEO" raus.
Wenn ich meinen Kommentaren glauben schenken darf, dann sollte das für 7*10^32 verschiedene Keys reichen.

Das sollte reichen um Skriptkiddies zu verscheuchen. Wie immer gilt natürlich, dass jemand, der wirklich dahinter kommen will es auch irgendwann schaffen wird.

PS: Ich würde es übrigens ähnlich machen wie Sylence... sofern ich den Key auf der CD entsprechend verstecken könnte, ohne dass er beim Kopieren mitkopiert würde.
Ansonsten würde ich wohl eher irgendeine Online-Validierung machen, mit Ansprüchen je nach Anwendung individuell (Key bei Install checken, Login anfordern, Code/Key beim Startup runterladen und wichtigen Programmcode oder Daten damit zur Laufzeit entschlüsseln oder ergänzen, ...).

Zitat von »Pixma«

Also ich hatte dann auch gedacht, das zum Beispiel der CD Key, zu einem Server geschickt wird. Dieser vergleicht das dann und sendet zurück, zb.: True oder False.
Wahrscheinlich habe ich total falsch gedacht.

Was hintert den Benutzer daran, das Packet abzufangen und aus dem False ein True zu machen?

Es muss ja nicht unbedingt nur um einen Bool-Wert gehen. Es kann auch viel komplexer seien...

Ja, wenn der Key nur bei der Installation geprüft wird, musst du den Schlüssel ja mitliefern, das ist ein potentielles Risiko. Bei der Variante mit dem Server muss man natürlich wieder aufpassen, dass man diesen nicht einfach aushebeln kann. Schickt er einfach nur einen Wert zurück, könnte man diesem leicht emulieren, indem man einfach das selbe Paket generiert und der Client gar nicht mit dem Server spricht. Man braucht also eine Art Challenge-Response Protokoll um sicher zu sein, dass die Antwort vom Server kommt.Also zum Beispiel SSL.

@Sylence: Dein Verfahren steht und fällt mit der Art der verwendeten Prüfsumme. Die Lookuptabelle ist im Prinzip witzlos, die erhöht die Sicherheit nicht wirklich. Damit es sicher ist, bräuchte man schon einen kryptografischen Hash, der irgendwie ein Password benutzt, damit ihn der Angreifer nicht selber berechnen kann. Sowas gibt es natürlich alles schon in fertig, aber damit ist der Implementationsaufwand immer noch etwas höher, als in meinem Vorschlag.
Natürlich muss es nicht unbedingt super sicher sein. Man kann sich einfach irgendeine simple Prüfsumme ausdenken und benutzen, es ist trotzdem noch schwer zu knacken. Die Frage ist nur, wieso sollte man eine eigene Lösung benutzen, die komplizierter zu implementieren ist, als ein Standardverfahren, das sehr viel sicherer und schneller eingebaut ist?

@Pixma: Den Algorithmus habe ich eigentlich schon komplett informal beschrieben. Wo hakt es?