Wieviel Sicherheit benötigt meine Anwendung?

Alles was die CPU ausführt, kann ein Angreifer auch beobachten. Er kann damit entsprechende Sicherheitsmechanismen verstehen und auch entfernen.“ Diese Aussage ist prinzipiell korrekt, doch wie können Sie als Softwarehersteller auf diese Erkenntnis reagieren?

Hier haben Sie drei Strategien:

• Sie sagen sich „Es bringt ja sowieso alles nichts“ und verwenden keinen Kopierschutz und keine Lizenzierung.
• Der Angreifer kann zwar alles verstehen, aber Sie verwenden CodeMeter in einer Art und Weise, dass der Aufwand für den Angreifer nahezu so hoch wäre, als würde er Ihre Software komplett neu schreiben.
• Sie lagern essentielle Codes in den CmDongle aus und führen diesen Code im CmDongle aus. Damit ist er für den Angreifer nicht mehr beobachtbar. 

Kein Kopierschutz

Die erste und mit Sicherheit schlechteste Alternative ist es, auf den Kopierschutz und die Lizenzierung ganz zu verzichten. Auch der Mythos „Microsoft ist durch Raubkopien groß geworden“ ist kein Freibrief für den Verzicht. Einer der wesentlichen Punkte für den Erfolg von Microsoft liegt in der Bündelung des Betriebssystems mit neu ausgelieferten Computern (IBM). Auch die Marktsituation mag dabei eine Rolle gespielt haben. Hatten doch zu diesem Zeitpunkt alle anderen Betriebssysteme den Ruf, schwer verständlich und umständlich bedienbar zu sein. So kamen zuerst die Verbreitung und Beliebtheit, und dann die Raubkopien. Über die Jahre haben sich die Sicherheitsmechanismen permanent verbessert. Online-Aktivierung mit Echtheits-Check und Speichern der Seriennummer im BIOS sind nur ein paar Beispiele dafür.

Gerade für kleine und mittlere Unternehmen kann die „Ich mache gar nichts“-Strategie sogar existenzbedrohend werden. Umfragen und Studien zeigen, dass die größten Verluste durch Raubkopien vor allem durch Unkenntnis der Lizenzbedingungen und unbeabsichtigtem Lizenzmissbrauch entstehen. Dies trifft vor allem auf Business-Software in Zentraleuropa und Nordamerika zu, die gewerblich genutzt wird. Bei der Vielfalt an Lizenzmodellen ist es auch kaum verwunderlich, dass Administratoren den Überblick verlieren und glauben, noch hinreichend Lizenzen zu besitzen, während diese alle bereits in Benutzung sind. In diesen Fällen würden einfache technische Maßnahmen bereits ausreichen, um diese eingesetzte Software zu monetarisieren.

Die Hacker-Pyramide

Betrachtet man die Hacker-Szene, kann man die Mitglieder in vier Gruppen einteilen: Skript-Kiddies, Hobby-Hacker, Profi-Hacker und Top-Hacker. Während Skript-Kiddies vor allem in der Lage sind, Google zu bedienen und damit Anleitungen zum Hacken und fertige Hacks herunterzuladen, verdienen Profi-Hacker und Top-Hacker mit der Bereitstellung von Cracks ihr Geld. Gerade diese Mitglieder denken profitorientiert. Welchen Crack kann ich am häufigsten so teuer wie möglich verkaufen und wo habe ich den geringsten Aufwand? Dies ist so wie die Geschichte mit den beiden Freunden und dem Bären. Beide werden von einem Bären überrascht und fliehen barfuß. Einer der beiden Freunde bleibt stehen und holt die Turnschuhe aus dem Rucksack. Da meint der andere: „Auch mit den Turnschuhen bist Du nicht schneller als der Bär.“ Darauf entgegnet der Mann mit den Turnschuhen: „Das muss ich auch nicht. Ich muss nur schneller sein als Du.“

Genauso ist es mit dem Softwareschutz. Er muss nicht perfekt sein, er muss dem Wert und der Begehrtheit der Software angemessen sein und etwas über dem Standard liegen. Er sollte so gut sein, dass es nur schwer möglich ist, Anleitungen und fertige Baukästen für Skript-Kiddies zu erstellen. Mit CodeMeter ist dies bereits durch den Einsatz von AxProtector erfüllt.

Viel hilft (wirklich) viel

Die zweite Strategie ist es, die Hürde für den Hacker so hoch wie möglich zu legen. Hacks sollten nicht automatisierbar sein und aus dem Wissen eines Cracks sollte es keine oder nur unwesentliche Vorteile für den nächsten Crack geben.

Hier kommt Ihnen als Softwarehersteller die Komplexität Ihrer eigenen Software zu Gute. Der Hacker kann zwar alles analysieren, was über die CPU ausgeführt wird, aber dazu muss es auch erst einmal ausgeführt werden. Bei einer üblichen Businessanwendung setzen Anwender nur 10 bis 20 Prozent der angebotenen Funktionen ein. Es wird also nur ein Bruchteil des Codes wirklich ausgeführt. Dies erschwert dem Hacker das Beobachten, denn er muss sich eine Strategie einfallen lassen, wie er den kompletten Code einmal ausführt. Wer diese Quadratur des Kreises lösen könnte, wäre der König der Testtools und müsste sein Geld nicht mehr damit verdienen, anderer Leute Software zu cracken.

Eine Voraussetzung dafür ist, dass der Kopierschutz und die Lizenzierung dort im Code erfolgt, wo er benötigt wird. Die oft gebräuchliche Strategie der Erstellung einer Lizenz-Wrapper-Klasse und des Aufrufs dieser Klasse an vielen Stellen ist hier kontraproduktiv. Der Hacker muss lediglich den Code dieser Lizenz-Wrapper-Klasse analysieren, verstehen und austauschen. Auch das Verschlüsseln dieser Klasse durch den AxProtector behebt diese Schwachstelle nicht und bietet eher ein falsches Gefühl von Sicherheit. Die bessere Lösung ist es hier, mit AxProtector .NET und IxProtector möglichst viele Funktionen im Code zu verschlüsseln. Denn dann muss der Hacker die Software wirklich komplett ausführen. Gegen automatische Analysen können Fallen eingestreut werden, die den CmDongle bzw. auch die CmActLicense im Falle eines Angriffes sperren. Mehr Details zu dieser Art der Integration finden Sie im vorherigen KEYnote Magazin 34.

CodeMoving

Die ultimative Sicherheit bietet die dritte Strategie: die Auslagerung von Code in den CmDongle und die Ausführung im CmDongle selbst. Damit ist eine Beobachtung durch den Hacker komplett unmöglich.

Die Möglichkeit, Code in den CmDongle zu verschieben, steht für CmDongles mit Seriennummer 3-xxxxxx und Firmware 4.03 zur Verfügung. Aktuell ist die Auslagerung von Code, der in C geschrieben ist, möglich. Die Unterstützung von Java- und .NET-Code ist bereits in Planung. Ein wichtiger Punkt beim Verschieben von Code ist die Auswahl des richtigen Codes. Ist er zu trivial, kann er anhand der Ergebnisse erraten werden. Ist er zu komplex, verlangsamt die Auslagerung des Codes den Ablauf oder die Menge des auslagerbaren Codes von 3 kByte wird überschritten. CodeMoving sollte nur mit Einzelplatz-Dongles eingesetzt werden.

Der auszulagernde Code wird in einer separaten C-Datei geschrieben. Der komplette Code der Datei inklusive aller Unterfunktionen wird dabei verschoben. Die C-Datei umfasst als Mindestangabe eine Eingabestruktur, eine Ausgabestruktur und eine Entry-Funktion, die diese Strukturen verwendet. Über die Eingabestruktur werden Daten an den CmDongle übergeben. Über die Ausgabestruktur werden Daten nach der Berechnung im CmDongle an die Anwendung zurückgegeben. Die Entry-Funktion ist die Funktion, die im CmDongle ausgeführt wird.

Das Beste dabei ist: Sie können beliebig viele Codefragmente erzeugen, die im CmDongle ausgeführt werden. Um den Code zu verschieben, wird die Anwendung mit AxProtector verschlüsselt. Alle zu verschiebenden Funktionen werden dabei vom AxProtector kompiliert und verschlüsselt in der Anwendung abgelegt. Zur Laufzeit wird der verschlüsselte Block an den CmDongle übertragen, dort im CmDongle entschlüsselt und mit den Eingabeparametern ausgeführt. Die Ausgabeparameter werden dann an die Anwendung zurückgeliefert.

Im CmDongle stehen einige Hilfsfunktionen zur Verfügung. So können Sie kryptographische Funktionen wie AES und SHA direkt verwenden. Zusätzlich können Daten temporär gespeichert und beim Aufruf der nächsten Funktion wiederverwendet werden. Auch der Zugriff auf Hidden Data ist möglich. Aus Sicherheitsgründen ist der Zugriff auf Hidden Data nur innerhalb des Product Items möglich, mit dem das Codefragment verschlüsselt wurde.

Skalierbare Sicherheit

Mit CodeMeter können Sie selber bestimmen, wie viel Sicherheit Ihre Anwendung benötigt. Von einfachen Lizenzabfragen, um unbeabsichtigten Lizenzmissbrauch zu verhindern, bis zur Ausführung von Code im CmDongle: CodeMeter passt sich an Ihre Anforderungen an.

 

KEYnote 35 – Frühjahrsausgabe 2018