Software mit Registrierungsschlüssel schützen

Hey Leute,
ich habe eine Windows Forms Applikation entwickelt und würde diese gerne kommerziell vertreiben. Da ich natürlich nicht möchte, dass sie nach dem einmaligen erwerb weiter verbreitet wird möchte ich sie schützen. Und hier fangen meine Probleme an 😉

Als Methode habe ich mir Folgendes überlegt:
Bei Programmstart wird überprüft, ob ein gültiger Registrierungsschlüssel existiert, falls nein wird eine entspr. Meldung angezeigt und das Programm lässt sich nicht starten.

1. Wie implementiere ich so einen Schlüssel "richtig"?
   Meine Gedanken dazu: Ich denke mir ein Pattern für den Schlüssel aus, z.B.
   5 Gruppen á 5 Zeichen [Nummern und Zahlen]
   Jede Gruppe enthält mindestens eine Zahl
   Die Summe der ASCII Werte aller Gruppen ergibt.. kA 2367
   Diese Pattern wird dann beim Programmstart überprüft.
   Jetzt würde ich einen Algorhytmus schreiben, der solche Schlüssel erstellt und diese dann an meine Kunden rausgeben.
   ==> Soweit meine Gedanken OK? Oder wie macht man das "richtig" / Links zu Tutorials?

2. Wie und wo speichert man einen Schlüssel?
   Damit der User nicht bei jedem Programmstart den Key eingeben muss, muss ich ihn irgendwo speichern. Wie und wo mache ich das am besten? einfach ein .txt File in den Ordner der Applikation schreiben wäre wohl etwas zu simpel? Ich habe an einen Wert in der Registry gedacht, habe damit aber keine Erfahrung und weiß auch nich, ob sowas üblich ist?

3. Wie schütze ich mein Programm vor der illegalen Weitergabe?
   Ich weiß, großes Thema 😉 Mir gehts aber eigentlich eher um Folgendes: Wie kann ich verhindern, dass jemand, der einen gültigen Schlüssel besitzt (gekauft hat), diesen zusammen mit dem Programm ins Internet stellt? Damit kann ihn ja jeder kostenlos herunterladen.. Oder übersehe ich hier irgendwas?

Gedankengang hier zu: Jeder Schlüssel, den ich herausgebe wird in einer DB auf meinem Webserver gespeichert, bei der ersten Eingabe Aufforderung des Keys zum Programmstart muss eine Internetverbindung bestehen und der Key wird mit der DB abgegelichen. wenn er nicht existiert => gecrackter Key, soweit ok. Was aber wenn er schon existiert? Dann könntes es sich ja auch um eine Neuinstallation des zahlenden Kunden handeln...

==> Macht der Gedankengang so Sinn oder sollte ich von dieser Mehtode generell Abstand nehmen? Ansonsten, wie wird sowas üblicherweise realisiert?

4. Wie schütze ich meinen Quellcode?
   Ich glaube ehrlich gesagt nicht, dass sich jemand die Mühe macht das Programm zu cracken.. Dafüt wird der Preis einfach zu niedrig sein. Allerdings möchte ich dennoch einen "rudimentären" Schutz einbauen, so dass der Cracker nicht einfach zu mittels Dissasemblierung zu dem oben erwähnten "if" springen kann und dieses auskommentiert. Außerdem muss ich natürlich verhindern, dass der Cracker meinen Key Algorithmus findet, sonst könnte er ja einen KeyGen erstellen. Reicht es in diesem Fall, den Code zu obfuskieren? Kenne mich damit (nocht) nicht weiter aus, aber habe schon ein paar mal darüber gelesen. Also fraglich ist, ob das Obfuskieren es schon "sehr merklich" erschweren würde, die o.g. Stellen (Key Algo + IF) zu finden.

Soo, das wärs erstmal. Ich hoffe hier könnt mir zumindest bei ein paar Punkten weiterhelfen 😃

Viele Grüße
Hamster

Hallo Hirnhamster,

vorneweg: von dem Gedanken von (ständigen) Online-Prüfungen solltest du dich dringend verabschieden. Das stellt eine unangemessene Benachteiligung deiner Kunden da. Gerade wenn du nur eine kleine Firma hast oder sogar als Einzelunternehmer auftrittst, würden die Kunden bei Geschäftsaufgabe, Insolvenz o.ä. das bezahlte Programm nicht mehr nutzen können. Mal ganz abgesehen von den Regressansprüchen, die auf dich zukommen, wenn der Lizenz-Server mal nicht verfügbar ist.

Aber es geht eigentlich sehr einfach und effektiv:

zu 1-3:

Erstelle eine XML-Datei, in der die Daten den Kunden enthalten sind. Pack außerdem eine feste GUID mit in die Datei. "Verschlüssele" die Datei mit deinem privaten Schlüssel. Schick die "verschlüsselte" Datei (=Lizenzdatei) an den Kunden. Der kann sie dann im Programmverzeichnis ablegen.

Dein Programm enthält den öffentlichen Schlüssel und kann damit die XML-Datei entschlüsseln. Nun schaut es, ob die GUID stimmt und wenn ja ist alles gut.

Zwar kann dann der Kunde die Lizenzdatei weitergeben oder ins Internet stellen, aber dann stellt er ja automatisch seine Daten mit ins Netz und kann jederzeit zurückverfolgt werden. Das ist sehr abschreckend und der bestmögliche Schutz.

Ein weiterer Vorteil: Selbst wenn jemand durch Reenginieering die GUID und den öffentlichen Schlüssel ermittelt, kann er trotzdem keine gültige Lizenzdatei erstellen, weil er den privaten Schlüssel nicht kennt.

EDIT: Um das Ergebnis der nachfolgenden Diskussion zu meinem Vorschlag vorwegzunehmen: Auf der theoretischen Ebene von asymmetrischen Verfahren funktioniert mein Vorschlag so wie beschrieben. Damit er auch auf der praktischen Ebene von .NET funktioniert, sollte man nicht die Verschlüsselungs- sondern stattdessen die Signierfunktionen verwenden.

zu 4.

Siehe [FAQ] .net Assembly vor Disassembling schützen (Obfuscator)

Ansonsten wurde das ganze Thema schon öfter besprochen. Bitte benutze die Forumssuche und poste die besten Treffer hier. Vielen Dank!

herbivore

Hallo herbivore,
danke für deine Antwort. Ernsthaft, finde dein Engagement hier bemerkenswert 😉

vorneweg: von dem Gedanken von (ständigen) Online-Prüfungen solltest du dich dringend verabschieden. Das stellt eine unangemessene Benachteiligung deiner Kunden da. Gerade wenn du nur eine kleine Firma hast oder sogar als Einzelunternehmer auftrittst, würden die Kunden bei Geschäftsaufgabe, Insolvenz o.ä. das bezahlte Programm nicht mehr nutzen können. Mal ganz abgesehen von den Regressansprüchen, die auf dich zukommen, wenn der Lizenz-Server mal nicht verfügbar ist.

Sehr gut.. spart mir auch ne Menge Aufwand 😃

Das mit der Verschlüsselung der XML Datei hört sich gut an, kannst du mir dazu noch ein-zwei Stichwörter nennen? Muss ich den Algorhitmus dafür selbst schreiben oder gibt es vorgefertige Klassen, die ich benutzen kann? Entspricht die GUID in diesem Zusammenhang dem Registrierungsschlüssel, den ich in meinem vorherigen Post erwähnt habe?

Bzgl. Forensuche: Habe die üblichen Verdächtigen im Vorfeld probiert (Software schützen, Lizensierung, Registrierungsschlüssel) aber keine auf meine Fragen passenden Antworten gefunden.

Grüße
Pascal

Hallo,

Das mit der Verschlüsselung der XML Datei hört sich gut an, kannst du mir dazu noch ein-zwei Stichwörter nennen? Muss ich den Algorhitmus dafür selbst schreiben oder gibt es vorgefertige Klassen, die ich benutzen kann? Entspricht die GUID in diesem Zusammenhang dem Registrierungsschlüssel, den ich in meinem vorherigen Post erwähnt habe?

Die GUID dient wohl nur dazu um die Lizenz eindeutig zuweisen zu können. Kann ja durchaus zwei Lizenznehmer mit dem gleichen Namen geben.
Als Verschlüsselungsmethode benötigst du einen asymetrischen Verschlüsselungsalorithmus, z.B. RSA. Dieser ist auch im .NET Framework implementiert, mit "RSA" und "Signatur" solltest du fündig werden 😃

Cheerio

Hallo Maximilian,

Die GUID dient wohl nur dazu um die Lizenz eindeutig zuweisen zu können. Kann ja durchaus zwei Lizenznehmer mit dem gleichen Namen geben.

nein, in meinem Vorschlag ist die GUID eindeutig für das Programm. Es gibt also nur eine einzige GUID für alle Installationen. Diese ist im Code des Programms hinterlegt und in allen (gültigen) Lizenzdateien.

Im Prinzip könnte da jede beliebige Zeichenfolge stehen. Es geht nur darum zu erkennen, ob die Lizenzdatei gültig ist. Also ob nach dem Entschlüsseln tatsächlich der Text dasteht, den man erwartet.

Ich habe nur deshalb geschrieben, dass man eine GUID nehmen kann/soll, weil das eine Zeichenfolge ist, die lang und eindeutig genug ist, damit die Wahrscheinlichkeit, dass eine Übereinstimmung zufällig zustande kommt, gering genug ist. Im Prinzip kann man sich die GUID auch ganz sparen, denn alleine durch die Prüfung, ob man nach der Entschlüsselung gültiges XML bekommt, stellt man mit ausreichender Wahrscheinlichkeit sicher, dass die Lizenzdatei tatsächlich mit dem privaten Schlüssel verschlüsselt wurde. Wenn nicht würde man ja nur Zeichensalat bekommen, aber sicher kein XML.

Hallo Hirnhamster,

was die vorgefertigen Klassen angeht, hat Maximilian schon das wesentliche genannt. Du kannst auch einfach in System.Security.Cryptography schauen.

Dass du keine Threads gefunden hast, kann ich kaum glauben. Ich habe auf Anhieb mindestens mal folgendes gefunden, in dem es mehr oder weniger um dein Problem geht:

Lizenzierung / Key / Serial / Seriennummer
Programm vor Weitergabe schützen
Aktivierungsmanager selbst programmieren
Aktivierung soll notwendig sein, aber Was? Wie? Wann? Wo?
Aktivierungsschlüssel oder nicht?
Software zeitlich begrenzen

Und hier noch ein paar:

Lizenzierungsmechanismus für Program selbst programmieren (da steht sogar schon mein Vorschlag, wenn auch nicht so ausführlich beschrieben)
Lizenzdatei mit SHA1-Signature ok?

herbivore

Hey herbivore,

Im Prinzip könnte da jede beliebige Zeichenfolge stehen. Es geht nur darum zu erkennen, ob die Lizenzdatei gültig ist. Also ob nach dem Entschlüsseln tatsächlich der Text dasteht, den man erwartet.

Moment ... Wenn ich mich nun nicht komplett täusche kann man Daten nur mit dem PrivateKey entschlüsseln. Ergo müsste man dem Programm diesen beilegen (wo auch immer) was das ganze absurd macht da man sich mit dem PrivateKey auch eigene Lizenzen ausstellen könnte. Oder irre ich mich jetzt da?

Sinnvoller fände ich die Lizenzdaten + die GUID als einen String zusammen zufassen, dann von diesem String mit dem Private Key eine Signatur zu erstellen (RSAPKCS1SignatureFormatter) und diese Signatur der Lizenzdatei beizufügen. Das Programm fasst dann bei der Überprüfung ebenfalls die Daten zusammen und checkt die Signatur auf Gültigkeit (RSAPKCS1SignatureDeformatter), dazu reicht der Public Key. Falls du das so gemeint hast, dann sorry, habe ich anders verstanden 😃

Hallo Maximilian,

Moment ... Wenn ich mich nun nicht komplett täusche kann man Daten nur mit dem PrivateKey entschlüsseln.

nein, es geht in beide Richtungen. Natürlich kann die Daten dann jeder entschlüsseln, der den öffentlichen Schlüssel hat. Sie sind also nicht (besonders) geheim. Aber darum geht es ja auch nicht. Es geht darum, die Authentizität der Daten zu prüfen und genau das erreicht man damit.

Oder irre ich mich jetzt da?

Ja, du irrst dich. 😃 In dem Programm braucht man nur den öffentlichen Key.

Falls du das so gemeint hast, dann sorry, habe ich anders verstanden 😃

Letztlich ging es mir darum, den Effekt einer Signatur zu erreichen. Klar kann man das auch explizit mit den Signatur-Funktionen machen. Hätte dann sogar den Vorteil, dass die XML-Datei im Klartext wäre und nur eine kryptische Signatur enthalten würde, die man dann gegen den (restlichen) Inhalt der Datei prüfen würde.

herbivore

Vielleicht hilft es, sich auch einmal die kommerziellen Lösungen anzuschauen, vor allem wenn Du folgendes (später einmal?) realisieren möchtest:
*Freischaltung von Programmfunktionen über generierte Schlüssel *Unterstützung von Wartungsverträgen *Mehrbenutzerbetrieb *Online-Aktivierung

Wie gesagt, das lohnt sich nur wenn die Anforderungen vorhanden sind. Aber dann kann die Thematik schnell komplex werden.

Meine ehrliche Meinung dazu...

Ich sträube mich persönlich gegen solchen wilden und strikten Mechanismen, nur damit einer meint niemand dürfte seine Software dazuverwenden, um sie illegal weiterzugeben oder sonstwie illegal zu verwenden. Dabie ist es doch so: je mehr Leute deine software nutzen, desto bekannter wird sie. Du solltest nicht davon ausgehen, dass gleich jeder, der deine Software nutzt, gleich den illegalen Weg sucht, und eine gehackte Version verwendet. Die allermeisten Anwender kaufen ganz legal ihre Software, zumal wenn es sich um unter 50 Euro Artikel handelt. Durch solche Sperrmechanismes schreckst du die Anwender nur ab, und eine gescheite für jedermann akzeptierte Lösung findest du sowieso keine... Zumindest keine hausgebackende und auf die Schnelle.

Ich bin der Meinung, der Entwickler sollte erstmal seine Potential in die eigentliche Anwendung selbst stecken, anstatt sich um irgendwelche Sicherheitsmechanismen zu kümmern, die sowieso NIE zu 100% funktionieren. Jede Software kann geknackt werden, es muss nur interessant genug sein, für einen Hacker. Ob das bei einer kleinen Applikation gleich der Fall sein wird, wag ich zu bezweifeln. Also... anstatt tagelang in irgendwelchen abstrusen Seriennummergeneratoren und Online Prüfung und co zu stecken, lohnt sich imho mehr diese Zeit z.B. für gescheite Dokumentationen, Marketing, Webauftritt usw. zu nutzen, damit überhaupt einmal jemand aufmerksam auf deine Software wird. Sollte sich das die Sache tatsächlich zum Kassenschlager entwickeln, so wirst du sowieso früher oder später eine neue Version herausbringen. Und wenn du dann immer noch der Meinung bist, deine software müsste unbedingt geschützt werden, dann nimm eine 200 von deinen 10.000 verdienten Euro aus der Tasche und investier sie in ein fertiges, funktionierendes Tool. Davon gibt es genügende.

So... Jetz wär das auch geschwätzt 😃

Hallo Jelly,

ich bin im Grunde der gleichen Meinung wie du und habe das ja auch schon an verschieden Stellen im Forum so klar vertreten wie du. Insbesondere wenn die Kopierschutzlösungen die berechtigten Interessen der zahlenden Kunden beeinträchtigen (und das ist sehr schnell und bei sehr vielen Kopierschutzlösungen der Fall) und illegale Nutzer mit gecrackten Versionen besser gestellt sind als die zahlenden Kunden mit ihren "geschützten" Version, läuft etwas verkehrt und ich könnte mich darüber stundenlang aufregen. Zumal nicht mal klar ist, ob die Hersteller damit überhaupt besser fahren, denn es gibt sicher viele Kunden, die so wie ich solchermaßen "geschützte" Software gar nicht erst einsetzen, also auch nicht kaufen.

Auf der anderen Seite habe ich nichts gegen einen vernünftigen Ausgleich zwischen den Interessen der Hersteller und den der Kunden. Das Interesse des Herstellers, die illegale Verbreitung zu verhindern oder zumindest einzuschränken, ist genauso legitim, wie das Interesse des Kunden, seine legal erworbenen Produkte ohne spürbare Einschränkungen einsetzen zu können.

Und die hier beschrieben Lösung mit einer nicht versteckten und damit "backup-baren" und auf neue (Ersatz-)Hardware übertragbaren Lizenzdatei finde ich vollkommen ok. Das schränkt den Benutzer nicht spürbar ein und erfüllt gleichzeitig das Schutzinteresse des Herstellers. Wie bei so vielem liegt die Lösung in einem ausgewogenem Kompromiss.

herbivore

Ich habe mal mit einem Sales-Mann einer Firma gesprochen, die große kommerzielle Lizenz-Lösungen anbieten. Dort kann man die Lizensierung undabhängig vom zusätzlich "Knack-Schutz" kaufen. Der sagte interessanterweise, dass nur 10% seiner Kunden sich für eine "sichere" Lösung entscheiden. Allerdings handelte es sich dabei auch um große kommerzielle Anwendungen, die i.d.R. nicht auf Crack-Seiten auftauchen. Dem normalen Business-Anwender werden wohl keine großen kriminellen Ambitionen zugetraut....

Auf der anderen Seite habe ich nichts gegen einen vernünftigen Ausgleich zwischen den Interessen der Hersteller und den der Kunden. Das Interesse des Herstellers, die illegale Verbreitung zu verhindern oder zumindest einzuschränken, ist genauso legitim, wie das Interesse des Kunden, seine legal erworbenen Produkte ohne spürbare Einschränkungen einsetzen zu können.

Die Meinung vertrete ich ja auch, wenn sie auch nicht so klar aus meinem letzten Post hervorkam.

Wir reden aber hier von einem kleinen Tool, das scheinbar für ein paar Euros zu erwerben wäre, und dessen Quellcode für Hacker wohl noch nicht einmal von grossem Interesse zu sein scheint. Für solche Software tue ich mir allerdings sehr schwer, dann irgendwelche komplizierten Registrierungsmethoden anzuwenden, damit ich als Endanwender in den Genuss der Vollversion komme.

Und was ist, wenn der "kleine Softwareschmiede" von nebenan plötzlich morgen die Meinung vertritt, anstatt Software zu entwickeln lieber einer anderen Tätogkeit nachgeht, oder er die Freizeit vielleicht nicht mehr aufbringen kann, die Software weiter zu pflegen. Haben dann unter Umständen die ganzen Anwender Pech, wenn sie ihre erworbene Software neu installieren müssen, aber keinen Support mehr kriegen um sie neu zu registrieren. (Ich sag nur hardwareverknüpfte Registrierungsschlüssel).

Hallo Jelly,

Haben dann unter Umständen die ganzen Anwender Pech, wenn sie ihre erworbene Software neu installieren müssen, aber keinen Support mehr kriegen um sie neu zu registrieren.

ganz deine Meinung. Darauf habe ich ja schon ganz oben hingewiesen:

Gerade wenn du nur eine kleine Firma hast oder sogar als Einzelunternehmer auftrittst, würden die Kunden bei Geschäftsaufgabe, Insolvenz o.ä. das bezahlte Programm nicht mehr nutzen können.

Das trifft auf meinen konkreten Vorschlag aber gerade nicht zu:

Und die hier beschrieben Lösung mit einer nicht versteckten und damit "backup-baren" und auf neue (Ersatz-)Hardware übertragbaren Lizenzdatei finde ich vollkommen ok.

Damit ist auch eine Neuinstallation problemlos möglich.

herbivore

Erstelle eine XML-Datei, in der die Daten den Kunden enthalten sind. Pack außerdem eine feste GUID mit in die Datei. "Verschlüssele" die Datei mit deinem privaten Schlüssel. Schick die "verschlüsselte" Datei (=Lizenzdatei) an den Kunden. Der kann sie dann im Programmverzeichnis ablegen.

Dein Programm enthält den öffentlichen Schlüssel und kann damit die XML-Datei entschlüsseln. Nun schaut es, ob die GUID stimmt und wenn ja ist alles gut.

Das geht so aber nicht. Man kann nicht mit dem private key ver- und dann wieder mit dem public key entschlüsseln. Anders herum schon.

Das Konzept geht so nicht auf. Würdest du der Anwendung den private key mitgeben und die XML mit dem public key verschlüsseln hat man nichts von der ganzen Sache da der public key vom private key hergeleitet werden kann und somit dann auch eine neue Lizenzdatei mit der GUID und anderem Firmennamen erstellt werden kann...

Gruß,
moson

Hallo moson,

Das geht so aber nicht. Man kann nicht mit dem private key ver- und dann wieder mit dem public key entschlüsseln. Anders herum schon.

doch, das kann man. In diesem Fall macht das so auch Sinn. (Generell funktioniert das so natürlich nicht zur Verschlüsselung einer Nachricht, da diese ja von jedem gelesen werden kann, der an den öffentlichen Schlüssel herankommt - also praktisch von jedem. Bei einer digitalen Signatur ist das sogar gewollt, da so die Urheberschaft der Nachricht gesichert werden kann - verschlüsselt wird die Nachricht dadurch allerdings nicht.)

Hier macht es jedoch Sinn, die Lizenzdatei mit dem privaten Schlüssel zu verschlüsseln, da nur der Urheber (Hirnhamster) diesen besitzt. Sein Programm entschlüsselt die erhaltene Lizenzdatei mit dem beigefügten öffentlichen Schlüssel und vergleicht anschließend beide GUIDs. Der Clou dabei ist, dass ein Anwender, der seine Lizenzdatei anderen zur Verfügung stellt, private Daten von sich bekanntgibt, die mit in der Lizenzdatei enthalten sind, was letzten Endes zu einer abschreckenden Wirkung führt. Die Lizenzdatei kann er, der Anwender, auch nicht selbst generieren und falsche Daten beifügen, da er dafür den privaten Schlüssel benötigt.

m0rius

Oh sorry, wusste nicht dass das signieren so funktioniert. War zu sehr auf Verschlüsselung fixiert 😃

Hallo moson,

es hätte ja gereicht, wenn du etwas weiter im Thread gelesen hättest, denn weiter oben kam derselbe Einwand schon mal und da hatte auch schon begründet, warum es eben doch geht und warum das Konzept eben doch aufgeht.

herbivore

Hey,
ich melde mich dann auch mal wieder 😉
Ich habe mich während der letzten Tage über die oben genannten kryptographischen Verschlüsselungsmethoden informiert, da ich davon bisher nur rudimentäre Kenntnisse hatte - deshalb auch so lange keine Rückmeldung von mir.

Ich stelle mal vornweg meine aktuelle Frage und beschreibe im Anschluss meinen bisherigen "Leidensweg" für die Nachwelt, die vor den gleichen Problemem steht wie ich 😉

Frage:
Gibt es eine Möglichkeit, Public und Private Key abhängig von Eingabeparametern zu erstellen, so dass ich die keys im Notfall erneut erzeugen kann? Also z.B. Ich will den String "diesIstMeinGeheimesPasswortMitHilfeDessenIchImmerDasGleichePublicPrivateKeyPairErzeuge" benutzen und damit dann immer die gleichen Public/privat Keys bekommen.

Hier folgt die Story:

Ich beschreibe hier mal die Probleme, auf die ich dabei als Laie gestoßen bin:
1. RSA als asynchrones Verschlüsselungsverfahren
Erste Anlaufstelle war RSACryptoServiceProvider Class - hier wird auch ein Beispiel zur Ver- und Entschlüsselung beschrieben. Bei dieser Implementierung war es aber aus irgendwelchen Gründen nicht möglich, mehr als 117(?) Zeichen oder so zu Verschlüsseln. Auf der Suche nach dem Grund dafür wurde es mir dann zu abstrakt, weil ich von der Thematik zu wenig Ahnung hatte.

Das führte mich zu Punkt 2:

2. Warum kein synchrones Verfahren
Ich habe dem public/private Key Aspekt zunächst keine Beachtung geschenkt, weil ich dachte: Die Lizenz muss ja einfach nur verschlüsselt werden, ohne das entsprechende Entschlüsselungspasswort kommt ja niemand an die Daten und kann diese manipulieren oder neue Lizenzen erzeugen.
Mit dieser (falschen) Prämisse habe ich mich dann für AES als synchronen Verschlüsselungsalgorithymus entschieden und mit Hilfe von dieser gut Dokumentierten Beispielklasse zur AES Verschlüsselung umgesetzt. Die Doku ist wirklich leicht verständlich und die Klasse leicht anpassbar.
Damit konnte ich nun meine Lizenz beim Erzeugen verschlüsseln und durch mein Programm entschüsseln.
ABER: Nun kommt der Punkt von herbivore ins Spiel, dass dann jeder, der den Schlüssel, also das Ent-/Verschlüsselungspasswort kennt, gültige Lizenzen erzeugen kann. AES ist synchron, deshalb ist dieser Schlüssel zum Ver-und Entschlüsseln gleich und muss außerdem fest in mein Programm (zum entschlüsseln der Lizenzen) integriert sein. Wenn nun jemand die .exe meines Programms disassembliert, dann sieht er sowohl den Schlüssel als auch den Algorithmus zur Erzeugung => Dadurch kann der Cracker beliebige neue (gültige) Lizenzen erzeugen und verschlüsseln.

Sry wenn das für den Rest hier von vornherein offensichtlich war - ich war vorher der Meinung, dass man den Schlüssel nur durch Bruteforce rausbekommen würde - und in dem Fall wäre es egal ob man nen Synchronen oder Asynchronen Algorithmus benutzt 😉 Aber wie gesagt, mein Fehler.

Soo... nach diesem "Misserfolg" gehts also wieder zurück zu RSA und jetzt stehe ich vor Punkt 3:

3. Wie erzeugt man bei RSA immer den gleichen Public/Private Key
Nach erneutem Googlen nach RSA bin ich auf diesen Artikel auf Codeproject zur RSA Encryption gestoßen. Das funktioniert wunderbar auch mit längerem Text (Quellcode runterladen und testen!). Allerdings werden hier Public und Private Key automatisch generiert, in einer XML gespeichert und von dort wieder geladen. Generell spricht ja nichts dagegen, das so zu machen, man muss ja lediglich die XML Dateien mit den Schlüsseln sicher aufbewahren. Aber es kann ja immer mal passieren, dass die Festplatte den Geist aufgibt und man kein Backup hat. In diesem worst-case Szenario hätte man nun keine Möglichkeit mehr, neue Lizenzen zu erzeugen, da ich keinen Private Key mehr hätte, der die Lizenz passend für meine (schon an die Kunden verteilten Programme) erzeugen kann. Wenn jetzt nen Kunde die Lizenzdatei "verliert" kann ich keinen Ersatz liefern.

Deshalb an dieser Stelle meine Frage:
Gibt es eine Möglichkeit, Public und Private Key abhängig von Eingabeparametern zu erstellen, so dass ich die keys im Notfall erneut erzeugen kann? Also z.B. Ich will den String "diesIstMeinGeheimesPasswortMitHilfeDessenIchImmerDasGleichePublicPrivateKeyPairErzeuge" benutzen und damit dann immer die gleichen Public/privat Keys bekommen.

Wenn ihr bis hierher gekommen seid bedanke ich mich für die Aufmerksamkeit ^^

Viele Grüße
Hamster

Hey, noch ein Nachtrag...

Gefordert is folgendes Szenario:
Verschlüsseln mit private Key,
Entschlüsseln mit public Key

Das das nicht dem eigentlichen Sinne der Verschlüsselung entspricht, wurde bereits vorher im Thread erwähnt. Allerdings ergibt sich ein neues Problem, denn laut diesem Thread zur RSA Encryption mit privatem Schlüssel ist das oben geforderte Szenario mit dem RSACryptoServiceProvider nicht möglich.

Nachdem ich ein paar mal erfolglos probiert hab, public und private key zu tauschen, bin ich letztendlich über diesen Eintrag gestolpert..

Edit:

Nachdem die oben gennante Methode nicht zu funktionieren scheint, bin ich auf Signierung umgestiegen. Siehe dazu
Gewusst wie: Signieren von XML-Dokumenten mit digitalen Signaturen und
Gewusst wie: Überprüfen der digitalen Signaturen von XML-Dokumenten

Dabei bekommt der verschlüsselnde RSACryptoServiceProvider den privaten Schlüssel und der entschlüsselnde den öffentlichen und nicht wie auf den o.g. Seiten beide die gleichen CspParameters.. sont hätten ja beide sowohl private als auch öffentliche Schlüssel.

Jetzt funktioniert es einwandfrei und die Lizenz kann sogar als Klartext eingesehen werden.. glaube kaum das jemand sowas freiwillig ins inet stellt 😉

Viele Grüße (und gute Nacht 0o)
Hamster

Hallo Hirnhamster,

Generell spricht ja nichts dagegen, das so zu machen, man muss ja lediglich die XML Dateien mit den Schlüsseln sicher aufbewahren.

eben!

Aber es kann ja immer mal passieren, dass die Festplatte den Geist aufgibt und man kein Backup hat. In diesem worst-case Szenario hätte man nun keine Möglichkeit mehr, neue Lizenzen zu erzeugen,

Dass eine (einzelne) Festplatte den Geist aufgibt, ist sicher nicht das Worst-Case-Szenario. Und warum sollte man kein Backup haben? Gerade von einem wichtigen privaten Schlüssel würde man sicher mehrere Backups erstellen. Hier würde man sogar mindestens ein räumlich getrenntes Backup erstellen.

... da ich keinen Private Key mehr hätte, der die Lizenz passend für meine (schon an die Kunden verteilten Programme) erzeugen kann.

Wenn du nicht mal für den private Key ein Backup hast, wäre das sicher dein geringstes Problem, weil ja dann wohl die Quellen des Programms erst recht weg wären.

Wenn jetzt nen Kunde die Lizenzdatei "verliert" kann ich keinen Ersatz liefern.

Wenn du die Quellen des Programms noch hättest, wäre es nämlich kein Problem, einfach ein neues Schlüsselpaar zu erzeugen und dem Kunden eine damit erstellte Lizenzdatei und eine passende EXE zu schicken. Denn es ist ja nicht erforderlich, dass du die Lizenzdatei mit einem ganz bestimmten private Key erstellst, sondern nur dass der private Key zu dem öffentlichen Key der EXE passt.

Nachdem ich ein paar mal erfolglos probiert hab, public und private key zu tauschen, bin ich letztendlich über diesen Eintrag gestolpert..

Welcher Key privat ist und welcher öffentlich, wird ja letztlich nicht durch ihre Namen bestimmt, sondern dadurch, welchen der Schlüssel man tatsächlich für sich behält und welchen man herausgibt (vorausgesetzt, in dem Objekt für den privaten Schlüssel ist nicht gleichzeitig auch der öffentliche Schlüssel enthalten, was ich nicht mit Sicherheit sagen kann, was aber auch egal ist, denn ...)

... bin ich auf Signierung umgestiegen. [...] Jetzt funktioniert es einwandfrei und die Lizenz kann sogar als Klartext eingesehen werden

Klar kann man das auch explizit mit den Signatur-Funktionen machen. Hätte dann sogar den Vorteil, dass die XML-Datei im Klartext wäre

😃

herbivore

Ja.. generell hast du irgendwie recht.. trotzdem hätte ich gern einfach die "Kontrolle" über das, was als Schlüssel rauskommt.. also, ist das generell möglich, wenn ja wie?

Welcher Key privat ist und welcher öffentlich, wird ja letztlich nicht durch ihre Namen bestimmt, sondern dadurch, welchen der Schlüssel man tatsächlich für sich behält und welchen man herausgibt (vorausgesetzt, in dem Objekt für den privaten Schlüssel ist nicht gleichzeitig auch der öffentliche Schlüssel enthalten, was ich nicht mit Sicherheit sagen kann, was aber auch egal ist, denn ...)

Das fett markierte trifft leider nicht zu.. der öffentliche Key ist im privaten enthalten.

Und ja, du hattest das mit dem Klartext bereits erwähnt 😉

Hallo,

sorry, dass ich diesen Thread wieder aufwärme.
Ich beziehe mich mal auf die Ausage von "herbivore" ziemlich am Anfang vom Thread:

Erstelle eine XML-Datei, in der die Daten den Kunden enthalten sind. Pack außerdem eine feste GUID mit in die Datei. "Verschlüssele" die Datei mit deinem privaten Schlüssel. Schick die "verschlüsselte" Datei (=Lizenzdatei) an den Kunden. Der kann sie dann im Programmverzeichnis ablegen.

Dein Programm enthält den öffentlichen Schlüssel und kann damit die XML-Datei entschlüsseln. Nun schaut es, ob die GUID stimmt und wenn ja ist alles gut.

Ich möchte gerne eine Datei mit dem privaten Key verschlüssen und mit dem öffentlichen Key entschlüsseln. Wenn ich das mache bekommeich die Fehlermeldung "ungültiger Schlüssel". Mache ich das in der "normalen" Richtung mit "public" verschlüsseln und mit "private" entschlüsseln passt das.

zum Codieren benutze ich:

RSACryptoServiceProvider rsa = new RSACryptoServiceProvider( 512 );
            rsa.FromXmlString( privateKey );  /
            return rsa.Encrypt( ContentInByte, false );

zum Decodieren:

RSACryptoServiceProvider rsa = new RSACryptoServiceProvider( 512 );
            rsa.FromXmlString( publicKey );
            byte[] entschluesselt = rsa.Decrypt( verschluesselteNachricht, false);

... ich schätze / hoffe mal, dass jemand der sich mit der Materie auskennt meinen Fehler sieht / erahnt.

spree

Hallo spree,

die Antwort wurde bereits in diesem Thread gegeben: Auf der theoretischen Ebene von asymmetrischen Verfahren funktioniert mein Vorschlag. Auf der praktischen Ebene von .NET solltest du nicht die Verschlüsselungs- sondern die Signierfunktionen nehmen.

herbivore

PS: Ich habe diese Information jetzt auch explizit in den Beitrag mit meinem Vorschlag geschrieben.

Hallo herbivore,

Danke für Deine Antwort. Ich versuchs dann mit der Signierfunktion!

spree

Nachdem die oben gennante Methode nicht zu funktionieren scheint, bin ich auf Signierung umgestiegen. Siehe dazu

> und

>

Dabei bekommt der verschlüsselnde RSACryptoServiceProvider den privaten Schlüssel und der entschlüsselnde den öffentlichen und nicht wie auf den o.g. Seiten beide die gleichen CspParameters.. sont hätten ja beide sowohl private als auch öffentliche Schlüssel.

Ich möchte hier eben kurz nochmal anknüpfen, auch wenn es schon recht lange her ist. Und zwar frage ich mich, wie genau ich beim Verschlüsseln und Entschlüsseln nur die jeweilig benötigten Keys verwenden kann. Die Beispiele verwenden ja jeweils den gleichen Container mit jeweils beiden Schlüsseln drin.

Hallo Calexico,

Und zwar frage ich mich, wie genau ich beim Verschlüsseln und Entschlüsseln nur die jeweilig benötigten Keys verwenden kann.

darum musst du dich nicht kümmern. Beim Verschlüsseln wird automatisch der öffentliche Schlüssel verwendet, beim Signieren automatisch der private.

herbivore