DE69724235T2

DE69724235T2 - Computersystem und Verfahren zum Schutz von Software

Info

Publication number: DE69724235T2
Application number: DE69724235T
Authority: DE
Inventors: Dr. Glenn Benson
Original assignee: Siemens AG
Current assignee: Siemens AG
Priority date: 1997-05-28
Filing date: 1997-05-28
Publication date: 2004-02-26
Anticipated expiration: 2017-05-29
Also published as: EP0881559B1; US6047242A; DE69724235D1; EP0881559A1; CN1165849C; CN1207530A

Description

Allgemeiner Stand der Technik
Die vorliegende Erfindung betrifft Mechanismen zum Schutz von Software vor unautorisierter Benutzung und insbesondere unautorisiertem Kopieren und Lizenzverletzungen.
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 Softwarevertreiber 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.
– Es sollte verhindert werden, daß Kunden ohne gültige Lizenz 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 Virusshutzmaß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 oben beschriebenen 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, symmetrische Kryptographie und die probabilistische Verschlüsselung, wie zum Beispiel das probabilistische Blum-Goldwasser-Verschlüsselungsschema findet sich in [2].
Eine Übersicht über digitale Signaturschemata (z. B. Rivest-Shamir-Adleman usw.) (RSA) und eine formale mathematische Definition digitaler Signaturen findet sich in [2].
Ein Beispiel für eine Nachrichten-Digest-Funktion (die auch als einseitige Hash-Funktion bekannt ist) findet sich in MD5 [6]. Es ist rechnerisch impraktikabel oder sehr schwierig, die Umkehrung eines Nachrichten-Digest zu berechnen.
Der Chiquadrattest, der Kolmogorov-Smirnov-Test und der Seriell-Korrelations-Test werden in [3] beschrieben.
In [4] wird kryptographische Zufälligkeit aus Luftturbulenz in Plattenlaufwerken beschrieben.
Eine Übersicht über verschiedene probabilistische Beweisschemata, wie zum Beispiel Null-Kenntnis-Beweisschemata (z. B. die Schemata nach Feige-Fiat-Shamir, Guillou-Quisquater, Blum-Feldmann-Micali, Brassard, Crepau usw.) oder Zeugen-Verbergungsbeweisschemata (z. B. das Schema nach Feige-Shamir usw.) finden sich in [2].
Die Aufgabe der Erfindung ist die Bereitstellung eines verbesserten ECP-Mechanismus, der den größten Teil oder sogar alle der oben beschriebenen Beispielanforderungen erfüllen kann.
Ein Speichergerät ist ein beliebiger Mechanismus, der Daten speichern und die Daten oder Informationen über die Daten nachfolgend bereitstellen kann. Beispiele für praktische Speichergeräte sind Chipkarten, CD-Roms, digitale Videoplatten und Disketten.
In [2] werden Zertifikate, Zertifikathierarchien, Ketten von Zertifikaten, Zertifikattopologien, Zertifikationswege und Zertifikationsbehörden besprochen. Ein Wurzelzertifikat (das auch als Zertifikatsbehördenzertifikat bekannt ist) ist ein Zertifikat, das den öffentlichen Schlüssel der Zertifizierungsbehörde hält. In der Regel werden Wurzelzertifikate unter Verwendung des privaten Schlüssels der Zertifikatbehörde signiert. Ein absteigendes Zertifikat ist ein Zertifikat, das über einen Zertifikationsweg von dem Wurzelzertifikat aus erreicht (validiert) werden kann.
Lizenzierte Software darf nur Betriebsmittel gemäß der Softwarelizenz benutzen. Zum Beispiel kann es eine Softwarelizenz Software gestatten, physisch auf einem gemeinsam genutzten Speichergerät verankert zu sein, es aber der Software verbieten, gleichzeitig auf mehreren Maschinen ausgeführt zu werden. In diesem Fall ist das „Betriebsmittel" eine Maschine, die die Software ausführt. Ein weiteres, Beispiel für ein Betriebsmittel ist eine Datei. In diesem Fall könnte der Lizenzserver potentiell die Zugangssteuerliste einer speziellen Datei modifizieren, um lizenzierten Programmen die Möglichkeit zu geben, auf die spezielle Datei zuzugreifen.
Die Binärdatei eines Programms enthält eine Folge von Anweisungen, die ein Computer befolgt, wenn der Computer das Programm ausführt.
Bei einem Wahl-Klartext-Angriff wählt der Gegner Klartext und erhält dann entsprechenden chiffrierten Text. Danach verwendet der Gegner etwaige abgeleitete Informationen, um Klartext wiederzugewinnen, der dem zuvor nicht gesehenen chiffrierten Text entspricht [2].
Ein adaptiver Wahl-Klartext-Angriff ist ein Wahl-Klartext-Angriff, bei dem die Wahl des Klartext von dem aus den vorherigen Ergebnissen empfangenen chiffrierten Text abhängen kann [2].
Ein Null-Kenntnis-Beweisprotokoll ist eine Art von asymmetrischem Verfahren, das sich besonders gut für den Kopierschutz und Lizenzierung eignet. Ein Null-Kenntnis-Beweis erleidet keine Verschlechterung der Sicherheit bei wiederholter Verwendung von Wahl-Text- Angriffen [und ein Null-Kenntnis-Beweis widersteht diesen]. Diese Eigenschaften sind besonders für den Kopierschutz und die Lizenzierung wünschenswert, da sie einen exzellenten Schutz von privatem Schlüsselmaterial bieten. Man nehme zum Beispiel an, daß das private Schlüsselmaterial auf einer Chipkarte gespeichert wurde. In diesem Fall könnte der Kunde die Chipkarte einer Maschine zur Verfügung stellen, ohne sich um einen Angriff von einem Trojanisches-Pferd- oder anderem Programm mit böser Absicht zu sorgen. Ein Trojanisches Pferd könnte zum Beispiel nicht wiederholt unter Verwendung gewählter Fragen die Chipkarte abfragen, um Informationen zu erhalten, die für eine nachfolgende Kryptoanalyse nützlich wären.
Ein Null-Kenntnis-Beweisprotokoll widersteht sowohl Wahl-Klartext-Angriffen als auch adaptiven Wahl-Klartext-Angriffen.
Als ein Beispiel für einen Null-Kenntnis-Beweis betrachte man das Null-Kenntnis-Beweisprotokoll nach Guillou-Quizquater (GQ), bei dem zwei Teilnehmer A und B auftreten, wobei A das private Schlüsselmaterial besitzt, zu dem B keinen Zugang hat. A beweist B, daß A Zugang zu dem privaten Schlüsselmaterial hat. Das GQ-Beweisprotokoll wird nachfolgend beschrieben.
Im folgenden wird angenommen, daß ein RSA-Schlüsselpaar wie in [2] definiert vorliegt. In der folgenden Beschreibung wird die Notation aus [2] verwendet. Bestimmte Aspekte dieser Notation sind: der öffentliche RSA-Schlüssel ist (n,e), der private RSA-Schlüssel ist d, gcd(e,Φ) = 1, Φ = (p – 1)(q – 1), und n = p·q.
Berechnung von Systemparametern:

a. Unter Verwendung der Primfaktorzerlegung p und q, die sich für die Verwendung bei der Berechnung eines RSA-artigen Schlüsselpaars eignet, Berechnung von n = p·q und Φ = (p – 1)(4 – 1).
b. A definiert einen öffentlichen Exponenten v ≥ 3 mit gcd(v,Φ) = 1, wobei gcd der größte gemeinsame Teiler ist.
c. A berechnet einen privaten Exponenten s = ν^– ¹(mod Φ)
d. Systemparameter (v, n) werden als das öffentliche Schlüsselmaterial zur Verfügung gestellt.

Berechnung von Benutzerparametern:

a. A wählt und veröffentlicht eine wohlbekannte Identität I und die redundante Identität J = f(I), die 1 < J < n erfüllt, unter Verwendung einer bekannten Redundanzfunktion f. Eine Redundanzfunktion f ist zum Beispiel die Redundanzabbildung der Vorverarbeitungsstufe von ISO/IEC 9796 [6].
b. A behält als das private Schlüsselmaterial s_A = J^–S (mod n).

Das GQ-Schlüsselpaar ist (privater Schlüssel = s_A) und (öffentlicher Schlüssel = (ν,n)). A gibt I, f und J = f(I) B bekannt. B validiert, daß J = f(I) (Box 33).
Die Protokollnachrichten des GQ-Beweisprotokolls sind nachfolgend angegeben:

– A → B: I,x = r^ν(mod n) (1)
– B → A: e (mit 1 ≤ e ≤ v) (2)
– A → B: y = r·s e / A(mod n) (3)

A beweist B seine Identität durch t Ausführungen der folgenden Schritte, wobei B die Identität von A nur dann annimmt, wenn alle t Ausführungen erfolgreich sind (Box 34).

a. A wählt eine geheime zufällige ganze Zahl r (die Verpflichtung), 1 ≤ r ≤ n – 1, und berechnet (den Zeugen) x = r^ν(mod n).
b. A sendet das Paar von ganzen Zahlen (I,x) zu B
c. B wählt und sendet eine zufällige ganze Zahl e (die Frage) zu A, 1 ≤ e ≤ ν
d. A berechnet und sendet zu B (die Antwort) y = r·s e / A (mod n)

B empfängt y, konstruiert J aus I unter Verwendung von f, berechnet z = J^e·y^ν(mod n) und nimmt den Beweis der Identität von A an, wenn sowohl z = x und z ≠ 0 gilt.
Z_n ist die Menge von ganzen Zahlenmodulo n Z * / n = {x ∈ Z_n|gcd(x,n) = 1}
Kurze Darstellung der Erfindung
Die vorliegende Erfindung verwendet ein Protokoll, das asymmetrische kryptographische Verfahren einsetzt. Beispiele für asymmetrische kryptographische Verfahren sind asymmetrische Vertraulichkeit, digitale Signaturen und von probabilistischen Beweisen.
Ein asymmetrisches kryptographisches Verfahren umfaßt öffentliches Schlüsselmaterial und entsprechendes privates Schlüsselmaterial. Es ist rechnerisch impraktikabel, das private Schlüsselmaterial zu berechnen, wenn außer dem entsprechenden öffentlichen Schlüsselmaterial keine weiteren Informationen gegeben sind. Bei der vorliegenden Erfindung wird die asymmetrische Kryptographie bei Wechselwirkungen zwischen zwei Teilnehmern A und B verwendet. A beweist B, daß er Zugang zu privatem Schlüsselmaterial hat, und B validiert den Beweis. A enthüllt B nicht das private Schlüsselmaterial.
Einige beispielhafte asymmetrische kryptographische Verfahren werden nachfolgend beschrieben.
Eine digitale Signatur ist ein elektronisches Analog einer handschriftlichen Signatur. Ein Beweis mit digitaler Signatur umfaßt mindestens zwei Teilnehmer A und B. Nachdem er sein öffentliches Schlüsselmaterial an einen öffentlichen Ort aufgegeben hat, verschlüsselt A die Nachricht unter Verwendung des privaten Schlüsselmaterials. Da beliebige Personen auf das öffentliche Schlüsselmaterial zugreifen können, besteht keine Nachrichtengeheimhaltung. Da A der einzige Kunde mit Zugang zu dem privaten Schlüsselmaterial ist, kann niemand anderes „die Signatur von A fälschen", indem er die Verschlüsselung durchführt. Eine beliebige Person kann die Signatur von A unter Verwendung des öffentlichen Schlüsselmaterials validieren.
Ein asymmetrischer Vertraulichkeitsbeweis umfaßt mindestens zwei Teilnehmer A und B. A besitzt privates Schlüsselmaterial und B hat keinen Zugang zu dem privaten Schlüsselmaterial von A, wenn nicht B selbst das private Schlüsselmaterial enthüllt (was B nicht tun sollte). Am Anfang haben A und B kein gemeinsames Geheimnis. Während des Verfahrens wird A und B ein gemeinsames Geheimnis bekannt.
Ein Beispiel für einen asymmetrischen Vertraulichkeitsbeweis ist die Verschlüsselung mit öffentlichem Schlüssel. Wie in dem nachfolgend dargestellten asymmetrischen Vertraulichkeitsprotokoll beweist A B, daß A Zugang zu dem privaten Schlüsselmaterial hat.
A ← B: h(r), B, PA(r,B) A → B: r
Das oben beschriebene 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 obenbeschriebenen 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 daß 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. Man sollte die probabilistische Verschlüsselung mit öffentlichen Schlüsseln nicht mit probabilistischen Beweisen, z. B. Null-Kenntnis-Beweisen verwechseln. Im ersten Fall dienen probabilistische Mittel zur Ausführung des Verschlüsselungsalgorithmus. Im zweiten Fall dienen probabilistische Mittel zum Definieren eines Versicherungsgrades. Probabilistische Beweise werden nachfolgend beschrieben.
Ein probabilistischer Beweis umfaßt mindestens zwei Teilnehmer A und B. A besitzt privates Schlüsselmaterial und B hat keinen Zugang zu dem privaten Schlüsselmaterial von A, ohne das private Schlüsselmaterial selbst zu enthüllen. Der Beweis von A ist nicht absolut, sondern probabilistisch, da A von B gezwungen wird, zu beweisen, daß A wahrscheinlich Zugang zu dem privaten Schlüsselmaterial hat, indem er Beweise gibt.
Es gibt zwei Varianten probabilistischer Beweise:

a) Beweise mit Null-Wissen, bei denen es beweisbar ist, daß B oder ein beliebiger Beobachter des Beweises nichts aus dem Beweis lernt, mit Ausnahme der Tatsache, daß A das private Schlüsselmaterial besitzt.
b) Zeugen-Frage-Antwort-Beweise, die die folgenden vier Elemente in einer Sequenz umfassen:
1. A sendet Informationen, die nicht für alle Aufrufe des Beweises konstant sind, zu B. Diese Informationen werden als der Zeuge bezeichnet. Bei vielen Protokollen wird der Zeuge zufällig erzeugt, und sollte niemals wiederholt werden.
2. B sendet Informationen zu A, die als die Frage bezeichnet werden. Bei vielen Protokollen wird die Frage zufällig erzeugt.
3. A sendet eine Antwort zu B.
4. B verifiziert, ob A tatsächlich das private Schlüsselmaterial kennt, indem er Berechnungen ausführt, an denen der Zeuge, die Frage und die Antwort beteiligt sind.

Tatsächlich sind viele Null-Kenntnis-Beweise Zeugen- Fragen-Antwort-Beweise.
Null-Kenntnis-Beweis-Schemata sind z. B. das Schema von Feige-Fiat-Shamir oder das Schema von Guillou-Quisquater, aber auch die monodirektionalen Null-Kenntnis-Beweis-Schemata, z. B. das Schema von Blum-Feldmann-Micali oder statistische Null-Kenntnis-Beweis-Schemata, z. B. das Brassard-Schema oder das Crepau-Schema usw.
Zeugen-Verberge-Beweis-Schemata sind z. B. das Schema von Feige-Shamir usw.
Im folgenden wird eine mögliche allgemeine Struktur eines Null-Kenntis-Protokolls beschrieben (vgl. [2]). Zur Veranschaulichung hat diese allgemeine Struktur ebenfalls das Format Zeuge-Frage-Antwort-Beweis.
Das Protokoll umfaßt zwei Teilnehmer A und B.

1. Der Beweisende, der beansprucht, A zu sein, wählt ein Zufallselement aus einer vordefinierten Menge als seine geheime Verpflichtung (Bereitstellung einer versteckten Randomisierung), und berechnet daraus einen zugeordneten (öffentlichen) Zeugen. Dadurch wird die Anfangszufälligkeit zur Variation aus anderen Protokollabläufen bereitgestellt und eine Menge von Fragen definiert, von denen der Beweisende behauptet, daß er sie alle beantworten kann, wodurch er a priori seine bevorstehende Antwort einschränkt. Nur der rechtmäßige Teilnehmer A, kann wirklich mit Kenntnis des Geheimnisses von A alle Fragen beantworten und die Antwort auf eine beliebige dieser liefert keine Informationen über das Langzeitgeheimnis von A.
2. Die nachfolgende Frage von B wählt eine dieser Fragen.
3. A gibt seine Antwort.
4. B prüft die Antwort auf Korrektheit.

Das Protokoll kann iteriert werden, um die Grenzeneinschränkung und die Wahrscheinlichkeit eines erfolgreichen Betrügens zu verbessern.
Jeder Kunde kann sein öffentliches Schlüsselmaterial auf ein öffentlich zugängliches Verzeichnis aufgeben, ohne das entsprechende private Schlüsselmaterial zu kompromittieren. Der Kunde sollte gewöhnlich sein privates Schlüsselmaterial als ein enges Geheimnis wahren; andernfalls kann das kryptographische System keine Korrektheit (Geheimheit) garantieren. Der beste bekannte Mechanismus zum Schutz von privatem Schlüsselmaterial ist 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 geben, können soziale Faktoren des E-Commerce 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, wie bewertet B dann die Gültigkeit? Das heißt, ein Kopierer kann versuchen, sich als A auszugeben, aber sein eigenes Schlüsselmaterial aufgeben. Bestimmte kommerzielle Organisationen lösen dieses Problem, indem sie als Zertifizierungsbehörden, (CA) handeln. (Möglicherweise) für eine Gebühr übernimmt die CA Identifizierungsmaterial von potentiellen Kunden, wie zum Beispiel einen Führerschein oder Paß. Nach der Validierung des Identifizierungsmaterials gibt die CA das öffentliche Schlüsselmaterial des Kunden 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 öffentliche Schlüsselmaterial des Kunden hält. Standardisierte 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 an die CA aufgibt, sollte sich der Kunde bemühen, sein privates Schlüsselmaterial zu schützen. Wenn das private Schlüsselmaterial des Kunden kompromittiert werden würde, könnte in diesem Fall das private Schlüsselmaterial nicht mehr länger sinnvoll verwendet. werden. Wenn das private Schlüsselmaterial des Kunden unwissentlich kompromittiert werden würde, dann hätte bei bestimmten asymmetrischen Schlüsseln der Kunde Grund zur Besorgnis. Im Fall von RSA-Schlüsseln, die auch für digitale Signaturen verwendet werden können, könnten vernetzte Händler zum Beispiel potentiell E-Commerce-Transaktionen autorisieren.
Die Erfindung wird durch die Merkmale der beigefügten unabhängigen Ansprüche 1, 29 und 30 definiert. Weitere Aspekte der Erfindung werden durch die Merkmale der abhängigen Ansprüche 2 bis 28 und 31 bis 57 definiert.
Kurze Beschreibung der Zeichnungen
1 ist ein Flußdiagramm eines Kaufprotokolls, das benutzt wird, wenn ein Kunde Software kaufen möchte, die durch einen Schutzmechanismus gemäß der Erfindung geschützt ist.
2 ist ein Blockschaltbild der Softwarekomponenten, die in der Maschine des Kunden installiert sein 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.
5 zeigt die Zertifikatinfrastruktur gemäß der Erfindung.
Beschreibung einer Ausführungsform der Erfindung
Ein Schutzmechanismus gemäß der Erfindung wird nun beispielhaft unter Bezugnahme auf die beigefügten Zeichnungen beschrieben.
Das Kaufprotokoll
1 zeigt ein Kaufprotokoll, das benutzt wird, wenn ein Kunde 102 Software kaufen möchte, die durch einen ECP-Mechanismus gemäß der Erfindung geschützt wird. Der Händler 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 Beweisprotokolle 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 einem Händler 101 durch Herunterladen der Software von einem Netzwerk-Bulletin-Board. Ein Abfragemechanismus 24 (vgl. 2), der später beschrieben wird, ist dergestalt in die geschützte Software 103 eingebettet, daß ein potentieller Angreifer den Abfragemechanismus 24 nicht leicht von dem geschützten Programm 103 trennen kann. Der Angreifer müßte den Code de-assemblieren und manuell den Abfragemechanismus entfernen. In den Abfragemechanismus 24 ist das öffentliche Schlüsselmaterial des Händlers eingebettet. Wie später beschrieben werden wird, verhindert der Abfragemechanismus 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 Händlers signiert.
Im Schritt 2 sendet der Kunde 102 ein Registrationspaket 104 per E-Mail zu dem Händler 101. Das Registrationspaket 104 enthält einen Verweis auf ein öffentliches Verzeichnis, das das öffentliche Schlüsselmaterial des Kunden hält.
Im Schritt 3 findet der Softwarehändler 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 installiert hat, gestattet es der Schutzmechanismus dem Kunden 102, die geschützte Software 103 auszuführen, solange der Kunde beweisen kann, daß er Zugang zu dem privaten Schlüsselmaterial des Kunden hat. Im Fall lizenzierter Software muß die Software möglicherweise Betriebsmittel von dem Lizenzserver erhalten, um in einem unbegrenzten Modus ausgeführt werden zu können.
Die Erzeugung der Schlüsseldatei 105 wird von einem Schüsseldateigenerator durchgeführt, bei dem es sich um ein Programm handelt, das in der Anlage des Händlers ausgeführt wird. Der Händler 101. muß Sorgfalt walten lassen, um dieses Programm zu schützen.
Bei der Verwendung des Schlüsseldateigenerators gibt ein Bediener die folgenden Informationen ein:
Händlername: Händlername ist der Name der Firma des Händlers.
Händlerpaßwort: Händlerpaßwort ist das Paßwort, das das private Schlüsselmaterial der Händlerfirma entriegelt. Firmenan-gestellte, die das Paßwort nicht kennen, können keine Schlüsseldateien erzeugen.
Kundenname: Der Kundenname ist der besondere Name eines Kunden (definiert in [7]), 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.
Nachdem er diese Informationen erhält, 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 Wertesequenz.
Das Aufbauen 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 Künden 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 wesentliche Menge an Tarnungsmaterial dar, kann jedoch in eine Standard-E-Mail-Nachricht passen.
Jede Schlüsseldatei 105 speichert das öffentliche Schlüsselmaterial des Kunden an einer verschiedenen Stelle. Außerdem 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 Händler leicht den Besitzer 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.) wird dann unter Verwendung verschiedener Algorithmen von dem Schlüsseldateigenerator verschlüsselt und mehrere Male neu verschlüsselt. Als letztes signiert der Schlüsseldateigenerator die Schlüsseldatei unter Verwendung des privaten Schlüsselmaterials des Händlers durch Anwenden eines digitalen Signaturalgorithmus.
Eine Schlüsseldatei wird als validiert bezeichnet, wenn das Abfragemittel die Signatur des Händlers unter Verwendung des öffentlichen Schlüsselmaterials validieren kann, das in der Binärdatei des Abfragemittels gespeichert ist und auf das in der Schlüsseldatei gespeicherte entschlüsselte öffentliche Schlüsselmaterial zugreifen kann.
Mehrere Lizenzserver
5 zeigt eine Zertifikatinfrastruktur, die hilf reich sein kann, wenn mehrere Lizenzserver verwendet werden. Oder möglicherweise, wenn ein einziger Lizenzserver verwendet wird, der periodisch Schlüsselmaterial verändert.
Der Ahfragemechanismus greift auf eine validierte Schlüsseldatei 510 zu. Während der Validierungsprozedur extrahiert der Abfragemechanismus das öffentliche Schlüsselmaterial des Händlers aus der Binärdatei des geschützten Programms und verwendet das öffentliche Schlüsselmaterial des Händlers zur Validierung der Signatur 512 der Schlüsseldatei. Die Schlüsseldatei soll als CAKF 510 bezeichnet werden, womit die Zertifikatsbehördenschlüsseldate gemeint ist. Unter Verwendung des in der CAKF 511 gespeicherten öffentlichen Schlüssels der CA validiert das Abfragemittel, die Signatur 522 eines Zertifikatsbehördenzertifikats (CAC) 520.
Das CAC 520 enthält mindestens einen öffentlichen Schlüssel 521 und eine digitale Signatur 522 des gesamten CAC. Nach der Validierung dieser digitalen Signatur wird das CAC als validiert bezeichnet.
Das geschützte Programm 103 durchsucht das Dateisystem nach Lizenzserverzertifikaten (LSi, i = 1 .. n), die in dem Dateisystem gespeichert sind. Bei dem vorliegenden Beispiel nehme man an, daß LSi 530 ist.
Jedes Lizenzserverzertifikat LSi enthält mindestens den öffentlichen Schlüssel des Lizenzhändlers (öffentlicher Schlüssel des Lizenzservers) 531 und eine digitale Signatur des gesamten LSi 532.
Wenn das geschützte Programm 103 ein Lizenzserverzertifikat LSi 530 findet, prüft das geschützte Programm 103 die verfügbaren Informationen, um zu bestimmen, ob das Lizenzserverzertifikat LSi benutzt werden kann.
Dann validiert das geschützte Programm 103 die digitale Signatur des LSi gemäß einer Kette von Zertifikaten, bis die Kette letztendlich das validierte CAC erreicht, wie in [2] beschrieben. Man beachte, daß jedes Zertifikat in der Kette von dem Abfragemechanismus gefunden werden muß. Man beachte außerdem, daß in 5 die Kette kurz ist, da die CA jedes der. Lizenzserverzertifikate 532 direkt signiert.
Wenn die Validierung erfolgreich ist, akzeptiert das geschützte Programm 103 das Lizenzserverzertifikat LSi. Dieses LSi-Zertifikat soll als validiertes Lizenzserverzertifikat (VLSC) bezeichnet werden.
Der öffentliche Schlüssel 531 des VLSC kann später zur Validierung des Lizenzservers verwendet werden.
Authentifizierung des Lizenzservers
Um eine gegenseitige Authentifizierung zwischen dem geschützten Programm 103 und einem Lizenzserver Li zu erreichen, validiert das geschützte Programm 103, daß es mit dem korrekten Lizenzserver Li kommuniziert, und der Lizenzserver Li validiert, daß er mit dem korrekten geschützten Programm 103 kommuniziert.
Mindestens eine dieser beiden Validierungen muß ein Protokoll ausführen, das asymmetrische kryptographische Verfahren verwendet. Bei dem vorliegenden Beispiel verwenden beide Validierungen den GQ-Beweis – ein asymmetrisches kryptographisches Verfahren mit der Null-Kenntnis-Eigenschaft (wie oben beschrieben).
Validierung des Lizenzservers:
Als erstes erhält das geschützte Programm (einschließlich Validierung) ein Lizenzserverzertifikat VLSC unter Verwendung des oben beschriebenen Verfahrens. Ein öffentlicher Schlüssel VLSCPK 531 ist der öffentliche Schlüssel VLSCPK 531, der in dem Lizenzserverzertifikat VLSC gespeichert ist.
Gemäß der obigen Beschreibung des GQ-Beweisprotokolls beweist der Lizenzserver Li (als Teilnehmer A) dem Abfragemechanismus 24 (Teilnehmer B), daß der Lizenzserver Li Zugang zu dem privaten Schlüsselmaterial LSPVTK hat. Der Abfragemechanismus verwendet den öffentlichen Schlüssel VLSCPK 531 bei der Validierung des GQ-Beweises.
Wenn der Abfragemechanismus 24 den Beweis validiert, dann wird das geschützte Programm 103 in einem unbegrenzten Modus ausgeführt, der nicht durch das Kopierschutz- oder Lizenzsystem eingeschränkt wird.
Wenn der Abfragemechanismus 24 den Beweis nicht validieren kann, dann hält das geschützte Programm 103 mit der Ausführung an, läuft in einem begrenzten Modus ab oder trifft andere entsprechende Maßnahmen.
Es ist möglich, daß in das geschützte Programm 103 ein einziger Abfragemechanismus eingebettet ist, der mit mehreren Lizenzservern auf die oben beschriebene Weise kommuniziert. Als Alternative könnten mehrere Abfragemittel mit mehreren Lizenzservern auf die oben beschriebene Weise kommunizieren.
Gegenseitige Authentifizierung zwischen dem geschützten Programm und dem Lizenzserver
(Box 31)(siehe 3) Als erstes validiert das geschützte Programm 103 den Lizenzserver Li unter Verwendung des oben beschriebenen Mechanismus. Als nächstes validiert der Lizenzserver Li das geschützte Programm 103 wie nachfolgend beschrieben.
Das geschützte Programm 103 enthält ein eingebettetes Antwortmittel. Dieses Antwortmittel enthält eingebettetes privates Schlüsselmaterial PPPVTK, wobei das private Schlüsselmaterial PPPVTK von dem privaten Schlüsselmaterial LSPVTK des Lizenzservers verschieden ist.
(Box 32) Der Lizenzserver Li erhält und validiert die Schlüsseldatei PPKF eines Programms. Die Validierungsprozedur ist analog zu der Validierungsprozedur für CAKF. Bei der Validierungsprozedur validiert der Lizenzserver die digitale Signatur des PPKF unter Verwendung des öffentlichen Schlüsselmaterials des Lizenzservers.
Man beachte, daß die Schlüsseldatei PPKF des geschützten Programms nicht die Schlüsseldatei CAKF des Lizenzservers ist.
(Box 33) Der Lizenzserver Li extrahiert das öffentliche Schlüsselmaterial aus dem PPKF durch Ausführen der jeweils erforderlichen mehrfachen Entschlüsselungen.
(Box 34) Das geschützte Programm 103 beweist dem Lizenzserver Li, daß das Schutzprogramm 103 Zugang zu privatem Schlüsselmaterial PPPVTK hat, unter Verwendung eines GQ-Beweisprotokolls. Der Lizenzserver validiert den Beweis unter Verwendung des aus der Schlüsseldatei PPKF des Programms extrahierten öffentlichen Schlüssels.
Wenn der Lizenzserver erfolgreich validiert, dann gewährt der Lizenzserver dem geschützten Programm Betriebsmittel, die es dem geschützten Programmm 103 erlauben, in einem potentiell unbegrenzten Modus zu arbeiten. Andernfalls könnte das geschützte Programm 103 in einem begrenzten Modus ausgeführt werden.
Als Alternative zu dem oben beschriebenen Verfahren kann der Lizenzserver das geschützte Programm unter Verwendung von symmetrischem Schlüsselmaterial validieren.
Vor der Ausführung des Protokolls erhalten sowohl das Abfragemittel in dem Lizenzserver (bezeichnet durch B) als auch das Antwortmittel in dem geschützten Programm (bezeichnet durch A) Zugang zu desmselben symmetrischen Schlüsselmaterial k. In dem folgenden Protokoll beweist das Antwortmittel dem Abfragemittel, daß das Antwortmittel Zugang zu dem symmetrischen Schlüsselmaterial hat. A ← B: rB (1) A → B: h(k,rB,B) (2)
Schritt (1): Als erstes erzeugt das Abfragemittel des Lizenzservers eine Zufallszahl r_B und sendet die Zufallszahl rB zu A.
Schritt (2): Als nächstes extrahiert das Antwortmittel des geschützten Programms das gemeinsam benutzte Schlüsselmaterial k, die Zufallszahl r_B und die eindeutige Identität des Lizenzservers B. Das Antwortmittel verkettet in der folgenden Reihenfolge: k,r_B,B. Als nächstes berechnet das Antwortmittel unter Verwendung der Nachrichten-Digest-Funktion h, z. B. MD5, h (k, r_B, B) .
Als letztes führt das Abfragemittel eine Validierungsprozedur durch, indem es zunächst das gemeinsam benutzte Schlüsselmaterial k und die im Schritt (1) erzeugte Zufallszahl r_B und die Identität B des Lizenzservers abruft. Das Abfragemittel berechnet h(k,r_B,B) und vergleicht das Ergebnis (auf Gleichheit) mit dem im Schritt (2) empfangenem entsprechenden Wert. Wenn die Gleichheitsprüfung erfolgreich ist, dann nimmt das Abfragemittel den Beweis an; andernfalls weist das Abfragemittel den Beweis zurück.
Wie aus beiden Verfahren zur gegenseitigen Authentifizierung ersichtlich ist, beweist das Antwortmittel, daß das Antwortmittel Zugang zu geheimem Schlüsselmaterial hat.
Im Fall der asymmetrischen Kryptographie ist das geheime Schlüsselmaterial das private Schlüsselmaterial, eines asymmetrischen Schlüsselpaars. Im Fall von symmetrischen Mitteln ist das geheime Schlüsselmaterial ein gemeinsam genutzter Schlüssel. Man beachte, daß man in diesem Fall sagt, daß das symmetrische Mittel sowohl symmetrische Verschlüsselungsalgorithmen, wie zum Beispiel DES (Data Encryption Standard), als auch andere Algorithmen enthält, bei denen der Verschlüsselungsschlüssel aus dem Entschlüsselungsschlüssel ableitbar ist und umgekehrt. Das symmetrische Mittel enthält zusätzlich Nachrichten-Digests, wie zum Beispiel MD5, oder andere kryptographische Mittel, bei dem sich beide Teilnehmer gemeinsames Schlüsselmaterial teilen.
Authentifizierung und Validierung eines zweiten Lizenzservers
Im Fall eines geschützten Programms mit einem eingebetteten Abfragemittel, das mit zwei oder mehr Antwortmitteln kommuniziert, sind die Mechanismen und Verfahren zur Kommunikation identisch. Das Abfrage mittel verwendet die oben beschriebenen Mechanismen und Verfahren zur Validierung erst eines Antwortmittels und dann des anderen. Das Abfragemittel kann so konfiguriert werden, daß es eine Validierung beider Antwortmittel erfordert, oder möglicherweise nur eines. In jedem Fall kann nach erfolgreicher Validierung das geschützte Programm in einem unbeschränkten Modus ausgeführt werden. Andernfalls hört das geschützte Programm mit der Ausführung auf oder wird in einem begrenzten Modus ausgeführt.
Das Abfragemittel kann potentiell unter Verwendung eines asymmetrischen Protokolls mit dem ersten Antwortmittel kommunizieren, und das Abfragemittel kann potentiell unter Verwendung eines symmetrischen Protokolls mit dem zweiten Antwortmittel kommunizieren. Oder es könnte der Fall sein, daß beide Protokolle symmetrisch sind.
Kundensoftware
2 zeigt die Softwarekomponenten, die in der Maschine, einem Computer, des Kunden installiert werden müssen, damit der Kunde die geschützte Software 103 nach der gegenseitigen Authentifizierung ausführen kann. Dazu gehören ein Lizenzserver 20, die Schlüsseldateien 105, die geschützte Software 103 und die Zertifikate (nicht gezeigt). Die geschützte Software 103 enthält einen Abfragemechanismus 24 und möglicherweise einen Antwortmechanismus (nicht gezeigt). Der Lizenzserver greift auf privates Schlüsselmaterial zu (nicht gezeigt). Falls das geschützte Programm einen Antwortmechanismus enthält, greift der Antwortmechanismus des geschützten Programms auf geheimes Schlüsselmaterial zu.
Der Lizenzserver 20 ist ein Programm, das der Kunde 102 ausführt, wenn das System anfänglich gebootet wird. Der Kunde 102 aktiviert das System durch Einlegen einer Chipkarte, die das private Schlüsselmaterial des Kunden enthält. Der Lizenzserver 20 fordert den Kunden 102 dann zur Eingabe einer Paßphrase auf, mit der die Chipkarte aktiviert wird. Die Lizenzsoftware wird nicht ausgeführt, wenn der Kunde nicht die korrekte Paßphrase zum Entriegeln der Chipkarte angeben kann. Der Lizenzserver erhält keinen Zugriff zu dem privaten Schlüsselmaterial, das auf der Chipkarte gespeichert ist. Der Lizenzserver 20 wird dann im Hintergrund ausgeführt.
Der Nonce-Generator
Die Erzeugung eines Nonce wird von einem in dem Abfragemechanismus 24 enthaltnen Nonce-Generator durchgeführt. Die Funktionsweise des Nonce-Generators ist wie folgt.
Als erstes fragt der Nonce-Generator eine große Anzahl von Systemparametern ab, z. B. die Systemzeit, den in der Seitentabelle verbleibenden freien Platz, die Anzahl von logischen Plattenlaufwerken, die Namen der Dateien indem Verzeichnis des Betriebssystems usw.
Als nächstes baut der Nonce-Generator unter Verwendung eines Zufallszahlengenerators eine Zufallszahl auf. Der Zufallszahlengenerator besteht aus zwei Prozeß-Threads, die hier als Thread 1 und Thread 2 bezeichnet werden. 4 zeigt die Funktionsweise von Thread 1, dem Haupt-Thread des Zufallszahlengenerators.
(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-F1ag 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 done_test-Flag auf TRUE. Man beachte, daß Thread 1 und Thread 2 das done_test-Flag gemeinsam benutzen.
(Box 54) Thread l 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, kehrt der Thread zur Box 54 zurück. Es ist also ersichtlich, daß Thread 1, während er auf den Abschluß des Plattenzugriffs wartet, dauernd den Zählerwert erhöht.
(Box 56) Wenn das done_test-Flag TRUE ist, beendet Thread 1 den Thread 2 und sichert den Zählerwert der ersten freien Speicherstelle in value_list.
(Box 57) Thread 1 ruft dann eine Statstest-Funktion auf, die den Zufälligkeitsgrad der Zählerwerte (oder von Teilen von Zählerwerten, z. B. Bit niederer Ordnung) schätzt, die in value_list gesichert werden. Diese Funktion kann den Chiquadrat-Test, den Kolmogorov-Smirnov-Test oder den Seriell-Korrelationstest verwenden, die in [3] beschrieben werden. Die Statstest-Funktion kann optimiert werden, um sicherzustellen, daß nicht für jeden Plattenzugriff komplizierte Berechnungen wiederholt werden. Die Statstest-Funktion gibt einen Wert zurück, der angibt, wie viele Bit niederer Ordnung jedes gesicherten Zählerwerts als zufällig betrachtet werden sollten.
(Box 58) Thread 1 vergleicht den von der Statstest-Funktion zurückgegebenen Wert, wenn er mit der Länge der value_list kombiniert 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 Ausgabezufallszahl zurück.
Kurz gefaßt ist ersichtlich, daß der Zufallszahlengenerator die Unvorhersehbarkeit in 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 benutzt der Zufallszahlengenerator außerdem Unvorhersehbarkeiten im Betrieb des Schedulers des Betriebssystems als eine zweite Quelle von Zufälligkeiten.
Die von der Statstest-Funktion durchgeführte Analyse gestattet dem Zufallszahlengenerator, sich selbst auf Prozessoren und Platten jeder beliebigen Geschwindigkeit abzustimmen, indem er die Anzahl von Bit niederer Ordnung jedes zurückzugebenden gesicherten Zählerwerts berechnet. Zum Beispiel erzeugt ein System mit einer Plattenzugriffszeit mit hoher Varianz mehr Zufallsbit pro Plattenzugriff als ein System mit einer Plattenzugriffszeit niedriger Varianz. Zum Beispiel erzeugt das System bei einer Platte des Typs Quantum 1080s (mittlere Schreibzeit 6 ms) und einem 468-66-Mhz- Prozessor ungefähr 45 Bit pro Sekunde. Als Alternative kann man die Anzahl von Bit pro Plattenzugriff fest codieren und eine de-skewing-Technik zur Sicherstellung eines guten Zufälligkeitsgrades verwenden.
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 oben beschriebene 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 Plattenzeitsteuerungszufalls-Zahlengenerator 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 oben beschriebene 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 Synchronisationsvariablen 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 in einem PC-Lager, auf dem Internet oder durch ein bestimmtes anderes Mittel der Verteilung erhalten.
Außerdem kann das private Schlüsselmaterial des Kunden oder des Händlers auf einer Chipkarte gespeichert werden. Bei einer solchen Chipkarten aktivierten Konfiguration kann ein unrechtmäßiger Kopierer nicht das private Schlüsselmaterial von der Chipkarte extrahieren, wodurch ein noch größerer Schutz vor Angriff bereitgestellt wird.
Privates Schlüsselmaterial kann auf einem unsicheren Speichergerät, wie zum Beispiel einer Diskette, gespeichert werden. In diesem Fall sollte das private Schlüsselmaterial verschlüsselt werden. Es sollte einem Antwortmechanismus nicht möglich sein, die Entschlüsselungsroutine durchzuführen, wenn nicht der Kunde zuerst ein Paßwort angibt. In diesem Fall erhält das Antwortmittel Zugriff auf das private Schlüsselmaterial, gibt das private Schlüsselmaterial jedoch nicht außerhalb seines Adreßraums frei.
Wahlweise kann dieses vorliegende Beispiel erweitert werden, indem man das Abfragemittel so aufbaut, daß es sich auf einen internen Zeitgeber bezieht, z. B. auf, einen Zähl-Thread, oder einen externen Timer, z. B. einen Takt. Wenn eine a priori definierte Schwelle endet, bevor das probabilistische Beweisprotokoll abgeschlossen ist, dann bleibt die Validierung automatisch erfolglos.
Mehrere Programme können eingebettete Abfragemittel enthalten, die mit demselben Antwortmittel kommunizieren. In diesem Fall könnte das Antwortmittel potentiell dieselbe Chipkarte zum Speichern des privaten Schlüsselmaterials verwenden, die bei seinen Interaktionen mit allen jeweiligen Abfragemitteln verwendet wurde. Wahlweise können die Programme so konfiguriert werden, daß das Antwortmittel in seinen Interaktionen mit jedem der jeweiligen Abfragemittel dasselbe private Schlüsselmaterial verwendet.
Ein Computersystem, das mindestens zwei Antwortmittel enthält, kann potentiell ein Antwortmittel enthalten, das asymmetrische Kryptographie verwendet, und ein zweites Antwortmittel, bei dem dies nicht der Fall ist. Ein Beispiel für ein Antwortmittel, das keine asymmetrische Kryptographie benutzt, ist ein Dongle, das symmetrische Kryptographie verwendet. In diesem Fall hat das Dongle keinen Zugriff auf asymmetrisches privates Schlüsselmaterial.
Zusätzlich zu der Implementierung des Kopierschutzes kann der oben beschriebene Mechanismus zum Verfolgen von Softwarekopierern verwendet werden. Der Mechanismus gibt eine ausgezeichnete Verfolgbarkeit, ohne daß jeder Kunde eine einzigartige Version des Programms erhalten muß.
Der Lizenzserver 20, der Abfragemechanismus 24 und die geschützte Software 103, die oben beschrieben wurden, können in einer Anzahl verschiedener Konfigurationen eingesetzt werden.
Beispiele:

– Der Lizenzserver 20 kann in einem Adreßraum und der Abfragemechanismus 24 und die geschützte Software 103 können in einem anderen Adreßraum in einer einzigen Maschine verankert sein.
- Der Lizenzserver 20 kann in einem Adreßraum auf einer Maschine 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 sich mehrere Kunden, die jeweils ihre eigene Kopie des geschützten Softwarepostens besitzen, einen gemeinsamen Lizenzserver 20 teilen, der auf Fragen 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 zum Beispiel. bei der Konstruktion von Mehrfachbenutzer-Lizenzierungsfunktionalität benut zen.
Bei einer anderen möglichen Modifikation kann die Schlüsseldatei 105 versteckte Informationen bezüglich der selektiven Aktivierung von Diensten des geschützten Programms 103 enthalten. Zum Beispiel kann die Schlüsseldatei 105 angeben, daß das geschützte Programm 103 die Ausführung eines Druckdienstes gestattet, aber. die Ausführung eines Dienstes des Sicherns auf Platte deaktiviert. 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 gechützte Programm 103 würde die Schlüsseldatei 105 lesen, um die Dienste zu bestimmen, die das geschützte Programm 103 ausführen sollte. Ein Kunde könnte die Möglichkeit erhalten, mehr Dienste auszuführen, indem er eine weitere Schlüsseldatei vom Händler anfordert. Wenn ein Lizenzserver ein Programm nicht authentifizieren kann, dann kann der Lizenzserver eine Gewährung von Betriebsmitteln für das Programm verweigern. Das Programm kann selbstständig verweigern, bestimmmte Dienste auszuführen, wenn nicht ausreichende Betriebsmittel erhalten werden.
Die folgenden Veröffentlichungen, wurden in der vorliegenden Schrift zitiert:
[1] Choudhury et al, Copyright Protection for Electronic Publishing over Computer Networks, IEEE Network, Mai/Juni 1995, S. 12–20.
[2] A. Menezes et al, Handbook of Applied Cryptography, CRC Press, Inc. ISBN 0-8493-8523-7, S. 405 – 424, 1997
[3] D. Knuth, The Art of Computer Programming, Addison-Wesley Publishing Co., Reading MA, 2. Auflage, 1981, S. 38–72, ISBN 0-201-03822-6.
[4] P. Fenstermacher et al, Cryptographic randomness from air turbulence in disk drives, Advances in Cryptology: Crypto '94, S. 114-120, Springer Verlag, 1994
[5] ISO/IEC 9796, „Information technology – Security techniques – Digital signature scheme giving message recover", International Organization for Standardization, Genf, Schweiz, 1991 (1, Auflage).
[6] R. Rivest, The MD5 message-digest algorithm, RFC 1321, April 1992.
[7] ISO/IEC 9594-1, „Information, technology – Open Systems Interconnection – The Directory: Overview of concepts, models, and services", International Organization for Standardization, Genf, Schweiz, 1995 (entspricht ITU-T Rec. X.509, 1993).

Claims

Computersystem mit einem Schutzmechanismus zum Schutz von Software, wobei der Schutzmechanismus mindestens drei Elemente umfaßt, wobei mindestens ein Abfragemittel einem geschützten Softwareposten zugeordnet ist und ein erstes Antwortmittel Zugang zu privatem Schlüsselmaterial eines asymmetrischen Schlüsselpaars hat und mit dem Abfragemittel kommunizieren kann und ein zweites Antwortmittel Zugang zu geheimem Schlüsselmaterial hat und in der Lage ist, mit dem Abfragemittel zu kommunizieren, wobei a) das Abfragemittel keinen Zugang zu dem privaten Schlüsselmaterial hat, auf das durch das erste Antwortmittel zugegriffen wird, b) das Abfragemittel ein Mittel zum Validieren eines asymmetrischen Beweises des ersten Antwortmittels und eines Beweises des zweiten Antwortmittels umfaßt, ohne daß es notwendig ist, daß das erste Antwortmittel sein privates Schlüsselmaterial enthüllt, c) das Abfragemittel ein Mittel umfaßt, das verhindert, daß ein geschütztes Programm ausgeführt wird, wenn nicht eine der Validierungen oder beide erfolgreich ist bzw. sind.
Computersystem nach Anspruch 1 mit einem zweiten Abfragemittel, wobei das zweite Antwortmittel mit dem zweiten Abfragemittel kommunizieren kann, wobei a) das zweite Abfragemittel den Beweis des zweiten Antwortmittels validiert, b) das erste Abfragemittel oder das zweite Abfragemittel eine Benutzung der Software verhindert oder eine Benutzung der Software in einem unbegrenzten Modus verhindert, wenn nicht eine der Validierungen oder beide Validierungen erfolgreich ist bzw. sind.
Computersystem nach Anspruch 1 oder 2, wobei das geheime Schlüsselmaterial des zweiten Antwortmittels privates Schlüsselmaterial eines weiten asymmetrischen Schlüsselpaars ist.
Computersystem nach Anspruch 1 oder 2, wobei das geheime Schlüsselmaterial des zweiten Antwortmittels geheimes Schlüsselmaterial eines symmetrischen Schlüsselpaars ist.
Computersystem nach einem der Ansprüche 1 bis 4, wobei das erste Antwortmittel und das zweite Antwortmittel auf privates Schlüsselmaterial zugreifen, das auf demselben Speichergerät gehalten wird.
Computersystem nach einem der Ansprüche 1 bis 5, bei dem ein Speichersystem, das einen Teil des privaten Schlüsselmaterials oder das gesamte private Schlüsselmaterial hält, über ein Protokoll, das Wahl-Klartext-Angriffen widersteht, in Wechselwirkung tritt.
Computersystem nach einem der Ansprüche 1 bis 6, – wobei in dem ersten Antwortmittel auf ein erstes privates Schlüsselmaterial zugegriffen wird und – wobei in dem zweiten Antwortmittel auf ein zweites privates Schlüsselmaterial zugegriffen wird.
Computersystem nach einem der Ansprüche 1 bis 7, wobei beide Antwortmittel auf dasselbe private Schlüsselmaterial zugreifen.
Computersystem nach einem der Ansprüche 1 bis 8, wobei in den mindestens zwei Antwortmitteln jeweils auf den privaten Schlüssel eines Lizenzservers zugegriffen wird.
Computersystem nach einem der Ansprüche 1 bis 9, wobei mindestens einer der folgenden Beweistypen verwendet wird: – digitale Signatur – asymmetrische Vertraulichkeit – probabilistischer Beweis.
Computersystem nach Anspruch 10, wobei das asymmetrische Vertraulichkeitsschema das Blum-Goldwasser-Schema ist.
Computersystem nach Anspruch 10, wobei das probabilistische Beweisschema ein Null-Kenntnis-Beweisschema ist..
Computersystem nach Anspruch 10, wobei das probabilistische Beweisschema ein Zeugen-Verbergungs-Beweisschema ist.
Computersystem nach einem der Ansprüche 1 bis 13 – wobei das erste Abfragemittel oder das zweite Abfragemittel ein Mittel zum Ausgeben einer Zufallsabfrage enthält.
Computersystem nach Anspruch 14, wobei das. Mittel zum Ausgeben einer Zufallsabfrage ein Mittel zum Erzeugen einer Zufallsabfrage durch wiederholte Zeitmessung von Antworten auf Gerätezugriffe umfaßt.
Computersystem nach Anspruch 15, wobei das Mittel zum Erzeugen einer Zufallsabfrage weiterhin ein Mittel zum Erzeugen neuer Threads dergestalt umfaßt, daß ein zusätzlicher Zufälligkeitsgrad in die Zufallsabfrage eingeführt wird, indem Unvorhersehbarkeiten in dem Scheduler des Betriebssystems ausgenutzt werden.
Computersystem nach Anspruch 15, wobei das Mittel zum Erzeugen einer Zufallsabfrage ein Mittel zum Durchführen eines statistischen Tests zur Bestimmung der Anzahl von durch jeden der Plattenzugriffe erhaltenen Zufallsbit und ein Mittel, das bewirkt, daß Gerätezugriffe wiederholt werden, bis eine vorbestimmte Anzahl von Zufallsbit erhalten wurde, umfaßt.
Computersystem nach einem der Ansprüche 1 bis 17, wobei das Abfragemittel in den geschützten Softwareposten eingebettet ist.
Computersystem nach einem der Ansprüche 1 bis 18, wobei das Abfragemittel zur Validierung eines Beweises ein erstes öffentliches Schlüsselmaterial verwendet.
Computersystem nach Anspruch 19, wobei das System eine Schlüsseldatei zum Halten des ersten öffentlichen Schlüsselmaterials enthält.
Computersystem nach Anspruch 20, wobei das in der Schlüsseldatei gehaltene erste öffentliche Schlüsselmaterial kryptographisch gesichert wird, wodurch es rechnerisch impraktikabel wird, irgendeinen Teil der Schlüsseldatei, einschließlich des ersten öffentlichen Schlüsselmaterials, zu verändern, ohne das Abfragemittel zu verändern.
Computersystem nach Anspruch 20 oder 21, wobei die Schlüsseldatei Informationen enthält, die den Kunden identifizieren, an den der geschützte Softwareposten geliefert wurde.
Computersystem nach Anspruch 22 oder 21, wobei die Schlüsseldatei Tarnungsbit zum Tarnen des darin gehaltenen ersten öffentlichen Schlüsselmaterials enthält.
Computersystem nach einem der Ansprüche 20 bis 23, wobei die Schlüsseldatei oder das Abfragemittel und/oder der geschützte Softwareposten Informationen bezüglich der selektiven Aktivierung von Diensten des geschützten Softwarepostens enthalten.
Computersystem nach Anspruch 24, wobei eine Entscheidung, ob eine bestimmte Einrichtung teilweise aktiviert werden soll, davon abhängt, ob das Abfragemittel das Antwortmittel validiert oder nicht.
Computersystem nach einem der Ansprüche 1 bis 25 mit mehreren geschützten Softwareposten, die jeweils ihr eigenes Abfragemittel aufweisen, und einem einzigen Antwortmittel, das zwischen allen geschützten Posten gemeinsam benutzt wird.
Computersystem nach einem der Ansprüche 1 bis 26 mit mindestens einem Wurzelzertifikat, das zur Validierung von abstammenden Zertifikaten verwendet wird, wobei die Zertifikate mindestens ein öffentliches Schlüsselmaterial für Antwortmittel umfassen.
Computersystem nach einem der Ansprüche 1 bis 27, das zum Kopierschutz von Software und/oder zur Lizenzierung von Software verwendet wird.
Gebrauch eines Computersystems nach Anspruch 1 bei der Verteilung von Software an mehrere Kunden, wobei jeder Kunde über ein Computersystem nach Anspruch 1 verfügt, und wobei jeder Kunde eine identische Kopie des geschützten Programms und des Abfragemittels erhält.
Verfahren zum Schutz eines Softwarepostens mit einem Schutzmechanismus zum Schutz von Software, wobei der Schutzmechanismus mindestens drei Elemente umfaßt, wobei mindestens ein Abfragemittel einem geschützten Softwareposten zugeordnet ist und ein erstes Antwortmittel Zugang zu privatem Schlüsselmaterial eines asymmetrischen Schlüsselpaars hat und. mit dem Abfragemittel kommunizieren kann und ein zweites Antwortmittel Zugang zu geheimem Schlüsselmaterial hat und in der Lage ist, mit dem Abfragemittel zu kommunizieren, wobei a) das Abfragemittel keinen Zugang zu dem privaten Schlüsselmaterial hat, auf das durch das erste Antwortmittel zugegriffen wird, b) das Abfragemittel ein Mittel. zum Validieren eines asymmetrischen Beweises des ersten Antwortmittels und eines Beweises des zweiten Antwortmittels umfaßt, ohne daß es notwendig ist, daß das erste Antwortmittel sein privates Schlüsselmaterial enthüllt, c) das Abfragemittel ein Mittel umfaßt, das verhindert, daß ein geschütztes Programm ausgeführt wird, wenn nicht eine der Vallidierungen oder beide erfolgreich ist bzw. sind.
Verfahren nach Anspruch 30, wobei das erste Antwortmittel und das zweite Antwortmittel auf privates Schlüsselmaterial zugreifen, das auf demselben Speichergerät gehalten wird.
Verfahren nach Anspruch 30 oder 31, wobei der Schutzmechanismus mindestens vier Elemente enthält, mit einem zweiten Abfragemittel, mit dem das zweite Antwortmittel kommunizieren kann, wobei a) das zweite Abfragemittel einen Beweis des zweiten Antwortmittels, daß das zweite Antwortmittel Zugang zu dem geheimen Schlüsselmaterial hat, validiert, b) das erste Abfragemittel oder das zweite Abfragemittel eine Benutzung der Software verhindert oder eine Benutzung der Software in einem unbegrenzten Modus verhindert, wenn nicht eine der Validierungen oder beide Validierungen erfolgreich ist bzw. sind.
Verfahren nach einem der Ansprüche 30 bis 32, wobei das geheime Schlüsselmaterial privates Schlüsselmaterial eines zweiten asymmetrischen Schlüsselpaars ist.
Verfahren nach Anspruch 30 bis 32, wobei das geheime Schlüsselmaterial Schlüsselmaterial eines symmetrischen Schlüsselpaars ist.
Verfahren nach einem der Ansprüche 30 bis 34, in dem ein Speichersystem einen Teil von oder das gesamte private Schlüsselmaterial speichert und über ein Protokoll, das Wahl-Klartext-Angriffen widersteht, in Wechselwirkung tritt.
Verfahren nach einem der Ansprüche 30 bis 35, in dem ein Speichersystem einen Teil von oder das gesamte private Schlüsselmaterial speichert und über ein Protokoll, das adaptiven Wahl-Klartext-Angriffen widersteht, in Wechselwirkung tritt.
Verfahren nach einem der Ansprüche 30 bis 36, – wobei in dem ersten Antwortmittel auf ein erstes privates Schlüsselmaterial zugegriffen wird und – wobei in dem zweiten Antwortmittel auf ein zweites privates Schlüsselmaterial zugegriffen wird.
Verfahren nach einem der Ansprüche 32 bis 37, wobei das zweite Abfragemittel keinen Zugang zu dem privaten Schlüsselmaterial, das in einem beliebigen der mindestens zwei Antwortmittel gespeichert ist, und auch keine Kenntnis darüber hat.
Verfahren nach einem der Ansprüche 30 bis 38, wobei in den mindestens zwei Antwortmitteln der private Schlüssel eines Lizenzservers jeweils sicher gespeichert wird.
Verfahren nach einem der Ansprüche 30 bis 39, wobei mindestens eine der folgenden Methoden zum Markieren der Informationen verwendet wird: – digitale Signatur, – asymmetrische Vertraulichkeit, – probabilistischer Beweis.
Verfahren nach Anspruch 40, wobei das asymme-, trische Vertraulichkeitsschema das Blum-Goldwasser-Schema ist.
Verfahren nach Anspruch 40, wobei das probabilistische Beweisschema ein Null-Kenntnis-Beweisschema ist.
Verfahren nach Anspruch 40, wobei das probabilistische Beweisschema ein Zeugen-Verbergungs-Beweisschema ist.
Verfahren nach einem der Ansprüche 30 bis 43, – wobei das Abfragemittel ein Mittel zum Ausgeben einer Zufallsabfrage umfaßt.
Verfahren nach Anspruch 44, wobei das Mittel zum Ausgeben einer Zufallsabfrage ein Mittel zum Erzeugen einer Zufallsabfrage durch wiederholte Zeitmessung von Antworten auf Plattenzugriffe umfaßt.
Verfahren nach Anspruch 45, wobei das Mittel zum Erzeugen einer Zufallsabfrage weiterhin ein Mittel zum Erzeugen neuer Threads dergestalt umfaßt, daß ein zusätzlicher Zufälligkeitsgrad in die Zufallsabfrage eingeführt wird, indem Unvorhersehbarkeiten in dem Scheduler des Betriebssystems ausgenutzt werden.
Verfahren nach Anspruch 46, wobei das Mittel zum Erzeugen einer Zufallsabfrage ein Mittel zum Durchführen eines statistischen Tests zur Bestimmung der Anzahl von durch jeden der Plattenzugriffe erhaltenen Zufallsbit und ein Mittel, das bewirkt, daß Plattenzugriffe wiederholt werden, bis eine vorbestimmte Anzahl von Zufallsbit erhalten wurde, umfaßt.
Verfahren nach einem der Ansprüche 30 bis 47, wobei das Abfragemittel in den geschützten Softwareposten eingebettet ist.
Verfahren nach einem der Ansprüche 30 bis 48, wobei das Abfragemittel das erste öffentliche Schlüsselmaterial zur Verschlüsselung der Informationen verwendet.
Verfahren nach einem der Ansprüche 30 bis. 49, wobei das System eine Schlüsseldatei zum Halten des ersten öffentlichen Schlüsselmaterials enthält.
Verfahren nach Anspruch 50, wobei das in der Schlüsseldatei gehaltene erste öffentliche Schlüsselmaterial kryptographisch gesichert wird, wodurch es rechnerisch impraktikabel wird, irgendeinen Teil der Schlüsseldatei, einschließlich, des ersten öffentlichen Schlüsselmaterials, zu verändern, ohne das Abfragemittel zu verändern.
Verfahren nach Anspruch 51, wobei die Schlüsseldatei Informationen enthält, die den Kunden identifizieren, an den der geschützte Softwareposten geliefert wurde.
Verfahren nach Anspruch 52, wobei die Schlüsseldatei Tarnungsbit zum Tarnen des darin gehaltenen ersten öffentlichen Schlüsselmaterials enthält.
Verfahren nach Anspruch. 51, wobei die Schlüsseldatei Informationen bezüglich der selektiven Aktivierung von Diensten des geschützten Softwarepostens enthält.
Verfahren nach einem der Ansprüche 30 bis 54, mit mindestens zwei Wurzelzertifikaten jeweils eines für jedes Antwortmittel, die zur Validierung von abstammenden Zertifikaten verwendet werden, wobei die Zertifikate jeweils mindestens ein öffentliches Schlüsselmaterial für jedes Antwortmittel umfassen.
Verfahren nach einem der Anprüche 30 bis 55, das zum Kopierschutz von Software und/oder zur Lizenzierung von Software verwendet wird.
Computersystem nach Anspruch 1 mit einem Mittel zum Eingeben eines gemäß dem Schutzmechanismus von Anspruch 1 zu schützenden Softwarepostens und zum Einbetten mindestens eines Abfragemittels in den Softwareposten.