-
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, PA(r,B)
A → B: r
-
Das oben beschriebene Protokollschema
verwendet die folgende Notation:
- – A → B bedeutet,
daß A
eine Nachricht zu B sendet; und 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
- – PA(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. PA(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 PA(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,
PA(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
- – PA(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
sA = J–S (mod n).
-
Das GQ-Schlüsselpaar ist (privater Schlüssel = sA) 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 = Je·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
END
-
integer GetCounter()
-
BEGIN
- [1] Zurückgeben
des aktuellen Werts des Zählers
der Chipkarte
END
-
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. 2128 – 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
END
-
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
END
-
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
END
-
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