Zitat von
Phoenix:
Niemand. Der Key muss bei jedem Programmstart neu erstellt werden. Die Basis für die Berechnung (z.B. der Seed für die Zufallszahlen) ist z.B. dann die SID des Rechners. Somit gibt es keinen irgendwo hinterlegten Key, der ausgetauscht werden könnte.
Dann brauche ich also nur den Algorithmus knacken und bin aus dem Schneider?!
Zitat von
Phoenix:
Hrm. Gute Frage. z.B. Wenn die Software die die Aktivierung vornimmt dass empfangene Assembly entschlüsseln und laden kann und dies dem System meldet. Dann kann zwar theoretisch diese Meldung abgefangen werden, aber da der public Key schon beim Webservice zu der Aktivierungsnummer hinterlegt ist kann man dann nur noch das mit diesem Key verschlüsselte Assembly mehrfach herunterladen. Das hilft auf einem anderen Rechner dann schon nicht mehr.
Korrekt, aber sobald ich die Assembly einmal habe, brauche ich sie nur entschlüsseln (mußt du ja machen) und dann unverschlüsselt ablegen. Da deine unverschlüsselte Assembly natürlich eine verschlüsselte Assembly erwartet, muß ich nur noch die unverschlüsselte mit dem vom zuvor geknackten Algo erlangten Schlüssel neu verschlüsseln. Voila, ich habe ein lauffähiges Programm auf einem anderen Rechner.
Zitat von
Phoenix:
Wie oben schon gesagt: Nirgends, damit niemand den Key austauschen kann
Wozu dann überhaupt die Trennung nach privatem und öffentlichem Schlüssel? Weil der öffentliche übertragen wird?
Zitat von
Phoenix:
Deswegen ist es aber auch wichtig, eine Möglichkeit zu finden die Berechnung des Schlüssels von der aktuellen Hardware abhängig zu machen. Ginge da was mit diesen TPM-Chips?
Im Prinzip ja ...
Zitat von
Phoenix:
Inwiefern? Wenn sich die Anwendung nicht mehr starten lässt wenn sie modifiziert wurde ist das Ziel doch erreicht. In die Schlüsselgenerierung und das Entschlüsseln der/des Assemblys mit der teuren Funktionalität kann nicht eingegriffen werden. Somit ist das unterjubeln von prä-Entschlüsselten Assemblys auch nicht möglich.
Statische Analyse! Ich brauche doch deinen Code nicht laufenlassen. Stattdessen analysiere ich ihn und schreibe mir etwas gleichwertiges.
Zitat von
Phoenix:
Das ist ne andere Sache. Was, wenn ich das System nicht für eigene Software haben will sondern z.b. als Kopierschutzsystem vermarkten will?
Dann hast du ein Problem, weil dann die Zielgruppe größer und damit dein "Schutz" attraktiver für Cracker wird.
Zitat von
Phoenix:
Oder es einfach - so es denn relativ sicher ist - einfach so für andere zur Verfügung stelle. Vielleicht will ich aber damit auch nur sicherstellen, dass die 1000 Leute meine 10€ - Shareware auch wirklich kaufen und nicht einfach nen Key runterladen.
Dann sind die 1000 Leute einfach nur verblödet. 10 EUR kann sich notfalls sogar der Hartz-IVler leisten. Deswegen ja dieser Ansatz: bei moderaten Preisen ist der Aufwand größer einen Kopierschutz zu implementieren und zu warten als das Produkt eigentlich wert ist (also für den einzelnen Käufer). Abgesehen davon kannst du doch sehr gut mit der Moralschiene punkten, denke ich. Wenn du den Käufern erklärst, daß sie Arbeitsplätze vernichten wenn sie das Programm raubkopieren ... allerdings lasse ich mir als ehrlicher Käufer auch nicht gern Antiraubkopierer-Spots bei DVDs aufdrücken. Kann also auch den gegenteiligen Effekt haben, je nachdem wie man es angeht.
Achja, das Programm zu personalisieren (also so wie du das Modell erklärt hast - die Schwächen ignoriert!) dürfte einen abschreckenden Effekt haben, weil du dann ja theoretisch zurückverfolgen könntest, auf wen die Kopie zurückgeht. Bei einem geklauten Laptop hilft die Zurückverfolgung allerdings auch nicht mehr viel ...
Alternativ nutzt den Placebo-Effekt, daß du einfach behauptest einen tollen Schutz mit Wasserzeichen (oder irgendeinem anderen PR-Schlagwort) eingebaut zu haben, wodurch du illegale Kopien zurückverfolgen könntest. Dadurch wird die moralische Schranke wieder höhergelegt.
Zitat von
Phoenix:
Deswegen möchte ich das mal durchspielen und mögliche Angriffspunkte aufdecken. Will heissen: Ob es sich überhaupt lohnt und die theoretische Möglichkeit bietet ein System zu entwickeln, dass einen erheblichen und am besten pro Installation individuellen Knackaufwand bieten würde.
IMO verlagerst du nur das Problem, behebst es aber nicht. Solange du dem Anwender vertrauen mußt (und das tust du, weil er ja den privaten Schlüssel hat - ob nun explizit oder implizit ist irrelevant), bist du gea....t, weil du ihm ja nicht vertraust, weshalb du Schutzmaßnahmen entwirfst, diese Schutzmaßnahmen aber bereits eine Trust Relationship beinhalten (intrinsisch). Da gibt es auch nichts zu deuteln. Solange du nicht die Kommunikation vom Benutzer wegsperren kannst (bspw. mit TPM) wird es da auch keine wirklich sichere Alernative geben.
Wie du anfänglich sagtest, man kann die Hürden erhöhen, aber
wirklich sicherer wird's davon nicht ...
Zitat von
dino:
bau mal ein Notebook, welche keine wechsellafwercke hat und in de Luft fliegt, wenn man versucht ans innere zu kommen...
Dann übertrage ich meine Dateien wahlweise über USB, Firewire,
COM, LPT oder eben stinknormales Netzwerk (RJ-45).
Zitat von
dino:
mit der Idee ein kleines Mp3 Stick zu bauen, welches man nur ausführen kann, wenn man ein Programm hat, welches es lesen kann, wobei der mp3Stick ne art dos hat, an das man nicht drankommt und welches sich ohne irgend ein windows startet und das Programm ausführt brauch ich ja auch nicht zu kommen, da das an der Aufgabenstellung vorbei geht.
Interessante Theorien. Wie willst du nun verhindern, daß jemand dein DOS reverst und das von dir bspw. proprietär entwickelte Dateisystem ausliest und die ganz Geschichte in einem Emulator laufen läßt?