Sichere Softwarelizenzierung

Wie gut ist ein guter Softwareschutz? Was muss ich als Softwareentwickler während der Entwicklung beachten, um der Perfektion nahe zu kommen? Wie lange muss ein guter Softwareschutz halten? 
Die ägyptischen Pyramiden sind ein gutes Beispiel für einen guten Schutz. Viele unterschiedliche tödliche Fallen haben vermieden, dass ein gescheiterter Angreifer einen zweiten Versuch bekam. Natürlich hat sich die Welt weiterentwickelt und dank Röntgengeräten ist der innere Mechanismus einer Pyramide heute kein Geheimnis mehr. Dennoch war es damals eine gute Idee, sein Eigentum zu schützen und es war auch gut geschützt, zumindest für damalige Verhältnisse. Hätten die Pyramiden sonst ihre heutige Berühmtheit erlangt?

Vom Sinn des Schutzes

Analog ist es mit dem Softwareschutz heute auch. Wenn sowieso alles irgendwann irgendwie umgangen werden kann, lohnt es sich dann überhaupt, die Software zu schützen? Sind Aufwand und Kosten des Schützens dann nicht vergebene Liebesmüh‘? Dies mag vielleicht in wenigen Einzelfällen stimmen, aber im Allgemeinen bringt ein Softwareschutz mehr Gewinn als Kosten. Ehrliche Kunden können nicht aus Versehen die Lizenzbedingungen verletzen und mehr Lizenzen einsetzen als sie gekauft haben. Der Mitbewerber kann die Methoden nicht einfach kopieren und abschreiben, Sie halten Ihren Marktvorsprung. Hätten sich die ägyptischen Pharaonen auf einem einfachen Feld bestatten lassen, würde man sie heute vermutlich noch nicht einmal mehr in den Geschichtsbüchern finden. Der Schutz hat lange genug gehalten, um sie als Exponate in den Museen der Welt zu finden. Damit haben sie die gewünschte Unsterblichkeit erreicht.

Auslesen von Daten

Der einfachste Schutz ist die Abfrage „Ist die Lizenz da“. Die versehentliche Mehrnutzung wird damit zwar verhindert, aber diese einfache Abfrage bietet keinen Schutz gegen Hacker, die professionell die Software kopieren, oder die Ihre Methodik durch Reverse Engineering verstehen wollen. Oft wird dies mit dem Auslesen von Daten aus der Lizenz, z.B. freigeschaltete Module oder Ablaufdaten, kombiniert. 

Im Code führt dies zu einer Ja/Nein-Entscheidung. Mit einem Disassembler kann diese Abfrage gefunden und durch eine geeignete Sequenz, z.B. immer Ja, ersetzt werden. Alternativ spiegelt der Hacker die richtige Antwort einfach vor. Dabei spielt es keine wesentliche Rolle, ob dies in einer selbst entwickelten statisch gelinkten Bibliothek oder einem externen Kopierschutzsystem ist.

Verschlüsseln von zufälligen Daten

Möchte man mehr Schutz implementieren, so greift man auf Kryptographie zurück. Hier spielt die Strategie: „Was verschlüssele ich wann?“ eine entscheidende Rolle.

Etwas besser als Auslesen von Daten ist das Verschlüsseln von Zufallsdaten. Diese werden zu einem späteren Zeitpunkt wieder entschlüsselt und nur wenn beide Werte übereinstimmen, ist die Lizenz auch vorhanden. Aber auch dies führt zu einer einfachen Ja/Nein-Entscheidung im Code. Außerdem kann diese Art von Verschlüsselung durch eine andere Verschlüsselung, z.B. ein XOR, simuliert werden.

Benötigte Daten verschlüsseln

Besser ist das Verschlüsseln von Daten – oder sogar ausführbarem Code, welche die Software benötigt. Diese Daten werden vor der Auslieferung verschlüsselt und in der Software eingebettet. Über das Kopierschutzsystem, zum Beispiel einen Dongle, wird die Sequenz entschlüsselt und kann dann verwendet werden. Fehlt die passende Lizenz, dann fehlt der passende Schlüssel und die Daten können weder entschlüsselt noch verwendet werden.

Versucht ein Hacker dies zu umgehen, kann er zwar die Abfrage ändern, sodass der Vergleich einer Checksumme immer „Ja“ liefert, aber die Software rechnet dann falsch oder stürzt einfach ab. Ein Hacken ohne die passende Lizenz ist dann nahezu unmöglich. Der Hacker müsste die verschlüsselten Daten erraten können.

Leider hat dieses Verfahren einen großen Nachteil. Durch ein Abhören und wieder Abspielen der Übertragung zwischen Software und Kopierschutz kann dieser Art von Schutz umgangen werden. Hier hilft nur die Integration von vielen verschlüsselten Geheimnissen an vielen verschiedenen Stellen.

Mehr als einen Schlüssel

Eine Verbesserung der Verschlüsselung von benötigten Daten bietet speziell CodeMeter. Bei CodeMeter können Sie mehr als nur einem Schlüssel verwenden. D.h. die gleichen Daten können mehrmals in der Software mit unterschiedlichen Schlüsseln verschlüsselt eingebettet werden. Zur Laufzeit wählen Sie dann einen Schlüssel zufällig aus und verwenden diesen. Dies erhöht den Aufwand für das Aufzeichnen aller Anfragen drastisch.

Auch das Hacken bei vorhandener Lizenz wird somit extrem aufwändig und damit teuer. Als weitere Verbesserung wählen Sie die zufällige Auswahl nicht zufällig, sondern machen diese abhängig von Datum und Rechnerdaten. Der Hacker glaubt einen zu haben, der aber beim „Kunden“ oder zu einem späteren Zeitpunkt nicht mehr funktioniert.

Challenge Response

Neben der Verschlüsselung mittels AES bietet CodeMeter auch die Option, Signaturen zu erzeugen. Sie erzeugen eine Zufallszahl, die Challenge, und lassen diese vom CmDongle signieren und erhalten die Response. Der entsprechende private Signaturschlüssel ist sicher in einem Secret oder Hidden Data Feld im CmDongle gespeichert.

In der Software überprüfen Sie die Signatur mittels des passenden öffentlichen Schlüssels, den Sie in Ihre Software eingebettet haben. Dieser dient nur zur Überprüfung. Selbst wenn der Hacker diesen aus der Software extrahiert, kann er damit keine gültige Signatur durchführen.

Challenge Response führt zu einer Ja/Nein-Entscheidung in der Software, kann aber nicht mittels XOR simuliert werden. Im Gegensatz zu Verschlüsselung mit AES ist eine Signatur deutlich langsamer. Bei einer benötigten Zeit von ca. 300 ms sollte man diesen Mechanismus dosiert einsetzen.

Integritätsschutz

Neben der Simulation des Kopierschutzes durch den Hacker ist der zweite Angriffspunkt das Verändern der geschützten Anwendung. Hierbei wird Code in der Anwendung modifiziert, zum Beispiel aus einem JNZ ein JZ gemacht („Springe wenn nicht null“ zu „Springe wenn null“).
Um dies zu Verhindern, sollte sich Ihre Software selbst überwachen und Modifikationen erkennen. Dies erzielen Sie durch Checksummen und Hashwerte, die Sie über einzelne Bereiche in Ihrer Software bilden und diese zur Laufzeit überprüfen. Auch hier gilt: „Viel hilft viel“ und „Viel verschachteln“. Noch besser ist die Verwendung von Checksummen als Sprungadressen. Eine manuelle Integration ist jedoch sehr aufwändig und fehleranfällig

Fallen zerstören die Lizenz

Was war der beste Schutz der Pyramiden? Die tödlichen Fallen. Mit CodeMeter bieten wir Ihnen das moderne Gegenstück dazu. Erkennen Sie eine Manipulation, zum Beispiel ein unpassender Hashwert, so schicken Sie eine Sperrsequenz an den CmDongle. Dieser erkennt dies und sperrt daraufhin alle von Ihnen erzeugten Lizenzen. Eine weitere Verwendung ist somit ausgeschlossen. Alle noch nicht entschlüsselten Daten werden auf immer unerreichbar für den Angreifer sein.

Natürlich können Sie die Lizenz wieder reanimieren. Dies können auch Remote über eine Remote-Update-Datei durchführen. Die Lizenzen sind also nicht endgültig vernichtet, sondern liegen unter Ihrer Kontrolle. Die Remote-Update-Datei kann übrigens nur in den einen dafür vorgesehenen CmDongle übertragen und auch nur einmal eingesetzt werden. Tappt der Angreifer in die nächste Falle, beginnt das Spiel von vorne.

Zusammenfassung

CodeMeter bietet ein umfassendes, patentiertes Framework für einen State-of-The-Art Softwareschutz. Bei einer guten und tiefen Integration in Ihre Software wird der Schutz vielleicht nicht mehrere tausend Jahre halten wie die Pyramiden, aber einige tausend Tage sollten es schon sein.
Damit Sie die Integration nicht mit Hammer und Faustkeil durchführen müssen, bietet Ihnen Wibu-Systems den AxProtector und vor allem den IxProtector. Mit dem AxProtector wird Ihre komplette Software verschlüsselt. Dabei verwendet der AxProtector verschiedene Schlüssel und implementiert Fallen zum Sperren der Lizenz. Durch den IxProtector werden einzelnen Teile Ihrer Anwendung zu einer späteren Zeit entschlüsselt. Somit ersparen Sie sich die Frage, was Sie verschlüsseln sollen, nehmen Sie mittels IxProtector einfach den ausführbaren Code. Ohne den kann die Software nicht fehlerfrei funktionieren.

Der Hacker muss dann die komplette Software benutzen, wenn er an alle Geheimnisse kommen möchte. Und je länger und intensiver er sie benutzen und analysieren muss, in umso mehr Fallen wird er fallen.

Einige in der letzten Zeit vereinzelt aufgetauchte Hacks zeigen, dass eine gute Integration für den Schutz immens wichtig ist. Alle analysierten gehackten Versionen waren nicht mit dem IxProtector geschützt oder hatten nur einfache Abfragen in der Software. Für einen guten Schutz empfehlen wir den AxProtector und IxProtector. Schalten Sie möglichst viele Anti-Debug-Features im AxProtector ein. Gerne unterstützt Sie unser Professional Services Team auch bei einer individuellen Integration in Ihrer Software. 

 

KEYnote 22 – Herbstausgabe 2011