Einsatz von Verschlüsselung für den Softwareschutz

Anbieter zum Thema

Linutronix GmbH

Parasoft® Deutschland GmbH

RTI Real-Time Innovations

WIBU-SYSTEMS AG

Software wird in Embedded-Systemen zunehmend essentiell für die Sicherung des eigenen Wettbewerbsvorteils. Der effiziente Einsatz von Verschlüsselung stellt sicher, dass dieser Wert auch gewahrt bleibt.

Der Anteil der Software am Wert eines Embedded-Gerätes hat in den letzten Jahren stark zugenommen. Günstige und leistungsfähige Standardgeräte machen die Entwicklung eigener Hardwaredesigns eher zu einem Nischengeschäft. Diese Entwicklung hat zur Folge, dass sich immer mehr Hersteller von Geräten über die Themen Softwareschutz und Lizenzierung Gedanken machen. Oft auch mit den Hintergedanken, Features nachträglich freischalten zu können oder über Abonnements wiederkehrende Einkünfte zu erzielen. In vielen Fällen wird eine schlüsselfertige Lösung eingesetzt. Dabei steht der Entwickler vor der Frage: Wie integriert man eine Schutzlösung, so dass diese nicht oder nur schwer umgangen werden kann?

Wichtig ist hier der Einsatz von Verschlüsselung. Prinzipiell gibt es mehrere Strategien, zum Beispiel:

• Das Verschlüsseln von ausführbarem Code;

• das Verschlüsseln von Daten; oder

• das Reagieren auf Ergebnisse kryptographischer Funktionsaufrufe.

Für ein hohes Schutzlevel können verschiedene Strategien miteinander kombiniert werden. Falls Geräte mit Arbeitsplatz-Computern zusammenspielen, kann auch die Kommunikation zwischen Gerät und PC verschlüsselt werden.

Verschlüsseln von ausführbarem Code en bloc

Das Verschlüsseln von ausführbarem Code ist vor allem dann eine gute Option, wenn die eigentliche Anwendung auf einem Medium wie zum Beispiel einer SD-Karte liegt und in den Hauptspeicher geladen wird.

Werkzeuge des Herstellers der Softwareschutzlösung verschlüsseln die komplette Anwendung. In der Regel wird ein Start-Code an die so geschützte Anwendung angehängt. Nach dem Laden der Anwendung in den Hauptspeicher wird anstelle der eigentlichen Anwendung zuerst der Start-Code ausgeführt. Dieser prüft, ob eine Lizenz für die Anwendung vorhanden ist und verwendet einen Schlüssel in der Lizenz, um die Anwendung zu entschlüsseln. Nach dem Entschlüsseln wird dann der eigentliche Code der Anwendung aufgerufen. Durch die Trennung von Schlüssel (in der Lizenz) und Anwendung wird ein hoher Schutzlevel erreicht (siehe Bild 1). Ein Angreifer ohne passende Lizenz kann die Anwendung nicht entschlüsseln.

Alternativ zum Anhängen des Start-Codes an jede geschützte Anwendung kann dieser auch bereits in das Betriebssystem des Gerätes integriert werden (vgl. Bild 2). Diese Technologie ist zum Beispiel für VxWorks von Wind River verfügbar. Der Gerätehersteller kann in diesem Fall zusätzlich zum Schutz gegen Raubkopien auch noch das Starten von Malware verhindern, da nur korrekt verschlüsselte und vor allem signierte Anwendungen gestartet werden können. Der Hersteller unterschreibt in diesem Fall die Anwendung mit seinem privaten Schlüssel. Der öffentliche Schlüssel befindet sich im Start-Code. Dass alle Anwendungen vom Start-Code geladen werden, kann nun mit dem öffentlichen Schlüssel geprüft werden, ebenfalls ob die Anwendungen vom Hersteller herausgegeben wurden und auf den Weg ins Gerät nicht manipuliert wurden.

Die hohe Kunst der Code-Verschlüsselung

Die soeben beschriebenen Methoden laden eine Anwendung komplett in den Speicher und entschlüsseln sie. Das hat den Vorteil, dass die Anwendung nach dem Start mit der gleichen Geschwindigkeit läuft, wie sie ohne Schutzmaßnahmen laufen würde. Allerdings könnte ein Angreifer versuchen, ein Abbild des Hauptspeichers zu erzeugen und dieses zu analysieren. Aus einem solchen Abbild eine lauffähige Anwendung zu erzeugen ist nicht einfach, allerdings mit entsprechenden Kenntnissen durchaus möglich. Anbieter von Softwareschutzlösungen bieten daher verschiedene Gegenmaßnahmen an.

Die erste Gegenmaßnahme ist das automatische Einfügen von „kleinen Schweinereien“. Dabei wird der ausführbare Code so modifiziert, dass automatische Tools für die Rekonstruktion einer Anwendung aus einem Speicherabbild versagen. Für den Angreifer ist Handarbeit angesagt. Das Hauptaugenmerk liegt dabei meist auf Windows-Anwendungen, da es hier mehrere einfach zu bedienende, automatische Tools gibt. Für den Gerätehersteller birgt diese Art der Gegenmaßnahmen ein gewisses Risiko. Der Anbieter der Schutzlösung gibt in der Regel keine Details über diese Maßnahmen preis, so dass eine Abschätzung der Sicherheit und des Einflusses auf die Performance nur schwer möglich ist. Diese Maßnahmen werden in der Regel für Windows-Anwendungen auf PCs verwendet.

Eine bessere Gegenmaßnahme ist die Zerteilung der Anwendung in kleine funktionale Teile und das dynamische Entschlüsseln dieser Teile zur Laufzeit. Diese Teile werden nicht beim Starten der Anwendung entschlüsselt, sondern bleiben verschlüsselt im Hauptspeicher. Bei CodeMeter kann der Gerätehersteller zum Beispiel entscheiden, ob er die Entschlüsselung eines Fragmentes per API selber anstößt, oder ob dies automatisch beim Aufruf erfolgt. Im ersten Fall kann der Entwickler die Performance komplett selbst bestimmen. Die automatische Entschlüsselung hat den Vorteil der einfachen und schnellen Integration in die Anwendung.

Eine dritte Möglichkeit ist das Auslagern und Ausführen von Code in einer separaten Hardware. Dieser Code kann dann weder gesehen noch seine Ausführung beobachtet werden. Eine Mischung aus den letzten beiden Möglichkeiten setzt Wibu-Systems in der Blurry-Box-Technologie ein, die den deutschen IT-Sicherheitspreis 2014 gewonnen hat, ein.

Verschlüsselte Daten anstelle von verschlüsseltem Code

Falls die Verschlüsselung von Code nicht möglich ist oder wenn der Schutzlevel weiter erhöht werden soll, dann hat der Gerätehersteller die Möglichkeit, Daten zu verschlüsseln. Auch hier sollte ein Schlüssel verwendet werden, der sich in der Lizenz und damit außerhalb der Anwendung befindet.

Eine Strategie ist es, benötigte Daten verschlüsselt in der Anwendung zu hinterlegen. Betrachten wir dazu ein vereinfachtes Beispiel. Der Hersteller benötigt die Zahl PI für eine Berechnung und er kennt die Zahl auf 10 Stellen genauer als seine Mitbewerber. Daher verschlüsselt er PI und legt dies als verschlüsseltes Byte-Array in seinem Quell-Code ab. Wenn er PI benötigt, dann entschlüsselt er PI, prüft eine Checksumme und verwendet es für seine Berechnung. Ein Angreifer ohne passende Lizenz besitzt den Schlüssel nicht, um den verschlüsselten Wert zu entschlüsseln. Je mehr solcher Konstanten wie PI in der Anwendung verschlüsselt hinterlegt sind, umso höher die Sicherheit, da ein Angreifer alle versteckten Konstanten erst finden muss.

Eine zweite Strategie ist das Verschlüsseln von erfassten Daten. Eine Option ist das Verschlüsseln mit einem in der Software hinterlegten öffentlichen Schlüssel. Dies ist auch ohne passende Lizenz möglich. Zum Laden und Entschlüsseln der Daten wird dann der private Schlüssel verwendet. Dieser befindet sich in der Lizenz. Somit können Sensoren zum Beispiel immer aufzeichnen, der Anwender kann die Daten aber nur weiterverarbeiten, wenn er die entsprechende Lizenz auch besitzt.

Überprüfen der Lizenz mit API-Aufrufen

Eine zusätzliche Option ist das Überprüfen der Lizenz mit einem API-Call. Dabei geht es darum, Simulatoren an der Schnittstelle zwischen Software und Sicherheitssystem zu verhindern. Hier sind folgenden Strategien gebräuchlich:

1. RED (Random Encryption Decryption) - Ver- und Entschlüsselung von Zufallsdaten. Es werden zufällige Daten erzeugt, verschlüsselt und später wieder entschlüsselt. Das Ergebnis der Entschlüsselung muss die originalen Daten ergeben. Das Ergebnis der Verschlüsselung muss anders sein als die originalen Daten. Diese Methode erzeugt ein zufälliges Rauschen in der Kommunikation mit dem Sicherheitssystem und kann nicht durch Aufzeichnen und erneutes Abspielen der Kommunikation simuliert werden.

2. RID (Required Information Decryption) - Entschlüsselung von (benötigten) Daten. Dies ist analog zum oben bereits behandelten Punkt der Datenentschlüsselung. Allerdings können hier auch zufällige Daten hinterlegt werden, die nur auf Korrektheit geprüft, aber nie verwendet werden. Diese Methode kann nicht durch eine andere Entschlüsselung simuliert werden.

3. P-RID (Probablistic Required Information Decryption) - Konditionelle Entschlüsselung von (benötigten) Daten. Hier wird Wert unterschiedlich verschlüsselt in mehreren Sequenzen hinterlegt. Zur Entschlüsselung wird abhängig von Datum oder Gerät eine der möglichen Sequenzen ausgewählt. Eine so erzeugte Simulation von Aufzeichnung und Abspielen sieht für den Angreifer auf den ersten Blick lauffähig aus, funktioniert aber nicht skalierbar zu jeder Zeit und auf jedem Gerät.

Ablage von Schlüsseln

Die Schlüssel für die Entschlüsselung sollten in der Lizenz sicher abgelegt sein. Zwei der gängigen Strategien sind Dongles und Lizenzdateien. Bei Dongles gibt es den Unterschied, ob der Dongle nur eine reine eindeutige Identifikation liefert oder Schlüssel sicher in einem Smartcard-Chip speichern kann und die Verwendung dieser per API ermöglicht.

Diesen Beitrag lesen Sie auch in der Fachzeitschrift ELEKTRONIKPRAXIS Ausgabe 21/2020 (Download PDF)

Bei Lizenzdateien können diese wahlweise unterschrieben sein, um eine Manipulation zu verhindern. Besser ist es, wenn die Lizenzdatei mit Daten des Zielgerätes verschlüsselt ist und somit auch als sicherer Speicher für Schlüssel diesen kann. Bei CodeMeter wird zum Beispiel aus der Hardware der Fingerabdruck berechnet und daraus ein privater Schlüssel abgeleitet. Der zugehörige öffentliche Schlüssel wird vom Gerätehersteller verwendet, um seinen Schlüssel verschlüsselt auszuliefern. Die Lizenzdatei kann somit nur auf dem Zielgerät mit dem korrekten Fingerabdruck entschlüsselt werden.

* Rüdiger Kügler ist VP Sales und Sicherheitsexperte, bei der WIBU-SYSTEMS AG.

(ID:46976469)