System für Lizenznummern?

[Sharky]

Hai,

kann mir einer von euch (oder auch mehrere *g*) einen Gedankenanstoss geben wie ich für ein Programm am besten Lizenznummern vergebe?

In der Lizenznummer müssten "enthalten sein":

• Name des Lizenznehmers.
• Anzahl der Serverlizenzen.
• Anzahl der Clientlizenzen.
• Ablaufdatum der Lizenz.

Beispiel:

Kunde Müller kauft eine Lizenz meines Programmes für 2 Server und 10 Clients. Diese soll gültig sein bis. 31.12.2004

Wenn der Kunde nun seinen Namen und die Lizenznummer eingibt soll das Programm:

a) Prüfen ob die Lizenz zur Firma Müller gehört.
b) Für welche Anzahl von Servern und Clients sie erworben wurde
c) Das Ablaufdatum aus der Lizenz lesen.

Kennt jemand ein System auf dessen Grundlage ich das realisieren kann?

[atreju2oo0]

Bin hier zwar noch ein Nuub aber ich würde das so machen:

Als erstes brauchst Du eine Datenbank in der Du eine Verschlüsselung speicherst

Müller=1
Meier=2
usw...
deine ganze Nummer setzt sich dann aus 0001 002 010 231004
0001= Müller
002 = Anzahl Clients
010 = Anzahl Lizenzen
23.10.04 Ablaufdatum

Da diese so entstandene Nummer natürlich ziemlich leicht zu hacken wäre würde ich
den entstandenen Wert mit einer relativ großen Primzahl multiplizieren und somit verschlüsseln.
Man könnte auch die entstehende dualzahl als HEX an den Kunden weitergeben um die Eingabe zu verkleinern(statt 8 bit nur 2)

Ich hoffe das hat Dir geholfen...
Wenn Du in puncto Verschlüsselungsalgorithmen noch n bissl Hilfe brauchen solltest melde Dich einfach... :warn:

:dancer: :coder: :dancer2:

[MrKnogge]

Zitat:

Zitat von atreju2oo0

Müller=1
Meier=2

Hier für müsste er aber schon zur Entwurfszeit
seines Programmes wissen, wer sein Produkt kauft :lol:

Aber der Ansatz is doch schon gut !

Ich würde die Serial nicht über den kompletten Namen, sondern beispielsweise nur aus den ersten 5 Buchstaben (kürzere Namen werden mit irgendeinem Zeichen aufgefüllt (0,1 oder leerzeiche - wie du willst)), damit alle Serials auch die gleiche länge haben.

Von diesen Buchstaben nimmst du dann den Ascii-Code mischt das mit den Anzahl der Server/Clients und dem Datum und verschlüsselst das ganze.

[Sharky]

[quote="MrKnogge"....nicht über den kompletten Namen,....[/quote]

Eventuell gibt es ja die Möglichkeit einen Hashwert einer festen länge zu erzeugen?
Zu knacken ist so eine Seriall natürlich immer. Mal sehen ob Hagen etwas dazu weiss.

Eine DB kann ich natülich nicht verwenden. Das Programm kann ja schlecht darauf zugreifen. Oder habe ich adreju2ooO da falsch verstanden?

[Phoenix]

Also ich habe da eine Prinzipielle Idee:

Du verwendest einfach eine Public-Key verschlüsselung ;-)

Die Idee ist folgende:

Du lieferst Deinen Public Key mit Deinem Programm aus.
Die Software beim Kunden erzeugt beim ersten Start ein Schlüsselpaar, bei der Bestellung der Serial schickt Dein Programm den Public Key des Käufers mit.

Du Verschlüsselst nun alle Angaben die Dein Programm braucht (kann dann ja sogar ne .ini sein) mit dessen public Key und signierst mit Deinem private Key.

Die Software kann nun a) verfizieren, daß das Keyfile von Dir kommt (dank Deinem Public Key).
Es erkennt also auch Key-Fälschungen.

Die Software kann nun b) den Key auch entschlüsseln - und zwar nur diesen einen Key! Alle anderen Keys haben andere Schlüssel und somit sind die Keys nicht austauschbar ;-)

Zudem brauchst Du Dir keine Gedanken zu machen, wie gut oder schlecht der Algorithmus Deiner Lizenznummenr ist, da es recht schwierig sein dürfte ohne Deinen private Key ein gültiges Lizenzfile zu verschlüsseln so das es aussieht asl käme es von Dir.

Freilich wird das File etwas grösser und lässt sich nur noch per eMail verschicken, aber es ist relativ sicher.

Damit brauchst Du also keine Lizenznummern erzeugen mit irgendeinem system, sondern Dich auf das wesentliche beschränken. Private/Public-Key implementationen gibt es bereits zu hauf, Du brauchst die also nur einzubinden und gut ist.

[MrKnogge]

So hat er das wohl gemeint, wäre aber auch von Datenschutzgründen aus schon fatal.

Klar, zu knacken ist so etwas immer siehe die großen Firmen aller MS & Co,
aber da sich an dein Programm, von der popularität her wenige Hacker drann
zu schaffen machen, reicht wohl eine kleinere Verschlüsselung.

Ein weiterer Tip wäre eventuell, die Datenbanken nach ablauf der Demoversion ebenfalls zu verschlüsseln.

[Sharky]

Uff...

ne ne. Es dürfen/können keine Daten versendet werden. Das Programm kann ohne Key installiert werden. Läuft dann halt in einem Demomodus.

Wenn der Kunde es kaufen möchte bekommt er seinen Key (xxxx-yyyyyyyy-zzzzz) und Trägt diesen ein.
Und in diesem Key sollte halt alles so stehen wie ich oben geschrieben habe.

Klar, die Server/Client anzahl und das Ablaufdatum kann ich einfach nach einem frei definierten Muster in den Schlüssel einbauen.
Dann müsste ich mir nur gedanken wegen dem Benutzernamen (Lizenznehmer) machen.

Ich dachte halt das es zu diesem Thema schon einiges an Theorien gibt. Es ist auch davon auszugehen das sich kaum einer die Mühe macht den Key zu knacken. Dafür ist das Programm zu speziell und ohne "support" würde es keiner einsetzen ;-)

[Christian Seehase]

Moin Sharky,

such doch mal bei Sourceforge nach TurboPower.
Wenn ich mich recht entsinne, gab's davon auch eine Komponentensammlung für Lizenzen/Seriennummern.
Vielleicht geht's damit.

[atreju2oo0]

Zitat:

Wenn der Kunde es kaufen möchte bekommt er seinen Key (xxxx-yyyyyyyy-zzzzz) und Trägt diesen ein.
Und in diesem Key sollte halt alles so stehen wie ich oben geschrieben habe

Aber warum?
Lizenz macht doch nur Sinn, wenn man anderen Usern was vorenthält...
Und so braucht nur einer die Lizens erwerben und alle können dein Prog nutzen...???

[Sharky]

Hai Chris,

danke für den Tipp. Ich werde mal schauen ob es etwas gibt. Auf die schnelle habe ich dort nichts gefunden. Aber das kann auch an meinen Augen liegen ;-)

[Sharky]

[quote="atreju2oo0...Und so braucht nur einer die Lizens erwerben und alle können dein Prog nutzen...???[/quote]

Darum muss ja der Name des Lizenznehmers (zumindest eine Prüfsumme) mit in den Key.

[Christian Seehase]

Moin Sharky,

ich hab' mal meiner Erinnerung auf die Sprünge geholfen:
Es müsste mit TurboPower OnGuard gehen.

[MrKnogge]

:shock: WoW
Sieht sehr interressant aus, gleich mal testen :coder:

[Sharky]

Zitat:

Zitat von Christian Seehase

... TurboPower OnGuard gehen.

:-D Danke das Du dein Gedächtniss bemüht hast. Liest sich ersteinmal ganz gut.
Ich werde es die Tage mal testen.

[Christian Seehase]

Moin Sharky,

Zitat:

Zitat von Sharky

Ich werde es die Tage mal testen.

und dann hoffentlich kurz Bericht erstatten.
Ich bin nämlich noch nicht dazu gekommen es zu testen ;-)

[Die Muhkuh]

Und wo bekommt man das Ding?

[sakura]

Zitat:

Zitat von Spider

Und wo bekommt man das Ding?

TurboPower OnGuard :roll: Schau Dir mal den ersten Link an ;-)

...:cat:...

[Treffnix]

Zitat:

Zitat von Christian Seehase

Moin Sharky,
such doch mal bei Sourceforge nach TurboPower.

[supermuckl]

in der komponente "AVlockGold" ist alles drin! sogar mit cpu/bios/festplatten ID überprüfung und public/private key :D

[negaH]

@Sharky:

Man sollte erstmal zwischen Liezenznummer und Registrationsschlüssel unterscheiden.
Eine Lizensnummer enthät Informationen über den Lizensnehmer und die Lieznesierungsart. Damit ist diese Nummer nicht sicherheitsrelevant an sich.
Der Registrationskey ist ein Schlüssel der sich meistens aus der Lizensnummer berechnet. Das dahinterliegene Verfahren, der Algortihmus und die verwendeten versteckten Daten müssen geheim bleiben.

Generell würde ich nicht alltzuviel Aufwand betreiben, sprich Public Keys, Produkte wie TurboPower oder AVLock sind rausgeschmissenes Geld, da JEDES Lizenzierungsverfahren das auf kurzen Registrationskeys basiert und OHNE sichere Hardware funktioniert IMMER leicht geknackt werden kann. Da helfen auch nicht die besten Kryptographischen Verfahren wie Public Key Verschlüsselungen ua. Diese Systeme suggerieren nur eine Sicherheit wo keine sein kann, und sie benutzten die Kryptoverfahren als Verkaufsförderndes Argument.

Nun ich würde folgendes machen:
Der Lizenzcode besteht auf einer Prüfsumme über die Regustrationsdaten wie Name, Firma usw. plus die Lizenzierungsart plus 4 Zeichen Zufallsdaten.

Also NNNNNNNNNNNNNNN-XXXXX-RRRR, alles in Base32 codiert, d.h. Zahlen in [0..9, 'A..Z' - 'Q' - 'O' - 'J' - 'I'].
Groß-Klein Schreibung spielt keine Rolle dabei, also ist der Code auch leicht eingebbar. Leicht zu verwechselnde Zeichen wie 'I','J','1' oder 'O','0','Q' werden zugunsten der Ziffern entfernt. D.h. I,J,O,Q sind nicht im Set enthalten.

NNNNNNNN enthält eine Prüfsumme über den Name,Firma,Anschrift des Lizensnehmers. Dabei werden dessen Daten in Großbuchstaben umgeandelt, und alle Sonderzeichen, wie Punkt,Semikolon und Spaces vorher entfernt. Über die so becleanten Daten kann man nun eine Prüfsumme beerechnen. Zb. mit Hilfe von MD5 Hash.
In die Prüfsummenberechnung wird der Zufallswert RRRR mit einbezogen !

XXXXX enthält eine Codierte Form der Lizenzart.
RRRR sind einfach nur Zufallszahlen.

Der Lizenznehmer sendet seine Daten wie Name,Firma + Lizensnummer an dich. Du trägst diese Daten in deine Kundendatenbank ein und überprüfst natürlich die Lizenznummer mit dem gleichen Verfahren. Nun wird mit einem "geheimenen" Algorithmus aus der Lizenznummer der Registrationskey berechnet und an den Kunden verschickt.

Der Code zur Überprüfung des Registrationskeys muß immer in der Software stehen, was demzufolge bedeutet das ein Cracker diesen Code mit entsprechendenm Aufwand IMMER herausfinden kann. Egal welches Verfahren benutzt wird, es ist immer unmöglich ein System mit solchen verfahren zu schützen.

Wie sollte der RegCode Algo. aufgebaut sein ?
Am besten er ist polymorph, d.h. der Lizenzcode ist ein Input aus dem ein Programmcode erzeugt wird. Dieser Programmcode wird mit Daten gefüttert die dann durch diesen dynamischen Code in den Registrationsschlüssel umgewandelt werden. Zusätzlich sollten einige Programmteile ebenfalls verschlüsselt vorliegen, um einfache JMP Patches zu verhindern.

D.h. das eigentliche Problem bei solchen Verfahren kann technisch reduziert werden auf Methoden wie man einen Cracker daran hindert den Code zu entschlüsseln. Da dem Cracker aber grundsätzlich die komplette Software zur Verfügung steht hat er immer auch die nötige Basis um mit entsprechendem Aufwand den RegCode zu entfernen.

Somit ist es viel clever sich nicht zu sehr auf den Schutz der Software zu konzentrieren, sondern eher mit der Kundenbindung an die eigene Firma zu befassen. D.h. guter Support, unique Features in der Software, gutes Preis/Leistungsverhältnis sind viel stärkere Maßnahmen gegen Raubkopierer.

Gruß Hagen

PS: Produkte mit AVLock und auch TurboPower's Schutzmechanismen sind geknackt worden !

[trifid]

Zitat:

PS: Produkte mit AVLock und auch TurboPower's Schutzmechanismen sind geknackt worden !

wie ?
gibt es da näheres zu erfahren ?

[negaH]

Einen gravierenden Unterschied in der Sicheheit erreicht man nur mit externer Hardware. Leider bleibt aber auch da bei heutigen Systemen eine Unsicherheits-Barriere übrig. Die Kommunikation der Softare mit der externen Hardware kann nämlich ebenfalls geknackt werden. Siehe die vielen Dongle-Lösungen die geknackt wurden.

Nur ein System in dem jede beteiligte Komponente, ausgehend bei der Datenübertragung über die Software bis hin zu der Hardware einbruchsicher ist, kann einen 100%tigen Schutz bieten. Microsoft hat mit Palladium und dessen integriertem TCPA + protected Memorychips + Nexus-CPU's eine solche Lösung präsentiert. Allerdings entstehen mit solchen Systemen auch enorme gesellschafliche und juristische Probleme !

Ich selber habe ein Hardware basiertes Projekt entwickelt, bei dem mit selber programmierten SmartCards ein Registrations- und Software Schutzsystem implementiert wurde. Wichtig bei diesem System war das die SmartCard direkt über eine Live-Internet-Verbindung zu jeder Zeit den Zugriff der Benutzer kontrollieren konnte. Aber auch in diesem System war die grundlegende Schwierigkeit nicht die SmartCard'Programmierung oder die kryptographischen Verfahren, sondern die Verankerung der Schutzsysteme in die Software. Aus diesem Grunde haben wir uns ja auch für die permanente Live-Überprüfung per Internet entschieden. So war es gewährleistet das zumindestens die Serverseite absolut einbruchsicher ist. Nur durch diesen "Trick" war es überhaupt möglich ein annährnd 100% sicheres System zu schaffen. Allerdings, solche Lösungen bleiben vorerst nur Speziallösungen.

Gruß Hagen

[negaH]

Zitat:

wie ? gibt es da näheres zu erfahren ?

Mit Debugger, HEX Editor, RegMon, FileMon und Patches. Die Versuche waren reine kryptologische Experimente und dienten zur Überprüfung der tatsächlichen Sicherheit der Systeme.

Das die obigen Produkte, bzw. Produkte die darauf aufsetzten unsicher waren hatte ich von vornherein angenommen.
Interessant waren die Produkte von Rainbow Technologies. Bei denen hatte ich erwartet das sie stärker sind als sie es dann tatsächlich waren.

Delphi's Trialversionen wurden zeitweise mit Rainbow geschützt. Diese Trial's waren mit 2 Änderungen an der Registry und dem Löschen zweier Dateien immer wieder freischaltbar.
Rainbow's Statements waren das die Sicherheit ihrer Produkte entscheidend von der Integration durch die Programmierer = Kunden abhängig ist. Diese Aussage fand ich ziemlich interessant, da Rainbow selber mit großen Worten auf Kryptographsiche Verfahren, Public Keys, Sicherheitsprotokolle wirbt, aber dann selber sagt das nur die aufwendige und korrekte Implementation durch den Kunden die eigentliche Sicherheit erzeigt wird.
Wer schon mal mit dem USB-Crypto Token gearbeitet hat weiß wie kompliziert deren Anwendung für uns Programmierer sein kann.

Gruß Hagen

[negaH]

Ausgehend von diesem Wissen habe ich meine SmartCard Lösung entworfen. Die Aufgabenstellung war es zwei sicherer Endpoints zu schaffen. Einmal die einbruchsichere SmartCard auf Kundenseite und der Server auf Herstellerseite. Die Kommunikation läuft über unsichere Verbindungen, aber eben authentifiziert und verschlüsselt zwischen SmartCard und Server. Durch die Regelmäßige Überprüfung per live Connection vom SmartCard zum Server wurden die Schwachstellen der Offline System beseitigt. Die Software wurde dadurch geschützt das der Server dynamisch veränderte Programmteile zur SmartCard überträgt.

Allerdings, solche Systeme sind tragbar für Pay-Per-Use Software, Online Katalog usw. D.h. es sollte in solchen Systemen immer ein Bedürfnis der Kunden geben sich beim Server einzuloggen. Dies beschränkt eben die Nutzbarkeit des Systemes auf spezialisierte Anwendungen. Ok, letzendlich war das Prohjekt eh nur eine Studie, gefördert vom Bund.

Gruß Hagen

[Sharky]

Hai Hagen,

ersteinmal besten Dank für dein, wie immer, sehr genauen erklärungen.

Einen zu großen Aufwand wollte ich eh nicht betreiben da das Porogramm eh nur für bestimmte Firmen interesant ist und diese ohne Support nicht viel damit machen werden.

Das wichtigste ist eigentlich in der Lizenznummer die Anzahl der Server/Clients zu kodieren.

Bzgl. eines Hashwertes müsste mir doch sicher dein DEC weiterhelfen können oder?

Wo kann ich das eigentlich bekommen?

[trifid]

@negaH

Zitat:

... auf Kryptographsiche Verfahren, Public Keys, Sicherheitsprotokolle wirbt, aber dann selber sagt das nur die aufwendige und korrekte Implementation durch den Kunden die eigentliche Sicherheit erzeigt wird.
Wer schon mal mit dem USB-Crypto Token gearbeitet hat weiß wie kompliziert deren Anwendung für uns Programmierer sein kann.

wenn aber der Dongle erst bei 35Euro anfängt, dann ist eine Hardwarelösung für eine 50Euro Software doch etwas zuviel des guten

Zitat:

Ausgehend von diesem Wissen habe ich meine SmartCard Lösung entworfen. ... Ok, letzendlich war das Prohjekt eh nur eine Studie, gefördert vom Bund.

a) das mit der SmartCard hört sich gar nicht so schlecht an, aber hatten wir das nicht
schon einmal ...
beim Installieren muss eine Diskette eingelegt werden und beim deinstallieren auch
b) nicht jede Anwendung soll und darf mit dem Internet verbunden sein ?
c) wenn der Bund das gefördert hat, dann ist es auch meistens frei zugänglich, wo kann man mehr
darüber erfahren ?

[negaH]

Zitat:

a) das mit der SmartCard hört sich gar nicht so schlecht an, aber hatten wir das nicht
schon einmal ...
beim Installieren muss eine Diskette eingelegt werden und beim deinstallieren auch
b) nicht jede Anwendung soll und darf mit dem Internet verbunden sein ?
c) wenn der Bund das gefördert hat, dann ist es auch meistens frei zugänglich, wo kann man mehr
darüber erfahren ?

A) nicht in der Form das über die Client Software die SmartCard eine Live Verbindung zum Server des Herausgebers der SmartCard hat. Die SmartCard ist intelligent im Vergleich zu Disketten, d.h. sie kann nun dynamisch mit der Serverseitigen Software kommunizieren. Sinn und Zweck dabei sind zB. Lösungen bei der die Client Software ohne großen Aufwand auf SICHERE Art und Weise die SmartCard dazu benutzt um zB. Pay per Use einzurichten. In einem Internet Cafe werden pro Benutzer solche Karten ausgegeben. Oder im Intranet wird der Zugriff auf die lokalen und internen Intranet Resourcen geregelt. Hier benötigt man keine Internet Verbindung, sondern der SmartCard Server der die Zugriffe und Authentifizierungen regelt sitzt als Intranet Server im Firmennetzwerk. Für meine Lösung spielt das alles keine Rolle. Man könnte sogar als privat Anwender auf dem gleichen Home PC den Server installieren und dann werden Multiple Client Anwendungen über ein einheitliches API durch die SmartCard Lösung unterstützt. Es könnte zB. auch so aussehen: Die jeweilige Nutzung der SmartCards ist von Anwendung zu Anwendung unterschiedlich. Die eine Anwendung nutzt die SmartCard als Authentifierung und Zugriffverwaltung für die Benutzer. Die andere Software benutzt die SmartCard als sicheren und serverbasiertem Passwortsafe. Die dritte Anwendung benutzt die SmartCard als Pay per View Zugriffskontrolle um vom Server bereitgestellt Mediainhalte zu dechiffrieren und abrechnen zu können. Die SmartCard Serveranwendung wiederum ist immer die gleiche und über sie können die drei Anwendungen im gesammten konfiguriert und gesteuert werden. Das heist also, die Server Software verwaltet ALLE verschiedenen Anwendungen die auf der SmartCard Lösung basieren im gleichen GUI + Database. Die Anwendungen selber können von verschiedenen Hersteller sein mit ganz unterschiedlichen Nutzungsformen für die SmartCards.

B) die Zielsysteme solcher Sicherheitslösungen müssen dies aber unterstützen. Das ist eine einfache grundlegende Bedingung. D.h. die Sicherheit des Systemes basiert eben darauf das auf einem einbruchsicheren Server die SmartCard Server Anwendung läuft. Dies IST bei solchen LAN/WEB basierten Systemen immer der Fall. Allerdings betrachtet aus der Sicht der Kommunikationswege ist der Server meistens der EINZIGSTE sichere Endpunkt im System. Dies ist die Schwachstelle der meisten heutigen Systeme. Um das sicher zu bekommen, wird am anderen Ende der Line ebenfalls ein einbruchsicherer Endknoten benötigt. Dieser wird bei unserer Lösung durch die SmartCards erledigt. Im Microsoft Palladium wäre das der Fritz TCPA + die Nexus CPU. Bei solchen Hardware Voraussetzung können nun die heutigen 100% sicheren Kryptographischen Verfahren voll ihr Potential ausschöpfen. In fakt: solche Systeme SIND IMMER absolut einbruchsicher und NICHT knackbar, vorausgesetzt alles wurde korrekt implementiert. Ein weiterer "Vorteil" bei solchen Systemen ist die Möglichkeit für die Hersteller dieser Systeme unbekannte Back Doors einzubauen. In den USA wird sowas generell von den Staatlichen Organen für solche Systeme vorgeschrieben !!
D.h. auch im Microsoft Palladium ist zu erwarten das NICHT mehr der Benutzer und Eigentümer der Hardware Vollzugriff auf ALLE Bereiche dieser Systeme hat, sondern AUSSCHLIESSLICH nur die Herstellerung und die Governements haben solche Zugriffsrechte.

C) Warum soll das dann frei zur Verfügung stehen ? Davon weis ich aber nichts, wäre ja noch schöner. Bei der Förderung durch den Bund geht es darum Geld für die Entwicklung der eigenen Systeme zu bekommen. Dazu muß man sich beim Bund bewerben, bekommt Projektbezogene, Personelle und Finanzielle Auflagen, die bei der Finalisierung des Projektes natürlich durch Profi's überprüft und überwacht werden. Das Geld ist also auch wenn es im Grunde ein Geschenk ist, nicht umsonst. Alleine der Papierkram kann den Aufwand im Vergleich zum Nutzen, der paar Kröten, übersteigen.

@Shary:

Zitat:

Bzgl. eines Hashwertes müsste mir doch sicher dein DEC weiterhelfen können oder?
Wo kann ich das eigentlich bekommen?

Im DEC mit

Delphi-Quellcode:

  ResultAsHEXString := THash_MD4.CalcString(InputString, nil, fmtHEX);

DEC kannste bei Delphi Super Page, Torry, VCLComponents etc downloaden.
Ich empfehle dir die Delphi Super Page, Abteilung D5 -> Security -> Cipher, oder Top Ten Downloads -> Cipher.
DEC sollte bei DSP auf dem 4. Platz aller Freeware Komponenten liegen.

Gruß hagen