Laufzeitumgebung für CodeMeter Protection Suite

Eine neue, native Komponente ermöglicht die Umsetzung weiterer Schutzmechanismen, die Ihre Software noch besser schützen. Warum das eine gute Idee ist und wie die sichere Anbindung dieser Komponente an Ihre geschützte Applikation funktioniert, erklären wir in diesem Artikel.

In der Entwicklung von Software ist die Technologie einem stetigen Wandel unterzogen. Was heute hip ist, kann morgen schon wieder Schnee von gestern sein. Manch einer hat hier schon auf das falsche Pferd gesetzt und musste seine Applikation nach einiger Zeit noch einmal in einer anderen Programmiersprache oder einer anderen Technologie neu schreiben, um selbst vom weiteren Fortschritt profitieren zu können. Die CodeMeter Protection Suite wird immer wieder erweitert, um auch für neue Technologien einen sehr guten Schutz anbieten zu können. Derzeit befindet sich beispielsweise der AxProtector Python in der Betaphase. Python-Skripte erfreuen sich einer großen Beliebtheit und werden vielfach als kleine Helferlein im Alltag einer Softwareentwicklung eingesetzt. Wenn daraus aber etwas Größeres erwächst, ergibt sich bald der Wunsch, die Ergebnisse der Arbeit zu schützen und zu lizenzieren.

Skriptsprachen schützen?

Python ist eine Skriptsprache und liegt daher im Quellcode vor. Wie will man sowas schützen? Eine Möglichkeit ist, den Quellcode mit entsprechenden Tools in nativen Code zu übersetzen und die erhaltene Binärdatei dann mit AxProtector zu verschlüsseln. Das funktioniert in vielen Anwendungsfällen gut. Als Softwarehersteller müssen Sie aber für verschiedene Plattformen unterschiedliche Binärdateien zur Verfügung stellen, damit Ihr Kunde das Programm dort einsetzen kann, wo er möchte.

Und Sie müssen sich darauf verlassen, dass das Konvertierungstool keine Fehler hat und Ihren Code korrekt und auch performant in nativen Code übersetzt. Möglicherweise ist durch die Wandlung in ein Programm aber auch mancher Einsatzzweck nicht oder nicht mehr so einfach zu erreichen – wie zum Beispiel die Verwendung von geschützten Funktionen in anderen Python-Skripten, die Ihre Kunden geschrieben haben.

Es war also an der Zeit, eine Lösung zu finden, um ohne Tools anderer Hersteller Skriptsprachen wie Python zu schützen. Die wesentliche Herausforderung dabei war, die Prüfung der Lizenzen und die Entschlüsselung in einem nicht manipulierbaren Umfeld durchzuführen – und das geht nicht in Skripten, die als Quellcode bei Ihrem Kunden vorliegen. Die Lösung dafür ist die Verwendung einer von Wibu-Systems bereitgestellten nativen Komponente, in der diese Operationen geschützt vor neugierigen Blicken ablaufen. Diese native Komponente ist die neue CodeMeter Protection Suite Laufzeitkomponente CPSRT (CodeMeter Protection Suite Runtime).

Native Bibliothek

In einem zu schützenden Skript werden die Inhalte der Funktionen verschlüsselt. Zusätzlich wird Code eingefügt, der zur Laufzeit den verschlüsselten Code an die native Komponente übergibt. In der nativen Komponente werden dann die gewünschten Lizenzen belegt, die Funktionen entschlüsselt, zurück übermittelt, in den Interpreter geladen und direkt ausgeführt. Die native Komponente kann noch weitere Aufgaben wahrnehmen, die ein Angreifer in der Skriptsprache einfach aus dem Quellcode entfernen könnte, wie zum Beispiel die regelmäßige Lizenzprüfung oder eine Debugger-Erkennung. Und damit ein Angreifer keine Änderungen an der nativen Komponente vornimmt, ist diese selbst mit AxProtector-Technologie geschützt.

Genauso wichtig wie die Härtung der nativen Komponente ist die Absicherung der Kommunikation zwischen geschützter Anwendung und nativer Komponente. Das wäre ein optimaler Angriffspunkt: Wenn man hier einfach die Kommunikation abhören könnte, hätte man alles, was man braucht. Und wenn man sich nach bester Man-in-the-Middle-Manier dazwischen hängen würde, könnte man sogar noch die Aufrufe abändern. Daher haben das Entwicklungsteam und die Sicherheitsexperten von Wibu-Systems zusammen ein Verfahren zur sicheren Kommunikation entwickelt.

Verschlüsselt kommunizieren

Beim Laden der nativen Komponente wird eine verschlüsselte Kommunikation aufgesetzt. Diese basiert auf Zertifikaten, die für die verschlüsselte Applikation ausgestellt werden. Diese Zertifikate (Copy-Protection-Key-Zertifikat und Protectee-Zertifikat) sind Teil einer Signaturkette, die sich über das von uns für Sie als Softwarehersteller ausgestellte Zertifikat (Licensor-Private-Key-Zertifikat) bis hin zum Wibu-Systems Root-Zertifikat erstreckt.

Mit Hilfe des Protectee-Zertifikats kann sich die geschützte Applikation gegenüber der nativen Komponente ausweisen und damit nachweisen, dass sie berechtigt ist, Lizenzzugriffe zu beauftragen und Funktionen entschlüsseln zu lassen. In der anderen Richtung kann die native Komponente, die mit einem Zertifikat von Wibu-Systems unterzeichnet ist, sich als authentische Komponente gegenüber der Applikation ausweisen. Auf Basis des damit geschaffenen Vertrauens kann dann ein Schlüssel zur Kommunikation ausgehandelt werden, der Außenstehenden nicht bekannt ist.

Außerdem wird die native Komponente Anfragen, zum Beispiel für eine Entschlüsselung, nur für solche Firm Codes ausführen, für welche die verschlüsselte Applikation die passenden Zertifikate vorlegen kann. Zusätzlich kann über die Zertifikate von der nativen Komponente auch die Integrität der verschlüsselten Applikation geprüft werden, so dass eine manipulierte Applikation gleich beim Start ausgebremst wird.

Zertifikate

Die angesprochene Zertifikatskette basiert auf der Zertifikatsinfrastruktur, die für den Universal Firm Code (Firm Code > 6.000.000) eingeführt wurde. Aber auch, wenn Sie als Softwarehersteller CodeMeter Firm Codes aus der Zeit davor oder sogar den Vorgänger WibuKey nutzen, können Sie die neue native Komponente mit derselben Zertifikatsinfrastruktur verwenden. In diesem Fall müssen die Zertifikate noch in Ihre Firm Security Box (FSB) ausgerollt werden – entweder für alle CodeMeter Firm Codes automatisch beim nächsten Update (zum Beispiel von Transaktionen) oder jederzeit auch separat und kostenfrei. Falls in Ihrer FSB ein solches Zertifikat fehlt, wird Ihnen beim Verschlüsseln eines Programms eine ausführliche Meldung angezeigt, die auch erklärt, an wen Sie sich wenden können.

Aktuell wird die native Komponente von AxProtector .NET sowie AxProtector Python verwendet. In naher Zukunft werden weitere AxProtector-Varianten folgen und ebenfalls zusätzlich zu den bisherigen Mechanismen auf die Möglichkeiten der nativen Komponente zurückgreifen und damit den Schutz Ihrer Software weiter erhöhen.

Notwendige Installation

Die native Komponente muss zur Laufzeit beim Anwender verfügbar sein. Beim AxProtector .NET wird sie beim Verschlüsseln in den protected-Ordner kopiert, in dem sich neben dem verschlüsselten Assembly alle notwendigen Dateien finden. Da bei .NET nicht von vorneherein klar ist, auf welcher Plattform später das Assembly ausgeführt wird, muss die native Komponente für verschiedene Plattformen mitgeliefert werden. Die native Komponente wird als CPSRT.dll daher in verschiedenen Unterordnern für die verschiedenen Plattformen bereitgestellt. Mit der Version 10.70a wurde der Mechanismus erweitert, mit dem ein mit AxProtector .NET geschütztes Assembly nach der CPSRT.dll sucht: Es wird zunächst im Verzeichnis der Applikation gesucht (sowohl im Verzeichnisbaum als auch direkt im Verzeichnis), danach zusätzlich an allen Orten, die über die PATH-Variable in der Umgebungsvariable definiert sind (ebenfalls sowohl im Verzeichnisbaum als auch direkt im Verzeichnis).

Ab der kommenden Version CodeMeter 7.30 wird die CPSRT.dll von den jeweiligen CodeMeter-Installationsprogrammen mitgeliefert und in der aktuellsten Version installiert. In Zukunft brauchen Sie die native Komponente daher nicht mehr selbst mit zu verteilen. Wibu-Systems stellt wie immer die Kompatibilität mit älteren Versionen sicher, so dass ein einmal mit CodeMeter Protection Suite geschütztes Programm auch mit zukünftigen Versionen der CPSRT.dll einwandfrei läuft.

 

KEYnote 41 – Frühjahrsausgabe 2021