DE60112227T2

DE60112227T2 - Verfahren und vorrichtung zur sicheren datenverteilung

Info

Publication number: DE60112227T2
Application number: DE60112227T
Authority: DE
Inventors: A. Michael EPSTEIN; Martin Rosner; A. Antonius STARING
Original assignee: Koninklijke Philips Electronics NV
Current assignee: Koninklijke Philips NV
Priority date: 2000-02-07
Filing date: 2001-01-18
Publication date: 2006-06-01
Anticipated expiration: 2021-01-19
Also published as: CN1366631A; CN1296789C; JP2012105284A; WO2001059549A3; JP4934261B2; JP5330488B2; EP1212670B1; WO2001059549A2; EP1212670A2; DE60112227D1; ATE300758T1; KR100873314B1; JP2003523009A; KR20020003380A; US6789188B1

Description

Die vorliegende Erfindung bezieht sich im Allgemeinen auf den Bereich der sichern Kommunikation, und insbesondere auf Techniken zur sicheren elektronischen Verteilung von Musik und anderen Typen von Content über ein Netzwerk oder ein anderes Kommunikationsmedium.
Sicherheit ist ein zunehmend wichtiges Thema bei der Lieferung von Musik oder anderen Typen von Content über globale Kommunikationsnetzwerke, wie Internet. Insbesondere ist die erfolgreiche Implementierung derartiger Netzwerk-basierter Content-Liefersysteme zu einem großen Teil abhängig von der Gewährleistung, dass Content-Lieferanten geeignete Lizenzgebühren empfangen und dass der gelieferte Content nicht geraubt oder sonst wie einer unrechtmäßigen Benutzung ausgesetzt werden kann.
In Bezug auf die Lieferung von Musik-Content ist neulich eine kooperative Entwicklungsanstrengung, bekannt als "Secure Digital Music Initiative" (SDMI) gegründet worden, und zwar von den führenden Betrieben in der Aufzeichnungsindustrie und Technologie. Das Ziel von SDMI ist, die Entwicklung einer offenen, zusammenarbeitsfähige Architektur für digitale Musiksicherheit. Dies ist eine Antwort auf den Wunsch des Konsumenten nach einer bequemen Zugreifbarkeit auf digitale Qualitätsmusik, während auch Schutz der Urheberrechte geschaffen wird zum Schützen von Investitionen in Content-Entwicklung und Content-Lieferung. SDMI hat bereits eine Standard-Spezifikation für tragbare Musikeinrichtungen geschaffen, die "SDMI Portable Device Specification" Teil 1, Version 1.0, 1999. Die Ansprengungen auf längerer Frist von SDMI ist zur Zeit auf dem Weg zum Abschluss einer gesamten Architektur zur Lieferung digitaler Musik in allen Formen.
Trotz Anstrengungen von SDMI und anderen Anstrengungen leiden bestehende Techniken zur sicheren Lieferung von Musik und anderem Content an einer Anzahl signifikanter Nachteile. So erfordern beispielsweise viele derartige Techniken, dass der Content-Lieferant dem Content-Konsumenten bei Lieferung des Contents explizit identifiziert wird, d.h. diese Techniken ermöglichen im Allgemein nicht, dass der Content-Lieferant völlig anonym bleibt im Falle einer Auseinandersetzung. Unglücklicherweise kann dieser Typ von Einrichtung in bestimmten Applikationen nicht erwünscht oder kosteneffektiv sein, insbesondere für Content-Lieferanten, wobei es sich um Einzelpersonen oder kleine Geschäfte handelt. Ein anderes Beispiel ist, dass herkömmliche Techniken im Allgemeinen nicht einen zentralisierten Mechanismus liefern, durch den alle Content-Lieferanten sicher ihre Arbeit registrieren können. Content-Lieferanten werden deswegen unter diesen bestehenden Techniken nicht auf gleiche Art und Weise behandelt, d.h. größere Lieferanten, die sich die Kosten leisten können, die mit der Implementierung komplexer Sicherheitsmaßnahmen einher gehen, haben gegenüber kleineren Lieferanten einen Vorteil.
Aus dem Obenstehenden dürfte es einleuchten, dass es ein Bedürfnis nach verbesserten Techniken zum Verteilen von SDMI-gemäßen Musik und anderen Typen von Content gibt.
US-A-5765152 beschreibt ein Verfahren zum Verpacken und Verteilen von digitalem Content.
Die vorliegende Erfindung schafft Verfahren und eine Einrichtung zur sicheren Verteilung von Musik und anderen Typen von Content. Die vorliegende Erfindung ermöglicht es, dass Content mit einer zentralen zuverlässigen Registrierungsautorität (TRA) derart registriert wird, dass er anonym verteilt werden kann, so dass die Identität des Content-Lieferanten erst dann entdeckt zu werden braucht, wenn eine Auseinandersetzung auftritt.
Content-Verteilung in einer ersten illustrativen Ausführungsform der vorliegenden Erfindung wird entsprechend einem Content-Verteilungsprotokoll implementiert, das eine ungebundene Rechteverwaltung schafft, d.h. eine sichere Registrierung des Contents, so dass Gebrauchsrechte für den Content nicht auf den Content selber begrenzt sind. In dieser Ausführungsform wird verteilter Content nicht durch Verschlüsselung geschützt, d.h. Vertraulichkeit des Contents ist nicht geschaffen. Aber der Content wird vor Räuberei geschützt, und zwar durch die Tatsache, dass der Content-Lieferant durch die TRA zertifiziert ist, und folglich nachgespürt oder sonst wie identifiziert werden kann, in dem Fall, dass Unregelmäßigkeiten detektiert werden. Da die Benutzungsrechte sich nicht auf den Content beschränken, kann der Content-Lieferant die Benutzungsrechte ändern, nachdem der Content bei der TRA registriert worden ist. Content-Verteilung in der zweiten und dritten illustrativen Ausführungsform der vorliegenden Erfindung wird entsprechend Content-Verteilungtsprotokollen implementiert, die ungebundene und gebundene Rechteverwaltung schaffen mit Verschlüsselung-basierten Content-Vertraulichkeit.
Auf vorteilhafte Weise können die Content-Verteilungsverfahren und – Einrichtungen nach der vorliegenden Erfindung bequemen, effizienten und kosteneffektiven Schutz für alle Content-Lieferanten schaffen.
Ausführungsbeispiele der Erfindung sind in der Zeichnung dargestellt und werden im Folgenden näher beschrieben. Es zeigen:
1 ein Content-Verteilungsverfahren mit nicht gebundener Rechtenverwaltung nach der vorliegenden Erfindung,
2, 3, 4, 5 und 6 Flussdiagramme zur Erläuterung von Verarbeitungsvorgängen, implementiert nach dem Content-Verteilungsverfahrens nach 1,
7 eine Darstellung eines Content-Verteilungsverfahrens mit ungebundener Rechteverwaltung und Content-Vertraulichkeit nach der vorliegenden Erfindung,
8, 9, 10 und 11 Flussdiagramme zur Erläuterung der Verarbeitungsvorgänge, implementiert nach dem Content-Verteilungsverfahren nach 7,
12 eine Darstellung eines Content-Verteilungsverfahrens mit gebundener Rechteverwaltung und Content-Vertraulichkeit nach der vorliegenden Erfindung,
13, 14, 5, 16, 17 und 18 Flussdiagramme zur Erläuterung der Verarbeitungsvorgänge, implementiert nach dem Content-Verteilungsverfahren nach 12.
Die vorliegende Erfindung ermöglicht es, dass Musik und jede andere Form von Content derart registriert wird, dass sie anonym verteilt werden kann. Die unten beschriebenen Content-Verteilungsverfahren ermöglichen Content-Lieferanten ihren Content bei einer vertraulichen Behörte vor der Verteilung zu registrieren, wodurch es ermöglicht wird, dass der Content von dem Content-Lieferanten einem Content-Konsumenten derart geliefert wird, dass der Content-Lieferant nicht entdeckt zu werden braucht, bis eine Auseinandersetzung stattfindet. Auf vorteilhafte Weise können die Content-Verteilungsverfahren nach der vorliegenden Erfindung auf bequeme, effiziente und kosteneffektive Weise Schutz bieten für alle Content-Lieferanten.
Drei illustrative Ausführungsformen der vorliegenden Erfindung werden nachstehend beschrieben, die je einem bestimmten Protokoll entsprechen, das die oben beschriebene Funktionalität implementiert. Die Protokolle variieren in dem Pegel der Sicherheit und der Steuerung zu dem Content-Lieferanten. In der nachfolgenden Beschreibung bezeichnet ein Vorgang E{K}[S] die Verschlüsselung der eingeklammerten Quantität S unter Verwendung des Schlüssels K, und der Vorgang D{K}[S] bezeichnet eine Entschlüs selung der eingeklammerten Quantität S unter Verwendung des Schlüssels K. Die nachstehend zu beschreibenden Protokolle können herkömmliche öffentliche Verschlüsselungstechniken zum Implementieren dieser Verschlüsselungs- und Entschlüsselungsvorgänge benutzen. Im Allgemeinen werden für die hier beschriebenen Ausführungsbeispiele asymmetrische Algorithmen verwendet zum Verschlüsseln und Entschlüsseln für Schlüssel die "Pub" oder "Prv" in der Subskript-Zeichenfolge enthalten, während symmetrische Algorithmen für alle anderen Schlüssel verwendet werden, beispielsweise den nachstehend zu beschreibenden K_Cont und K_License. Diese und andere Verschlüsselungs- und Entschlüsselungstechniken, geeignet zur Verwendung bei der vorliegenden Erfindung, sind dem Fachmann durchaus bekannt und werden deswegen an dieser Stelle nicht detailliert beschrieben.
1 zeigt ein Basisprotokoll zur Verteilung von Content mit nicht gebundener Rechteverwaltung entsprechend einer ersten Ausführungsform der vorliegenden Erfindung. Diese Figur zeigt die Interaktion zwischen einer Zertifizierungsbehörde (CA) 102, einem Content-Lieferanten 104, einer vertrauten Registrierungsautorität (TRA) 106 und einem Content-Konsumenten 108. Die CA 102, der Content-Lieferant 104 und der Content-Konsument 108 sind hier auch durch die Buchstaben X, G bzw. C bezeichnet. Das in 1 dargestellte Verfahren umfasst Verarbeitungsvorgänge 110, 120, 130, 140 und 150, die in den Flussdiagrammen nach den 2, 3, 4, 5 bzw. 6 detaillierter dargestellt sind.
Die Verarbeitungsvorgänge nach 1 implementieren ein Basisprotokoll, in dem verteilter Content nicht mit Hilfe von Verschlüsselung geschützt ist, d.h. Vertraulichkeit des Contents ist nicht gegeben. Aber der Content wird vor Räuberei geschützt, und zwar durch die Tatsache, dass der Content-Lieferant G durch die TRA 106 zertifiziert ist und folglich nachgeforscht oder sonst wie identifiziert werden kann, falls Unregelmäßigkeiten detektiert werden. Weiterhin sind in dieser Ausführungsform der vorliegenden Erfindung Benutzungsrechte nicht auf den Content begrenzt. Dies ermöglicht es, dass der Content-Lieferant G die Benutzungsrechte ändern kann, nachdem der Content bei der TRA 106 registriert worden ist.
In dem Basisprotokoll nach 1 beantragt der Content-Lieferant 104 (G) zunächst ein Zertifikat von der CA 102 (X). Die CA 102 erzeugt das Zertifikat in dem Vorgang 110, was in 2 dargestellt ist. Der Erzeugungsprozess des Zertifikats kann auf herkömmliche Art und Weise durchgeführt werden, beispielsweise entsprechend einem bestehenden Standard. In dem Schritt 111 ermittelt die CA 102, ob das Register G ist, was sie sagen, dass sie sind. Sollte dies nicht der Fall sein, so wird das Zertifikat nicht ausgegeben. Sollte der Antragsteller G sein, wer er sagt, so erzeugt die CA 102 in dem Schritt 112 ein öffentliches Schlüsselpaar für den Antragsteller und in dem Schritt 113 gibt er sicher dem Antragsteller G den privaten Schlüssel K_Prvrequestor. Die CA 102 legt danach die Identität des Antragstellers I_requestor und den öffentlichen Schlüssel K_Pubrequestor des Antragstellers in ein Zertifikat fest, wie in dem Schritt 114 dargestellt und liefert dem Antragsteller G das Zertifikat Cert_x(I_G, K_PubG), wie in 1 dargestellt. Es sei bemerkt, dass Anträge für Zertifikate nicht für jede Transaktion obligatorisch sind, d.h. wenn jemand einmal ein Zertifikat erhalten hat, kann es wieder benutzt werden, bis es abgelaufen ist.
Der Vorgang 120 in 1 ist in 3 dargestellt. Der Content-Lieferant G liefert in dem Schritt 121 einen Hash-Wert für den spezifischen Content M: H = hash(M)
Der Content-Lieferant G verschlüsselt danach in dem Schritt 122 H unter Anwendung des privaten Schlüssels K_PrvG: H' = E{KPrvG}[H],und erzeugt Q in dem Schritt 123 wie folgt: Q = (H', Certx(IG, KPubG)).
Der Content-Lieferant G sendet danach einen Antrag an die TRA 106 zum Registrieren von Q, wie in 1 dargestellt.
4 zeigt den Vorgang 130, implementiert durch die TRA 106. In dem Schritt 131 ermittelt die TRA, ob das Zertifikat Cert_x(I_G, K_PubG) für den Content-Lieferanten G gültig ist. Sollte dies nicht der Fall sein, so endet der Vorgang und der Antrag auf Registrierung von Q wird verweigert. Sollte das Zertifikat in dem Schritt 131 als gültig ermittelt werden, so speichert die TRA in dem Schritt 132 das Paar H' und I_G sowie die Zeit und das Datum des Empfangs. In dem Schritt 133 extrahiert die TRA den Hash-Wert H aus Q, und zwar wie folgt: H = D{KPubG}[H']
Die TRA erzeugt danach in dem Schritt 134 einen Registrierungsabschnitt Q' wie folgt: Q' = E{KPrvTRA}[H]
Die TRA entschlüsselt auf diese Art und Weise den Hash-Wert H, der von dem Content-Lieferanten G gesendet worden ist und verschlüsselt diesen Wert neu mit dem privaten Schlüssel K_PrvTRA. Der resultierende Registrierungsabschnitt Q' wird de, Content-Lieferanten G zugeführt, wie in 1 dargestellt.
Der Vorgang 140 nach 1 wird danach von dem Content-Lieferanten G durchgeführt. 5 zeigt diesen Vorgang detailliert. Es wird vorausgesetzt, dass der Content-Lieferant G das Zertifikat für die TRA auf eine beliebig herkömmliche Art und Weise erhalten hat. In dem Schritt 141 ermittelt der Content-Lieferant G, ob das Zertifikat für die TRA gültig ist. Sollte das Zertifikat für die TRA gültig sein, dann bestimmt der Content-Lieferant G in dem Schritt 142, ob: D{KPubTRA}[Q'] = hash(M) ist.
Sollte dies der Fall sein, dann werden Q' und M in dem Schritt 143 zur nachfolgenden Verteilung gespeichert. Sonst endet der Vorgang ohne Speicherung von Q' und M. Sollten Q' und M gespeichert werden, so weiß der Content-Lieferant, dass der Registrierungsprozess für den Content M erfolgreich beendet worden ist und der Content-Lieferant ist folglich frei, einem oder mehreren Konsumenten den Content zu liefern.
In 1 verteilt nach einer erfolgreichen Beendigung des Vorgangs 140 der Content-Lieferant den Registrierungsabschnitt Q' und den Content M zu dem Content-Konsumenten 108 (C). 6 zeigt den Vorgang 150, wie dieser durch den Content-Konsumenten C durchgeführt wird. Der Content-Konsument C ermittelt in dem Schritt 151, ob das Zertifikat für TRA gültig ist. Sollte dies nicht der Fall sein, so endet der Vorgang. Sonst ermittelt der Content-Konsument in dem Schritt 152, ob D{KPubTRA}[Q'] = hash(M) ist.
Sollte dies nicht der Fall sein, so endet der Vorgang. Sonst spielt und/oder speichert er Content-Konsument C in dem Schritt 153 den Content M. Der Content-Konsument C akzeptiert auf diese Weise den Content nur dann, wenn der Content-Lieferant G als "bona fide" bewertet ist.
Es sei bemerkt, dass der Vorgang 150 und andere hier beschriebene als von einem Content-Konsumenten durchgeführte Vorgänge in einer manipulationssicheren oder manipulationsbeständigen Anordnung durchgeführt wird, beispielsweise wenn Content durch einen Content-Konsumenten entschlüsselt wird, sollte der entschlüsselte Content nicht von unberechtigten Benutzern und Einrichtungen zugreifbar sein.
Wie oben bemerkt, kann der Content M Musik oder jeder beliebige Typ von Content sein. Er kann in einem komprimierten Formal sein, erzeugt unter Verwendung ei ner beliebigen geeigneten Codierungseinrichtung, oder in einem nicht komprimierten Format. Eine garantierte Verteilung zu einem einzigen Content-Konsumenten kann unter Anwendung eines herkömmlichen Sicheren Verbindungsprotokolls implementiert werden, wie dies dem Fachmann einleuchten dürfte.
Ein mögliches Schutzproblem kann in dem oben beschriebenen Basisprotokoll dann entstehen, wenn der Content-Konsument "vererbten" Content sowie Content spielen kann, der von dem Registrierungsabschnitt Q' begleitet wird. Wenn nämlich Q' verloren gegangen ist oder sonst wie nicht vorhanden ist, gibt es keine Möglichkeit vererbten Content von registrierten Content in dem Basisprotokoll zu unterscheiden.
In den verbesserten Versionen des nachstehend noch zu beschreibenden Protokolls schafft das verschlüsselte Format die Verteilung, so dass dieses Schutzproblem im Allgemeinen nicht spielt. Das Schutzproblem kann aber auch in dem Basisprotokoll dadurch gelöst werden, dass ein eingebettetes Wasserzeichen in dem Content M vorgesehen wird. Dieses eingebettete Wasserzeichen gibt dem Content-Konsumenten an, dass ein gültiger Registrierungsabschnitt Q' vorhanden sein soll bevor der Content gespielt werden könnte. In einer derartigen Ausführungsform wird der in 6 dargestellte Vorgang 150 modifiziert um vor dem Schritt 151 einen zusätzlichen Verarbeitungsschritt einzuschließen, der ermittelt, ob M ein Wasserzeichen enthält, das angibt, dass Q' vorhanden sein sollte. Sollte dies der Fall sein, so fährt der Vorgang mit dem Schritt 151 fort. Sollte es nicht ein derartiges Wasserzeichen geben, so überspringt der Vorgang die Schritte 151 und 152 und fährt mit dem Schritt 153 fort. Andere Konfigurationen sind ebenfalls möglich, so kann beispielsweise der oben beschriebene zusätzliche Verarbeitungsschritt für das eingebettete Wasserzeichen zwischen den Verarbeitungsschritten 151 und 152 nach 6 durchgeführt werden.
Es sei bemerkt, dass das eingebettete Wasserzeichen nur anzugeben braucht, dass ein gültiger Registrierungsabschnitt vorhanden sein sollte und möglicherweise die Art des Abschnitts, beispielsweise hash(M), usw. Das eingebettete Wasserzeichen braucht dazu nicht den Registrierungsabschnitt selber zu enthalten. Außerdem sei bemerkt, dass ein derartiges Wasserzeichen auch in Content verwendet werden kann, der unter Verwendung verbesserter Versionen des nachstehend noch zu beschreibenden Protokolls verteilt werden kann, damit vermieden wird, dass Aufzeichnung und Verteilung von Content in Einrichtungen erfolgt, die nur das Basisprotokoll unterstützen.
7 zeigt ein Content-Verteilungsverfahren mit nicht gebundener Rechteverwaltung und Content-Vertraulichkeit entsprechend einer zweiten Beispielsausführungsform der vorliegenden Erfindung. Diese Figur zeigt die Interaktion zwischen einer zusätzlichen Zertifikatbehörde, CA 200, auch als CA Y bezeichnet, und den Entitäten CA (X) 192, dem Content-Lieferanten 104, TRA 106 und dem Content-Konsumenten 108. Die 8,9, 20 und 11 sind Flussdiagramme, die Verarbeitungsvorgänge zeigen, implementiert in dem Content-Verteilungsverfahren nach 7. Das in 7 dargestellte Verfahren umfasst Verarbeitungsvorgänge 210, 220, 250, 260 und 270. Der Verarbeitungsvorgang 210 entspricht im Allgemeinen dem Vorgang 110 aus 2, aber Informationssignal durch die CA (Y) 200 implementiert. Die Verarbeitungsvorgänge 220, 250, 260 und 270 sind in den Flussdiagrammen 8, 9, 10 bzw. 11 detailliert dargestellt.
Die Verarbeitungsvorgänge nach 7 implementieren eine verbesserte Version des Basisprotokolls nach 1. In diesem verbesserten Protokoll wird der Content mit Hilfe von Verschlüsselung geschützt, d.h. es wird Content-Vertraulichkeit vorgesehen. Außerdem, wie in dem oben beschriebenen Basisprotokoll wird der Content in dem verbesserten Protokoll auch vor Räuberei geschützt, und die Benutzungsrechte sind nicht auf den Content begrenzt, wodurch der Herausgeber die Möglichkeit hat, nachdem der Content registriert worden ist, die Benutzungsrechte zu ändern.
In dem verbesserten Protokoll nach 7 beantragt der Content-Lieferant (G) 104 ein Zertifikat bei der CA (X) 102 und der Content-Konsument (C) 108 beantragt ein Zertifikat bei der CA (Y) 200. Die CAs 102, 200 erzeugen Zertifikate Cert_x(I_G, K_PubG) Cert_Y(I_C, K_PubC), in den Vorgängen 110 bzw. 120 auf eine Art und Weise, die oben anhand der 2 beschrieben worden ist. Das Zertifkat Cert_x(I_G, K_PubG) wird von CA 102 zu dem Content-Lieferanten G herausgegeben und das Zertifikat Cert_Y(I_C, K_PubC) wird von der CA 200 dem Content-Konsumenten C herausgegeben. Es sei bemerkt, dass die CA 102 und die CA 200 dieselbe CA sein kann. In diesem Beispiel sind sie als separate Entitäten dargestellt, damit illustriert werden kann, dass die Zertifikate nicht von derselben CA her zu rühren brauchen.
Der Vorgang 220 nach 7 ist in 8 dargestellt. Der Content-Lieferant G verschlüsselt in dem Schritt 221 den Content M zum Erzeugen eines verschlüsselten Contents M': M' = E{KCont}[M].
Es sei bemerkt, dass K_Cont nicht ein einziger Schlüssel sein braucht. Es könnte beispielsweise eine Folge von Schlüsseln sein, wobei jeder Schlüssel in der Folge verwendet wird zum Verschlüsseln verschiedener Teile des Contents. Der Content-Lieferant G erzeugt in dem Schritt 222 einen Hash-Wert für bestimmten Content M': H = hash(M').
Der Content-Lieferant G verschlüsselt danach in dem Schritt 223 H, und zwar unter Verwendung des privaten Schlüssels K_PrvG: H' = E{KPrvG}[H]und erzeugt Q in dem Schritt 224 wie folgt: Q = (H', Certx(IG, KPubG)).
Der Content-Lieferant G sendet danach einen Antrag zu der TRA 106 zum Registrieren von Q, wie in 7 dargestellt. Der Antrag wird von der TRA 106 im Vorgang 130 verarbeitet, wie in 4 dargestellt und der Registrierungsabschnitt Q' wird von TRA 106 zu dem Content-Lieferanten G zugeschickt.
Der Content-Lieferant G führt danach den Vorgang 140' durch, der derselbe ist wie der Vorgang 140 in 5, ausgenommen dass in den Schritten 142 und 143 M durch M' ersetzt worden ist. Dass Q' und M' gespeichert werden ist ein Ergebnis der Zustandprüfung 142. Wenn 142 wahr ist, dann werden Q' und M' gespeichert und der Content-Lieferant G weiß, dass der Registrierungsprozess für den verschlüsselten Content M' erfolgreich abgeschlossen wurde. Der Content-Lieferant ist dadurch frei den verschlüsselten Content einem oder mehreren Konsumenten zu liefern.
In 7 verteilt nach einem erfolgreichen Abschluss des Vorgangs 140' der Content-Lieferant G den Registrierungsabschnitt Q' und den verschlüsselten Content M' zu dem Content-Konsumenten 108 (C).
9 zeigt den Vorgang 150, wie dieser durch den Content-Konsumenten C durchgeführt wird. Der Content-Konsument C ermittelt in dem Schritt 251, ob das Zertifikat für TRA gültig ist. Sollte dies nicht der Fall sein, so endet der Vorgang. Sonst ermittelt der Content-Konsument in dem Schritt 252, ob D{KPubTRA}[Q'] = hash(M') ist.
Sollte dies nicht der Fall sein, so endet der Vorgang. Sonst speichert der Content-Konsument C in dem Schritt 253 den verschlüsselten Content M'. Der Content-Konsument C speichert auf diese Weise den verschlüsselten Content nur dann, wenn der Content-Lieferant G als "bona fide" bezeichnet wird.
Um auf den Content zugreifen zu können, muss der Content-Konsument C auch den Content-Entschlüsselungsschlüssel K_Cont sowie alle von dem Lieferanten definierten Benutzungsregeln empfangen. Diese Information wird dem Content-Konsumenten C nur dann zugeführt, wenn die Prüfung der Identität des Konsumenten durch den Content-Lieferanten G erfolgreich war. Dazu erzeugt der Content-Konsument C in dem Schritt 254 des Vorgangs 259 einen Hash-Wert für den verschlüsselten Inhalt M': H = hash(M').
Der Content-Konsument entschlüsselt dann unter Verwendung des privaten Schlüssels K_PrvC in dem Schritt 255 H: H'' = E{KPrvC}[H].und erzeugt in dem Schritt 256 ein Paar Q'' mit dem verschlüsselten Hash-Wert und dem oben genannten Zertifikat Cert_Y(I_C, K_PubC): Q'' = (H'', Certy(IC, KPubC)).
Das Paar Q'' wird danach von dem Content-Konsumenten C dem Content-Lieferanten G zugeführt
10 zeigt den Vorgang 260, durchgeführt von dem Content-Lieferanten G. In dem Schritt 261 ermittelt der Content-Lieferant G ob das Zertifikat Cert_Y(I_C, K_PubC) des Content-Konsumenten C gültig ist. Sollte dies nicht der Fall sein, so endet der Vorgang. Sonst ermittelt der Content-Lieferant G in dem Schritt 262 ob D{KPubC}[H''] = hash(M') ist.
Sollte dies nicht der Fall sein, so endet der Vorgang. Sonst benutzt der Content-Lieferant G in dem Schritt 263 einen Lizenzschlüssel K_license zum Verschlüsseln des Content-Schlüssels K_Cont und der Benutzungsregeln: A = E{Klicense}[usage_rules| KCont]und verschlüsselt danach in dem Schritt 264 den Lizenzschlüssel: B = E{KPubC}[Klicense]
Es wird danach in dem Schritt 265 ein Lizenzabschnitt L als das Paar (A, B) erzeugt. Wie in 7 dargestellt, sendet der Content-Lieferant G danach den Lizenzabschnitt L dem Content-Konsumenten C zu.
11 zeigt den Vorgang 270, durchgeführt von dem Content-Konsumenten C bei Empfang des Lizenzabschnitts L. In dem Schritt 271 entschlüsselt der Content-Konsument C den Lizenzschlüssel: Klicense = D{KPrvC}[B],und entschlüsselt danach in dem Schritt 272 die Regeln und den Content-Schlüssel: Usage_rules | KCont = D{Klicense}[A].
Der Content-Konsument C entschlüsselt danach in dem Schritt 273 den verschlüsselten Content M': M = D{KCont}[M'].
Der Content-Konsument wendet danach in dem Schritt 274 die Benutzungsregeln auf den Content M an und in dem Schritt 275 spielt und/oder speichert er den Content M.
12 zeigt ein Content-Verteilungsverfahren mit begrenzter Rechteverwaltung und Content-Vertraulichkeit nach einem dritte Ausführungsbeispiel der vorliegenden Erfindung. Die Figur zeigt Interaktionen zwischen den Entitäten CA (Y) 200, CA (X) 102, dem Content-Lieferanten (G) 104, der TRA 106 und dem Content-Konsumenten (C) 108. Die 13, 14, 15, 16, 17 und 18 sind Flussdiagramme, die Verarbeitungsvorgänge 320, 330, 340, 350, 360 bzw. 370 zeigen, implementiert in dem Content-Verteilungsverfahren nach 12. Die Verarbeitungsvorgänge 110 und 210 sind implementiert worden auf die Art und Weise, wie oben im Zusammenhang mit der Ausführungsform nach 7 beschrieben.
Die Verarbeitungsvorgänge nach 12 implementieren eine alternative verbesserte Version des Basisprotokolls nach 1. In diesem alternativen verbesserten Protokoll wird, so wie in dem verbesserten Protokoll nach 7, der Content mit Hilfe von Verschlüsselung geschützt, d.h. es wird Content-Vertraulichkeit geschaffen. Außerdem wird, so wie in dem oben beschriebenen Basisprotokoll und in dem verbesserten Protokoll, der Content in dem alternativen verbesserten Protokoll vor Räuberei geschützt. Aber anders als bei den oben beschriebenen Protokollen gewährleistet dieses alternative verbesserte Protokoll auch, dass die Lizenz authentisch ist, weil diese an den Content gekoppelt und bei der TRA 106 registriert ist.
Es sei bemerkt, dass diese Annäherung den Content-Lieferanten G darin beschränkt, dass dieser die Content-Benutzungsregeln nicht ändern kann, nachdem der Content bei der TRA 106 registriert worden ist. Folglich ist, wenn der Content-Lieferant G die Benutzungsregeln nach der Registrierung ändern möchte, eine neue Registrierung erforderlich.
In dem verbesserten Protokoll nach 12 beantragt der Content-Lieferant (G) ein Zertifikat von der CA (X) 102 und der Content-Konsument (C) 108 beantragt ein Zertifikat von der CA (Y) 200. Die CAs 102, 200 erzeugen Zertifikate Cert_x(I_G, K_PubG), Cert_Y(I_C, K_PubC), in den Vorgängen 110 bzw. 210 auf eine Art und Weise, wie oben im Zusammenhang mit der 2 beschrieben worden ist. Das Zertifikat Cert_x(I_G, K_PubG) wird von CA 102 dem Content-Lieferanten G geliefert und das Zertifikat Cert_Y(I_C, K_PubC) wird von der CA 200 dem Content-Konsumenten C geliefert. Wie oben bereits erwähnt, können die CA 102 und CA 200 dieselbe CA sein.
Der Vorgang 320 nach 12 ist in 13 dargestellt. Der Content-Lieferant G verschlüsselt den Content M in dem Schritt 321 zum Erzeugen des verschlüsselten Contents M': M' = E{KCont}[M].
Wie oben erwähnt braucht K_Cont nicht ein einziger Schlüssel zu sein und könnte beispielsweise eine Folge von Schlüsseln sein, wobei jeder Schlüssel der Folge benutzt wird um verschiedene Teile des Contents zu verschlüsseln.
Der Content-Lieferant G erzeugt in dem Schritt 322 einen Hash-Wert für spezifischen Content M': H1 = hash(M').
In dem Schritt 323 koppelt der Content-Lieferant G einen Satz mit Regeln an den Content-Schlüssel durch Erzeugung eines Lizenz-Registrierungsabschnitts A wie folgt: A = E{Klicense}[usage_rules | KCont].
Es sei bemerkt, dass die Kopplung der Regeln an einen bestimmten Content-Schlüssel durch Verschlüsselung erfolgen kann, wie oben erwähnt, oder auf alternative Weise mit Hilfe eines anderen beliebigen Verschlüsselungsmechanismus. Wenn durch Verschlüsselung, soll die Verschlüsselung eine Verkettungsmode benutzen, damit eine Blockwiederholungsangriff vermieden wird, der die Kopplung aufbrechen könnte.
Nach der Kopplung der Regeln in dem Schritt 323 wird in dem Schritt 324 ein Hash-Wert A erzeugt: H2 = hash(A).
Der Content-Lieferant G verschlüsselt danach in dem Schritt 325 H1 und H2, und zwar unter Verwendung des privaten Schlüssels K_PrvG: H' = E{KPrvG}[H1 | H2],und erzeugt in dem Schritt 326 wie folgt Q: Q = (H', CertX)IG, KPubG)).
Der Content-Lieferant G sendet danach zu der TRA 106 einen Antrag zum Registrieren von Q, wie in 12 dargestellt. Der Antrag wird von der TRA 106 in dem Vorgang 330 verarbeitet, wie in 14 dargestellt. In dem Schritt 331 ermittelt die TRA ob das Zertifikat Cert_x(I_G, K_PubG) für den Content-Lieferanten G gültig ist. Sollte dies nicht der Fall sein, so endet der Vorgang und der Antrag zur Registrierung von Q wird verweigert. Sollte in dem Schritt 331 ermittelt werden, dass das Zertifikat gültig ist, so speichert die TRA in dem Schritt 332 das Paar H' und I_G sowie die Zeit und das Datum des Empfangs. In dem Schritt 333 extrahiert die TRA die Hash-Werte H1 und H2 aus Q. Die TRA erzeugt danach in dem Schritt 334 einen Content-Registrierungsabschnitt Q1' wie folgt: Q1' = E{KPrvTRA}[H1],und erzeugt in dem Schritt einen Benutzungsregeln-Registrierungsabschnitt Q2' wie folgt: Q2' = E{PrvTRA}[H2].
Die TRA entschlüsselt auf diese Art und Weise die Hash-Werte H1 und H2, die von dem Content-Lieferanten G gesendet worden sind und verschlüsselt sie abermals unter Verwendung des privaten Schlüssels K_PrvTRA. D resultierenden Registrierungsabschnitte Q1' und Q2' werden dem Content-Lieferanten G geliefert, wie in 12 dargestellt.
Der Vorgang 340 nach 12 wird danach von dem Content-Lieferanten G durchgeführt. 15 zeigt diesen Vorgang detailliert. In dem Schritt 341 ermittelt der Content-Lieferant G ob das Zertifikat für die TRA gültig ist. Sollte das Zertifikat für die TRA gültig sein, so ermittelt der Content-Lieferant G in dem Schritt 142 ob: D{KPubTRA}[Q1'] = hash(M') ist.
Sollte dies der Fall sein, so werden Q1', Q2' und M' in dem Schritt 343 zur nachfolgenden Verteilung gespeichert. Sonst endet der Vorgang ohne dass Q1', Q2' und M' gespeichert werden. Sollten Q1', Q2' und M' gespeichert werden, so weiß der Content-Lieferant, dass der Registrierungsprozess für den verschlüsselten Content M' erfolgreich war und der Content-Lieferant ist deswegen frei, den Content einem oder mehreren Konsumenten zuzuführen.
In 12 verteilt nach erfolgreicher Beendigung des Vorgangs 340 der Content-Lieferant G den registrierten Content-Abschnitt Q1' und den verschlüsselten Content M' zu dem Content-Konsumenten 108 (C).
16 zeigt den Vorgang 350, wie dieser von dem Content-Konsumenten C durchgeführt wird. Der Content-Konsument C ermittelt in dem Schritt 351, ob das Zertifikat für TRA gültig ist. Sollte dies nicht der Fall sein, so endet der Vorgang. Sonst ermittelt der Content-Konsument C in dem Schritt 352, ob D{KPubTRA}[Q1'] = hash(M') ist.
Sollte dies nicht der Fall sein, so endet der Vorgang. Sonst speichert der Content-Konsument C in dem Schritt 353 den verschlüsselten Content M'. Der Content-Konsument C speichert auf diese Weise den verschlüsselten Content nur dann, wenn der Content-Lieferant G als "bona fide" bezeichnet werden kann.
Um auf den Content eingreifen zu können muss der Content-Konsument C auch den Content-Verschlüsselungsschlüssel K_Cont sowie die Benutzungsregeln empfangen, wie diese von dem Urheber definiert worden sind. Diese Information wird dem Content-Konsumenten C nur dann zugeführt, wenn Verifikation der Konsumentenidentität durch den Content-Lieferanten G erfolgreich stattgefunden hat. Dazu erzeugt der Content-Konsument C in dem Schritt 354 des Vorgangs 350 einen Hash-Wert für den verschlüsselten Content M': H = hash(M').
Der Content-Konsument verschlüsselt danach in dem Schritt 355 H, und zwar unter Verwendung des privaten Schlüssels K_PrvC: H'' = E[KPrvC}[H],und erzeugt in dem Schritt 356 ein Paar Q'' mit dem verschlüsselten Hash-Wert und dem oben genannten Zertifikat Cert_Y(I_C, K_PubC): Q'' = (H'', CertY(IC, KPubC)).
Das Paar Q'' wird von dem Content-Konsumenten C dem Content-Lieferanten G zugeführt.
17 zeigt den Vorgang 360, durchgeführt von dem Content-Lieferanten G. In dem Schritt 361 ermittelt der Content-Lieferant G, ob das Zertifikat Cert_Y(IC, K_PubC) des Content-Konsumenten C gültig ist. Sollte dies nicht der Fall sein, so endet der Vorgang. Sonst ermittelt der Content-Lieferant G in dem Schritt 362 ob: D{KPubC}[H''] = hash(M').
Sollte dies nicht der Fall sein, so endet der Vorgang. Sonst verschlüsselt in dem Schritt 363 der Content-Lieferant G den Lizenzschlüssel K_license unter Verwendung des öffentlichen Schlüssels K_PubC des Content-Konsumenten C: B = E{KPubC}[Klicense]
Ein Lizenzabschnitt L wird danach in dem Schritt 364 als das Triplet (A, B, Q2') erzeugt. Wie in 12 dargestellt, sendet der Content-Lieferant G danach den Lizenzabschnitt L zu dem Content-Konsumenten C.
18 zeigt den Vorgang 370, durchgeführt von dem Content-Konsumenten C bei Empfang des Lizenzabschnitts L. In dem Schritt 371 ermittelt der Content-Konsument C ob: D KPubTRA[Q2'] = hash(A).
Sollte dies nicht der Fall sein, so endet der Prozess. Sonst entschlüsselt der Content-Konsument C in dem Schritt 372 den Lizenzschlüssel: Klicense = D{KPrvC}[B],und entschlüsselt danach in dem Schritt 373 die Regeln und den Content-Schlüssel: usage_rules | KCont = D{Klicense}[A].
Der Content-Konsument C entschlüsselt danach in dem Schritt 374 den verschlüsselten Content M': M = D{KCont}[M]
Der Content-Konsument wendet danach in dem Schritt 375 die Benutzungsregeln auf den Content M an und spielt und/oder speichert in dem Schritt 376 den Content M.
In den oben beschriebenen Protokollen wird, wenn eine illegale Kopie eines bestimmten Content-Teils, beispielsweise eine geraubte Musikselektion, registriert wird, in einem Versuch, die illegale Kopie SDMI-übereinstimmend zu machen, die TRA 106 die Registrierung ohne jegliche durchführen. Eine derartige Registrierung erfordert aber, dass der Content-Lieferant G sich einwandfrei identifiziert, indem der TRA 106 ein Zertifikat präsentiert wird. Auf diese Weise kann, sogar obschon eine illegale Kopie registriert wurde, der Content-Lieferant, der die Registrierung machte, sofort identifiziert und verfolgt werden. Auf diese Art und Weise werden Verletzer verfolgt, nachdem der Content dem Content-Konsumenten freigegeben wurde, und nur dann, wenn ein Konflikt auftritt. Die Gründe zur Identifikation eines registrierten Content-Lieferanten sollen legal definiert sein, damit es erforderlich ist, dass ein Ankläger eine gültige und vorhergehende Registrierung für denselben oder genügend übereinstimmenden Content präsentiert.
Es sei bemerkt, dass eine oder mehrere der CAs 102 und 200, der Content-Lieferant 104, die TRA 106 und der Content-Konsument 108 je einen oder mehrere PCs, Arbeitsstationen, Großrechner oder andere Prozessor-basierte Einrichtungen zur Implementierung der Verarbeitungsvorgänge, die mit den beschriebenen Protokollen assoziiert sind, darstellen. Derartige Prozessor-Einrichtungen werden im Allgemeinen eine oder mehrere Speichereinrichtungen zur Speicherung geeigneter Software-Programminstruktionen enthalten, die mit den beschriebenen Verarbeitungsfunktionen assoziiert sind, und wenigstens ein Prozessor zum Durchführen der Software-Programminstruktionen aufweisen. Die Kommunikation zwischen diesen Entitäten, wie in den 1, 7 und 12 dargestellt, können Netzwerkverbindungen sein, implementiert über ein globales Kommunikationsnetzwerk, wie Internet, ein Großbereich-Netzwerk, ein Lokal-Netzwerk, ein Intranet, ein Extranet, sowie Kombinationen dieser und anderer Netzwerke. Die 1, 7 und 12 können auf diese Weise auch als Systemdiagramme gesehen werden, welche die gegenseitige Verbindung zwischen Systemverarbeitungselementen zum Implementieren der entsprechenden Protokolle illustrieren.
Die oben beschriebenen Ausführungsformen der vorliegenden Erfindung sind nur als Erläuterung gemeint. So kann beispielsweise die vorliegende Erfindung angewandt werden zum Implementieren die Aufwertung oder einer anderen Neukonfiguration eines beliebigen gewünschten Software-Typs oder einer Hardware-Komponente, sowie als Kombination dieser und anderer Komponenten, für jeden gewünschten Typ einer Prozessorbasierten Einrichtung, und in vielen Applikationen, anders als die hier beschrieben worden sind. Die vorliegende Erfindung kann auch wenigstens teilweise in Form eines oder mehrerer Software-Programme implementier werden, die auf einem weiterhin herkömmlichen elektronischen, magnetischen oder optischen Speichermedium gespeichert und von einer Verarbeitungseinrichtung, beispielsweise den Prozessoren 220 und 230 des Systems 200 durchgeführt werden. Diese und viele andere Ausführungsformen im Rahmen der nachfolgenden Patentansprüche dürften dem Fachmann einfallen.

1

102: Zertifizierungsbehörde X
104: Content-Lieferant G
106: Vertraute Registrierungsbehörde (TRA)
108: Content-Konsument C
: Beantragung des Zertifikats
: Lieferung des Zertifikats
: Beantragung der Registrierung Q
: Lieferung des Registrierungsabschnitts Q'
: Verteilung des Registrierungsabschnitts Q' und des Contents M

2

102: Zertifizierungsbehörde
111: Ist der Antragsteller derjenige, den er sagt ?
112: Erzeugung eines öffentlichen Schlüsselpaars für den Antragsteller
113: Sichere Abgabe des privaten Schlüssels K_Prvrequestor an den Antragsteller
114: Kopplung von I_requestor und K_pubrequestor in einem Zertifikat
: Ende

3

104: Content-Lieferant G
121: Erzeugung eines Hash-Wertes für spezifischen Content M
122: Verschlüsselung von H mit dem privaten Schlüssel P_PrvG
123: Erzeugung von Q
: Ende

4

106: Vertraute Registrierungsbehörde (TRA)
131: Ist das Zertifikat für G gültig ?
132: Speicherung von H', I_G Zeit und Datum
133: Extrahierung des Hash-Wertes H von Q
134: Erzeugung des Registrierungsabschnitts Q'
: Ende

5

104: Content-Lieferant G
141: Ist das Zertifikat für TRA gültig ?
143: Speicherung von Q' und M zur Verteilung
: Ende

6

108: Content-Konsument C
151: Ist das Zertifikat für TRA gültig ?
153: Spiel/Speicherung des Contents M
: Ende

7

200: Zertifikatbehörde Y
102: Zertifikatbehörde X
104: Content-Lieferant G
106: Vertraute Registrierungsbehörde (TRA)
108: Content-Konsument C
: Beantragung des Zertifikats
: Lieferung des Zertifikats
: Beantragung der Registrierung für Q
: Lieferung des Registrierungsabschnitts Q'
: Verteilung des Registrierungsabschnitts Q' und des Contents M'
: Übersendung des Zertifikats und des verschlüsselten Hash-Wertes Q''
: Übersendung des Lizenzabschnitts L

8

104: Content-Lieferant G
221: Verschlüsselung des Contents M
222: Erzeugung eines Hash-Wertes für spezifischen Content M'
223: Verschlüsselung H mit dem privaten Schlüssel K_PrvG
224: Erzeugung von Q
: Ende

9

108: Content-Lieferant C
251: Ist das Zertifikat für TRA gültig ?
253: Speicherung des Contents M'
254: Erzeugung eines Hash-Wertes für den Content M'
255: Verschlüsselung H mit dem privaten Schlüssel K_PrvC
256: Erzeugung von Q''
: Ende

10

104: Content-Lieferant G
261: Ist das Zerifikat für C gültig ?
263: Verschlüsselung des Content-Schlüssels und Benutzungsregeln
264: Verschlüsselung des Lizenzschlüssels
265: Erzeugung von L
: Ende

11

108: Content-Konsument G
271: Entschlüsselung des Lizenzschlüssels L_license
272: Entschlüsselung der Regeln und des Content-Schlüssels
273: Entschlüsselung des Contents
274: Anwendung der Benutzungsregeln auf M
275: Spiel/Speicher5ung des Contents M
: Ende

12

13

104: Content-Konsument G
321: Verschlüsselung des Contents M
322: Erzeugung eines Hash-Wertes für einen spezifischen Content M'
323: Kopplung von Regeln an den Content-Schlüssel
325: Verschlüsselung von H1 und H2 mit dem privaten Schlüssel K_PrvG
326: Erzeugung von Q
: Ende

14

106: vertraute Registrierungsbehörde (TRA)
331: Ist das Zertifikat für G gültig ?
332: Speicherung H', I_G, Zeit und Datum
333: Extrahierung der Hash-Werte H1 und H2 von Q
334: Erzeugung des Content-Registrierungsabschnitts Q1'
335: Erzeugung der Benutzungsregel-Registrierungsabschnitts Q2'
: Ende

15

104: Content-Lieferant G
341: Ist das Zertifikat für TRA gültig ?
343: Speicherung von Q1', Q2' und M' zur Verteilung
: Ende

16

108: Content-Lieferant C
351: Ist das Zertifikat für TRA gültig ?
353: Speicherung des Contents M'
354: Erzeugung eines Hash-Wertes für den Content M'
355: Verschlüsselung H mit dem privaten Schlüssel K_PrvC
356: Erzeugung von Q''
: Ende

17

104: Content-Lieferant G
361: Ist das Zertifikat für C gültig ?
363: Verschlüsselung des Lizenz-Schlüssels
364: Erzeugung von L
: Ende

18

108: Content-Konsument C
372: Entschlüsselung des Lizenzschlüssels
373: Entschlüsselung der Regeln und des Content-Schlüssels
374: Entschlüsselung des Contents
375: Anwendung der Benutzungsregeln auf M
376: Spiel/Speicherung des Contents M
: Ende

Claims

Verfahren zum Verteilen des Contents von einem Content-Lieferanten (104) zu einem Content-Konsumenten (108), wobei das Verfahren die nachfolgenden Verfahrensschritte umfasst: – das Beantragen einer Registrierung des Contents mit einer zuverlässigen Registrierungsautorität (106); – das Empfangen von Registrierungsinformation von der zuverlässigen Registrierungsautorität; und – das Verteilen wenigstens eines Teils der Registrierungsinformation zu dem Content-Konsumenten im Zusammenhang mit dem Content; wobei die Registrierung des Contents mit der zuverlässigen Registrierungsautorität wenigstens teilweise auf ein Zertifikat basiert, erhalten von dem Content-Lieferant von einer Zertifizierungsautorität (102); dadurch gekennzeichnet, dass der Content-Lieferant einen Hash-Wert H für einen spezifischen Content M erzeugt, unter Verwendung des privaten Schlüssels K_PrvG H verschlüsselt zum Erzeugen eines verschlüsselten Hash-Werts H' und danach ein Paar Q wie folgt erzeugt: Q = (H', Certx(IG, KPubG))wobei Cert_x(I_G, K_PubG) das Zertifikat ist, das von der Zertifikatautorität erhalten worden ist, wobei das Zertifikat die Identität des Content-Lieferanten I_G und den öffentlichen Schlüssel K_PubG des Content-Lieferanten umfasst, und Q zur Registrierung der zuverlässigen Registrierungsautorität zuführt; und dass die zuverlässigen Registrierungsautorität bestimmt, ob das Zertifikat Cert_x(I_G, K_PubG) für den Content-Lieferanten gültig ist, die Registrierung ablehnt, sollte sie nicht gültig sein, und falls sie gültig ist, den verschlüsselten Hash-Wert H' zusammen mit I_G und Zeit und Datum des Empfangs speichert und den Hash-Wert H aus Q wie folgt extrahiert: H = D{KPubG}[H'],und danach die Registrierungsinformation in Form eines Registrierungsabschnitts Q' wie folgt erzeugt: Q' = E{KPrvTRA}[H] zum Beibehalten der Anonymität des Content-Lieferanten während der nachfolgenden Verteilung.
Verfahren nach Anspruch 1, wobei die Registrierungsinformation zu dem Content-Konsumenten verteilt wird, und zwar im Zusammenhang mit dem Content, so dass der Content-Lieferant daraufhin durch die zuverlässige Registrierungsautorität aus der dem Content-Konsumenten gelieferten Registrierungsinformation identifiziert werden kann.
Verfahren nach Anspruch 1, wobei der Content-Lieferant die Registrierungsinformation von der zuverlässigen Registrierungsautoritätempfängt, die Gültigkeit der Registrierungsautorität ermittelt, und wenn die Registrierungsautorität gültig ist, die Content- und die Registrierungsinformation für nachfolgende Verteilung zu dem Content-Konsumenten speichert.
Verfahren nach Anspruch 1, wobei der Content-Lieferant Q' von der zuverlässigen Registrierungsautorität empfängt und ermittelt, ob D{KpubTRA}[Q] = hash(M),und sollte dies so sein, Q' und M zur nachfolgenden Lieferung zu dem Content-Konsumenten speichert.
Verfahren nach Anspruch 4, wobei der Content-Konsument bei Empfang von Q' und M von dem Content-Lieferant ermittelt, ob D{KPubTRA}[Q'] = hash(M),und sollte dies so sein, den Content M benutzt.
Verfahren nach Anspruch 5, wobei wenn ermittelt wird, dass der Content M illegal ist, die Quelle des Contents durch die zuverlässige Registrierungsautorität identifiziert werden kann.
Gerät zur Verteilung von Content von einem Content-Lieferant (104) zu einem Content-Konsumenten (108), wobei das Gerät Folgendes umfasst: – eine Anordnung (104), assoziiert mit einem Content-Lieferanten und wie folgt wirksam: (i) zum Beantragen einer Registrierung des Contents bei einer zuverlässigen Registrierungsautorität (106); (ii) zum Empfangen von Registrierungsinformation von der zuverlässigen Registrierungsautorität; und (iii) zum Verteilen wenigstens eines Teils der Registrierungsinformation zu dem Content-Konsumenten im Zusammenhang mit dem Content; wobei die Registrierung des Contents bei der zuverlässigen Registrierungsautorität wenigstens teilweise auf einem Zertifikat basiert ist, das von dem Content-Lieferanten von einer Zertifikationsautorität (102) erhalten worden ist; dadurch gekennzeichnet, dass die Anordnung wirksam ist zum Erzeugen eines Hash-Wertes H für einen spezifischen Content M, zum Verschlüsseln von H unter Verwendung des privaten Schlüssels K_PrvG zum Erzeugen eines verschlüsselten Hash-Wertes H', und danach zum Erzeugen eines Paares Q, wie folgt: Q = (H', CertX(IG, KPubG)),wobei Cert_X(I_G, K_PubG) das Zertifikat ist, das von der Zertifikatsautorität erhalten worden ist, wobei das Zertifikat die Identität des Content-Lieferanten I_G und den öffentlichen Schlüssel K_PubG des Content-Lieferanten umfasst, und zum Senden von Q zu der zuverlässigen Registrierungsautorität zur Registrierung; und dass die Anordnung wirksam ist zum Empfangen der Registrierungsinformation in Form eines Registrierungsabschnitts Q' von der zuverlässigen Registrierungsautorität in Reaktion auf die Registrierungsautorität, die bestimmt hat, dass das Zertifikat Cert_X(I_G, K_PubG) für den Content-Lieferanten gültig ist, und den verschlüsselten Hash-Wert H' zusammen mit I_G und mit Zeit und Datum des Empfangs gespeichert hat, den Hash-Wert H von Q wie folgt extrahiert hat: H = D{KPubG}[H'],und den Registrierungsabschnitt Q' wie folgt erzeugt hat: Q' = E{KPrvTRA}[H],um die Anonymität des Content-Lieferanten während der nachfolgenden Lieferung beizubehalten.
Erzeugnis mit einem von einer Maschine auslesbaren Medium mit einem oder mehreren Softwareprogrammen zur Verwendung bei der Verteilung von Content von einem Content-Lieferanten (104) zu einem Content-Konsumenten (108), wobei die Soft wareprogramme, wenn sie durchgeführt werden, die Schritte des Verfahrens nach einem der Ansprüche 1 bis 6 implementieren.
Verfahren zum Erzeugen von Registrierungsinformation zur Verwendung bei der Verteilung von Content von einem Content-Lieferanten (104) zu einem Content-Konsumenten (108), wobei das Verfahren die nachfolgenden Schritte umfasst: – das Empfangen eines Antrags zur Registrierung des Contents mit einer zuverlässigen Registrierungsautorität (106); und – das Senden von Registrierungsinformation, erzeugt von der zuverlässigen Registrierungsautorität zu dem Content-Lieferanten, so dass der Content-Lieferant wenigstens einen Teil der Registrierungsinformation zu dem Content-Konsumenten liefern kann, und zwar im Zusammenhang mit dem Content; wobei die Registrierung des Contents bei der zuverlässigen Registrierungsautorität wenigstens teilweise auf dem Zertifikat basiert, das der Content-Lieferant von einer Zertifizierungsautorität (102) erhalten hat; dadurch gekennzeichnet, dass die Registrierungsautorität ein Paar Q empfängt, erzeugt von dem Content-Lieferanten, und zwar wie folgt: Q = H', CertX(IG, KPubG)),wobei H' ein verschlüsselter Hash-Wert für den spezifischen Content M ist, verschlüsselt unter Verwendung des privaten Schlüssels K_PrVG des Content-Lieferanten, und wobei Cert_X(I_G, K_PubG) das Zertifikat ist, das von der Zertifizierungsautorität erhalten worden ist, wobei das Zertifikat die Identität des Content-Lieferanten I_G und den öffentlichen Schlüssel K_PubG des Content-Lieferanten enthält; und dass die zuverlässige Registrierungsautorität bestimmt, ob das Zertifikat Cert_X(I_G, K_PubG) für den Content-Lieferanten gültig ist, die Registrierung verneint, wenn es nicht gültig ist, und wenn es gültig ist, den verschlüsselten Hash-Wert H' zusammen mit I_G und der Zeit und dem Datum des Empfangs speichert, und den Hash-Wert H von Q wie folgt extrahiert: H = D{KPubG}[H'],und danach die Registrierungsinformation in Form eines Registrierungsabschnitts Q' wie folgt erzeugt: Q' = E{KPubTRA}[H],um Anonymität des Content-Lieferanten während einer nachfolgenden Verteilung beizubehalten.