Lizenzierung für eigene Applikation?

[Stephan Schneider]

Hallo,<br>
Umg.: Delphi 6 Ent. UP2.<br>
Wir überlegen zur Zeit, wie wir in unsere eigene Applikationswelt eine Art Lizenzierung integrieren können. Dabei soll ein Lizenzschlüssel, der bspw. während der Installation angegeben wird, an die Applikationen 'weitergereicht' werden. Die einzelnen Applikationen können dann anhand dieses Lizenzschlüssels in einer Lizenzschlüsseldatenbank nachschauen, wer nun der gültige Lizenznehmer ist (und diesen z.B. in der Infobox anzeigen). Alle Lizenznehmer stehen im vornherein fest.<br>
Was haltet Ihr davon?<br>
Habt Ihr eventuell bessere oder geeignetere Alternativen? Meine Erfahrungen mit Lizenzierungen und den dahinterstehenden Verfahren (wie wird ein Lizenzschlüssel an die Applikationen weitergereicht? Wo soll die Lizenzdatenbank stehen? etc.) tendieren gegen Null.<br>
PS: Einträge in die Registry werden nicht gemacht!<br>
Danke<br>Stephan

[Mario.Noack]

Hallo,<p>
Wie sicher seit Ihr, dass Ihre alle Lizenznehmerdaten vorher festlegen könnt und die auch dem Kunden mitgebt?<p>
Sinnvoller wäre meiner Meinung nach folgendes: Ein Kunde muss Information nach einem Schema, z.B. Firmenname, Gültigkeitsdauer und Lizenztyp abgeben. Dann wird aus dem Firmennamen ein Hash gebildet und dieser wird dann noch mit der Gültigkeitsdauer und dem Lizenztyp versehen.<p>
Der Kunde muss also seine Firma und den codierten Schlüssel hinterlegen. Daraus kann die Anwendug prüfen, ob der Hash stimmt und welche Lizenzart und Dauer vorliegt.<p>
Somit landen keine fremden Lizenzdaten beim Kunden, was Datenschutzrechtlich sicher bedeutend unproblematischer ist.<p>
Mari

[Stephan Schneider]

Hallo Mario,<br>
Unsere kleine Welt umfasst eine Reihe von Programmen, die allesamt den Lizenznehmer anzeigen sollen. Nun sollte aber eine Implementierung eines Lizenzverfahrens mit möglichst geringem Aufwand geschehen. Das bedeutet auch, dass ich eventuell nicht an alle Programme selber ran kann, um Derartiges zu realisieren. Daher ist der Gedanke erwachsen eine Art Lizenzdatenbank aufzubauen, in der sich neben dem Schlüssel der Lizenznehmer befindet. Diese Lizenzdatenbank müsste gecryptet wo auch immer stehen, so dass der Zugriff für die Programme darauf bspw. über eine von mir geschriebene DLL-Funktion stattfindet.<br>
Wenn ich Dich recht verstanden habe, dann erzeugt ein Setup diesen Lizenzschlüssel (Schlüssel = gehashter Firmenname + Dauer + Typ).<br>Wo steht dann dieser Lizenzschlüssel? In einer Datei? Wo befindet sich dann diese Datei?<br>Die Applikation selbst braucht dann nur noch auf diese Information zugreifen (vorausgesetzt sie weiß, wo sie sich befindet) und daraus den Lizenznehmer 'zurückhashen'. Richtig?<br>Hättest Du da eventuell ein Beispiel mit Quellcode, vorausgesetzt, dass ist nicht zu viel Aufwand?<br>
Stepha

[Mario.Noack]

Ich habe es so gelöst, dass der Schlüssel einfach in einer Key-Datei im Anwendungsverzeichnis liegt. Die Datei enthält nur den Schlüssel. Dann liegen noch die Anwenderinformation verschlüsselt in einer ini-Datei. Die Verschlüsselung könnte aber auch weggelassen werden, da es dem Anwender nur Sicherheit vorgaukelt, die eigentlich überflüssig ist.
Da es der Lizenznehmer aus dem Key nicht rückrechenbar ist, weil Hash, brauche ich da auch keinen weiteren Schutz. Bei dieser Art und Weise wäre es aber sinnvoll, den Lizenznehmer dann aber auch im Produkt mit zu verankern. Wenn beispielsweise PDFs erzeugt werden, den Author fest auf den Lizenznehmer zu setzen. Damit wäre die Weitergabe von Schlüssel und Lizenznehmer sofort nachvollziehbar.<p>
Source kann ich Dir zu dem Thema nicht direkt rüberreichen, da dieser in der Anwendung absichtlich komplett verstreut und unnötig kompliziert ist, um externe Debugger aussen vor zu lassen. Für die Erstellung von Hash's oder die notwendige Verschlüsselung empfehle ich Dir aber das DEC (Delphi Encryption Compendium). Google mal danach, den Download findest Du sicher noch irgendwo.<p>
Mari

[Stephan Schneider]

Danke für Deine ausführlichen Antworten :-)<br>
Brauche ich wirklich das DEC komplett? Ich bin zwar kein Kryptographie-Experte, aber meines Erachtens benötige ich doch nur zwei Funktionen:<br>
Funktion1 erstellt einen Hash-String aufgrund des Firmennamens, gepaart mit Dauer und Typ<br>
Funktion2 ermittels aus dem Hash-String den Firmennamen zurück<br>
Gibt es derartige Funktionen bereits, die ich wiederverwenden kann? Und zwar ohne gleich eine ganze Komponentenpalette installieren zu müssen. Ich stelle mir eine kleine unit vor, die diese Funktionalität anbietet

[Mario.Noack]

Es reicht, wenn der Source im Suchpfad ist, dann brauchst Du keine Komponente Installieren:<p>
<i><pre>uses ... Hash, Cipher, DecUtil... <p>

WITH THash_RipeMD256.Create(NIL) DO
TRY
Result := CalcString('Originalwert fuer Hash' ,NIL, fmtHex);
FINALLY
Free
END;

</pre>
</i><p>
Delphi kümmert sich automatisch drum, dass nicht die ganze Lib eingebaut wird. Das Prinzip ist bei Cipher das gleiche. Die installierbaren Komponenten waren ein Tribut von Hagen, die nur so im Code nicht arbeiten wollten und die uses nicht von Hand erweitern konnten/wollten.<p>
Mari

[Stephan Schneider]

Ich gehe davon aus, dass der 'Originalwert fuer Hash' dem zu hashenden String entspricht, also dem Firmennamen.<br>Wie sieht dann die Ermittlung des Originalwerts aus dem Hashstring aus?<br>Ich werde trotzdem die ganze Sammlung einbinden müssen, da die Anwendungen auf Run-Time-Packages basieren

[Mario.Noack]

Hallo Stephan,<p>
Aus einem Hash kann kein Original-Wert mehr ermittelt werden. Das ist ja der Trick! Du vergleichst nur, ob der eigegebene Hash mit dem aus dem Namen ermittelbaren Hash übereinstimmt. Aus dem Hash selbst könnte aber nie wieder ein Wert zurückberechnet werden. Damit ist das "Passwort" sicher. Ein Grund, warum man in vielen Foren etc. sein Passwort nicth mehr anfordern kann, weil es einfach nicth mehr vorliegt. Somit kann es auch nicht abhanden kommen.<p>
Du kannst doch diese Funktionalität komplett in ein Package einkompilieren, somit sollte es eigentlich ganz gut funktionieren?<p>
Mari

[Mario.Noack]

Nachtrag: Ein Encode und Decode bieten die Klassen in der Unit Cipher.<p>
Mari

[Stephan Schneider]

]...ob der eingegebene Hash mit dem aus dem Namen ermittelten Hash überstimmt...<br>Wie habe ich das prozessual zu verstehen?<br>Im Setup gibt der Benutzer seinen Firmennamen an, der anschließend gehashed und in einer Datei gespeichert wird. Diese Datei befindet sich anschließend im Anwendungsverzeichnis. Die Anwendung startet und liest den Hashstring aus der Datei aus, und dann

[Mario.Noack]

Nein, nicht ganz. Der Anwender gibt seinen Firmennamen und den Hash oder etwas was darauf basiert zum Beispiel als Hex ein. Du prüfst dann, ob der Hash stimmt. Der Hash kann, aber muss nicht vom Setup geprüft werden. Dass würde ich in die Anwendung auslagern und bei falschem Hash nur im Demo-Modus starten. Abgespeichert wird nur der Hash, den der Anwender eingibt. Egal ob der stimmt.<p>
Willst Du umfangreicher Lizenzinformationen einbinden, so würde sich aber auch anbieten, die Lizenzinformation in einer Art Ini-Format abzulegen (Anschrift, Rechte, Datum) etc. und diese komplett durch den Cipher zu jagen. Dann bekommt der Anwender nur eine Lizenzdatei, die vielleicht 1-2 kB groß ist, welcher er in Deiner Anwendung verlinken muss.<p>
Mari

[Stephan Schneider]

Vielleicht sollte ich mich erst ein wenig mit der dahinterstehenden Theorie auseinandersetzen...<br>Wenn ich aus dem Hash keinen Rückschluß auf den Originalstring ziehen kann, wie kann ich dann den Hashstring prüfen?<br>Wie komme ich zu dem Hashstring, den der Benutzer angeben muss?<br>Nehmen wir mal an, ich habe in der Datei den Hashstring stehen, der von einer Anwendung ausgelesen wird. Anschließend muss doch mit diesem Hashstring was passieren, um zu dem Ergebnis zu kommen, dass er a) passt und b) wer dahinter steht. Und somit führe ich doch mehr oder weniger implizit eine kleine Lizenzdatenbank mit in der Anwendung, oder?
&#10

[Mario.Noack]

Folgendes Szenario, wenn ich nur überprüfen will, ob ein User einen gültigen Schlüssel hat:<p>
1) Der Anwender nennt mir seinen Namen und ich erzeuge daraus einen Hash mit einem kleinen Key-Maker und liefere ihm diesen aus.<p>
2) Der Anwender nimmt Name und Hash und gibt Ihn in seiner Anwendung ein.<p>
3) Deine Anwendung berechnet live den Hash aus seinem Namen und überprüft, ob dieser Hash mit dem eingegebenen übereinstimmt.<p>
Die Anwendung hat sozusagen zwei freie Eingabefelder für den Namen und den Hash. Stimmt eines von beiden nicht überein, wird der Vergleich nicht funktionieren und Du weißt, dass der Schlüssel nicht mehr OK ist.<p>
Warum so umständlich: Wir haben über diesen Weg sichergestellt, dass es einen echten berechneten Schlüssel gibt, der nicht erraten werden kann. Wir haben trotzdem einen anzeigbaren String, den wir in Ergebnisse unserer Anwendung integrieren können. Wir brauchen keine Lizenzdatenbank, da der Anwender seinen Namen selbst eingibt, weil sich daraus ja der Schlüssel ergibt.<p>
Hast Du einen geschlossenen Kundenkreis, der nicht sehr ambitioniert im Hacken ist, bzw. Deine Anwendung ist für den freien Markt nicht so interessant, so ist der Cipher sicher der einfachere Weg:<p>
1) Du nimmst alle Benutzerinformationen auf, trägst diese in eine Datei in einem definierten Format inkl. Berechtigung ein.<p>
2) Du jagst diese Datei durch den Cipher und sendest die verschlüsselte Variante Deinem Anwender.<p>
3) Dein Anwender speichert die Datei, gibt in Deiner Anwendung den Pfad an<p>
4) Deine Anwendung entschlüsselt die Datei im Speicher und liest alle Informationen und Berechtigungen aus.<p>
Nachteil: Der Key zum Entschlüsseln liegt beim Anwender. Üblicherweise ist das der gleiche wie zum Verschlüsseln. Wird dieses Verfahren geknackt, so kann diese Person alle verschlüsselten Lizenzinformationen von Dir praktisch im Klartext lesen. Das ist dann quasi die alles oder nichts Info.<p>
Der Hash bietet diesen Angriffspunkt von Haus aus nicht, da es gar keinen Rückweg gibt. Folglich muss der Anwender seine Informationen selbst preisgeben und der Hash ist nur Mittel zum Zweck, die Infos zu prüfen.<p>
Mari

[Stephan Schneider]

Ich habe mich nun mittlerweile etwas über Hash-Algorithmen informiert :-)<br>Die Punkte 2 und 3 besagen aber, dass aufgrund eines Originalwertes immer ein und derselbse Hashcode generiert wird, quasi eine Art elekronischer Fingerabdruck. Nehmen wir mal an, die Firma heißt ABC und der daraus generierte Hashcode ist X. Die Anwendung kann nun anhand des Firmennamens, der beim Login der Anwendung angegeben werden muss, den Hashcode ermitteln (nämlich X) und ihn mit dem entweder in einer Datei befindlichen oder zusätzlich eingegebenen Wert vergleichen. Entscheidend ist, dass für einen Originalwert immer(!) ein und derselbe Hashcode generiert wird, jedoch aufgrund des Hashcodes kein Rückschluss auf den Originalwert möglich ist

[Mario.Noack]

Genau, ich hoffe ich habe nichts gegenteiliges beschrieben.<p>
Mari