DE69724947T2

DE69724947T2 - Rechnersystem und Verfahren zur Sicherung einer Datei

Info

Publication number: DE69724947T2
Application number: DE69724947T
Authority: DE
Inventors: Dr. Glenn Benson
Original assignee: Siemens AG
Current assignee: S Aqua Semiconductor LLC
Priority date: 1997-07-31
Filing date: 1997-07-31
Publication date: 2004-05-19
Anticipated expiration: 2017-08-01
Also published as: DE69724947D1; EP0895149B1; EP0895149A1; US6301660B1

Description

Allgemeiner Stand der Technik
Die vorliegende Erfindung betrifft Mechanismen zum Schutz elektronischer Dokumente (Dateien) vor unautorisierter Benutzung und insbesondere vor unautorisiertem Kopieren oder Ausdrucken.
Ein elektronisches Dokument ist ein elektronischer Informationsbehälter. Die in dem Behälter gespeicherten Informationen können zum Beispiel Zeichen, graphische Bilder, bewegliche Bilder, Klänge und Animation sein.
Es ist relativ schwierig, vor unautorisierten Informationslecks zu schützen. Photokopierer, Faxmaschinen und andere Technologie ermöglichen ein leichtes Kopieren und Verteilen von Informationen, die auf einem Papiermedium fixiert wurden. Im Fall elektronisch gespeicherter Informationen können Computer sofort eine praktisch unbegrenzte Anzahl identischer Kopien elektronisch gespeicherter Informationen konstruieren.
Eine Aufgabe der Erfindung ist es, einen oder mehrere Menschen als autorisierte Verteiler zu kennzeichnen. Eine weitere Aufgabe der Erfindung ist die Kennzeichnung eines oder mehrerer Menschen als autorisierte Kunden, mit den folgenden Bedingungen:

i) Der autorisierte Verteiler kann sich selbst oder andere als autorisierte Kunden kennzeichnen.
ii) Die autorisierten Verteiler können ein elektronisches Dokument an einen oder mehrere autorisierte Kunden verteilen.
iii) Für jedes an jeden autorisierten Kunden verteilte elektronische Dokument kann der autorisierte Verteiler eine oder mehrere Dokumentbehandlungsregeln zuweisen. Beispielhafte Dokumentbehandlungsregeln sind ein Zulassen eines Nur-Lese-Zugriffs oder ein Zulassen eines Lese- und Druckzugriffs.
iv) Autorisierte Kunden dürfen nur dann Dokumente verteilen, wenn sie auch autorisierte Verteiler sind. Es ist möglich, daß null oder mehr autorisierte Kunden auch autorisierte Verteiler sind.

Man betrachte die in 1 beschriebene Situation.
In 1 sendet ein autorisierter Verteiler 101 Informationen 106 (elektronische Dokumente) an jeden von mehreren autorisierten Kunden 102, 103, 104. Der Verteiler 101 sendet die Informationen 106 in verschlüsselter Form, um sicherzustellen, daß kein unautorisierter Intruder die Informationen betrachten kann, während sich die Informationen im Transit befinden. Viele der Kunden, z. B. ein autorisierter erster Kunde 102 und ein autorisierter zweiter Kunde 103, verwenden die Dokumente 106 auf die beabsichtigte Weise. Das heißt, die Kunden, die das Dokument benutzen, leiten die Dokumente korrekter Weise nicht an andere weiter. Bestimmte Kunden, z. B. ein autorisierter dritter Kunde 104 kann jedoch versuchen, Aktionen durchzuführen, die über seine Autorisierung hinaus gehen. Das heißt, der dritte Kunde 104 kann versuchen, die Dokumente 106 an einen oder mehrere unautorisierte Kunden 105 weiterzuleiten. Die vorliegende Erfindung verhindert, daß der dritte Kunde 104 die Dokumente 106 an einen etwaigen unautorisierten Kunden 105 weiterleitet, wenn nicht der autorisierte dritte Kunde 104 auch ein autorisierter Verteiler ist.
Bestimmte beispielhafte Anforderungen, die ein Sicherheitsmechanismus potentiell erfüllen muß, sind nachfol gend aufgelistet:

– Die autorisierten Kunden sollten weiterhin in der Lage sein, Sicherungskopien anzufertigen.
– Es sollten nur Standard-Hardware- und Software-Annahmen getroffen werden. Obwohl Hardware-Dongles Kopierschutzdienste liefern, möchten zum Beispiel viele Händler den Verkauf der Software nicht auf die Ansammlung von Kunden beschränken, die ein Dongle besitzen oder bereit sind, eines zu installieren.
– Wenn ein Kunde auf legitime Weise ein Dokument erlangt, sollte der Kunde in der Lage sein, das Dokument ungeachtet der Eigentümerschaft auf jeder beliebigen Maschine zu benutzen. Wahlweise sollte der Kunde in der Lage sein, eine gleichzeitige Benutzung der Dokumente in mehreren Maschinen zu autorisieren.
– Dem Verteiler sollte es gestattet sein, eine identische Version der Dokumentsoftware an alle autorisierten Kunden zu verteilen. Durch diese Anforderung wird es möglich, die Dokumente durch normale Kanäle, wie zum Beispiel CD-Rom, Disketten oder Netzwerk-Bulletin-Boards, zu verteilen.
– Es sollte für einen potentiellen unrechtmäßigen Kopierer äußerst schwierig und/oder rechnerisch impraktikabel sein, den Sicherheitsmechanismus zu umgehen.
– Der Sicherheitsmechanismus sollte das private Schlüsselmaterial des Kunden nicht dem Verteiler, jeglichem von dem Verteiler erzeugten verteilten Programm oder jeglichem potentiellen Trojanisches-Pferd-Programm enthüllen. Obwohl die Hauptfunktionalität darin besteht, den Dokumenthändler und -verteiler zu schützen, darf dies nicht auf Kosten des Kunden geschehen.

Die vorliegende Erfindung entspricht den beispielhaften Anforderungen durch Bereitstellen eines speziellen kopiergeschützten Programms, das als das Viewer-Programm bezeichnet wird und den Inhalt des geschützten Dokuments (der Datei) anzeigt. Der Begriff „anzeigen" wird hier frei benutzt und umfaßt ein Zeigen, ein Audio-Rundsenden oder ein Ausdrucken. Der Sicherheitsmechanismus der Erfindung stellt sicher, daß man die geschützte Datei ohne das Viewer-Programm nicht betrachten kann. Weiterhin verhindert das Viewer-Programm ein Betrachten durch andere Personen als ein autorisierter Benutzer.
Die Erfindung kann für jede Datei verwendet werden, die über ein Programm benutzt wird, unabhängig vom Inhalt der Datei.
Der Schutz solcher Dateien ist in sehr verschiedenen Szenarios wichtig, von denen einige nachfolgend erläutert werden:

– Mikro-Veröffentlicher: Ein Mikro-Veröffentlicher ist ein Hobbymensch zu Hause oder ein kleines Unternehmen, der bzw. das bereit ist, mit Internet-Veröffentlichung zu experimentieren. Ein Mikro-Veröffentlicher ist zum Beispiel ein Fotograf, der bei einem Sportereignis Fotos aufnimmt und die Fotos dann an eine Zeitung verkauft.
– Legacy-E-Veröffentlicher: Die Legacy-E-Veröffentlicher veröffentlichen elektronische Dokumente. Ein Legacy-E-Veröffentlicher ist zum Beispiel eine große Enzyklopädiefirma.
– Copyright-Durchsetzer und Direktvermarkter: Bestimmte Organisationen sind mehr daran interessiert, Copyright-Verletzungen zu verhindern, anstatt Umsatz zu erzeugen.
– Werber: Werber sind bereit, Werbegebühren zu bezahlen, wenn sie sicher sind, daß die Werbung tatsächlich in die Datei eingebettet wird und nicht ohne Autorisierung verändert werden kann.
– Dokument-Markierer: Ein Dokument-Markierer fügt eine Markierung in ein Dokument ein, wie z. B. Firmen-Vertraulich. Der Dokument-Markierer fügt außerdem eine Dokumentbehandlungsregel ein. Zum Beispiel ist kein Angestellter außerhalb der Firma ein autorisierter Kunde jegliches firmen-vertraulichen Dokuments.

In [1] wird ein kryptographischer Verkapselungsmechanismus der Anwendungsschicht beschrieben.
Der Grundmechanismus ist in 2 dargestellt. Der Mechanismus wird eingeleitet, wenn ein Händler 201 eine Datei erzeugt (z. B. ein Dokument mit dem Inhalt einer Zeitung, eines Magazins, Musik usw.) und die Datei mit einem symmetrischen Schlüssel K verschlüsselt. Der Händler verschlüsselt den symmetrischen Schlüssel unter Verwendung des öffentlichen Schlüssels 204 des Händlers. Der Händler sendet 202 sowohl das verschlüsselte Dokument als auch den verschlüsselten symmetrischen Schlüssel 204 zu einem Kunden 209. Danach koordinieren der Kunde 209 und der Händler 201 Bezahlungsinformationen. Während dieser Koordination sendet 206 der Kunde eine Kaufanforderung, die den verschlüsselten symmetrischen Schlüssel 205 (der von dem verschlüsselten symmetrischen Schlüssel 204 kopiert wurde) und ein Zertifikat mit dem öffentlichen Schlüssel 207 des Kunden enthält. Als nächstes entschlüsselt der Händler 201 den symmetrischen Schlüssel mit Hilfe des privaten Schlüssels des Händlers und verschlüsselt den symmetrischen Schlüssel dann erneut unter Verwendung des öffentlichen Schlüssels 207 des Kunden (der aus dem Zertifikat des Kunden erhalten wird). Der Händler 201 sendet 210 den neuverschlüsselten symmetrischen Schlüssel 208 zu dem Kunden 209 zurück. Unter Verwendung des privaten Schlüssels des Kunden entschlüsselt der Kunde 209 die ursprüngliche Datei. Die gesamte oben beschriebene Funktionalität des Kunden wird durch ein spezielles Viewer-Programm durchgeführt.
Bei dem oben erwähnten Mechanismus muß der Kunde 209 eine asymmetrische Entschlüsselungsoperation durchführen, um einen symmetrischen Dateiverschlüsselungsschlüssel K zu erhalten. Die Absicht ist, daß der Kunde über seinen asymmetrischen privaten Schlüssel verfügen muß, um die asymmetrische Entschlüsselungsoperation durchzuführen.
Der oben erwähnte Mechanismus ist jedoch angreifbar, z. B. durch das folgende, in 3 dargestellte Angriffsszenario:

1. Nach dem Abschluß des korrekt autorisierten Szenarios von 2 erhält ein autorisierter Kunde 209 eine verschlüsselte Datei 203. Die Datei wird mit dem symmetrischen Schlüssel K verschlüsselt.
2. Der verschlüsselte symmetrische Schlüssel 208 wird dem Kunden 209 gegeben.
3. Der Entschlüsselungsmechanismus des Kunden, z. B. die Chipkarte, führt die Entschlüsselungsoperation durch. Der Kunde sichert den symmetrischen Schlüssel K im Klartext.
4. Wenn der Kunde 209 eine unautorisierte Kopie der Datei durchführen möchte, leitet 314 der Kunde 209 die verschlüsselte Datei 313 (die aus der verschlüsselten Datei 203 kopiert wurde), den verschlüsselten symmetrischen Schlüssel 311 (der aus dem verschlüsselten symmetrischen Schlüssel 208 kopiert wurde), den symmetrischen Schlüssel K im Klartext 312 an einen unautorisierten Kunden 315 weiter.
5. Das Viewer-Programm des unautorisierten Kunden, das die Datei verwendet, gibt dem unautorisierten Kunden 315 den verschlüsselten symmetrischen Schlüssel 311 (das Viewer-Programm weiß nicht, daß der Kunde 315 nicht autorisiert ist).
6. Der Entschlüsselungsmechanismus des unautorisierten Kunden fälscht die Entschlüsselungsoperation, da der unautorisierte Kunde 315 nicht den privaten Schlüssel des Kunden besitzt. Statt dessen gibt der Entschlüsselungsmechanismus des unautorisierten Kunden den im Schritt 4 erhaltenen symmetrischen Schlüssel 312 im Klartext zurück. Da dies der korrekte symmetrische Schlüssel ist, glaubt der Viewer, daß der unautorisierte Kunde weiß, wie die erforderliche Entschlüsselungsoperation durchgeführt wird. Folglich gestattet der Viewer dem unautorisierten Kunden 315, die Datei zu betrachten und zu benutzen.

Wie aus diesem Angriff ersichtlich ist, beweist der bekannte Mechanismus nicht, daß der Kunde 315 den korrekten asymmetrischen privaten Schlüssel besitzt. Folglich schützt dieser Mechanismus nicht vor einer unautorisierten Dokumentweiterverteilung.
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 Checkpoint-Routinen, die von dem Softwareprogramm und einer Software-Regulierungseinrichtung, die Teil des Computersystems oder extern mit diesem verbunden sein kann, verarbeitet werden. Die Checkpoint-Routinen erzeugen Zufalls-Checkpoint-Nachrichten, die chiffriert und zu der Softwareregulierungseinrichtung gesendet werden. Die Softwareregulierungseinrichtung 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 entweder dem Softwareprogramm, weiterzufahren, oder beendet es.
Eine Übersicht über die asymmetrische Kryptographie, zum Beispiel bezüglich des RSA-Schemas, und der probabilistischen Verschlüsselung, zum Beispiel des probabilistischen Verschlüsselungsschemas mit öffentlichem Schlüssel nach Blum-Goldwasser findet sich in [2].
Eine Übersicht über verschiedene probabilistische Beweisschemata, wie zum Beispiel Null-Kenntnis-Beweisschamata (z. B. das Schema von Feige-Fiat-Shamir, das Schema von Guillou-Quisquater, das Schema von Blum-Feldmann-Micali, das Brassard-Schema, das Crepau-Schema usw.) oder Zeugen-Verbergungs-Beweisschemata (z. B. das Schema von Feige-Shamir usw.) finden sich in [2].
Eine Übersicht über digitale Signaturschemata (z. B. Rivest-Shamir-Adleman usw.) 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 [3]. Es ist rechnerisch impraktikabel oder sehr schwierig, die Umkehrung eines Nachrichten-Digest zu berechnen.
In [4] wird die kryptographische Zufälligkeit aus Luftturbulenz in Plattenlaufwerken beschrieben.
Der Chiquadrattest, der Kolmogorov-Smirnov-Test und der Seriell-Korrelationstest werden in [5] beschrieben.
Die Aufgabe der vorliegenden Erfindung ist die Bereitstellung eines verbesserten Mechanismus zum Schutz einer Datei, der die meisten oder sogar alle der oben beschriebenen beispielhaften Anforderungen erfüllen kann.
Ein asymmetrischer kryptographischer Mechanismus enthält ö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. In der vorliegenden Erfindung wird asymmetrische Kryptographie beim Dialog zwischen zwei Teilnehmern A und B verwendet. A beweist B, daß A Zugang zu privatem Schlüsselmaterial hat, und B validiert den Beweis. A enthüllt B nicht das private Schlüsselmaterial.
Bestimmte wichtige asymmetrische kryptographische Algorithmen, die in der Erfindung verwendet werden können, sind nachfolgend aufgelistet.
Das asymmnetrische Vertraulichkeitsschema
Ein asymmetrisches Vertraulichkeitsprotokoll umfaßt zwei Teilnehmer A und B. A besitzt privates Schlüsselmaterial und B hat keinen Zugang zu dem privaten Schlüsselmaterial A, ohne das private Schlüsselmaterial selbst zu enthüllen. Zu 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, P_A(r,B)
A → B: r
Das oben beschriebene Protokollschema verwendet die folgende Notation:

– A → B bedeutet, daß A eine Nachricht zu B sendet; und A ← B 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 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.
Digitales Signaturschema
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.
Probabilistisches Beweisschema
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 erfährt, 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 [2] oder das Schema von Guillou-Quisquater [2], 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.
Man sollte die probabilistische Verschlüsselung mit öffentlichem Schlüssel (zum Zweck der Bereitstellung von Vertraulichkeit) nicht mit probabilistischen Beweisen verwechseln. Im ersten Fall werden probabilistische Mittel verwendet, um den Verschlüsselungsalgorithmus auszuführen. Im zweiten Fall werden probabilistische Mittel zum Definieren eines Versicherungsgrades für einen Dienst, wie zum Beispiel Identifikation, verwendet.
Im folgenden wird eine mögliche allgemeine Struktur eines Null-Kenntnis-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 Grenze zu verbessern, die die Wahrscheinlichkeit eines erfolgreichen Betrügens einschränkt.
Ein Schema mit digitalem Wasserzeichen schreckt vor unautorisierter Dokumentverteilung ab, indem ein eindeutiges Identifikationssymbol in ein Dokument eingebettet wird.
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-Beweis-Protokoll widersteht sowohl Wahl-Klartext-Angriffen als auch adaptiven Wahl-Klartext-Angriffen.
Bei allen asymmetrischen kryptographischen Verfahren kann jeder Kunde 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 vcn 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 Verschlusselungsdiensten 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, wird sich der Kunde wahrscheinlich sehr bemühen, sein privates Schlüsselmaterial zu schützen. 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 Aufgabe der vorliegenden Erfindung ist die Bereitstellung eines verbesserten Mechanismus, der den größten Teil oder sogar alle der oben beschriebenen Beispielanforderungen erfüllt.
Kurze Darstellung der Erfindung
Die Erfindung wird durch die Merkmale der beigefügten unabhängigen Ansprüche 1, 25 und 26 definiert. Weitere Aspekte der Erfindung werden durch die Merkmale der abhängigen Ansprüche 2 bis 24 und 27 bis 49 definiert.
Eine wichtige technische Differenzierung zwischen der Erfindung und dem in [1] beschriebenen Mechanismus ist ein Unterschied in dem jeweiligen Mechanismen zur Authentifizierung des Kunden. Die Erfindung verwendet kryptographische Beweise zur Unterscheidung zwischen Kunden, während der in [1] beschriebene Mechanismus Entschlüsselungstechnologien zur Unterscheidung zwischen Kunden verwendet.
Wie oben beschrieben, beweist das Protokoll in [1] nicht, daß der Kunde den korrekten asymmetrischen privaten Schlüssel besitzt, wie in dem oben beschriebenen Angriffsszenario dargestellt. Die Erfindung hat diese Angreifbarkeit nicht mehr. Folglich schützt die Erfindung vor unautorisierter Dateiweiterverteilung, im Gegensatz zu dem Protokoll in [1].
Die Verfasser definieren einen Viewer als ein Computerprogramm, das eine Datei als Eingabe annimmt und dann den Inhalt der Datei einem Benutzer auf sinnvolle Weise anzeigt. Wenn die Datei zum Beispiel ein graphisches Bild enthält, dann könnte der Viewer das graphische Bild auf einem Computermonitor anzeigen. Die Begriffe „Viewer" und „Anzeige" werden hier liberal verwendet. Wenn die Datei Audioinformationen enthält, dann sendet der Viewer die Informationen zu den Lautsprechern des Computersystems auf eine solche Weise, die es einem Benutzer gestattet, die aufgezeichneten Informationen zu hören. Wenn die Datei ein bewegliches Bild oder Animation enthält, dann kann der Viewer einen Film oder eine Animation auf einem Computermonitor anzeigen. Bestimmte Viewer können potentiell den Inhalt der Datei anzeigen, indem sie einen Teil des Inhalts oder den gesamten Inhalt an einem Drucker zur Verfügung stellen. In bestimmten Fällen wird möglicherweise gewünscht, einen Viewer so aufzubauen, daß der Viewer nur qualitativ minderwertige Informationen an den Drucker weiterleitet. Im Rest der vorliegenden Schrift ist mit dem Ausdruck, daß der Viewer eine Datei anzeigt, gemeint, daß der Viewer die Informationen in der Datei auf sinnvolle Weise präsentiert, z. B. als Audio, Graphik, Filme.
Die Erfindung bezieht sich auf zwei Dateiformate, das ungeschützte Format (UF) und das geschützte Format (PF). Der Begriff ungeschütztes Format UF wird als Platzhalter für ein bestimmtes Dokumentformat verwendet. Häufig definiert man ein ungeschütztes Format UF ohne Bezugnahme auf Sicherheit. Ein Beispiel für ein ungeschütztes Format (UF-Format) ist das Rich Text Format (RTF). Viele zur Zeit verfügbare Textverarbeitungsprogramme können den Inhalt eines Dokuments in dem RTF-Format oder einem bestimmten anderen proprietären ungeschützten Format speichern. Ein anderes Beispiel für ein ungeschütztes Format UF ist ein digitales Format zum Speichern von aufgezeichneten Audiosignalen. Ein weiteres Beispiel für ein ungeschütztes Format UF ist ein digitales Format zum Speichern von Animation oder eines Films. Normalerweise versuchen die Entwickler eines ungeschützten Formats UF nicht, zu verhindern, daß andere einen Viewer bauen, der eine mit UF formatierte Datei anzeigt oder erzeugt.
Das geschützte Format PF hat die Eigenschaft, daß das geschützte Format PF nur spezifisch aufgebauten Viewer-Programmen sinnvolle Informationen gibt. Wenn die Datei in geschütztem Format PF zum Beispiel Musik enthält, dann könnte sich ein Benutzer die Musik nur dann anhören, wenn die Datei in dem geschützten Format PF einem speziellen Viewer-Programm gegeben würde. Es ist äußerst schwierig, ohne richtige Dokumentation, die das geschützte Format PF beschreibt, ein Viewer-Programm zu bauen. Diese Dokumentation sollte ein gut geschütztes Geheimnis sein. Zum Beispiel kann ein einzelner Händler das geschützte Format PF definieren und dann das zugeordnete Viewer-Programm konstruieren. Der Händler erklärt niemals Dritten Informationen über das geschützte Format PF.
Man betrachte zum Beispiel eine Datei, die im RTF-Format gespeicherte Informationen enthält. Man betrachte weiterhin eine zweite Datei, die durch Verschlüsseln der RTF-Datei konstruiert wurde. Der Entschlüsselungsschlüssel der zweiten Datei ist ein gut geschütztes Geheimnis und der Entschlüsselungsschlüssel ist in ein spezielles Viewer-Programm eingebettet. Bei diesem Beispiel hat das mit RTF formatierte Dokument ein ungeschütztes Format UF und das verschlüsselte Dokument ein geschütztes Format PF. Ein unautorisierter Angreifer könnte kein betrügerisches Viewer-Programm konstruieren, das die Datei in geschütztem Format PF versteht, ohne daß der Angreifer den Entschlüsselungsschlüssel der Datei im geschützten Format PF entdecken kann. Später in der vorliegenden Arbeit werden bestimmte andere Verfahren besprochen, durch die man aus einer Datei im ungeschützten Format UF eine Datei in geschütztem Format PF konstruieren kann.
Kurze Beschreibung der Zeichnungen
1 ist ein Blockschaltbild eines Verteilungsszenarios.
2 ist ein Blockschaltbild eines ausführlichen Verteilungsszenarios.
3 ist ein Blockschaltbild eines Angriffsszenarios.
4 ist ein Blockschaltbild einer Dokumenterzeugung.
5 ist ein Diagramm eines Kaufprotokolls.
6 ist ein Blockschaltbild einer Zertifikatbehörde.
7 ist ein Blockschaltbild eines Szenarios mit einem teilnehmenden Kunden.
8 ist ein Blockschaltbild der Softwarekomponenten, die in der Maschine des Kunden installiert sein müssen, damit der Kunde die geschützte Datei benutzen kann.
9 ist ein Blockschaltbild von Angriffsbeispielen.
10 ist ein Flußdiagramm der Funktionsweise eines zur Erzeugung von Nonces verwendeten Zufallszahlengenerators.
11 ist ein Blockschaltbild der Architektur des Software-Verleihsystems.
12 ist ein Blockschaltbild eines Verleih-Softwarekaufszenarios.
13 ist ein Blockschaltbild der Chipkartenarchitektur.
14 ist ein Blockschaltbild eines beispielhaften Audit-Verlaufs.
Beschreibung einer Ausführungsform der Erfindung
Es wird nun ein Schutzmechanismus gemäß der Erfindung beispielhaft mit Bezug auf die beigefügten Zeichnungen beschrieben.
4 zeigt die Komponenten, die von dem Computersystem 201 des Händlers verwendet werden, um ein geschütztes Dokument zu erzeugen. Der Händler verwendet zuerst ein Dokumenterzeugungswerkzeug (DGT) 401, z. B. ein Textverarbeitungsprogramm, um ein UF-Dokument 402 zu erzeugen. Der Dokumentübersetzer (DT) 403 nimmt das UF-Dokument 402 an und übersetzt den Inhalt des Dokuments in ein PF-Format 404 (PF-Dokument). Der Händler sollte das UF-Dokument als ein gut geschütztes Geheimnis aufbewahren.
Der Dokumantübersetzer 403 wirkt dann auf proprietäre und geheime Weise. Der Dokumentübersetzer 403 kann zum Beispiel folgendermaßen aufgebaut werden.

1. Anhängen eines Nachspanns an das Ende des UF-Dokuments 402. Der Nachspann ist eine wohlbekannte Zeichenkette (die für dieses UF-Dokument 402 eindeutig ist), wie zum Beispiel ein Copyright-Vermerk und die Seriennummer, die durch das Symbol: str. bezeichnet wird.
2. Berechnen eines Nachrichten-Digest muf über das UF-Dokument 402 (einschliefllich des Nachspanns), muf = h(UF + str (h bedeutet die Nachrichten-Digest-Funktion, z. B. MD5 [3]).
3. Signieren von muf unter Verwendung des privaten Schlüsselmaterials des Händlers. Diese Signatur soll als smuf bezeichnet werden.
4. Aufbauen einer temporären Datei, die aus einem Kopfteil besteht, der smuf enthält. Der Rest der temporären Datei ist das UF-Dokument 402 (einschließlich des Nachspanns).
5. Erzeugung einer Zufallszahl K, die als ein Verschlüsselungsschlüssel verwendet werden soll.
6. Das PF-Dokument 404 wird durch Verschlüsseln der temporären Datei unter Verwendung von K berechnet. Ein symmetrischer Verschlüsselungsalgorithmus, wie zum Beispiel der wohlbekannte DES (Data Encryption Standard) im CBC-Modus (Cipher Block Chaining Mode) oder Dreifach-DES im CBC-Modus kann verwendet werden.

5 zeigt ein Kaufprotokoll, das verwendet wird, wenn ein Kunde eine PF-Datei 404 kaufen möchte, die durch einen Schutzmechanismus gemäß der Erfindung geschützt ist.
Der Händler 201 gibt das PF-Dokument 404 in ein Netzwerk-Bulletin-Board 501 im Internet 502 auf (Schritt 504). Ein Kunde 503 lädt die PF-Datei 504 aus dem Netzwerk-Bulletin-Board 501 herunter (Schritt 505).
In einem weiteren Schritt 506 handeln der Kunde 503 und der Händler 201 eine Autorisierung des Kunden aus, die PF-Datei 404 anzuzeigen, d. h. den Inhalt der PF-Datei 404 zu betrachten oder zu lesen oder den Inhalt der PF-Datei 404 anzuhören. Der Schritt 506 wird später ausführlicher beschrieben.
6 zeigt ein ausführliches Szenario einschließlich einer Zertifikatbehörde 603. Die Aufgabe der Zertifikatbehörde 603 besteht darin, den Händler 201 sicher den PF-Dateien 404, die der Händler 201 erzeugt, zuzuordnen. Die Reihenfolge der Schritte lautet:

1. Schritt 606 (wird einmal für das Dokument durchgeführt)
2. Schritt 607 (wird einmal für das Dokument durchgeführt)
3. Schritt 504 (wird einmal für das Dokument durchgeführt)
4. Schritt 505 (wird für jeden Kunden durchgeführt)
Schritt 506 (wird für jeden Kunden durchgeführt) umfaßt:
a.
b. Schritt 702 (später beschrieben)
c. Schritt 704 (später beschrieben)

Der Händler 201 sendet ein Zertifikat mit dem öffentlichen Schlüsselmaterial 601 des Händlers, einem Nachrichten-Digest 602 der PF-Datei 404 und einer Signatur 608 des Nachrichten-Digest zu der Zertifikatbehörde 603 (Schritt 606).

– Das Nachrichten-Digest 602 wird berechnet durch Ausführen einer einseitigen Hash-Funktion, wie zum Beispiel MD5 [3], über eine PF-Datei 404, die der Händler verteilen möchte.
– Die Signatur 608 des Nachrichten-Digest wird vom Händler durch Durchführen einer digitalen Signaturoperation über das Nachrichten-Digest 602 berechnet. Diese digitale Signaturoperation wird mit Hilfe des privaten Schlüsselmaterials des Händlers berechnet. Der Händler stellt sorgfältig sicher, daß keine Dritten Zugang zu diesem privaten Schlüsselmaterial haben.
– Das öffentliche Schhüsselzertifikat 601 des Händlers enthält den öffentlichen Schlüssel des Händlers. Das öffentliche Schlüsselzertifikat des Händlers 601 wird von der CA signiert.
1. Die Zertifikatbehörde (CA) 603 validiert die digitale Signatur 608 des Händlers. Die Zertifikatbehörde 603 verwendet das aus dem Zertifikat 601 extrahierte öffentliche Schlüsselmaterial des Händlers, um diesen Validierungsschritt durchzuführen. Zusätzlich prüft die Zertifikatbehörde 603 ihre interne Datenbank, um sicherzustellen, daß der Zertifikatbehörde 603 noch niemals zuvor dasselbe Nachrichten-Digest präsentiert wurde. Wenn die Validierung und/oder die Prüfung erfolglos bleibt, dann hält die Zertifikatbehörde 603 die Verarbeitung der Anforderung des Händlers an.
2. Andernfalls validiert die Zertifikatbehörde 603 das öffentliche Schlüsselzertifikat 601 des Händlers. Die Zertifikatbehörde 603 führt diese Validierung durch, indem sie sicherstellt, daß das Zertifikat von der Zertifikatbehörde 603 signiert ist. Die Zertifikatbehörde 603 verwendet das öffentliche Schlüsselmaterial der CA zur Durchführung dieser Validierung. Wenn die Validierung erfolglos bleibt, dann hält die Zertifikatbehörde 603 die Verarbeitung der Anforderung des Händlers an.
3. Die Zertifikatbehörde 603 prüft ihre interne Datenbank, um zu bestimmen, ob die Zertifikatbehörde 603 dem Händler 201 erlaubt, Dokumente zu veröffentlichen. Die Zertifikatbehörde 603 gestattet keinem unautorisierten Händler, Dokumente zu veröffentlichen. Wenn der Händler nicht autorisiert ist, hält die Zertifikatbehörde 603 die Verarbeitung der Anforderung des Händlers an.
4. Andernfalls verkettet die Zertifikatbehörde 603 das Zertifikat 601, das Nachrichten-Digest 602 und möglicherweise andere Informationen zu einer einzigen Zeichenkette S. Die Zertifikatbehörde 603 berechnet eine digitale Signatur über der Zeichenkette S unter Verwendung des privaten Schlüsselmaterials der CA. Die Zertifikatbehörde 603 stellt sorgfältig sicher, daß das private Schlüsselmaterial der CA ein gut geschütztes Geheimnis ist.
5. Die Zertifikatbehörde 603 sendet eine Nachricht zurück zu dem Händler (Schritt 607). In dieser Nachricht gibt die CA die über die Zeichenkette S berechnete digitale Signatur 604 zurück.
6. Der Händler validiert die digitale Signatur 604 der CA unter Verwendung des öffentlichen Schlüsselmaterials 605 der CA. Der Händler 201 prüft die interne Datenbank des Händlers, um sicherzustellen, daß der Händler 201 die korrekte Zertifikatbehörde 603 verwendet. Wenn der Händler die Zertifikatbehörde 603 nicht weiter benutzen möchte, dann hält der Händler an.
1. Der Kunde 209 sendet ein Zertifikat 701, das das öffentliche Schlüsselmaterial des Kunden 209 enthält, im Schritt 702 zu dem Händler 201 (siehe 7). Dieses Zertifikat 701 wird von einer zweiten Zertifikatbehörde CA' signiert. Die zweite Zertifikatbehörde CA' muß nicht dieselbe wie die Zertifikatbehörde 603 sein, obwohl nicht ausgeschlossen wird, daß die zweite Zertifikatbehörde CA' und die Zertifikatbehörde 603 dieselbe sein können.
2. Der Händler 201 validiert die Signatur des Zertifikats des Kunden und extrahiert dann das öffentliche Schlüsselmaterial des Kunden. Wenn irgendein Aspekt dieses Schritts erfolglos bleibt, dann hält der Händler 201 an.
3. Zum Abschluß des Schrittes 702 autorisiert der Händler unter Verwendung bestimmter Autorisierungskriterien den Kunden. Zum Beispiel kann es der Händler 201 auslassen, einen Kunden 209 zu autorisieren, bis der Händler 201 eine Bezahlung von dem Kunden 209 erhält. Wenn der Händler 201 den Kunden 209 nicht autorisiert, dann hält der Händler 201 an.
4. Der Händler 201 erzeugt eine Schlüsseldatei 705 für den Kunden 209. Die Schlüsseldatei 705 enthält eine Darstellung des öffentlichen Schlüsselmaterials des Kunden, das der Händler 201 aus dem Zertifikat des Kunden extrahiert hat, den Dokumentverschlüsselungsschlüssel K und Benutzerzugriffsrechte (später beschrieben).

Die Erzeugung der Schlüsseldatei 705 wird von einem Schlüsseldateigenerator durchgeführt, bei dem es sich um ein Programm handelt, das in der Anlage des Händlers ausgeführt wird. Der Händler 201 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. Firmenangestellte, die das Paßwort nicht kennen, können keine Schlüsseldateien erzeugen.
Kundenname:	Der Kundenname ist der besondere Name eines Kunden (definiert in [2]), 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 705 auf, die die später beschriebene Kundeninformationszeichenkette (CIS) enthält. Teile der Schlüsseldatei 705 erscheinen dem Kunden 703 als eine völlig zufällige Wertesequenz.
Das Aufbauen der Schlüsseldatei 705 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 705 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 705 speichert die CIS an einer verschiedenen Stelle. Außerdem sind in jede Schlüsseldatei 705 verschlüsselte Kundeninformationen eingebettet, ohne daß der erforderliche Verschlüsselungsl schlüssel enthüllt wird. Durch diese verschlüsselten Kundeninformationen kann ein Händler leicht den Besitzer einer Schlüsseldatei 705 identifizieren, falls die Schlüsseldatei 705 an einem öffentlichen Ort, wie zum Beispiel einem Bulletin-Board, erscheint. Die Schlüsseldatei (oder Teile der Schlüsseldatei) 705 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 705 unter Verwendung des privaten Schlüsselmaterials des Händlers durch Anwenden eines digitalen Signaturalgorithmus.
Eine Schlüsseldatei wird als validiert bezeichnet, wenn das Abfragemittel der Viewer-Anwendung (siehe unten) die Signatur des Händlers unter Verwendung des öffentlichen Schlüsselmaterials validieren kann, das in der Binärdatei des Abfragemittels gespeichert ist, und auf die in der Schlüsseldatei gespeicherte entschlüsselte CIS zugreifen kann. Zusätzlich muß das Abfragemittel den Schlüssel K entdecken, die PF-Datei 404 entschlüsseln, das Hash und die Signatur des Kopfteils der entschlüsselten Datei unter Verwendung des öffentlichen Schlüsselmaterials des Händlers, das aus der Schlüsseldatei 705 extrahiert wurde, validieren und validieren, daß der Nachspann des entschlüsselten Dokuments die wohlbekannte Zeichenkette str ist.
Nach der Erzeugung der Schlüsseldatei 705 sendet der Computer 305 des Händlers die Schlüsseldatei 705 per E-Mail zu dem Kunden 209.
Die CIS ist eine Zeichenkette, die das öffentliche Schlüsselmaterial des Kunden, den Dokumentverschlüsselungsschlüssel K und die Zugriffsrechte des Kunden enthält. Die Zugriffsrechte geben dem Viewer-Programm Informationen, die selektiv Funktionalität ermöglichen. Zum Beispiel kann ein Zugriffsrecht potentiell den Viewer autorisieren, ein graphisches Bild auf einem Monitor anzuzeigen. Ein anderes Zugriffsrecht könnte potentiell dem Viewer gestatten, eine Audiodatei durch die Lautsprecher des Kunden abzuspielen. In bestimmten Fällen könnte man ein Viewer-Programm mit komplexen Zugriffsrechten aufbauen. Zum Beispiel könnte ein Viewer potentiell ein Zugriffsrecht anerkennen, das einem Kunden gestattet, die ersten zehn Minuten eines Films zu betrachten. Voraussichtlich erhalten hochvertrauenswürdige Kunden oder Kunden, die mehr Geld bezahlen, bessere Zugriffsrechte in ihren Schlüsseldateien 705. Zusätzlich enthält die CIS jegliche andere Informationen, die das Beweisschema benötigt.
Es ist beabsichtigt, daß die Schlüsseldatei 705 eine doppelte Verwendung hat – Autorisierung für den Viewer, die PF-Datei 404 anzuzeigen, und Kopierschutz, Lizenzierung oder Verleih des Viewer-Programms.
Kundensoftware
Nachdem der Kunde 305 die Schlüsseldatei 705 installiert hat, gestattet es der Schutzmechanismus dem Kunden 305, ein Viewer-Programm auszuführen, das die PF-Datei 404 benutzt. Je nach den oben beschriebenen Szenarios ist das Viewer-Programm kopiergeschützt, lizenziert und/oder wird geliehen.
Der Viewer wird nur dann ausgeführt, wenn es der Kopierschutz-, der Linzenzierungs- oder der Verleihmechanismus gestattet. Wenn das Viewer-Programm auf irgendeine Weise nicht in der Lage ist, die Schlüsseldatei zu validieren, oder wenn das Viewer-Programm die CIS nicht korrekt extrahieren kann, dann läuft der Viewer nicht.
8 zeigt die Softwarekomponenten, die in der Maschine des Kunden, einem Computer, installiert sein müssen, damit der Kunde 209 die PF-Datei 404 anzeigen kann. Diese bestehen aus einem Schutzserver 804 und einem Viewer 803, wobei der Viewer ein eingebettetes Abfragemittel 802 enthält. Außerdem sind die Schlüsseldatei 705, das private Schlüsselmaterial des Kunden 801 und die PF-Datei 404 gezeigt.
Der Schutzserver 804 ist ein Programm, das der Kunde 209 ausführt, wenn das System zu Anfang gebootet wird. Der Kunde 209 aktiviert das System durch Einlegen einer Diskette, die eine verschlüsselte Kopie des privaten Schlüsselmaterials 801 des Kunden enthält. Der Schutzserver 804 fordert den Kunden 209 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 209 nicht die korrekte Paßphrase angeben kann. Der Schutzserver 804 wird dann im Hintergrund ausgeführt und wartet auf Anforderungen, ein asymmetrisches Beweisprotokoll auszuführen, wie z. B. asymmetrische Vertraulichkeit, probabilistischer Beweis oder digitale Signatur. Der Zweck des asymmetrischen Beweisprotokolls besteht darin, zu beweisen, daß der Schutzserver Zugang zu dem privaten Schlüsselmaterial 801 des Kunden hat.
Es ist zu beachten, daß der Schutzserver 804 das private Schlüsselmaterial 801 außerhalb seiner eigenen Prozeßgrenzen niemals freigibt. Der Schutzserver 804 verwendet Schutzmechanismen des Betriebssystems, um seine eigene Integrität sicherzustellen. Der Schutzserver 804 wird in seinem eigenen Adreßraum ausgeführt und kommuniziert mit externen Prozessen.
Wenn der Abfragemechanismus des Viewer den Mechanismus des Kopierschutzes, der Softwarelizenzierung und/oder des Softwareverleihs wie nachfolgend beschrieben ausführt, bestimmt der Abfragemechanismus, ob der Viewer weiter ausgeführt werden darf. Wenn der Kopierschutz, die Softwarelizenzierung und/oder das Softwareverleihprotokoll erfolglos bleibt, dann wird der Viewer nicht weiter ausgeführt oder wird in einem begrenzten Modus ausgeführt. Andernfalls fährt der Viewer mit der Durchführung der nachfolgend beschriebenen Dienste fort.

1. Erhalten des öffentlichen Schlüsselmaterials. des Händlers. Wenn dieser Schritt erfolglos bleibt, stoppen.
2. Verwendung des öffentlichen Schlüsselmaterials des Händlers zur Neuvalidierung der digitalen Signatur der Schlüsseldatei. Wenn dieser Schritt erfolglos bleibt, stoppen.
3. CIS aus der Schlüsseldatei extrahieren. Wenn dieser Schritt erfolglos bleibt, stoppen.
4. Extrahieren des öffentlichen Schlüsselmaterials der CA, das in dem Abfragemechanismus fest kodiert ist. Wenn dieser Schritt erfolglos bleibt, stoppen.
5. Extrahieren der Signatur 704 der CA des öffentlichen Schlüssels des Händlers und des Nachrichten-Digest der PF-Datei 404. Validieren dieser Signatur unter Verwendung des öffentlichen Schlüssel materials der CA, das in den Abfragemechanismus fest kodiert ist. Wenn dieser Schritt erfolglos bleibt, stoppen.
6. Extrahieren der Zugriffsrechte aus der CIS.
7. Danach, keine Funktionalität gestatten, die nicht explizit in einem oder mehreren der aus der CIS extrahierten Zugriffsrechte aktiviert ist.

Somit ist ersichtlich, daß der Viewer keine Anzeige der PF-Datei gestattet, die nicht explizit in der vom Autor erzeugten Schlüsseldatei zugelassen ist.
Wie in 9 dargestellt, verhindert der Sicherheitsmechanismus außerdem, daß ein Kunde, der autorisiert ist, ein Dokument anzuzeigen, das Dokument zu unautorisierten Kunden weiterleitet. 9 zeigt Angriffsbeispiele:

– 901 bedeutet alle möglichen Angriffe.
– 902 bedeutet einen Angriff, bei dem der Kunde die UF-Datei extrahiert und die UF-Datei dann modifiziert. Der Kunde behauptet dann, der Händler der modifizierten Datei zu sein. Dieser Angriff wird verhindert, da der Viewer dem Kunden nicht den Dokumententschlüsselungsschlüssel K (903) freigibt.
– 904 bedeutet einen Angriff, bei dem der Kunde die UF-Datei nicht modifiziert; der Kunde modifiziert jedoch den Kopfteil. Dieser Angriff wird verhindert, da der Kunde nicht seine eigene Signatur erzeugen kann, da der Kunde nicht den Dokumententschlüsselungsschlüssel kennt. Außerdem kann der Kunde aus demselben Grund (905) den bestehenden Kopfteil nicht modifizieren.
– 906 bedeutet einen Angriff, bei dem der Kunde das UF oder den Kopfteil nicht verändert. Der Kunde verändert jedoch das PF. Dieser Angriff wird verhindert, da jede Änderung an dem PF ohne Kenntnis des Dokumententschlüsselungsschlüssels bewirkt, daß die Nachspannvalidierung erfolglos bleibt (CBC ist ein Vorwärtsfehlerkorrekturcode) (907).
– 908 bedeutet einen Angriff, bei dem der Kunde behauptet, der Händler des ursprünglichen Dokuments zu sein. Die CA verhindert diesen Angriff, indem sie mit mehreren Anforderungen desselben PF-Nachrichten-Digest vergleicht. Zusätzlich wird der Viewer das Dokument letztendlich zurückweisen, da die Kopfteilvalidierung erfolglos bleiben würde.
– 909 bedeutet einen Angriff, bei dem der Kunde einfach die Schlüsseldatei und die PF-Datei zu Anderen weiterleitet. In diesem Fall besitzen die Anderen nicht das zur Validierung der Schlüsseldatei erforderliche private Schlüsselmaterial.

Die obige Beschreibung erklärt, wie das Viewer-Programm eine PF-Datei 404 erhält und anzeigt. Die nachfolgenden Ausführungsformen erläutern, wie das Viewer-Programm kopiergeschützt oder verliehen werden kann.
Ausführungsformen mit Seriennummer
Bei dieser Ausführungsform greift das Antwortmittel sowohl auf das private Schlüsselmaterial als auch auf eine öffentlich bekannte Seriennummer zu. Die Abfrageund Antwortmittel arbeiten wie für die Ausführungsform, die eine digitale Signatur verwendet, beschrieben, mit einer Ausnahme. Das Antwortmittel, d. h. der Schutzserver, besitzt eine eindeutige Seriennummer, die öffentlich bekannt ist, aber in keinem anderen Antwortmittel erscheint. Das Antwortmittel ist so programmiert, daß das Antwortmittel IMMER seine digitale Signatur über die Eingangszeichenkette und die eindeutige Seriennummer berechnet. Der Validierungsschritt des Abfragemittels stellt sicher, daß das Antwortmittel die digitale Signatur über Informationen berechnet, die die korrekte Seriennummer enthalten. Das Abfragemittel erhält die eindeutige Seriennummer aus der Schlüsseldatei. Der Händler hat zuvor die eindeutige Seriennummer in die Schlüsseldatei eingefügt, nachdem diese eindeutige Seriennummer vom Kunden zugeführt wurde.
Es ist also ersichtlich, daß die PF-Datei nur dann betrachtet werden kann, wenn der Kunde das richtige private Schlüsselmaterial und die Schlüsseldatei besitzt. Trotzdem könnten potentiell alle Kunden identische Kopien desselben privaten Schlüsselmaterials besitzen.
Ausführungsform mit asymmetrischer Vertraulichkeit Die Abfrage- und Antwortmittel führen das nachfolgend dargestellte asymmetrische Vertraulichkeitsprotokoll aus.
A ← B: h(r),B, P_A(r,B)
A → B : r
Die Figur verwendet die folgende Notation:

– Das Abfragemittel (der Abfragemechanismus) wird als B bezeichnet (bedeutet außerdem die Identität von B), z. B. „kopiergeschützte PF-Datei x")
– Das Antwortmittel (der Schutzserver) wird als A bezeichnet (bedeutet auch die Identität von A), z. B. „Schutzserver Version 1".
– r bedeutet eine Zufallszahl, die als ein 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 Verschlüsselungsmaterials von A

Das Abfragemittel des Dokuments im geschützten Format erzeugt ein unratbares Nonce (Zufallszahl). Als nächstes berechnet das Abfragemittel h(r) (das Nachrichten-Digest von r).
Der Abfragemechanismus ruft dann eine Verschlüsselungsfunktion in dem Abfragemechanismus auf, um das Nonce und die Identität des Abfragemittels mit dem öffentlichen Schlüsselmaterial des Kunden zu verschlüsseln. Der Abfragemechanismus leitet das Nachrichten-Digest des Nonce h(r), die Indentität des Abfragemittels (die Identität von B) und das Ergebnis der Verschlüsselung E(r) an den Schutzserver mit einer Anforderung, an einem asymmetrischen Vertraulichkeitsbeweis teilzunehmen, weiter.
Wenn der Schutzserver die Anforderung empfängt, entschlüsselt er zunächst 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, daß die Identität B des Abfragemittels korrekt in der Nachricht und in dem entschlüsselten Wert erscheint.
Falls irgendeine Validierung erfolglos bleibt, gibt der Schutzserver einen Mißerfolg zurück, ohne das ent schlüsselte Nonce zurückzugeben. Wenn die Validierung erfolgreich ist, gibt der Schutzserver jedoch das entschlüsselte Nonce r zurück.
Der Abfragemechanismus vergleicht das empfangene entschlüsselte Nonce mit dem Nonce, das der Abfragemechanismus ursprünglich verschlüsselt hat. Wenn sie nicht übereinstimmen, läßt der Abfragemechanismus das geschützte Programm hängen oder stört anderweitig die normale Programmausführung.
Es ist also ersichtlich, daß das Dokument 404 in geschütztem Format nur dann angezeigt werden kann, wenn der Kunde das ordnungsgemäße private Schlüsselmaterial und die Schlüsseldatei 705 besitzt.
Ausführungsform mit probabilistischem Beweis
Die Abfrage- und Antwortmittel führen das nachfolgend dargestellte probabilistische Beweisprotokoll aus (bei dieser Ausführungsform wird das Identifikationsprotokoll nach Guillou-Quizquater beschrieben).
Bei der folgenden Protokollbeschreibung wird der Schutzserver als Teilnehmer A und der Abfragemechanismus als Teilnehmer B bezeichnet.
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) (q – 1.
b. A definiert einen öffentlichen Exponenten ν ≥ 3 mit gcd(ν,Φ) = 1, wobei gcd der größte gemeinsame Teiler ist.
c. A berechnet einen privaten Exponenten s = ν^–1(mod Φ)
d. Systemparameter (ν, 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.
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.
Die Protokollnachrichten des GQ-Beweisprotokolls sind nachfolgend angegeben:
– A → B: I, x = r^ν(mod n) (1)
– B → A: e (mit 1 ≤ e ≤ ν) (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.
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.

Wenn der Abfragemechanismus als Teilnehmer B den Identitätsbeweis von A nicht annimmt, dann läßt der Abfragemechanismus das geschützte Programm hängen bleiben oder stört anderweitig die normale Programmausführung.
Es ist also ersichtlich, daß das Dokument 404 in geschütztem Format nur dann normal weiter ausgeführt wird, wenn der Kunde das ordnungsgemäße private Schlüsselmaterial und die Schlüsseldatei 705 besitzt.
Ausführungsform mit digitaler Signatur
Unter Verwendung der digitalen Signatur ist der Mechanismus wie folgt.
Der Abragemechanismus des Dokuments in geschütztem Format erzeugt ein unratbares Nonce und leitet das Nonce mit einer Anforderung einer digitalen Signatur an den Schutzserver weiter.
Wenn er das Nonce empfängt, prüft der Schutzserver zuerst, daß das ihm präsentierte Nonce einem gegebenen Format entspricht. Wenn dies nicht der Fall ist, verweigert der Schutzserver die Signaturanforderung. Unter der Annahme, daß das Nonce im korrekten Format vorliegt, verwendet der Schutzserver eine kryptographische Engine, um das Nonce unter Verwendung des privaten Schlüsselmaterials des Kunden zu signieren. Der Schutzserver gibt dann das signierte Nonce an den Abfragemechanismus in dem Programm zurück, daß das Dokument in geschütztem Format verwendet.
Wenn er das signierte Nonce empfängt, greift der Abfragemechanismus auf die dem Dokument im geschützten Format zugeordnete Schlüsseldatei zu und ruft eine Signaturvalidierungsfunktion in dem Abfragemechanismus auf, um die Signatur des Händlers der Schlüsseldatei unter Verwendung des öffentlichen Schlüsselmaterials des Händlers, das in den Abfragemechanismus eingebettet ist, zu validieren. Wie im Fall aller Ausführungsformen der vorliegenden Erfindung stellt diese Validierung der Schlüsseldateisignatur sicher, daß ein Angreifer die Schlüsseldatei oder ihre digitale Signatur nicht modifizieren kann, ohne zusätzlich den Abfragemechanismus zu modifizieren. Wahlweise kann der Händler diesen Schutz durch Verwendung zusätzlicher proprietärer Verteidigungslinien ergänzen. Wenn die Schlüsseldatei modifiziert wurde, läßt der Abfragemechanismus das Programm hängen.
Vorausgesetzt, daß die Signatur validiert wird, analysiert der Abfragemechanismus dann die Schlüsseldatei unter Verwendung eines proprietären autorenspezifischen Algorithmus, um das öffentliche Schlüsselmaterial des Kunden zu finden. Der Abfragemechanismus ruft dann seine Signaturvalidierungsfunktion auf, um die digitale Signatur zu validieren, die unter Verwendung des öffentlichen Schlüsselmaterials des Kunden über das Nonce berechnet wurde. Wenn die Signatur nicht gültig ist, bleibt der Abfragemechanismus hängen oder arbeitet auf begrenzte Weise. Es ist also ersichtlich, daß das Dokument in geschütztem Format nur dann angezeigt werden kann, wenn der Kunde das ordnungsgemäße private Schlüsselmaterial und die Schlüsseldatei besitzt.
Der Nonce-Generator
Die Erzeugung eines Nonce wird von einem in dem Abfragemechanismus enthaltenen Vonce-Generator durchgeführt. Die Funktionsweise des Nonce-Generators ist wie folgt (siehe 10).
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 in dem 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. 10 zeigt die Funktionsweise von Thread 1, dem Haupt-Thread des Zufallszahlengenerators.
(Box 1001) Thread 1 erzeugt zuerst eine Datenstruktur value list zum Halten einer Liste von Zählerwerten. Die Liste ist zu Anfang leer.
(Box 1002) Thread 1 setzt einen aktuellen Zählerwert auf Null und setzt ein done_test-Flag auf FALSE.
(Box 1003) Thread 1 erzeugt dann Thread 2. Thread 2 gibt einen asynchronen Platter zugriff 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 1004) Thread 1 erhöht den Zählerwert um Eins.
(Box 1005) 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 1006) 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 1007) 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 [5] 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 1008) 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 1002 zurück, um so einen weiteren Zählerwert zu erzeugen und zu sichern.
(Box 1009) 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 bei einer Platte des Typs Quantum 1080s (mittlere Schreibzeit 6 ms) und einem 468-66-Mhz-Prozessor das System 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 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 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 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 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.
Software-Verleihmechanismus
11 zeigt die Architektur des Systems 1100. Potentiell sind mehrere Anwendungen (Programme) von Software auf dem System verankert, wobei jede Anwendung ihre eigene Schlüsseldatei besitzt. 11 zeigt drei Anwendungen, ein Textverarbeitungsprogramm 1104, eine Tabellenkalkulation 1105 und eine andere Anwendung 1106, die auf Schlüsseldateien 1101, 1102 bzw. 1103 zugreifen. In bestimmten Fällen können sich mehrere Anwendungen 1104, 1105, 1106 eine gemeinsame Schlüsseldatei teilen.
Jede der Anwendungen 1104, 1105, 1106 greift auf ihre Schlüsseldatei 1101, 1102 und 1103 zu, um das öffentliche Schlüsselmaterial des Kunden aus der CIS zu extrahieren.
Jeder Anwendungshändler fügt Verleihanweisungen in ein kopiergeschütztes Programm ein. Diese Verleihanweisungen erzeugen Protokollierungsdatensätze, z. B. 1109, 1110, 1111. Zum Beispiel erzeugt das Textverarbeitungsprogramm 104 während der Ausführung des Textverarbeitungsprogramms 1104 alle 15 Minuten den folgenden Protokollierungsdatensatz: „Die Textverarbeitung WP mit dem öffentlichen Schlüssel 9828a8c12a5873654bac684517d3afe3 ist 15 Minuten lang gelaufen" (man beachte, daß der Datensatz anstelle des öffentlichen Schlüsselmaterials selbst das Nachrichten-Digest des öffentlichen Schlüsselmaterials speichern könnte). Als nächstes sendet die Anwendung ihren Protokollierungsdatensatz zu einem Verleih-Server 1107. Am Ende eines sicheren Audit-Verlaufs 1108, der an einer potentiell unsicheren Speicherstelle, z. B. in einer Datei auf einer Platte, gespeichert wird, fügt der Verleih-Server 1107 den Protokollierungsdatensatz ein. Der Verleih-Server 107 verwendet zur Unterstützung eine Chipkarte 1112 zur Sicherheit.
Eine Anwendung, z. B. 1104, 1105 oder 1106, kann wählen, einen Protokollierungsdatensatz zu erzeugen, der jede beliebige Kette von Bit mit beliebiger Länge enthält. Zusätzlich zu oder anstelle des Aufzeichnens der Zeit könnte eine Anwendung potentiell protokollieren, wie oft die Anwendung oder ein bestimmtes ihrer Module ausgeführt wird. Z. B. könnte ein SS 105 potentiell jedes Mal dann, wenn SS gebootet wird, einen einzigen Protokollierungsdatensatz anhängen: „Die Anwendung SS mit dem öffentlichen Schlüssel 768230aac8239d9df88cfe3c7b832a wird ausgeführt". Verschiedene Arten von Audit-Datensätzen, z. B. die Benutzungszeit oder wie oft die Benutzung aufgetreten ist, können in demselben Audit-Verlauf erscheinen. Mehrere verliehene Anwendungen können gleichzeitig denselben Audit-Verlauf benutzen.
Man erhält einen Software-Verleih durch Vergleichen von Schwellen mit dem Audit-Verlauf. 12 zeigt einen Kunden 209, der Software von einem Händler 201 leiht. Als erstes sendet der Kunde 209 eine Anforderung, die Software zu leihen, zu dem Händler 201 in einer Bestellanforderung 1203. Bei diesem Beispiel kauft der Kunde 6 Stunden der Anwendung 1104. Nach Erhalt der Bezahlung sendet der Händler eine Schlüsseldatei 1101 zu dem Kunden, die eine Benutzungsautorisierung enthält. In diesem Fall erlaubt die Schlüsseldatei 1101 6 Stunden der Ausführung durch die Anwendung 1104. Die später beschriebene Schlüsseldatei 1101 kann potentiell andere Informationen enthalten, wie z. B. Kopierschutzoder Lizenzierungsinformationen.
Periodisch untersucht die verliehene Anwendung, z. B. das Textverarbeitungsprogramm (die Anwendung) 1104 den Audit-Verlauf 1108. Wenn der Audit-Verlauf 1108 nicht gültig ist, dann gestattet sich das Textverarbeitungsprogramm 1104 nicht, verliehen zu werden. Wenn der Audit-Verlauf 1108 jedoch gültig ist, dann analysiert die Anwendung 1104 den Audit-Verlauf und vergleicht die Analyse mit der Schlüsseldatei 1101. Zum Beispiel zählt die Anwendung 1104 die Anzahl von Protokollierungsdatensätzen, die 15-Minuten-Intervalle beschreiben. Als nächstes betrachtet die Anwendung 1104 die Schlüsseldatei 1101, um eine Verleihschwelle zu finden, die bei dem vorliegenden Beispiel 6 Stunden beträgt (24 15-Minuten Intervalle). Wenn die Anwendung 1104 weniger als 24 ihrer Protokollierungsdatensätze findet, die 15-Minuten-Intervalle bezeichnen, dann wird die Anwendung 104 weiter ausgeführt. Andernfalls gestattet sich die Anwendung 1104 nicht, verliehen zu werden. Im letzteren Fall muß der Kunde eine neue Schlüsseldatei kaufen, um die Anwendung 1104 weiter zu leihen. Wenn die Anwendung 1104 ihre Verleihschwelle überschreitet, dann werden andere Anwendungen, z. B. die Tabellenkalkulation 1105 und die andere Anwendung 106, nicht beeinträchtigt. Das heißt, jede verliehene Anwendung sieht ihre eigenen Datensätze aus dem Audit-Verleih, ohne von anderen Anwendungen erzeugte Datensätze zu interpretieren.
Aus der obigen Besprechung ist ersichtlich, daß die Architektur einen Software-Verleih implementiert, solange die verliehenen Anwendungen, z. B. 1104, 1105, 1106, den Audit-Verlauf 1108 eindeutig validieren können. Die folgenden Eigenschaften sollten erfüllt sein:

1. Löcher: Eine verliehene Anwendung, z. B. das Textverarbeitungsprogramm 1104, validiert bei diesem Beispiel, daß der Audit-Verlauf alle Datensätze enthält, die jemals geschrieben wurden, und zwar ungeachtet der Anwendung. Wenn eine Anwendung zuvor zehn Protokollierungsdatensätze geschrieben hat, dann würde die verliehene Anwendung, z. B. das Textverarbeitungsprogramm 1104, den Audit-Verlauf nicht validieren, wenn die verliehene Anwendung nicht alle zehn Protokollierungsdatensätze finden konnte. Es wird ein Fehlen von Löchern gefordert, da man einem Angreifer nicht gestatten will, einzelne Protokollierungsdatensätze zu löschen, um einen Benutzungsdatensatz zu zerstören.
2. Modifikation: Eine Anwendung, z. B. das Textverarbeitungsprogramm 1104, muß eindeutig schließen, daß kein unautorisierter Angreifer jegliche der Protokollierungsdatensätze des WP modifiziert hat. Andernfalls könnte zum Beispiel der Angreifer alle 15-Minuten-Protokollierungsdatensätze in 15-Sekunden-Protokollierungsdatensätze umwandeln, um die Zeit, für die die Software ausgeführt werden kann, drastisch zu erhöhen.
3. Aktuell: Eine verliehene Anwendung muß in der Lage sein, zu validieren, daß der Audit-Verlauf 1108 aktuell ist. Andernfalls könnte der Audit-Verlauf 1108 potentiell alt sein und somit relativ neue Audit-Datensätze 1109, 1110, 1111 verbergen. Zum Beispiel wünscht man nicht, daß ein Angreifer den Sicherungsund Wiederherstellungsangriff durchführen kann.

Diese drei Eigenschaften entfernen jeglichen Anreiz für einen Angreifer, einen Audit-Verlauf 1108 zu verfälschen, zu löschen, zu verlieren oder anderweitig zu mißbrauchen. Wenn der Angreifer den Audit-Verlauf 1108 ungültig machen sollte, dann würden alle verliehenen Anwendungen 1104, 1105, 1106 den Mißbrauch identifizieren und ein Verleihen nachfolgend verweigern.
Um Sicherheit bereitzustellen, erfordert die Architektur eine Chipkarte 1112, die eine asymmetrische Kryptographie durchführt. Bei dem vorliegenden Beispiel führt die Chipkarte 1112 digitale Signaturen aus. Die Chipkarte 1112 enthält privates Schlüsselmaterial 1301 und einen Zähler 1302 (siehe 13).
Wenn der Kunde die Chipkarte 1112 erhält, befindet sich die Chipkarte 1112 in einem sicheren Zustand. Die Chipkarte liefert genau zwei Dienste, die entweder auf das private Schlüsselmaterial oder den Zähler zugreifen: SignAndIncrement() und GetCounter(), die in dem folgenden Pseudoprogrammcode beschrieben werden (man beachte, daß das Symbol // einen Kommentar und ← den Zuweisungsoperator bedeuten): Signature SignAndIncrement (HASH h) // h ist ein Nachrichten-Digest
BEGIN

[1] Berechnen des Nachrichten-Digest von h und des Zählers der Chipkarte, d. h. h' ← hash(h,counter)
[2] Signieren von h' mit dem privaten Schlüsselmaterial
[3] Erhöhen des Zählers der Chipkarte um Eins
[4] Zurückgeben der im Schritt [2] berechneten digitalen Signatur

integer GetCounter()
BEGIN

[1] Zurückgeben des aktuellen Werts des Zählers der Chipkarte

Man betrachte das folgende Verfolgungsbeispiel. Man nehme an, daß der Zähler der Chipkarte einen Anfangswert von 6 hat und daß man die folgenden Operationen ausführt:

(i) Signature 1 ← SignAndIncrement (hash(„m1"))
(ii) Signature 2 ← SignAndIncrement (hash(„m2))
(iii) int1 ← GetCounter()

Die Ergebnisse dieses Beispiels lauten:

– Signature 1 erhält die digitale Signatur (unter Verwendung des privaten Schlüsselmaterials der Chipkarte) von hash(hash(„m1"),6)
– Signature 2 erhält die digitale Signatur (unter. Verwendung des privaten Schlüsselmaterials der Chipkarte) von hash(hash(„m2"),7)
– int1 erhält 8

Der Audit-Verlauf 1108 enthält eine Liste von Datensätzen, wobei jeder Datensatz vier Felder aufweist: nonce, string, counter und signature. Die Dateneingabe in signature ist hash(hash(nonce,string),counter). 14 zeigt einen beispielhaften Audit-Verlauf mit vier Datensätzen. In dem ersten Datensatz hat das Nonce den Wert 96, die Zeichenkette ist „WP 15 Minuten öffentlicher Schlüssel 9828a8c12a5873654bac684517d3afe3" (wobei 9828a8c12a5873654bac684517d3afe3 das Nachrichten-Digest eines echten öffentlichen Schlüssels bedeutet), der Wert des Zählers ist Null und die digitale Signatur ist von hash(hash(96, „WP 15 Minuten öffentlicher Schlüssel 9828a8c12a5873654bac684517d3afe3"),0). Dabei wurde die digitale Signatur unter Verwendung von privatem Schlüsselmaterial bereitgestellt, das öffentlichem Schlüsselmaterial 9828a8c12a5873654bac684517d3afe3 entspricht. Dieses öffentliche Schlüsselmaterial kann aus der Schlüsseldatei des WP extrahiert werden.
Der Zähler läuft niemals von seinem höchsten Wert auf Null über. Wenn der Zähler seinen höchsten Wert, z. B. 2¹²⁸ – 1, erreicht, hält das System an.
Eine verliehene Anwendung hängt durch Ausführen der Write-Routine einen Datensatz an den Audit-Verlauf an, wobei die Write-Routine in die verliehenen Anwendungen eingebettet ist. Diese Routine erzeugt einen Audit-Datensatz und sendet den Audit-Datensatz dann zu dem Verleih-Server 1107. Der Verleih-Server 1107 schreibt den Audit-Datensatz in ein nicht flüchtiges stabiles Bild des Audit-Verlaufs, z. B. in eine oder mehrere Dateien. Der Verleih-Server 1107 synchronisiert den Zugriff auf die Chipkarte 1112 und den Audit-Verlauf. Der Verleih-Server 1107 kann nicht so ausgeführt werden, daß er die Systemsicherheit durchkreuzt, d. h. die verliehenen Anwendungen vertrauen dem Verleih-Server 1107 nicht. Wenn der Verleih-Server 1107 falsch handeln würde, könnte potentiell eine Dienstverweigerung stattfinden, da es der Fall sein kann, daß die verliehenen Anwendungen den Audit-Verlauf nicht validieren konnten.
Die Write-Routine wird nachfolgend im Pseudoprogrammcode angegeben:
Boolean Write(String str)
BEGIN

[1] n ← neues Nonce erzeugen
[2] h1 ← hash( n,str)
[3] s ← SignAndIncrement (h1) // nachfolgend ist c eine lokale Kopie des Werts in der Chipkarte
[4] c ← GetCounter() // nachfolgend hat ein Erniedrigen um 1 keine Wirkung auf die Chipkarte
[5] decrement c by 1
[6] h2 ← hash(h1,c)
[7] Validieren, daß s die Signatur von h2 ist, im Vergleich zu dem öffentlichen Schlüssel, der in der Schlüsseldatei gefunden wird (wenn die Validierung erfolglos bleibt, dann sofort Mißerfolg zurückgeben, ohne jegliche weitere Schritte auszuführen).
[8] Verleih-Datensatz r ← <n,str,c,s> erzeugen
[9] r an den Audit-Verlauf anhängen
[10] TRUE zurückgeben, wenn alle vorausgehenden Schritte erfolgreich sind, andernfalls Mißerfolg zurückgeben

Die ValidateTrail-Routine ist ebenfalls in die verliehene Anwendung eingebettet und sollte periodisch ausgeführt werden und wird nachfolgend im Pseudoprogrammcode angegeben (man nehme an, daß das System mit einem Anfangszählerwert von Null gestartet hat):
Boolean ValidateTrail()
BEGIN

[1] c ← GetCounter()
[2] Write(c) // die obige Write-Routine verwenden, // Ende bei Mißerfolg
[3] r ← letzter Datensatz im Audit-Verlauf // dies ist der Datensatz, der gerade im Schritt [2] geschrieben wurde
[4] Validieren der in r gespeicherten Signatur im Vergleich zu dem in der Schlüsseldatei gespeicherten öffentlichen Schlüssel
[5] Validieren, daß c mit dem in r gespeicherten Zähler übereinstimmt
[6] FOR i←0 UNTIL keine weiteren Datensätze, INCREMENT i um 1
[6.1] r ← i-ter Datensatz aus dem Audit-Verlauf
[6.2] Validieren der in r gespeicherten Signatur im Vergleich zu dem in der Schlüsseldatei gespeicherten öffentlichen Schlüssel
[6.3] Validieren, daß i mit dem in r gespeicherten Zähler übereinstimmt
[7] END FOR LOOP
[8] wenn alle obigen Schritte erfolgreich sind, TRUE zurückgeben, andernfalls FALSE zurückgeben

In den Schritten [4] und [6.2] stammen alle Eingaben für die Validierung aus dem Audit-Datensatz selbst. Durch sorgfältige Analyse aller Schritte in den Routinen Write und ValidateTrail ist es klar, daß jeder Angriff, der die beabsichtigte Verwendung dieser Routinen durchkreuzt, einen Mißerfolg verursacht. In diesem Fall bemerken die verliehenen Anwendungen den Mißerfolg und gestatten sich nicht, ausgeliehen zu werden.
Der Mechanismus zur Wiederherstellung nach einem Mißerfolg hängt von dem Händler für jede bestimmte verliehene Anwendung ab. Der Händler kann zum Beispiel auf Anforderung bestimmter Kunden eine neue Schlüsseldatei ausgeben. Das bedeutsamste Problem ist möglicherweise die Wiederherstellung nach einem versehentlichen Verlust des Audit-Verlaufs, der aufgrund eines Plattenfehlers auftreten kann. Um vor dieser Situation zu schützen, sollte der Verleih-Server 1107 für das Schreiben aller Datensätze in den Audit-Verlauf im Namen aller verliehenen Anwendungen verantwortlich sein. Der Verleih-Server sollte einen primären Audit-Verlauf auf der lokalen Festplatte und mindestens einen Sicherungs-Audit-Verlauf auf einem separaten Medium, z. B. einer Diskette oder einem Netzwerk-Dateiserver, führen. Man kann zum Beispiel einen Dienst bereitstellen, durch den der Verleih-Server Audit-Verläufe zu einem gesicherten Netzwerk-Sicherungs-Dienst e-mailen kann. In diesem Fall kann man Vertraulichkeit sicherstellen, indem dem Verleih-Server gestattet wird, den Audit-Verlauf vor der Übertragung zu verschlüsseln.
Bestimmte mögliche Modifikationen
Bei einer alternativen Ausführungsform der Erfindung kann das öffentliche Schlüsselmaterial des Kunden, das in der Schlüsseldatei gehalten wird, kryptographisch gesichert werden, wodurch es rechnerisch impraktikabel wird, irgendeinen Teil der Schlüsseldatei zu verändern, einschließlich des öffentlichen Schlüsselmaterials des Kunden, ohne das Abfragemittel zu verändern. Das heißt, die Schlüsseldatei wird mit dem privaten Schlüsselmaterial des Händlers signiert, und das öffentliche Schlüsselmaterial des Händlers wird in das Abfragemittel codiert.
Außerdem kann die Schlüsseldatei Informationen enthalten, die den Kunden identifizieren, dem die geschützte PF-Datei geliefert wurde.
Statt im Internet oder im allgemeinen in einem Kommunikationsnetz, kann die PF-Datei bzw. können die PF-Dateien auch auf einem anderen Medium, z. B. der CD-ROM, gespeichert werden.
Weiterhin kann der Übersetzer die UF-Datei unter Verwendung digitaler Wasserzeichen (Fingerabdrücke) markieren. Verschiedene Arten von Wasserzeichen werden in [7] beschrieben und verwenden z. B. etwas verschiedene Abstände zwischen Buchstaben oder modifizierte Schriftarten oder einen ungewöhnlichen Zeilenabstand.
Der Viewer nimmt ein PF nur dann an, wenn der Viewer zuerst die UF-Datei erhalten und dann das Wasserzeichen finden und validieren kann. Dieses Wasserzeichen ist ein Geheimnis.
Nach dem Extrahieren der UF-Datei aus der PF-Datei kann der Viewer ein Wasserzeichen einfügen, das einzigartig für den Kunden ist. Wenn der Kunde eine unautorisierte Kopie des Dokuments anfertigen sollte, würde auf diese Weise die unautorisierte Kopie ein Wasserzeichen enthalten, das den Kunden eindeutig identifiziert. Während die vorliegende Erfindung eine einfache Konstruktion unautorisierter elektronischer Kopien verhindert, könnte der Kunde potentiell eine Kamera verwenden, um Bilder einer Anzeige aufzunehmen, und dann Kopien dieser Bilder verteilen.
Die Schlüsseldatei kann mehr als ein CIS-Stück enthalten, die, wenn sie kombiniert werden, eine einzige CIS bilden. Als Folge muß der Händler nicht alle Kundeninformationen, z. B. öffentlicher Schlüssel und Zugriffsrechte des Kunden, zu einer einzigen zusammenhängenden Kette verketten.
Die CA und der Händler könnten entweder in einem einzigen administrativen Bereich verankert sein, oder in verschiedenen administrativen Bereichen. Im ersten Fall kann der Händler Dokumente ohne die dauernde Unterstützung einer außenstehenden CA verteilen. Im letzteren Fall liefert die außenstehende CA zusätzliche Sicherheitsversicherungen. Im Fall einer außenstehenden CA sollte von allen Händlern verlangt werden, eine rechtsgültige Vereinbarung zu unterzeichnen, die die Verwendung der CA zum Zwecke des Betrugs verhindert.
Der Übersetzer kann bei der Erzeugung der PF-Datei das UF zweimal verschlüsseln. Jede Verschlüsselung verwendet einen verschiedenen symmetrischen Schlüssel K und K'. Der Händler legt den Schlüssel K in der CIS ab. Der Händler verschlüsselt K' unter Verwendung des öffentlichen Schlüsselmaterials des Kunden und legt das verschlüsselte Ergebnis dann in der Schlüsseldatei ab. Der Viewer kann K' nur dann entschlüsseln, wenn der Kunde das korrekte private Schlüsselmaterial besitzt.

– Kein Angreifer kann den Schlüssel K entdecken, wenn er nicht die Sicherheitsmechanismen überwindet, die die Schlüsseldatei schützen.
– Da das private Schlüsselmaterial des Kunden sicher in einer Chipkarte oder in einem Schutzserver gespeichert ist, kann der Viewer keinen Zugriff auf das private Schlüsselmaterial erhalten. Somit muß der Viewer das verschlüsselte K' der Chipkarte oder dem Schutzserver zur Entschlüsselung geben. Der Kunde könnte potentiell das Ergebnis der Entschlüsselung mithören und K' erhalten. Durch Verwendung der beiden Schlüssel erhöht dieser Mechanismus dennoch die Gesamtsicherheit des Systems.

Vor der Verschlüsselung, der Berechnung von Nachrichten-Digests und der Berechnung von Signaturen könnte der Übersetzer die UF-Datei auf eine Weise modifizieren, die spezielle Semantik der UF-Datei verbirgt. Wenn zum Beispiel Standard-Viewer für die UF-Datei existieren, dann könnte der Übersetzer Nicht-Standard-Befehle einfügen, die diese Standard-Viewer brechen. Wenn ein Angreifer also alle Sicherheitsmechanismen der vorliegenden Erfindung brechen und die UF-Datei erhalten sollte, könnte der Angreifer nicht ohne Weiteres jeden beliebigen Standard-Viewer zur Anzeige der UF-Datei nutzen.
Jegliches oder alles private Schlüsselmaterial, das in der vorliegenden Erfindung beschrieben wird, könnte sicher auf einer Chipkarte gespeichert werden. Die Chipkarte hat die Eigenschaft, daß die Chipkarte unter Verwendung des privaten Schlüsselmaterials asymmetrische kryptographische Operationen durchführt. Die Chipkarte gibt niemals außerhalb des Umfangs der Chipkarte das private Schlüsselmaterial in unverschlüsselter Form frei. Somit ist ersichtlich, daß eine Chipkarte das private Schlüsselmaterial nicht offenlegt.
Um die Leistungsfähigkeit der Verleihausführungsform zu verbessern, könnte man das System mit einem vertrauenswürdigen Audit-Verlauf-Validierungsdienst ergänzen. Hierbei validiert der vertrauenswürdige Dienst periodisch einen Audit-Verlauf und hängt einen neuen Audit-Datensatz an, den Validiererdatensatz, der sich sicher für die vorherigen Datensätze verbürgt. Informationen, die der Validiererdatensatz enthalten kann, sind zum Beispiel eine digitale Signatur des Nachrichten-Digest (hash) aller vorausgehenden Audit-Datensätze in dem Audit-Verlauf (die digitale Signatur verwendet den privaten Schlüssel des Audit-Validierungsdienstes). Von nun an müssen verliehene Anwendungen keine digitalen Signaturen der Datensätze validieren, die dem Validiererdatensatz vorausgehen. Der Audit-Verlauf-Validierungsdienst könnte von einem Dritten implementiert werden, der über ein Netzwerk oder eine E-Mail--Verbindung zugänglich ist.
Bei den Schritten [5] und [6.3) der ValidateTrail-Prozedur ist es möglich, daß der Zählerwert des anfänglichen Datensatzes nicht Null ist. In diesem Fall beginnt der Zählerwert mit offset, und die Schritte [5] und [6.3] müssen offset bei dem Vergleich berücksichtigen.
Man beachte, daß der Händler der verliehenen Anwendung sich darauf verläßt, daß die Chipkarte vermeidet, das private Schlüsselmaterial freizugeben. Außerdem verläßt sich der Händler der verliehenen Anwendung darauf, daß die Chipkarte ihr privates Schlüsselmaterial in keinen anderen Funktionen als SignAndIncrement und GetCounter verwendet. Der Händler der verliehenen Anwendung kann wünschen, den Chipkartenhersteller und/oder -personalisierer zu validieren.
Ein Händler kann eine Anwendung erzeugen und verteilen, nachdem ein Kunde eine Chipkarte erhält. In diesem Fall erzeugt der Händler einfach eine Software-Verleih-Schlüsseldatei für den Kunden und sendet die Schlüsseldatei zu dem Kunden (möglicherweise nach Erhalt einer Bezahlung).
Universelles privates Schlüsselmaterial
Bei einer Variante des beispielhaften Mechanismus leihen alle Kunden die Software unter Verwendung desselben Paars von öffentlichem bzw. privatem Schlüssel aus. Dabei verläßt sich der Händler darauf, daß die Chipkarte korrekt arbeitet und niemals den Wert des privaten Schlüsselmaterials außerhalb der Chipkarte herausgibt. Wie im Fall von 13 enthält die Chipkarte sowohl das private Schlüsselmaterial 1301 als auch den Zähler 1302. Zusätzlich enthält die Chipkarte eine eindeutige Seriennummer, wobei niemals zwei Chipkarten dieselbe Seriennummer aufweisen. Schritt [1] der Routine SignAndIncrement, die auf der Chipkarte implementiert wird, unterscheidet sich von dem oben beschriebenen wie folgt:

[1] Berechnen des Nachrichten-Digest von h und der Seriennummer und des Zählers der Chipkarte, d. h. h' ← hash(h,serial_number,counter)

Zusätzlich zu den Routinen SignAndIncrement und GetCounter stellt die Chipkarte außerdem die GetSerialNumber-Routine bereit:
String GetSerialNumber()
BEGIN

[1] zurückgeben der Seriennummer der Chipkarte

In dem durch 1203 abgebildeten Schritt sendet der Kunde zusätzlich die Seriennummer seiner Chipkarte. Die Schlüsseldatei 705 enthält die folgenden Informationen:

– Das von allen Kunden gemeinsam benutzte universelle öffentliche Schlüsselmaterial
– Die eindeutige Seriennummer der Chipkarte des Kunden

Die in der Protokollierungsdatei gespeicherten Hash-Datensätze berücksichtigen die Seriennummer. Zum Beispiel weist der erste Hash-Datensatz von 14 die folgenden Informationen für eine Nachrichtensignatur auf
Signatur von hash(hash(96,WP...),serial number,0)
Der Schritt [6] der Write-Routine hat die folgende Modifikation:
[6] h2 ← hash(h1,serial_number,c)
Die Schritte [4] und [6.2] der ValidateTrail-Routine müssen die Seriennummer benutzen (andernfalls würden sie immer erfolglos bleiben). Das Transportmittel, das die Routinen Write und ValidateTrail zum Erhalt der Seriennummer der lokalen Chipkarte verwenden, soll hier nicht spezifiziert werden. Man könnte zum Beispiel die Chipkarte ein einziges Mal abfragen und dann die Seriennummer in einer Datei in dem lokalen Dateiensystem speichern.
Der Softwarehändler könnte potentiell eine verliehene Anwendung mit einer komplexen Schwellenberechnung ausstatten. Zum Beispiel kann der Händler Blöcke von 1000 Einheiten verleihen. Für jede Stunde, für die die Software zwischen 20.00 (8 Uhr nachmittags) und 6.00 (6 Uhr morgens) am nächsten Morgen ausgeführt wird, definiert der Protokollierungsdatensatz eine Einheit; und für jede Stunde in einem anderen Teil des Tages definiert der Protokollierungsdatensatz zwei Einheiten. Also könnte ein Kunde zum Beispiel potentiell die Software für 1000 Nachtstunden, 500 Tagesstunden oder eine bestimmte berechnete Kombination von Nacht- und Tagesstunden benutzen.
Man beachte, daß in der vorliegenden Erfindung beschrieben wird, daß der Händler einen Kunden autorisiert, eine Datei zu betrachten, indem er dem Kunden eine Schlüsseldatei mit dem öffentlichen Schlüsselmaterial des Kunden gibt.
Zusätzlich kann der Händler einen Verteiler für folgendes autorisieren:

1. Autorisierung der Verteilung und/oder
2. Autorisierung Anderer, Verteiler zu sein, indem dem Verteiler das private Schlüsselmaterial des Händlers gegeben wird.

Zusätzlich kann der Händler mindestens einen zweiten Verteiler für folgendes autorisieren:

1. Autorisierung der Verteilung, aber nicht
2. Autorisierung Anderer, zu verteilen, durch Verwendung der folgenden Technik.

Der Händler signiert ein Zertifikat, das das öffentliche Schlüsselmaterial des zweiten Verteilers enthält. Der zweite Verteiler signiert Schlüsseldateien mit dem privaten Schlüsselmaterial des zweiten Verteilers (anstelle der Signatur des Händlers von Schlüsseldateien). In dem Schlüsseldateivalidierungsschritt des Abfragemittels validiert das Abfragemittel das Zertifikat des zweiten Verteilers unter Verwendung des öffentlichen Schlüsselmaterials des Händlers, das in das Abfragemittel eingebettet ist. Das Abfragemittel verwendet danach das öffentliche Schlüsselmaterial des zweiten Verteilers zur Validierung von Schlüsseldateien.
Die folgenden Publikationen werden in der vorliegenden Schrift zitiert:

[1] Cryptolope Container Technology, International Business Machines, erhältlich auf dem World Wide Web 3.3.97 http://www.cryptolope.ibm.com/white.htm.
[2] A. Menezes et al, Handbook of Applied Cryptography, CRC Press, Inc. ISBN 0-8493-8523-7, S. 22–23, 224–233, 250–259, 308–311, 405–424, 433–438, 572–577, 1997
[3] R. Rivest, The MD5 message-digest algorithm, RFC 1321, April 1992.
[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] D . Knuth, The Art of Computer Programming, Band 2 , Seminumerical Algorithms, Addison-Wesley Publishing Co., Reading MA, 2. Auflage, 1981, S. 38–73, ISBN 0-201-03822-6.
[6] 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 zu ITU-T Rec. X.509, 1993).
[7] J. Brasil et al, Electronic marking and identification techniques to discourage document copying, IEEE INFOCOM 94, S. 1278–1287, 1994

Claims

Computersystem mit einem Schutzmechanismus zum Schutz des Inhalts einer Datei, wobei der Schutzmechanismus mindestens ein Viewer-Programm, mindestens ein dem Viewer-Programm zugeordnetes Abfragemittel und die Datei umfaßt, sowie ein Antwortmittel mit privatem Schlüsselmaterial, auf das es zugreifen kann, wobei a) das Abfragemittel keinen Zugriff auf das private Schlüsselmaterial hat und in ihm gespeichertes öffentliches Schlüsselmaterial verwendet b) das Antwortmittel ein Mittel zum Beweisen umfaßt, daß es Zugriff auf das private Schlüsselmaterial hat, durch Wechselwirkung mit dem Abfragemittel unter Verwendung eines asymmetrischen kryptographischen Schemas, c) das Abfragemittel ein Mittel zur Verhinderung der Verwendung eines Teils des Inhalts der Datei oder des gesamten Inhalts der Datei, solange der Beweis nicht erfolgreich ist, umfaßt.
Computersystem nach Anspruch 1, wobei die Verwendung ein Anzeigen oder Ausdrucken ist.
Computersystem nach einem der Ansprüche 1 bis 2, mit einer Zertifikatbehörde, die ein öffentliches Schlüsselpaar verfügbar macht.
Computersystem nach Anspruch 3, wobei – die Zertifikatbehörde öffentliches Schlüsselmaterial und/oder die Datei mit einem privaten Schlüsselmaterial der Zertifikatbehörde signiert, – es zu einem Computer des Händlers sendet und – der Computer des Händlers das öffentliche Schlüsselmaterial und/oder die Datei validiert.
Computersystem nach einem der vorhergehenden Ansprüche, wobei das asymmetrische kryptographische Schema eines der folgenden Schemata ist: – ein probabilistisches Beweisschema, – ein asymmetrisches Vertraulichkeitsschema oder – ein digitales Signaturschema.
Computersystem nach einem der Ansprüche 1 bis 5, wobei das probabilistische Beweisschema eines der folgenden Schemata ist: – ein Null-Kenntnis-Beweisschema oder – ein Zeugen-Verbergungs-Beweisschema.
Computersystem nach einem der vorhergehenden Ansprüche, wobei das Abfragemittel ein Mittel zum Ausgeben einer Zufallsfrage umfaßt.
Computersystem nach Anspruch 7, wobei das Mittel zum Ausgeben einer Zufallsfrage ein Mittel zum Erzeugen einer Zufallsfrage durch wiederholte Zeitmessung von Antworten auf Gerätezugriffe umfaßt.
Computersystem nach Anspruch 8, wobei das Mittel zum Erzeugen einer Zufallsfrage ein Mittel zum Erzeugen neuer Threads dergestalt umfaßt, daß ein zusätzlicher Zufälligkeitsgrad in die Zufallsfrage eingeführt wird, indem Unvorhersehbarkeiten in dem Scheduler des Betriebssystems ausgenutzt werden.
Computersystem nach Anspruch 8, wobei das Mittel zum Erzeugen einer Zufallsfrage ein Mittel zum Durchführen eines statistischen Tests umfaßt, um die Anzahl von Zufallsbit zu bestimmen, die durch jeden der Plattenzugriffe erhalten wird, sowie ein Mittel zum Bewirken, daß Plattenzugriffe wiederholt werden, bis eine vorbestimmte Anzahl von Zufallsbit erhalten wurde.
Computersystem nach einem der vorhergehenden Ansprüche, wobei das Abfragemittel in das Programm eingebettet ist.
Computersystem nach einem der vorhergehenden Ansprüche, wobei das System eine Schlüsseldatei zum Halten des öffentlichen Schlüsselmaterials und/oder von Dokumentbehandlungsregeln enthält.
Computersystem nach einem der vorhergehenden Ansprüche, wobei der Inhalt der Schlüsseldatei physisch in einer oder mehreren Dateien gespeichert ist.
Computersystem nach Anspruch 13, wobei das in der Schlüsseldatei gehaltene öffentliche Schlüsselmaterial kryptographisch gesichert ist, wodurch es rechnerisch impraktikabel ist, irgendeinen Teil der Schlüsseldatei, einschließlich des öffentlichen Schlüsselmaterials, zu verändern, ohne das Abfragemittel zu verändern.
Computersystem nach Anspruch 14, wobei die Schlüsseldatei Informationen enthält, die den Kunden identifizieren, an den der geschützte Softwareposten geliefert wurde.
Computersystem nach Anspruch 14, wobei die Schlüsseldatei Tarnungsbit zum Tarnen des darin gehaltenen ersten öffentlichen Schlüsselmaterials enthält.
Computersystem nach Anspruch 14, wobei die Schlüsseldatei Informationen bezüglich der selektiven Aktivierung von Diensten der geschützten Datei enthält.
Computersystem nach einem der vorhergehenden Ansprüche, wobei die Datei über eines der folgenden Medien zugänglich ist: – ein Kommunikationsnetz, – CD-ROM.
Computersystem nach einem der vorhergehenden Ansprüche, wobei die Datei mit digitalen Wasserzeichen markiert wird.
Computersystem nach einem der vorhergehenden Ansprüche, wobei die Datei verschlüsselt ist.
Computersystem nach einem der vorhergehenden Ansprüche, mit einem Verteilungssystem mit Zugriff auf privates Schlüsselmaterial des Händlers, wobei das Verteilungssystem autorisiert ist, die Datei zu verteilen.
Computersystem nach Anspruch 21, wobei das Verteilungssystem mindestens ein weiteres Verteilungssystem mit Zugriff auf das private Schlüsselmaterial des Händlers herstellt, wobei das weitere Verteilungssystem autorisiert ist, die Datei zu verteilen.
Computersystem nach Anspruch 22, wobei das Verteilungssystem verhindert, daß das weitere Verteilungssystem andere Verteilungssysteme mit Zugriff auf das private Schlüsselmaterial des Händlers herstellt, wobei – das weitere Verteilungssystem die Schlüsseldatei unter Verwendung eines privaten Schlüsselmaterials des weiteren Verteilungssystems signiert, – das Abfragemittel ein Zertifikat des weiteren Verteilungssystems, das unter Verwendung des privaten Schlüsselmaterials des Händlers signiert wurde, validiert, wobei das Zertifikat ein öffentliches Schlüsselmaterial des weiteren Verteilungssystems umfaßt, wobei ein öffentliches Schlüsselmaterial des Händlers verwendet wird, – das Abfragemittel die Schlüsseldatei unter Verwendung des öffentlichen Schlüsselmaterials des weiteren Verteilungssystems validiert.
Computersystem nach Anspruch 1, mit einem Mittel zum Eingeben eines Viewer-Programms, das die Datei verwendet, und zum Einbetten des Abfragemittels in das Viewer-Programm, das die Datei verwendet.
Verwendung eines Computersystems nach Anspruch 1 bei der Verteilung einer geschützten Datei an mehrere Kunden, wobei jeder Kunde ein Computersystem nach Anspruch 1 besitzt, und wobei jeder Kunde eine identische Kopie der geschützten Datei und des mit dem Abfragemittel im Zusammenhang stehenden Viewer-Programms erhält.
Verfahren zum Schutz des Inhalts einer Datei, wobei mindestens ein Abfragemittel einem Viewer-Programm zugeordnet ist, das die Datei benutzt, wobei das mindestens eine Abfragemittel der Datei zugeordnet ist und mindestens ein Antwortmittel auf privates Schlüsselmaterial zugreift, wobei a) das Abfragemittel keinen Zugriff auf das private Schlüsselmaterial hat und in ihm gespeichertes öffentliches Schlüsselmaterial verwendet, b) das Antwortmittel dem Abfragemittel beweist, daß es Zugriff auf das private Schlüsselmaterial hat, indem es unter Verwendung eines asymmetrischen kryptographischen Schemas mit dem Abfragemittel in Wechselwirkung tritt, c) das Abfragemittel die Verwendung eines Teils des Inhalts der Datei oder des gesamten Inhalts der Datei verhindert, wenn der Beweis nicht erfolgreich ist.
Verfahren nach Anspruch 26, wobei die Verwendung ein Anzeigen oder Ausdrucken ist.
Verfahren nach einem der vorhergehenden Ansprüche, wobei eine Zertifikatbehörde ein öffentliches Schlüsselpaar verfügbar macht.
Verfahren nach Anspruch 28, wobei – die Zertifikatbehörde ein öffentliches Schlüsselmaterial und/oder die Datei mit einem öffentlichen Schlüsselmaterial der Zertifikatbehörde signiert, – es zu einem Computer des Händlers sendet und – der Computer des Händlers das erste öffentliche Schlüsselmaterial und/oder die Datei validiert.
Verfahren nach einem der vorhergehenden Ansprüche, wobei das asymmetrische kryptographische Schema eines der folgenden Schemata ist: – ein probabilistisches Beweisschema, – ein asymmetrisches Vertraulichkeitsschema oder – ein digitales Signaturschema
Verfahren nach Anspruch 30, wobei das probabilistische Beweisschema eines der folgenden Schemata ist: – ein Null-Kenntnis-Beweisschema oder – ein Zeugen-Verbergungs-Beiweisschema.
Verfahren nach einem der vorhergehenden Ansprüche, – wobei das Abfragemittel eine Zufallsfrage ausgibt und – wobei die Informationen die Zufallsfrage umfassen.
Verfahren nach Anspruch 32, wobei das Mittel zum Ausgeben einer Zufallsfrage eine Zufallsfrage durch wiederholte Zeitmessung von Antworten auf Gerätezugriffe erzeugt.
Verfahren nach Anspruch 33, wobei das Mittel zum Erzeugen einer Zufallsfrage neue Threads dergestalt erzeugt, daß ein zusätzlicher Zufälligkeitsgrad in die Zufallsfrage eingeführt wird, indem Unvorhersehbarkeiten in dem Scheduler des Betriebssystems ausgenutzt werden.
Verfahren nach Anspruch 34, wobei das Mittel zum Erzeugen einer Zufallsfrage einen statistischen Test durchführt, um die Anzahl von Zufallsbit zu bestimmen, die durch jeden der Plattenzugriffe erhalten wird, und bewirkt, daß Plattenzugriffe wiederholt werden, bis eine vorbestimmte Anzahl von Zufallsbit erhalten wurde.
Verfahren nach einem der vorhergehenden Ansprüche, wobei das Abfragemittel in das Programm eingebettet ist.
Verfahren nach einem der vorhergehenden Anspruche, wobei das Abfragemittel das erste öffentliche Schlüsselmaterial zur Verschlüsselung der Informationen verwendet.
Verfahren nach einem der vorhergehenden Ansprüche, wobei das System eine Schlüsseldatei zum Halten des öffentlichen Schlüsselmaterials enthält.
Verfahren nach Anspruch 38, wobei das in der Schlüsseldatei gehaltene erste öffentliche Schlüsselmaterial kryptographisch gesichert ist, wodurch es rechnerisch impraktikabel ist, irgendeinen Teil der Schlüsseldatei, einschließlich des ersten öffentlichen Schlüsselmaterials, zu verändern, ohne das Abfragemittel zu verändern.
Verfahren nach Anspruch 39, wobei die Schlüsseldatei Informationen enthält, die den Kunden identifizieren, an den der geschützte Softwareposten geliefert wurde.
Verfahren nach Anspruch 39, wobei die Schlüsseldatei Tarnungsbit zum Tarnen des darin gehaltenen ersten öffentlichen Schlüsselmaterials enthält.
Verfahren nach Anspruch 41, wobei die Schlüsseldatei Informationen bezüglich der selektiven Aktivierung von Diensten der geschützten Datei enthält.
Verfahren nach einem der vorhergehenden Ansprüche, mit mehreren geschützten Dateien, jeweils mit ihrem eigenen Abfragemittel und einem einzigen Antwortmittel, das zwischen allen geschützten Posten gemeinsam genutzt wird.
Verfahren nach einem der vorhergehenden Ansprüche, wobei die Datei über eines der folgenden Medien zugänglich ist: – ein Kommunikationsnetz, – CD-ROM.
Verfahren nach einem der vorhergehenden Ansprüche, wobei die Datei mit digitalem Wasserzeichen markiert wird.
Verfahren nach einem der vorhergehenden Ansprüche, wobei die Datei verschlüsselt wird.
Verfahren nach einem der vorhergehenden Ansprüche, wobei das Verteilungssystem Zugriff auf ein privates Schlüsselmaterial des Händlers hat und wobei das Verteilungssystem autorisiert ist, die Datei zu verteilen.
Verfahren nach Anspruch 47, wobei das Verteilungssystem mindestens ein weiteres Verteilungssystem mit Zugriff auf das private Schlüsselmaterial des Händlers herstellt, und wobei das weitere Verteilungssystem autorisiert ist, die Datei zu verteilen.
Verfahren nach Anspruch 48, wobei das Verteilungssystem verhindert, daß das weitere Verteilungssystem andere Verteilungssysteme mit Zugriff auf das private Schlüsselmaterial des Händlers herstellt, wobei – das weitere Verteilungssystem die Schlüsseldatei unter Verwendung eines privaten Schlüsselmaterials des weiteren Verteilungssystems signiert, – das Abfragemittel ein Zertifikat des weiteren Verteilungssystems, das unter Verwendung des privaten Schlüsselmaterials des Händlers signiert wurde, validiert, wobei das Zertifikat ein öffentliches Schlüsselmaterial des weiteren Verteilungssystems umfaßt, wobei ein öffentliches Schlüsselmaterial des Händlers verwendet wird, – das Abfragemittel die Schlüsseldatei unter Verwendung des öffentlichen Schlüsselmaterials des weiteren Verteilungssystems validiert.