DE69720972T2

DE69720972T2 - Computersystem und Verfahren zum Schutz von Software

Info

Publication number: DE69720972T2
Application number: DE69720972T
Authority: DE
Inventors: Dr. Glenn Benson; Dr. Markus Dichtl
Original assignee: Siemens AG
Current assignee: Siemens AG
Priority date: 1997-05-28
Filing date: 1997-05-28
Publication date: 2004-02-19
Anticipated expiration: 2017-05-29
Also published as: DE69720972D1; CN1165848C; CN1206151A; US6651169B1; EP0881558A1; EP0881558B1

Description

Allgemeiner Stand der Technik
Die vorliegende Erfindung betrifft Mechanismen zum Schutz von Software vor unautorisierter Benutzung und insbesondere unautorisiertem Kopieren.
Die Business Software Alliance schätzt, daß die finanziellen Verluste, die auf das unerlaubte Kopieren von Software zurückzuführen sind, für 1995 8,1 Milliarden US Dollar für Geschäftsanwendungssoftware und 15,2 Milliarden US Dollar für alle Software betragen.
Lösungen wurden in zwei Bereichen vorgeschlagen:

– verbesserte Legislatur für den Schutz von geistigem Eigentum (IPR) und
– verbesserte elektronische Kopierschutzmechanismen (ECP-Mechanismen).

Die IPR-Legislatur und -Durchsetzung verbessert sich in vielen Ländern, es bestehen aber weiterhin signifikante Schwierigkeiten in anderen Teilen der Welt. Als Folge stufen bestimmte Vertreiber zur Zeit ECP neu ein.
Bestimmte beispielhafte Anforderungen, die ein ECP-Mechanismus potentiell erfüllen muß, sind im folgenden aufgelistet:

– Es sollte verhindert werden, daß unautorisierte Kunden geschützte Software ausführen.
– Der Kunde sollte weiterhin Sicherungskopien anfertigen dürfen.
– Der ECP-Mechanismus sollte sich nur minimal auf die Benutzeroberfläche auswirken. Der visuelle Effekt sollte auf das erste anfängliche Einloggen in das Betriebssystem und/oder die Chipkarte begrenzt sein.
– Es sollten nur Standard-Hardware- und -Software-Annahmen getroffen werden. Obwohl Hardware- Dongles Kopierschutzdienste bereitstellen, möchten viele Vertreiber zum Beispiel den Verkauf der Software nicht auf die Gruppe von Kunden beschränken, die ein Dongle besitzen oder ein solches zu installieren bereit sind.
– Der ECP-Mechanismus sollte die Ausführung der geschützten Software nicht auf eine beschränkte Gruppe von Maschinen beschränken. Wenn ein Kunde rechtmäßig Software erwirbt, sollte der Kunde in der Lage sein, die Software ungeachtet der Eigentümerschaft auf jeder beliebigen Maschine auszuführen. Wahlweise sollte der Kunde in der Lage sein, die gleichzeitige Ausführung der Software in mehreren Maschinen zu autorisieren.
– Der ECP-Mechanismus sollte keine erforderlichen Netzwerkabhängigkeiten aufweisen, um ein bereits erworbenes geschütztes Programm auszuführen.
– Dem Vertreiber sollte es gestattet sein, an alle Kunden eine identische Version der geschützten Software zu vertreiben. Durch diese Anforderung kann die geschützte Software durch normale Kanäle verteilt werden, wie zum Beispiel durch CD-ROMs, Disketten oder Netzwerk-Bulletin-Boards.
– Es sollte für einen potentiellen unrechtmäßigen Softwarekopierer extrem schwierig und/oder rechnerisch impraktikabel sein, den ECP-Mechanismus zu umgehen, ohne das geschützte Programm zu modifizieren. Diese Anforderung dient als eine Virusschutzmaßnahme, da eine von dem Vertreiber gelieferte digitale Signatur nicht validiert werden würde, wenn ein unrechtmäßiger Kopierer eine modifizierte Version des ursprünglichen Programms verteilt.
– Der ECP-Mechanismus sollte dem Vertreiber, jedem von dem Vertreiber erstellten Programm oder einem etwaigen potentiellen Trojanisches-Pferd-Programm nicht das private Schlüsselmaterial enthüllen. Obwohl die Hauptfunktionalität darin besteht, den Softwarevertreiber zu schützen, darf dies nicht auf Kosten des Kunden geschehen.
– Der ECP-Mechanismus sollte sowohl in einer Nur-Software-Version als auch in einer hardwareunterstützten Version, die zum Beispiel eine Chipkarte zur Sicherstellung einer weiten Marktannahme verwendet, verfügbar sein.

In [1] wird ein Mechanismus vorgeschlagen, bei dem ein geschütztes Dokument nur über ein speziell konfiguriertes Viewer-Programm betrachtet werden kann, das einem Kunden nur dann erlaubt, das Dokument zu betrachten, wenn der Kunde dem Viewer das private Schlüsselmaterial des Kunden liefert. Dadurch wird der Kunde davon abgehalten, unautorisierte Kopien des Viewer-Programms zu verteilen, denn dazu müßte der Kunde anderen sein eigenes privates Schlüsselmaterial enthüllen. Da dieser Mechanismus erfordert, daß das Viewer-Programm auf das private Schlüsselmaterial zugreift, wird jedoch eine der obenbeschriebenen Anforderungen verletzt. Außerdem kann dieser Mechanismus nicht in Verbindung mit einer Chipkarte verwendet werden, die so konfiguriert ist, daß eine Freigabe von privatem Schlüsselmaterial vermieden wird.
Die internationale Patentanmeldung WO 88 05941 lehrt ein Softwareregulierungssystem zur Regulierung der Verwendung eines Softwareprogramms in einem digitalen Host-Datenverarbeitungssystem. Das Softwareregulierungssystem enthält eine oder mehrere von dem Softwareprogramm verarbeitete Checkpoint-Routinen und eine Software-Regulierungseinrichtung, die Teil des Computersystems oder extern mit diesem verbunden sein kann. Die Checkpoint-Routinen erzeugen Zufalls-Checkpoint-Nachrichten, die chiffriert und zu der Software-Regulierungseinrichtung übertragen werden. Die Software-Regulierungseinrichtung dechiffriert die Checkpoint-Nachricht, führt eine Verarbeitungsoperation durch, um eine Antwortnachricht zu erzeugen, chiffriert die Antwort und sendet die chiffrierte Antwort zu der Checkpoint-Routine. Die Checkpoint-Routine bestimmt dann, ob die chiffrierte Antwort korrekt ist und erlaubt dem Softwareprogramm entweder, weiterzulaufen oder beendet es.
Eine Übersicht über die asymmetrische Kryptographie zum Beispiel bezüglich des RSA-Verfahrens, und die probabilistische Verschlüsselung, wie zum Beispiel das probabilistische Blum-Goldwasser-Verschlüsselungsschema mit öffentlichen Schlüsseln, findet sich in [2].
Der Chiquadrattest, der Kolmogorov-Smirnov-Test und der Seriell-Korrelations-Test werden in [3] beschrieben.
Eine Übersicht über digitale Signaturverfahren (z. B. Rivest-Shamir-Adleman (RSA) usw.) findet sich in [2].
In [4] wird die kryptographische Zufälligkeit aus Luftturbulenz in Plattenlaufwerken beschrieben.
Ein Beispiel für eine Nachrichten-Digest-Funktion (die auch als einseitige Hash-Funktion bekannt ist) findet sich in MD5 [5]. Es ist rechnerisch impraktikabel oder sehr schwierig, die Umkehrung eines Nachrichten-Digest zu berechnen.
Die Aufgabe der vorliegenden Erfindung ist die Bereitstellung eines verbesserten ECP-Mechanismus, der die meisten der obenbeschriebenen Beispielanforderungen oder sogar alle erfüllen kann.
Kurze Darstellung der Erfindung
Die vorliegende Erfindung benutzt ein asymmetrisches Vertraulichkeitsprotokoll. Bei einem asymmetrischen Vertraulichkeitsprotokoll treten zwei Teilnehmer A und B auf. A besitzt privates Schlüsselmaterial und B hat keinen Zugang zu dem privaten Schlüsselmaterial von A, ohne selbst das private Schlüsselmaterial zu enthüllen. Zu Anfang haben A und B kein gemeinsames Geheimnis. Im Verlauf des Verfahrens wird A und B ein gemeinsames Geheimnis bekannt. A beweist B, daß A Zugang zu dem privaten Schlüsselmaterial hat.
Ein asymmetrischer Vertraulichkeitsbeweis ist zum Beispiel die Verschlüsselung mit öffentlichen Schlüsseln. Wie in dem nachfolgenden asymmetrischen Vertraulichkeitsprotokoll dargestellt, beweist A B, daß A Zugang zu dem privaten Schlüsselmaterial hat.
A ← B: h(r),B,P_A(r,B)
A → B: r
Das obenbeschriebene Protokollschema verwendet die folgende Notation:
– A → B bedeutet, daß A eine Nachricht zu B sendet; und B → A bedeutet, daß B eine Nachricht zu A sendet.
– r bedeutet eine Zufallszahl, die als Nonce verwendet wird
– h(r) ist ein Nachrichten-Digest des Nonce
– P_A(r,B) ist die Verschlüsselung des Nonce und der Identität von B unter Verwendung des öffentlichen Schlüsselmaterials von A.
Hierbei erzeugt B ein Nonce und verschlüsselt das Nonce (zusammen mit der Identität von B) unter Verwendung des öffentlichen Schlüsselmaterials von A, d. h. P_A(r,B).
Zusätzlich berechnet B das Nachrichten-Digest des Nonce, h(r).
B sendet die oberbeschriebenen Informationen zusammen mit einem Wert, der die Identität von B darstellt, zu A.
Als nächstes verwendet A sein privates Schlüsselmaterial zur Entschlüsselung von P_A(r,B) und erhält r, B. A berechnet das Nachrichten-Digest des entschlüsselten Zufallswertes r und vergleicht das Ergebnis mit dem von B erhaltenen h(r).
An diesem Punkt ist die Zufallszahl ein sowohl A als auch B bekanntes gemeinsames Geheimnis.
Um das Protokoll zu beenden, gibt A die Zufallszahl an B zurück, um zu beweisen, daß A das Geheimnis kennt. Sobald A die Enthüllung liefert, ist die Vertraulichkeit der Zufallszahl natürlich verloren. B validiert den Beweis von A, indem das von A zurückgegebene Geheimnis auf Gleichheit mit dem ursprünglich von B erzeugten geprüft wird.
Ein zweites Beispiel für ein asymmetrisches Vertraulichkeitsprotokoll ist ein probabilistisches Verschlüsselungsschema, wie zum Beispiel das. probabilistische Blum-Goldwasser-Verschlüsselungsverfahren mit öffentlichen Schlüsseln. Hierbei verwendet der Verschlüsselungs- oder Entschlüsselungsmechanismus Zufallszahlen oder andere probabilistische Mittel.
Bei allen asymmetrischen Vertraulichkeitsprotokollen kann jeder Kunde sein öffentliches Schlüsselmaterial in ein Verzeichnis mit öffentlichem Zugang aufgeben, ohne das entsprechende private Schlüsselmaterial zu kompromittieren. Der Kunde solle gewöhnlich sein privates Schlüsselmaterial als ein enges Geheimnis schützen; andernfalls kann das kryptographische System die Korrektheit (Vertraulichkeit) nicht garantieren. Der beste bekannte Mechanismus zum Schutz eines persönlichen privaten Schlüsselmaterials ist durch die Verwendung einer Chipkarte. In diesem Fall ist die Chipkarte eine Einrichtung ohne Schnittstelle zum Freigeben von privatem Schlüsselmaterial (in einer nicht kryptographisch geschützten Form).
Obwohl Chipkarten den besten Schutz liefern, können soziale Faktoren des elektronischen Handels eine Rolle bei der Sicherstellung des Schutzes von privatem Schlüsselmaterial spielen. Eine der signifikanten Schwierigkeiten bei asymmetrischen Verschlüsselungsdiensten ist die Authentifizierung. Wenn zum Beispiel A sein öffentliches Schlüsselmaterial in ein öffentliches Verzeichnis aufgibt, stellt sich die Frage, wie B die Gültigkeit bewertet? Das heißt, ein unrechtmäßiger Kopierer kann versuchen, sich als A auszugeben, aber sein eigenes Schlüsselmaterial aufgeben. Bestimmte kommerzielle Organisationen lösen dieses Problem, indem sie als Zerfifizierungsbehörden (CA) handeln. Für eine (mögliche) Gebühr vermittelt die CA Identifizierungsmaterial von potentiellen Kunden, wie zum Beispiel einen Führerschein oder Paß eines Autofahrers. Nach der Validierung. des Identifizierungsmaterials gibt die CA das öffentliche Schlüsselmaterial in ein öffentliches Verzeichnis auf und die CA unterzeichnet ein Zertifikat (unter Verwendung einer digitalen Signatur mit dem privaten Schlüssel der CA); das das öffentlichen Schlüsselmaterial des Kunden hält. Standartisierte Dienste, wie zum Beispiel X.500, können angepaßt werden, um die Verwendung von Verzeichnissen, die öffentliches Schlüsselmaterial enthalten, zu erleichtern.
Nachdem ein Kunde sein öffentliches Schlüsselmaterial auf die CA aufgegeben hat, wird sich der Kunde wahrscheinlich sehr anstrengen, sein privates Schlüsselmaterial zu schützen. Wenn das private Schlüsselmaterial des Kunden unwissentlich kompromitiert werden würde, dann hätte bei bestimmten asymmetrischen Schlüsseln der Kunde Grund für starke . Besorgnis. Zum Beispiel könnten im Fall von RSA-Schlüsseln, die auch für digitale Signaturen verwendet werden können, vernetzte Vertreiber potentiell elektronische Handelstransaktionen autorisieren.
Die Erfindung wird durch die Merkmale der beigefügten unabhängigen Ansprüche 1,20 und 21 definiert. Weitere Aspekte der Erfindung werden durch die Merkmale der abhängigen Ansprüche 2 bis 19 und 22 bis 38 definiert.
Kurze Beschreibung der Zeichnungen
1 ist ein Flußdiagramm eines Kaufprotokolles, das verwendet wird, wenn ein Kunde Software kaufen möchte, die durch einen erfindungsgemäßen Schutzmechanismus geschützt ist.
2 ist ein Blockschaltbild der Softwarekomponenten, die in der Maschine des Kunden installiert werden müssen, damit der Kunde die geschützte Software ausführen kann.
3 ist ein Flußdiagramm der Funktionsweise des Schutzmechanismus in der geschützten Software.
4 ist ein Flußdiagramm der Funktionsweise eines zur Erzeugung von Nonces verwendeten Zufallszahlengenerators.
Beschreibung einer Ausführungsform der Erfindung
Es wird nun ein erfindungsgemäßer Schutzmechanismus an Hand eines Beispieles mit Bezug auf die beigefügten Zeichnungen beschrieben.
Das Kaufprotokoll
1 zeigt ein Kaufprotokoll, das verwendet wird, wenn ein Kunde 102 Software kaufen möchte, die durch einen erfindungsgemäßen ECP-Mechanismus geschützt ist. Der Vertreiber 101 besitzt öffentliches und privates Schlüsselmaterial, das für digitale Signaturen verwendet wird; und jeder potentielle Kunde 102 besitzt öffentliches und privates Schlüsselmaterial, das für asymmetrische Vertraulichkeitsbeweisprotokolle verwendet wird. Jeder Teilnehmer stellt sein öffentliches Schlüsselmaterial anderen Teilnehmern zur Verfügung, hält aber sein privates Schlüsselmaterial geheim.
Im Schritt 1 erhält der Kunde 102 die geschützte Software 103 von dem Vertreiber 101, indem er die Software von einem Netzwerk-Bulletin-Board herunterlädt.
Ein später ausführlicher zu beschreibender Abfragemechanismus 24 (siehe 2) wird dergestallt in die geschützte Software 103 eingebettet, daß ein potentieller Angreifer nicht leicht den Abfragemechanismus 24 von dem geschützten Programm trennen kann. Der Angreifer müßte den Code auseinanderbauen und den Abfragemechanismus manuell entfernen. In dem Abfragemechanismus 24 ist das öffentliche Schlüsselmaterial des Vertreibers eingebettet. Wie beschrieben werden wird, verhindert der Abfragemechänismus 24, daß der Kunde die Software in dieser Phase ausführt. Das gesamte geschützte Programm, einschließlich des Abfragemechanismus, wird unter Verwendung des privaten Schlüsselmaterials des Vertreibers signiert.
Im Schritt 2 sendet der Kunde 102 ein Registrationspaket 104 per E-mail zu dem Vertreiber 101. Das Reg strationspaket 104 enthält eine Referenz auf ein öffentliches Verzeichnis, das das öffentliche Schlüsselmaterial des Kunden hält.
Im Schritt 3 findet der Software-Vertreiber 101 das öffentliche Schlüsselmaterial des Kunden und bettet das öffentliche Schlüsselmaterial des Kunden in eine Schlüsseldatei 105 ein und sendet die Schlüsseldatei 105 per E-mail zu dem Kunden 102. Nachdem der Kunde 102 die Schlüsseldatei 105 installiert hat, erlaubt der Schutzmechanismus dem Kunden 102, die geschützte Software 103 auszuführen, solange der Kunde über einen asymmetrischen Vertraulichkeitsbeweis beweisen kann, daß er Zugang zu dem privaten Schlüsselmaterial des Kunden hat.
Die Erzeugung der Schlüsseldatei 105 wird von einem Schlüsseldateigenerator durchgeführt, bei dem es sich um ein Programm handelt, das beim Vertreiber ausgeführt wird. Der Vertreiber 101 muß Sorgfalt walten lassen, um dieses Programm zu schützen.
Bei der. Verwendung des Schlüsseldateigenerators gibt ein Bediener die folgenden Informationen ein:
Vertreibername: Vertreibername ist der Name der Firma des Vertreibers.
Vertreiberpaßwort: Vertreiberpaßwort ist das Paßwort, das das private Schlüsselmaterial der Vertreiberfirma entriegelt. Firmenangestellte, die das Paßwort nicht kennen, können keine Schlüsseldateien erzeugen.
Kundenname: Der Kundenname ist der distinguierte Name eines Kunden (definiert in [6]), für den eine Schlüsseldatei erzeugt werden soll. Der Name indiziert in eine Datenbank von öffentlichem Schlüsselmaterial.
Schlüsseldateiname: Der Schlüsseldateiname ist der Name einer neuen Schlüsseldatei.
Nach dem Erhalt dieser Informationen baut der Schlüsseldateigenerator eine Schlüsseldatei 105 auf, die das öffentliche Schlüsselmaterial des Kunden enthält. Teile der Schlüsseldatei 105 erscheinen dem Kunden 102 als eine völlig zufällige Sequenz von Werten.
Der Aufbau der Schlüsseldatei 105 umfaßt die folgenden Operationen.
Als erstes erzeugt der Schlüsseldateigenerator eine Datei und fügt das öffentliche Schlüsselmaterial des Kunden zusammen mit tausenden von Tarnungsbit in die Datei ein. Bei dem vorliegenden Beispiel enthält jede Schlüsseldatei 105 ungefähr 480 000 Tarnungsbit. Diese Anzahl von Bit stellt eine signifikante Menge an Tarnungsmaterial dar, paßt jedoch in eine Standard-Email-Nachricht.
Jede Schlüsseldatei 105 speichert das öffentliche Schlüsselmaterial des Kunden an einer anderen Speicherstelle. Zusätzlich sind in jede Schlüsseldatei 105 verschlüsselte Kundeninformationen eingebettet, ohne daß der erforderliche Verschlüsselungsschlüssel enthüllt wird. Durch diese verschlüsselten Kundeninformationen kann ein Softwarevertreiber leicht den Eigentümer einer Schlüsseldatei 105 identifizieren, falls die Schlüsseldatei 105 an einem öffentlichen Ort, wie zum Beispiel einem Bulletin-Board, erscheint. Die Schlüsseldatei (oder Teile der Schlüsseldatei) 105 wird dann von dem Schlüsseldateigenerator mehrere Male mit verschiedenen Algorhythmen verschlüsselt und neu verschlüsselt. Als letztes signiert der Schlüsseldateigenerator die Schlüsseldatei 105 unter Verwendung des privaten Schlüsselmaterials des Vertreibers durch Anwenden eines digitalen Signaturalgorhythmus.
Eine Schlüsseldatei wird als validiert bezeichnet, wenn das Abfragemittel die Signatur des Vertreibers unter Verwendung der in der Binärdatei des Abfragemittels gespeicherten öffentlichen Schlüsselmaterials validieren und auf das in der Schlüsseldatei gespeicherte entschlüsselte öffentliche Schlüsselmaterial zugreifen kann.
Die Kunden Software
2 zeigt die Softwarekomponenten, die in der Maschine des Kunden, einem Computer, installiert sein müssen, damit der Kunde 102 die geschützte Software 103 ausführen kann. Diese bestehen aus einem Schutzserver 20. Außerdem sind die Schlüsseldatei 105 und die geschützte Software 103 gezeigt. Die kopiergeschützte Software 103 enthält einen Abfragemechanismus 24.
Der Schutzserver 20 ist ein Programm, das der Kunde 102 ausführt, wenn das System zu Anfang gebootet wird. Der Kunde 102 aktiviert das System durch Einlegen einer Diskette, die eine verschlüsselte Kopie des privaten Schlüsselmaterials des Kunden enthält. Der Schutzserver 20 fordert den Kunden 102 dann zur Eingabe einer Paßphrase auf, die zur Entschlüsselung der Diskette verwendet wird. Die Schutzsoftware wird nicht weiter ausgeführt, wenn der Kunde nicht. die korrekte Paßphrase eingeben kann. Der Schutzserver 20 wird dann im Hintergrund ausgeführt und wartet auf Anforderungen zur Ausführung des asymmetrischen Vertraulichkeitsprotokolls.
Es sollte beachtet werden, daß der Schutzserver 20 niemals das private Schlüsselmaterial des Kunden aus seiner Prozeßgrenze heraus freigibt. Der Schutzserver 20 verwendet Schutzvorrichtungen des Betriebssystems, um seine eigene Integrität sicherzustellen. Der Schutzserver 20 wird in seinem eigenen Adreßraum ausgeführt und kommuniziert mit externen Prozessen.
Funktionsweise des Schutzmechanismus
3 zeigt die Funktionsweise des Schutzmechanimus. Dieser wird ausgeführt, wenn der Kunde zu Anfang versucht, die geschützte Software 103 auszuführen, und wird außerdem periodisch während der Ausführung der geschützten Software 103 wiederholt. Durch Senden einer neuen Abfrage und Warten auf eine Antwort, die validiert werden kann.
(Box 31) Wenn der Abfragemechanismus 24 den Prozeß startet, greift der Abfragemechanismus 24 auf die der geschützten Software 103 zugeordnete Schlüsseldatei 105 zu und ruft eine Signaturvalidierungsfunktion in dem Abfragemechanismus 24 auf, um die Vertreibersignatur der Schlüsseldatei 105 unter Verwendung des öffentlichen Schlüsselmaterials des Vertreibers, das in den Abfragemechanismus 24 eingebettet ist, zu validieren. Diese Validierung der Schlüsseldateisignatur stellt sicher, daß ein Angreifer die Schlüsseldatei 105 oder ihre digitale Signatur nicht modifizieren kann, ohne zusätzlich den Abfragemechanismus 24 zu modifizieren. Vertreiber können wahlweise diesen Schutz durch Verwendung zusätzlicher proprietärer Verteidigungslinien ergänzen. Wenn die Schlüsseldatei 105 modifiziert worden ist, läßt der Abfragemechanismus 24 das Programm hängen oder stört die normale Programmausführung anderweitig.
Vorausgesetzt, daß die Signatur der Schlüsseldatei 105 validiert wird, analysiert der Abfragemechanismus 24 dann die Schlüsseldatei 105 unter Verwendung eines proprietären vertreiberspezifischen Algorhythmus, um das öffentliche Schlüsselmaterial des Kunden in der Schlüsseldatei 105 zu finden, und extrahiert das öffentliche Schlüsselmaterial des Kunden.
Das Abfrage- und das Antwortmittel führen das nachfolgend dargestellte asymmetrische Vertraulichkeitsprotokoll aus.
A•B:h®,B,P_A(r,$)
A•B:r
Der Ausdruck verwendet die folgende Notation:
– Das Abfragemittel (der Abfragemechanismus) 24 mit der Bezeichnung B (verzeichnet außerdem die Identität von B, z. B. „kopiergeschütztes Programm x")
– Das Antwortmittel (der Schutzserver) 20 mit der Bezeichnung A (bezeichnet auch die Identität von A, z. B. „Schutzserver, Version 1". – r bedeutet eine Zufallszahl, die als Nonce verwendet wird – h(r) ist ein Nachrichten-Digest des Nonce – P_A(r,B) ist eine Verschlüsselung des Nonce und der Identität von B unter Verwendung des öffentlichen Schlüsselmaterials von A.
(Box 31) Das Abfragemittel 24 der geschützten Software 103 erzeugt ein nicht erratbares Nonce (eine Zufallszahl). Als nächstes berechnet der Abfragemechn smus h(r) (das Nachrichten-Digest von r).
Der Abfragemechanismus 24 ruft dann eine Verschlüsselungsfunktion in dem Abfragemechanismus 24 auf, um das Nonce und die Identität von B mit dem öffentlichen Schlüsselmaterial des Kunden zu verschlüsseln. Der Abfragemechanismus leitet das Nachrichten-Digest des Nonce h(r), die Identität von B und das Ergebnis der Verschlüsselung mit einer Anforderung zur Teilnahme an einem asymmetrischen Vertraulichkeitsbeweis zu dem Schutzserver 20 weiter.
(Box 32) Wenn der Schutzserver 20 die Anforderung empfängt, entschlüsselt er zuerst den verschlüsselten Teil der Nachricht unter Verwendung des privaten Schlüsselmaterials des Kunden.
Als nächstes validiert der Schutzserver h(r) im Vergleich zu dem entschlüsselten Wert.
Als nächstes validiert der Schutzserver 20, daß seine Identität B in der Nachricht und in dem entschlüsselten Wert korrekt erscheint.
Wenn eine etwaige Validierung erfolglos bleibt, gibt der Schutzserver 20 einen Mißerfolg zurück, ohne das entschlüsselte Nonce zurückzugeben. Wenn die Validierung erfolgreich ist, gibt der Schutzserver 20 jedoch das entschlüsselte Nonce zurück.
(Box 33) Der Abfragemechanismus 24 vergleicht das empfangene entschlüsselte Nonce mit dem Nonce, das der Abfragemechanismus 24 ursprünglich verschlüsselt hat. Wenn sie nicht übereinstimmen, läßt der Abfragemechanismus 24 das geschützte Programm hängen oder stört die normale Programmausführung anderweitig.
Es ist also ersichtlich, daß das geschützte Programm nur dann weiter normal ausgeführt wird, wenn der Kunde über das ordnungsgemäße private Schlüsselmaterial und die ordnungsgemäße Schlüsseldatei 105 verfügt.
Der Nonce-Generator
Die Erzeugung eines Nonce wird von einem in dem Abfragemechanismus 24 enthaltenen Nonce-Generator durchgeführt. Die Funktionsweise des Nonce-Genetators ist wie folgt.
Als erstes fragt der Nonce-Generator eine große Anzahl von Systemparametern ab, z. B. die Systemzeit, den verbleibenden Platz in der Seitentabelle, die Anzahl logischer Plattenlaufwerke, die Namen der Dateien in dem Verzeichnis des Betriebssystems usw.
Als nächstes baut der Nonce-Generator unter Verwendung eines Zufallszahlengenerators eine Zufallszahl auf. Der Zufalhszahlengenerator besteht aus zwei Prozeß-Threads, die hier als Thread 1 und Thread 2 bezeichnet werden. 4 zeigt die Funktionsweise von Thread 1, bei dem es sich um den Hauptthread des Zufallszahlengenerators handelt.
(Box 51) Thread 1 erzeugt zuerst eine Datenstruktur value list zum Halten einer Liste von Zählerwerten. Die Liste ist zu Anfang leer.
(Box 52) Thread 1 setzt einen aktuellen Zählerwert auf Null und setzt ein done_test-flag auf FALSE.
(Box 53) Thread 1 erzeugt dann Thread 2. Thread 2 gibt einen asynchronen Plattenzugriff auf und schläft dann, bis der Plattenzugriff abgeschlossen ist. Wenn der Plattenzugriff abgeschlossen ist, setzt Thread 2 das Flag done_test auf TRUE. Man beachte, daß Thread 1 und Thread 2 sich das Flag done_-test teilen.
(Box 54) Thread 1 erhöht den Zählerwert um eins.
(Box 55) Thread 1 prüft dann, ob das done_test-Flag nun TRUE ist, wodurch angezeigt wird, daß der von Thread 2 eingeleitete Plattenzugriff abgeschlossen ist. Wenn das done_test-Flag FALSE ist, dann kehrt der Thread zur Box 54 zurück. Somit ist ersichtlich, daß, während auf den Abschluß des Plattenzugriffs gewartet wird, Thread 1 den Zählerwert dauernd erhöht.
(Box 56) Wenn das done_test-Flag TRUE ist, beendet Thread 1 den Thread 2 und sichert den Zählerwert in der ersten freien Speicherstelle in value_list.
(Box 57) Thread 1 ruft dann eine Stautest-Funktion. auf, die den Grad der Zufälligkeit der Zählerwerte (oder Teile von Zählerwerten, z. B. Bit niederer Ordnung), die in value_list gesichert wurden, schätzt. Diese Funktion kann den Chiquadrattest, den Kolmogorov-Smirnov-Test oder den Seriell-Korrelation-Test verwenden, die in [3] beschrieben werden. Die Statstest-Funktion kann möglicherweise optimiert werden, um sicherzustellen, daß keine komplizierten Berechnungen für jeden Plattenzugriff wiederholt werden. Die Statstest-Funktion gibt einen Wert zurück, der angibt, wieviele Bit niederer Ordnung jedes gesicherten Zählerwertes als zufällig angesehen werden sollten.
(Box 58) Thread 1 vergleicht den Wert, der von der Statstest-Funktion bei der Kombination mit der Länge von value_list zurückgegeben wird, mit einem vorbestimmten Schwellenwert, um zu bestimmen, ob nun genug Zufallsbit erzeugt worden sind. Wenn noch nicht genug Zufallsbit erzeugt worden sind, kehrt der Prozeß zu der obigen Box 52 zurück, um so einen weiteren Zählerwert zu erzeugen und zu sichern.
(Box 59) Wenn die erforderliche Anzahl von Zufallsbit erzeugt worden ist, extrahiert Thread 1 die spezifizierte Anzahl von Bit niederer Ordnung aus jedem Zählerwert in value_list und gibt diese Bitsequenz als die Ausgangszufallszahl aus.
Kurz gefaßt ist ersichtlich, daß der Zufallszahlengenerator die Unvorhersehbarkeit der Zeitsteuerung einer Reihe von Plattenzugriffen als Quelle von Zufälligkeit bei der Erzeugung von Nonces ausnutzt (siehe [4]). Durch Erzeugen neuer Threads bei jedem Plattenzugriff nutzt der Zufallszahlengenerator außerdem Unvorhersehbarkeiten in der Funktionsweise des Schedulers des Betriebssystems als zweite Quelle von Zufälligkeit aus.
Die von der Statstest-Funktion durchgeführte Analyse gestattet dem Zufallszahlengenerator, sich für Prozessoren und Platten mit beliebiger Geschwindigkeit selbst abzustimmen, indem die Anzahl von Bit niederer Ordnung jedes gesicherten Zählerwertes zur Rückkehr berechnet wird. Zum Beispiel wird ein System mit einer Plattenzugriffszeit mit hoher Varianz mehr Zufallsbit pro Plattenzugriff erzeugen als ein System mit einer Plattenzugriffszeit mit niedriger Varianz. Zum Beispiel. erzeugt das System im Fall einer Platte des Typs Quantum 1080s (mittlere Schreibzeit 6 ms) und eines 486-Prozessors mit 66 Mhz ungefähr 45 Bit pro Sekunde. Als Alternative kann die Anzahl von Bit pro Plattenzugriff fest codiert und eine De-Skewing-Technik verwendet werden, um einen guten Zufälligkeitsgrad sicherzustellen.
Der Nonce-Generator fragt außerdem das Betriebssystem ab, um sicherzustellen, daß es jeden Plattenzugriff auf eine tatsächliche Platte ausgibt. Das letzte Ausgabe-Nonce wird durch Kombinieren der Ausgangszufallszahl aus dem Zufallszahlengenerator mit dem Ergebnis der Abfrage der Systemparameter wie oben beschrieben unter Verwendung eines Nachrichten-Digest gebildet.
Der obenbeschriebene Nonce-Generator arbeitet am besten, wenn er auf einem Betriebssystem ausgeführt wird, das direkten Zugriff auf die Platte bereitstellt, wie zum Beispiel Windows 95 oder Windows NT 4,0. Bei einem solchen Betriebssystem gestatten spezielle Aufrufe des Betriebssystems, die im Benutzerraum ausgeführten Programmen verfügbar sind, einem Programm, den internen Puffermechanismus des Betriebssystems zu umgehen und direkt auf die Platte zu schreiben. Die meisten Programme nutzen diese speziellen Betriebssystemaufrufe nicht aus, da sie relativ ineffizient und schwierig zu benutzen sein können. Unter Windows 95 und Windows NT kann ein Programm diese speziellen Aufrufe nur dann verwenden, wenn das Programm auf Daten zugreift, die ein Vielfaches der Sektorgröße der Platte aufweisen, indem das Betriebssystem abgefragt wird.
Wenn das Betriebssystem keinen direkten Zugriff auf die Platte bereitstellt, dann könnte der Abfragemechanismus 24 immer noch den Plattenzeitsteuerungszufallszahlengenerator verwenden. In diesem Fall würde sich die Qualität der erzeugten Werte jedoch mehr auf Unvorhersehbarkeiten in dem Scheduler des Betriebssystems verlassen, anstatt auf die der Plattenzugriffszeit innewohnende Varianz.
Das obenbeschriebene Beispiel der Erfindung nimmt an, daß das Betriebssystem einem Programm gestattet, mehrere Threads in einem einzigen Adreßraum zu erzeugen. Zusätzlich nimmt das Beispiel der Erfindung an, daß das Betriebssystem den Threads gestattet, auf Synchronisationsvar ablen wie zum Beispiel Semaphoren zuzugreifen. Die meisten modernen Betriebssysteme liefern diese Dienste. Das Beispiel der Erfindung verwendet mehrere Threads zur Implementierung, eines Mechanismus, der jede Plattenzugriffszeit quantifiziert. Wenn eine Implementierung der Erfindung jedoch auf einem System ausgeführt werden würde, das keine mehreren Threads oder Synchronisationsvariablen bereitstellt, dann könnte der Nonce-Generator andere Mechanismen einsetzen, z. B. Abfrage eines physikalischen Takts.
Einige mögliche Modifikationen
Der Kunde muß die Software nicht durch Herunterladen der Software von einem Netzwerk-Bulletin-Board erhalten. Der Kunde kann die Software auch auf einer Diskette, einer CD-ROM, einer DVD, einem PC-Kaufhaus, dem Internet oder anderen Verteilungsmedien erhalten.
Als Alternative könnte der Schutzserver 20 auch ein probabilistisches Verschlüsselungsverfahren verwenden, wie zum Beispiel das probabilistische B1um-Goldwasser-Verschlüsselungsschema mit öffentlichen Schlüsseln, um sicherzustellen, daß nur der Kunde das ordnungsgemäße private Schlüsselmaterial besitzt.
Es ist also ersichtlich, daß es gemäß der vorliegenden Erfindung nur wichtig ist, daß ein asymmetrischer Vertraulichkeitsbeweis verwendet wird.
Außerdem kann eine Chipkarte zum Speichern des privaten Schlüsselmaterials des Kunden (oder des privaten Schlüsselmaterials des Vertreibers, das bei der Schlüsseldateierzeugung verwendet wird) oder zum Zugriff darauf verwendet werden. Bei einer solchen Konfiguration mit Chipkartenmöglichkeit kann ein unrechtmäßiger- Kopierer das private Schlüsselmaterial nicht aus der Chipkarte extrahieren, wodurch eine noch größere Verteidigung gegenüber Angriffen bereitgestellt wird. Bestimmte Chipkarten werden erst dann ausgeführt, wenn der Benutzer ein korrektes Paßwort oder eine korrekte persönliche Geheimnummer angibt.
Wahlweise kann dieses vorliegende Beispiel erweitert werden, indem man das Abfragemittel so konstruiert, daß ein interner Timer, z. B. ein Zählthread, oder ein externer Timer, z. B. ein Takt, referenziert wird. Wenn eine im voraus definierte Schwelle endet, bevor das probablistische Beweisprotokoll abgeschlossen ist, dann bleibt die Validierung automatisch erfolglos.
Zusätzlich zu der Implementierung des Kopierschutzes kann man die Erfindung zum Verfolgen von unrechtmäßigen Software-Kopierern verwenden. Der Mechanismus liefert eine exzellente Verfolgbarkeit, ohne daß es notwendig ist, daß jeder Kunde eine einzigartige Version des Programms erhält.
Der Schutzserver 20, der Abfragemechanismus 24 und die geschützte Software 103, die oben beschrieben wurden, können in einer Anzahl verschiedener Konfigurationen eingesetzt werden.
Zum Beispiel:

– Der Schutzserver 20 kann in einem Adreßraum und der Abfragemechanismus 24 und die geschützte Software 103 in einem anderen Adreßraum in einer einzigen Maschine verankert sein.
- Der Schutzserver 20 kann in einem Adreßraum auf einer Maschine verankert sein, und der Abfragemechanismus 24 und die geschützte Software 103 können in einem anderen Adreßraum auf einer anderen Maschine verankert sein.

Außerdem können mehrere Kunden, die jeweils über ihre eigene Kopie des geschützten Softwareartikels verfügen, sich einen gemeinsamen Schutzserver 20 teilen, der auf Abfragen von allen diesen Kopien antwortet.
Eine andere Alternative besteht darin, daß sich mehrere Kunden gemeinsames privates Schlüsselmaterial teilen können. Eine Firma kann eine oder mehrere dieser Einsatzmöglichkeiten benutzen, wenn zum Beispiel Mehrfach-Benutzer-Lizenzierungsfunktionalität konstruiert wird.
Bei einer anderen möglichen Modifikation kann die Schlüsseldatei 105 versteckte Informationen bezüglich der selektieven Aktivierung von Diensten des geschützten Programms 103 erhalten. Zum Beispiel kann die Schlüsseldatei 105 spezifizieren, daß das geschützte Programm 103 die Ausführung eines Druckdienstes gestattet, aber die Ausführung eines Sichern-Auf-Platte-Dienstes sperrt. Als ein weiteres Beispiel kann die Schlüsseldatei 105 ein Ablaufdatum enthalten, das das letzte Datum beschreibt, an dem ein bestimmter Dienst ausgeführt werden kann. Das geschützte Programm 103 würde die Schlüsseldatei 105 lesen, um die Dienste zu bestimmen, die das geschützte Programm 103 ausführen soll. Ein Kunde könnte die Möglichkeit erhalten, mehr Dienste auszuführen, indem eine weitere Schlüsseldatei von dem Vertreiber angefordert wird.
Bei einer weiteren möglichen Modifikation könnte das geschützte Programm das Ergebnis der asymmetrischen Vertraulichkeitsbeweise zu anderen Programmen verteilen. Diese anderen Programme könnten dieses Ergebnis benutzen, um dabei zu helfen, zu bestimmen, ob die anderen Programme mit der Ausführung aufhören sollen oder auf beschränkte Weise ausgeführt werden sollen.
Die folgenden Publikationen werden in dieser Schrift zitiert:
[1] Choudhury et al, Copyright Protection for Electronic Publishing over Computer Networks, IEEE Network, Mai/Juni 1995, Seiten 12–20
[2] A. Menezes, P. Van Oorschot und S. Vanstone, Handbook of Applied Cryptography, CRC Press, Boca Raton, ISBN 0-8493-8523-7, Seiten 405–424, 1997.
[3] D. Knuth, The Art of Computer Programming, Band 2, Sminumerical Algorithms, Addison-Weslez Publishing Co., Reading MA, 2. Auflage, Seiten 38 –73, ISBN 0-201-03822-6.
[4] P. Fenstermacher et at, Cryptographic randomness from air turbulence in disk drives, Advances in Cryptology: Crypto 94, Seiten 114–120. Springer Verlag 1994
[5] R. Rivest, The MD5 message-digest algorithm, RFC 1321, April 1992
[6] ISO/IEC 9594-1, "Information technology – Open Systems Interconnection – The Directory: Overview of concepts, models, and services", International Organiyation for Standardization, Genf, Schweiz, 1995 (entspricht ITU-T Rec. X.509, 1993).

Claims

Computersystem mit einem asymmetrischen kryptographischen Schutzmechanismus zum Schutz von Software, wobei der Schutzmechanismus mindestens ein Abfragemittel (24), das einem geschützten Softwareposten (103) zugeordnet ist, und mindestens ein Antwortmittel mit privatem Schlüsselmaterial, auf das es zugreifen kann, umfaßt, wobei a) das Abfragemittel keinen Zugang zu dem privaten Schlüsselmaterial hat und in ihm gespeichertes öffentliches Schlüsselmaterial verwendet, b) das Abfragemittel und das Antwortmittel jeweils ein Mittel zum Erzeugen von Gemeinsames-Geheimnis-Informationen gemäß einem asymmetrischen Vertraulichkeitsschema umfassen, c) das Antwortmittel ein Mittel umfaßt, das dem Abfragemittel beweist, daß das Antwortmittel Zugang zu dem privaten Schlüsselmaterial hat, indem es unter Verwendung eines asymmetrischen Vertraulichkeitsbeweisschemas einen Dialog mit dem Abfragemittel führt, d) das Abfragemittel ein Mittel umfaßt, das verhindert, daß ein Kunde bestimmte oder alle der Softwareposten benutzt, ohne daß der Beweis erfolgreich ist.
Computersystem nach Anspruch 1 und mit einem Mittel zum Eingeben eines zu schützenden Programms und zum Einbetten mindestens eines Abfragemittels in dieses Programm, wobei das Abfragemittel ein Mittel umfaßt, das – die Gemeinsames-Geheimnis-Informationen gemäß einem asymmetrischen Vertraulichkeitsschema erzeugt, – den Beweis des Antwortmittels, daß das Antwortmittel die Gemeinsames-Geheimnis-Informationen kennt, validiert und verhindert, daß ein Kunde bestimmte oder alle der Softwareposten benutzt, ohne daß der Beweis erfolgreich ist.
Computersystem nach Anspruch 1 oder 2, bei dem das Antwortmittel ein Mittel umfaßt, das dem Abfragemittel beweist, das Antwortmittel das gemeinsame Geheimnis entdeckt hat.
Computersystem nach einem der Ansprüche 1 bis 3, bei dem das Abfragemittel ein Mittel umfaßt, das den Beweis des Antwortmittels, daß das Antwortmittel das gemeinsame Geheimnis entdeckt hat, validiert.
Computersystem nach Anspruch 4, bei dem das Abfragemittel ein Mittel umfaßt, das den Beweis des Antwortmittels, daß das Antwortmittel das gemeinsame Geheimnis entdeckt hat, validiert, indem es eine Demonstration, daß das Antwortmittel den Wert des gemeinsamen Geheimnisses entdeckt hat, validiert.
Computersystem nach einem der Ansprüche 1 bis 5, – wobei das Abfragemittel ein Mittel umfaßt, das Informationen verschlüsselt und dann die verschlüsselten Informationen zu dem Antwortmittel sendet, – wobei das Antwortmittel ein Mittel umfaßt, das die verschlüsselten Informationen entschlüsselt und somit die Gemeinsames-Geheimnis-Informationen erzeugt und dann beweist, daß das Antwortmittel die Gemeinsames-Geheimnis-Informationen kennt.
Computersystem nach einem der Ansprüche 1 bis 5, wobei das asymmetrische Vertraulichkeitsschema das Blum-Goldwasser-Schema ist.
Computersystem nach einem der Ansprüche 1 bis 5, – wobei das Abfragemittel ein Mittel umfaßt, das eine Zufallsabfrage ausgibt, und – wobei die Informationen die Zufallsabfrage umfassen.
Computersystem nach Anspruch 8, wobei das Mittel zum Ausgeben einer Zufallsabfrage ein Mittel zum Erzeugen einer Zufallsabfrage durch wiederholtes Timen von Antworten auf Zugriffe auf Geräte enthält.
Computersystem nach Anspruch 8, wobei das Mittel zum Erzeugen einer Zufallsabfrage ein Mittel zum Forken neuer Threads dergestalt, daß durch Ausnutzen von Unverhersehbarkeiten in dem Scheduler des Betriebssystems ein zusätzlicher Zufälligkeitsgrad in die Zufallsabfrage eingeführt wird, enthält.
Computersystem nach Anspruch 8, wobei das Mittel zum Ausgeben einer Zufallsabfrage ein Mittel zum Durchführen einer statistischen Prüfung zur Bestimmung der durch jeden der Plattenzugriffe erhaltenen Anzahl von Zufallsbit und ein Mittel zum Bewirken einer Wiederholung von Plattenzugriffen, bis eine vorbestimmte Anzahl von Zufallsbit erhalten wurde, enthält.
Computersystem nach einem der Ansprüche 1 bis 11, wobei das Abfragemittel in den geschützten Softwareposten eingebettet ist.
Computersystem nach einem der Ansprüche 1 bis 12, wobei das Abfragemittel das öffentliche Schlüsselmaterial zum Verschlüsseln der Informationen verwendet.
Computersystem nach einem der Ansprüche 1 bis 13, wobei das System eine Schlüsseldatei (105) zum Halten des öffentlichen Schlüsselmaterials enthält.
Computersystem nach Anspruch 14, wobei das in der Schlüsseldatei gehaltene öffentliche Schlüsselmaterial kryptographisch gesichert ist, wodurch es rechnerisch impraktikabel wird, irgendeinen Teil der Schlüsseldatei, darunter das öffentliche Schlüsselmaterial, zu verändern, ohne das Abfragemittel zu veränden.
Computersystem nach, Anspruch 15, wobei die Schlüsseldatei Informationen enthält, die den Kunden identifizieren, an den der geschützte Sof-twareposten geliefert wurde.
Computersystem nach Anspruch 16, wobei die Schlüsseldatei falsche Bit zum Tarnen des darin gehaltenen ersten öffentlichen Schlüsselmaterials enthält.
Computersystem nach Anspruch 16, wobei die Schlüsseldatei Informationen bezüglich der selektiven Aktivierung von Diensten des geschützten Softwarepostens enthält.
Computersystem nach einem der Ansprüche 1 bis 18 mit mehreren geschützten Softwareposten, die jeweils ihr eigenes Abfragemittel aufweisen, und einem einzigen, gemeinsam von allen geschützten Posten benutzten Antwortmittel.
Gebrauch eines Computersystems nach Anspruch 1 bei der Verteilung von Software an mehrere Kunden, wobei jeder Kunde über ein Computersystems nach Anspruch 1 verfügt und eine identische Kopie des geschützten Programms und des Abfragemittels erhält.
Verfahren zum Schutz eines Softwarepostens durch einen asymmetrischen kryptographischen Schutzmechanismus, wobei dem geschützten Softwareposten (103) mindestens ein Abfragemittel (24) zugeordnet ist und mindestens ein Antwortmittel auf privates Schlüsselmaterial zugreift, wobei a) das Abfragemittel keinen Zugang zu dem privaten Schlüsselmaterial hat und in ihm gespeichertes öffentliches Schlüsselmaterial verwendet, b) das Abfragemittel und das Antwortmittel jeweils gemäß einem asymmetrischen Vertraulichkeitsschema Gemeinsames-Geheimnis-Informationen erzeugen, c) das Antwortmittel dem Abfragemittel beweist, daß das Antwortmittel Zugang zu dem privaten Schlüsselmaterial hat, d) das Abfragemittel verhindert, daß ein Kunde bestimmte oder alle der Softwareposten benutzt, ohne daß der Beweis erfolgreich ist.
Verfahren nach Anspruch 21, bei dem das Antwortmittel dem Abfragemittel beweist, daß das Antwortmittel das gemeinsame Geheimnis entdeckt hat.
Verfahren nach Anspruch 21 oder 22, bei dem das Abfragemittel den Beweis des Antwortmittels, daß das Antwortmittel das gemeinsame Geheimnis entdeckt hat, validiert.
Verfahren nach Anspruch 23, bei dem das Abfragemittel den Beweis des Antwortmittels, daß das Antwortmittel das gemeinsame Geheimnis entdeckt hat, validiert, indem es eine Demonstration, daß das Antwortmittel den Wert des gemeinsamen Geheimnisses entdeckt hat, validiert.
Verfahren nach einem der Ansprüche 21 bis 24, – wobei das Abfragemittel Informationen verschlüsselt und dann die verschlüsselten Informationen zu dem Antwortmittel sendet, wobei das Antwortmittel die verschlüsselten Informationen entschlüsselt und somit die Gemeinsames-Geheimnis-Informationen erzeugt und dann beweist, daß das Antwortmittel die Gemeinsames-Geheimnis-Informationen kennt.
Verfahren nach einem der Ansprüche 21 bis 25, wobei das asymmetrische Vertraulichkeitsschema das Blum-Goldwasser-Schema ist.
Verfahren nach einem der Ansprüche 21 bis 26, – wobei das Abfragemittel eine Zufallsabfrage ausgibt und – wobei die Informationen die Zufallsabfrage umfassen.
Verfahren nach Anspruch 27, wobei die Zufallsabfrage durch wiederholtes Timen von Antworten auf Zugriffe auf Geräte erzeugt wird.
Verfahren nach Anspruch 28, wobei die Zufallsabfrage unter Forken neuer Threads erzeugt wird, dergestalt, daß durch Ausnutzen von Unverhersehbarkeiten in dem Scheduler des Betriebssystems ein zusätzlicher Zufälligkeitsgrad in die Zufallsabfrage eingeführt wird.
Verfahren nach Anspruch 28, wobei die Zufallsabfrage unter Durchführung einer statistischen Prüfung erzeugt wird, um die durch jeden der Plattenzugriffe erhaltene Anzahl von Zufallsbit zu bestimmen, und eine Wiederholung von Plattenzugriffen bewirkt wird, bis eine vorbestimmte Anzahl von Zufallsbit erhalten wurde.
Verfahren nach einem der Ansprüche 21 bis 30, wobei das Abfragemittel in den geschützten Softwareposten eingebettet ist.
Verfahren nach einem der Ansprüche 21 bis 31, wobei das Abfragemittel das erste, öffentliche Schlüsselmaterial zur Verschlüsselung der Informationen verwendet.
Verfahren nach einem der Ansprüche 21 bis 32, wobei das erste öffentliche Schlüsselmaterial in einer Schlüsseldatei gehalten wird.
Verfahren nach Anspruch 33, wobei das in der Schlüsseldatei gehaltene erste öffentliche Schlüsselmaterial kryptographisch gesichert ist, wodurch es rechnerisch impraktikabel wird, irgendeinen Teil der Schlüsseldatei, darunter das erste öffentliche Schlüsselmaterial, zu verändern, ohne das Abfragemittel zu veränden.
Verfahren nach, Anspruch 34, wobei die Schlüsseldatei Informationen enthält, die den Kunden identifizieren, an den der geschützte Softwareposten geliefert wurde.
Verfahren nach Anspruch 34, wobei die Schlüsseldatei falsche Bit zum Tarnen des darin gehaltenen ersten öffentlichen Schlüsselmaterials enthält.
Verfahren nach Anspruch 34, wobei die Schlüsseldatei Informationen bezüglich der selektiven Aktivierung von Diensten des geschützten Softwarepostens enthält.
Verfahren nach einem der Ansprüche 21 bis 37 mit mehreren geschützten Softwareposten, die jeweils ihr eigenes Abfragemittel aufweisen, und einem einzigen, gemeinsam von allen geschützten Posten benutzten Antwortmittel.