Seriennummer

[Manuela]

Hallo,

ich soll für unseren Auftraggeber
eine Seriennummer in seiner Software einbauen.
bloß habe ich das Problem das die Freischaltung so ablaufen soll.
Unser Kunde verkauft die Software und möchte diese mit einer Seriennummer sichern.
Ich weis das es keinen hundertprozentigen Schutz gibt.

Jetzt aber zu Vorgehensweise.:
1. Kaufer installiert Software
2. startet Software
3. Es erscheint ein Fenster für den Freischaltcode
4. Käufer ruft an um die Seriennummer zu erhalten.
5.Unser Auftraggeber (startet seinen Key-Generator) den ich noch programmieren muß und
erhält den Code.

Vollgendes habe ich vor.:
Ich will einen Algorithmus erstellen, der eine Seriennummer als Richtig erkennen kann
(keine Ahnung wo ich da ansetzen kann).
Denn es macht keinen Sinn eine Nummer-oder mehrere Nummer in der Software zu hinterlegen.

ich bin für alles offen.

Gruß Manuela

 

[HoaX]

Und die Frage ist jetzt was?

 

[Manuela]

Hallo :lol:

Die Frage ist: wie ich am besten vorgehen kann um das zu bewerkstelligen.

Gruß Manuela

 

[Spitfire777]

Hi,

ich bin zwar nicht von dem Fachgebiet, daher lasse ich mich gerne korrigieren.

Ich würde folgenden Ablauf vorschlagen:
1. Sobald ein Produkt initiiert (fertig produziert bzw. verkauft wurde) wird, wird ein Algorithmus ausgeführt, der einen Key nach irgend einer Verschlüsselungsart (MD5, SHA1, oder so) generiert. Somit kann man eigentlich schonmal ausschließen, dass jemand den Algorithmus anhand des Key knackt.
2. Mit dem Generieren wird dieser Key in eine Datenbank eingetragen und die Möglichkeit der Zuordnung zu einem Account intern offengelassen.

Aktivierung:
- Grundsätzlich soll bei jedem Öffnen der Software eine Authentifzierung mittels Key und Account erfolgen. Dieses würde dann über den gespeicherten Key funktionieren.
- Ist kein Key gespeichert, muss dieser zusammen mit einem Account registriert werden und dann mit diesem (nicht in der GUI, im Hintergrund) eingeloggt werden, damit man die Software nutzen kann.

 

[Gott148814]

Macht alles keinen Sinn, da man den Java Bytecode ja wieder in Klartext umwandeln kann und so immer sieht was du da gemacht hast..

 

[CHBenutzer]

Macht alles keinen Sinn, da man den Java Bytecode ja wieder in Klartext umwandeln kann und so immer sieht was du da gemacht hast..

Macht es doch. Dafür wurden auch Code-Obfuscatoren entwickelt.

 

[Spitfire777]

@Gott: Generiert wird aber durch den Server.

Und das Cracken der Clientsoftware kann man auf kurz oder lang eh nicht verhindern.

 

[Manuela]

Hallo,

Also die Käufer des Programm sind Leute die Froh sind einen Computer anzubekommen also keine cracks.

also gehen wir mal davon aus das keiner das programm dekompieliert ( auserdem verschleiern wir das programm )

aber das ist nicht das problem.

Gruß Manuela

Ps.: Also wie könnte ich vorgehen ???

 

[mvitz]

Naja, halt irgendwie einen Algorithmus dir ausdenken, der funktioniert. Simple Beispiele wären z.B.:

Der Rest des Codes muss 0 sein.
Oder die Quersumme des Codes muss 5 sein.

So Dinge lassen sich dann beliebig kombinieren.

 

[Spitfire777]

Haja, du schreibst halt nen Aktivierungsserver, der mit Verkauf des Produkts eine Seriennummer mittels irgend ner Verschlüsselungstechnik (SHA1 oder so..) generiert und in eure Produktdatenbank schreibt.
Der Code ist nun zum registrieren freigeben und wird dem Kunden zugesendet. Der Kunde muss dann um den Code auf sich (und auch nur auf sich) zu registrieren, in der Software dann den Code und seine Logindaten eingeben. Die werden dann beim Kunden irgendwo lokal gespeichert und beim jedem Starten der Software übermittelt. Nach der Registrierung ist der Code nicht mehr auf einen neuen Account registrierbar.

Edit: So Sachen mit Quersumme ist aber auch unsicher, da kann man dann sehr leicht einen Keygenerator schreiben kann, um die Software ungehindert illegal nutzen zu können.

 

[Manuela]

Hallo,

Spitfire777 :
Also so wie ich das Verstehe muß der Rechner immer am Netz sein um damit zu Arbeiten ?


Das Problem ist so das die Software zu 90 % auf Laptops installiert sind und KEINE Verbindung zum Internet hat.

Gruß Manuela

 

[Spitfire777]

Jop, das wäre die Kehrseite.

 

[slawaweis]

wenn man keine Erfahrung mit solchen Sachen hat, würde ich erst gar nicht selber programmieren, sondern die Technik irgendwo anders einkaufen. Ich denke es gibt bestimmt Anbieter, die solche Algorithmen und/oder Frameworks auch für Java anbieten. Kostet natürlich was, aber dafür wäre es sicherer, würde extern gepflegt und der Hersteller hat bestimmt Erfahrung damit, wie man so ein System abdichtet.

Slawa

 

[Tomate_Salat]

Wenn dass doch eh über einen Kundendienst laufen soll:
Mach ein Formular, indem der Kunde Daten zu sich angeben muss, über die ihr ihn idendifizieren könnt. Das Programm baut eine Verbindung zum aktivierungsserver auf und der Kunde kontaktiert euch, nennt seine Daten und wird Freigeschaltet.

Der aktivierungsserver sendet ieine Message, dass das Programm weis: ich bin legal und ab dann ist keine Internetverbindung mehr notwendig.

 

[Yamato]

Man benötigt eine Einwegfunktion mit Falltürinformation.

Der Keygenerator des Herstellers erzeugt aus einem Startwert s (der eine bestimmte Eigenschaft hat, z. B. eine Zahl in einem bestimmten Intervall) einen Key k = f(s). Der Kunde kauft einen solchen Wert k vom Hersteller. Die Software berechnet s = g(k), wobei g die Umkehrfunktion von f ist. Die Software prüft dann, ob das berechnete s die bestimmte Eigenschaft hat.

Folgende Bedingungen müssen erfüllt sein:
1.) Ein Angreifer darf die Funktion g kennen, nicht aber f
2.) Die Eigenschaft für den Startwert s muss derart speziell sein, dass es extrem unwahrscheinlich ist, durch zufällige Wahl eines Keys k einen Wert s = g(k) zu erzeugen, der diese Eigenschaft hat

Eigenschaft 1.) ist erfüllt, wenn g eine Einwegfunktion ist. Die besagte Falltürinformation ermöglicht die Berechnung von f, die der Keygenerator vornimmt. Beispielsweise die beim RSA-Verfahren verwendete.

 

[Spitfire777]

Oder nochmal zu meiner Idee bzw. zu der von Tomate Salat... Man könnte dem Kunden auch die Möglichkeit offen lassen, um zu prüfen, ob nur er den Key nutzt.
Somit kann er im Falle eines geklauten Keys die Echtheit seiner Lizenz beweisen.

 

[Manuela]

Hallo,

ich hatte eine Verschlüsslung gemacht die unseren Kunden nicht gefallen hat
(diese hatte ich mit Hardware gekoppelt und der Käufer mußte dem Verkäufer einen
String angeben (tel -email)
der in etwa so ausgesehen hat: 86DF40-E4AE61-6CFB4B-3133FE-311010-09BB1F-8F7145
diese wurde eingetragen und mit einem Gegencode der aus 6 Blocken a. 6 Zeichen besteht in seine
Software eintragen Fertig.
aber das war unserem Auftraggeber zu Kompliziert und das die Software auf nur einem Rechner
funktioniert hätte.

Unser Kunde will auf keinen Fall das der Käufer irgendeine Nr. durchgeben soll.
also Käufer ruft an und bekommt eine Nr. gesagt die er Eintragen muß und die Software soll dann Funktionieren.

Tomate_Salat:
Ich muß das ganz ohne Internet machen.


Spitfire777 : ????

Yamato:

Dein Vorschlag scheint Interesant zu sein. Kannst du mir das ein wenig ausführlicher erklären.

Gruß Manuela

 

[Wookie81]

Unser Kunde will auf keinen Fall das der Käufer irgendeine Nr. durchgeben soll.
also Käufer ruft an und bekommt eine Nr. gesagt die er Eintragen muß und die Software soll dann Funktionieren.

:lol: Mach ne Eingabebox und wenn der Käufer "Software freigeschaltet" eingibt, dann ist sie freigeschaltet! :lol:

Das was du gemacht hast hört sich doch ganz vernünftig an und du hättest durchaus mal erwähnen können was du schon alles gemacht hast und was die genaue Randbedingungen sind! Wenn der Käufer keine Informationen durchgeben, die Installation nicht computergebunden sein soll, es kein Internet gibt und die Software für Computerlaien ist, würde ich einfach eine der vorgeschlagenen Berechnungen nehmen (beliebige Zahlen deren Quersumme gleich 0 ist o.ä.).

Yamatos Vorschlag könnte man zum Beispiel mit einem Schlüsselpaar und asymmetrischer Verschlüsselung (bzw. Signatur) lösen. Das ganze aber noch so zu gestalten, dass der Käufer keine ewig lange Nummer eingibt, ist sicher nicht einfach! Und vielleicht auch Overkill ... je nachdem von welcher Software wir hier reden?

Gruß,
Wk

 

[kay73]

Das ganze aber noch so zu gestalten, dass der Käufer keine ewig lange Nummer eingibt, ist sicher nicht einfach! Und vielleicht auch Overkill

Sowas kam mir auch gerade in den Sinn. Man könnte sich ja den Spaß machen, RSA einfach aus Wikipedia abtippen und p,q nicht zu groß zu machen. Außerdem auf das Padding verzichten und eine kurze Zufallszahl zu signieren. Mit Javas BigInteger sollte das kein Problem sein.

 

[Wookie81]

Sowas kam mir auch gerade in den Sinn. Man könnte sich ja den Spaß machen, RSA einfach aus Wikipedia abtippen und p,q nicht zu groß zu machen. Außerdem auf das Padding verzichten und eine kurze Zufallszahl zu signieren. Mit Javas BigInteger sollte das kein Problem sein.

Genauso hab ichs mir gedacht aber der Aufwand? Nein danke ...

@Manuela: Du könntest dann quasi eine Zufallszahl und die Signatur (z. B. 12345-Signa) an den Käufer schicken und deine Software prüft mit einem (oder mehreren) öffentlichen Schlüssel ob die Werte zusammenpassen. Hat den Vorteil, dass man beliebig viele Schlüssel generieren kann.

Wk

 

[kay73]

Genauso hab ichs mir gedacht aber der Aufwand? Nein danke ...

Nö wieso. Bekommst Du alles geschenkt, denn BigInteger hat genau die modulo-Operatoren die man braucht! :toll:

Wahrscheinlich sind die Werte alle doof gewählt (besonders der "hash"), bei

genKeyPair()

fliegt des öfteren mal eine "BigInteger not invertible" Exception, aber es reicht ja, ein einziges Mal ein Schlüsselpaar zu erzeugen. Mit 20 bit für p und q und message-Länge 10 ist man gerade noch im tippbaren Bereich, wobei ich das schon viel finde.

private key: 591912286555
public key: 887870315911
message: 4534287589
signature: 372512578630
valid: true

Als "Aktivierungsnummer" würde man z. B."4534287589 - 372512578630" schicken. Bisschen lang, 6-stellige message würde bestimmt reichen, und die Signatur wäre z. B. 7-stellig, wenn man p und q auf 14 bit setzt. So z. B.:

private key: 74482459
public key: 111745363
message: 987654
signature: 19913831
valid: true

Ich könnte mir vorstellen, dass es richtig schwer ist, das zu reverse-engineeren. Und so verkehrt kann der Code hier eigentlich nicht sein...

import java.math.BigInteger;
import java.util.Random;
import java.util.logging.Logger;


public class StupidRSA {

	private static final BigInteger E = BigInteger.valueOf(3L);
	
	static class KeyPair {
		public final BigInteger publicKey;
		public final BigInteger privateKey;
		
		public KeyPair(final BigInteger n, final BigInteger d) {
			this.publicKey = n;
			this.privateKey = d;
		}		
	} 
	public KeyPair genKeyPair() {
		final Random r = new Random();
		
		boolean hasPrime=false;
			
		BigInteger p=BigInteger.ZERO;
		while(!hasPrime) {
			p = BigInteger.probablePrime(20, r);
			hasPrime = p.isProbablePrime(8);
		}
		
		hasPrime=false;
		BigInteger q=BigInteger.ZERO;
		while(!hasPrime) {
			q = BigInteger.probablePrime(20, r);
			hasPrime = p.isProbablePrime(8) && !(q.equals(p));
		}
		
		BigInteger n = p.multiply(q);
		
		final BigInteger eTot = p.subtract(BigInteger.ONE).multiply(q.subtract(BigInteger.ONE));
		BigInteger d = E.modInverse(eTot);
		
		return new KeyPair(n, d);
	}
	
	public BigInteger hash(final BigInteger number) {
		return number.mod(BigInteger.valueOf(8379));
	}
	
	public BigInteger sign (final BigInteger number, final KeyPair kp) {
		return hash(number).modPow(kp.privateKey, kp.publicKey);
	}
	
	public boolean verify(final BigInteger message, final BigInteger signature, final BigInteger publicKey) {
		return hash(message).equals(signature.modPow(E, publicKey)); 
	}

	public static void main(String[] args) {
		
		final StupidRSA s = new StupidRSA();
		
//		final KeyPair kp = s.genKeyPair();
//		final KeyPair kp = new KeyPair(BigInteger.valueOf(418573), BigInteger.valueOf(278187));
		final KeyPair kp = new KeyPair(BigInteger.valueOf(887870315911L), BigInteger.valueOf(591912286555L));
		final BigInteger message = BigInteger.valueOf(4534287589L);
		
		final BigInteger signature = s.sign(message, kp);
		
		final boolean isValid = s.verify(message, signature, kp.publicKey);
		
		Logger.getAnonymousLogger().info(String.format("private key: %1$s\npublic key: %2$s\nmessage: %3$s\nsignature: %4$s\nvalid: %5$s", 
				kp.privateKey, kp.publicKey, message, signature, isValid));
	}

}

 

[mabuhay]

Hallo

Ich denke die Idee von kay73 ist ganz gut. Nicht all zu Kompliziert und auch nicht einfach so zu "knacken".

Kommt halt ganz darauf an wie teuer die Software ist, wie oft sie verkauft wird und wie wichtig es deinem Auftraggeber ist. Wenns wirklich sicher sein sollte dann müsste das schon jemand machen der Erfahrung mit Kryptografie und solchen Sachen hat.

mfg

 

[Wookie81]

@kay: Nice!

Als "Aktivierungsnummer" würde man z. B."4534287589 - 372512578630" schicken. Bisschen lang, 6-stellige message würde bestimmt reichen, und die Signatur wäre z. B. 7-stellig, wenn man p und q auf 14 bit setzt. So z. B.: ...

Man könnte die Nummern noch konvertieren, dass sie kürzer werden. Hex bringt jetzt nicht so viel, aber über Telefon kann man ja auch das gesamte Alphabet übermitteln:

Logger.getAnonymousLogger().info(String.format("private key: %1$s\npublic key: %2$s\nmessage: %3$s\nsignature: %4$s\nvalid: %5$s", 
                kp.privateKey, kp.publicKey, message.toString(36), signature.toString(36), isValid));

Wk

 

[Manuela]

Hallo,

Wookie81: du hast den Nagel auf den Punkt getroffen.

Ich darf natürlich nichts von der Software verraten, aber nur so viel dass diese im Medizinischen Bereich eingesetzt wird.
Ich kann dir sagen dort sind die größten "Dau's" die ich je gesehen habe.

Es gibt natürlich auch chrecks unter den Medizinern, aber die kannst du an einer Hand abzählen. :lol::lol:

Und kaufen nichts wenn Sie Angst haben es würde bei der Freischaltung Irgendwelche Daten ausgespäht.

Gruß Manuela

 

[Marcinek]

Da frage ich mich, wieso so eine aktivierung überhaupt notwendig ist.

Wenn dann sollen sie die korrekte Anzahl kaufen und fertig..

Das ist ja das paradoxe... Du kannst deine Software nur deswegen schützen, weil es sich für die Leute nicht lohnt die Software zu "hacken".

Grund dafür ist, dass sie dafür nicht ihr eigenes Geld ausgeben müssen

Bei dem o.g Verfahren: Wenn ich die Software von einem PC zum andere kopiere oder sie auf einem Terminal Server installiere, hat jede Software pot. den gleichen pk. Ergo auch mit dem gleichen key zu aktivieren Also auch sinnlos. BTW Bei asymmetrischen verschlüsselungen ist es das Ziel den PK auf keinen fall zu verraten.

~~
Ich würde einen pseudokey generieren, der ebenfals unsicher ist.

Dieser ist aber revesibel und enthält die Information: Du darfst die Module X Y Z der Software bis zum Zeitpunkt KKKK benutzen.

Wobei X schon das Programm selbst ist und Y und Z weitere Module...

 

[kay73]

...message.toString(36), signature.toString(36)...

Cool! Das Radix kannte ich gar nicht. Ich wollte das schon selbst implementieren. Sollte die Tipperei um 2/3 verkuerzen. Dann kann man bestimmt problemlos p und q auf 28 bit hochscrauben, den Hash 5- oder 6-stellig machen.

Ich finds in Seriennummern immer nur nicht schoen, wenn I,J und O enhalten sind. Aber am Telefon ist das ja egal. Eigentlich sollte Manuela jetzt mit einer vernuenftigen Loesung versorgt sein. Das hier sieht doch schon ziemlich brutal aus:

private key: 16038608168407987
public key: 24057912563732533
message: 22ZLIP1
signature: 2PD8CQWMD3N
valid: true

 

[Manuela]

Hallo,

Marcinek:
Ich gebe dir Rech was du sagst.

Aber es kommt wohl eher nicht darauf an ob der Käufer Die Software auf mehreren Rechnern hat.
Wichtig ist nur das die Software nicht illegal weitergeleitet wird.
Was ich noch erwähnen muß, ist des alle 1 bis 2 Monate ein Update gibt und das update wird auf einer Internetseite hinterlegt das mit seinem Namen und der Nr(Seriennummer) ausgeführt werden kann.
Und somit sehen wir schon wie oft ein update Downgeloadet wurde.
Dann der nächste Punkt ist wenn die Hotline benötigt wird (und spätestens da wissen wir ob es eine Illegale Version gibt).

gruß Manuela

 

[fastjack]

Soweit ich weis mußt Du gar nichts abtippen. Das Java-Crypto Paket sollte eigentlich alles mitbringen, was Du brauchst. Der Kunde braucht auch keine ellenlangen Zeichenketten einzugeben.

 

[fastjack]

Tip: Gibt doch in der Software noch zusätzlich aus, auf wen (Person oder Firma) die Software lizensiert wurde.

 

[Guybrush Threepwood]

Noch so ein Gedanke: Wo speicherst Du eigentlich "die Freischaltung". In der Registry, oder in einer externen Datei? In diesem Fall musst Du bedenken, dass Du z. B. bei Windows seit Vista nur noch in User-eigenen Verzeichnissen ablegen kannst, und nicht mehr im Programm-Ordner. Wenn die Freischaltung für alle Benutzer eines Rechners erfolgen soll, dann müssen die Programme auf Windowes im Administrator-Modus laufen, um systemweit Informationen ablegen zu können.
Hat jetzt nichts mit Deiner Frage an sich zu tun, aber vermutlich wirst Du noch auf dieses Problem stoßen.

 

[Wookie81]

Bei dem o.g Verfahren: Wenn ich die Software von einem PC zum andere kopiere oder sie auf einem Terminal Server installiere, hat jede Software pot. den gleichen pk. Ergo auch mit dem gleichen key zu aktivieren Also auch sinnlos. BTW Bei asymmetrischen verschlüsselungen ist es das Ziel den PK auf keinen fall zu verraten.

Äh moment: Wir hinterlegen den öffentlichen Schlüssel in der/jeder Software und signieren einen Zufallswert mit dem privaten Schlüssel. Klar kann man das gleiche Tupel Zufallswert/Signatur beliebig oft eingeben, aber bei den Rahmenbedingungen ist das immer möglich! (Und fällt wie wir gelernt haben spätestens beim Update auf)

Einzige Ausnahme wär es wenn man jede Software individualisiert ausliefert? @Manuela: Kannst du die Software für jeden Kunden anpassen?

Wk

 

[kay73]

Bei dem o.g Verfahren: Wenn ich die Software von einem PC zum andere kopiere oder sie auf einem Terminal Server installiere, hat jede Software pot. den gleichen pk. Ergo auch mit dem gleichen key zu aktivieren Also auch sinnlos.

Dem koennte begegnen, indem man z. B. nach der Aktivierung ein paar System-Properties in einem verschluesselten File ablegt. Wenn das File nicht da ist oder die Infos nicht mit den Properties uebereinstimmen muss neu aktiviert werden

BTW Bei asymmetrischen verschlüsselungen ist es das Ziel den PK auf keinen fall zu verraten.

So war das auch hier natuerlich gedacht, wie wookie schon erwaehnt hat

Soweit ich weis mußt Du gar nichts abtippen. Das Java-Crypto Paket sollte eigentlich alles mitbringen, was Du brauchst. Der Kunde braucht auch keine ellenlangen Zeichenketten einzugeben.

Stimmt schon, allerdings ist die Signatur hier 128 byte lang.

Simple Digital Signature Example : RSA algorithmSecurityJava Tutorial

 

[FerFemNemBem]

Halloechen,

Aber es kommt wohl eher nicht darauf an ob der Käufer Die Software auf mehreren Rechnern hat.
Wichtig ist nur das die Software nicht illegal weitergeleitet wird.

Wie soll das denn gehen? Wenn die Software in der Firma auf mehreren Rechnern laeuft, dann tut sie das auch ausserhalb der Firma. Du kannst also entweder an einen Rechner koppeln oder Dir den ganzen Aufwand sparen.

Gruss, FFNB.

 

[Tomate_Salat]

-- ich hätte noch lesen sollen, was du zitiert hast --

 

[ToterTag]

Was soll jemanden daran hindern, Software+Key im Internet zum Download an zu bieten? Wenn die Aktivierung nicht über das Internet erfolgen muss, kannst du nicht nachvollziehen, ob ein Schlüssel jetzt einmal oder tausendmal verwendet wurde. Auch, wenn du Software+Key voneinander abhängig machst, also ein Key passt nur auf eine Version der Software, du gibst jedem Kunden eine andere, interessiert das den, der die Software im Internet anbietet nicht im Geringsten.

 

[Manuela]

Hallo,

FerFemNemBem;
Klar könnten man den Aufwand auch sparen aber es geht ein wenig auf die Psychologische Schiene.

Eine Software die Erst Freigeschaltet werden muß, bietet auch einen gewisse Hemschwelle diese weiter zugeben und bei Mediziner noch eher.

!!! Wichtig !!!
Es geht weniger um die weitergabe an dritte,
sondern um kontrolle zu haben ob der Vertrieb auch Ehrlich ist.
weil die Freischaltung nur über meinen Auftraggeber geht und nicht
über den Vertrieb.

Gruß Manuela

 

[Tomate_Salat]

Mach doch eine Register-Datei. Der Kunde ruft bei euch an. Ihr erstellt daraufhin eine verschlüsselte Datei (in den Schlüssel könntet ihr sowas wie: computername, benutzername etc. einfließen lassen). Diese könntet ihr dann z.B. per Email versenden. Das ganze hätte dann noch einen gewissen Grad an kopierschutz.

 

[Guybrush Threepwood]

Mach doch eine Register-Datei. Der Kunde ruft bei euch an. Ihr erstellt daraufhin eine verschlüsselte Datei (in den Schlüssel könntet ihr sowas wie: computername, benutzername etc. einfließen lassen). Diese könntet ihr dann z.B. per Email versenden. Das ganze hätte dann noch einen gewissen Grad an kopierschutz.

Ich mache das eigentlich auch so: Es gibt eine User-ID-Datei, die direkt bei der Auslieferung (nach Bestellung) mitgeliefert wird, und die den Namen der person enthält und diesen auch prominent in der GUI anzeigt. Der Schlüssel wird bei der Installation im Programmordner abgelegt und gilt pro Maschine.

Es ist Spezialsoftware mit einigen 1000 Installationen. Bisher habe ich keine Fälle mitbekommen, wo die Software weitergegeben wurde. Es gibt dann doch eine Hemmung, wenn der Name genannt wird, zumal man bei illegalen Kopien im Netz dann dem User auf die Finger klopfen kann, der die Sachen weitergegeben hat. Die User-ID-Datei enthält den Namen, eine interne Serial des Programms und ein Ablaufdatum (für Trial-Versionen). Hieraus generiere ich einen MD5-verschlüsselten Hash und serialisiere das Objekt. Bei Start des Programms wird überprüft, ob ein gültiger Schlüssel vorliegt und dieser nicht manipuliert wurde, sowie ob der Schlüssel noch nicht abgelaufen ist.

Das ist sicher "knackbar", aber stellt meines Erachtens einen vernünftigen Kompromiss aus Sicherheit und Praktikabilität dar, sowohl für den User als auch den Auslieferer.

 

[Marcinek]

Äh moment: Wir hinterlegen den öffentlichen Schlüssel in der/jeder Software und signieren einen Zufallswert mit dem privaten Schlüssel. Klar kann man das gleiche Tupel Zufallswert/Signatur beliebig oft eingeben, aber bei den Rahmenbedingungen ist das immer möglich! (Und fällt wie wir gelernt haben spätestens beim Update auf)

Einzige Ausnahme wär es wenn man jede Software individualisiert ausliefert? @Manuela: Kannst du die Software für jeden Kunden anpassen?

Wk

Angenommen: Du machst ein Update und lieferst die ganze Software aus? - Du musst für jeden Kunden SEINE Software vorhalten...

Angenommen du stellst fest, dass das Update mehrfach mit einer Lizensierung heruntergeladen wurde... Hmm Was dann? - Welchen Kunden zeigst du an? Und vor allem warum?

Und wenn ein Kunde seine Software weiter gibt. (Siehe Terminal Umgebung) Dann braucht er sich auch nur ein Update herunterladen und puff fertig.

Die hier diskutierten Ansätze überzeugen mich nicht 100 %. Eine mittelfristige Lösung möglich..

Gerade hat noch jemand gesagt, dann hinterlegt man das verschlüsselt auf der platte.

Dann musst du das auch entschlüsseln und wo speicherst du den Key zum entschlüsseln ab?

Ich mache das eigentlich auch so: Es gibt eine User-ID-Datei, die direkt bei der Auslieferung (nach Bestellung) mitgeliefert wird, und die den Namen der person enthält und diesen auch prominent in der GUI anzeigt. Der Schlüssel wird bei der Installation im Programmordner abgelegt und gilt pro Maschine.

Es ist Spezialsoftware mit einigen 1000 Installationen. Bisher habe ich keine Fälle mitbekommen, wo die Software weitergegeben wurde. Es gibt dann doch eine Hemmung, wenn der Name genannt wird, zumal man bei illegalen Kopien im Netz dann dem User auf die Finger klopfen kann, der die Sachen weitergegeben hat. Die User-ID-Datei enthält den Namen, eine interne Serial des Programms und ein Ablaufdatum (für Trial-Versionen). Hieraus generiere ich einen MD5-verschlüsselten Hash und serialisiere das Objekt. Bei Start des Programms wird überprüft, ob ein gültiger Schlüssel vorliegt und dieser nicht manipuliert wurde, sowie ob der Schlüssel noch nicht abgelaufen ist.

Das ist sicher "knackbar", aber stellt meines Erachtens einen vernünftigen Kompromiss aus Sicherheit und Praktikabilität dar, sowohl für den User als auch den Auslieferer.

Das ist etwas, was ich mir vorstelle... Firmenkunden werden das so akzeptieren und nix weiter. Da dieses Klientel ehh vertrauenswürdiger ist vor allem beim Einsatz von Spezialsoftware.

Wenn diese Software aber nicht in einer verschlüsselten JVM liegt und damit der Quellcode verschlüsselt ist, benötige ich keine 2 Stunden um das Program im vollen Umfang (sofern es für mich interessant ist) zu nutzen und unerkannt zu distributieren. Du kannst da 10000 MD5 / AES / DES / Verschüsselungen reinhauen. Da man den Code dekompilieren kann bringt es dir nix. :applaus:

(mist steht schon da unten ^^ na egal ich lösche das jetzt nicht ;P)

 

[FerFemNemBem]

Halloechen,

wenn es einen "psychologischen" Effekt haben soll, dann halte ich die Sache mit dem Namen von Guybrush Threepwood fuer sehr sinnvoll.

Bei der von Dir genannten Clientel fuer das Programm koenntest Du dir dann sogar den ganzen Aufwand mit Hashes etc. sparen. Knackbar ist es sowieso letztendlich.

Leg einfach eine Textdatei mit dem Usernamen daneben und wenn die noch nicht da ist einen "please register" Nag-Screen.

Gruss, FFNB.

 

[ToterTag]

Nenne die Textdatei aber nicht "licensed.txt", sondern denke dir einen echt bescheuerten Namen aus. Die Datei lässt du dann natürlich auch nicht auf *.txt enden, sondern nimmst die Endung einer Datei, die man gewöhnlicherweise nicht mit dem Texteditor öffnet, und die idr. keine Textformatierung hat. Also wenn du unter Windoof (es hieß ja Software für DaUs) zu Hause bist, nimm *.exe. Damit sich keiner wundert, wieso die Datei nur 4kb (normalerweise Mindestgröße) schwer ist, und jemand Verdacht schöpft, kannst du ja noch einige MB dummy-Content rein packen.

 

[Guybrush Threepwood]

Wenn diese Software aber nicht in einer verschlüsselten JVM liegt und damit der Quellcode verschlüsselt ist, benötige ich keine 2 Stunden um das Program im vollen Umfang (sofern es für mich interessant ist) zu nutzen und unerkannt zu distributieren. Du kannst da 10000 MD5 / AES / DES / Verschüsselungen reinhauen. Da man den Code dekompilieren kann bringt es dir nix. :applaus:

(mist steht schon da unten ^^ na egal ich lösche das jetzt nicht ;P)

Das will ich sehen.
Der User hat ja schließlich nicht den Part mit der Schlüssel-Generierung, sodass er nicht weiß, wie der Hash genau gebildet wird. Ich könnte mit Dir wetten, dass Du das nicht so leicht hinkriegst. Natürlich könnte man das Programm per Reverse-Enginering rekonstruieren und den Check im Programm selbst aushebeln. Einen Schlüssel so zu manipulieren, dass er dann noch akzeptiert wird, ist aber vermutlich eine harte Nuss.

 

[kay73]

Kann es sein, dass all der technische Krempel fuer Manuela's Use Case total uninteressant ist...? :autsch: Aber ich bleib' bei diesem thread. Ist total lustig hier.

 

[Marcinek]

Das will ich sehen.
Der User hat ja schließlich nicht den Part mit der Schlüssel-Generierung, sodass er nicht weiß, wie der Hash genau gebildet wird. Ich könnte mit Dir wetten, dass Du das nicht so leicht hinkriegst. Natürlich könnte man das Programm per Reverse-Enginering rekonstruieren und den Check im Programm selbst aushebeln. Einen Schlüssel so zu manipulieren, dass er dann noch akzeptiert wird, ist aber vermutlich eine harte Nuss.

Ich bin jetzt hier kein Meisterhacker oder so ^^

Aber ich würde dann eher so vorgehen, dass die Methode, die prüft ob iwas vorhanden ist einfach entferne und stttdessen return true mache

Mir ist ja die Datei egal ^^ Will ja nur das Programm

 

[Guybrush Threepwood]

Kann es sein, dass all der technische Krempel fuer Manuela's Use Case total uninteressant ist...? Aber ich bleib' bei diesem thread. Ist total lustig hier.

Nein, denke ich nicht. Irgendwie muss man es ja realisieren und es ist ein Problem, für das es keine optimale Lösung gibt, bei der gleichzeitig Praktikabilität und Sicherheit optimal berücksichtigt werden.

 

[Guybrush Threepwood]

Ich bin jetzt hier kein Meisterhacker oder so ^^

Aber ich würde dann eher so vorgehen, dass die Methode, die prüft ob iwas vorhanden ist einfach entferne und stttdessen return true mache

Mir ist ja die Datei egal ^^ Will ja nur das Programm

Ja, da hast Du recht. So wäre der Schutz sehr schnell ausgehebelt.

 

[Marcinek]

Nein, denke ich nicht. Irgendwie muss man es ja realisieren und es ist ein Problem, für das es keine optimale Lösung gibt, bei der gleichzeitig Praktikabilität und Sicherheit optimal berücksichtigt werden.

Es gibt Hersteller für JVMs, die verschlüsselte JAR Dateien lesen können.

Für den massenvertrieb von kostenplichtiger Java Software ein muss.

componio GmbH - ByteCode-Verschlüsselung für Java-basierte Software mit der JarCryp™-Technologie