Integritätsschutz von Software

Ein Anwendungsfall von Zertifikaten ist die Code-Signatur. Ein Softwarehersteller unterschreibt seine Software mit seinem privaten Schlüssel. Über ein Zertifikat, welches eine vertrauenswürdige Zertifizierungsstelle ausgestellt hat, wird der öffentliche Schlüssel mit der Identität des Softwareherstellers verknüpft. Der Anwender kann damit sicher erkennen, von welchem Hersteller die entsprechende Software entwickelt wurde und ob sie unverändert ist. Dieser Mechanismus wurde entwickelt, um Anwender vor Viren zu schützen; er dient allerdings nicht dazu, den Softwarehersteller gegen Raubkopien und Manipulation an seiner Software zu schützen. Und hier kommen AxProtector und ExProtector ins Spiel.

Der in Windows bereits integrierte Code-Signatur-Mechanismus (Authenticode) zeigt dem Benutzer an, wenn eine Software aus einer unbekannten Quelle kommt. Dies ist der Fall, wenn sie nicht unterschrieben ist, wenn das Zertifikat nicht auf ein vertrauenswürdiges Wurzelzertifikat zurückzuführen ist oder wenn die Signatur nicht korrekt ist. Diese Meldungen sind lediglich Warnmeldungen, die vom Anwender zudem abgeschaltet werden können. Warum sollte sich ein Raubkopierer oder der Anwender einer Raubkopie davon abschrecken lassen?

Windows – AxProtector

Der AxProtector verschlüsselt Ihre komplette Anwendung (.exe-Datei) und fügt automatisch einen Fingerabdruck der Anwendung und eine Signatur des Fingerabdrucks hinzu. Zusätzlich wird der öffentliche Schlüssel versteckt in der Anwendung hinterlegt.

Getreu nach dem Motto „Traue niemanden außer Dir selbst“ überprüft sich die geschützte Anwendung selber beim Starten. Stimmt die Signatur nicht mit der im Speicher geladenen Anwendung überein, beendet sich die Anwendung mit einer entsprechenden Fehlermeldung. Neben der Tatsache, dass sich Ihre Anwendung mit dem AxProtector geschützt nur noch auf sich selbst verlässt, hat der AxProtector noch einen zweiten wesentlichen Vorteil gegenüber dem Standardmechanismus von Windows: Die geschützte Anwendung überprüft sich selbst im Speicher und nicht nur auf der Festplatte. Änderungen, die von Hackern nach dem Laden vorgenommen wurden, werden damit auch erkannt.

Anwendung und Bibliotheken

Natürlich kann man sich fragen, ob ein versteckter Fingerabdruck (Prüfsumme) nicht die gleichen Ergebnisse liefern würde wie die Prüfung der eigenen Signatur. Bei einer Anwendung, die aus einer einzelnen exe besteht, ist dies korrekt. Der große Vorteil kommt erst zum Tragen, wenn die Anwendung aus einer exe und mehreren Bibliotheken (dlls) besteht.

In diesem Fall werden die exe und alle dlls vom AxProtector signiert. Beim Laden einer geschützten dll überprüft die exe die Integrität der dll und die dll die Integrität der exe. Dabei können Sie definieren, ob die dll nur in bestimmten (eigenen) Anwendungen geladen werden darf. Und Sie können festlegen, welche dlls zwingend eine gültige Signatur besitzen müssen, damit diese geladen werden dürfen.

Damit können Sie unter anderem folgende Anwendungsfälle abbilden und folgende Bedrohungen abwehren:

• Ein Hacker erzeugt eine veränderte Kopie einer Ihrer dlls. Zum Bespiel ersetzt er die dll, welche den Kopierschutz überprüft durch eine dll, die immer „Ok“ antwortet. Die Integritätsprüfung des AxProtectors verhindert, dass diese dll ausgetauscht werden kann. Die Hürde für den Hacker wurde damit deutlich erhöht. Prinzipiell ist allerdings das Auslagern des Kopierschutzes in eine extra dll aus Sicherheitsgründen nicht zu empfehlen.
• Ein Hacker verwendet Ihre dll mit Ihrem geistigen Eigentum in einer eigenen Anwendung. Durch die Integritätsprüfung erkennt die dll, dass Sie innerhalb einer nicht von Ihnen autorisierten Anwendung geladen wurde und verweigert den Dienst.

Warum ist es notwendig, hier mit Signaturen zu arbeiten? Die Antwort liefert das Henne-Ei-Phänomen. Wenn die exe die dll prüfen soll, dann müsste die exe die Prüfsumme der dll kennen. Also trägt man diese in der exe ein. Wenn die dll aber auch die exe prüfen soll, dann muss die dll die Prüfsumme der exe kennen. Dazu müsste man diese eintragen, was aber die dll verändert und damit die in der exe eingebundene Prüfsumme ungültig macht.

Verwendet man Signaturen, wird in allen Modulen (exe und alle dlls) lediglich der öffentliche Schlüssel versteckt eingebettet. Mit dem privaten Schlüssel wird jedes Modul unterschrieben und die Signatur an das Modul selber angehängt. Damit kann jeder jeden prüfen. Und einzelne Teile können später unabhängig von den anderen Teilen aktualisiert werden.

ExProtector – Embedded Devices

Der AxProtector erzeugt eine geschützte Anwendung oder Bibliothek, welche sich selber entschlüsselt. Beim ExProtector ist dies anders: Der ExProtector schützt Anwendungen, Bibliotheken oder das komplette Betriebssystemimage auf einem Embedded Device. Zum Laden und Ausführen der geschützten Teile wird zusätzlich ein Modul, die ExEngine, in den aufrufenden Teil integriert. Ist das komplette Betriebssystemimage (z.B. ein VIP unter VxWorks) verschlüsselt, wird die ExEngine in den Bootloader integriert. Sind Anwendungen und Bibliotheken (z.B. RTPs und DKMs unter VxWorks) verschlüsselt, wird die ExEngine in das Betriebssystem integriert.

Beim Schutzvorgang können Sie festlegen, ob Sie die zu schützende Software verschlüsseln, signieren oder verschlüsseln und signieren. Verschlüsseln schützt gegen Reverse Engineering; Signieren stellt die Integrität sicher. 

Bei der Verschlüsselung wird, ebenso wie beim AxProtector, ein Schlüssel aus der Lizenz verwendet und die zu schützenden Daten werden mit AES verschlüsselt. Bei der Signatur wird ein privater Schlüssel verwendet, um den Fingerabdruck der Anwendung zu unterschreiben. Sowohl AES-Schlüssel als auch Signaturschlüssel werden sicher in einem Master-Dongle, der Firm Security Box (FSB), gespeichert. Somit sind diese beiden Schlüssel sicher vor Auslesen und unbefugter Benutzung geschützt.

Berechtigungsverwaltung

Im einfachen Fall gibt es einen oder wenige Master-Dongles, die alle denselben privaten Schlüssel enthalten. Der zugehörige öffentliche Schlüssel wurde während der Entwicklung der Software für das Embedded Device in die ExEngine integriert.

Der ExProtector unterstützt auch ein Berechtigungsmanagement. In diesem Falle erhält jeder Master-Dongle einen eigenen privaten Schlüssel für die Codesignatur. Eine zentrale Stelle erstellt Zertifikate, welche die Berechtigungen der einzelnen Master-Dongles festlegen. Die Berechtigungen können sowohl nach Anwendungsebene als auch nach Geräteklasse oder Gerätecharge unterschieden werden.

Die Anzahl der Anwendungsebenen wird bei der Integration der ExEngine in das Embedded Device festgelegt. Ein einfaches Beispiel ist: Betriebssystem, Anwendung, Konfigurationsdaten. Geräteklasse und Gerätechargen werden ebenfalls individuell implementiert.

Damit ist es möglich, dass ein Anbieter von Embedded Devices seinen Kunden ein Zertifikat erstellt, mit dem der Kunde selber in seinen Geräten Anwendungen aktualisieren kann. Ein Update des Betriebssystems bleibt aber weiterhin dem Anbieter vorbehalten. Der Kunde kann nur ein Betriebssystemimage einspielen, welches vom Anbieter unterschrieben wurde. Doch auch beim Anbieter selbst können die Rechte unterschiedlich verteilt sein. Nur die Produktion kann Software für produktive Geräte unterschreiben; Entwickler besitzen nur die Möglichkeit, Testgeräte zu verwenden. CodeMeter bietet Ihnen ein Signaturtool, mit dem entsprechende Zertifikate einfach erstellt und verwaltet werden können.

Fazit

Ob Embedded Device oder PC mit Standard-Betriebssystem: AxProtector und ExProtetcor schützen Ihre Software sicher gegen Reverse Engineering durch Verschlüsselung und gegen Manipulation durch Codesignaturen. Auf einem Standard-Betriebssystem folgt der AxProtector treu dem Grundsatz „Vertraue niemanden außer Dir selbst“ und bietet so höchste Sicherheit. Auf einem Embedded Device bietet der ExProtector zusätzlich die Möglichkeit, mittels Zertifikaten die Berechtigungen „Wer darf welche Teile aktualisieren“ zu verwalten.