Rudimentärer Kopierschutz

izoards

Bekanntes Mitglied
Hi,

ich möchte meine Java Programme vor ungerwchtfertigter vervielfältigung schützen.
Es soll einfach eine Hürde sein, damit nicht per copy/paste die sw neu installiert werden kann. Also wirklich nur basics.

gibt es eine einfache Lösung, damit ich eine Kopierhprde einbauen kann?

das ganze kann auch manuell gemacht werden, es wird keine x-tausend installationen geben..

Kann man irgendwie das programm mit dem Rechner „verheiraten“ so dass es nicht einfach an einem neuen Rechner installiert werden kann?
Vielen Dank für eure Hinweise...
 

M.L.

Top Contributor
Man könnte einen "Obfuscator" einsetzen. Oder (auch) Code verwenden, der eine Mindest-Javaversion voraussetzt (in Java 16 z.B. Records, Sealed Classes). Oder man prüft vorab auf die Existenz bestimmter Verzeichnisse / Dateien /Informationen auf dem Zielrechner (muss alles keinen 100%-igen Schutz darstellen)...
 

izoards

Bekanntes Mitglied
Danke M.L.
Ein Obfuscator ist ja vorallem einen Schutz, damit der Quellcode nicht ausgelesen werden kann, richtig?
Es geht in erster Linie einfach darum, dass das ausgelieferte Programm sozusagen nur 1 Mal installiert werden kann.
Welche Informationen des Zielrechners wären da zu empfehlen?
Könnte man diese Information dann einmalig auslesen und danach in einem verschlüsselten File ablegen? Und so jeweils bei jedem Start des Programms prüfen, ob diese Information noch passen?
 

Robert Zenz

Top Contributor
Was fuer eine Applikation hast du, und in welchem Umfeld? Privat? Kommerziell? Firma?

Je nachdem gibt es andere Ansaetze wie man so etwas loesen kann.
 

izoards

Bekanntes Mitglied
Genau, es sind kleine Hilfs-Software Lösungen, welche die Arbeit Workflows mit einer veralteten SW vereinfachen sollten.
Also z.B. kann die veraltete SW keine PDF's generieren, das wird dann mein Java Programm realisieren.
Ziel ist es, dies unseren Kunden kommerziell anzubieten.
Die Kunden sind nicht IT affin, also genügt eine einfache Hürde...
 
K

kneitzel

Gast
Also generell gibt es da keinen wirklichen Schutz. Das erkennt man an den ganzen Firmen, die dies massiv probiert haben und alle mehr oder weniger gescheitert sind.

Das, was Du da baust, ist eher etwas negatives aus Anwendersicht. Daher sollte man sich immer gut überlegen ob und was man macht. Man muss ja nur an die eigene Genervtheit denken, wenn eine Windows Aktivierung Probleme machte oder so ...

Ich sehe das also sehr kritisch! Zumal die, die es "hacken" wollen, es einfach machen.

Generell kannst Du Dir anschauen, was für Werte Du wo auslesen kannst. (z.B. mal bei https://github.com/oshi/oshi schauen, was es da alles gibt ... )
So Dinge kannst Du dann als String zusammen fassen und den dann nutzen um diesen dann mit einem private key/Zertifikat zu signieren. Dann kannst Du auf dem Client immer wieder prüfen, ob die gelesenen werte und die Signatur übereinstimmen (mit dem public key/zertifikat).
Aber ist natürlich leicht zu hacken - ich tauschen den public key aus und signiere einen String entsprechend oder ich passe die Kontrolle so an, dss diese immer ohne Check zurückgibt, dass der Check ok ist ....
Kann man erschweren - zur Not sogar mit GraalVM ein native binary bauen. (Also voll übersetzt - nichts "zusammengepacktes". Dann braucht es auch keine Spielereien wie Obfuscator.

Obfuscator ist was feines - dann viel Spass mit den Stacktraces. Da es ja keine aussagekräftigen Namen mehr gibt, ist der Stacktrace quatsch. Traces schreiben wird auch blöd, denn was nützt es, wenn eine Methode unleserlich gemacht wird aber als erstes eine Tracenachricht mit dem original Methodennamen kommt?

Um es etwas sicherer zu haben, könntest Du da natürlich Online Checks machen. Dann hast Du einen Server zu betreiben und die Applikation redet mit dem um zu sehen, ob er arbeiten darf. Macht es dem Kunden einfach, die Applikation zu verlagern. Er kann diese aber nur einmal nutzen. Denn jeder Client spricht den Server ja an mit Details a.la. "Kundenname" "Lizenznummer" und nur wenn das passt und nicht von einem anderen Rechner angefragt wurde in letzter Zeit, dann ist es ok. Musst Du aber auch absichern denn so einen REST Service mocken ist nicht schwer ...
Und der Kunde verhaut Dich, weil er nicht arbeiten kann, wenn das Netz mal nicht geht, dein Server nicht läuft und und und ...

Es gibt natürlich auch noch die Idee, das mit Hardware abzusichern. Diese Hardware Dongles gab es in der Vergangenheit z.B. bei Autocad. (Evtl. auch heute noch, keine Ahnung). Steinberg sichert Lizenzen auf einem USB Stick / Key meine ich. Unraid nutzt eine Lizensierung per USB Stick, der eine id haben muss (haben die meisten). Sowas wäre also auch denkbar - müsste man zur Not schauen, wie man per JNI sowas ausliest.

Also ich sehe es kritisch, den es macht es den ehrlichen Kunden schwerer. Und die Frage ist eh, was für Schaden Du da ggf. hast. Und es hört sich nicht wirklich wie ein eigenständiges Produkt an sondern ein Tool, das da spezifisch ist für einen Kunden. Da wird die Entwicklung Kostenseitig doch hoffentlich abgedeckt sein, so dass der Kunde machen kann, was er will. (Sprich: Auftragsentwicklung - da hat der Kunde sogar alle Rechte. Der kriegt sogar den Source und kann machen was er will.)

Das einfach einmal von meiner Seite über Möglichkeiten, die ich so sehe und die ich aber alle extrem kritisch sehe! Ich würde mich auf das Produkt konzentrieren und die Zufriedenheit des Kunden sicher stellen. Und dann reicht ein einfaches bauen eines Produktes.

Ach ja: Die notwendigen Tools um selbst exe zu analysieren und so gibt es auch schon als Open Source - dank NSA: https://www.nsa.gov/resources/everyone/ghidra/. Da braucht man also keine teuren Tools mehr :)
 

izoards

Bekanntes Mitglied
Danke für die Einschätzungen. Es soll ja nicht unknackbar sein.
Einfach eine Hürde, so dass Kunde X, das Programm nicht an Kunde Y weitergeben kann....
Das wäre denke ich schonmal ganz ok.
Ich will keinen Server einrichten oder zuviel Aufwand dafür betreiben...
 

LimDul

Top Contributor
ich würde folgendes bauen, weil das meines Erachtens die wenigsten Einschränkungen hat:
* Man gibt beim Kauf Namen und Co an
* Daraus wird ein String generiert, der signiert wird mit einem privaten Schlüssel
* Die Signatur wird in ein Key File gepackt, das der Anwender rein kopiert
* Die Anwendung prüft mit dem öffentlichen Schlüssel, dass der eingegebene Name & Co passt.
* Das wird beim Start auch angezeigt "Lizenziert für XY"

Das hindert nicht, dass man das Key File auf verschiedene Rechner kopiert. Aber so "sieht" man dann als Anwender, ob die Lizenz da ist und legt die moralische Hürde höher.
 

Robert Zenz

Top Contributor
Ich stimme allem was @kneitzel sagt komplett zu.

Also z.B. kann die veraltete SW keine PDF's generieren, das wird dann mein Java Programm realisieren.
Ziel ist es, dies unseren Kunden kommerziell anzubieten.
Also das klingt nach einem sehr spezifischen Markt. Ich wuerde hier mal die Wahrscheinlichkeit analysieren ob die Software ueberhaupt irgendwie "missbraeuchlich" weitergegeben wird oder nicht.

Ich denke der einfachste Weg wird hier sein weniger Schutz als viel mehr Nachvollziehbarkeit zu machen. Erstens, baut ihr eine Lizenz in die Software ein. Jeder Kunde bekommt eine Lizenz-Datei welche die Software freischaltet. Die Lizenzen sind personalisiert sowohl im Inhalt als auch im Dateinamen und in der Anzeige in der Software selbst. Wenn die Lizenz nicht da ist, oder als ungueltig erkannt wird, verweigert die Software halt den Dienst. Achte hierbei darauf dass das nicht mit einem "richtigen" Kunden passieren kann, es ist furchtbar wenn der Kunde anruft weil seine Lizenz nicht erkannt wird. Als Zweites fuehrst du einfach nur, alle paar Stunden oder Tage, einen Anruf Zuhause durch. Also das Programm meldet sich bei eurem "Lizenzserver" und meldet den aktuellen Status, also ob eine Lizenz verwendet wird oder nicht und wem diese gehoert. Dieser Anruf hat keine Auswirkungen auf die Applikation (am besten auch kein eigenes Protokoll oder so, sondern einfach POST ueber HTTPS auf euren Server).

Damit wisst ihr dann wenn jemand die Software wirklich missbraeuchlich verwendet ("Oh guck mal, jemand in Indien verwendet die Lizenz von Meier Apothekenbedarf GmbH...") aber die Wahrscheinlichkeit dass legitime Kunden unangenehm davon betroffen werden ist sehr gering. Wenn ihr bereits Dienstleistungen fuer einen Kunden habt, also dort laeuft bereits eure Software und ihr habt mit dem Kunden einen Dienstleistungs-/Wartungsvertrag, koenntet ihr beim Anruf Zuhause auch noch uebermitteln ob andere Software von euch laeuft (und wem die gehoert nach Lizenz). Damit erschlaegt man dass sich zwei Kumpels die Software teilen, weil man dann sieht "Okay, Schneider hat ploetzlich unser PDF-Programm mit der Lizenz von Meier." und dann wuerde ich einfach beim Kunden mal anrufen und sagen dass sie ab jetzt ihre eigene Lizenz bekommen zusammen, mit der Rechnung.
 

izoards

Bekanntes Mitglied
ich würde folgendes bauen, weil das meines Erachtens die wenigsten Einschränkungen hat:
* Man gibt beim Kauf Namen und Co an
* Daraus wird ein String generiert, der signiert wird mit einem privaten Schlüssel
* Die Signatur wird in ein Key File gepackt, das der Anwender rein kopiert
* Die Anwendung prüft mit dem öffentlichen Schlüssel, dass der eingegebene Name & Co passt.
* Das wird beim Start auch angezeigt "Lizenziert für XY"

Genau, so was habe ich mir vorgestellt :)

Verstehe ich das richtig, dass:

* Daraus wird ein String generiert, der signiert wird mit einem privaten Schlüssel
Die Generierung des Strings und die Signierung, ausserhalb der eigentlichen Applikation geschieht?
Gibt es Tools um solche dinge zu machen?

* Die Signatur wird in ein Key File gepackt, das der Anwender rein kopiert
Wäre es hier nicht besser, dass man das Key File bei der Installation selbst ein wenig versteckt? Also vielleicht irgendwo ablegt, wo man nicht gerade hinkommt?

Ansonsten kann man ja das ganze wieder relativ einfach per copy/paste mal versuchen neu zu installieren.

* Die Anwendung prüft mit dem öffentlichen Schlüssel, dass der eingegebene Name & Co passt.
Kenne mich noch zuwenig mit privaten und öffentlichen Schlüssel aus. Hat dann die Anwendung jeweils immer denselben öffentlichen Schlüssel?
Oder gibt es pro Installation ein Schlüsselpaar?


@Robert Zenz Das tönt nach einer sehr tollen Umsetzung, jedoch auch Aufwendig, da einen "Lizenzserver" benötigt....
 
K

kneitzel

Gast
Als Zweites fuehrst du einfach nur, alle paar Stunden oder Tage, einen Anruf Zuhause durch
Da wäre ich aber vorsichtig. Da wertest Du personenbezogene Daten aus (Eine ip ist schon personenbezogen! Über Namen muss man nicht erst diskutieren!). Das würde ich also nicht einfach so einbauen. Und wenn es nur ein Kunde ist, ist die Frage, ob und wie der da zustimmt.

Ich frage mich da gerade, wie da die Zusammenarbeit mit dem einen Kunden ist. Wieso sollte der eine Kunde es weiter geben? Die Zusammenrbeit sollte doch eigentlich passen. Da würde ich eher über eine Zusammenarbeit nachdenken: Der Kunde bekommt Benefits und hilft Dir bei der Vermarktung. Wie das genau aussieht, muss man schauen. Das können finanzielle Anreize sein oder evtl. auch schon rein die Sicherung der Weiterentwicklung bzw, eine Mischung. Es ist ja eine Firma / Gewerbe, die werden also Kostenrechnungen und so kennen. Und da ist klar: Ein Update macht x Stunden Arbeit. Damit man die x Stunden macht muss da also mind. Betrag x*y bei raus kommen. Ohne weitere Kunden hat er das zu bezahlen. Bei 2 Kunden, dann teilt sich das etwas auf. Bei ganz vielen Kunden (mit seiner Hilfe) bekommt er es evtl. für lau oder kriegt gar Provisionen wenn die anderen Kunden das Update kaufen ...

Also da ist doch eine Zusammenarbeit existenziell. Und wenn man für regelmäßige Updates sorgt, dann werden Leute mit Kopie das doch auch haben wollen ... Darüber kann man also auch eine Kundenbindung hin bekommen. Setzt aber voraus, dass die Anwender die Anwendung und die Updates auch haben wollen.

Aber die Idee von @LimDul ist sehr vernünftig. Das zusammen mit jpackage oder so um ein Binary zu bekommen....
 
K

kneitzel

Gast
Also wie Du das genau machst, ist dir überlassen. Zur Not machst Du nur etwas wie eine Checksumme / Hash und speicherst das mit ab.
(Das ist dann aber nur Security by Obscurity - das ist dann wie damals bei Microsoft, wo Keys ähnlich validiert wurden).

Aber du findest z.B. bei Bouncycastle auch einige Beispiele, wenn ich das richtig sehe:
Bei x509 sollte das Zertifikatsbasierte Signieren zu finden sein.
Openpgp Beispiele dürften das dann mit den pgp basierten Keys zeigen.

Generell braucht es bouncycastle nicht - Java bietet auch von Hause aus alles, was man braucht. Aber mit der Library wird es evtl. einfacher...

Wenn Du Dir das Thema richtig erarbeiten willst, dann wäre meine Empfehlung: https://leanpub.com/javacryptotoolsandtech
Da handelt ein ganzes Kapitel das Signieren.
 

Robert Zenz

Top Contributor
Da wäre ich aber vorsichtig. Da wertest Du personenbezogene Daten aus (Eine ip ist schon personenbezogen! Über Namen muss man nicht erst diskutieren!). Das würde ich also nicht einfach so einbauen. Und wenn es nur ein Kunde ist, ist die Frage, ob und wie der da zustimmt.
Ist richtig. Ist aber die Frage wie genau die Geschaeftsbeziehung eigentlich aussieht, mit hoher Wahrscheinlichkeit wird es reichen dass irgendwo im Vertrag oder beim Kauf stehen zu haben. Beziehungsweise wenn die einen laufenden Service-/Wartungsvertrag haben, wird die Firma wahrscheinlich ohnehine auf die ein oder andere Art und Weise das Recht haben Daten zu verarbeiten. Aber es stimmt dass ich hier wahrscheinlich nicht ganz auf dem neuesten Stand bin was das Rechtliche angeht.
 

LimDul

Top Contributor
Genau, so was habe ich mir vorgestellt :)

Verstehe ich das richtig, dass:


Die Generierung des Strings und die Signierung, ausserhalb der eigentlichen Applikation geschieht?
Gibt es Tools um solche dinge zu machen?
Ja. Irgendwo bezahlt und kauft der Kunde ja das Programm. Da bekommt er das erzeugte Key File mitgeliefert. Das war beim / nach dem Kauf erzeugt.
Wäre es hier nicht besser, dass man das Key File bei der Installation selbst ein wenig versteckt? Also vielleicht irgendwo ablegt, wo man nicht gerade hinkommt?

Ansonsten kann man ja das ganze wieder relativ einfach per copy/paste mal versuchen neu zu installieren.
Warum willst du unbedingt die Neuinstallation verhindern? Ein Programm, was es nicht erlaubt sich einfach neuzuinstallieren zu lassen ist im Unternehmensumfeld ziemlich schnell auf der Abschussliste:

* Rechner sind in Unternehmen in der Regel Leasinggeräte
* Die werden häufig (alle 3 Jahre oder öfter) ausgetausch
* Hardwaredefekt? => Neuer Rechner
* Rechner werden oft per Image installiert
Viele Unternehmen haben mittlerweile auch virtuelle Umgebungen. Ein Anwendung die sagt "Ich will mich aber an die physische Hardware binden" verursacht da schnell spürbare Kosten. Entweder du machst explizit ein Modell mit Anzahl Installationen / gleichzeitige Benutzer mit allen Konsequenzen (Sprich verfügbarer Lizenzing Server, der das real time prüfen kann etc.) oder du lebst damit das der Kunde die Anwendung auf zwei Rechnern installieren kann. Alles andere sorgt dafür, dass die Anwendung schnell ein schlechtes Image hat und lieber gar nicht mehr verwendet wird.


Kenne mich noch zuwenig mit privaten und öffentlichen Schlüssel aus. Hat dann die Anwendung jeweils immer denselben öffentlichen Schlüssel?
Oder gibt es pro Installation ein Schlüsselpaar?
Der öffentliche Schlüssel ist immer gleich. Das Verfahren ist dabei eigentlich im Prinzip simpel.

Man gibt als Lizenznehmer die "Max Mustermann GmbH" an. Da wird (mit dem privaten Schlüssel) der String h789Xeb berechnet.

Die Anwendung kann nun prüfen, ob der String h789Xeb zu der Eingabe Max Mustermann GmbH passt. Es ist aber nicht möglich ohne den privaten Schlüssel den Text von Max Mustermann GmbH auf Maria Musterfrau GmbH zu ändern, den dazu passenden String kann man nicht berechne. Konsequenz: Wenn die Anwendung weitergegeben wird, steht bei Start immer "Lizenziert für die Max Mustermann GmbH". Das heißt jeder Mitarbeiter in der Maria Musterfrau GmbH, der die weitergegebene Anwendung nutzt würde sehen, dass sie nicht lizenziert ist.
 

izoards

Bekanntes Mitglied
Warum willst du unbedingt die Neuinstallation verhindern? Ein Programm, was es nicht erlaubt sich einfach neuzuinstallieren zu lassen ist im Unternehmensumfeld ziemlich schnell auf der Abschussliste:

Er soll die Software ja schon installieren können, jedoch fehlt Ihm dann das Key File, da er es nicht so einfach findet. (So meinte ich das)

Man gibt als Lizenznehmer die "Max Mustermann GmbH" an. Da wird (mit dem privaten Schlüssel) der String h789Xeb berechnet.

Die Anwendung kann nun prüfen, ob der String h789Xeb zu der Eingabe Max Mustermann GmbH passt. Es ist aber nicht möglich ohne den privaten Schlüssel den Text von Max Mustermann GmbH auf Maria Musterfrau GmbH zu ändern, den dazu passenden String kann man nicht berechne. Konsequenz: Wenn die Anwendung weitergegeben wird, steht bei Start immer "Lizenziert für die Max Mustermann GmbH". Das heißt jeder Mitarbeiter in der Maria Musterfrau GmbH, der die weitergegebene Anwendung nutzt würde sehen, dass sie nicht lizenziert ist.

danke für die Erklärung
 
G

Gelöschtes Mitglied 65838

Gast
Warum lizensierst du den Code nicht einfach? wenn es jemand weiter gibt kannst ihn verklagen wegen urheberrechts verletzung...


das ist die einfachste Möglichkeit

eine "Hürde" ist genauso wie wenn du sagst "wenn du es schaffst über die Hürde dann darfst duu es vervielfältigen"


und zusätzlich eine Account Sicherung einbauen und ohne den Account ist das Programm nutzlos
 

mihe7

Top Contributor
Warum lizensierst du den Code nicht einfach? wenn es jemand weiter gibt kannst ihn verklagen wegen urheberrechts verletzung...
Irgendwas hast Du da falsch verstanden. Das Urheberrecht gilt immer, sobald eine gewisse (sehr niedrige) Schöpfungshöhe erreicht ist. Ohne eingeräumte Nutzungsrechte (aka Lizenz) darf das Programm niemand nutzen. Nutzungsrechte können sich implizit auch aus einem Vertrag ergeben, dann sind sie auf das beschränkt, was der Vertrag hergibt.
 
G

Gelöschtes Mitglied 65838

Gast
der code kann als "lizenzfreier" code verstanden werden der zur absolut freien benutzung bereit steht
 

mihe7

Top Contributor
Schöpfungshöhe nicht erreicht. Aber im Grundsatz stimmt das: wenn Du hier Code veröffentlichst und keine Quelle angibst, ist erstmal anzunehmen, dass Du der Urheber bist. Dementsprechend entscheidest Du auch über die Nutzung.

Lies dazu auch mal die Formulierung in den Forenbedingungen: "Du gewährst uns eine nicht-exklusive, permanente, unwiderrufliche, unbegrenzte Lizenz zur Nutzung, Veröffentlichung oder Wiederveröffentlichung deiner Inhalte in Verbindung mit dem Service. Du behälst das Urheberrecht an den Inhalten." (@tbone78, da ist übrigens ein Tippfehler: behältst)
 
K

kneitzel

Gast
Da ist der erwähnte Punkt der Schöpfungshöhe ...
Ansonsten kommst du mit nicht übersetzbaren Code nicht wirklich weit ...
 
G

Gelöschtes Mitglied 65838

Gast
gibt es auch eine Lizenz wenn ich zb eine CSS datei hab und sage
"die Veränderung der datei ist erlaubt aber die weiter verbreitung nicht"
 
K

kneitzel

Gast
Ohne deine Erlaubnis wird eine CSS Datei niemand weiter geben dürfen - so da eine gewisse Schöpfungshöhe erreicht ist. Bei komplexeren CSS ist das durchaus der Fall meine ich.

Du musst es nur nachweisen können. Wenn ich Deine CSS nehme und z.B. gewisse Anpassungen mache, dann wird es schon schwer fallen, da den Beweis anzutreten. Die Beweislast liegt hier bei Dir. Aber wenn ich da Deine Datei 1:1 kopiere und da noch ein Kommentar (c) 2021 by Joreyk drin ist, dann ist es ein Problem ...

Wobei die Lage schwierig ist, wenn ich Deine CSS nicht kopiere und nur in meiner Seite auf Deine CSS verweise .... Dann nutze ich nur Deine URL. Und die Clients laden es halt runter und nutzen es ... Da wäre mal ein Gerichtsbeschluss interessant :)
 
G

Gelöschtes Mitglied 65838

Gast
dann wäre es vllt sinnvoll die CSS dateien unter GPL2 zu lizensieren und den source coude unter einer proprietary Lizenz


ausserhalb des Programms kann man ja mit der CSS nichts anfangen die ist ja nicht wirklich komplex
 
K

kneitzel

Gast
Wenn die CSS nicht komplex ist, musst du Dir da keine Gedanken machen, da dann evtl. eh die Schöpfungshöhe nicht erreicht wird.
 

Robert Zenz

Top Contributor
Warum lizensierst du den Code nicht einfach? wenn es jemand weiter gibt kannst ihn verklagen wegen urheberrechts verletzung...
Standardmaeszig ist alles "All Rights Reserved", wenn du Software kaufst bekommst du damit eine Lizenzvereinbarung die dir Rechte als Kaeufer einraeumt, zum Beispiel die Software zu haben und zu betreiben, und ziemlich genau immer hast du kein Recht diese weiterzugeben.

der code kann als "lizenzfreier" code verstanden werden der zur absolut freien benutzung bereit steht
Nein, so funktioniert Urheberrecht nicht. Wenn du Code schreibst, oder ein Bild malst, oder ein Lied schreibst, hast du automatisch das Urheberrecht auf deine Schoepfung. Du kannst das Urheberrecht nicht los werden, du hast es automatisch, es ist immer da. Das bedeutest du als Urheber darfst bestimmen was damit geschieht, das inkludiert die Verbreitung und ob es jemand haben darf, und ob es jemand veraendern darf. Alles ist also standardmaeszig "All Rights Reserved" (auch bekannt als "das ist meines, du darfst nichts!"). Wenn du jemandem Rechte einraeumen willst, zum Beispiel die Verwendung, musst du es lizenzieren. Jetzt koenntest du sagen "ich stelle es in die Oeffentlichkeit/Public Domain", das ist eine nette Aussage von dir, aber rechtlich geht das in den meisten Laendern nicht. In Deutschland gehen Dinge automatisch bei bestimmten Kriterien in die Public Domain ueber, aber es gibt keine Moeglichkeit dies aktiv zu tun. Also "Public Domain" ist keine valide Lizenz. Wenn dir jemand sagt "ich stelle diesen Code unter Public Domain, also verwende ihn ruhig" ist das keine valid Lizenz und wenn du den Code tatsaechlich verwendest, stehst du auf wackeligem rechtlichen Grund. Also immer darauf achten dass das was du verwendest auch eine valide Lizenz dabei hat (GPL, MIT, BSD, CC0, ...).

Wieso ist das wichtig? Stell dir vor du erhaeltst relativ viel Code von jemandem, derjenige sagt "ja, das ist Public Domain von mir aus" und du baust darauf eine riesige Firma. Du verdienst viel Geld, originaler Autor will nichts davon, alle sind gluecklich. Jetzt stirbt der originale Autor und alles geht an einen nahen Verwandten ueber. Dieser Verwandte lernt dass deine Firma mit Hilfe von Code von dem Toten aufgebaut wurde, und fragt dich unter welcher Lizenz das eigentlich passiert ist. Du sagst "joah, Public Domain", so, jetzt fragt dieser Verwandte mal kurz einen Anwalt was das heiszt und der sagt "ja, eigentlich nicht zulaessig". Das bedeutet deine gesamte Firma baut jetzt auf einer Urheberrechtsverletzung auf. Doof gelaufen fuer dich.

Eine Anekdote dazu ist wieso jede Lizenz die Worte "...unrevocable right to..." enthaelt. Oracle, wir kennen Oracle, ja die grosze Firma. Die hat vor etwa zehn Jahren Sun gekauft, ja, das MySQL und Java Sun. Sun hatte auch noch andere Produkte, zum Beispiel Solaris. Solaris ist ein sehr gutes UNIX welches unter einer freien Lizenz stand und steht. Es wird sehr viel auf der Server-Seite verwendet und hat eine grosze Fan-Gemeinschaft hinter sich, insbesondere im kommerziellen Bereich. Nachdem Oracle Sun gekauft hatte, haben diese beschlossen so viel wie moeglich zu Geld zu machen, und das inkludierte auch Solaris. Und wie macht man am einfachsten mit freier Software Geld? Richtig, man verklagt alle Verwender wegen Urheberrechtsverletzung. Oracle hat die Lizenz von Solaris zurueckgezogen. Sie haben das nicht nur fuer zukuenftige Versionen getan, sondern sie wollten das fuer alle Versionen machen. Aber die Lizenz von Solaris war gut genug formuliert dass es kein Schlupfloch dafuer gab, und die einmal eingeraeumten Rechte durch die Lizenz, konnten von Oracle nicht zurueck genommen werden. Dennoch wurden alle zukuenftigen Versionen nur noch als closed-source angeboten. Aber die freie Version von Solaris lebt heute, nach etwas hin und her, als openindiana weiter.
 

thecain

Top Contributor
Google vs. Oracle ist da auch ein spannender Fall. Auf eine Zusammenfassung verzichte ich aber hier, weil ich es eh nur verfälschen würde
 

izoards

Bekanntes Mitglied
ich würde folgendes bauen, weil das meines Erachtens die wenigsten Einschränkungen hat:
* Man gibt beim Kauf Namen und Co an
* Daraus wird ein String generiert, der signiert wird mit einem privaten Schlüssel
* Die Signatur wird in ein Key File gepackt, das der Anwender rein kopiert
* Die Anwendung prüft mit dem öffentlichen Schlüssel, dass der eingegebene Name & Co passt.
* Das wird beim Start auch angezeigt "Lizenziert für XY"

Ich bin nochmals an diesem Thema dran und habe mir nun folgendes überlegt.

- Ich erstelle mir ein RSA - Private- und Public Key Paar.
- Der "Lizenznehmer" gibt Name und Co an.
- Daraus verschlüssle ich diese Info mittels Public Key
- die verschlüsselte Info, wird dann als Key File mitgeliefert
- Die Anwendung entschlüsselt das Key File mit dem private Key, welcher fix im Code drin ist.
(- Nun käme der Vergleich, welcher mit einer online DB gemacht werden könnte. )
- Da online nicht in Frage kommt, würde ich das Key File irgendwo unter einem Pfad zusätzlich ablegen. (Das sollte sozusagen die online Verifizierung "simulieren")
- Wenn diese beide key's übereinstimmen, startet das Programm und zeigt den entschlüsselten Lizenznehmer an.


Ist das in etwa so das korrekte Vorgehen?

Was ich nicht ganz verstehe, ist, dass ich eigentlich den Private Key hier "freigebe" (Also er ist in der SW drin)!?


Oder ist das mit "Signieren" anderst gemeint? Ich glaube ich verstehe das signieren noch nicht ganz,

So wie ich das "Signieren" verstehe, würde man ja genau umgekehrt vorgehen, indem man einen plain Text mittels private Key "verschlüsselt"
Danach würde das Programm mittels Public Key den "signierten" plain - Text irgendwie verifizieren... und könnte sagen, dass dieser plain Text mit dem private Key "verschlüsselt" wurde.
So wäre ja gar nicht möglich, dass ich an den plain Text komme und den Namen und Co angeben könnte?

Kann mir hier jemand Licht ins Dunkle bringen? Ich steh grad ziemlich auf dem Schlauch 🙈
 

mihe7

Top Contributor
Du erzeugst mit Deinem privaten Schlüssel eine Signatur, die mit dem öffentlichen Schlüssel überprüft werden kann. Die Signatur kann natürlich auch in einer separaten Datei stehen, das spielt letztlich keine Rolle. Damit lässt sich sicherstellen, dass die Inhalte der "Lizenzdatei" nicht verändert wurden.

Der Vollständigkeit halber, damit hier niemand auf dumme Gedanken kommt: einen wirklichen Kopierschutz bietet das natürlich auch nicht. Lediglich die Hürden werden höher.
 

LimDul

Top Contributor
- Name & Co wird angegeben - Nennen wir den Wert mal X
- Es wird damit mittels private Key eine Signatur von X berechnet PRIVATE_KEY(X) = Y.
- Y wird dem Lizenznehmer zur Verfügung gestellt
- Die Anwendung startet, der Lizennehmer gibt Namen & Co an - X'
- Mittels des Public Keys wird geprüft, ob Y zu X' passt. (Das gibt nur dann True, wenn X = X')
- Wenn ja, wird Ausgegeben "Lizenziert für X'" (Was ja gleich zu Lizenziert für X ist)

Sobald jemand etwas eingibt, was nicht X ist, schlägt die Prüfung an oder sobald jemand Y modifiziert.

Siehe auch hier: https://de.wikipedia.org/wiki/Digitale_Signatur#Das_Grundprinzip
 

izoards

Bekanntes Mitglied
Ich mache das ganze jetzt über die PC Serienummer.
Also Serienummer wird signiert (mit PrivateKey), Kunde erhält "Key-File"
Programm liest beim Start PC Serienummer aus und verifziert gegen das "Key-File" mit dem public Key...

Sieht Ihr hier Probleme?

Ein Kollege meinte noch, dass man das über das TPM machen könnte (Trusted Platfrom Module)
 

LimDul

Top Contributor
Das "Problem" was ich sehe, dass damit bei jeder Änderung der der Hardware, die Einfluss auf die Seriennummer hat, man ein neues Key File braucht. Technisch sehe ich kein Problem, außer das man halt seine Software damit unattraktiver macht.
 

kay73

Bekanntes Mitglied
Antiquierter Thread, aber identische Anforderung: https://www.java-forum.org/thema/seriennummer.108274/

Lief dann irgendwann aus dem Ruder, aber es hängt eine RSA Implementierung mit handhabbarer SN dran. Für den zu signierenden Hash kannst Du Dir ja was ausdenken (MAC-Adresse + Arbeitsspeicher- / Festplattengröße + etc... aber sei da vorsichtig). So ab Post #20 geht es los...

In dem oben erwähnten Post ist natürlich der defeat erwähnt; das gilt natürlich weiterhin...
 
Zuletzt bearbeitet:
Ähnliche Java Themen

Ähnliche Java Themen

Neue Themen


Oben