Sicherheit von CodeMeter
Der Raum war zwar nicht dunkel, aber dennoch hatte das Meeting den Charakter eines Verhörs. Ich allein auf der einen Seite des Tisches und zwei Geschäftsführer eines potenziellen Kunden auf der anderen Seite. Nach zwei Stunden dann das erlösende Fazit meines Gegenübers: „Herr Kügler, ich weiß, dass nichts 100% sicher sein kann, aber CodeMeter ist die beste verfügbare Lösung.“
Rückblick, zwei Stunden früher.
Herr X: Herr Kügler, können Sie mir erklären, wie der AxProtector unsere Software verschlüsselt?
Meine Antwort: Wir haben mit der CodeMeter Protection Suite ein Optimum aus Performance und Sicherheit erreicht. Daher werden beim Verschlüsseln ein bzw. mehrere Software-Schlüssel pseudozufällig erzeugt. Diese werden dann verwendet, um Ihre Software bzw. einzelne Teile Ihrer Software mit AES 256-Bit zu verschlüsseln. Diese Schlüssel selbst werden dann mittels mehrerer CodeMeter-Schlüssel, die sich in der CodeMeter-Lizenz befinden, verschlüsselt und in der Software hinterlegt.
Beim Starten oder wenn ein verschlüsselter Teil der Software verwendet wird, wird aus den verschiedenen möglichen CodeMeter-Schlüsseln einer gewählt. Der Software-Schlüssel wird damit entschlüsselt und mit diesem dann Ihre Software. Ist die passende Lizenz nicht vorhanden, wird der benötigte Software-Schlüssel nicht bereitgestellt und Ihre Software kann nicht entschlüsselt und somit auch nicht ausgeführt werden.
Herr X: Ist die CmActLicense nicht sicherer als der Dongle? Beim Dongle hat man doch ein wohl bekanntes Interface auf USB-Ebene, während man bei der CmActLicense ja asymmetrische Verfahren verwenden kann.
Meine Antwort: Um große Datenmengen wie bspw. eine Anwendung zu entschlüsseln, benötigt man immer ein symmetrisches Verschlüsselungsverfahren wie AES 256-Bit. Wenn man außerdem das gleiche Installationspaket für jeden Kunden bereitstellen möchte, muss dieser Schlüssel zwangsläufig für alle Lizenzen identisch sein. In beiden Fällen (CmDongle und CmActLicense), aber auch im Fall eines CmCloudContainers, werden die symmetrischen Schlüssel über asymmetrische Verfahren in den CmContainer übertragen und dort sicher gespeichert: im CmDongle in einem Smartcard-Chip, in einer CmActLicense verschlüsselt über Eigenschaften des Rechners in einer Lizenzdatei und im Fall des CmCloudContainers sicher in der Cloud. Bei einem CmDongle und einem CmCloud Container sind die CodeMeter-Schlüssel nie im Hauptspeicher des Rechners des Anwenders. Im Fall einer CmActLicense sind diese zwangsläufig für eine kurze Zeit im Speicher verfügbar. CodeMeter verwendet verschiedene Anti-Reverse-Engineering-Mechanismen, um das Auslesen zu erschweren. Aber dennoch gilt: Etwas, das gar nicht erst da ist, kann auch nicht ausgelesen werden.
Herr X: Aber wenn jemand die USB-Kommunikation abhört. Dann kann er doch einen CmDongle simulieren.
Meine Antwort: Auch hier gilt, dass CodeMeter auf verschiedene Mechanismen setzt. Zum einen ist die Kommunikation der CodeMeter Runtime mit dem CmDongle verschlüsselt. Zum anderen beinhaltet eine Lizenz neben den symmetrischen Schlüsseln auch immer asymmetrische Schlüssel. Die geschützte Software erzeugt eine zufällige Challenge, der CmDongle muss diese mit dem privaten Schlüssel beantworten und die Software prüft diese mit dem öffentlichen Schlüssel. Diese Prüfung kann nicht ohne den privaten Schlüssel simuliert werden. Aber die beste Maßnahme kommt zum Schluss. Wie ich erklärt hatte, werden verschiedene CodeMeter-Schlüssel verwendet, um einen Software-Schlüssel zu verschlüsseln. Das heißt, beim Schützen werden viele Möglichkeiten erzeugt. Beim Starten wird eine davon ausgewählt. Die Auswahl erfolgt so, dass auch bei tausenden Starts nicht alle möglichen Schlüssel ausgeschöpft werden. Das heißt, ein über Aufzeichnen der Sequenzen erzeugter Simulator wäre nicht vollständig und würde nur stark eingeschränkt funktionieren.
Herr X: Wie sieht das mit Updates meiner Software aus? Verwenden diese den gleichen Schlüssel? Oder sollte ich aus Sicherheitsgründen besser eine neue Lizenz auch bei einem Minor-Update erstellen?
Meine Antwort: Nein, Sie können das nächste Update ganz sorgenfrei mit der gleichen Lizenz schützen. Das ist ja der Sinn der Sache, dass CodeMeter nicht nur den Schutz sicher zur Verfügung stellt, sondern auch Ihre Lizenzierungsprozesse vereinfacht. Hinter jeder Lizenz steht ein Wurzel-Schlüssel, der Product Item Secret Key (PISK). Aus diesem werden beim Verschlüsseln (im CmDongle) die benötigten CodeMeter-Schlüssel abgeleitet. Aus Revisionsgründen ist diese Ableitung von der Prüfsumme der zu schützenden Anwendung abhängig.
Gleiche Anwendung / Gleiche Lizenz -> gleiche Schlüssel -> gleiche geschützte Anwendung.
Unterschiedliche Anwendung (z.B. Minor-Update) / Gleiche Lizenz -> unterschiedliche Schlüssel -> unterschiedliche geschützte Anwendung.
Herr X: Meine Kollegen haben bei einem eigenen Chip über eine Seitenkanal-Attacke unsere eigenen Schlüssel auslesen können. Geht das auch bei einem CmDongle?
Meine Antwort: Hier greifen auch mehrere Maßnahmen. Wir verwenden einen sicheren Smartcard-Chip, der bereits vom Hersteller mit Maßnahmen gegen Seitenkanal-Attacken ausgestattet ist. Außerdem haben wir in der Firmware eigene Maßnahmen implementiert und zu guter Letzt kann der PISK nicht direkt verwendet werden, so dass der Wurzel-Schlüssel nicht direkt angegriffen werden kann.
Herr X: Wie sicher ist der IP Protection Modus, bei dem meine Software ohne CodeMeter-Lizenz ausgeführt werden kann?
Meine Antwort: Offen und ehrlich gesagt kann diese Art des Schutzes nicht das Niveau des Schutzes mit einer CodeMeter-Lizenz erreichen. Bei einer CodeMeter-Lizenz ist die Software sicher mit einem Schlüssel verbunden, der in einem sicheren Schlüsselspeicher liegt. Im IP Protection Modus wird der Software-Schlüssel verschlüsselt und versteckt in der geschützten Anwendung hinterlegt. Das Verstecken des Schlüssels gehört zu unserer Kernkompetenz. Allerdings erhöht die Trennung von Software und Lizenz den Schutz eben noch weiter.
Herr X: Habe ich das richtig verstanden, dass der automatische Schutz einer nativen C/C++-Anwendung besser ist als der einer .NET-Anwendung? Bei .NET ist der Intermediate-Code ja einfacher lesbar als Maschinencode.
Meine Antwort: Das Paradoxe ist, dass es genau andersherum ist. Der AxProtector .NET kann automatisch ein viel höheres Schutzniveau erreichen als der AxProtector Windows, eben weil der Intermediate-Code einfach lesbar ist. AxProtector Windows verschlüsselt die ganze Anwendung als einen Block und entschlüsselt diese wieder komplett. AxProtector .NET zerlegt die Anwendung in ihre einzelnen Funktionen und verschlüsselt diese einzeln. Zur Laufzeit wird nur der Teil, der gerade verwendet wird, entschlüsselt und sofort in Maschinencode umgewandelt und dann aus dem Speicher entfernt. Das erhöht die Sicherheit automatisch um ein Vielfaches.
Herr X: Könnte ein Angreifer dann bei einer .NET-Anwendung nicht einfach alle Funktionen auslesen und einzeln entschlüsseln?
Meine Antwort: Im Prinzip ist dies möglich. Das nennt sich statische Analyse, weil im Gegensatz zur dynamischen Analyse der Code nicht ausgeführt wird. Um dies zu verhindern, fügt AxProtector .NET Fallen ein. Diese sehen aus wie normaler Code, aber eine Entschlüsselung führt zu einer Sperre und damit dem Verlust der Lizenz. Und ohne Lizenz kann der Rest der Anwendung nicht mehr entschlüsselt werden, auch nicht durch eine statische Analyse.
Bei einer nativen Anwendung, z.B. in C/C++, Delphi oder Fortran, können Sie die dynamische Entschlüsselung zur Laufzeit und die Falle auch verwenden, allerdings erfordert diese eine Definition von Funktionen und Fallen in der Anwendung, also etwas mehr Aufwand auf Ihrer Seite.
Herr X: Was würden Sie mir für den höchstmöglichen Schutz mit CodeMeter und AxProtector empfehlen?
Meine Antwort: Wir haben für C/C++-Anwendungen eine neue Art der Obfuskierung entwickelt und in den AxProtector integriert. Wir nennen diese Technology CTP (Compile Time Protection). Dabei wird die Anwendung bereits beim Kompilieren so verändert, dass Strukturen nicht mehr zu erkennen sind. Diese Technologie geht weit über den IP Protection Modus beim Verschlüsseln hinaus und kann mit oder ohne CodeMeter-Lizenz verwendet werden. Die Compiler-Integration erfordert allerdings den Einsatz des Clang-Compilers. Falls Sie einen CmDongle oder einen CmCloud Container verwenden, empfehle ich Ihnen, besonders sensiblen Code Ihrer Anwendung in den CmContainer auszulagern. Dieser Code wird von Ihnen speziell geschrieben, verschlüsselt in den CmContainer verschoben und dort entschlüsselt und ausgeführt. Diesen Mechanismus nennen wir CodeMoving und er bietet den höchstmöglichen Schutz gegen Reverse Engineering, da der Angreifer den ausgeführten Code gar nicht sehen kann, weil er niemals im Arbeitsspeicher des Systems vorhanden ist.
Mein Gegenüber bedankte sich für die ausführliche und technisch in die Tiefe gehende Beschreibung der CodeMeter-Sicherheitsmechanismen, auch für das ehrliche Aufzeigen der generellen Grenzen der Technologie. Vor allem die Tatsache, dass Wibu-Systems diese Details offenlegt, spricht für CodeMeter. Schon Auguste Kerckhoffs stellte vor 140 Jahren fest, dass eine gute Sicherheit nur gewährleistet werden kann, wenn Mechanismen und Prinzipien nicht auf Geheimhaltung basieren. Lediglich der Schlüssel ist geheim. Und hat, da stimmte mir mein Gegenüber zu, mit einem CmDongle einen guten sicheren Ort gefunden, um geheim zu bleiben.
KEYnote 45 – Ausgabe Frühjahr/Sommer 2023