Know-how-Schutz
Wie sich Software-Diebstahl vorbeugen lässt
Die Bedeutung der Software nimmt im Maschinen- und Anlagenbau stetig zu. Ergo stellt sich sowohl für die Hersteller als auch die Anwender die Frage: Wie lässt sich sicherstellen, dass es hier zu keinen unerwünschten Manipulationen kommt?
Meine erste Begegnung mit Softwareschutz und Lizenzierung hatte ich 1994. Damals wurde kurz vor der Cebit die ‚Yellow Point CD‘ veröffentlicht. Diese von der Firma Yellow-Point entwickele ‚Freischalt-CD‘ – quasi ein Offline-Shop in der Prä-Internet-Ära – enthielt verschlüsselte Software-Produkte namhafter Hersteller wie Microsoft, Lotus und Computer Associates. Zum Kauf der Software konnte der Kunde bei der Hotline von Yellow-Point anrufen und bekam gegen Bezahlung einen Freischalt-Schlüssel für die gewünschte Software. Marketingmäßig war dies ein super Erfolg. Aber technisch ein totales Fiasko: Schon nach wenigen Tagen wurden Hacks über Diskette und Mailboxen weitergegeben. Doch wie kam es dazu? In der Implementierung war ein Fehler, so dass man nur wenige Schlüssel (256 laut Aussagen des Chaos Computer Clubs/CCC) durchprobieren musste, um an die gewünschte Software zu kommen. Dabei wurde die originale Software manipuliert und missbraucht, das heißt der Aufwand für die Angreifer war extrem gering.
Die ‚ultimative Höchststrafe‘ für eine fehlerhafte Implementierung ist ein Schlüsselgenerator, auch KeyGen genannt. Ein Hersteller – nennen wir ihn Herbert – hat eine Software produziert, die er verkaufen möchte. Zwei unbedarfte User – Uwe und Ute – wollen die Software kaufen. Ein unbefugter Dritter, der bösen Boris, hat schließlich einen Schlüsselgenerator geschrieben. Das heißt, er kann für Uwe und Ute eine passende Lizenz erzeugen, welche mit der originalen Software von Herbert funktioniert. Uwe und Ute merken gar nicht, dass sie eine Raubkopie einsetzen. Das Resultat: Boris erhält das ganze Geld und Herbert geht leer aus.
Was hat Herbert falsch gemacht? Er hat einen Fehler in der Implementierung der Kryptographie gemacht. Solche Fehler sind leider keine Seltenheit. „Ich verschlüssele meine Lizenzinformation mit einem Hash-Algorithmus“ ist eine beliebte Aussage, bei der sich dem Security-Fachmann die Nackenhaare gleich mehrfach sträuben. Beim Verschlüsseln geht es darum, einen Text so zu codieren, dass er nur noch mit dem passenden Schlüssel gelesen werden kann. Bei einer Hash-Funktion wird der Text so zerhackt, dass er nie wieder gelesen werden kann. Dabei hat man eigentlich die beiden folgenden Optionen:
- Ich verschlüssele meine Lizenzinformation und entschlüssele diese wieder in meiner Software. Nur meine Software kennt den Schlüssel.
- Ich versehe meine Lizenz mit einem Hash-Wert. Normalerweise verwendet ein Hash-Algorithmus keinen Schlüssel. Das heißt, jeder kann den Hash-Wert erzeugt haben. Daher fügt man an die originalen Daten einen geheimen Schlüssel an – auch Salt-Wert genannt – und berechnet dann den Hash-Wert. Mit anderen Worten: Nur die eigene Software kennt den Salt-Wert und nur sie kann dann den Hash-Wert prüfen.
Der konzeptionelle Fehler liegt hier jedoch in der Tatsache, dass das ‚Geheimnis‘ (sprich der Schlüssel beziehungsweise der Salt-Wert), welches zum Erstellen der Lizenz nötig ist, auch in der gleichen Form in der Software eingebettet ist. Der böse Boris muss dieses Geheimnis nur finden und schon kann er sich seinen KeyGen basteln.
Die Schlüssel-Frage
Abhilfe schafft hier der Einsatz von asymmetrischer Kryptographie. Während für eine symmetrische Verschlüsselung der gleiche Schlüssel zum Verschlüssen und Entschlüsseln verwendet wird, kommt bei asymmetrischer Verschlüsselung ein Schlüsselpaar – bestehend aus einem privaten Schlüssel und einem öffentlichen Schlüssel – zum Einsatz. Mathematisch gilt dabei, dass sich aus dem privaten Schlüssel der öffentliche Schlüssel ableiten lässt; jedoch gibt es keinen Weg, wie man aus der Kenntnis des öffentlichen Schlüssels wieder auf den privaten Schlüssel kommt. Der private Schlüssel ist geheim zu halten und nur dem Besitzer bekannt. Den öffentlichen Schlüssel darf jeder kennen.
Zwei Beispiele für asymmetrische Verfahren sind RSA (Rivest Shamir Adleman) und ECC (Elliptic Curve Cryptography). ECC ist dabei das modernere und flexiblere Verfahren. Um eine vergleichbare Sicherheit zu RSA zu erhalten, kann man deutlich kürzere Schlüssel wählen. Während die Erzeugung eines RSA-Schlüssels eine aufwendige Mathematik mit Primzahlen benötigt, ist bei ECC jede beliebige Zahl als privater Schlüssel verwendbar. Ein weiterer Vorteil von ECC ist die klare Trennung nach asymmetrischer Verschlüsselung und Signatur.
Der Anwendungsfall einer Signatur sind Integrität und Authentizität von Daten. Dies bedeutet, dass die Daten unverändert sind und sichergestellt werden kann, wer die Daten erstellt hat. Dazu werden die Daten mit dem privaten Schlüssel des Senders unterschrieben. Jeder beliebige Empfänger kann mit dem öffentlichen Schlüssel des Senders die Echtheit der Daten überprüfen.
Im Anwendungsfall Lizenzierung bettet der Hersteller Herbert seinen öffentlichen Schlüssel in seiner Software ein. Nun erstellt er für seine User Uwe und Ute individuelle Lizenzen und unterschreibt diese mit seinem privaten Schlüssel. Herberts Software überprüft mittels des eingebetteten öffentlichen Schlüssels, ob die Lizenz wirklich von Herbert erstellt wurde und ob sie unverändert ist.
Diese einfache Methode verhindert einen KeyGen. Der böse Boris ist nunmehr gezwungen, auch die Software von Herbert zu verändern. Damit haben Uwe und Ute die Möglichkeit, eine Raubkopie zu erkennen, und Herbert bieten sich weitere Optionen, eine Raubkopie zu verhindern oder deutlich zu erschweren.
Zertifikate für den Anwender
Indem Herbert nicht nur seine Lizenzen unterschreibt, sondern auch seine Software, können Uwe und Ute unter der Verwendung des öffentlichen Schlüssels von Herbert überprüfen, ob die Software wirklich von Herbert kam und unverändert ist. Den öffentlichen Schlüssel schickt Herbert dabei mit seiner Software einfach mit. Was aber wäre, wenn der böse Boris die Software mit seinem eigenen Schlüssel unterschreibt und seinen eigenen öffentlichen Schlüssel beilegt? An diesem Punkt kommen Zertifikate ins Spiel.
Ein Zertifikat bestätigt den Eigentümer eines öffentlichen Schlüssels. Der Eigentümer kann eine Person, eine Organisation oder ein IT-System sein. Es beinhaltet Attribute, die den Zweck des Zertifikats beschreiben und eine Unterschrift des Ausstellers. Herbert lässt sich also von einer Zertifizierungsstelle wie zum Beispiel VeriSign zu seinem öffentlichen Schlüssel ein Zertifikat ausstellen. Die Zertifizierungsstelle überprüft die Identität von Herbert, bevor sie sein Zertifikat erstellen. Nachdem Herbert nun sein Zertifikat besitzt, legt er dieses anstelle seines öffentlichen Schlüssels seiner Software bei. Damit können Uwe und Ute die Echtheit seines öffentlichen Schlüssels überprüfen. Zur Prüfung des Zertifikats wird der öffentliche Schlüssel der Zertifizierungsstelle verwendet. Doch wie kommen Uwe und Ute an diesen? Und was noch wichtiger ist: Woher wissen Uwe und Ute, dass dieser öffentliche Schlüssel echt ist? Die Antwort liegt in den Stammzertifikaten.
Ein Stammzertifikat beglaubigt die Echtheit des eigenen öffentlichen Schlüssels und ist bei Uwe und Ute bereits vorhanden, da Stammzertifikate schon im Betriebssystem integriert sind und bei Aktualisierungen des Betriebssystems ebenfalls aktualisiert werden. Solche Aktualisierungen sind notwendig, wenn ein Stammzertifikat abgelaufen ist, eines hinzukommt oder ein Zertifikat gesperrt werden muss. Mit anderen Worten: Regelmäßige Updates des Betriebssystems sind essenziell notwendig, um die Liste der vertrauenswürdigen Stammzertifikate aktuell zu halten.
Ein Beispiel für einen solchen Zertifikatsmechanismus ist Authenticode. Herbert versieht seine Software mit einer digitalen Signatur und das Betriebssystem warnt Uwe und Ute ganz automatisch, wenn die Signatur ungültig ist. Leider warnt es die beiden nicht, wenn die Signatur entfernt oder durch eine andere Signatur ersetzt wurde. Dies müssen Uwe und Ute selber manuell prüfen.
Jetzt könnte Herbert auf die Idee kommen, solche Zertifikate gleich als Lizenzen zu verwenden. Allerdings hat er diesbezüglich die Rechnung ohne den arglistigen Anwender Anton gemacht. Im Gegensatz zu Uwe und Ute, welche die Software kaufen wollen, beabsichtigt der arglistige Anton, eine Raubkopie einzusetzen. Dabei ist ihm vollkommen egal, ob die Software beim Starten eine Warnung ausgibt, dass die Signatur nicht stimmt. Auch würde er nie auf die Idee kommen, die Signatur selber manuell zu prüfen, und er würde sich nicht scheuen, seinen Rechner zu manipulieren, um die Raubkopie einzusetzen. Also reichen Zertifikate alleine nicht aus, um eine sicherer Lizenzierung zu realisieren.
Zertifikate als Lizenzen
Erzeugung eines privaten Schlüssels aus den Eigenschaften eines Rechners mit SmartBird
© Wibu-SystemsDie Lösung hierfür ist asymmetrische Verschlüsselung. Beim asymmetrischen Verschlüsseln kann eine beliebige Person einen Text verschlüsseln, aber nur ein dedizierter Empfänger kann den Text wieder entschlüsseln. Zum Verschlüsseln dient der öffentliche Schlüssel des Empfängers. Zum Entschlüsseln verwendet der Empfänger seinen privaten Schlüssel.
Dieses Verfahren eignet sich perfekt für Softwareschutz mit der Bindung einer Lizenz an einen bestimmten Rechner. Herbert implementiert in seiner Software einen Mechanismus, der einen Fingerabdruck des Rechners erzeugt. Dies kann im einfachen Fall die Seriennummer der Festplatte sein. Aus diesem Fingerabdruck erzeugt er einen privaten Schlüssel. Bei ECC ist dieser Fingerabdruck ganz einfach als privater Schlüssel verwendbar. Dies ist ein weiterer Grund, dieses Verfahren gegenüber RSA vorzuziehen.
Uwe startet nun die Software von Herbert. Diese erzeugt das Schlüsselpaar und schickt den öffentlichen Schlüssel im Rahmen einer Online-Aktivierung an Herbert. Herbert verschlüsselt damit die Lizenz für Uwe und schickt diese zurück. Nur Herberts Software auf dem Rechner von Uwe kann die Lizenz jetzt entschlüsseln und verwenden. Für alle anderen ist die Lizenz nur ‚Kauderwelsch‘. Wenn Ute die gleiche Aktion durchführt, erhält sie eine andere verschlüsselte Lizenz, welche sich nur auf ihrem Rechner entschlüsseln lässt.
Das Beste beider Welten
Der arglistiger Anton kann Herberts Software damit weder mit der Lizenzdatei von Uwe noch mit der von Ute verwenden. Aber der böse Boris – unser Hacker – könnte in diesem Fall einen KeyGen schreiben und eine Lizenz erzeugen. Daher ist eine Mischform von Signaturen/Zertifikaten und Verschlüsselung die finale Lösung für einen guten Softwareschutz – sprich eine zertifikatsbasierende Lösung mit Verschlüsselung wie dies beispielsweise bei CodeMeter von Wibu-Systems umgesetzt wurde.
Zum einen wird dabei jede Lizenzdatei genau für den jeweiligen Rechner verschlüsselt. Als privater Schlüssel wird ein Fingerabdruck verwendet, der sich aus vielen verschiedenen Hardware-Eigenschaften des Rechners von Uwe und Ute zusammensetzt. Dabei gehen diese Eigenschaften mit unterschiedlichen Gewichtungen in den Fingerabdruck ein. Die genaue Zusammensetzung dieses Fingerabdrucks ist das Betriebsgeheimnis von Wibu-Systems. Über ein patentiertes Verfahren – das sogenannte SmartBind – wird noch eine Toleranz hinzugefügt, so dass sich die Hardware bei Uwe und Ute in bestimmten Grenzen ändern darf und der private Schlüssel dennoch erhalten bleibt.
Zum anderen wird die Lizenzdatei vom Hersteller Herbert mit einem privaten Schlüssel unterschrieben. Dabei fügt er automatisch ein Zertifikat bei, welches er von Wibu-Systems erhalten hat. Zur Laufzeit – sprich wenn seine Software die Lizenz überprüft – kann die CodeMeter Runtime mit Hilfe dieses Zertifikats die Gültigkeit der Lizenz überprüfen. Zusätzlich kann Herbert in dem Zertifikat die Berechtigung an seine User geben, die Lizenz weiterzugeben oder befristet auszuleihen.
Letztlich steht man als Softwarehersteller wie Herbert immer vor der Frage, ob man sich eine Lizenzierung selber implementieren oder eine entsprechende Lösung zukaufen sollte. Je umfangreicher die Anforderungen werden und umso mehr Sicherheit man gegen Raubkopien erzielen möchte, umso mehr spricht für letzteres.
Autor:
Rüdiger Kügler ist Security-Experte bei Wibu-Systems.
Das könnte Sie auch interessieren
Technische Schulden bremsen KI-Fortschritt
Technische Schulden gefährden die Einführung von KI, veraltete Legacy-Technologien sind für Unternehmen eine teure Hürde, so das Ergebnis der jüngsten Studie von Pegasystems. Sie kosten Zeit, Geld, Innovationsfähigkeit und womöglich auch Kunden.
mehr...Mit Hackern auf Tuchfühlung
In einem interaktiven Cyber Experience Center können Entscheider ab dem 18. März auf Unternehmensseite hautnah den Ernstfall einer Cyberattacke erleben und ihre Handlungsfähigkeit in einer solchen Stresssituation auf die Probe stellen.
mehr...Fertigungsindustrie: Top-Ziel von Ransomware-Attacken
Ransomware-Taktiken entwickeln sich weiter und nehmen gezielt Industrien mit geringer Toleranz für Ausfallzeiten ins Visier. Artic Wolf veröffentlicht Zahlen dazu.
mehr...Die Basis für sichere IIoT-Projekte
Um der Professionalisierung von Cyberattacken entgegenzuwirken, benötigt es einen umfassende Cybersecurity-Strategie. Normungsgremien und die EU haben dazu Richtlinien erlassen. Wie IEC 62443 und NIS-2-Compliance zusammenhängen und die Basis für...
mehr...Cybersecurity für industrielle Netzwerke
Mit ‚Anybus Defender‘ stellt HMS Networks eine neue Produktreihe für höchste Cybersicherheitsanforderungen im industriellen Umfeld vor. Die neue Produktreihe bietet Schutz für Netzwerke u.a. in der Fertigungsindustrie und für den Bereich der...
mehr...Weltweite Computerstörungen – Was wir wissen und was nicht
Computerprobleme stören vielerorts auf der Welt unter anderem den Luftverkehr. Hier ein Überblick über das, was man bisher weiß und die Aspekte, die noch unklar sind.
mehr...Neuer Chief Revenue Officer ernannt
TXOne Networks, Anbieter von Cyber-Physical Systems (CPS), hat Stephen Driggers zum Chief Revenue Officer (CRO) ernannt. In dieser Rolle wird er der Entwicklung und Ausführung von umfassenden Umsatzstrategien vorstehen.
mehr...Moxa – Grundlagen Security – Teil 3
Paradebeispiel einer Cybersecurity-Strategie
Ein Betreiber von dezentralen Energieressourcen (DER) hat mit einer umfassenden Strategie seine Cybersecurity-Bedrohungen nachhaltig entschärft. Das Beispiel kann als Leitfaden für andere Unternehmen zur Sicherung ihrer Systeme dienen. Teil 3 der...
mehr...Karlsruher Institut für Technologie
Das Projekt EDAI
Im Projekt EDAI koppeln die Forschenden des Karlsruher Instituts für Technologie (KIT) den Entwurf von KI-Algorithmen und KI-Chips. EDAI baut auf Open-Source-Software auf, um insbesondere kleineren und mittleren Unternehmen den Zugang zu...
mehr...