Verschlüsselung von Serials

[nt2005]

Hallo Community,

Ich bin auf der Suche nach ein oder mehrere Verschlüsselungssystemen mit folgenden Ziel.

Ich programmiere eine Erweiterung welches an eine Applikation gebunden ist.
Diese Applikation hat eine Seriennummer. Jeder Benutzer besitzt genau eine Seriennummer von der Applikation.

Mit einem Teil der Seriennummer und etwas Geld in der Hand kann ein Benutzer meine Erweiterung kaufen.

Er erhält von mir eine Seriennummer, die generiert wurde aus der Teilseriennummer aus der Applikation.
Beim Einbinden der Erweiterung in die Applikation prüft meine Erweiterung meine Seriennummer mit der Seriennummer der Applikation. Stimmen diese über ein, kann der Benutzer die Erweiterung verwenden.

Der springende Punkt an der Stelle ist, dass ich gerne ein sichere Seriennummer aus der A.-Seriennummer generieren würde.

Mein erste Versuch war, die A.SN zu verschlüsseln (Zeichen austauschen, Shiften) und dann dies über RSA zu verschlüsseln.
Nun habe ich jedoch erfahren, das RSA einen Public Key verwendet um zu verschlüsseln und einen Private Key zum entschlüsseln. Das ist natürlich nicht das was ich will, da ich ja verhindern will, das jeder eine SN generieren kann.

Möglichkeit wäre einen Symmetrischen Key zu verwenden, jedoch ist das nicht sicher genug (meiner Meinung nach) da man hier ja die Erweiterung dekompilieren kann und den Key rauslesen könnte.

Die Suche nach einem Asynchronen Verschlüsselungsprinzip mit PrivateKey lief leider erfolglos.

Jemand eine Idee was ich machen könnte um dies zu realisieren?
Ein Hinweis noch: Ich verwende die Cryptopp Biblothek.

[Razor1911]

Schau mal auf www.crackmes.de da könntest du ein paar Denkanstöße bekommen.

[nt2005]

Hmm, hilft mir auf erster Linie nicht wirklich weiter.

Ich bin zurzeit am überlegen ob dies sicher ist (in groben Zügen):
Ich nehme die A.SN und signiere sie mit RSA.
Die Signierung gebe ich an den Benutzer weiter und dieser verwendet das Signum als Serial. Und meine Erweiterung schaut ob dieses Signum mit dem vom A.SN übereinstimmt bzw. gültig ist.

[otze]

nt2005 schrieb:

Nun habe ich jedoch erfahren, das RSA einen Public Key verwendet um zu verschlüsseln und einen Private Key zum entschlüsseln. Das ist natürlich nicht das was ich will, da ich ja verhindern will, das jeder eine SN generieren kann.

Die Keys sind genau umgekehrt. du verschlüsselst mit dem private key und entschlüsselst mit dem public. Und das ist ja genau das, was du willst:

Um einen Schlüssel zu generieren, braucht der Benutzer ein Geheimnis(= den private key). Hat er den Key nicht, kann er den Schlüssel nicht erzeugen. Andererseits soll das Programm von sich aus entschlüsseln können, also braucht es den Public Key. Das heißt es ist für das Programm einfach zu validieren, ob der Schlüssel echt ist, aber es ist schwierig für Aussenstehende den Schlüssel zu erzeugen.

Den Schlüsselaustausch sicher hin zu kriegen ist damit kein Problem. Die eigentliche Frage ist: wie umgehst du, dass der Benutzer dn Schlüsselaustausch nicht einfach umgeht?

[nt2005]

otze schrieb:

Die Keys sind genau umgekehrt. du verschlüsselst mit dem private key und entschlüsselst mit dem public. Und das ist ja genau das, was du willst:

Richtig. Du hast recht, jedoch finde ich keine Möglichkeit dies in Cryptopp zu machen. Wenn ich PublicKey und PrivateKey vertausche stürtzt meistens die Anwendung ab...
Das habe ich als einziges gefunden:
http://www.cryptopp.com/wiki/Raw_RSA#Private_Key_Encryption

Jedoch der Vertausch von e und d ist jetzt, wie ich finde, nicht die Hürde (3, 17 oder 2^16+1) zu erraten.

otze schrieb:

Den Schlüsselaustausch sicher hin zu kriegen ist damit kein Problem. Die eigentliche Frage ist: wie umgehst du, dass der Benutzer dn Schlüsselaustausch
nicht einfach umgeht?

Sicherlich meinst du damit Cracken. Ja, da hast du recht. Dafür werde ich mir die Seite einmal anschauen, die Razor verlinkt hat.

[Bitte ein Bit]

Hmm, warum nimmst du nicht einen anderen, einfacheren Algorithmus wie RC4/RC5? Die sind einfach zu implementieren und erlauben so einige Parametrisierungen.

Wenn du dein Kopierschutz implementiert hast, lade dir unbedingt OllyDbg oder besser IDA Pro Free herunter und versuche deinen eigenen Code zu knacken ! Was nützt dir die beste Verschlüsselung der Wert wenn ein Cracker hingeht und deine Kopierschutzüberprüfung im Assembly überspringt ?

[SeppJ]

Bitte ein Bit schrieb:

Hmm, warum nimmst du nicht einen anderen, einfacheren Algorithmus wie RC4/RC5? Die sind einfach zu implementieren und erlauben so einige Parametrisierungen.

Das sind symmetrische Verfahren und somit hier ungeeignet. Schließlich stünde dann der Schlüssel zum erstellen einer gültigen Serial irgendwie abgreifbar im Programm, da er zum Entschlüsseln benötigt wird.

[otze]

nt2005 schrieb:

Richtig. Du hast recht, jedoch finde ich keine Möglichkeit dies in Cryptopp zu machen.

Dann machs anders rum. Namen sind Schall und Rauch, der Algorithmus zählt.

[Bitte ein Bit]

Das sind symmetrische Verfahren und somit hier ungeeignet. Schließlich stünde dann der Schlüssel zum erstellen einer gültigen Serial irgendwie abgreifbar im Programm, da er zum Entschlüsseln benötigt wird.

Hmm, die Beschränkung auf symmetrische Verfahren war so ganz und gar nicht von mir gemeint. Sondern ich plädiere eher für eine Verwendung von vielen verschiedenen Maßnahmen mit Blendern, Hashes, diverse Verschlüsselungsverfahren + Anti Reverse Engineering Maßnahmen.

Gewiss, der Schlüssel steht bei RC4 im Speicher. Aber so schlimm finde ich das nicht, wenn man an die Anti Reverse Engineering Maßnahmen bedenkt, die in jedem koperigeschützten Programm sein sollte. -> Code obfuscation: Man könnte beispielsweise hingehen, die Fouriertransformierte eines festgelegten Signal berechnen, die Transformierte dann mit einem delta T (= berechnet aus der Seriernnummer) abtasten und das resultierende Signal als Schlüssel nehmen...

Aber was nutzt mir eine dicke fette Verschlüsselung wenn ein Cracker hingeht, das Programm in einen Debugger lädt, das Programm bis zu dem Freischaltedialog ausführt, und den Kopierschutz mittels ein zwei Assemblerbefehlen umgeht ?

Für mich ist das ein Eintwicklungsprozess für Kryptografie + Anti Reverse Engineering, abhängig von dem möglichen Umsatz des Programms. Je teuerer das Programm, desto gemeiner und vielfältiger sind die Methoden.

[SeppJ]

Bitte ein Bit schrieb:

Aber was nutzt mir eine dicke fette Verschlüsselung wenn ein Cracker hingeht, das Programm in einen Debugger lädt, das Programm bis zu dem Freischaltedialog ausführt, und den Kopierschutz mittels ein zwei Assemblerbefehlen umgeht ?

Nichts. Deshalb würde ich es allgemein nicht machen. Aber hier kann man leicht ein Verfahren haben, welches sich eben nur durch Cracken des Schutzes umgehen lässt, wohingegen bei symmetrischen Verfahren ein sehr großer Aufwand betrieben werden soll, damit man ein vermeintlich einfacheres Verfahren benutzen kann, welches dann aber am Ende doch angreifbar ist. Sehr guter Tausch .

Schlimmer noch: Denn nach einmaligem Angriff (der gar nicht so schwer ist, denn irgendwann muss der Schlüssel irgendwo im Speicher stehen) steht der Masterkey zur Verfügung! Somit hat man gleich einen universell benutzbaren Keygen, mit dem sich jeder andere Nutzer ganz einfach Serials generieren kann. Bei einem Kopierschutzcrack ist die Hürde wesentlich größer, da man einem bekannten Hackerprogramm Zugriff auf den eigenen Rechner geben muss und Cracks allgemein Schwierigkeiten mit wechselnden Programmversionen und Patches.