Ich möchte noch einmal darauf hinweisen, dass mir kein Schutzmechanismus in Java bekannt ist, mit dem erstens Lizenzen erfolgreich verwaltet
und andererseits die Anforderungen an die Umgebung des Kunden adäquat abgedeckt werden können.
Mit diesem Thema habe ich mich ergiebig auseinander gesetzt und gefunden, dass alle Mechanismen leicht ausgehebelt werden können.
Denn letztendlich muss jedes Java-Programm über den Class File Verifier der JVM gültigen Bytecode repräsentieren. Spätestens an dieser Stelle muss der Bytecode in JVM-kompatibler Form vorliegen. Alle Dinge, die vorher gemacht wurden, wie beipsielsweise Verschlüsselung der
class-Dateien und Laden derselben über einen eigenen Classloader sind dann hinfällig.
Also lässt sich der Aufruf einer Routine, die prüft, ob ein Benutzer lizenziert ist, ausbauen oder immer mit ja beantworten, also keine Lizenzkosten notwendig.
Ich hatte mal ein System entworfen, in denen Kunden über verschlüsselte Informationen(Zertifikate für Kunde/Anbieter liegen vor) und somit angeben welchen Typ von Lizenz sie benötigen. Danach erstellt der Anbieter eine Schlüsseldatei und überträgt sie zum Kunden. Beim Programmstart wird geprüft, ob das Programm ausreichend lizenziert ist, indem die Lizenzdatei gelesen, entschlüsselt und ausgewertet wird.
Wie oben aber bereits erwähnt, ist dieses "nur" ein Grund, der die Attacke auf das Programm erschwert aber nicht unmöglich macht.
Andere Optionen wären:
Abfrage der Lizenz über das Netzwerk beim Programmstart
Dieses ist eine gute Option, aber meistens nicht mit den Sicherheitsrichtlinien des Kunden vereinbar.
Eine Subalternative wäre die Installation eines Lizenzervers beim Kunden
Dieses ist aber aus offensichtlichen Gründen ebenfalls schwer umsetzbar. Diesmal kann der Kunden natürlich den Server selbst kompromittieren und daher ist das Sicherheitskonzept per se ausgehebelt.
Verdongelung der Software
Dieses ist eine weitere gute Option und kann mit minimalen Aufwand für Anbieter/Kunde umgesetzt werden. Hierbei werden insbesondere die beiden Punkte Verschlüsselung und Sicherstellung das die JVM nicht manipuliert wurde, kombiniert. Mit WibuKey als Beispiel wird für den Kunden ein spezieller Code erzeugt und in den USB-Dongle geschrieben. Gleichzeitig wird die Software verschlüsselt und kann nur noch mit dem richtigen Dongle entschlüsselt werden. Dabei verifiziert die Wibu-SW, dass keine Manipulationen zum Beispiel an den Classloadern der JVM erkannt werden.
Alles in allem, war die Verdongelung der SW die Lösung, die eingesetzt wurde, zumal dies mit überschaubaren Aufwand und Kosten gemacht werden kann.
Leider bietet die JVM nur unzureichende Möglichkeiten des Schutzes der Java-Software. Vielleicht deshalb ist ein extrem großer SW-Bereich Open-source und es wird eher mit (weiteren) Dienstleistungen oder Support gearbeitet.
Ich kann mir auch nicht vorstellen, das deine SW einen sooo grossen Mehrwert erzeugt, dass sich dieser ganze Schutz-Aufwand lohnen würde, zumal geschickt formulierte Eula's hier gut helfen können.
Da ist die Speicherung von MAC-Adressen in der DB beim Anbieter nur ein geringes Problem, wobei dies, wie bereits erwähnt, in den Nutzungsbedingungen erwähnt werden kann.
Also kannst du diesen Weg weiter verfolgen, aber ich habe dich gewarnt wg. des Aufwandes, der Qualität des Schutzes und der
Akzeptanz beim Kunden.